Internet Draft R. Bonica Expiration Date: January 2002 WorldCom E. Rosen Cisco Systems K. Kompella Juniper Networks D. Meyer Sprint R.Dube Xebeo Communications July 2001 Generic Tunnel Tracing Protocol (GTTP) Specification draft-bonica-tunproto-01.txt 1. Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of [RFC-2026]. 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 The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. 2. Abstract This document describes the Generic Tunnel Tracing Protocol (GTTP). GTTP supports enhanced route-tracing applications. Network operators use enhanced route-tracing applications to trace through an IP network's forwarding plane (including the MPLS forwarding plane). Enhanced route-tracing applications also reveal details regarding IP and MPLS tunnels that contribute to the traced path. 3. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC-2119]. 4. Introduction This document describes the Generic Tunnel Tracing Protocol (GTTP). GTTP supports enhanced route-tracing applications. Network operators use enhanced route-tracing applications to trace through an IP network's forwarding plane (including the MPLS forwarding plane). Enhanced route-tracing applications also reveal details regarding IP and MPLS tunnels that contribute to traced path. A companion document [TUNREQ] specifies requirements for enhanced route-tracing applications. Each section of this document presents a significant aspect of GTTP. This section describes the generic tunnel-tracing problem and provides an informal description of GTTP. Section 5 describes protocol mechanisms and Section 6 describes IANA considerations. Section 7 details security considerations. 4.1. The Tunnel Tracing Problem ----- | D0 | |Route| |Trace| ----- | | - H1 - H2 - H3 - (IP) -|D|----|D|-------------------------------------|D|----|D| |1| |2| H2:1 - H2:2 - H2:3 |3| |4| (IP) | | | |------|D|-------------------|D|------| | | | - - |5| H2:2:1 - H2:2:2 |6| - - (MPLS) | |--------|D|--------| | - |7| - | | - Figure 1: Tunnel Tracing Problem Figure 1 depicts eight IP accessible devices (D0 through D7). A route-tracing application executes upon device D0. The route-tracing application must trace the route between the D1 and D4. In this example, assume that the traced route originates on D1's loopback interface and terminates on D4's loopback interface. The route between D1 and D4 contains three Top Level Hops (TLH) . These are H1, H2 and H3. An IP-in-IP tunnel supports H2. The IP-in-IP tunnel itself contains three hops. These hops, H2:1, H2:2 and H2:3, are subordinate to H2. Finally, an MPLS LSP supports H2:2. The LSP contains two hops, H2:2:1 and H2:2:2. 4.2. Informal Protocol Description GTTP supports two PDU types. These PDUs represent a TraceProbe and a TraceResponse. Route-tracing applications emit a series of TraceProbes in order to obtain information regarding the path that connects two network interfaces. Specifically, route-tracing applications emit one TraceProbe to discover each hop that contributes to the traced path. Each TraceProbe elicits exactly one TraceResponse. Each TraceResponse reveals details concerning one hop that contributes to the traced path. That hop may represent a TLH or part of a subordinate tunnel. The User Datagram Protocol (UDP) carries all GTTP traffic. IANA will assign a UDP port to GTTP. Route-tracing applications will direct all TraceProbes to this well-known port and network elements will listen for GTTP traffic on this well-know port only. Route-tracing applications will listen for TraceResponses on a non-well-known port that they will specify in the corresponding TraceProbe's UDP source address. UDP obtains network layer services from IP. IP datagrams that carry GTTP MUST NOT specify IP options. 4.3. Discovering the Top-Level Path In the example above, the route-tracing application sends one TraceProbe to discover H1, another TraceProbe to discover H2, and a third TraceProbe to discover H3. Each TraceProbe elicits a single TraceResponse and each TraceResponse provides details regarding a single TLH. The application sends its first TraceProbe to D1, in order to discover H1. The TraceProbe contains the following information: 1) The IP address of the route-tracing application 2) A Sequence Number, used to match TraceProbes with TraceResponses 3) An IP address that identifies the head-end of the traced path (i.e., D1's loopback address) 4) A Path Identifier Object (PIO). In its simplest form, the Path Identifier Object identifies the traced path by its destination address (i.e., D4's loopback address). In a more complex form, the PIO identifies the traced path based upon an incoming interface (or sub-interface), a tunnel header (e.g. MPLS header), and an IP header. 5) A TLH Identifier. The TLH identifier identifies the TLH about which the application is requesting information. In this case, the value "1" represents the first TLH (i.e., H1). 6) A Tunnel Hop Identifier. As this probe solicits TLH details, this value is equal to zero. 7) An optional Access Control Object (ACO) D1 receives the TraceProbe, removes its IP and UDP headers, and delivers it to a local GTTP module. The GTTP module examines the TraceProbe ACO in order to determine whether local security policy permits it to process the probe. If security policy does not permit the GTTP module to service the probe, D1 can either silently discard the TraceProbe or send D0 a TraceResponse, indicating insufficient privilege, as per local security policy. If security policy permits the GTTP module to process the probe, the GTTP module examines the TraceProbe and determines that it is soliciting details regarding a downstream TLH. Therefore, the GTTP module relays the TraceProbe downstream. First, if required by PIO size specifications, the GTTP module pads the TraceProbe. Next, the GTTP module encapsulates the TraceProbe in a UDP header. The GTTP module then encapsulates the UDP packet in an IP header. The IP header contains information specified by the original TraceProbe's PIO. The GTTP module then copies the original TraceProbe's TLH Identifier to the IP header TTL field and recalculates the IP header checksum. D1 then forwards the TraceProbe downstream as per all PIO specifications. (Note that the Layer 2 interface and tunnel upon which a datagram might arrive can contribute to PIO specifications.) In our example, D1 forwards the TraceProbe through H1 to D2. D2 decrements the TTL value to 0 and forwards the datagram to an error- processing module. The error-processing module sends an ICMP Time Expired Message to D1. D1 discards this ICMP message. The error-processing module then forwards the TraceProbe to a local GTTP module. The GTTP module examines the TraceProbe ACO in order to determine whether local security policy permits it to process the probe. If security policy does not permit the GTTP module to service the probe, the GTTP module silently discards the TraceProbe. If security policy permits the GTTP module to process the probe, the GTTP module examines the TraceProbe and determines that it is soliciting details regarding a directly connected, upstream TLH. Therefore, D2 sends D0 a TraceResponse. The TraceResponse contains the following information: 1) The IP address of the route-tracing application 2) A Sequence Number, used to match TraceProbes with TraceRespones 3) An IP address identifying the interface upon which the TraceProbe arrived. If the TraceProbe arrived on an unnumbered interface, this IP address will not uniquely identify the interface upon which the TraceProbe arrived 4) The MIB-II ifDescr value associated with the interface upon which the TraceProbe arrived. This value, in conjunction with the IP address mentioned above, SHOULD uniquely identify the interface upon which the datagram arrived. 5) A Tunnel Security Status (TSS). This value indicates whether local security policy permits GTTP to reveal tunnel details. 6) A Tunnel Identifier Object (TIO). The TraceResponse contains a TIO if security policy permits GTTP to reveal tunnel details and if the TraceProbe was encapsulated in a tunnel header when it arrived at the probed node. The TIO contains several data items. One data item represents the type of the outermost tunnel (e.g., IP-in-IP, MPLS). Another data item represents the entire tunnel header stack, as it encapsulated the TraceProbe when it arrived at the probed network element. Another data item represents a tunnel identifier that is shared between the tunnel ingress and tunnel egress nodes. (This data item is empty when the tunneling mechanism does not support such a shared identifier). 7) Egress Indicator. This field indicates whether the TraceResponse was sent by the tail-end of the traced path. The GTTP module sets this Egress Indicator if the tail-end of the traced path, as specified by the PIO, is a local interface. 8) An Optional Access Control Object (ACO). This object is copied from the TraceProbe. D0 receives the TraceResponse and processes it if the ACO matches that which was sent in the corresponding TraceProbe. D0 repeats the procedure described above, incrementing the TLH identifier in order to discover each subsequent TLH. Specifically, D0 sends each TraceProbe to D1 and D1 probes the traced path. D0 repeats this process until it receives a TraceResponse from the tail-end of the traced path. Local policy determines how many times D0 should probe each hop. It also determines how long D0 should wait for a response to each probe and the maximum number of probes that D0 should send in order to trace a given path. In order to trace the top-level path accurately, D2 must be configured so that it sets TTL value specified by the outer header of its IP-in-IP tunnel to an appropriately high value. 4.4. Discovering First Order Tunnel Details At this point, the network has revealed details regarding H1, H2 and H3. D3 also has provided cursory information regarding the IP-in-IP tunnel that supports H2. D2 and D4, however, have provided no information regarding tunnels that might support H1 and H3. Even though D2 and D4 returned a TraceProbe that did not include a TIO, tunnels may support H1 and H3. For example, an MPLS LSP that engages in penultimate hop popping may support H1. In this case, a TraceProbe would arrive at D2 without an MPLS header and D2 would return a TraceResponse that does not include a TIO. Therefore, the route-tracing application must probe D1, D2 and D3 for details regarding tunnels that might support H1, H2 and H3, respectively. The route-tracing application begins by sending a TraceProbe to D1. The TraceProbe contains the following information: 1) The IP address of the route-tracing application 2) A Sequence Number, used to match TraceProbes with TraceResponses 3) An IP address that identifies the head-end of the traced tunnel (i.e., D1's loopback address) 4) A Path Identifier Object (PIO). This PIO contains values identical to those that were sent to D1 while tracing the top- level path. 5) A TLH Identifier. As this TraceProbe solicits tunnel details, the TLH identifier is equal to zero. 6) A Tunnel Hop Identifier. The Tunnel Hop Identifier represents a tunnel hop about which the current TraceProbe is soliciting details. In this case, a value of 1 represents the first hop in a tunnel that might support H1. 7) An optional Access Control Object (ACO) D1 receives the TraceProbe, removes its IP and UDP headers, and delivers it to a local GTTP module. The GTTP module examines the TraceProbe ACO in order to determine whether local security policy permits it to process the probe. If security policy does not permit the GTTP module to service the probe, the D1 can either silently discard the TraceProbe or send D0 a TraceResponse, indicating insufficient privilege, as per local security policy. If security policy permits the GTTP module to process the probe, the GTTP module examines the TraceProbe and determines that it is soliciting details regarding the first hop of a particular downstream tunnel. (The GTTP module makes this determination based upon the Tunnel Hop Identifier value). Therefore, D1 queries its routing information and determines that no tunnel supports H1. Having made this determination, D1 sends D0 a TraceResponse message that does not include a TIO. D0 receives the TraceResponse and processes it if the ACO matches that which was sent in the corresponding TraceProbe. Having processed this TraceResponse, D0 is informed that no tunnel supports H1. D0 now probes D2, soliciting details concerning the tunnel that supports H2. Specifically, D0 sends D2 a TraceProbe. The TraceProbe contains the following information: 1) The IP address of the route-tracing application 2) A Sequence Number, used to match TraceProbes with TraceResponses 3) An IP address that identifies the head-end of the traced tunnel (i.e., D2's loopback address) 4) A Path Identifier Object (PIO). The PIO contains the same IP header that all previously mentioned PIOs contained. The route- tracing application augments this information information that was obtained from D2 while discovering the top-level path. For example, while discovering the top-level path, the the route- tracing application learned that D2 received its TraceProbe from a particular sub-interface. The route-tracing application specifies this sub-interface in the PIO when probing D2 for H2 tunnel details. 5) A TLH Identifier. As this TraceProbe solicits tunnel details, the TLH identifier is equal to zero. 6) A Tunnel Hop Identifier. The Tunnel Hop Identifier represents a tunnel hop about which the current TraceProbe is soliciting details. In this case, a value of 1 represents the first hop in a tunnel that might support H2. 7) An optional Access Control Object (ACO) D2 receives the TraceProbe, removes its IP and UDP headers, and delivers it to a local GTTP module. The GTTP module examines the TraceProbe ACO in order to determine whether local security policy permits it to process the probe. If security policy does not permit the GTTP module to service the probe, the D2 can either silently discard the TraceProbe or send D0 a TraceResponse, indicating insufficient privilege, as per local security policy. If security policy permits the GTTP module to process the probe, the GTTP module examines the TraceProbe and determines that it is soliciting details regarding the first hop of a particular downstream tunnel. (The GTTP module makes this determination based upon the Tunnel Hop Identifier value). Therefore, D2 queries its routing information and determines that an IP-in-IP tunnel supports H2. D2 then executes a tunnel specific tracing procedure. In this particular case, D2 encapsulates the TraceProbe in a UDP header. It then encapsulates the UDP packet in the IP header that is specified by the PIO. It sets the IP TTL value to 1 and recalculates the checksum. Finally, D2 encapsulates the IP header in another IP header. The outer IP header represents the IP-in-IP tunnel. Its source address represents the tunnel ingress and its destination address represents the tunnel egress. D2 copies the Tunnel Hop Identifier to the outer header TTL field and recalculates the outer checksum. Finally, D2 forwards the encapsulated TraceProbe. In our example, D2 forwards the TraceProbe through H2:1 to D5. D5 decrements the outer TTL value to 0 and forwards the datagram to an error-processing module. The error-processing module sends an ICMP Time Expired Message to D2. D2 discards this ICMP message. The error-processing module then forwards the TraceProbe to a local GTTP module. The GTTP module examines the TraceProbe ACO in order to determine whether local security policy permits it to process the probe. If security policy does not permit the GTTP module to service the probe, the GTTP module silently discards the TraceProbe. If security policy permits the GTTP module to process the probe, the GTTP module examines the TraceProbe and determines that it is soliciting details regarding a directly connected, upstream tunnel hop. Therefore, D5 sends D2 a TraceResponse. The TraceResponse contains the following information: 1) The IP address of the route-tracing application 2) A Sequence Number, used to match TraceProbes with TraceRespones 3) An IP address identifying the interface upon which the TraceProbe arrived. If the TraceProbe arrived on an unnumbered interface, this IP address will not uniquely identify the interface upon which the TraceProbe arrived 4) The MIB-II ifDescr value associated with the interface upon which the TraceProbe arrived. This value, in conjunction with the IP address mentioned above, SHOULD uniquely identify the interface upon which the datagram arrived. 5) A Tunnel Security Status (TSS). This value indicates whether local security policy permits GTTP to reveal tunnel details. 6) A Tunnel Identifier Object (TIO). The TIO contains several data items. One data item represents the type of the outermost tunnel (i.e., IP-in-IP). Another data item represents the entire tunnel header stack, as it encapsulated the TraceProbe when it arrived at the probed network element. Another data item represents a tunnel identifier that is shared between the tunnel ingress and tunnel egress nodes. (In this case, the identifier is a 64 bit value, with the first 32 bits representing the IP address of the tunnel ingress and the remaining 32 bits representing the IP address of the tunnel egress). 7) Egress Indicator. This field indicates whether the TraceResponse was sent by the tail-end of the traced tunnel. The GTTP module sets this Egress Indicator if the tail-end of the traced tunnel is a local interface. 8) An Optional Access Control Object (ACO). This object is copied from the TraceProbe. D2 receives the TraceResponse and relays it to the route-tracing application on D0. Having processed this TraceResponse, the route- tracing application has acquired H2:1 details. The route-tracing application sends another TraceProbe to D2 in order to solicit details regarding the second hop of the tunnel that supports H2. In return, it receives a TraceResponse that describes H2:2. Next, the route-tracing application sends another TraceProbe to D2 in order to solicit details regarding the third hop of the tunnel that supports H2. In response, it receives a TraceResponse that describes H2:3. This TraceResponse indicates that H2:3 is the final hop of the tunnel that supports H2. Finally, the route-tracing application sends a TraceProbe to D3 in order to determine whether any tunnel supports H3. In return, the application receives a TraceResponse that does not contain a TIO. This TraceResponse indicates that no tunnel supports H3. Local policy determines how many times D0 should probe each tunnel hop. It also determines how long D0 should wait for a response to each probe and the maximum number of probes that D0 should send in order to trace a given tunnel. In order to trace the the IP-in-IP tunnel accurately, D5 must be configured so that it sets TTL value specified the MPLS header that supports H2:2 to an appropriately high value. 4.5. Discovering Order N Tunnel Details Now D0 probes D2, D5 and D6 in order to determine whether any tunnel supports H2:1, H2:2 or H2:3. D0 repeats the procedure described above, this time augmenting the PIO with information obtained while discovering first layer tunnels. 5. Protocol Mechanisms 5.1. Transport GTTP rides directly over UDP. 5.2. Message Formats The following subsections detail GTTP Message Formats. 5.2.1. The TraceProbe Message 0 1 2 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| Type | Unused | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Application Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Head-end Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TLH ID | Tunnel Hop ID | Unused | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Optional Objects +-+-+-+-+-+-+-+-+-+-+-+-+-+- Figure 2: The TraceProbe Message Figure 2 depicts the TraceProbe Message. Applications send a TraceProbe in order to solicit details about a hop that is contained by a traced path. The following paragraphs describe each field that contributes to the TraceProbe Message. Version: 4 bits The Version field specifies the GTTP Message format. Value is equal to 1. Type: 4 bits The Type field specifies the GTTP message type. A value of 0 identifies a TraceProbe Message. Checksum: 16 bits The checksum is the 16-bit ones's complement of the one's complement sum of the GTTP message starting with the TraceProbe Version. For computing the checksum, the checksum field should be zero. Application Address: 32 bits The Application Address identifies the route-tracing application that originated the TraceProbe by IP address. Sequence Number: 16 bits Route-tracing applications use the Sequence Number to match TraceProbes with TraceResponses. Length: 16 bits The Length field specifies the length of the TraceProbe Message, beginning with the TraceProbe Version, in octets. Head-end Address: 32 bits The Head-end Address identifies the head-end of the traced path or tunnel. Top Level Hop (TLH) ID: 8 bits The Top Level Hop (TLD) ID identifies the TLH about which the TraceProbe is soliciting details. For example, when soliciting details regarding the first TLH that contributes to a path, the TLH ID should be equal to 1. Tunnel Hop ID: 8 bits The Tunnel Hop ID identifies the tunnel hop about which the TraceProbe is soliciting details. For example, when soliciting details regarding the first tunnel hop that contributes to a tunnel, the Tunnel Hop ID should be equal to 1. Optional Objects: Variable Length The ACO, PIO, and Padding Objects may be specified in the TraceProbe Message. The PIO is mandatory. Each optional object must begin on a 32 bit boundary. See the following subsections for optional object details. All Unused bits must be set to 0. 5.2.2. The TraceResponse Message 0 1 2 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| Type | Flags | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Application Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Arrival Interface Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code | ifDesc Length | Unused | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ifDescr | | // | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Optional Objects +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: The TraceResponse Message Figure 3 depicts the TraceResponse Message. Network elements send the TraceResponse Message in order to reveal details concerning a TLH or tunnel hop. The following paragraphs describe each field that contributes to the TraceResponse Message. Version: 4 bits The Version field specifies the GTTP Message format. Value is equal to 1. Type: 4 bits The Type field specifies the GTTP message type. A value of 1 identifies a TraceResponse Message. Flags: 8 bits The leftmost bit of the Flags field represents the Egress Indicator. The Egress Indicator bit is set if the path or tunnel egress device originated the TraceResponse. The second bit represents the Tunnel Security Status (TSS). The TSS bit is set if local security policy permits GTTP to reveal whether a tunnel supports the hop upon which the current TraceResponse reports. All unused bits MUST be cleared (i.e., set to zero). Checksum: 16 bits The checksum is the 16-bit ones's complement of the one's complement sum of the GTTP message starting with the TraceProbe Version. For computing the checksum, the checksum field should be zero. Application Address: 32 bits The Application Address identifies the route-tracing application that originated the corresponding TraceProbe by IP address. Sequence Number: 16 bits Route-traccing applications use the Sequence Number to match TraceProbes with TraceResponses. Length: 16 bits The Length field specifies the length of the TraceResponse Message, beginning with the TraceResponse Version, in octets. Arrival Interface Address: 32 bits The Arrival Interface Address identifies the interface upon which the corresponding TraceProbe arrived. If the corresponding TraceProbe arrived on an unnumbered interface, the Arrival Interface Address may not uniquely indentify the interface upon which the corresponding TraceProbe arrived. Code: 8 bits The Code represents an error code. The following values are defined: 0 No Error 1 Insufficient Privilege 2 Malformed TraceProbe 3 No such tunnel 4 No route to destination 5 Communication administratively prohibited 6 Ambiguous PIO ifDescr Length: 8 bits The ifDescr Length specifies the number of significant bytes in the field. ifDescr: variable Length The ifDescr field identifies the interface upon which the corresponding TraceProbe arrived, by name. This value is taken from the MIB-II ifDesc object. This value, in conjunction with the Arrival Interface Address, uniquely identifies the interface upon which the corresponding TraceProbe arrived. The ifDescr field is zero padded for word alignment. Optional Objects: Variable Length The ACO and TIO objects may be specified in the TraceResponse Message. Each optional object must begin on a 32 bit boundary. See the following subsections for optional object details. 5.2.3. The Access Control Object 0 1 2 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 | Length | AuType | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Authentication | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Authentication | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: The Access Control Object Figure 4 depicts the Access Control Object. GTTP entities use the access control object to enforce access control policy. The following paragraphs describe each field that contributes to the access control object. Type: 8 bits The Type field specifies the type of the object that follows. For the Access Control Object, the Type field is always equal to 1. Length : 8 bits The Length Field specifies the length of the object that follows, in octets. For the Access Control Object, the value of the Length field is always equal to 12. AuType: 8 bits The AuType specifies the type of authentication used for this message. Encoding rules follow: 1 = Plaintext password 2 = Cryptographic Authentication Authentication: 64 bits The Authentication field contains authentication data. See Appendix D of [RFC 2328] for a description of this field. 5.2.4. The Path Identifier Object (PIO) 0 1 2 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 | Length | ifDesc Length | Tun Hdr Len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IP Hdr Len | Tunnel Type | Unused | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tunnel Ingress Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tunnel Egress Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ifDescr | | // | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tunnel Stack Header | | // | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IP Header | | // | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5: Path Identifier Object Figure 5 depicts the Path Identifier Object (PIO). TraceProbe Messages use the PIO in order to identify a traced path. The following paragraphs describe each field that contributes to the PIO. Type: 8 bits The Type field specifies the type of the object that follows. For the PIO, the Type field is always equal to 2. Length : 8 bits The Length field specifies the object length, in octets. ifDescr Length: 8 bits The ifDescr Length field specifies the number of significant octets contained by the ifDescr field. Tunnel Header Length: 8 bits The Tunnel Header Length field specifies the number of significant octets contained by the Tunnel Header field. IP Header Length: 8 bits The IP Header Length field represents an IP header that might encapsulate a datagram. Tunnel Type: 8 bits The Tunnel Type field identifies the type of the outermost tunnel specified in the Tunnel Header. The following values are defined: 0 Undefined 1 GRE 2 MPLS 3 IPSEC 4 IP Optical (IPO) 5 Layer 2 Tunneling Protocol (L2TP) 6 IP-in-IP 7 UTI Tunnel Ingress Address: 32 bits When soliciting tunnel details, the Tunnel Ingress address identifies any interface that is local the the tunnel ingress node. When soliciting TLH details, the Tunnel Ingress Address is meaningless. Tunnel Egress Address: 32 bits When soliciting tunnel details, the Tunnel Egress address identifies any interface that is local the the tunnel egress node. When soliciting TLH details, the Tunnel Egress Address is meaningless. ifDescr : variable length The ifDescr Field identifies the interface or sub-interface upon which a datagram might arrive, by MIB-II ifDescr. The ifDescr field can be zero padded for word alignment. This field can be empty if the incoming interface does not contribute to the routing decision. Tunnel Header : variable length The Tunnel Header Field identifies a tunnel header that might encapsulate an incoming datagram. The Tunnel Header field can be zero padded for word alignment. This field can be empty if the incoming tunnel header does not contribute to the routing decision. IP Header : variable length The IP Header Field identifies a traced path. The Tunnel Type field can be zero padded for word alignment. The IP Header field can be zero padded for word alignment. This field must be specified. 5.2.5. The Tunnel Identification Object (TIO) 0 1 2 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 | Length | Tunnel Type | Tunnel ID Len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tun Hdr Len | Unused | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tunnel Ingress Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tunnel Egress Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tunnel ID | | // | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tunnel Header Stack | | // | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6: The Tunnel Identification Object Figure 6 depicts the Tunnel Identification Object (TIO). The TIO object describes a tunnel upon which the probed network element received a TraceProbe. The following paragraphs describe each field that contributes to the TIO. Type: 8 bits The Type field specifies the type of the object that follows. For TIO, the Type field is always equal to 3. Length : 8 bits The Length Field specifies the length of the object that follows, in octets. Tunnel Type: 8 bits The Tunnel Type field identifies a tunnel type. The following values are defined: 0 Undefined 1 GRE 2 MPLS 3 IPSEC 4 IP Optical (IPO) 5 Layer 2 Tunneling Protocol (L2TP) 6 IP-in-IP 7 UTI Tunnel ID Length: 8 bits The Tunnel ID Length field specifies the number of significant bits in the Tunnel ID field. Tun Hdr Len: 8 bits This field represents the number of significant octets in the Tunnel Header Stack. Tunnel Ingress Address: 32 bits The Tunnel Ingress Address identifies the tunnel ingress, by IP address. The route-tracing application can send a TraceProbe Message to this address in order to obtain tunnel details. If the tail-end device cannot provide this information, it specifies the address 0.0.0.0. Tunnel Egress Address: 32 bits The Tunnel Egress address identifies the tunnel egress, by IP address. If the tail-end device cannot provide this information, it specifies the address 0.0.0.0. Tunnel ID: variable length The Tunnel ID field identifies the tunnel to its ingress device. The format of this field is determined by tunnel specific tracing procedures (defined below). This field is empty when the tunneling mechanism does not support such an identifier. Tunnel Header Stack: variable length This field represents the entire tunnel header stack, as it encapsulated the TraceProbe when it arrived at the probed node. 5.2.6. The Padding Object 0 1 2 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 | Length | Unused | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-. . . . . Figure 7: The Padding Object Figure 7 depicts the Padding Object. Route-tracing applications use the Padding object to extend a TraceProbe to the desired size. The following paragraphs describe each field that contributes to the Padding Object. Type: 8 bits The Type field specifies the type of the object that follows. For the Padding Object, the Type field is always equal to 4. Length : 8 bits The Length Field specifies the length of the object that follows, in octets. The length of the Padding Object must be a multiple of four. Unused: variable length Unused bits must be set to zero. 5.3. Message Processing 5.3.1. The TraceProbe Message Having received a TraceProbe Message, the GTTP module must examine TraceProbe's ACO in order to determine whether local security policy permits it to process the probe. If security policy does not permit the GTTP module to service the probe, the GTTP module can either silently discard the TraceProbe or send route-tracing application a TraceResponse, indicating insufficient privilege, as per local security policy. If local security policy permits the GTTP module to process the probe, the GTTP module must determine which of the following is true: 1) The TraceProbe is soliciting details concerning a downstream TLH. This condition is true if the TLH Identifier is greater than zero and the head-end of the traced path is a local interface and the tail-end of the traced path is not a local interface. 2) The TraceProbe is soliciting details concerning a directly connected upstream TLH. This condition is true if the TLH Identifier is greater than zero and the head-end of the traced path is a not local interface. 3) The TraceProbe is soliciting details concerning a tunnel for which the local node serves as igress. This condition is true if the Tunnel Hop Identifier is greater than zero and the head-end of the traced tunnel is a local interface. 4) The TraceProbe is soliciting details concerning a directly connected upstream tunnel hop. This condition is true if the Tunnel Hop Identifier is greater than zero and the head-end of the traced tunnel is not a local interface. If the first condition is true, the GTTP module relays the TraceProbe downstream. First, if required by PIO specifications, the GTTP module pads the TraceProbe Message. Next, the GTTP module encapsulates the TraceProbe Message in a UDP header. The GTTP module then encapsulates the UDP packet in an IP header. The IP header contains all of the information specified by the original TraceProbe's PIO. The GTTP module then copies the original TraceProbe's TLH Identifier to the IP header TTL field and recalculates the IP header checksum. The GTTP module then forwards the TraceProbe downstream as per all PIO specifications. If the second condition is true, the GTTP module formats a TraceResponse and sends it to the route-tracing application. If the third condition is true, GTTP executes a tunnel specific tracing procedure. The tunnel specific tracing procedure elicits a TraceResponse message that describes a hop of the traced tunnel. Tunnel specific tracing procedures are described in a later paragraph. If the fourth condition is true, the GTTP module formats a TraceResponse and sends it to the head-end of the traced tunnel. 5.3.2. The TraceResponse Message Having received a TraceResponse Message, the GTTP module examines the TraceResponse ACO in order to determine whether local security policy permits it to process the probe. If security policy does not permit the GTTP module to service the probe, the the GTTP module silently discards the TraceResponse. If security policy permits the GTTP module to process the response, the GTTP module relays the TraceResponse to the route-tracing application. 5.4. Tunnel Specific Tracing Proceedures The following subsections detail tunnel specific tracing procedures. 5.4.1. TTL Aware Tunnels The GTTP module encapsulates the TraceProbe in a UDP header. It then encapsulates the UDP packet in the IP header that is specified by the PIO. It sets the IP TTL value to 1 and recalculates the checksum. Finally, the GTTP module encapsulates the IP header in tunnel header (e.g., MPLS shim header). Finally, the GTTP module copies the Tunnel Hop Identifier to the tunnel header TTL field and recalculates the tunnel checksum (if required). Finally, the GTTP module forwards the encapsulated TraceProbe. 5.4.2. Other Tunnel Types TBD 6. IANA Guidelines IANA will assign a UDP port to GTTP [RFC-2434]. 7. Security Considerations The following are security considerations: 1) GTTP MUST enforce access control policy before disclosing any information. 2) GTTP MUST NOT yield multiple TraceResponses in response to a single TraceProbe. 3) When tracing through encrypted tunnels, GTTP must never deliver the cipher-text equivalent of user provided data. 4) GTTP entities should rate limit messages that they send and receive. 5) When the device at the head-end of a traced path generates a TraceProbe, it MUST identify a local address in that messages IP Source Address field. 8. References [RFC-2026], Bradner, S., "Internet Standards Process Revision 3", RFC 2026, Harvard University, October 1996. [RFC-2119], Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, Harvard University, March 1997 [RFC-2151], Kessler, G., Shepard, S., A Primer On Internet and TCP/IP Tools and Utilities, RFC 2151, Hill Associates, Inc., June 1997 [RFC-2328], Moy, J., OSPF Version 2, April, 1998. [RFC-2434] T. Narten and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", RFC 2434, October, 1998. [RFC-2637] Hamzeh, K. et. al., "Point-to-Point Tunneling Protocol (PPTP)", RFC 2637, July, 1999. [TUNREQ] Bonica, R., Kompella, K., Meyer, D., Tracing Requirements for Generic Tunnels, draft-bonica-tunneltrace-02.txt, July 2002. 9. Acknowledgements Thanks to Randy Bush, Philip Matthews, Tricci So and Beth Alwin for their comments. 10. Author's Addresses Ronald P. Bonica WorldCom 22001 Loudoun County Pkwy Ashburn, Virginia, 20147 Phone: 703 886 1681 Email: ronald.p.bonica@wcom.com Eric C. Rosen Cisco Systems, Inc. 250 Apollo Drive Chelmsford, Massachusetts, 01824 E-mail: erosen@cisco.com Kireeti Kompella Juniper Networks, Inc. 1194 N. Mathilda Ave. Sunnyvale, California 94089 Email: kireeti@juniper.net Dave Myers Sprint E|Solutions 12502 Sunrise Valley Drive Reston, Virginia 20191 Email: dmm@sprint.net Rohit Dube Xebeo Communications Inc. 1 Cragwood Road, Suite 100 South Plainfield, NJ 07080 Email: rohit@xebeo.com 11. Full Copyright Statement Copyright (C) The Internet Society (2001). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.