RE: draft-bonica-tunneltrace-02

["David Allan"<dallan@nortelnetworks.com>]

Title: re: draft-bonica-tunneltrace-02

Neil:

 

My comment on the stuff turning up anywhere was more specific to IP. Given that the network implements the service, a packet (that deliberately TTL exhausts prematurely while on it's way between two points) ending up just about anywhere could be a legitimate network response to a fault or combination of faults, this is in addition to genuine misdirection (forwarding table problems or similar).

 

This behaviour is common to a set of identified technologies (in particular forwarding driven by IP routing, with TTL on the forwarding plane) and drives some of the requirements esp w.r.t. authorization/policy etc. Other solutions for specific tunnel applications may have different attributes/requirements (e.g. optical, ER-LSPs etc., concatenated L2TP tunnels) where the traced entity is a closed system.

 

Dave

 

 -----Original Message-----
From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com]
Sent: Thursday, February 21, 2002 3:08 PM
To: Ronald.P.Bonica@wcom.com; Allan, David [CAR:NS00:EXCH]
Cc: ccamp@ops.ietf.org
Subject: RE: draft-bonica-tunneltrace-02

Hi Ron....nice to us getting back on to the real discussion here.  Few small observations below.

Regards, Neil

-----Original Message-----
From: Ron Bonica [mailto:Ronald.P.Bonica@wcom.com]
Sent: 21 February 2002 19:32
To: David Allan
Cc: ccamp@ops.ietf.org
Subject: RE: draft-bonica-tunneltrace-02

Hi David,

 

Comments inline......

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

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.  

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

NH=> I am really glad you pointed this out Ron and its something I have tried to explain to randy in an earlier mail.  That is, whilst the *function* we are trying to use here (ie trail-trace) is common (wrt objectives to be met) one has to accept/understand the nuances/limitations of the technology of the layer network trail in question.  In other words, it can't be strictly *common* in functional behaviour as the server layer technologies are different.   Quite obvious IMO.

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.  

NH=> This is also related to the point in my earlier mail about usually having to assume a network to be defect free so that any such 'request/response' pairs work in an expected manner.  I suspect Dave is alluding to the case where the 'request' pkt ends up at unexpected nodes (eg due to swapped or mismerged LSPs say) and so (i) there has to be a viable return path from anywhere and (ii) the nodes getting the requests must be able to respond.....and if you expect to use this under such defect conditions, then by inference the whole network must be 'GTTP aware' and constantly looking for request occurences.