idnits 2.17.1 draft-bonica-internet-icmp-14.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 20. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 903. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 914. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 921. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 927. 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 (December 11, 2006) is 6338 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) ** Downref: Normative reference to an Informational RFC: RFC 3022 == Outdated reference: A later version (-09) exists of draft-atlas-icmp-unnumbered-01 == Outdated reference: A later version (-08) exists of draft-ietf-mpls-icmp-06 == Outdated reference: A later version (-12) exists of draft-ietf-tcpm-icmp-attacks-01 Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet R. Bonica 3 Internet-Draft D. Gan 4 Intended status: Standards Track Juniper Networks 5 Expires: June 14, 2007 P. Nikander 6 Ericsson Research Nomadic Lab 7 D. Tappan 8 C. Pignataro 9 Cisco Systems, Inc. 10 December 11, 2006 12 Modifying ICMP to Support Multi-part Messages 13 draft-bonica-internet-icmp-14 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on June 14, 2007. 40 Copyright Notice 42 Copyright (C) The IETF Trust (2006). 44 Abstract 46 This document redefines selected ICMP messages to support multi-part 47 operation. A multi-part ICMP message carries all of the information 48 that ICMP messages carried previously, as well as additional 49 information that applications may require. 51 Multi-part messages are supported by an ICMP extension structure. 52 The extension structure is situated at the end of the ICMP message. 53 It includes an extension header followed by one or more extension 54 objects. Each extension object contains an object header and object 55 payload. All object headers share a common format. 57 This document further redefines the above mentioned ICMP messages by 58 specifying a length attribute. All of the currently defined ICMP 59 messages to which an extension structure can be appended include an 60 "original datagram" field. The "original datagram" field contains 61 the initial octets of the datagram that elicited the ICMP error 62 message. Although the original datagram field is of variable length, 63 the ICMP message does not include a field that specifies its length. 64 Therefore, in order to facilitate message parsing, this draft 65 allocates eight previously reserved bits to reflect the length of the 66 "original datagram" field. 68 The proposed modifications change the requirements for ICMP 69 compliance. The impact of these changes on compliant implementations 70 is discussed, and new requirements for future implementations are 71 presented. 73 Table of Contents 75 1. Conventions Used In This Document . . . . . . . . . . . . . . 4 76 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 77 3. Summary of Changes to ICMP . . . . . . . . . . . . . . . . . . 5 78 4. ICMP Extensibility . . . . . . . . . . . . . . . . . . . . . . 5 79 4.1. ICMPv4 Destination Unreachable . . . . . . . . . . . . . . 8 80 4.2. ICMPv4 Time Exceeded . . . . . . . . . . . . . . . . . . . 8 81 4.3. ICMPv4 Parameter Problem . . . . . . . . . . . . . . . . . 9 82 4.4. ICMPv6 Destination Unreachable . . . . . . . . . . . . . . 9 83 4.5. ICMPv6 Time Exceeded . . . . . . . . . . . . . . . . . . . 10 84 4.6. ICMP Messages That Can Be Extended . . . . . . . . . . . . 10 85 5. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 11 86 5.1. Classic Application Receives ICMP Message With 87 Extensions . . . . . . . . . . . . . . . . . . . . . . . . 12 88 5.2. Non-compliant Application Receives ICMP Message With 89 No Extensions . . . . . . . . . . . . . . . . . . . . . . 13 90 5.3. Non-compliant Application Receives ICMP Message With 91 Compliant Extensions . . . . . . . . . . . . . . . . . . . 14 92 5.4. Compliant Application Receives ICMP Message with No 93 Extensions . . . . . . . . . . . . . . . . . . . . . . . . 14 94 5.5. Compliant Application Receives ICMP Message with 95 Non-compliant Extensions . . . . . . . . . . . . . . . . . 14 96 6. Interaction with Network Address Translation . . . . . . . . . 15 97 7. The ICMP Extension Structure . . . . . . . . . . . . . . . . . 15 98 8. ICMP Extension Objects . . . . . . . . . . . . . . . . . . . . 16 99 9. Security Considerations . . . . . . . . . . . . . . . . . . . 17 100 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 101 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 102 12. Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 103 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 104 13.1. Normative References . . . . . . . . . . . . . . . . . . . 19 105 13.2. Informative References . . . . . . . . . . . . . . . . . . 19 106 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 107 Intellectual Property and Copyright Statements . . . . . . . . . . 22 109 1. Conventions Used In This Document 111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 113 document are to be interpreted as described in [RFC2119]. 115 2. Introduction 117 This document redefines selected ICMPv4 [RFC0792] and ICMPv6 118 [RFC4443] messages to include an extension structure and a length 119 attribute. The extension structure supports multi-part ICMP 120 operation. Protocol designers can make an ICMP message carry 121 additional information by encoding that information in the extension 122 structure. 124 This document also addresses a fundamental problem in ICMP 125 extensibility. All of the ICMP messages addressed by this memo 126 include an "original datagram" field. The "original datagram" field 127 contains the initial octets of the datagram that elicited the ICMP 128 error message. Although the "original datagram" field is of variable 129 length, the ICMP message does not include a field that specifies its 130 length. 132 Application software infers the length of the "original datagram" 133 field from the total length of the ICMP message. If an extension 134 structure were appended to the message without adding a length 135 attribute for the "original datagram" field, the message would become 136 unparsable. Specifically, application software would not be able to 137 determine where the "original datagram" field ends and where the 138 extension structure begins. Therefore, this document proposes a 139 length attribute as well as an extension structure that is appended 140 to the ICMP message. 142 The current memo also addresses backwards compatibility with existing 143 ICMP implementations that either do not implement the extensions 144 defined herein or implement them without adding the required length 145 attributes. In particular, this draft addresses backwards 146 compatibility with certain, widely deployed, MPLS-aware ICMPv4 147 implementations that send the extensions defined herein without 148 adding the required length attribute. 150 The current memo does not define any ICMP extension objects. It 151 defines only the extension header and a common header that all 152 extension objects share. [I-D.atlas-icmp-unnumbered], 153 [I-D.shen-icmp-routing-inst] and [I-D.ietf-mpls-icmp] provide sample 154 applications of the ICMP Extension Object. 156 The above mentioned memos share a common characteristic. They all 157 append information to the ICMP Time Expired message for consumption 158 by TRACEROUTE. In this case, as in many others, appending 159 information to the existing ICMP Time Expired Message is preferable 160 to defining a new message and emitting two messages whenever a packet 161 is dropped to to TTL expiration. 163 3. Summary of Changes to ICMP 165 The following is a summary of changes to ICMP that are proposed by 166 this memo: 168 An ICMP Extension Structure MAY be appended to ICMPv4 Destination 169 Unreachable, Time Exceeded, and Parameter Problem messages. 171 An ICMP Extension Structure MAY be appended to ICMPv6 Destination 172 Unreachable, and Time Exceeded messages. 174 The above mentioned messages include an "original datagram" field, 175 and the message formats are updated to specify a length attribute 176 for the "original datagram" field. 178 The "original datagram" field MUST include at least 128 octets. 179 If the original datagram did not contain 128 octets, the "original 180 datagram" field MUST be zero padded to 128 octets. 182 For ICMPv4 messages, the "original datagram" field MUST be zero 183 padded to the nearest 32-bit boundary. 185 For ICMPv6 messages, the "original datagram" field MUST be zero 186 padded to the nearest 64-bit boundary. 188 4. ICMP Extensibility 190 RFC 792 defines the following ICMPv4 message types: 192 - Destination Unreachable 194 - Time Exceeded 196 - Parameter Problem 198 - Source Quench 199 - Redirect 201 - Echo Request/Reply 203 - Timestamp/Timestamp Reply 205 - Information Request/Information Reply 207 [RFC1191] reserves bits for the "Next-Hop MTU" field in the 208 Destination Unreachable message. 210 RFC 4443 defines the following ICMPv6 message types: 212 - Destination Unreachable 214 - Packet Too Big 216 - Time Exceeded 218 - Parameter Problem 220 - Echo Request/Reply 222 Many ICMP messages are extensible as currently defined. Protocol 223 designers can extend ICMP messages by simply appending fields or data 224 structures to them. 226 Many ICMP messages are not extensible as currently defined. These 227 messages contain an "original datagram" field which represents the 228 leading octets of the datagram to which the ICMP message is a 229 response. RFC 792 defines the "original datagram" field for ICMPv4 230 messages. In RFC 792, the "original datagram" field includes the IP 231 header plus the next eight octets of the original datagram. 232 [RFC1812] extends the "original datagram" field to contain as many 233 octets as possible without causing the ICMP message to exceed the 234 minimum IPv4 reassembly buffer size (i.e., 576 octets). RFC 4443 235 defines the "original datagram" field for ICMPv6 messages. In RFC 236 4443, the "original datagram" field always contained as many octets 237 as possible without causing the ICMP message to exceed the minimum 238 IPv6 reassembly buffer size (i.e., 1280 octets). 240 Unfortunately, the "original datagram" field lacks a length 241 attribute. Application software infers the length of this field from 242 the total length of the ICMP message. If an extension structure were 243 appended to the message without adding a length attribute for the 244 "original datagram" field, the message would become unparsable. 245 Specifically, application software would not be able to determine 246 where the "original datagram" field ends and where the extension 247 structure begins. 249 In order to solve this problem, this memo introduces an 8-bit length 250 attribute to the following ICMPv4 messages. 252 - Destination Unreachable (type = 3) 254 - Time Exceeded (type = 11) 256 - Parameter Problem (type = 12) 258 It also introduces an 8-bit length attribute to the following ICMPv6 259 messages. 261 - Destination Unreachable (type = 1) 263 - Time Exceeded (type = 3) 265 The length attribute MUST be specified when the ICMP Extension 266 Structure is appended to the above mentioned ICMP messages. 268 The length attribute represents the length of the "original datagram" 269 field. Space for the length attribute is claimed from reserved 270 octets, whose value was previously required to be zero. 272 For ICMPv4 messages, the length attribute represents 32-bit words. 273 When the length attribute is specified, the "original datagram" field 274 MUST be zero padded to the nearest 32-bit boundary. Because the 275 sixth octet of each of the impacted ICMPv4 messages was reserved for 276 future use, this octet was selected as the location of the length 277 attribute in ICMPv4. 279 For ICMPv6 messages, the length attribute represents 64-bit words. 280 When the length attribute is specified, the "original datagram" field 281 MUST be zero padded to the nearest 64-bit boundary. Because the 282 fifth octet of each of the impacted ICMPv6 messages was reserved for 283 future use, this octet was selected as the location of the length 284 attribute in ICMPv6. 286 In order the achieve backwards compatibility, when the ICMP Extension 287 Structure is appended to an ICMP message and that ICMP message 288 contains an "original datagram" field, the "original datagram" field 289 MUST contain at least 128 octets. If the original datagram did not 290 contain 128 octets, the "original datagram" field MUST be zero padded 291 to 128 octets. (See Section 5.1 for rationale.) 293 The following sub-sections depict length attribute as it has been 294 introduced to selected ICMP messages. 296 4.1. ICMPv4 Destination Unreachable 298 Figure 1 depicts the ICMPv4 Destination Unreachable Message. 300 0 1 2 3 301 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 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 | Type | Code | Checksum | 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 | unused | Length | Next-Hop MTU* | 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 | Internet Header + leading octets of original datagram | 308 | | 309 | // | 310 | | 311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 313 Figure 1: ICMPv4 Destination Unreachable 315 The syntax and semantics of all fields are unchanged from RFC 792. 316 However, a length attribute is added to the second word. The length 317 attribute represents length of the padded "original datagram" field, 318 measured in 32-bit words. 320 * The Next-Hop MTU field is not required in all cases. It is 321 depicted only to demonstrate that those bits are not available for 322 assignment in this memo. 324 4.2. ICMPv4 Time Exceeded 326 Figure 2 depicts the ICMPv4 Time Exceeded Message. 328 0 1 2 3 329 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 330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 331 | Type | Code | Checksum | 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 | unused | Length | unused | 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 335 | Internet Header + leading octets of original datagram | 336 | | 337 | // | 338 | | 339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 340 Figure 2: ICMPv4 Time Exceeded 342 The syntax and semantics of all fields are unchanged from RFC 792, 343 except for a length attribute which is added to the second word. The 344 length attribute represents length of the padded "original datagram" 345 field, measured in 32-bit words. 347 4.3. ICMPv4 Parameter Problem 349 Figure 3 depicts the ICMPv4 Parameter Problem Message. 351 0 1 2 3 352 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 353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 354 | Type | Code | Checksum | 355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 356 | Pointer | Length | unused | 357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 358 | Internet Header + leading octets of original datagram | 359 | | 360 | // | 361 | | 362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 364 Figure 3: ICMPv4 Parameter Problem 366 The syntax and semantics of all fields are unchanged from RFC 792, 367 except for a length attribute which is added to the second word. The 368 length attribute represents length of the padded "original datagram" 369 field, measured in 32-bit words. 371 4.4. ICMPv6 Destination Unreachable 373 Figure 4 depicts the ICMPv6 Destination Unreachable Message. 375 0 1 2 3 376 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 377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 378 | Type | Code | Checksum | 379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 380 | Length | Unused | 381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 382 | As much of invoking packet | 383 + as possible without the ICMPv6 packet + 384 | exceeding the minimum IPv6 MTU [RFC4443] | 386 Figure 4: ICMPv6 Destination Unreachable 388 The syntax and semantics of all fields are unchanged from RFC 4443. 389 However, a length attribute is added to the second word. The length 390 attribute represents length of the padded "original datagram" field, 391 measured in 64-bit words. 393 4.5. ICMPv6 Time Exceeded 395 Figure 5 depicts the ICMPv6 Time Exceeded Message. 397 0 1 2 3 398 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 399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 400 | Type | Code | Checksum | 401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 402 | Length | Unused | 403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 404 | As much of invoking packet | 405 + as possible without the ICMPv6 packet + 406 | exceeding the minimum IPv6 MTU [RFC4443] | 408 Figure 5: ICMPv6 Time Exceeded 410 The syntax and semantics of all fields are unchanged from RFC 4443, 411 except for a length attribute which is added to the second word. The 412 length attribute represents length of the padded "original datagram" 413 field, measured in 64-bit words. 415 4.6. ICMP Messages That Can Be Extended 417 The ICMP Extension Structure MAY be appended to messages of the 418 following types: 420 - ICMPv4 Destination Unreachable 422 - ICMPv4 Time Exceeded 424 - ICMPv4 Parameter Problem 426 - ICMPv6 Destination Unreachable 427 - ICMPv6 Time Exceeded 429 The ICMP Extension Structure MUST NOT be appended to any of the other 430 ICMP messages mentioned in Section 4. Extensions were not defined 431 for the ICMPv6 "Packet Too Big" and "Parameter Problem" messages 432 because these messages lack space for a length attribute. 434 ICMP messages defined in the future SHOULD indicate whether or not 435 they support the extension mechanism defined in this specification. 436 It is recommended that all new messages support extensions. 438 5. Backwards Compatibility 440 ICMP messages can be categorized as follows: 442 - Messages that do not include any ICMP extensions 444 - Messages that include non-compliant ICMP extensions 446 - Messages that includes compliant ICMP extensions 448 Any ICMP implementation can send a message that does not include 449 extensions. ICMP implementations produced prior to 1999 are not 450 known to send ICMP extensions. 452 Some ICMP implementations, produced between 1999 and the present, may 453 send a non-compliant version of ICMP extensions described in this 454 memo. Specifically, these implementations may append the ICMP 455 Extension Structure to the Time Exceeded and Destination Unreachable 456 messages. When they do this, they send exactly 128 octets 457 representing the original datagram, zero padding if required. They 458 also calculate checksums as described in this document. However, 459 they do not specify a length attribute to be associated with the 460 "original datagram" field. 462 It is assumed that ICMP implementations produced in the future will 463 send ICMP extensions that are compliant with this specification. 465 Likewise, applications that consume ICMP messages can be categorized 466 as follows: 468 - Classic applications 470 - Non-compliant applications 471 - Compliant applications 473 Classic applications do not parse extensions defined in this memo. 474 They are insensitive to the length attribute that is associated with 475 the "original datagram" field. 477 Non-compliant implementations parse the extensions defined in this 478 memo, but only in conjunction with the Time Expired and Destination 479 Unreachable messages. They require the "original datagram" field to 480 contain exactly 128 octets and are insensitive to the length 481 attribute that is associated with the "original datagram" field. 482 Non-compliant applications were produced between 1999 and the 483 present. 485 Compliant applications comply fully with the specifications of this 486 document. 488 In order to demonstrate backwards compatibility, Table 1 describes 489 how members of each application category would parse each category of 490 ICMP message. 492 +----------------+----------------+----------------+----------------+ 493 | | No Extensions | Non-compliant | Compliant | 494 | | | Extensions | Extensions | 495 +----------------+----------------+----------------+----------------+ 496 | Classic | - | Section 5.1 | Section 5.1 | 497 | Application | | | | 498 | | | | | 499 | Non-compliant | Section 5.2 | - | Section 5.3 | 500 | Application | | | | 501 | | | | | 502 | Compliant | Section 5.4 | Section 5.5 | - | 503 | Application | | | | 504 +----------------+----------------+----------------+----------------+ 506 Table 1 508 In the table above, cells that contain a dash represent the nominal 509 case and require no explanation. In the following sections, we 510 assume that the ICMP message type is "Time Exceeded". 512 5.1. Classic Application Receives ICMP Message With Extensions 514 When a classic application receives an ICMP message that includes 515 extensions, it will incorrectly interpret those extensions as being 516 part of the "original datagram" field. Fortunately, the extensions 517 are guaranteed to begin at least 128 octets beyond the beginning of 518 the "original datagram" field. So, only those ICMP applications that 519 process the 129th octet of the "original datagram" field will be 520 adversely effected. To date, only two applications falling into this 521 catagory have been identified and the degree to which they are 522 effected is minimal. 524 Some TCP stacks, when they receive an ICMP message, verify the 525 checksum in the original datagram field [I-D.ietf-tcpm-icmp-attacks]. 526 If the checksum is incorrect, the TCP stack discards the ICMP message 527 for security reasons. If the trailing octets of the original 528 datagram field are overwritten by ICMP extensions, the TCP stack will 529 discard an ICMP message that it would not otherwise have discarded. 530 The impact of this issue is considered to be minimal because many 531 ICMP messages are discarded for other reasons (e.g., ICMP filtering, 532 network congestion, checksum was incorrect because original datagram 533 field was truncated.) 535 Another theoretically possible, but highly improbably scenario occurs 536 when ICMP extensions overwrite the portion of the original datagram 537 field that represents the TCP header, causing the TCP stack to 538 operate upon the wrong TCP connection. This scenario is highly 539 unlikely because it occurs only when the TCP header appears at or 540 beyond the 128th octet of the original datagram field and then only 541 when the extensions approximate a valid TCP header. 543 5.2. Non-compliant Application Receives ICMP Message With No Extensions 545 When a non-compliant ICMPv4 application receives a message that 546 contains no extensions, the application examines the total length of 547 the ICMPv4 message. If the total ICMPv4 message length is less than 548 the length of its IP header plus 144 octets, the application 549 correctly determines that the message does not contain any 550 extensions. 552 The 144 octet sum is derived from 8 octets for the first two words of 553 the ICMPv4 Time Exceeded message, 128 octets for the "original 554 datagram" field, 4 octets for the ICMP Extension Header and 4 octets 555 for a single ICMP Object header. All of these octets would be 556 required if extensions were present. 558 If the ICMPv4 payload contains 144 octets or more, the application 559 must examine the 137th octet to determine whether it represents a 560 valid ICMPv4 Extension Header. In order to represent a valid 561 Extension Header, it must contain a valid version number and 562 checksum. If it does not contain a valid version number and 563 checksum, the application correctly determines that the message does 564 not contain any extensions. 566 Non-compliant applications assume that the ICMPv4 Extension Structure 567 begins on the 137th octet of the Time Exceeded message, after a 128 568 octet field representing the padded "original datagram" message. 570 It is possible that a non-compliant application will parse an ICMPv4 571 message incorrectly under the following conditions: 573 - the message does not contain extensions 575 - the original datagram field contains 144 octets or more 577 - selected octets of the original datagram field represent the 578 correct values for an extension header version number and checksum 580 Although this is possible, it is very unlikely. 582 A similar analysis can be performed for ICMPv6. However, the numeric 583 constants would change as appropriate. 585 5.3. Non-compliant Application Receives ICMP Message With Compliant 586 Extensions 588 When a non-compliant application receives a message that contains 589 compliant ICMP extensions, it will parse those extensions correctly 590 only if the "original datagram" field contains exactly 128 octets. 591 This is because non-compliant applications are insensitive to the 592 length attribute that is associated with the "original datagram" 593 field. (They assume its value to be 128.) 595 Provided that the entire ICMP messages does not exceed the minimum 596 reassembly buffer size (576 octets for ICMPv4 or 1280 octets for 597 ICMPv6), there is no upper limit upon the length of the "original 598 datagram" field. However, each vendor will decide how many octets to 599 include. Those wishing to be backward compatible with non-compliant 600 TRACEROUTE implementations will include exactly 128 octets. Those 601 not requiring compatibility with non-compliant TRACEROUTE 602 applications may include more octets. 604 5.4. Compliant Application Receives ICMP Message with No Extensions 606 When a compliant application receives an ICMP message, it examines 607 the length attribute that is associated with the "original datagram" 608 field. If the length attribute is zero, the compliant application 609 MUST determine that the message contains no extensions. 611 5.5. Compliant Application Receives ICMP Message with Non-compliant 612 Extensions 614 When a compliant application receives an ICMP message, it examines 615 the length attribute that is associated with the "original datagram" 616 field. If the length attribute is zero, the compliant application 617 MUST determine that the message contains no extensions. In this 618 case, that determination is technically correct, but not backwards 619 compatible with the non-compliant implementation that originated the 620 ICMP message. 622 So, to ease transition yet encourage compliant implementation, 623 compliant TRACEROUTE implementations MAY include a non-default 624 operation mode to also interpret non-compliant responses. 625 Specifically, when a TRACEROUTE application operating in non- 626 compliant mode receives a sufficiently long ICMP message that does 627 not specify a length attribute, it will parse for a valid extension 628 header at a fixed location, assuming a 128 octet "original datagram" 629 field. If the application detects a valid version and checksum, it 630 will treat the following octets as an extension structure. 632 6. Interaction with Network Address Translation 634 The ICMP extensions defined in this memo do not interfere with 635 Network Address Translation. [RFC3022] permits traditional NAT 636 devices to modify selected fields within ICMP messages. These fields 637 include the "original datagram" field mentioned above. However, if a 638 NAT device modifies the "original datagram" field, it should modify 639 only the leading octets of that field which represent the outermost 640 IP header. Because the outermost IP header is guaranteed to be 641 contained by the first 128 octets of the "original datagram" field, 642 ICMP extensions and NAT will not interact with one another. 644 It is conceivable that a NAT implementation might overstep the 645 restrictions of RFC 3022 and overwrite the length attribute specified 646 by this memo. If a NAT implementation were to overwrite the length 647 attribute with zeros, the resulting packet will be indistinguishable 648 from a packet that was generated by a non-compliant ICMP 649 implementation. See Section 5.5 for packet details and a discussion 650 of backwards compatibility. 652 7. The ICMP Extension Structure 654 This memo proposes an optional ICMP Extension Structure that can be 655 appended to the ICMP messages referenced in Section 4.6 of this 656 document. 658 The Extension Structure contains exactly one Extension Header 659 followed by one or more objects. Having received an ICMP message 660 with extensions, application software MAY process selected objects 661 while ignoring others. The presence of an unrecognized object does 662 not imply that an ICMP message is malformed. 664 As stated above, the total length of the ICMP message, including 665 extensions, MUST NOT exceed the minimum reassembly buffer size. 666 Figure 6 depicts the ICMP Extension Header. 668 0 1 2 3 669 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 670 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 671 |Version| (Reserved) | Checksum | 672 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 674 Figure 6: ICMP Extension Header 676 The fields of the ICMP Extension Header are as follows: 678 Version: 4 bits 680 ICMP extension version number. This is version 2. 682 Reserved: 12 bits 684 Must be set to 0. 686 Checksum: 16 bits 688 The one's complement of the one's complement sum of the data 689 structure, with the checksum field replaced by zero for the 690 purpose of computing the checksum. An all-zero value means that 691 no checksum was transmitted. See Section 5.2 for a description of 692 how this field is used. 694 8. ICMP Extension Objects 696 Each extension object contains one or more 32-bit words, representing 697 an object header and payload. All object headers share a common 698 format. Figure 7 depicts the Object Header and payload. 700 0 1 2 3 701 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 702 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 703 | Length | Class-Num | C-Type | 704 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 705 | | 706 | // (Object payload) // | 707 | | 708 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 710 Figure 7: Object Header and Payload 712 An object header has the following fields: 714 Length: 16 bits 716 Length of the object, measured in octets, including the object 717 header and object payload. 719 Class-Num: 8 bits 721 Identifies object class. 723 C-Type: 8 bits 725 Identifies object sub-type. 727 9. Security Considerations 729 Upon receipt of an ICMP message, application software must check it 730 for syntactic correctness. The extension checksum must be verified. 731 Improperly specified length attributes and other syntax problems may 732 result in buffer overruns. 734 This memo does not define the conditions under which a router sends 735 an ICMP message. Therefore, it does not expose routers to any new 736 denial of service attacks. Routers may need to limit the rate at 737 which ICMP messages are sent. 739 10. IANA Considerations 741 The ICMP Extension Object header contains two 8-bit fields: The 742 Class-Num identifies the object class, and the C-Type identifies the 743 class sub-type. Sub-type values are defined relative to a specific 744 object class value, and are defined per-class. 746 IANA should establish a registry of ICMP extension objects classes 747 and class sub-types. There are no values assigned within this 748 document to maintain. Object classes 0xF7 - 0xFF are reserved for 749 private use. Object class values are assignable on a first-come- 750 first-serve. The policy for assigning sub-type values should be 751 defined in the document defining new class values. 753 11. Acknowledgments 755 Thanks to Mark Doll, Fernando Gont, Joe Touch and Christian Voiqt and 756 for their comments regarding this draft. 758 12. Testing 760 [RFC Editor: Please remove this section before publication] 762 In order to demonstrate that the ICMP extensions defined herein do 763 not adversely impact classic ICMP applications, the authors performed 764 the following experiments: 766 Experiment 1: Ping a device that sends non-compliant ICMP 767 extensions. Also ping through a devices that sends non-compliant 768 ICMP extensions. 770 Experiment 2: Traceroute to device that sends non-compliant ICMP 771 extensions. Also traceroute through a devices that sends non- 772 compliant ICMP extensions. 774 Experiment 3: Cause a TCP implementation to receive a non- 775 compliant ICMP messages with extensions that is classified as a 776 soft error. 778 Experiment 4: Cause a TCP implementation to receive a non- 779 compliant ICMP messages with extensions that is classified as a 780 hard error. 782 As defined in Section 5, a non-compliant ICMP extension is identical 783 to a fully compliant extension in every way excpet that it lacks a 784 length attribute. 786 In all cases, the classic application behaved as if the ICMP 787 extension was not present. 789 Classic applications ran under the following operating systems: 791 Windows XP 793 Macintosh OS X, OS 9 795 Solaris 797 Linux 799 Cisco IOS XR 801 Juniper JUNOS 803 13. References 805 13.1. Normative References 807 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 808 RFC 792, September 1981. 810 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 811 November 1990. 813 [RFC1812] Baker, F., "Requirements for IP Version 4 Routers", 814 RFC 1812, June 1995. 816 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 817 Requirement Levels", BCP 14, RFC 2119, March 1997. 819 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 820 Address Translator (Traditional NAT)", RFC 3022, 821 January 2001. 823 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 824 Message Protocol (ICMPv6) for the Internet Protocol 825 Version 6 (IPv6) Specification", RFC 4443, March 2006. 827 13.2. Informative References 829 [I-D.atlas-icmp-unnumbered] 830 Atlas, A., "ICMP Extensions for Unnumbered Interfaces", 831 draft-atlas-icmp-unnumbered-01 (work in progress), 832 March 2006. 834 [I-D.ietf-mpls-icmp] 835 Bonica, R., "ICMP Extensions for MultiProtocol Label 836 Switching", draft-ietf-mpls-icmp-06 (work in progress), 837 September 2006. 839 [I-D.ietf-tcpm-icmp-attacks] 840 Gont, F., "ICMP attacks against TCP", 841 draft-ietf-tcpm-icmp-attacks-01 (work in progress), 842 October 2006. 844 [I-D.shen-icmp-routing-inst] 845 Shen, N. and E. Chen, "ICMP Extensions for Routing 846 Instances", draft-shen-icmp-routing-inst-00 (work in 847 progress), November 2006. 849 Authors' Addresses 851 Ronald P. Bonica 852 Juniper Networks 853 2251 Corporate Park Drive 854 Herndon, VA 20171 855 US 857 Email: rbonica@juniper.net 859 Der-Hwa Gan 860 Juniper Networks 861 1194 N. Mathilda Ave. 862 Sunnyvale, CA 94089 863 US 865 Email: dhg@juniper.net 867 Pekka Nikander 868 Ericsson Research Nomadic Lab 869 JORVAS FIN-02420 870 Finland 872 Email: pekka.nikander@nomadiclab.com 874 Daniel C. Tappan 875 Cisco Systems, Inc. 876 250 Apollo Drive 877 Chelmsford, MA 01824 878 US 880 Email: dan.tappan@gmail.com 881 Carlos Pignataro 882 Cisco Systems, Inc. 883 7025 Kit Creek Road 884 Research Triangle Park, N.C. 27709 885 US 887 Email: cpignata@cisco.com 889 Full Copyright Statement 891 Copyright (C) The IETF Trust (2006). 893 This document is subject to the rights, licenses and restrictions 894 contained in BCP 78, and except as set forth therein, the authors 895 retain all their rights. 897 This document and the information contained herein are provided on an 898 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 899 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 900 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 901 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 902 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 903 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 905 Intellectual Property 907 The IETF takes no position regarding the validity or scope of any 908 Intellectual Property Rights or other rights that might be claimed to 909 pertain to the implementation or use of the technology described in 910 this document or the extent to which any license under such rights 911 might or might not be available; nor does it represent that it has 912 made any independent effort to identify any such rights. Information 913 on the procedures with respect to rights in RFC documents can be 914 found in BCP 78 and BCP 79. 916 Copies of IPR disclosures made to the IETF Secretariat and any 917 assurances of licenses to be made available, or the result of an 918 attempt made to obtain a general license or permission for the use of 919 such proprietary rights by implementers or users of this 920 specification can be obtained from the IETF on-line IPR repository at 921 http://www.ietf.org/ipr. 923 The IETF invites any interested party to bring to its attention any 924 copyrights, patents or patent applications, or other proprietary 925 rights that may cover technology that may be required to implement 926 this standard. Please address the information to the IETF at 927 ietf-ipr@ietf.org. 929 Acknowledgment 931 Funding for the RFC Editor function is provided by the IETF 932 Administrative Support Activity (IASA).