RE: draft-bonica-tunneltrace-02

-----Original Message-----
From: David Allan [mailto:dallan@nortelnetworks.com]
Sent: Wednesday, February 20, 2002 10:59 AM
To: Ron Bonica
Cc: ccamp@ops.ietf.org
Subject: re: draft-bonica-tunneltrace-02

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.

This is the case for some tunnel types, but not others. The next two paragraphs provide examples.

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.).

Hmm.... good point! I thought about the probed device authenticating traceProbes, but never considered the possibility that the probing device might need to authenticate responses. I will add this to the next draft version.

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.

One of our initial requirements was to provide all of the functionality that "traceroute" currently provides. Currently, traceroute supports third party traces. Unfortunately, it does so using the IP source routing option. I wanted to support this functionality without fundamentally altering the routing mechanism.

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.

Again, we are mimicking functionality currently provided by traceroute. We would timestamp probes and echo the timestamp back in responses. The tracing application could calculate RTT by comparing the current time with the timestamp.

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)

I am not sure that I agree. Given that the device at the head end of the L2TP tunnel tells us that there is an L2TP tunnel involved, what stops us from tracing through it?

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.

No. Requirement 4 states that the application will tell us details about a tunnel. Requirement 7 states that the application can tell us details about tunnels within tunnels.

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.

Currently, traceroute traces through the forwarding plane. It sends a probe downstream and each network device responds, indicating that it has received the probe. When tracing the forwarding plane, only the device at the tail-end of a hop can report on that hop.

Alternatively, we could ask the device at the head end of each hop to report on the downstream interface. This is tracing through the control plane.

Generally, control plane information and forwarding plane information are pretty similar. There are, however, times when the two diverge. For example, when tracing through the forwarding plane of an MPLS LSP that is configure for penultimate hop popping, the egress LSR would have no way to know that a datagram was delivered through an LSP.

How would you trace through the forwarding plane for tunnel types that do not support TTL decrement?

11) Any intention of aligning TTL models with the terminology emerging elsewhere (pipe or uniform
models?).

We could actually expand this requirement to include more interface attributes and do it in both directions. You could get attributes in one direction when tracing the control plane and in the other direction when tracing the forwarding plane.

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.