re: draft-bonica-tunneltrace-02

["Thomas D. Nadeau" <tnadeau@cisco.com>]

At 10:59 AM 2/20/2002 -0500, David Allan wrote:

>Ron:
>
>I have a number of comments on the draft.
>
>Clarifications:
>
>The discussion of traceroute in section 5, 2nd para. Are you really saying 
>that
>traceroute only reveals the current layer/level and reveals no knowledge 
>of nesting of
>lower layer/level tunnels or the relationship of the current level to 
>higher levels?
>It doesn't clearly come out.
>
>Comments on application requirements (numbers correspond to the requirement):
>
>1) I think a broader discussion of some of the security issues needs to be 
>raised. First by
>whatever means a trace request needs to be able to be instantiated at a 
>tunnel end
>point. Second, as a result of initiating a trace, any node in the network 
>may be required to
>generate a response to the tracing application. Therefore the tracing 
>application is required
>to promiscuously accept responses. A mechanism is required to 
>authoritatively associate
>responses with requests and discard spurious messages. Further such a 
>mechanism should not be
>able to be leveraged for denial of service attacks (e.g. spurious trace 
>responses forcing lots
>of cryptography, defense against replay attacks etc.).
>
>2) Any interface? I think any routable interface (mind you this is where 
>separating out routing
>limitations into a separate section reduces the clarity). I think there is 
>a separate stipulation that
>there is no representation as to the number of protocol exchanges it takes 
>to perform a trace
>(other than permitting the trace originator to perform some measure of 
>flow control by the protocol
>being designed to bound the number of responses a transaction will elicit; 
>ideally 1 to 1, this also
>has DOS implications similar to ICMP smurf type attacks whereby the 
>responses to a single
>message can be unbounded). You actually bring this up obliquely in the 
>protocol requirements, but IMHO it
>should be expressed less prescriptively.
>
>3) Is third party really a special case? Can I not instantiate an in-line 
>trace using management
>protocols etc. and pull back the results.

         You can certainly envision a proprietary (or standard) MIB
that could be crafted to configure and then activate the tunnel
trace operation (or many of them) remotely. Depending on how you have
your security configured, 3rd parties can be allowed to do this. I would
treat this as a special case only that special security measures need to be
taken to ensure that only the right 3rd party (or customer) has
access to the tools. Once authenticated, the operations should be the same
as if an operator was running the tool. An example of this in today's 
environment,
some companies offer VRF-aware ping MIBs for some of their customers
that they may also use themselves.

         --Tom



>4) the application "displays" tunnels (editorial nit)? are we really 
>discussing how much information the
>application collects and reports on. The alternative interpretation is 
>that the same amount of
>information is always collected, and somehow filtered during presentation.
>
>4) When you say "single hop" or "in detail", are you really saying "this 
>layer" or "constituent
>lower layer components"? It could use clarification.
>
>5) Are you sure the collected information includes round trip delay? It's 
>not clear to me
>whether this is some pre-existing chunk of information just lying around, 
>or where the trace
>transaction is expected to measure RTT on the fly for every hop and 
>provide current view.
>
>6) I think are more accurate statement is support any tunneling technology 
>that is used between
>IP endpoints. Otherwise this is not a sustainable requirement. I am 
>concerned, for example, that
>any intervening L2 or layer 2 and a half skewers the model. (e.g.. 
>IP/PPP/L2TP, you can only
>reveal the PPP end points, or if you look at L2TP tunnel switches, you 
>appear to be SOL)
>
>7) This is the "detail" referred to earlier? Seems this one is subject to 
>the routing
>requirements reported later. Might be easier simply to introduce that 
>limitation here.
>
>8) Is the expectation that the quality of information obtained from a 
>control plane trace and a
>forwarding plane be comparable? Can you clarify what you mean by a control 
>plane trace? I can see augmenting
>signalling protocols to faciliate this (e.g. LSP query I-D), but that does 
>not fit into this discussion.
>
>10) This seems to be overlapping with a solution framework.
>
>11) Any intention of aligning TTL models with the terminology emerging 
>elsewhere (pipe or uniform
>models?).
>
>13) Don't quite grok the motivation. I plead ignorance ;-)
>
>The protocol requirements section is actually rather prescriptive. There 
>are specific requirements
>in there that end up as either application limitations or part of an 
>applicability statement (e.g. routing
>requirements) or design guidelines. The rest shouldn't be in this document.
>
>IMHO at the present time the document is not quite ready for "prime time".
>
>my two cents
>Dave



------------------------------------------------------------------------
Mathematics is the supreme nostalgia of our time.