idnits 2.17.1 draft-ietf-behave-nat-icmp-12.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? -- It seems you're using the 'non-IETF stream' Licence Notice instead 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 and authors Copyright Line does not match the current year == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- 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 07, 2009) is 5578 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (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 (ref. 'NAT-TRAD') ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) == Outdated reference: A later version (-12) exists of draft-ietf-tcpm-icmp-attacks-04 -- Obsolete informational reference (is this intentional?): RFC 4008 (ref. 'NAT-MIB') (Obsoleted by RFC 7658) Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Intended Status: Best Current Practice 3 BEHAVE WG P. Srisuresh 4 Internet Draft Kazeon Systems 5 Expires: July 07, 2009 B. Ford 6 MPI-SWS 7 S. Sivakumar 8 Cisco Systems 9 S. Guha 10 Cornell U. 11 January 07, 2009 13 NAT Behavioral Requirements for ICMP protocol 14 16 Status of this Memo 18 This Internet-Draft is submitted to IETF in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 Abstract 39 This document specifies the behavioral properties required of the 40 Network Address Translator (NAT) devices in conjunction with the 41 Internet Control Message Protocol (ICMP). The objective of this 42 memo is to make NAT devices more predictable and compatible with 43 diverse application protocols that traverse the devices. Companion 44 documents provide behavioral recommendations specific to TCP, UDP 45 and other protocols. 47 Table of Contents 49 1. Introduction and Scope ....................................... 50 2. Terminology .................................................. 51 3. ICMP Query Handling .......................................... 52 3.1. ICMP Query Mapping ...................................... 53 3.2. ICMP Query Session Timeouts ............................. 54 4. ICMP Error Forwarding ........................................ 55 4.1. ICMP Error Payload Validation ........................... 56 4.2. ICMP Error Packet Translation ........................... 57 4.2.1. ICMP Error Packet Received from External Realm .... 58 4.2.2. ICMP Error Packet Received from Private Realm ..... 59 4.3. NAT Sessions Pertaining to ICMP Error Payload ........... 60 5. Hairpinning Support for ICMP packets ......................... 61 6. Rejection of Outbound Flows Disallowed by NAT ................ 62 7. Conformance to RFC 1812 ...................................... 63 7.1. IP packet fragmentation ................................. 64 7.1.1. Generating "Packet Too Big" ICMP Error Message .... 65 7.1.2. Forwarding "Packet Too Big" ICMP Error Message .... 66 7.2. Time Exceeded Message ................................... 67 7.3. Source Route Options .................................... 68 7.4. Address Mask Request/Reply Messages ..................... 69 7.5. Parameter Problem Message ............................... 70 7.6. Router Advertisement and Solicitations .................. 71 7.7. DS Field Usage .......................................... 72 8. Non-QueryError ICMP Messages ................................. 73 9. Summary of Requirements ...................................... 74 10. Security Considerations ...................................... 75 11. IANA Considerations .......................................... 76 12. Acknowledgements ............................................. 78 1. Introduction and Scope 80 As pointed out in RFC 3424 [UNSAF], NAT implementations vary 81 widely in terms of how they handle different traffic. The purpose 82 of this document is to define a specific set of requirements for NAT 83 behavior with regard to ICMP messages. The objective is to reduce 84 the unpredictability and brittleness the NAT devices (NATs) 85 introduce. This document is an adjunct to [BEH-UDP], [BEH-TCP], and 86 other protocol-specific BEHAVE document(s) in the future which 87 define requirements for NATs when handling protocol-specific 88 traffic. 90 The requirements of this specification apply to Traditional NATs as 91 described in [NAT-TRAD]. Traditional NAT has two variations, namely, 92 Basic NAT and Network Address Port Translator (NAPT). Of these, NAPT 93 is by far the most commonly deployed NAT device. NAPT allows 94 multiple private hosts to share a single public IP address 95 simultaneously. 97 This document only covers the ICMP aspects of NAT traversal, 98 specifically the traversal of ICMP Query messages and ICMP Error 99 messages. Traditional NAT inherently mandates firewall-like 100 filtering behavior [BEH-UDP]. However, firewall functionality in 101 general or any other middlebox functionality is out of the scope 102 of this document. 104 In some cases, ICMP Message traversal behavior on a NAT device may 105 be overridden by local administrative policies. Some administrators 106 may choose to entirely prohibit forwarding of ICMP Error messages 107 across a NAT device. Some others may choose to prohibit ICMP Query 108 based applications across a NAT device. These are local policies 109 and not within the scope of this document. For this reason, some 110 of the ICMP requirements listed in the document are preceded with a 111 constraint of local policy permitting. 113 This document focuses strictly on the behavior of the NAT device, 114 and not on the behavior of applications that traverse NATs. 115 Application designers may refer [BEH-APP] and [ICE] for 116 recommendations and guidelines on how to make applications work 117 robustly over NATs that follow the requirements specified here and 118 the adjunct protocol-specific BEHAVE documents. 120 Per [RFC1812], ICMP is a control protocol that is considered to be 121 an integral part of IP, although it is architecturally layered upon 122 IP - it uses IP to carry its data end-to-end. As such, many of the 123 ICMP behavioral requirements discussed in this document apply to all 124 IP protocols. 126 In case a requirement in this document conflicts with 127 protocol-specific BEHAVE requirement(s), protocol-specific BEHAVE 128 documents will take precedence. The authors are not aware of any 129 conflicts between this and any other IETF document at the time of 130 this writing. 132 Section 2 describes the terminology used throughout the document. 133 Sections 3 is focused on requirements concerning ICMP Query based 134 applications traversing a NAT device. Sections 4 and 5 describe 135 requirements concerning ICMP Error messages traversing a NAT 136 device. Sections 6 and 7 describe requirements concerning ICMP Error 137 messages generated by a NAT device. Section 8 summarizes all the 138 requirements in one place. Section 9 has a discussion on security 139 considerations. 141 2. Terminology 143 Definitions for majority of the NAT terms used throughout the 144 document may be found in [NAT-TERM] and [BEH-UDP]. 146 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 147 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 148 document are to be interpreted as described in RFC 2119 [RFC2119]. 150 The term "Realm" is adapted from [NAT-TERM] and is defined as 151 follows. "Realm" is often interchanged for "network domain" or simply 152 "network" throughout the document. 154 Address realm or Realm - An address realm is a network domain in 155 which the network addresses are uniquely assigned to entities such 156 that datagrams can be routed to them. Routing protocols used within 157 the network domain are responsible for finding routes to entities 158 given their network addresses. Note that this document is limited to 159 describing NAT in IPv4 environment and does not address the use of 160 NAT in other types of environments (e.g., IPV6 environment). 162 The term "NAT Session" is adapted from [NAT-MIB] and is defined as 163 follows. 165 NAT Session - A NAT session is an association between a session as 166 seen in the private realm and a session as seen in the public realm, 167 by virtue of NAT translation. If a session in the private realm were 168 to be represented as (PrivateSrcAddr, PrivateDstAddr, 169 TransportProtocol, PrivateSrcPort, PrivateDstPort) and the same 170 session in the public realm were to be represented as (PublicSrcAddr, 171 PublicDstAddr, TransportProtocol, PublicSrcPort, PublicDstPort), the 172 NAT session will provide the translation glue between the two session 173 representations. NAT sessions in the document are restricted to 174 sessions based on TCP and UDP only. In the future, NAT sessions may 175 be extended to be based on other transport protocols such as SCTP, 176 UDP-lite and DCCP. 178 ICMP Message Classification - Section 3.2.2 of [RFC1122] and Section 179 4.3.1 of [RFC1812] broadly group ICMP messages into two main 180 categories, namely "ICMP Query" messages and "ICMP Error" messages. 181 All ICMP Error messages listed in RFC1122 and RFC1812 contain part 182 of the internet datagram that elicited the ICMP error. All the ICMP 183 Query messages listed in RFC1122 and RFC1812 contain an "Identifier" 184 field, which is referred to in this document as "Query Identifier". 185 There are however ICMP messages that do not fall into any of these 186 two categories. We refer to them as "Non-QueryError ICMP Messages". 187 All three ICMP message classes are described as follows: 189 o ICMP Query Messages - ICMP Query messages are characterized by an 190 Identifier field in the ICMP header. The Identifier field used by 191 the ICMP Query messages is also referred as "Query Identifier" or 192 "Query Id", for short throughout the document. A Query Id is used 193 by Query senders and responders as the equivalent of a TCP/UDP 194 port to identify an ICMP Query session. ICMP Query Messages 195 include ICMP Messages defined after RFC1122 or RFC1812, as for 196 example Domain Name Request/Reply ICMP messages defined in 197 RFC1788, as they include request/response pairs and contain an 198 "Identifier" field. 200 o ICMP Error Messages - ICMP Error messages provide signaling for 201 IP. All ICMP Error messages are characterized by the fact that 202 they embed the original datagram that triggered the ICMP Error 203 message. The original datagram embedded within the ICMP Error 204 payload is also referred as "Embedded packet", throughout the 205 document. Unlike ICMP Query messages, ICMP Error messages do not 206 have a Query Id in the ICMP header. 208 o Non-QueryError ICMP Messages - ICMP messages that do not fall 209 under either of the above two classes are referred to as 210 "Non-QueryError ICMP Messages" throughout the document. For 211 example, Router Discovery ICMP messages ([RFC1256]) are 212 "request/response" type ICMP messages. However, they are not 213 characterized as ICMP Query messages in this document as they 214 do not have an "Identifier" field within the messages. Likewise, 215 there are other ICMP messages defined in [RFC4065] that do not 216 fall in either of ICMP Query or ICMP Error message categories, 217 but will be referred as Non-QueryError ICMP messages. 219 The reason for categorizing ICMP messages for a NAT behavioral 220 properties is because each category has different characteristics 221 used for mapping (i.e., the Query Id and the Embedded datagram), 222 which leaves the Non-QueryError ICMP messages in a separate 223 distinctive group. 225 3. ICMP Query Handling 227 This section lists the behavioral requirements for a NAT device 228 when processing ICMP Query packets. The following sub sections 229 discuss requirements specific to ICMP Query handling in detail. 231 3.1. ICMP Query Mapping 233 Unless local policy explicitly overrides, a NAT device MUST permit 234 ICMP Queries and their associated responses, when the Query is 235 initiated from a private host to the external hosts. ICMP Query 236 mapping by NAT devices is necessary for current ICMP Query based 237 applications to work. This entails a NAT device to transparently 238 forward ICMP Query packets initiated from the nodes behind NAT 239 and the responses to these Query packets in the opposite 240 direction. As specified in [NAT-TRAD], this requires translating 241 the IP header. A NAPT device further translates the ICMP Query Id 242 and the associated checksum in the ICMP header prior to forwarding. 244 NAT mapping of ICMP Query Identifiers SHOULD be external host 245 independent. Say, an internal host A sent an ICMP Query out to an 246 external host B using Query Id X. And, say, the NAT assigned this 247 an external mapping of Query Id X' on the NAT's public address. If 248 host A reused the Query Id X to send ICMP Queries to the same or 249 different external host, the NAT device SHOULD reuse the same Query 250 Id mapping (i.e., map private host's Query Id X to Query Id X' on 251 NAT's public IP address) instead of assigning a different mapping. 252 This is similar to the "endpoint independent mapping" requirement 253 specified in the TCP and UDP requirement documents ([BEH-UDP], 254 [BEH-TCP]). 256 Below is justification for making the endpoint independent mapping 257 for ICMP Query Id a SHOULD [RFC2119] requirement. ICMP Ping 258 ([RFC1470]) and ICMP traceroute ([MS-TRCRT]) are two most commonly 259 known legacy applications built on top of ICMP Query messages. 260 Neither of these applications require the ICMP Query Id to be 261 retained across different sessions with external hosts. But, that 262 may not be case with future applications. In the future, when an 263 end host application reuses the same Query Identifier in sessions 264 with different target hosts, the end host application might require 265 that the endpoint identity (i.e., the tuple of IP address and Query 266 Identifier) appears the same across all its target hosts. Such a 267 requirement will be valid to make in an IP network without NAT 268 devices. When NAT devices enforce endpoint mapping that is external 269 host independent, the above assumption will be valid to make even 270 in a world with NAT devices. Given the dichotomy between legacy 271 applications not requiring endpoint independent mapping and future 272 applications that might require it, the requirement level is kept 273 at SHOULD [RFC2119]. 275 REQ-1: Unless local policy explicitly overrides, a NAT device MUST 276 permit ICMP Queries and their associated responses, when the Query 277 is initiated from a private host to the external hosts. 278 a) NAT mapping of ICMP Query Identifiers SHOULD be external host 279 independent. 281 3.2. ICMP Query Session Timeouts 283 NATs maintain a mapping timeout for the ICMP Queries that traverse 284 them. The mapping timeout is the time a mapping will stay active 285 without packets traversing the NAT. There is great variation in the 286 values used by different NATs. The ICMP Query session timeout 287 requirement is necessary for current ICMP Query applications to 288 work. Query response times can vary. ICMP Query based applications 289 are primarily request/response driven. 291 Ideally, the timeout should be set to Maximum Round Trip Time 292 (Maximum RTT). For the purposes of constraining the maximum RTT, the 293 Maximum Segment Lifetime (MSL), defined in [RFC793] could be 294 considered a guideline to set packet lifetime. Per [RFC793], MSL is 295 the maximum amount of time a TCP segment can exist in a network 296 before being delivered to the intended recipient. This is the maximum 297 duration an IP packet can be assumed to take to reach the intended 298 destination node before declaring that the packet will no longer be 299 delivered. For an application initiating ICMP Query message and 300 waiting for a response for the Query, the Maximum RTT could in 301 practice be constrained to be sum total of MSL for the Query message 302 and MSL for the response message. In other words, Maximum RTT could 303 be constrained to no more than 2x MSL. The recommended value for MSL 304 in [RFC793] is 120 seconds, even though several implementations set 305 this to 60 seconds or 30 seconds. When MSL is 120 seconds, the 306 Maximum RTT (2x MSL) would be 240 seconds. 308 In practice, ICMP Ping ([RFC1470]) and ICMP traceroute ([MS-TRCRT]), 309 the two most commonly known legacy applications built on top of ICMP 310 Query messages take less than 10 seconds to complete a round trip, 311 when the target node is operational on the network. 313 Setting the ICMP NAT session timeout to a very large duration (say, 314 240 seconds) could potentially tie up precious NAT resources such as 315 Query mappings and NAT Sessions for the whole duration. On the other 316 hand, setting the timeout very low can result in premature freeing 317 of NAT resources and applications failing to complete gracefully. 318 The ICMP Query session timeout needs to be a balance between the two 319 extremes. 60 seconds timeout is a balance between the two extremes. 320 An ICMP Query session timer MUST NOT expire in less than 60 seconds. 321 It is RECOMMENDED that the ICMP Query session timer be made 322 configurable. 324 REQ-2: An ICMP Query session timer MUST NOT expire in less than 60 325 seconds. 326 a) It is RECOMMENDED that the ICMP Query session timer be made 327 configurable. 329 4. ICMP Error Forwarding 331 Many applications make use of ICMP Error messages from end hosts and 332 intermediate devices to shorten application timeouts. Some 333 applications will not operate correctly without the receipt of ICMP 334 Error messages. The following sub-sections discuss the requirements 335 a NAT device must conform to in order to ensure reliable forwarding. 337 4.1. ICMP Error Payload Validation 339 ICMP Error message checksum covers the entire ICMP message, including 340 the payload. When an ICMP Error packet is received, if the ICMP 341 checksum fails to validate, the NAT SHOULD silently drop the ICMP 342 Error packet. This is because NAT uses the embedded IP and transport 343 headers for forwarding and translating the ICMP Error message 344 (described in section 4.2). When the ICMP checksum is invalid, the 345 embedded IP and transport headers, which are covered by the ICMP 346 checksum, are also suspect. 348 [RFC1812] and [RFC1122] require a router or an end host that receives 349 an IP packet with invalid IP header checksum to silently drop the IP 350 packet. As such, end hosts and routers do not generate an ICMP Error 351 message in response to IP packets with invalid IP header checksum. 352 For this reason, If the IP checksum of the embedded packet within an 353 ICMP Error message fails to validate, the NAT SHOULD silently 354 drop the Error packet. 356 When the IP packet embedded within the ICMP Error message includes IP 357 options, the NAT device must not assume that the transport header of 358 the embedded packet is at a fixed offset (as would be the case when 359 there are no IP options associated with the packet) from the start of 360 the embedded packet. Specifically, if the embedded packet includes IP 361 options, the NAT device MUST traverse past the IP options to locate 362 the start of transport header for the embedded packet. 364 It is possible to compute the transport checksum of the embedded 365 packet within an ICMP Error message when the ICMP Error message 366 contains the entire transport segment. However, ICMP Error messages 367 do not contain the entire transport segment in many cases. This is 368 because [ICMP] stipulates that an ICMP Error message should embed 369 IP header and only a minimum of 64 bits of the IP payload. Even 370 though, section 4.3.2.3 of [RFC1812] recommends an ICMP Error 371 originator to include as much of the original packet as possible 372 in the payload, the length of the resulting ICMP datagram cannot 373 exceed 576 bytes. ICMP Error originators truncate IP packets that 374 do not fit within the stipulations. 376 A NAT device SHOULD NOT validate the transport checksum of the 377 embedded packet within an ICMP Error message, even when it is 378 possible to do so. This is because NAT dropping an ICMP Error 379 message due to invalid transport checksum will make it harder for 380 end hosts to receive error reporting for certain types of 381 corruption. End-to-end validation of ICMP Error messages is best 382 left to end hosts. Many newer revision end host TCP/IP stacks 383 implement the improvements in [TCP-SOFT] and do not accept ICMP 384 Error messages with a mismatched IP or TCP checksum in the 385 embedded packet, if the embedded datagram contains full IP packet 386 and the TCP checksum can be calculated. 388 In the case the ICMP Error payload includes ICMP extensions 389 ([ICMP-EXT]), the NAT device MUST exclude the optional zero-padding 390 and the ICMP extensions when evaluating transport checksum for the 391 embedded packet. Readers are urged to refer [ICMP-EXT] for 392 identifying the presence of ICMP extensions in an ICMP message. 394 REQ-3: When an ICMP Error packet is received, if the ICMP checksum 395 fails to validate, the NAT SHOULD silently drop the ICMP Error 396 packet. If the ICMP checksum is valid, do the following. 397 a) If the IP checksum of the embedded packet fails to validate, the 398 NAT SHOULD silently drop the Error packet; and 399 b) If the embedded packet includes IP options, the NAT device MUST 400 traverse past the IP options to locate the start of transport 401 header for the embedded packet; and 402 c) The NAT device SHOULD NOT validate the transport checksum of the 403 embedded packet within an ICMP Error message, even when it is 404 possible to do so; and 405 d) If the ICMP Error payload contains ICMP extensions([ICMP-EXT]), 406 the NAT device MUST exclude the optional zero-padding and the ICMP 407 extensions when evaluating transport checksum for the embedded 408 packet. 410 4.2. ICMP Error Packet Translation 412 Section 4.3 of [NAT-TRAD] describes the fields of an ICMP Error 413 message that a NAT device translates. In this section, we describe 414 the requirements a NAT device must conform to while performing the 415 translations. Requirements identified in this section are necessary 416 for the current applications to work correctly. 418 Consider the following scenario in figure 1. Say, NAT-xy is a NAT 419 device connecting hosts in private and external networks. 420 Router-x and Host-x are in the external network. Router-y and 421 Host-y are in the private network. The subnets in the external 422 network are routable from the private as well as the external 423 domains. By contrast, the subnets in the private network are only 424 routable within the private domain. When Host-y initiated a session 425 to Host-x, let us say that the NAT device mapped the endpoint on 426 Host-y into Host-y' in the external network. The following 427 subsections describe the processing of ICMP Error messages on the 428 NAT device(NAT-xy), when the NAT device receives an ICMP Error 429 message in response to a packet pertaining to this session. 431 Host-x 432 | 433 ---------------+------------------- 434 | 435 +-------------+ 436 | Router-x | 437 +-------------+ 438 External Network | 439 --------------------+--------+------------------- 440 | ^ 441 | | (Host-y', Host-x) 442 | | 443 +-------------+ 444 | NAT-xy | 445 +-------------+ 446 | 447 Private Network | 448 ----------------+------------+---------------- 449 | 450 +-------------+ 451 | Router-y | 452 +-------------+ 453 | 454 ----------------+-------+-------- 455 | ^ 456 | | (Host-y, Host-x) 457 | | 458 Host-y 460 Figure 1. A Session from a private host traversing a NAT device. 462 4.2.1. ICMP Error Packet Received from External Realm 464 Say, a packet from Host-y to Host-x triggered an ICMP Error message 465 from one of Router-x or Host-x (both of which are in the external 466 domain). Such an ICMP Error packet will have one of Router-x or 467 Host-x as the source IP address and Host-y' as the destination IP 468 address as described in figure 2 below. 470 Host-x 471 | 472 ---------------+------------------- 473 | 474 +-------------+ 475 | Router-x | 476 +-------------+ 477 External Network | 478 --------------------+--------+------------------- 479 | 480 | | ICMP Error Packet to Host-y' 481 | v 482 +-------------+ 483 | NAT-xy | 484 +-------------+ 485 Private Network | 486 ----------------+------------+---------------- 487 | 488 +-------------+ 489 | Router-y | 490 +-------------+ 491 | 492 ----------------+-------+-------- 493 | 494 Host-y 496 Figure 2. ICMP Error Packet Received from External Network 498 When the NAT device receives the ICMP Error packet, the NAT device 499 uses the packet embedded within the ICMP Error message (i.e., 500 the IP packet from Host-y' to Host-x) to look up the NAT Session the 501 embedded packet belongs to. If the NAT device does not have an 502 active mapping for the embedded packet, the NAT SHOULD silently 503 drop the ICMP Error packet. Otherwise, the NAT device MUST use 504 the matching NAT Session to translate the embedded packet. That is, 505 translate the source IP address of the embedded packet (e.g., 506 Host-y' -> Host-y) and transport headers. 508 ICMP Error payload may contain ICMP extension objects ([ICMP-EXT]). 509 NATs are encouraged to support ICMP extension objects. At the time 510 of this writing, the authors are not aware of any standard ICMP 511 extension objects containing realm specific information. 513 The NAT device MUST also use the matching NAT Session to translate 514 the destination IP address in the outer IP header. In the outer 515 header, the source IP address will remain unchanged because the 516 originator of the ICMP Error message (Host-x or Router-x) is in 517 external domain and routable from the private domain. 519 REQ-4: If a NAT device receives an ICMP Error packet from external 520 realm, and the NAT device does not have an active mapping for the 521 embedded payload, the NAT SHOULD silently drop the ICMP Error 522 packet. If the NAT has active mapping for the embedded payload, 523 then the NAT MUST do the following prior to forwarding the packet, 524 unless local policy explicitly overrides. 525 a) Revert the IP and transport headers of the embedded IP packet to 526 their original form, using the matching mapping; and 527 b) Leave the ICMP Error type and code unchanged; and 528 c) Modify the destination IP address of the outer IP header to be 529 same as the source IP address of the embedded packet after 530 translation. 532 4.2.2. ICMP Error Packet Received from Private Realm 534 Now, say, a packet from Host-x to Host-y triggered an ICMP Error 535 message from one of Router-y or Host-y (both of which are in the 536 private domain). Such an ICMP Error packet will have one of 537 Router-y or Host-y as the source IP address and Host-x as the 538 destination IP address as specified in figure 3 below. 540 Host-x 541 | 542 ---------------+------------------- 543 | 544 +-------------+ 545 | Router-x | 546 +-------------+ 547 External Network | 548 --------------------+--------+------------------- 549 | 550 | 551 +-------------+ 552 | NAT-xy | 553 +-------------+ 554 | ^ 555 | | ICMP Error Packet to Host-x 556 Private Network | 557 ----------------+------------+---------------- 558 | 559 +-------------+ 560 | Router-y | 561 +-------------+ 562 | 563 ----------------+-------+-------- 564 | 565 Host-y 567 Figure 3. ICMP Error Packet Received from Private Network 569 When the NAT device receives the ICMP Error packet, the NAT device 570 MUST use the packet embedded within the ICMP Error message (i.e., 571 the IP packet from Host-x to Host-y) to look up the NAT Session the 572 embedded packet belongs to. If the NAT device does not have an 573 active mapping for the embedded packet, the NAT SHOULD silently 574 drop the ICMP Error packet. Otherwise, the NAT device MUST use 575 the matching NAT Session to translate the embedded packet. 577 ICMP Error payload may contain ICMP extension objects ([ICMP-EXT]). 578 NATs are encouraged to support ICMP extension objects. At the time 579 of this writing, the authors are not aware of any standard ICMP 580 extension objects containing realm specific information. 582 In the outer header, the destination IP address will remain 583 unchanged, as the IP addresses for Host-x is already in the external 584 domain. If the ICMP Error message is generated by Host-y, the NAT 585 device must simply use the NAT Session to translate the source IP 586 address Host-y to Host-y'. If the ICMP Error message is originated 587 by the intermediate node Router-y, translation of the source IP 588 address varies depending on whether Basic NAT or NAPT function 589 ([NAT-TRAD]) is enforced by the NAT device. A NAT device enforcing 590 Basic NAT function has a pool of public IP addresses and enforces 591 address mapping (which is different from the endpoint mapping 592 enforced by NAPT) when a private node initiates an outgoing session 593 via the NAT device. So, if the NAT device has active mapping for 594 the IP address of the intermediate node Router-y, the NAT device 595 MUST translate the source IP address of the ICMP Error packet with 596 the public IP address in the mapping. In all other cases, the NAT 597 device MUST simply use its own IP address in the external domain 598 to translate the source IP address. 600 REQ-5: If a NAT device receives an ICMP Error packet from private 601 realm, and the NAT does not have an active mapping for the embedded 602 payload, the NAT SHOULD silently drop the ICMP Error packet. If the 603 NAT has active mapping for the embedded payload, then the NAT MUST 604 do the following prior to forwarding the packet, Unless local 605 policy explicitly overrides. 606 a) Revert the IP and transport headers of the embedded 607 IP packet to their original form, using the matching mapping; and 608 b) Leave the ICMP Error type and code unchanged; and 609 c) If the NAT enforces Basic NAT function ([NAT-TRAD]), and the NAT 610 has active mapping for the IP address that sent the ICMP Error, 611 translate the source IP address of the ICMP Error packet with the 612 public IP address in the mapping. In all other cases, translate the 613 source IP address of the ICMP Error packet with its own public IP 614 address. 616 4.3. NAT Sessions Pertaining to ICMP Error Payload 618 While processing an ICMP Error packet pertaining to an ICMP Query 619 or Query response message, a NAT device MUST NOT refresh or delete 620 the NAT Session that pertains to the embedded payload within the 621 ICMP Error packet. This is in spite of the fact that the NAT device 622 uses the NAT Session to translate the embedded payload. This ensures 623 that the NAT Session will not be modified if someone is able to 624 spoof ICMP Error messages for the session. [ICMP-ATK] lists a number 625 of potential ICMP attacks that may be attempted by malicious users 626 on the network. This requirement is necessary for current 627 applications to work correctly. 629 REQ-6: While processing an ICMP Error packet pertaining to an ICMP 630 Query or Query response message, a NAT device MUST NOT refresh or 631 delete the NAT Session that pertains to the embedded payload within 632 the ICMP Error packet. 634 5. Hairpinning Support for ICMP packets 636 [BEH-UDP] and [BEH-TCP] mandate support for hairpinning for UDP and 637 TCP sessions respectively on NAT devices. A NAT device needs to 638 support hairpinning for ICMP Query sessions as well. Specifically, 639 NAT devices enforcing Basic NAT ([NAT-TRAD]) MUST support the 640 traversal of hairpinned ICMP Query sessions. Say, for example, 641 individual private hosts register their NAT assigned external IP 642 address with a rendezvous server. Other hosts that wish to initiate 643 ICMP Query sessions to the registered hosts might do so using the 644 public address registered with the Rendezvous server. For this 645 reason, Basic NAT devices are required to support the traversal of 646 hairpinned ICMP Query sessions. This requirement is necessary for 647 current applications to work correctly. 649 Packets belonging to any of the hairpinned sessions could in turn 650 trigger ICMP Error messages directed to the source of hairpinned 651 IP packets. Such hairpinned ICMP Error messages will traverse the 652 NAT devices enroute. All NAT devices (i.e., Basic NAT as well as 653 NAPT devices) MUST support the traversal of hairpinned ICMP Error 654 messages. Specifically, the NAT device must translate not only the 655 embedded hairpinned packet, but also the outer IP header that is 656 hairpinned. This requirement is necessary for current applications 657 to work correctly. 659 A hairpinned ICMP Error message is received from a node in private 660 network. As such, the ICMP Error processing requirement specified 661 in Req-5 is applicable in its entirety in processing the ICMP 662 Error message. In addition, the NAT device MUST translate the 663 destination IP address of the outer IP header to be same as the 664 source IP address of the embedded IP packet after the translation. 666 REQ-7: NAT devices enforcing Basic NAT ([NAT-TRAD]) MUST support the 667 traversal of hairpinned ICMP Query sessions. All NAT devices (i.e., 668 Basic NAT as well as NAPT devices) MUST support the traversal of 669 hairpinned ICMP Error messages. 670 a) When forwarding a hairpinned ICMP Error message, the NAT device 671 MUST translate the destination IP address of the outer IP header to 672 be same as the source IP address of the embedded IP packet after 673 the translation. 675 6. Rejection of Outbound Flows Disallowed by NAT 677 A NAT device typically permits all outbound sessions. However, 678 a NAT device may disallow some outbound sessions due to resource 679 constraints or administration considerations. For example, a NAT 680 device may not permit the first packet of a new outbound session, 681 if the NAT device is out of resources (out of addresses or TCP/UDP 682 ports or NAT Session resources) to set up a state for the session, 683 or, the specific session is administratively restricted by the NAT 684 device. 686 When a NAT device is unable to establish a NAT Session for a 687 new transport-layer (TCP, UDP, ICMP, etc.) flow due to resource 688 constraints or administrative restrictions, the NAT device SHOULD 689 send an ICMP destination unreachable message, with a code of 13 690 (Communication administratively prohibited) to the sender, and drop 691 the original packet. This requirement is meant primarily for future 692 use. Current applications do not require this for them to work 693 correctly. The justification for using ICMP code 13 in the ICMP 694 Error message is as follows. Section 5.2.7.1 of [RFC1812] recommends 695 routers to use ICMP code 13 (Communication administratively 696 prohibited) when they administratively filter packets. ICMP code 13 697 is a soft error and is on par with other soft error codes generated 698 in response to transient events such as 'network unreachable' (ICMP 699 type=3, code=0). 701 Some NAT designers opt to never reject an outbound flow. When a 702 NAT runs short of resources, they prefer to steal a resource 703 from an existing NAT Session rather than reject the outbound flow. 704 Such a design choice may appear conformant to REQ-8 below. However, 705 the design choice is in violation of the spirit of both REQ-8 and 706 REQ-2. Such a design choice is strongly discouraged. 708 REQ-8: When a NAT device is unable to establish a NAT Session for a 709 new transport-layer (TCP, UDP, ICMP, etc.) flow due to resource 710 constraints or administrative restrictions, the NAT device SHOULD 711 send an ICMP destination unreachable message, with a code of 13 712 (Communication administratively prohibited) to the sender, and drop 713 the original packet. 715 7. Conformance to RFC 1812 717 This document specifies NATs to have a behavior which is consistent 718 with the way routers handle ICMP messages, as specified in 719 Section 4.3 of [RFC1812]. However, since the publication of 720 [RFC1812], some of its requirements are no longer best current 721 practices. Thus, the following requirements are derived from 722 [RFC1812] and apply to NATs compliant with this specification: 724 REQ-9: A NAT device MAY implement a policy control that prevents 725 ICMP messages being generated toward certain interface(s). 726 Implementation of such a policy control overrides the MUSTs and 727 SHOULDs in REQ-10. 729 REQ-10: Unless overridden by REQ-9's policy, a NAT device needs to 730 support ICMP messages as below, some conforming to Section 4.3 of 731 [RFC1812] and some superseding the requirements of Section 4.3 of 732 [RFC1812]. 733 a. MUST support: 734 1. Destination Unreachable Message, as described in 735 Section 7.1 of this document, 736 2. Time Exceeded Message, as described in Section 7.2 of 737 of this document, 738 3. Echo Request/Reply Messages, as described in REQ-1. 740 b. MAY support: 741 1. Redirect Message, as described in Section 4.3.3.2 of 742 [RFC1812], 743 2. Timestamp and Timestamp Reply Messages, as described in 744 Section 4.3.3.8 of [RFC1812], 745 3. Source Route Options, as described in Section 7.3 of 746 this document, 747 4. Address Mask Request/Reply Message, as described in 748 Section 7.4 of this document, 749 5. Parameter Problem Message, as described in Section 7.5 750 of this document, 751 6. Router Advertisement and Solicitations, as described in 752 Section 7.6 of this document. 754 c. SHOULD NOT support: 755 1. Source Quench Message, as described in Section 4.3.3.3 756 of [RFC1812], 757 2. Information Request/reply, as described in Section 4.3.3.7 758 of [RFC1812]. 760 In addition, a NAT device is RECOMMENDED to conform to the following 761 implementation considerations: 762 d. DS Field Usage, as described in Section 7.7 of this document, 763 e. When Not to Send ICMP Errors, as described in 764 Section 4.3.2.7 of [RFC1812], 765 f. Rate Limiting, as described in Section 4.3.2.8 of [RFC1812]. 767 7.1. IP packet fragmentation 769 Many networking applications (which include TCP as well as UDP based 770 applications) depend on ICMP Error messages from the network to 771 perform end-to-end path MTU discovery [PMTU]. Once path MTU is 772 discovered, an application that chooses to avoid fragmentation may 773 do so by originating IP packets that fit within the Path MTU enroute 774 and setting the DF (Don't Fragment) bit in the IP header, so the 775 intermediate nodes enroute do not fragment the IP packets. The 776 following sub-sections discuss the need for NAT devices to honor the 777 DF bit in the IP header and be able to generate "Packet Too Big" 778 ICMP Error message when they cannot forward the IP packet without 779 fragmentation. Also discussed is the need to seamlessly forward 780 ICMP Error messages generated by other intermediate devices. 782 7.1.1. Generating "Packet Too Big" ICMP Error Message 784 When a router is unable to forward a datagram because it exceeds 785 the MTU of the next-hop network and its Don't Fragment (DF) bit is 786 set, the router is required by [RFC1812] to return an ICMP 787 Destination Unreachable message to the source of the datagram, with 788 the Code indicating "fragmentation needed and DF set". Further, 789 [PMTU] states that the router MUST include the MTU of that next-hop 790 network in the low-order 16 bits of the ICMP header field that is 791 labeled "unused" in the ICMP specification[ICMP]. 793 A NAT device MUST honor the DF bit in the IP header of the packets 794 that transit the device. The NAT device may not be able to forward 795 an IP packet without fragmentation if the MTU on the forwarding 796 interface of the NAT device is not adequate for the IP packet. If 797 the DF bit is set on a transit IP packet and the NAT device cannot 798 forward the packet without fragmentation, the NAT device MUST send 799 a "Packet Too Big" ICMP message (ICMP type 3, Code 4) with the 800 Next-Hop MTU back to the sender and drop the original IP packet. 801 The sender will usually resend after taking the appropriate 802 corrective action. 804 If the DF bit is not set and the MTU on the forwarding interface 805 of the NAT device mandates fragmentation, the NAT device MUST 806 fragment the packet and forward the fragments [RFC1812]. 808 7.1.2. Forwarding "Packet Too Big" ICMP Error Message 810 This is flip side of the argument for the above section. By virtue 811 of the address translation NAT performs, NAT may end up being the 812 recipient of "Packet Too Big" message. 814 When NAT device is the recipient of "Packet Too Big" ICMP message 815 from the network, the NAT device MUST forward the ICMP message back 816 to the intended recipient, pursuant to the previously stated 817 requirements REQ-3, REQ-4 and REQ-5. 819 7.2. Time Exceeded Message 821 A NAT device MUST generate "Time Exceeded" ICMP Error message 822 when it discards a packet due to an expired TTL field. A NAT 823 device MAY have a per-interface option to disable origination 824 of these messages on that interface, but that option MUST 825 default to allowing the messages to be originated. 827 When a NAT device conforms to the above requirement, it ensures 828 that legacy applications such as Traceroute ([RFC1470], 829 [MS-TRCRT]), which depend upon "Time Exceeded" ICMP Error 830 message will continue to operate even as NAT devices are 831 enroute. 833 7.3. Source Route Options 835 A NAT device MAY support modifying IP addresses in source route 836 option so the IP addresses in the source route option are realm 837 relevant. If a NAT device does not support forwarding packets with 838 the source route option, the NAT device SHOULD NOT forward 839 outbound ICMP messages that contain source route option in the 840 outer or inner IP header. This is because such messages could 841 reveal private IP addresses to the external realm. 843 7.4. Address Mask Request/Reply Messages 845 Section 4.3.3.9 of [RFC1812] says an IP router MUST implement 846 support for receiving ICMP Address Mask Request messages and 847 responding with ICMP Address Mask Reply messages. However, several 848 years(more than 13 years at the time of this document) have elapsed 849 since the text in rfc1812 was written. In the intervening time DHCP 850 protocol [DHCP] has replaced the use of address mask request/reply. 851 In the current time, there is rarely any host which does not meet 852 host requirements [RFC1122] and needs a NAT device to support 853 address mask request/reply. 855 For this reason, a NAT device is not required to support this ICMP 856 message. 858 A NAT device MAY support address mask request/reply message. 860 7.5. Parameter Problem Message 862 Section 4.3.3.5 of [RFC1812] says an IP router MUST generate a 863 Parameter Problem message for any error not specifically covered 864 by another ICMP message. However, this message is rarely used in 865 practice in networks where IPv4 NATs are deployed. 867 For this reason, a NAT device is not required to support this ICMP 868 message. 870 A NAT device MAY support parameter problem message. 872 7.6. Router Advertisement and Solicitations 874 Section 4.3.3.10 of [RFC1812] says an IP router MUST support the 875 router part of the ICMP Router Discovery Protocol on all connected 876 networks on which the router supports either IP multicast or IP 877 broadcast addressing. However, this message is rarely used in 878 practice in networks where IPv4 NATs are deployed. 880 For this reason, a NAT device is not required to support this ICMP 881 message. 883 A NAT device MAY support Router Advertisement and Solicitations. 885 7.7. DS Field Usage 887 [RFC1812] refers the TOS octet in the IP header, which contains the 888 TOS and IP precedence fields. However, the TOS and IP precedence 889 fields are no longer in use today. [RFC2474] renamed the TOS octet 890 as the DS field and defined diffserv classes within the DS field. 892 When generating an ICMP message, a NAT device SHOULD copy the 893 diffserv class of the message that causes the sending of the ICMP 894 error message. A NAT device MAY allow configuration of the 895 diffserv class to use for the different types of ICMP messages. 897 8. Non-QueryError ICMP Messages 899 In the preceding sections, ICMP requirements were identified for 900 NAT devices, with a primary focus on ICMP Query and ICMP Error 901 messages, as defined in the Terminology Section (see Section 2). 902 This document provides no guidance on the handling of 903 Non-QueryError ICMP messages by the NAT devices. A NAT MAY drop or 904 appropriately handle Non-QueryError ICMP messages. 906 REQ-11: A NAT MAY drop or appropriately handle Non-QueryError ICMP 907 messages. The semantics of Non-QueryError ICMP messages is defined 908 in Section 2. 910 9. Summary of Requirements 912 Below is a summary of all the requirements. 914 REQ-1: Unless local policy explicitly overrides, a NAT device MUST 915 permit ICMP Queries and their associated responses, when the Query 916 is initiated from a private host to the external hosts. 917 a) NAT mapping of ICMP Query Identifiers SHOULD be external host 918 independent. 920 REQ-2: An ICMP Query session timer MUST NOT expire in less than 60 921 seconds. 922 a) It is RECOMMENDED that the ICMP Query session timer be made 923 configurable. 925 REQ-3: When an ICMP Error packet is received, if the ICMP checksum 926 fails to validate, the NAT SHOULD silently drop the ICMP Error 927 packet. If the ICMP checksum is valid, do the following. 928 a) If the IP checksum of the embedded packet fails to validate, the 929 NAT SHOULD silently drop the Error packet; and 930 b) If the embedded packet includes IP options, the NAT device MUST 931 traverse past the IP options to locate the start of transport 932 header for the embedded packet; and 933 c) The NAT device SHOULD NOT validate the transport checksum of the 934 embedded packet within an ICMP Error message, even when it is 935 possible to do so; and 936 d) If the ICMP Error payload contains ICMP extensions([ICMP-EXT]), 937 the NAT device MUST exclude the optional zero-padding and the ICMP 938 extensions when evaluating transport checksum for the embedded 939 packet. 941 REQ-4: If a NAT device receives an ICMP Error packet from external 942 realm, and the NAT device does not have an active mapping for the 943 embedded payload, the NAT SHOULD silently drop the ICMP Error 944 packet. If the NAT has active mapping for the embedded payload, 945 then the NAT MUST do the following prior to forwarding the packet, 946 unless local policy explicitly overrides. 947 a) Revert the IP and transport headers of the embedded IP packet to 948 their original form, using the matching mapping; and 949 b) Leave the ICMP Error type and code unchanged; and 950 c) Modify the destination IP address of the outer IP header to be 951 same as the source IP address of the embedded packet after 952 translation. 954 REQ-5: If a NAT device receives an ICMP Error packet from private 955 realm, and the NAT does not have an active mapping for the embedded 956 payload, the NAT SHOULD silently drop the ICMP Error packet. If the 957 NAT has active mapping for the embedded payload, then the NAT MUST 958 do the following prior to forwarding the packet, Unless local 959 policy explicitly overrides. 960 a) Revert the IP and transport headers of the embedded 961 IP packet to their original form, using the matching mapping; and 962 b) Leave the ICMP Error type and code unchanged; and 963 c) If the NAT enforces Basic NAT function ([NAT-TRAD]), and the NAT 964 has active mapping for the IP address that sent the ICMP Error, 965 translate the source IP address of the ICMP Error packet with the 966 public IP address in the mapping. In all other cases, translate the 967 source IP address of the ICMP Error packet with its own public IP 968 address. 970 REQ-6: While processing an ICMP Error packet pertaining to an ICMP 971 Query or Query response message, a NAT device MUST NOT refresh or 972 delete the NAT Session that pertains to the embedded payload within 973 the ICMP Error packet. 975 REQ-7: NAT devices enforcing Basic NAT ([NAT-TRAD]) MUST support the 976 traversal of hairpinned ICMP Query sessions. All NAT devices (i.e., 977 Basic NAT as well as NAPT devices) MUST support the traversal of 978 hairpinned ICMP Error messages. 979 a) When forwarding a hairpinned ICMP Error message, the NAT device 980 MUST translate the destination IP address of the outer IP header to 981 be same as the source IP address of the embedded IP packet after 982 the translation. 984 REQ-8: When a NAT device is unable to establish a NAT Session for a 985 new transport-layer (TCP, UDP, ICMP, etc.) flow due to resource 986 constraints or administrative restrictions, the NAT device SHOULD 987 send an ICMP destination unreachable message, with a code of 13 988 (Communication administratively prohibited) to the sender, and drop 989 the original packet. 991 REQ-9: A NAT device MAY implement a policy control that prevents 992 ICMP messages being generated toward certain interface(s). 993 Implementation of such a policy control overrides the MUSTs and 994 SHOULDs in REQ-10. 996 REQ-10: Unless overridden by REQ-9's policy, a NAT device needs to 997 support ICMP messages as below, some conforming to Section 4.3 of 998 [RFC1812] and some superseding the requirements of Section 4.3 of 999 [RFC1812]. 1000 a. MUST support: 1001 1. Destination Unreachable Message, as described in 1002 Section 7.1 of this document, 1003 2. Time Exceeded Message, as described in Section 7.2 of 1004 of this document, 1005 3. Echo Request/Reply Messages, as described in REQ-1. 1007 b. MAY support: 1008 1. Redirect Message, as described in Section 4.3.3.2 of 1010 [RFC1812], 1011 2. Timestamp and Timestamp Reply Messages, as described in 1012 Section 4.3.3.8 of [RFC1812], 1013 3. Source Route Options, as described in Section 7.3 of 1014 this document, 1015 4. Address Mask Request/Reply Message, as described in 1016 Section 7.4 of this document, 1017 5. Parameter Problem Message, as described in Section 7.5 1018 of this document, 1019 6. Router Advertisement and Solicitations, as described in 1020 Section 7.6 of this document. 1022 c. SHOULD NOT support: 1023 1. Source Quench Message, as described in Section 4.3.3.3 1024 of [RFC1812], 1025 2. Information Request/reply, as described in Section 4.3.3.7 1026 of [RFC1812]. 1028 In addition, a NAT device is RECOMMENDED to conform to the following 1029 implementation considerations: 1030 d. DS Field Usage, as described in Section 7.7 of this document, 1031 e. When Not to Send ICMP Errors, as described in 1032 Section 4.3.2.7 of [RFC1812], 1033 f. Rate Limiting, as described in Section 4.3.2.8 of [RFC1812]. 1035 REQ-11: A NAT MAY drop or appropriately handle Non-QueryError ICMP 1036 messages. The semantics of Non-QueryError ICMP messages is defined 1037 in Section 2. 1039 10. Security Considerations 1041 This document does not introduce any new security concerns related 1042 to ICMP message handling in the NAT devices. However, the 1043 requirements in the document do mitigate some security concerns 1044 known to exist with ICMP messages. 1046 [ICMP-ATK] lists a number of ICMP attacks that can be directed 1047 against end host TCP stacks. For example, a rogue entity could 1048 bombard the NAT device with a large number of ICMP Errors. If the 1049 NAT device did not validate the legitimacy of the ICMP Error 1050 packets, the ICMP Errors would be forwarded directly to the end 1051 nodes. End hosts not capable of defending themselves against such 1052 bogus ICMP Error attacks could be adversely impacted by such 1053 attacks. Req-3 recommends validating the ICMP checksum and the IP 1054 checksum of the embedded payload prior to forwarding. These 1055 checksum validations by themselves do not protect end hosts from 1056 attacks. However, checksum validation mitigates end hosts from 1057 malformed ICMP Error attacks. Req-4 and Req-5 further mandate that 1058 when a NAT device does not find a mapping selection for the embedded 1059 payload, the NAT should drop the ICMP Error packets, without 1060 forwarding. 1062 A rogue source could also try and send bogus ICMP Error messages for 1063 the active NAT sessions, with intent to destroy the sessions. Req-6 1064 averts such an attack by ensuring that an ICMP Error message does 1065 not effect the state of a session on the NAT device. 1067 Req-8 recommends a NAT device sending ICMP Error message when the 1068 NAT device is unable to create a NAT session due to lack of 1069 resources. Some administrators may choose not to have the NAT device 1070 send ICMP Error message, as doing so could confirm to a malicious 1071 attacker that the attack has succeeded. For this reason, sending 1072 of the specific ICMP Error message stated in REQ-8 is left to the 1073 discretion of the NAT device administrator. 1075 Unfortunately, ICMP messages are sometimes blocked at network 1076 boundaries due to local security policy. Thus, some of the 1077 requirements in this document allow local policy to override the 1078 recommendations of this document. Blocking such ICMP messages is 1079 known to break some protocol features (most notably Path MTU 1080 Discovery) and some applications (e.g., ping, traceroute), and 1081 such blocking is NOT RECOMMENDED. 1083 11. IANA Considerations 1085 There are no IANA considerations. 1087 12. Acknowledgements 1089 The authors wish to thank Fernando Gont, Dan Wing, Carlos Pignataro, 1090 Philip Matthews and members of the BEHAVE work group for doing a 1091 thorough review of early versions of the document and providing 1092 valuable input and offering generous amount of their time in shaping 1093 the ICMP requirements. Their valuable feedback made this document 1094 a better read. The authors appreciate that. Dan Wing and Fernando 1095 Gont were a steady source of encouragement. Fernando Gont spent 1096 many hours preparing slides and presenting the document in an IETF 1097 meeting on behalf of the authors. For this, the authors are grateful 1098 to Fernando. The authors wish to thank Carlos Pignataro and 1099 Dan Tappan, authors of the [ICMP-EXT] document, for their feedback 1100 concerning ICMP extensions. The authors wish to thank Philip 1101 Matthews for agreeing to be a technical reviewer for the document. 1103 Lastly, the authors highly appreciate the rigorous feedback from the 1104 IESG members. 1106 Normative References 1108 [BEH-UDP] Audet, F., and Jennings, C., "NAT Behavioral Requirements 1109 for Unicast UDP", RFC 4787, January 2007. 1111 [ICMP] Postel, J., "Internet Control Message Protocol", STD 5, 1112 RFC 792, September 1981. 1114 [ICMP-EXT] Bonica, R., Gan, D., Nikander, P., Tappan, D., and 1115 Pignataro, C., "Extended ICMP to Support Multi-part 1116 Messages", RFC 4884, April 2007. 1118 [NAT-TRAD] Srisuresh, P., and Egevang, K., "Traditional IP Network 1119 Address Translator (Traditional NAT)", RFC 3022, 1120 January 2001. 1122 [RFC793] "Transmission Control Protocol DARPA Internet Program 1123 Protocol Specification", RFC 793, September 1981. 1125 [RFC1812] Baker, F., "Requirements for IP Version 4 Routers", 1126 RFC 1812, June 1995. 1128 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1129 Requirement Levels", BCP 14, RFC 2119, March 1997. 1131 Informative References 1133 [BEH-APP] Ford, B., Srisuresh, P., and Kegel, D., "Application Design 1134 Guidelines for Traversal through Network Address 1135 Translators", draft-ford-behave-app-05.txt (Work In 1136 Progress), March 2007. 1138 [BEH-TCP] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and 1139 Srisuresh, P., "NAT Behavioral Requirements for TCP", 1140 BCP 142, RFC 5382, October 2008. 1142 [DHCP] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, 1143 March 1997. 1145 [ICE] Rosenberg, J., "Interactive Connectivity Establishment 1146 (ICE): A Methodology for Network Address Translator (NAT) 1147 Traversal for Offer/Answer Protocols", 1148 draft-ietf-mmusic-ice-19.txt (work in Progress), 1149 October 2007. 1151 [ICMP-ATK] Gont, F., "ICMP attacks against TCP", 1152 draft-ietf-tcpm-icmp-attacks-04.txt (Work In Progress), 1153 October 2008. 1155 [MS-TRCRT] Microsoft Support, "How to use the Tracert 1156 command-line utility to troubleshoot TCP/IP problems 1157 in Windows", http://support.microsoft.com/kb/162326, 1158 October, 2006. 1160 [NAT-MIB] Rohit, R., Srisuresh, P., Raghunarayan, R., Pai, N., 1161 and Wang, C., "Definitions of Managed Objects for Network 1162 Address Translators (NAT)", RFC 4008, March 2005. 1164 [NAT-TERM] Srisuresh, P., and Holdrege, M., "IP Network Address 1165 Translator (NAT) Terminology and Considerations", RFC 2663, 1166 August 1999. 1168 [PMTU] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 1169 November 1990. 1171 [RFC1122] Braden, R., "Requirements for Internet Hosts -- 1172 Communication Layers", RFC 1122, October 1989. 1174 [RFC1256] Deering, S., "ICMP Router Discovery Messages", RFC1256, 1175 September 1991. 1177 [RFC1470] Stine, R., "FYI on a Network Management Tool Catalog: Tools 1178 for Monitoring and Debugging TCP/IP Internets and 1179 Interconnected Devices", RFC 1470, June 1993. 1181 [RFC2474] Nichols, K., Blake, S., Baker, F., and Black, D., 1182 "Definition of the Differentiated Services Field (DS Field) 1183 in the IPv4 and IPv6 Headers", RFC 2474, December 1998. 1185 [RFC4065] Kempf, J., "Instructions for Seamoby and Experimental 1186 Mobility Protocol IANA Allocations", RFC 4065, July 2005. 1188 [TCP-SOFT] Gont, F., "TCP's Reaction to Soft Errors", 1189 draft-ietf-tcpm-tcp-soft-errors-09.txt (Work In Progress), 1190 November 2008. 1192 [UNSAF] Daigle, L., and IAB, "IAB Considerations for UNilateral 1193 Self-Address Fixing (UNSAF) Across Network Address 1194 Translation", RFC 3424, November 2002. 1196 Authors' Addresses: 1198 Pyda Srisuresh 1199 Kazeon Systems, Inc. 1200 1161 San Antonio Rd. 1201 Mountain View, CA 94043 1202 U.S.A. 1203 Phone: +1 408 836 4773 1204 E-mail: srisuresh@yahoo.com 1206 Bryan Ford 1207 Max Planck Institute for Software Systems 1208 Campus Building E1 4 1209 D-66123 Saarbruecken 1210 Germany 1211 Phone: +49-681-9325657 1212 EMail: baford@mpi-sws.org 1214 Senthil Sivakumar 1215 Cisco Systems, Inc. 1216 7100-8 Kit Creek Road 1217 PO Box 14987 1218 Research Triangle Park, NC 27709-4987 1219 U.S.A. 1220 Phone: +1 919 392 5158 1221 Email: ssenthil@cisco.com 1223 Saikat Guha 1224 Cornell University 1225 331 Upson Hall 1226 Ithaca, NY 14853 1227 U.S.A. 1228 Phone: +1 607 255 1008 1229 EMail: saikat@cs.cornell.edu 1231 Copyright Statement 1233 Copyright (c) 2009 IETF Trust and the persons identified as the 1234 document authors. All rights reserved. 1236 This document is subject to BCP 78 and the IETF Trust's Legal 1237 Provisions Relating to IETF Documents 1238 (http://trustee.ietf.org/license-info) in effect on the date of 1239 publication of this document. Please review these documents 1240 carefully, as they describe your rights and restrictions with respect 1241 to this document.