Internet N. Shen Internet-Draft C. Pignataro Intended status: Standards Track R. Asati Expires: December 6, 2008 E. Chen Cisco Systems, Inc. June 4, 2008 UDP Traceroute Message Extension draft-shen-udp-traceroute-ext-01 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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. This Internet-Draft will expire on December 6, 2008. Abstract This document specifies an extension to UDP traceroute messages that allows the UDP traceroute probe packets to be authenticated by the intermediate nodes and the destination node. This extension can also include requests for node specific information that the sender is interested to receive from one or more nodes via the traceroute replies. Shen, et al. Expires December 6, 2008 [Page 1] Internet-Draft UDP Traceroute Extension June 2008 Table of Contents 1. Specification of Requirements . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. UDP Traceroute Message Extension . . . . . . . . . . . . . . . 4 3.1. Original Length Field . . . . . . . . . . . . . . . . . . 4 3.2. UDP Traceroute Structure . . . . . . . . . . . . . . . . . 4 3.2.1. Traceroute Common Header . . . . . . . . . . . . . . . 4 3.2.2. Traceroute TLV . . . . . . . . . . . . . . . . . . . . 5 3.2.2.1. Traceroute Authentication TLV . . . . . . . . . . 6 3.2.2.2. Traceroute Information-Request TLV . . . . . . . . 7 4. Implementation and Operation Considerations . . . . . . . . . 8 4.1. Traceroute Probe Sender . . . . . . . . . . . . . . . . . 8 4.2. Traceroute Probe Receiver . . . . . . . . . . . . . . . . 8 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 8. Normative References . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 Intellectual Property and Copyright Statements . . . . . . . . . . 12 Shen, et al. Expires December 6, 2008 [Page 2] Internet-Draft UDP Traceroute Extension June 2008 1. Specification of Requirements 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 [RFC2119]. 2. Introduction Traceroute is a tool widely used in the diagnosis of network problems. Majority of the traceroute tools are implemented by sending out UDP [RFC0768] probe messages and receiving ICMP messages. Internet Control Message Protocol (ICMP/ICMPv6) [RFC0792] [RFC4443] has been extended to support multi-part message inside ICMP [RFC4884]. Some of the applications [I-D.atlas-icmp-unnumbered] [RFC4950] [I-D.shen-icmp-routing-inst] are designed mainly for internal network troubleshooting by network operators. Network providers may want to limit those applications only to trusted senders of traceroute probes due to security or policy reasons. Although one may employ a rudimentary control mechanism to limit the trusted senders by defining access control lists specifying IPv4/IPv6 source addresses of the UDP traceroute message, such mechanism is deemed configuration intensive, static, and error-prone. Moreover, such mechanism would be susceptible to address spoofing. Additionally, such mechanism does not provide the sender with dynamic control of the different kind of extensions to be requested. This document defines an extension for UDP traceroute messages to optionally include authentication signature. The intermediate and destination nodes can authenticate the sender of the traceroute packet before providing the requested information in the traceroute response. This document also includes an Information-Request TLV for the traceroute extension. This TLV specifies the types of information the sender expects to be included in the traceroute response (i.e., in the ICMP message elicited by the UDP packet and generated by the intermediate or destination node or nodes). This extension is backwards compatible with the existing Internet traceroute mechanism, and it is applied to both IPv4 and IPv6 networks. This extension is applicable to only the UDP type of traceroute probe, similar scheme might be used with other types of traceroute probe and it is outside the scope of this document. Shen, et al. Expires December 6, 2008 [Page 3] Internet-Draft UDP Traceroute Extension June 2008 3. UDP Traceroute Message Extension This proposed extension is to reserve the lowest 4 bits in the UDP source port field, and a traceroute structure within UDP data field. 3.1. Original Length Field This "original length" field is defined as the lowest nibble of the UDP source port field, and specifies the position at which the traceroute data structure begins. The value represents 32-bit words ranges from 0x0 to 0xF, with value 0xF as reserved. Thus the position of the traceroute data structure can start from 0 to 56 octets inside UDP data field. The "original length" field value 0xF indicates there is no traceroute data structure inside the UDP data field. The "original length" field is defined within UDP "source port" as the following: 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |Ori-Len| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Ori-Len: 4 bits. The value (Ori-Len) represents the traceroute data structure start position in 32-bit words. The Ori-Len value 0xF is reserved. 3.2. UDP Traceroute Structure The UDP traceroute structure starts in UDP data field location from 0 to 56 octets specified in the "original length" in 32-bit boundary. It MUST have exactly one traceroute common header followed by one or more UDP traceroute TLVs. 3.2.1. Traceroute Common Header The Common Header is a 8 octets structure has the following format: Shen, et al. Expires December 6, 2008 [Page 4] Internet-Draft UDP Traceroute Extension June 2008 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| Length | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Magic-Number (0x54726163) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The fields of the Common Header are defined as follows: Version: 4 bits. It is defined as 1 in this document. Length: 12 bits. The total length of the traceroute data structure specifying number of 32-bit words (includes the common header and all the TLVs). Checksum: 16 bits. The one's complement of the one's complement sum of the traceroute data structure, with the checksum field replaced by zero for the purpose of computing the checksum. Magic Number: 32 bits. It is defined as Hex value of 0x54726163 in this document. This is used mainly for structure identification of this extension version. 3.2.2. Traceroute TLV Traceroute TLVs (Type-Length-Value tuples) have the following format: 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value | . . . . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: 16 bits. Length: 16 bits. length of the Value field in octets. Shen, et al. Expires December 6, 2008 [Page 5] Internet-Draft UDP Traceroute Extension June 2008 Value: depends on the Type. It is zero padded to align to a 4-octet boundary. This document defines two TLVs below. 3.2.2.1. Traceroute Authentication TLV This TLV carries the HMAC authentication related information. It verifies both the data integrity and the authenticity of the entire message. This TLV has the following format: 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 = 1 (Authentication) | Length (variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Auth Type | Key ID | Auth Data Len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Auth Data (Variable) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Auth Type: 16 bits. The following values are proposed: * Type=0 signifies no authentiction * Type=1 signifies simple password based authentication. * Type=2 signifies Cryptographic authentication. Please note that the above type values are in line with IANA allocated values for other protocols (e.g., OSPF). Key ID: 8 bits. This allows multiple secret keys to be active simultaneously. Using Key IDs makes the key rollover convenient. Each secret key must be associated with the hash algorithm. This may be done through provisioning on each node. Auth Data Len: 8 bits. This specifies the length of the authentication data (and allows for the support of current and future authentication schemes). Shen, et al. Expires December 6, 2008 [Page 6] Internet-Draft UDP Traceroute Extension June 2008 Auth Data: Variable length. This field carries the result (e.g., HMAC code) of the HMAC alogorithm applied over the entire traceroute IP/IPv6 packet. When the Auth data is calculated, the shared key is stored in this field, and the checksum fields in the IP header, UDP header and traceroute common header are set to zero. The result of the algorithm is placed in the Auth Key field. The following lists algorithms that could be commonly supported: * HMAC-MD5 * HMAC-SHA1 * HMAC-SHA2 variants (e.g., 224, 256, 384, 512, etc.) At least HMAC-MD5 and HMAC-SHA1 algorithms should be supported on all the nodes compliant with this specification. 3.2.2.2. Traceroute Information-Request TLV The Information-Request TLV has the following format: 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 = 2 (Info-Req) | Length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Info Request | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Info-Req: 32 bits. This bitflag field lists the request items the traceroute sender is interested. The bit number ranges from the right most bit to the left most bit. Currently defined as the following: Shen, et al. Expires December 6, 2008 [Page 7] Internet-Draft UDP Traceroute Extension June 2008 Bit Number Information Item 0 MPLS label related attributes 1 Interface related attributes 2 IP/IPv6 address related attributes 3 Routing Instance related attributes 4. Implementation and Operation Considerations There is no change in this extension for the normal traceroute implementation and operation except for reserving the lowest 4 bits in the UDP source port field. The implementations for the sender can use the same semantics with the UDP source port; and it makes no difference to the receivers if they don't support this extension. 4.1. Traceroute Probe Sender The sender supports this extension MAY include the Traceroute structure in it's UDP probe to specify the request types and authentication key. The sender SHOULD set the "original length" value to 0xF if there is no Traceroute structure present inside the UDP probe. The sender MAY request one or multiple types of information defined in the traceroute "Info-Req" TLV. 4.2. Traceroute Probe Receiver When the traceroute probe receiver, the intermediate and destination node, processes the UDP probe, it MAY check the UDP Traceroute structure to verify if the sender is from an authenticated host and to see what types of information it requested. This check is only needed when the receiver tries to authenticate the UDP probe sender, or when the receiver is formating the ICMP and ICMPv6s that support multi-part messages and it has certain internal information that can be included in the ICMP packets. If the "original length" value is not 0xF, UDP traceroute structure may be present. The receiver MUST verify the integrity of the data structure by examining the "version" field, the Magic-Number value, and the length of the structure. It MUST perform the checksum to verify the data structure. If the authentication TLV is present and the local policy requires it to perform the verification, the receiver MUST use it's locally stored shared key to validate the checksum in the TLV. Multiple Authentication Keys can be used which can be useful in the case the UDP probes are from trusted peer networks. If the "Info-Req" TLV is included, the receiver SHOULD fetch the related information when formating the ICMP packets, but MUST NOT Shen, et al. Expires December 6, 2008 [Page 8] Internet-Draft UDP Traceroute Extension June 2008 inlcude information that has the corresponding bitflag cleared. 5. Security Considerations This extension enhances the security of traceroute operation in a backwards-compatible fashion. The mechanism allows the receiver to verify the sender of the UDP traceroute packet such that certain sensitive interface and network related information can be supplied in the internal network or across trusted networks. The use of Cryptographic authentication (i.e., an Auth Type value of 2) allows for a strong authentication mechanism since the keys cannot be discerned by intercepting the packets. The proposed Keyed authentication does not prevent replay attacks. However, in the case of replay attacks, since the packet source IP/IPv6 address of the traceroute probe can not be changed, there is no easy way for the attacker to retrieve the ICMP messages. A router needs to protect against purposefully-bogus UDP Traceroute packets with extensions that fail the authentication, as a high rate of messages can require significant processing time. [RFC1812] specifies how rate-limiting is applied to the generation of ICMP messages, and this rate-limiting deterrs the threat when applied before checking the Authentication. Additionally, when using Cryptographic authentication, the HMAC includes the source IP address, which means the HMAC will not validate if the UDP packet is sent over a NAT. 6. IANA Considerations The UDP Traceroute Extension contains traceroute TLVs. IANA should establish a registry of UDP Traceroute Extension Types. This document defines Type 1 and Type 2 for authentication and information-request. Types 3-0xF6 are allocated through Expert Review [RFC5226]. Types 0xF7 to 0xFF are reserved for private use. IANA should also establish a registry for UDP Traceroute Info-Request Bits. This document defines bits 0 - 3 in section 3.2.2.2. Bits 4-29 are allocated through Expert Review. Bits 30 - 31 are reserved for private use. 7. Acknowledgements Many thanks to Dan Wing, for his insighful comments and valuable suggestions regarding this document. Shen, et al. Expires December 6, 2008 [Page 9] Internet-Draft UDP Traceroute Extension June 2008 8. Normative References [I-D.atlas-icmp-unnumbered] Atlas, A., Bonica, R., Systems, N., Shen, N., and E. Chen, "Extending ICMP to Identify the Receiving Interface", draft-atlas-icmp-unnumbered-04 (work in progress), November 2007. [I-D.shen-icmp-routing-inst] Shen, N. and E. Chen, "ICMP Extensions for Routing Instances", draft-shen-icmp-routing-inst-00 (work in progress), November 2006. [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980. [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981. [RFC1812] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, June 1995. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 4443, March 2006. [RFC4884] Bonica, R., Gan, D., Tappan, D., and C. Pignataro, "Extended ICMP to Support Multi-Part Messages", RFC 4884, April 2007. [RFC4950] Bonica, R., Gan, D., Tappan, D., and C. Pignataro, "ICMP Extensions for Multiprotocol Label Switching", RFC 4950, August 2007. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. Shen, et al. Expires December 6, 2008 [Page 10] Internet-Draft UDP Traceroute Extension June 2008 Authors' Addresses Naiming Shen Cisco Systems, Inc. 225 West Tasman Drive San Jose, CA 95134 USA Email: naiming@cisco.com Carlos Pignataro Cisco Systems, Inc. 7200 Kit Creek Road Research Triangle Park, NC 27709 USA Email: cpignata@cisco.com Rajiv Asati Cisco Systems, Inc. 7025 Kit Creek Road Research Triangle Park, NC 27709 USA Email: rajiva@cisco.com Enke Chen Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 USA Email: enkechen@cisco.com Shen, et al. Expires December 6, 2008 [Page 11] Internet-Draft UDP Traceroute Extension June 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Shen, et al. Expires December 6, 2008 [Page 12]