idnits 2.17.1 draft-bonica-internet-icmp-16.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 930. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 941. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 948. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 954. 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 (Using the creation date from RFC792, updated by this document, for RFC5378 checks: 1981-09-01) -- 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 (January 27, 2007) is 6293 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-01 == Outdated reference: A later version (-08) exists of draft-ietf-mpls-icmp-07 == Outdated reference: A later version (-12) exists of draft-ietf-tcpm-icmp-attacks-01 Summary: 1 error (**), 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 Updates: 792, 4443 Juniper Networks 5 (if approved) P. Nikander 6 Intended status: Standards Track Ericsson Research Nomadic Lab 7 Expires: July 31, 2007 D. Tappan 8 C. Pignataro 9 Cisco Systems, Inc. 10 January 27, 2007 12 Extended ICMP to Support Multi-part Messages 13 draft-bonica-internet-icmp-16 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 July 31, 2007. 40 Copyright Notice 42 Copyright (C) The IETF Trust (2007). 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 This memo updates RFC 792 and RFC 4443. 75 Table of Contents 77 1. Conventions Used In This Document . . . . . . . . . . . . . . 4 78 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 79 3. Summary of Changes to ICMP . . . . . . . . . . . . . . . . . . 5 80 4. ICMP Extensibility . . . . . . . . . . . . . . . . . . . . . . 5 81 4.1. ICMPv4 Destination Unreachable . . . . . . . . . . . . . . 8 82 4.2. ICMPv4 Time Exceeded . . . . . . . . . . . . . . . . . . . 9 83 4.3. ICMPv4 Parameter Problem . . . . . . . . . . . . . . . . . 9 84 4.4. ICMPv6 Destination Unreachable . . . . . . . . . . . . . . 10 85 4.5. ICMPv6 Time Exceeded . . . . . . . . . . . . . . . . . . . 10 86 4.6. ICMP Messages That Can Be Extended . . . . . . . . . . . . 11 87 5. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 11 88 5.1. Classic Application Receives ICMP Message With 89 Extensions . . . . . . . . . . . . . . . . . . . . . . . . 13 90 5.2. Non-compliant Application Receives ICMP Message With 91 No Extensions . . . . . . . . . . . . . . . . . . . . . . 14 92 5.3. Non-compliant Application Receives ICMP Message With 93 Compliant Extensions . . . . . . . . . . . . . . . . . . . 15 94 5.4. Compliant Application Receives ICMP Message with No 95 Extensions . . . . . . . . . . . . . . . . . . . . . . . . 15 96 5.5. Compliant Application Receives ICMP Message with 97 Non-compliant Extensions . . . . . . . . . . . . . . . . . 15 98 6. Interaction with Network Address Translation . . . . . . . . . 16 99 7. The ICMP Extension Structure . . . . . . . . . . . . . . . . . 16 100 8. ICMP Extension Objects . . . . . . . . . . . . . . . . . . . . 17 101 9. Security Considerations . . . . . . . . . . . . . . . . . . . 18 102 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 103 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 104 12. Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 105 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 106 13.1. Normative References . . . . . . . . . . . . . . . . . . . 19 107 13.2. Informative References . . . . . . . . . . . . . . . . . . 20 108 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 109 Intellectual Property and Copyright Statements . . . . . . . . . . 22 111 1. Conventions Used In This Document 113 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 114 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 115 document are to be interpreted as described in [RFC2119]. 117 2. Introduction 119 This document redefines selected ICMPv4 [RFC0792] and ICMPv6 120 [RFC4443] messages to include an extension structure and a length 121 attribute. The extension structure supports multi-part ICMP 122 operation. Protocol designers can make an ICMP message carry 123 additional information by encoding that information in the extension 124 structure. 126 This document also addresses a fundamental problem in ICMP 127 extensibility. All of the ICMP messages addressed by this memo 128 include an "original datagram" field. The "original datagram" field 129 contains the initial octets of the datagram that elicited the ICMP 130 error message. Although the "original datagram" field is of variable 131 length, the ICMP message does not include a field that specifies its 132 length. 134 Application software infers the length of the "original datagram" 135 field from the total length of the ICMP message. If an extension 136 structure were appended to the message without adding a length 137 attribute for the "original datagram" field, the message would become 138 unparsable. Specifically, application software would not be able to 139 determine where the "original datagram" field ends and where the 140 extension structure begins. Therefore, this document proposes a 141 length attribute as well as an extension structure that is appended 142 to the ICMP message. 144 The current memo also addresses backwards compatibility with existing 145 ICMP implementations that either do not implement the extensions 146 defined herein or implement them without adding the required length 147 attributes. In particular, this draft addresses backwards 148 compatibility with certain, widely deployed, MPLS-aware ICMPv4 149 implementations that send the extensions defined herein without 150 adding the required length attribute. 152 The current memo does not define any ICMP extension objects. It 153 defines only the extension header and a common header that all 154 extension objects share. [I-D.atlas-icmp-unnumbered], 155 [I-D.shen-icmp-routing-inst] and [I-D.ietf-mpls-icmp] provide sample 156 applications of the ICMP Extension Object. 158 The above mentioned memos share a common characteristic. They all 159 append information to the ICMP Time Expired message for consumption 160 by TRACEROUTE. In this case, as in many others, appending 161 information to the existing ICMP Time Expired Message is preferable 162 to defining a new message and emitting two messages whenever a packet 163 is dropped due to TTL expiration. 165 3. Summary of Changes to ICMP 167 The following is a summary of changes to ICMP that are introduced by 168 this memo: 170 An ICMP Extension Structure MAY be appended to ICMPv4 Destination 171 Unreachable, Time Exceeded, and Parameter Problem messages. 173 An ICMP Extension Structure MAY be appended to ICMPv6 Destination 174 Unreachable, and Time Exceeded messages. 176 The above mentioned messages include an "original datagram" field, 177 and the message formats are updated to specify a length attribute 178 for the "original datagram" field. 180 When the ICMP Extension Structure is appended to an ICMP message 181 and that ICMP message contains an "original datagram" field, the 182 "original datagram" field MUST contain at least 128 octets 184 When the ICMP Extension Structure is appended to an ICMPv4 message 185 and that ICMPv4 message contains an "original datagram" field, the 186 "original datagram" field MUST be zero padded to the nearest 32- 187 bit boundary. 189 When the ICMP Extension Structure is appended to an ICMPv6 message 190 and that ICMPv6 message contains an "original datagram" field, the 191 "original datagram" field MUST be zero padded to the nearest 64- 192 bit boundary. 194 ICMP messages defined in the future SHOULD indicate whether or not 195 they support the extension mechanism defined in this 196 specification. It is recommended that all new messages support 197 extensions. 199 4. ICMP Extensibility 201 RFC 792 defines the following ICMPv4 message types: 203 - Destination Unreachable 205 - Time Exceeded 207 - Parameter Problem 209 - Source Quench 211 - Redirect 213 - Echo Request/Reply 215 - Timestamp/Timestamp Reply 217 - Information Request/Information Reply 219 [RFC1191] reserves bits for the "Next-Hop MTU" field in the 220 Destination Unreachable message. 222 RFC 4443 defines the following ICMPv6 message types: 224 - Destination Unreachable 226 - Packet Too Big 228 - Time Exceeded 230 - Parameter Problem 232 - Echo Request/Reply 234 Many ICMP messages are extensible as currently defined. Protocol 235 designers can extend ICMP messages by simply appending fields or data 236 structures to them. 238 However, the following ICMP messages are not extensible as currently 239 defined: 241 - ICMPv4 Destination Unreachable (type = 3) 243 - ICMPv4 Time Exceeded (type = 11) 245 - ICMPv4 Parameter Problem (type = 12) 247 - ICMPv6 Destination Unreachable (type = 1) 248 - ICMPv6 Packet Too Big (type = 2) 250 - ICMPv6 Time Exceeded (type = 3) 252 - ICMPv6 Parameter Problem (type = 4) 254 These messages contain an "original datagram" field which represents 255 the leading octets of the datagram to which the ICMP message is a 256 response. RFC 792 defines the "original datagram" field for ICMPv4 257 messages. In RFC 792, the "original datagram" field includes the IP 258 header plus the next eight octets of the original datagram. 259 [RFC1812] extends the "original datagram" field to contain as many 260 octets as possible without causing the ICMP message to exceed the 261 minimum IPv4 reassembly buffer size (i.e., 576 octets). RFC 4443 262 defines the "original datagram" field for ICMPv6 messages. In RFC 263 4443, the "original datagram" field always contained as many octets 264 as possible without causing the ICMP message to exceed the minimum 265 IPv6 reassembly buffer size (i.e., 1280 octets). 267 Unfortunately, the "original datagram" field lacks a length 268 attribute. Application software infers the length of this field from 269 the total length of the ICMP message. If an extension structure were 270 appended to the message without adding a length attribute for the 271 "original datagram" field, the message would become unparsable. 272 Specifically, application software would not be able to determine 273 where the "original datagram" field ends and where the extension 274 structure begins. 276 In order to solve this problem, this memo introduces an 8-bit length 277 attribute to the following ICMPv4 messages. 279 - Destination Unreachable (type = 3) 281 - Time Exceeded (type = 11) 283 - Parameter Problem (type = 12) 285 It also introduces an 8-bit length attribute to the following ICMPv6 286 messages. 288 - Destination Unreachable (type = 1) 290 - Time Exceeded (type = 3) 292 The length attribute MUST be specified when the ICMP Extension 293 Structure is appended to the above mentioned ICMP messages. 295 The length attribute represents the length of the "original datagram" 296 field. Space for the length attribute is claimed from reserved 297 octets, whose value was previously required to be zero. 299 For ICMPv4 messages, the length attribute represents 32-bit words. 300 When the length attribute is specified, the "original datagram" field 301 MUST be zero padded to the nearest 32-bit boundary. Because the 302 sixth octet of each of the impacted ICMPv4 messages was reserved for 303 future use, this octet was selected as the location of the length 304 attribute in ICMPv4. 306 For ICMPv6 messages, the length attribute represents 64-bit words. 307 When the length attribute is specified, the "original datagram" field 308 MUST be zero padded to the nearest 64-bit boundary. Because the 309 fifth octet of each of the impacted ICMPv6 messages was reserved for 310 future use, this octet was selected as the location of the length 311 attribute in ICMPv6. 313 In order the achieve backwards compatibility, when the ICMP Extension 314 Structure is appended to an ICMP message and that ICMP message 315 contains an "original datagram" field, the "original datagram" field 316 MUST contain at least 128 octets. If the original datagram did not 317 contain 128 octets, the "original datagram" field MUST be zero padded 318 to 128 octets. (See Section 5.1 for rationale.) 320 The following sub-sections depict length attribute as it has been 321 introduced to selected ICMP messages. 323 4.1. ICMPv4 Destination Unreachable 325 Figure 1 depicts the ICMPv4 Destination Unreachable Message. 327 0 1 2 3 328 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 329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 330 | Type | Code | Checksum | 331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 332 | unused | Length | Next-Hop MTU* | 333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 334 | Internet Header + leading octets of original datagram | 335 | | 336 | // | 337 | | 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 340 Figure 1: ICMPv4 Destination Unreachable 342 The syntax and semantics of all fields are unchanged from RFC 792. 343 However, a length attribute is added to the second word. The length 344 attribute represents length of the padded "original datagram" field, 345 measured in 32-bit words. 347 * The Next-Hop MTU field is not required in all cases. It is 348 depicted only to demonstrate that those bits are not available for 349 assignment in this memo. 351 4.2. ICMPv4 Time Exceeded 353 Figure 2 depicts the ICMPv4 Time Exceeded Message. 355 0 1 2 3 356 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 357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 358 | Type | Code | Checksum | 359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 360 | unused | Length | unused | 361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 362 | Internet Header + leading octets of original datagram | 363 | | 364 | // | 365 | | 366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 368 Figure 2: ICMPv4 Time Exceeded 370 The syntax and semantics of all fields are unchanged from RFC 792, 371 except for a length attribute which is added to the second word. The 372 length attribute represents length of the padded "original datagram" 373 field, measured in 32-bit words. 375 4.3. ICMPv4 Parameter Problem 377 Figure 3 depicts the ICMPv4 Parameter Problem Message. 379 0 1 2 3 380 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 381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 382 | Type | Code | Checksum | 383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 384 | Pointer | Length | unused | 385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 386 | Internet Header + leading octets of original datagram | 387 | | 388 | // | 389 | | 390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 392 Figure 3: ICMPv4 Parameter Problem 394 The syntax and semantics of all fields are unchanged from RFC 792, 395 except for a length attribute which is added to the second word. The 396 length attribute represents length of the padded "original datagram" 397 field, measured in 32-bit words. 399 4.4. ICMPv6 Destination Unreachable 401 Figure 4 depicts the ICMPv6 Destination Unreachable Message. 403 0 1 2 3 404 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 405 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 406 | Type | Code | Checksum | 407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 408 | Length | Unused | 409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 410 | As much of invoking packet | 411 + as possible without the ICMPv6 packet + 412 | exceeding the minimum IPv6 MTU [RFC4443] | 414 Figure 4: ICMPv6 Destination Unreachable 416 The syntax and semantics of all fields are unchanged from RFC 4443. 417 However, a length attribute is added to the second word. The length 418 attribute represents length of the padded "original datagram" field, 419 measured in 64-bit words. 421 4.5. ICMPv6 Time Exceeded 423 Figure 5 depicts the ICMPv6 Time Exceeded Message. 425 0 1 2 3 426 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 427 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 428 | Type | Code | Checksum | 429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 430 | Length | Unused | 431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 432 | As much of invoking packet | 433 + as possible without the ICMPv6 packet + 434 | exceeding the minimum IPv6 MTU [RFC4443] | 436 Figure 5: ICMPv6 Time Exceeded 438 The syntax and semantics of all fields are unchanged from RFC 4443, 439 except for a length attribute which is added to the second word. The 440 length attribute represents length of the padded "original datagram" 441 field, measured in 64-bit words. 443 4.6. ICMP Messages That Can Be Extended 445 The ICMP Extension Structure MAY be appended to messages of the 446 following types: 448 - ICMPv4 Destination Unreachable 450 - ICMPv4 Time Exceeded 452 - ICMPv4 Parameter Problem 454 - ICMPv6 Destination Unreachable 456 - ICMPv6 Time Exceeded 458 The ICMP Extension Structure MUST NOT be appended to any of the other 459 ICMP messages mentioned in Section 4. Extensions were not defined 460 for the ICMPv6 "Packet Too Big" and "Parameter Problem" messages 461 because these messages lack space for a length attribute. 463 5. Backwards Compatibility 465 ICMP messages can be categorized as follows: 467 - Messages that do not include any ICMP extensions 468 - Messages that include non-compliant ICMP extensions 470 - Messages that includes compliant ICMP extensions 472 Any ICMP implementation can send a message that does not include 473 extensions. ICMP implementations produced prior to 1999 are not 474 known to send ICMP extensions. 476 Some ICMP implementations, produced between 1999 and the time of this 477 publication, may send a non-compliant version of ICMP extensions 478 described in this memo. Specifically, these implementations may 479 append the ICMP Extension Structure to the Time Exceeded and 480 Destination Unreachable messages. When they do this, they send 481 exactly 128 octets representing the original datagram, zero padding 482 if required. They also calculate checksums as described in this 483 document. However, they do not specify a length attribute to be 484 associated with the "original datagram" field. 486 It is assumed that ICMP implementations produced in the future will 487 send ICMP extensions that are compliant with this specification. 489 Likewise, applications that consume ICMP messages can be categorized 490 as follows: 492 - Classic applications 494 - Non-compliant applications 496 - Compliant applications 498 Classic applications do not parse extensions defined in this memo. 499 They are insensitive to the length attribute that is associated with 500 the "original datagram" field. 502 Non-compliant implementations parse the extensions defined in this 503 memo, but only in conjunction with the Time Expired and Destination 504 Unreachable messages. They require the "original datagram" field to 505 contain exactly 128 octets and are insensitive to the length 506 attribute that is associated with the "original datagram" field. 507 Non-compliant applications were produced between 1999 and the time of 508 publication of this memo. 510 Compliant applications comply fully with the specifications of this 511 document. 513 In order to demonstrate backwards compatibility, Table 1 describes 514 how members of each application category would parse each category of 515 ICMP message. 517 +----------------+----------------+----------------+----------------+ 518 | | No Extensions | Non-compliant | Compliant | 519 | | | Extensions | Extensions | 520 +----------------+----------------+----------------+----------------+ 521 | Classic | - | Section 5.1 | Section 5.1 | 522 | Application | | | | 523 | | | | | 524 | Non-compliant | Section 5.2 | - | Section 5.3 | 525 | Application | | | | 526 | | | | | 527 | Compliant | Section 5.4 | Section 5.5 | - | 528 | Application | | | | 529 +----------------+----------------+----------------+----------------+ 531 Table 1 533 In the table above, cells that contain a dash represent the nominal 534 case and require no explanation. In the following sections, we 535 assume that the ICMP message type is "Time Exceeded". 537 5.1. Classic Application Receives ICMP Message With Extensions 539 When a classic application receives an ICMP message that includes 540 extensions, it will incorrectly interpret those extensions as being 541 part of the "original datagram" field. Fortunately, the extensions 542 are guaranteed to begin at least 128 octets beyond the beginning of 543 the "original datagram" field. So, only those ICMP applications that 544 process the 129th octet of the "original datagram" field will be 545 adversely effected. To date, only two applications falling into this 546 catagory have been identified and the degree to which they are 547 effected is minimal. 549 Some TCP stacks, when they receive an ICMP message, verify the 550 checksum in the original datagram field [I-D.ietf-tcpm-icmp-attacks]. 551 If the checksum is incorrect, the TCP stack discards the ICMP message 552 for security reasons. If the trailing octets of the original 553 datagram field are overwritten by ICMP extensions, the TCP stack will 554 discard an ICMP message that it would not otherwise have discarded. 555 The impact of this issue is considered to be minimal because many 556 ICMP messages are discarded for other reasons (e.g., ICMP filtering, 557 network congestion, checksum was incorrect because original datagram 558 field was truncated.) 560 Another theoretically possible, but highly improbably scenario occurs 561 when ICMP extensions overwrite the portion of the original datagram 562 field that represents the TCP header, causing the TCP stack to 563 operate upon the wrong TCP connection. This scenario is highly 564 unlikely because it occurs only when the TCP header appears at or 565 beyond the 128th octet of the original datagram field and then only 566 when the extensions approximate a valid TCP header. 568 5.2. Non-compliant Application Receives ICMP Message With No Extensions 570 When a non-compliant ICMPv4 application receives a message that 571 contains no extensions, the application examines the total length of 572 the ICMPv4 message. If the total ICMPv4 message length is less than 573 the length of its IP header plus 144 octets, the application 574 correctly determines that the message does not contain any 575 extensions. 577 The 144 octet sum is derived from 8 octets for the first two words of 578 the ICMPv4 Time Exceeded message, 128 octets for the "original 579 datagram" field, 4 octets for the ICMP Extension Header and 4 octets 580 for a single ICMP Object header. All of these octets would be 581 required if extensions were present. 583 If the ICMPv4 payload contains 144 octets or more, the application 584 must examine the 137th octet to determine whether it represents a 585 valid ICMPv4 Extension Header. In order to represent a valid 586 Extension Header, it must contain a valid version number and 587 checksum. If it does not contain a valid version number and 588 checksum, the application correctly determines that the message does 589 not contain any extensions. 591 Non-compliant applications assume that the ICMPv4 Extension Structure 592 begins on the 137th octet of the Time Exceeded message, after a 128 593 octet field representing the padded "original datagram" message. 595 It is possible that a non-compliant application will parse an ICMPv4 596 message incorrectly under the following conditions: 598 - the message does not contain extensions 600 - the original datagram field contains 144 octets or more 602 - selected octets of the original datagram field represent the 603 correct values for an extension header version number and checksum 605 Although this is possible, it is very unlikely. 607 A similar analysis can be performed for ICMPv6. However, the numeric 608 constants would change as appropriate. 610 5.3. Non-compliant Application Receives ICMP Message With Compliant 611 Extensions 613 When a non-compliant application receives a message that contains 614 compliant ICMP extensions, it will parse those extensions correctly 615 only if the "original datagram" field contains exactly 128 octets. 616 This is because non-compliant applications are insensitive to the 617 length attribute that is associated with the "original datagram" 618 field. (They assume its value to be 128.) 620 Provided that the entire ICMP message does not exceed the minimum 621 reassembly buffer size (576 octets for ICMPv4 or 1280 octets for 622 ICMPv6), there is no upper limit upon the length of the "original 623 datagram" field. However, each implementation will decide how many 624 octets to include. Those wishing to be backward compatible with non- 625 compliant TRACEROUTE implementations will include exactly 128 octets. 626 Those not requiring compatibility with non-compliant TRACEROUTE 627 applications may include more octets. 629 5.4. Compliant Application Receives ICMP Message with No Extensions 631 When a compliant application receives an ICMP message, it examines 632 the length attribute that is associated with the "original datagram" 633 field. If the length attribute is zero, the compliant application 634 MUST determine that the message contains no extensions. 636 5.5. Compliant Application Receives ICMP Message with Non-compliant 637 Extensions 639 When a compliant application receives an ICMP message, it examines 640 the length attribute that is associated with the "original datagram" 641 field. If the length attribute is zero, the compliant application 642 MUST determine that the message contains no extensions. In this 643 case, that determination is technically correct, but not backwards 644 compatible with the non-compliant implementation that originated the 645 ICMP message. 647 So, to ease transition yet encourage compliant implementation, 648 compliant TRACEROUTE implementations MUST include a non-default 649 operation mode to also interpret non-compliant responses. 650 Specifically, when a TRACEROUTE application operating in non- 651 compliant mode receives a sufficiently long ICMP message that does 652 not specify a length attribute, it will parse for a valid extension 653 header at a fixed location, assuming a 128 octet "original datagram" 654 field. If the application detects a valid version and checksum, it 655 will treat the octets that follow as an extension structure. 657 6. Interaction with Network Address Translation 659 The ICMP extensions defined in this memo do not interfere with 660 Network Address Translation. [RFC3022] permits traditional NAT 661 devices to modify selected fields within ICMP messages. These fields 662 include the "original datagram" field mentioned above. However, if a 663 NAT device modifies the "original datagram" field, it should modify 664 only the leading octets of that field which represent the outermost 665 IP header. Because the outermost IP header is guaranteed to be 666 contained by the first 128 octets of the "original datagram" field, 667 ICMP extensions and NAT will not interfere with one another. 669 It is conceivable that a NAT implementation might overstep the 670 restrictions of RFC 3022 and overwrite the length attribute specified 671 by this memo. If a NAT implementation were to overwrite the length 672 attribute with zeros, the resulting packet will be indistinguishable 673 from a packet that was generated by a non-compliant ICMP 674 implementation. See Section 5.5 for packet details and a discussion 675 of backwards compatibility. 677 7. The ICMP Extension Structure 679 This memo proposes an optional ICMP Extension Structure that can be 680 appended to the ICMP messages referenced in Section 4.6 of this 681 document. 683 The Extension Structure contains exactly one Extension Header 684 followed by one or more objects. Having received an ICMP message 685 with extensions, application software MAY process selected objects 686 while ignoring others. The presence of an unrecognized object does 687 not imply that an ICMP message is malformed. 689 As stated above, the total length of the ICMP message, including 690 extensions, MUST NOT exceed the minimum reassembly buffer size. 691 Figure 6 depicts the ICMP Extension Header. 693 0 1 2 3 694 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 695 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 696 |Version| (Reserved) | Checksum | 697 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 699 Figure 6: ICMP Extension Header 701 The fields of the ICMP Extension Header are as follows: 703 Version: 4 bits 705 ICMP extension version number. This is version 2. 707 Reserved: 12 bits 709 Must be set to 0. 711 Checksum: 16 bits 713 The one's complement of the one's complement sum of the data 714 structure, with the checksum field replaced by zero for the 715 purpose of computing the checksum. An all-zero value means that 716 no checksum was transmitted. See Section 5.2 for a description of 717 how this field is used. 719 8. ICMP Extension Objects 721 Each extension object contains one or more 32-bit words, representing 722 an object header and payload. All object headers share a common 723 format. Figure 7 depicts the Object Header and payload. 725 0 1 2 3 726 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 727 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 728 | Length | Class-Num | C-Type | 729 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 730 | | 731 | // (Object payload) // | 732 | | 733 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 735 Figure 7: Object Header and Payload 737 An object header has the following fields: 739 Length: 16 bits 741 Length of the object, measured in octets, including the object 742 header and object payload. 744 Class-Num: 8 bits 745 Identifies object class. 747 C-Type: 8 bits 749 Identifies object sub-type. 751 9. Security Considerations 753 Upon receipt of an ICMP message, application software must check it 754 for syntactic correctness. The extension checksum must be verified. 755 Improperly specified length attributes and other syntax problems may 756 result in buffer overruns. 758 This memo does not define the conditions under which a router sends 759 an ICMP message. Therefore, it does not expose routers to any new 760 denial of service attacks. Routers may need to limit the rate at 761 which ICMP messages are sent. 763 10. IANA Considerations 765 The ICMP Extension Object header contains two 8-bit fields: The 766 Class-Num identifies the object class, and the C-Type identifies the 767 class sub-type. Sub-type values are defined relative to a specific 768 object class value, and are defined per-class. 770 IANA should establish a registry of ICMP extension objects classes 771 and class sub-types. There are no values assigned within this 772 document to maintain. Object classes 0xF7 - 0xFF are reserved for 773 private use. Object class values are assignable on a first-come- 774 first-serve. The policy for assigning sub-type values should be 775 defined in the document defining new class values. 777 11. Acknowledgments 779 Thanks to Mark Doll, Fernando Gont, Joe Touch, Christian Voiqt and 780 Sharon Chrisholm for their comments regarding this draft. 782 12. Testing 784 [RFC Editor: Please remove this section before publication] 786 In order to demonstrate that the ICMP extensions defined herein do 787 not adversely impact classic ICMP applications, the authors performed 788 the following experiments: 790 Experiment 1: Ping a device that sends non-compliant ICMP 791 extensions. Also ping through a devices that sends non-compliant 792 ICMP extensions. 794 Experiment 2: Traceroute to device that sends non-compliant ICMP 795 extensions. Also traceroute through a devices that sends non- 796 compliant ICMP extensions. 798 Experiment 3: Cause a TCP implementation to receive a non- 799 compliant ICMP messages with extensions that is classified as a 800 soft error. 802 Experiment 4: Cause a TCP implementation to receive a non- 803 compliant ICMP messages with extensions that is classified as a 804 hard error. 806 As defined in Section 5, a non-compliant ICMP extension is identical 807 to a fully compliant extension in every way excpet that it lacks a 808 length attribute. 810 In all cases, the classic application behaved as if the ICMP 811 extension was not present. 813 Classic applications ran under the following operating systems: 815 Windows XP 817 Macintosh OS X, OS 9 819 Solaris 821 Linux 823 Cisco IOS 825 Cisco IOS XR 827 Juniper JUNOS 829 13. References 831 13.1. Normative References 833 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 834 RFC 792, September 1981. 836 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 837 November 1990. 839 [RFC1812] Baker, F., "Requirements for IP Version 4 Routers", 840 RFC 1812, June 1995. 842 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 843 Requirement Levels", BCP 14, RFC 2119, March 1997. 845 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 846 Message Protocol (ICMPv6) for the Internet Protocol 847 Version 6 (IPv6) Specification", RFC 4443, March 2006. 849 13.2. Informative References 851 [I-D.atlas-icmp-unnumbered] 852 Atlas, A., "ICMP Extensions for Unnumbered Interfaces", 853 draft-atlas-icmp-unnumbered-01 (work in progress), 854 March 2006. 856 [I-D.ietf-mpls-icmp] 857 Bonica, R., "ICMP Extensions for MultiProtocol Label 858 Switching", draft-ietf-mpls-icmp-07 (work in progress), 859 December 2006. 861 [I-D.ietf-tcpm-icmp-attacks] 862 Gont, F., "ICMP attacks against TCP", 863 draft-ietf-tcpm-icmp-attacks-01 (work in progress), 864 October 2006. 866 [I-D.shen-icmp-routing-inst] 867 Shen, N. and E. Chen, "ICMP Extensions for Routing 868 Instances", draft-shen-icmp-routing-inst-00 (work in 869 progress), November 2006. 871 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 872 Address Translator (Traditional NAT)", RFC 3022, 873 January 2001. 875 Authors' Addresses 877 Ronald P. Bonica 878 Juniper Networks 879 2251 Corporate Park Drive 880 Herndon, VA 20171 881 US 883 Email: rbonica@juniper.net 885 Der-Hwa Gan 886 Juniper Networks 887 1194 N. Mathilda Ave. 888 Sunnyvale, CA 94089 889 US 891 Email: dhg@juniper.net 893 Pekka Nikander 894 Ericsson Research Nomadic Lab 895 JORVAS FIN-02420 896 Finland 898 Email: pekka.nikander@nomadiclab.com 900 Daniel C. Tappan 901 Cisco Systems, Inc. 902 250 Apollo Drive 903 Chelmsford, MA 01824 904 US 906 Email: dan.tappan@gmail.com 908 Carlos Pignataro 909 Cisco Systems, Inc. 910 7025 Kit Creek Road 911 Research Triangle Park, N.C. 27709 912 US 914 Email: cpignata@cisco.com 916 Full Copyright Statement 918 Copyright (C) The IETF Trust (2007). 920 This document is subject to the rights, licenses and restrictions 921 contained in BCP 78, and except as set forth therein, the authors 922 retain all their rights. 924 This document and the information contained herein are provided on an 925 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 926 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 927 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 928 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 929 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 930 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 932 Intellectual Property 934 The IETF takes no position regarding the validity or scope of any 935 Intellectual Property Rights or other rights that might be claimed to 936 pertain to the implementation or use of the technology described in 937 this document or the extent to which any license under such rights 938 might or might not be available; nor does it represent that it has 939 made any independent effort to identify any such rights. Information 940 on the procedures with respect to rights in RFC documents can be 941 found in BCP 78 and BCP 79. 943 Copies of IPR disclosures made to the IETF Secretariat and any 944 assurances of licenses to be made available, or the result of an 945 attempt made to obtain a general license or permission for the use of 946 such proprietary rights by implementers or users of this 947 specification can be obtained from the IETF on-line IPR repository at 948 http://www.ietf.org/ipr. 950 The IETF invites any interested party to bring to its attention any 951 copyrights, patents or patent applications, or other proprietary 952 rights that may cover technology that may be required to implement 953 this standard. Please address the information to the IETF at 954 ietf-ipr@ietf.org. 956 Acknowledgment 958 Funding for the RFC Editor function is provided by the IETF 959 Administrative Support Activity (IASA).