Re: draft-bonica-tunneltrace-02

[Loa Andersson <loa.andersson@utfors.se>]

All,

a more IETF (possibly ccamp) philosophical question. What do
we do when we accept a document as a WG document. In my mind
it is a step taken when we realise that this is something that
the WG group should do and the document is a good enough starting
point for doing this work.

Even if I agreed with all of Dave's comments it is my 2 c's
that both the criteria above are met and that we should progress
the doc as a WG document.

There will be a couple of iterations where the comments will be
addressed and possibly be worked into the final req doc.


/Loa

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


-- 
Loa Andersson
Chief Architect,
Utfors Research, Architecture and Future Lab (URAX)
Utfors AB
Råsundavägen 12
Box 525, 169 29 Solna
Office          +46 8 5270 2000
Office direct   +46 8 5270 5038
Mobile          +46 70 848 5038
Email           loa.andersson@utfors.se
WWW             www.utfors.se