Ron:
Thanks for the reply. Comments in line:
rgds
Dave
<snip>
>> 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.
I'll read it again. I interpreted it is "I can see the current hop, or i can see the underlying hops, it all depends on what level/layer I insert my probes", that struck me as rather self evident but awkwardly worded.
>>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.).
>
> 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.
Actually the problem breaks down into about 4 things:
- any host can inject trace requests into the network.
- if you do not want to share trace information on your network, the only mechanism is to block replies.
- if you are able to block replies, you are screening initiators (who can be anyone). This imples authentication and replay protection.
- any host can send malicious replies to a tracing agent.
- you don't want unauthorized folks instructing other network elements to do things, but that is more an requirement of the system design, and not necessarily that of the protocol.
>>
>> 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.
>
> I am not sure that I understand the comment. Could you restate it?
Sure: There's actually two points in here, mainly relating to protocol
requirements:
- one is the editorial suggestion that non-prescriptive requirements get
extracted from the protocol requirements section and added to the
application requirements section to improve clarity.
- the other is that rather than stipulating that the protocol design is
built around two legged transactions, that it simply be able to pace
itself by having any transaction have a bounded number of responses. It
doesn't have to explicitly be one.
>> 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.
I'm not sure that saying this has to be a superset of traceroute is
sustainable, simply desirable. I would agree with eliminating source
routing as that is a major security hole. Can I suggest that the
document suggest that third party traces would be a useful function, and
that the mechanism chosen should avoid solutions with known problems
(such as source routing).
>> 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.
>>
> The former. I will clarify this.
Great.
>> 4) When you say "single hop" or "in detail", are you really saying "this
>> layer" or "constituent lower layer components"? It could use clarification.
>
> Yes. Again, I will clarify this
Again, great.
>> 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.
The statement "RTT across each component" led me to believe you were measuring each hop.
The other observagtion is that this would be irrelevant for third party traces as it would include
the latency from the tracing agent to one tunnel endpoint, and the
latency from the intermediate node (where TTL exhaust occurred or
whatever the mechanism used was) back to the tracing agent, plus if the
authentication/priviledge token had any crypto requirements, this would
introduce additional latency that had nothing to do with the path under
trace.
>> 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?
Okay, there was the two scenarios I mentioned. One was PPP over L2TP.
The PPP would render the trace impossible as the LAC would not be
visible to the client IP layer trace. The LNS would, so I suppose you
could work backwards. The other is when there is a tunnel switch, where
I can trace the client layer, but when I try to trace the IP carrying
the L2TP, it would have to have knowledge of the tunnel switch function
in order to accurately report the real path. Put my LAC in Ottawa, my
LNS in Toronto and my tunnel switch in Vancouver. The stuff is actually
going Ottawa, Vancouver Toronto, but the trace of the layer below L2TP
would only know the IP endpoints, and would trace the shortest path
Ottawa->Toronto.
I think the generalized statement is that the tunnel technology must support IP/TTL at every hop.
>> 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.
I'm missing the distinction, only being able to recurse once (rq 4)
seems to be an artificial restriction.
>> 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.
Now I understand what you meant by control plane. Actually I would have thought of
this as tracing through the forwarding table. What should happen vs. what does happen. That does'nt necessarily detect when what should happen is wrong but it catches disconnects. That does look useful, I would have described it differently.
> 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.
> The control and forwarding plane can also diverge when routers are broken.
>> 10) This seems to be overlapping with a solution framework.
> How would you trace through the forwarding plane for tunnel types that do
> not support TTL decrement?
I understand the point, more philosophical that it should not appear in
a requirments document, even if the obvious solution.
Your staring point is the traceroute application, my starting point is more generic.
>> 11) Any intention of aligning TTL models with the terminology emerging
>> elsewhere (pipe or uniform models?).
Always glad to clarify terminology.
>> 13) Don't quite grok the motivation. I plead ignorance ;-)
> 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.
I should have been more clear. I did not understand why I would want to collect reverse direction information. As the reverse path between two points frequently will be disjoint from the forward path, struck me I was simply collecting a lot of noise.
>> 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".