Re: draft-ietf-ccamp-tracereq

[Xiaoming Fu <[e-mail]>]

Ron,

Ron Bonica wrote:
> Xiaoming,
> 
> I am not familiar with any traceroute implementations that use TCP. Could
> you point me at a reference?

Most are only used experimentally; you may find some in:
http://www.postel.org/pipermail/end2end-interest/2002-February/001820.html
http://honor.trusecure.com/pipermail/firewall-wizards/1998-December/004324.html
http://michael.toren.net/code/tcptraceroute/

> Why would TCP be preferable to UDP. Since you only expect one response to
> each probe, what value would TCP add?

For example, TCP might be useful for passing some firewalls and possibly
detecting them from the changes in the unreachable messages returned.
Furthermore, is it useful to introduce some kind of record-route object 
in the TCP/SCTP payload (using UDP may be also possible, but at least in 
some machines UDP messages are constrained by MTU) - which may be useful 
for logging topology, MTU, etc. - say, as shown in Option 1 or 2? I 
assume option 3 is the default way for traditional "traceroute" using 
ICMP/UDP/TCP.

      ----       ----     ----     ----
      |N1|  ---  |N2| --- |N3| --- |N4|
      ----       ----     ----     ----
      tcp ----> tcp
                 tcp ---> tcp
                           tcp ----> tcp
                               <----
                     <---
          <----
                  (option 1)


      ----       ----     ----     ----
      |N1|  ---  |N2| --- |N3| --- |N4|
      ----       ----     ----     ----
      tcp ----> tcp
                 tcp ---> tcp
                           tcp ----> tcp
          <-------------------------
                  (option 2)

      ----       ----     ----     ----
      |N1|  ---  |N2| --- |N3| --- |N4|
      ----       ----     ----     ----
      xxx <----> xxx
      xxx <-------------> xxx
      xxx <----------------------> xxx
                  (option 3)


BTW - text from http://michael.toren.net/code/tcptraceroute/:

"The more traditional traceroute(8) sends out either UDP or ICMP ECHO
packets with a TTL of one, and increments the TTL until the destination
has been reached. By printing the gateways that generate ICMP time
exceeded messages along the way, it is able to determine the path
packets are taking to reach the destination.

"The problem is that with the widespread use of firewalls on the modern
Internet, many of the packets that traceroute(8) sends out end up being
filtered, making it impossible to completely trace the path to the
destination. However, in many cases, these firewalls will permit inbound
TCP packets to specific ports that hosts sitting behind the firewall are
listening for connections on. By sending out TCP SYN packets instead of
UDP or ICMP ECHO packets, tcptraceroute is able to
  bypass the most
common firewall filters. "

Cheers,
Xiaoming
>                                                             Ron
> 
> 
>>-----Original Message-----
>>From: [e-mail] [mailto:[e-mail]]On
>>Behalf Of Xiaoming Fu
>>Sent: Wednesday, June 04, 2003 6:12 AM
>>To: Ron Bonica
>>Cc: [e-mail]
>>Subject: Re: draft-ietf-ccamp-tracereq
>>
>>
>>Ron,
>>
>>Thanks for your new version. One more issue:
>>
>>Current available transport mechanisms for traceroute include ICMP, UDP,
>>and TCP. UDP may relief DoS issues, but NAT/firewall might be another
>>issue (although we could have STUN). TCP has an issue of connection
>>setup latency, however it could be potentially considered (it may also
>>have a number of available ports?). To my knowledge, circulations from
>>one protocol to protocol are sometimes helpful, for example, SIP
>>initially used UDP, while TCP was recently proposed.
>>
>>Hence, I would suggest a "SHOULD" instead of "MUST" in Section 4.2.
>>
>>Cheers,
>>Xiaoming
>>
>>Ron Bonica wrote:
>>
>>>Xiaoming,
>>>
>>>Thanks for the thorough review. A new version of the draft is
>>
>>available at
>>
>>>http://www.bonica.org/docs/draft-ietf-ccamp-tracereq-04.txt.
>>>
>>>                              Ron
>>>
>>>
>>>
>>>
>>>>-----Original Message-----
>>>>From: [e-mail] [mailto:[e-mail]]On
>>>>Behalf Of Xiaoming Fu

>>>>Sent: Friday, May 30, 2003 7:20 PM
>>>>To: Ron Bonica
>>>>Cc: [e-mail]
>>>>Subject: Re: draft-ietf-ccamp-tracereq
>>>>
>>>>
>>>>Ron,
>>>>
>>>>It is a nice document. I went it through and have a few comments:
>>>>
>>>>- Section 3, 9) - "forwarding plane failu res" ==> _failures_
>>>
>>>
>>>Oops....
>>>
>>>
>>>
>>>>- I didn't understand why the following paragraph appears twice - the
>>>>  same in Section 3, 13) and 14). I assume you're talking about control
>>>>  plane failure in 13).
>>>>      Justification: MTU information is sometimes useful in identifying
>>>>      the root cause of forwarding plane failures.
>>>
>>>
>>>You have a point. MTU information, in either direction, can be useful in
>>>debugging
>>>both control and forwarding plane failures. The paragraph should read as
>>>follows in
>>>both 3.13 and 3.14:
>>>
>>>Justification: MTU information is sometimes useful in identifying
>>>the root cause of forwarding and control plane failures.
>>>
>>>
>>>
>>>>- Again, Section 3, 14):
>>>>      14) When tracing through the forwarding plane, display the MTU
>>>>      associated with each hop in the reverse direction.
>>>>  Meanwhile, in Section 4.3:
>>>>      The protocol must be stateless. That is, nodes should not have to
>>>>      maintain state between successive traceroute messages.
>>>>  Are you assuming the probe and response messages are always
>>
>>hop-by-hop
>>
>>>>  addressed? Otherwise, the forwarding and reverse paths of
>>
>>transporting
>>
>>>>  the probe & response pair could differ, e.g., due to the Internet
>>>>  routing, or policies. And -
>>>>  Do we need a same transport path for them? If so, how a stateless
>>>>  traceroute protocol knows the reverse path to forward the response
>>>>  message?  Probably we could create a temporary state while handling a
>>>>  probe message, to include P_HOP & Interface information like in RSVP,
>>>>  although the state is used only once in this case.
>>>
>>>
>>>Requirements 13 and 14 are ambiguous. As a result, you have interpretted
>>>them
>>>in a manner that was not intended. They should be restated as follows:
>>>
>>>13) When tracing through the control plane, display the MTU
>>
>>associated with
>>
>>>interface
>>>that forwards datagrams through the traced path.
>>>
>>>14) When tracing through the forwarding plane, display the MTU
>>
>>associated
>>
>>>with each
>>>interface that receives datagtrams along the traced path.
>>>
>>>
>>>
>>>>- Section 4.1 - I don't understand the following sentense:
>>>>                             Many network forward datagrams
>>
>>that specify
>>
>>>>    IP options differently than they would forward datagrams
>>
>>that do not
>>
>>>>    specify IP options.
>>>>  Maybe they ==> them, but the implication of this sentense is still
>>>>  unclear to me.
>>>
>>>
>>>This paragraph should read as follows:
>>>
>>>Many networks forward datagrams that specify IP options differently than
>>>they would forward datagrams that do not specify IP options. Therefore,
>>>the introductions of IP options would cause the application to trace a
>>>forwarding path other than the path that its user intended to trace.
>>>
>>>
>>>
>>>>- Section 4.2 "IP was _disqualified_ in order to conserve protocol
>>>>   identifiers." - I'm not sure this is always valid. Anyway,
>>>>   using UDP would have also to request a port number from IANA; there
>>>>   is actually a tradeoff among protocol_ID v.s. port number v.s. ICMP
>>>>   type. BTW, UDP may introduce a little (although minor)
>>>>   additional overhead.
>>>
>>>
>>>IANA is much more willing to assign UDP port numbers than protocol-IDs.
>>>This is because there are so many more UDP port numbers available.
>>>
>>>
>>>
>>>>- In general I would expect the document would not constrain too much
>>>>  on protocol details - the latter looks to me more of a protocol
>>>>  design issue, instead of an informational RFC on "requirement".
>>>
>>>
>>>In principle, I agree. Section 4 provides just enough protocol
>>
>>requirements
>>
>>>to keep protocol designers away from some known bad design
>>
>>approaches. For
>>
>>>example,
>>>years ago we tried returning MPLS information in ICMP
>>
>>datagrams. This wasn't
>>
>>>well received. So, the requirements document guides us around that bad
>>>approach.
>>>
>>>
>>>
>>>>- It looks better if an experimental traceroute protocol (RFC1393 -
>>>>  traceroute using an IP option) would be referenced and shortly
>>>>  introduced in Section 2 (e.g., MTU determination).
>>>
>>>
>>>I thought about referencing RFC 1393 but decided not to because
>>
>>it is not
>>
>>>widely known or implemented.
>>>
>>>                                             Ron
>>>
>>>
>>>
>>>>My 2 cents.
>>>>
>>>>Xiaoming
>>>>
>>>>Ron Bonica wrote:
>>>>
>>>>
>>>>>Folks,
>>>>>
>>>>>At the request of the IESG, I have updated
>>
>>draft-ietf-ccamp-tracereq and
>>
>>>>>sent a new copy to the draft editor. Until the draft editor
>>>>
>>>>posts it, a copy
>>>>
>>>>
>>>>>can be found at
>>>
>>>http://www.bonica.org/docs/draft-ietf-ccamp-tracereq-03.txt.
>>>
>>>
>>>>Please take a look, as this draft will need to go through
>>
>>another WG last
>>
>>>>call.
>>>>
>>>>===========================================
>>>>Ronald P. Bonica       Ph: 703 886 1681
>>>>vBNS Engineering       page: 1 888 268 8021
>>>>Ashburn, Va.
>>>>===========================================
>>>>"We are not on Earth to guard a museum, but
>>>>to cultivate a flourishing garden of life."
>>>>               -- Angelo Giuseppe Roncalli
>>>>
>>>>
>>
>>
>