idnits 2.17.1 draft-shen-udp-traceroute-ext-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 470. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 481. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 488. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 494. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 4, 2008) is 5804 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-09) exists of draft-atlas-icmp-unnumbered-04 -- Possible downref: Normative reference to a draft: ref. 'I-D.shen-icmp-routing-inst' ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet N. Shen 3 Internet-Draft C. Pignataro 4 Intended status: Standards Track R. Asati 5 Expires: December 6, 2008 E. Chen 6 Cisco Systems, Inc. 7 June 4, 2008 9 UDP Traceroute Message Extension 10 draft-shen-udp-traceroute-ext-01 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on December 6, 2008. 37 Abstract 39 This document specifies an extension to UDP traceroute messages that 40 allows the UDP traceroute probe packets to be authenticated by the 41 intermediate nodes and the destination node. This extension can also 42 include requests for node specific information that the sender is 43 interested to receive from one or more nodes via the traceroute 44 replies. 46 Table of Contents 48 1. Specification of Requirements . . . . . . . . . . . . . . . . 3 50 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 3. UDP Traceroute Message Extension . . . . . . . . . . . . . . . 4 53 3.1. Original Length Field . . . . . . . . . . . . . . . . . . 4 54 3.2. UDP Traceroute Structure . . . . . . . . . . . . . . . . . 4 55 3.2.1. Traceroute Common Header . . . . . . . . . . . . . . . 4 56 3.2.2. Traceroute TLV . . . . . . . . . . . . . . . . . . . . 5 57 3.2.2.1. Traceroute Authentication TLV . . . . . . . . . . 6 58 3.2.2.2. Traceroute Information-Request TLV . . . . . . . . 7 60 4. Implementation and Operation Considerations . . . . . . . . . 8 61 4.1. Traceroute Probe Sender . . . . . . . . . . . . . . . . . 8 62 4.2. Traceroute Probe Receiver . . . . . . . . . . . . . . . . 8 64 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 66 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 68 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 70 8. Normative References . . . . . . . . . . . . . . . . . . . . . 10 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 73 Intellectual Property and Copyright Statements . . . . . . . . . . 12 75 1. Specification of Requirements 77 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 78 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 79 document are to be interpreted as described in [RFC2119]. 81 2. Introduction 83 Traceroute is a tool widely used in the diagnosis of network 84 problems. Majority of the traceroute tools are implemented by 85 sending out UDP [RFC0768] probe messages and receiving ICMP messages. 87 Internet Control Message Protocol (ICMP/ICMPv6) [RFC0792] [RFC4443] 88 has been extended to support multi-part message inside ICMP 89 [RFC4884]. Some of the applications [I-D.atlas-icmp-unnumbered] 90 [RFC4950] [I-D.shen-icmp-routing-inst] are designed mainly for 91 internal network troubleshooting by network operators. Network 92 providers may want to limit those applications only to trusted 93 senders of traceroute probes due to security or policy reasons. 95 Although one may employ a rudimentary control mechanism to limit the 96 trusted senders by defining access control lists specifying IPv4/IPv6 97 source addresses of the UDP traceroute message, such mechanism is 98 deemed configuration intensive, static, and error-prone. Moreover, 99 such mechanism would be susceptible to address spoofing. 100 Additionally, such mechanism does not provide the sender with dynamic 101 control of the different kind of extensions to be requested. 103 This document defines an extension for UDP traceroute messages to 104 optionally include authentication signature. The intermediate and 105 destination nodes can authenticate the sender of the traceroute 106 packet before providing the requested information in the traceroute 107 response. 109 This document also includes an Information-Request TLV for the 110 traceroute extension. This TLV specifies the types of information 111 the sender expects to be included in the traceroute response (i.e., 112 in the ICMP message elicited by the UDP packet and generated by the 113 intermediate or destination node or nodes). 115 This extension is backwards compatible with the existing Internet 116 traceroute mechanism, and it is applied to both IPv4 and IPv6 117 networks. 119 This extension is applicable to only the UDP type of traceroute 120 probe, similar scheme might be used with other types of traceroute 121 probe and it is outside the scope of this document. 123 3. UDP Traceroute Message Extension 125 This proposed extension is to reserve the lowest 4 bits in the UDP 126 source port field, and a traceroute structure within UDP data field. 128 3.1. Original Length Field 130 This "original length" field is defined as the lowest nibble of the 131 UDP source port field, and specifies the position at which the 132 traceroute data structure begins. The value represents 32-bit words 133 ranges from 0x0 to 0xF, with value 0xF as reserved. Thus the 134 position of the traceroute data structure can start from 0 to 56 135 octets inside UDP data field. The "original length" field value 0xF 136 indicates there is no traceroute data structure inside the UDP data 137 field. 139 The "original length" field is defined within UDP "source port" as 140 the following: 142 0 1 143 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 145 | |Ori-Len| 146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 148 Ori-Len: 4 bits. The value (Ori-Len) represents the traceroute data 149 structure start position in 32-bit words. The Ori-Len value 150 0xF is reserved. 152 3.2. UDP Traceroute Structure 154 The UDP traceroute structure starts in UDP data field location from 0 155 to 56 octets specified in the "original length" in 32-bit boundary. 156 It MUST have exactly one traceroute common header followed by one or 157 more UDP traceroute TLVs. 159 3.2.1. Traceroute Common Header 161 The Common Header is a 8 octets structure has the following format: 163 0 1 2 3 164 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 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 166 |Version| Length | Checksum | 167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 168 | Magic-Number (0x54726163) | 169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 171 The fields of the Common Header are defined as follows: 173 Version: 4 bits. It is defined as 1 in this document. 175 Length: 12 bits. The total length of the traceroute data structure 176 specifying number of 32-bit words (includes the common 177 header and all the TLVs). 179 Checksum: 16 bits. The one's complement of the one's complement sum 180 of the traceroute data structure, with the checksum field 181 replaced by zero for the purpose of computing the checksum. 183 Magic Number: 32 bits. It is defined as Hex value of 0x54726163 in 184 this document. This is used mainly for structure 185 identification of this extension version. 187 3.2.2. Traceroute TLV 189 Traceroute TLVs (Type-Length-Value tuples) have the following format: 191 0 1 2 3 192 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 193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 194 | Type | Length | 195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 196 | Value | 197 . . 198 . . 199 . . 200 | | 201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 203 Type: 16 bits. 205 Length: 16 bits. length of the Value field in octets. 207 Value: depends on the Type. It is zero padded to align to a 208 4-octet boundary. 210 This document defines two TLVs below. 212 3.2.2.1. Traceroute Authentication TLV 214 This TLV carries the HMAC authentication related information. It 215 verifies both the data integrity and the authenticity of the entire 216 message. This TLV has the following format: 218 0 1 2 3 219 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 220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 221 | Type = 1 (Authentication) | Length (variable) | 222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 223 | Auth Type | Key ID | Auth Data Len | 224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 225 | | 226 | Auth Data (Variable) | 227 | | 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 Auth Type: 16 bits. The following values are proposed: 232 * Type=0 signifies no authentiction 234 * Type=1 signifies simple password based 235 authentication. 237 * Type=2 signifies Cryptographic authentication. 239 Please note that the above type values are in line with IANA 240 allocated values for other protocols (e.g., OSPF). 242 Key ID: 8 bits. This allows multiple secret keys to be active 243 simultaneously. Using Key IDs makes the key rollover 244 convenient. Each secret key must be associated with the 245 hash algorithm. This may be done through provisioning on 246 each node. 248 Auth Data Len: 8 bits. This specifies the length of the 249 authentication data (and allows for the support of current 250 and future authentication schemes). 252 Auth Data: Variable length. This field carries the result (e.g., 253 HMAC code) of the HMAC alogorithm applied over the entire 254 traceroute IP/IPv6 packet. When the Auth data is 255 calculated, the shared key is stored in this field, and the 256 checksum fields in the IP header, UDP header and traceroute 257 common header are set to zero. The result of the algorithm 258 is placed in the Auth Key field. The following lists 259 algorithms that could be commonly supported: 261 * HMAC-MD5 263 * HMAC-SHA1 265 * HMAC-SHA2 variants (e.g., 224, 256, 384, 512, etc.) 267 At least HMAC-MD5 and HMAC-SHA1 algorithms should be 268 supported on all the nodes compliant with this 269 specification. 271 3.2.2.2. Traceroute Information-Request TLV 273 The Information-Request TLV has the following format: 275 0 1 2 3 276 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 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 | Type = 2 (Info-Req) | Length = 4 | 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 280 | Info Request | 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 283 Info-Req: 32 bits. This bitflag field lists the request items the 284 traceroute sender is interested. The bit number ranges from 285 the right most bit to the left most bit. Currently defined 286 as the following: 288 Bit Number Information Item 289 0 MPLS label related attributes 290 1 Interface related attributes 291 2 IP/IPv6 address related attributes 292 3 Routing Instance related attributes 294 4. Implementation and Operation Considerations 296 There is no change in this extension for the normal traceroute 297 implementation and operation except for reserving the lowest 4 bits 298 in the UDP source port field. The implementations for the sender can 299 use the same semantics with the UDP source port; and it makes no 300 difference to the receivers if they don't support this extension. 302 4.1. Traceroute Probe Sender 304 The sender supports this extension MAY include the Traceroute 305 structure in it's UDP probe to specify the request types and 306 authentication key. The sender SHOULD set the "original length" 307 value to 0xF if there is no Traceroute structure present inside the 308 UDP probe. The sender MAY request one or multiple types of 309 information defined in the traceroute "Info-Req" TLV. 311 4.2. Traceroute Probe Receiver 313 When the traceroute probe receiver, the intermediate and destination 314 node, processes the UDP probe, it MAY check the UDP Traceroute 315 structure to verify if the sender is from an authenticated host and 316 to see what types of information it requested. This check is only 317 needed when the receiver tries to authenticate the UDP probe sender, 318 or when the receiver is formating the ICMP and ICMPv6s that support 319 multi-part messages and it has certain internal information that can 320 be included in the ICMP packets. 322 If the "original length" value is not 0xF, UDP traceroute structure 323 may be present. The receiver MUST verify the integrity of the data 324 structure by examining the "version" field, the Magic-Number value, 325 and the length of the structure. It MUST perform the checksum to 326 verify the data structure. If the authentication TLV is present and 327 the local policy requires it to perform the verification, the 328 receiver MUST use it's locally stored shared key to validate the 329 checksum in the TLV. Multiple Authentication Keys can be used which 330 can be useful in the case the UDP probes are from trusted peer 331 networks. 333 If the "Info-Req" TLV is included, the receiver SHOULD fetch the 334 related information when formating the ICMP packets, but MUST NOT 335 inlcude information that has the corresponding bitflag cleared. 337 5. Security Considerations 339 This extension enhances the security of traceroute operation in a 340 backwards-compatible fashion. The mechanism allows the receiver to 341 verify the sender of the UDP traceroute packet such that certain 342 sensitive interface and network related information can be supplied 343 in the internal network or across trusted networks. 345 The use of Cryptographic authentication (i.e., an Auth Type value of 346 2) allows for a strong authentication mechanism since the keys cannot 347 be discerned by intercepting the packets. The proposed Keyed 348 authentication does not prevent replay attacks. However, in the case 349 of replay attacks, since the packet source IP/IPv6 address of the 350 traceroute probe can not be changed, there is no easy way for the 351 attacker to retrieve the ICMP messages. 353 A router needs to protect against purposefully-bogus UDP Traceroute 354 packets with extensions that fail the authentication, as a high rate 355 of messages can require significant processing time. [RFC1812] 356 specifies how rate-limiting is applied to the generation of ICMP 357 messages, and this rate-limiting deterrs the threat when applied 358 before checking the Authentication. Additionally, when using 359 Cryptographic authentication, the HMAC includes the source IP 360 address, which means the HMAC will not validate if the UDP packet is 361 sent over a NAT. 363 6. IANA Considerations 365 The UDP Traceroute Extension contains traceroute TLVs. IANA should 366 establish a registry of UDP Traceroute Extension Types. This 367 document defines Type 1 and Type 2 for authentication and 368 information-request. Types 3-0xF6 are allocated through Expert 369 Review [RFC5226]. Types 0xF7 to 0xFF are reserved for private use. 371 IANA should also establish a registry for UDP Traceroute Info-Request 372 Bits. This document defines bits 0 - 3 in section 3.2.2.2. Bits 373 4-29 are allocated through Expert Review. Bits 30 - 31 are reserved 374 for private use. 376 7. Acknowledgements 378 Many thanks to Dan Wing, for his insighful comments and valuable 379 suggestions regarding this document. 381 8. Normative References 383 [I-D.atlas-icmp-unnumbered] 384 Atlas, A., Bonica, R., Systems, N., Shen, N., and E. Chen, 385 "Extending ICMP to Identify the Receiving Interface", 386 draft-atlas-icmp-unnumbered-04 (work in progress), 387 November 2007. 389 [I-D.shen-icmp-routing-inst] 390 Shen, N. and E. Chen, "ICMP Extensions for Routing 391 Instances", draft-shen-icmp-routing-inst-00 (work in 392 progress), November 2006. 394 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 395 August 1980. 397 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 398 RFC 792, September 1981. 400 [RFC1812] Baker, F., "Requirements for IP Version 4 Routers", 401 RFC 1812, June 1995. 403 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 404 Requirement Levels", BCP 14, RFC 2119, March 1997. 406 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 407 Message Protocol (ICMPv6) for the Internet Protocol 408 Version 6 (IPv6) Specification", RFC 4443, March 2006. 410 [RFC4884] Bonica, R., Gan, D., Tappan, D., and C. Pignataro, 411 "Extended ICMP to Support Multi-Part Messages", RFC 4884, 412 April 2007. 414 [RFC4950] Bonica, R., Gan, D., Tappan, D., and C. Pignataro, "ICMP 415 Extensions for Multiprotocol Label Switching", RFC 4950, 416 August 2007. 418 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 419 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 420 May 2008. 422 Authors' Addresses 424 Naiming Shen 425 Cisco Systems, Inc. 426 225 West Tasman Drive 427 San Jose, CA 95134 428 USA 430 Email: naiming@cisco.com 432 Carlos Pignataro 433 Cisco Systems, Inc. 434 7200 Kit Creek Road 435 Research Triangle Park, NC 27709 436 USA 438 Email: cpignata@cisco.com 440 Rajiv Asati 441 Cisco Systems, Inc. 442 7025 Kit Creek Road 443 Research Triangle Park, NC 27709 444 USA 446 Email: rajiva@cisco.com 448 Enke Chen 449 Cisco Systems, Inc. 450 170 West Tasman Drive 451 San Jose, CA 95134 452 USA 454 Email: enkechen@cisco.com 456 Full Copyright Statement 458 Copyright (C) The IETF Trust (2008). 460 This document is subject to the rights, licenses and restrictions 461 contained in BCP 78, and except as set forth therein, the authors 462 retain all their rights. 464 This document and the information contained herein are provided on an 465 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 466 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 467 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 468 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 469 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 470 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 472 Intellectual Property 474 The IETF takes no position regarding the validity or scope of any 475 Intellectual Property Rights or other rights that might be claimed to 476 pertain to the implementation or use of the technology described in 477 this document or the extent to which any license under such rights 478 might or might not be available; nor does it represent that it has 479 made any independent effort to identify any such rights. Information 480 on the procedures with respect to rights in RFC documents can be 481 found in BCP 78 and BCP 79. 483 Copies of IPR disclosures made to the IETF Secretariat and any 484 assurances of licenses to be made available, or the result of an 485 attempt made to obtain a general license or permission for the use of 486 such proprietary rights by implementers or users of this 487 specification can be obtained from the IETF on-line IPR repository at 488 http://www.ietf.org/ipr. 490 The IETF invites any interested party to bring to its attention any 491 copyrights, patents or patent applications, or other proprietary 492 rights that may cover technology that may be required to implement 493 this standard. Please address the information to the IETF at 494 ietf-ipr@ietf.org.