Internet Engineering Task Force Xiaoming Fu Internet Draft Rene Soltwisch University of Goettingen draft-fu-ccamp-traceroute-00.txt 23 June 2003 Expires: Dec 2003 A Proposal for Generic Traceroute Over Tunnels STATUS OF THIS MEMO This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress". The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt To view the list Internet-Draft Shadow Directories, see http://www.ietf.org/shadow.html. Abstract We identify some issues for generic traceroute for tunnels (tunnel- trace): (1) it is possible that some IP hops do not support tunneltrace, (2) for each tunnel wishing to be traced, at least the two end points should support the tunneltrace, (3) tracing message should be able to by- pass firewalls and NATs. One possible solution, based on the CASP signaling protocol (stateless mode), is proposed to support generic routetracing over tunnels. X. Fu et. al. [Page 1] Internet Draft CASP Traceroute 23 June 2003 1 Introduction UDP is the transport mechanism recommended as the basis for the IETF CCAMP WG towards a generic traceroute tool that can also verify tunnel paths and diagnose tunnel failures. Some protocols, e.g., GTTP [1], are being developed based on UDP. This draft identifies some issues concerning generic route tracing over tunnels and proposes a solution based on a generic signaling protocol. 2 Some Issues with Transport Support for Generic Traceroute In addition to the requirements for traceroute over generic tunnels pro- posed in [2], we find there are some other issues for a generic tracer- oute tool should consider: Transition requirements: it would be difficult to have all IP routers support the generic traceroute tool at the same time, thus it can be quite possible some of IP hops do not support the generic traceroute tool. Nevertheless, to enable tunnel tracing, at least tunnel entry and exit points should support the traceroute functionality. Firewall traversal: some network administrators deploy packet fil- ters which discard UDP or ICMP packets or packets with IP options. The decision for dropping packets these packets might be based on past security incidents. Thus, traceroute based on UDP, ICMP or UDP/raw IP with router alert option may fail. Transport of generic traceroute messages: it is possible (and adopted by most of existing proposals) to use UDP end-to-end addressing for the traceroute messages. However there are some potential problems, for instance: 1) collecting information about tunnels and nodes along the path might exceed the path MTU size. This might cause fragmen- tation and reassemply. 2) Routing assymmetry requires that tunnnel tracing to be ini- tiated by both end points to have information about the path in both directions. 3 Traceroute based on CASP (CASP-T) 3.1 CASP Introduction The Cross-Application Signaling Protocol (CASP) [3] is a generic signal- ing protocol for path-coupled (and path-decoupled signaling) between two X. Fu et. al. [Page 2] Internet Draft CASP Traceroute 23 June 2003 nodes. Particular path-coupled signaling is attractive for this applica- tion. CASP splits signaling message transport and application specific infor- mation. This allows to support different signaling applications to reuse the same underlying transport mechanism. Furthermore it allows to next-hop discovery from signaling message delivery, as shown in Fig- ure 1. The messaging layer is responsible for delivering signaling mes- sages from the initiator to the responder, typically the data source and the data sink, respectively, or the reverse way. The CASP messaging layer is built on existing reliable or unreliable transport protocols, such as TCP, SCTP or UDP, depending on the needs of the application. The client layer consists of a specialized client, namely next-peer dis- covery, and any number of specific signaling client protocols, which perform the actual signaling functions, e.g., QoS resource reservation, firewall and configuration, code distribution for active networks, and network diagnostics. Each node can choose its own next-hop discovery mechanism, relying on manual configuration, router advertisements, link state routing protocols, scout protocol [3], or server discovery solu- tions such as DNS or SLP. A CASP message is simply forwarded to next CASP hop if a CASP node doesn't support the requested client type. The stateful mode of CASP relies on the soft-state maintained for sig- naling clients and messaging layer. The stateless mode of CASP, however, does not establish state in IP devices by using record-route objects that enable to traverse the response message to follow the same path in the reverse direction. Traceroute based on CASP (CASP-T) works as a signaling client layer pro- tocol upon the stateless mode operation of CASP. Depending on the need of transport support, TCP or SCTP is recommended in CASP-T, but a CASP node can decide individually to use UDP if it knows there is no UDP firewall problem and the message size is not larger than MTU to next CASP node. 3.2 CASP-T Overview In this section, first we describe how the traceroute client for CASP (CASP-T) works, then present its general working environment. A CASP-T message traverses and records information in all intermediate nodes between a source (initiator) and a destination node in a hop-by- hop way. CASP-T returns information about the entire path with a single roundtrip instead of iteratively requesting more and more information. With regard to tunnels CASP-T works incrementally, which means, an X. Fu et. al. [Page 3] Internet Draft CASP Traceroute 23 June 2003 +- - - - - - - - - - - - - - - + - - - - - - - - - - - - - - + | +--------------+ | | Application+--------------+| |Signaling+--------------+|| | +------------------------+ | Protocols| CASP Clients ||+ |CASP Next-hop Discovery | | |eg.,CASP-T,QoS|+ | | Clients (e.g. Scout) | | CASP +--------------+ +------------------------+ Client | ^ | ^ ^ ^ | Layer +- - - - - - - - -| - - - - - -+ | | | =|=================|=========================|========|===|===|========= v v | | | +------------------------------------+ | | | CASP | CASP Messaging Layer | | | Messaging | +------------------------------------+ | | | Layer ^ ^ | | +- - - - - - - - - - - - - - - |- - - - - - - - |- - |- -| - + v v v | +-------------------------------+ +-------+ | |Reliable Transport(TCP,SCTP...)| | UDP | | +-------------------------------+ +-------+ | | | v +---------------------------------------------+ | IP | +---------------------------------------------+ Figure 1: Cross-Application Signaling Protocol intermediate tunnel immediately. First the signaling message discovers the end points of the tunnel, which then serves as a new source and des- tination for a subsequent CASP-T session. Once the response message is built the tunnel information is added. Essentially, CASP-T can be used to identify the top-level hops (without looking into tunnels or clouds do not support CASP-T), or all IP hops (including those within tunnels and non-CASP-T clouds) in between the initiator and the destination. Once the destination has been reached the results are sent back to its initiator. When an examination into a tunnel is performed, the results are not directly sent back to the tunnel entrance but forwarded from the tunnel end to the tier-1 next CASP hop for examination. When an error occurs, a CASP_TraceResponse message set with corresponding error code is sent back (in a hop-by-hop fashion) to the initiator on the same level, which is the CASP-T initiator or tunnel entrance in case of tun- nel examination. X. Fu et. al. [Page 4] Internet Draft CASP Traceroute 23 June 2003 When the destination on top level is reached a response message is sent back to the top level initiator. This message includes all captured information and provides the entire route information. Classical trace- route [4] can be incorporated within CASP-T to look into each IP hop between two CASP nodes, as described in Section 3.3. This allows CASP-T (and CASP) to be deployed incrementally. Figure 2 shows an example to illustrate how CASP-T can trace IP hops information inside a tunnel. At node B, CASP uses node D as destination of the next-hop discovery to learn the next CASP hop supporting CASP-T. Then it adds its local information into the traceroute payload of the CASP message, and forwards the message to the next hop. The tunnel exit point, node B, determines that it is not the final destination of the signaling message, and repeats the discovery process (if the next hop is not already known. end-to-end addressed signaling message +---------------------------------------------------------+ | (a tunnel: B-->D) | | %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% | A V B % C D % E| +----------+ +-----%----+ +----------+ +-----%----+ +---------+ | CASP-T | | CASP-T | | CASP-T | | CASP-T | | CASP-T | +----------+ +----------+ +----------+ +----------+ +---------+ | CASP-M |-->| CASP-M |-->| CASP-M |-->| CASP-M |-->| CASP-M | +----------+ +----------+ +----------+ +----------+ +---------+ | ^ | ^ | ^ | ^ | | | | | | | | +------------+ +--------+ +-----------+ +-----------+ hop-by-hop addressing and signaling message delivery Figure 2: Tunnel routetracing using CASP-T CASP-T is not necessary to be supported in all IP nodes; rather, it can be configured in a more flexible way. Figure 3 shows an example where protocol stacks regarding CASP are configured differently (next-hop dis- covery is necessary for all CASP nodes; here we omit it in the figure). CASP-T works on the Client Layer of the two-layer CASP architecture. It is based on the functionalities provided by the messaging layer of CASP, which supports secure, congestion-controlled delivery of signaling mes- sages (of any size and for any purpose) between each two CASP aware X. Fu et. al. [Page 5] Internet Draft CASP Traceroute 23 June 2003 nodes, while the next CASP node can be discovered by a special discovery client. Figure 3 illustrates a path from node A to B where node A, C and E support CASP-T but node B does not. Some nodes, for instance node D in our example, do not support CASP at all. Here, various nodes reuse the same CASP messaging layer (CASP-M) and different client layers (e.g. CASP-QoS and CASP-T). Interworking with CASP-QoS (e.g. Query message) is possible. end-to-end addressed signaling message +-------------------------------------------------------+ A V B C D E | +------+--------+ +--------+ +------+ +---------+ +------+--------+ |CASP-T|CASP-QoS| |CASP-QoS| |CASP-T| | IP hop, | |CASP-T|CASP-QoS| +------+--------+ +--------+ +------+ | no CASP | +------+--------+ | CASP-M |-->| CASP-M |-->|CASP-M|-------------->| CASP-M | +---------------+ +--------+ +------+ +---------+ +---------------+ | ^ | ^ | ^ +---------------+ +--------+ +----------------------+ hop-by-hop addressing and signaling message delivery Figure 3: A Possible Configuration 3.3 Incorporating with classical traceroute It is quite possible not all nodes along the path are CASP aware, there- fore, a classical traceroute based on ICMP responses (classical way of traceroute) is incorpated in CASP-T, to trace into such non-CASP-aware clouds along the path. Figure 4 illustrates an example where node A and D speak CASP but node B and C do not. When node A is reached, (classi- cal) traceroute is performed to discover IP addresses and delays for intermediate IP hops between A and D. These results, in addition to information like path MTU and RTT between A and D measured by CASP-T, are added as new trace objects to the CASP-Trace message in node A. This CASP-Trace message in A will be forwarded to node D by CASP-T, and node D will perform a similar operation as node A, until the destination is reached. 3.4 Error Handling X. Fu et. al. [Page 6] Internet Draft CASP Traceroute 23 June 2003 A B C D +-------+ +--------------+ +------+ +------+ |CASP-T | |normal IP node| | IP | |CASP-T| +-------+ +--------------+ +------+ +------+ | ^ ^ ^ ^ ^ | +--------------+ | | | | +----------------------------------+ | | | +--------------------------------------------------+ | | classical traceroute | +----------------------------------------------------------+ CASP_Trace Figure 4: CASP-T: Using Classical Traceroute Errors might be caused due to various reasons. One error reason might be a broken tunnel along the path and another reason might be caused by a lost ICMP packet or a firewall dropping packets. In such cases, an error has to be reported back to the initiator by a CASP-T node along the path discovering the error situation. 3.5 CASP-T Messages Currently, two types of CASP-T messages are defined: CASP_Trace and CASP_TraceResponse messages. As shown in Figure 5, a CASP_Trace message consists of one Initiator object and several Trace objects collected along the path. Figure 6 shows the CASP_TraceResponse message format. Trace objects collected along the path are encapsulated as the CASP_TraceResponse pay- load. Type: Identify the type of the message. Here, 2 for CASP_TraceRe- sponse. (Later version might include a reverse trace message.) Version: 4 bit Identifies the Version of the Protocol. Currently Version = 1. X. Fu et. al. [Page 7] Internet Draft CASP Traceroute 23 June 2003 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ | Type |Version| Error Code | Length | +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ | Tunnel depth |C | Reserved | +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ | Session ID | | // | +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ | Source ID | | // | +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ | Destination ID | | // | +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ | Timestamp (date, seconds) | | (milliseconds) | +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ | Initiator Object | | // | +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ | Authorization Token | +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ |nextObj + Object 1 | +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ |nextObj + Object 2 | +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ |nextObj + Object 3 | | // | Type: The message type (here, 1 for CASP_Trace) C=Classical traceroute flag Figure 5: CASP_Trace message format Error Code: 8 bit to identify protocol errors. 0 - no error 1 - access denied 2 - broken tunnel 3 - destination unreachable X. Fu et. al. [Page 8] Internet Draft CASP Traceroute 23 June 2003 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ | Type |Version| Error Code | Length | +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ | Session ID | | // | +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ | Source ID | | // | +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ | Destination ID | | // | +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ | Trace objects as payload | | // | Type: The message type (here, 2 for CASP_TraceResponse) Figure 6: CASP_TraceResponse message format Length: 16 bit The total length of the message Tunnel depth: 8 bit The maximum tunnel depth for the analyses. 0 - top level analysis only. 1 - 255 for the tunnel depth Classical traceroute flag: 1 bit 0 - CASP node examination only 1 - Classical traceroute enabled Session ID: 128bit An identifier to identify the CASP_Trace message. It can be a random number selected by the originator node. Source and destination ID: 128bit IPv4 address + identifier or IPv6 address Timestamp: 64bit 32 bit for date in seconds since 01/01/1970 X. Fu et. al. [Page 9] Internet Draft CASP Traceroute 23 June 2003 32 bit for milliseconds 3.6 CASP-T Objects Trace Object := := | | | | | | | | Depending on the ObjectType, ObjectValue can be one of the following: IPVersion: can be either 4 or 6. IPAddress: the node's IP address. LocalHop: an increasing number and counts hops. 0 for the first hop and all tunnel entrances ErrorCode: indicates what kind of error occurs. 0 if there was no error. 1 for timeout, 2 for destination unreachable, 3 for connection interruption, 4 for explicit rejection of the measurement response, 5 authorization required, 6 access denied Other codes are reserved. Delay: (in ms) shows the time to reach the node MTU: is the Maximum Transportation Unit which indicates the payload size of IP pages Level: shows the depth of the tunnel 0 indicates top level 1 one level of tunnel 2+ several level of tunnel in tunnel. Tunnel type: indicates what kind of tunnel the node belongs to. (For example, IP-in-IP encapsulation, IPsec, GRE, MPLS, L2TP or others) Classical_Tracroute_Object: The correspondent ObjectValue can be expressed as follows: X. Fu et. al. [Page 10] Internet Draft CASP Traceroute 23 June 2003 Value := The Classical_Traceroute_Object is used for the case that no CASP aware node are in between. In that case the classical traceroute is used. IPAddress is the classical traceroute ini- tiator. Next CASP_hop is the destination hop is the number of hops the reach the next CASP hop the result is the classical traceroute result. 4 Security Considerations CASP uses security mechanisms described in [3]. Generic traceroute over tunnels introduces some security threats, such as source authentication, trust relationships between neighboring nodes and between neighboring network domains. Authorization tokens are suggested in CASP-T to provide protection against such threats. The details are to be investigated in a future version of this document. 5 Open Issues and Discussions Third-party Tracing: CASP-T can support third-party tracing, by using the tracing source address different from the tracing initiator (with certain changes in operations). Overhead and Operational Time: Stateless mode of CASP does not introduce significant overhead in the nodes it traverses. As CASP is a generic protocol for various signaling purposes as well, it is possible to reduce the overall overhead if other signaling client protocols are supported. The way that results are forwarded over reliable connections makes that approach more robust against packet losses, and allows it to carry larger size of messages. However, this has to tradeoff with the possibly longer operational time because of the connection establishment. Nevertheless, due to the possibility of reusing existing TCP/SCTP connections (which can be used for both CASP-T and other signaling clients) between CASP hops, the average time for CASP-T can be, on average, low. Extensibility: use of TCP or SCTP allows larger size of traceroute message, avoiding fragmentation and defragmentation for deliv- ery of the traced data. For example, CASP can be also used for X. Fu et. al. [Page 11] Internet Draft CASP Traceroute 23 June 2003 discovery of more information, such as flow-based measurement information in IP nodes, if desired. 6 Acknowledgement We would like to acknowledge Hannes Tschofenig for his useful comments and discussions with Henning Schulzrinne. 7 Authors' Address University of Goettingen Institute for Informatics Lotzestr. 16-18 37083 Goettingen Germany EMail: [fu,soltwisch]@cs.uni-goettingen.de 8 Bibliography [1] R. Bonica et al., "Generic tunnel tracing protocol (GTTP) specifica- tion," Internet Draft, Internet Engineering Task Force, July 2001. Work in progress. [2] R. Bonica, K. Kompella, and D. Meyer, "Tracing requirements for generic tunnels," 2003. Work in progress. [3] H. Schuzrinne, H. Tschofenig, X. Fu, J. Eisl, and R. Hancock, "Casp -- cross-application signaling protocol." Internet draft, work in progress, Sept. 2002. [4] G. Kessler and S. Shepard, "A primer on internet and TCP/IP tools and utilities," RFC FYI 30, 2151, Internet Engineering Task Force, June 1997. X. Fu et. al. [Page 12] Table of Contents 1 Introduction . . . . . . . . . . . . . . . . . . . . . . 2 2 Some Issues with Transport Support for Generic Traceroute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 3 Traceroute based on CASP (CASP-T) . . . . . . . . . . . . 2 3.1 CASP Introduction . . . . . . . . . . . . . . . . . . . . 2 3.2 CASP-T Overview . . . . . . . . . . . . . . . . . . . . . 3 3.3 Incorporating with classical traceroute . . . . . . . . . 6 3.4 Error Handling . . . . . . . . . . . . . . . . . . . . . 6 3.5 CASP-T Messages . . . . . . . . . . . . . . . . . . . . . 7 3.6 CASP-T Objects . . . . . . . . . . . . . . . . . . . . . 10 4 Security Considerations . . . . . . . . . . . . . . . . . 11 5 Open Issues and Discussions . . . . . . . . . . . . . . . 11 6 Acknowledgement . . . . . . . . . . . . . . . . . . . . . 12 7 Authors' Address . . . . . . . . . . . . . . . . . . . . 12 8 Bibliography . . . . . . . . . . . . . . . . . . . . . . 12 X. Fu et. al. [Page 1]