idnits 2.17.1 draft-srisuresh-behave-nat-icmp-02.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 on line 737. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 708. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 715. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 721. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 2006) is 6553 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) -- Looks like a reference, but probably isn't: '2' on line 79 == Missing Reference: 'SOCKS' is mentioned on line 89, but not defined == Missing Reference: 'RSIP' is mentioned on line 89, but not defined == Missing Reference: 'MIDCOM' is mentioned on line 89, but not defined == Missing Reference: 'UPNP' is mentioned on line 89, but not defined == Missing Reference: 'RFC2663' is mentioned on line 116, but not defined == Missing Reference: 'RFC2119' is mentioned on line 121, but not defined == Missing Reference: 'RFC 1147' is mentioned on line 177, but not defined ** Obsolete undefined reference: RFC 1147 (Obsoleted by RFC 1470) == Unused Reference: 'KEYWORDS' is defined on line 615, but no explicit reference was found in the text == Unused Reference: 'NAT-TERM' is defined on line 618, but no explicit reference was found in the text == Unused Reference: 'NAT-TRAD' is defined on line 622, but no explicit reference was found in the text == Unused Reference: 'PMTU' is defined on line 625, but no explicit reference was found in the text == Unused Reference: 'PRIV-ADDR' is defined on line 628, but no explicit reference was found in the text == Unused Reference: 'RFC1191' is defined on line 632, but no explicit reference was found in the text == Unused Reference: 'RFC1147' is defined on line 635, but no explicit reference was found in the text == Unused Reference: 'UNSAF' is defined on line 652, but no explicit reference was found in the text == Outdated reference: A later version (-08) exists of draft-ietf-behave-nat-udp-04 == Outdated reference: A later version (-08) exists of draft-ietf-behave-tcp-00 ** Downref: Normative reference to an Informational RFC: RFC 2663 (ref. 'NAT-TERM') ** Downref: Normative reference to an Informational RFC: RFC 3022 (ref. 'NAT-TRAD') -- Duplicate reference: RFC1191, mentioned in 'RFC1191', was also mentioned in 'PMTU'. ** Obsolete normative reference: RFC 1147 (Obsoleted by RFC 1470) == Outdated reference: A later version (-05) exists of draft-ford-behave-app-02 == Outdated reference: A later version (-12) exists of draft-ietf-tcpm-icmp-attacks-00 == Outdated reference: A later version (-09) exists of draft-ietf-tcpm-tcp-soft-errors-00 Summary: 8 errors (**), 0 flaws (~~), 22 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BEHAVE WG P. Srisuresh 3 Internet Draft Consultant 4 Expires: December 8, 2006 B. Ford 5 M.I.T. 6 S. Sivakumar 7 Cisco Systems 8 S. Guha 9 Cornell U. 10 May 2006 12 NAT Behavioral Requirements for ICMP protocol 13 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 Abstract 40 This document identifies the behavioral properties required of the 41 Network Address Translator devices (NATs) in conjunction with the 42 ICMP protocol. The objective of this memo is to make NAT devices 43 more predictable and compatible with diverse application protocols 44 that traverse the devices. Companion documents provide behavioral 45 recommendations specific to TCP and UDP. 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. Rejection of Outbound Flows Disallowed by NAT ................. 61 6. Conformance to RFC 1812 ....................................... 62 6.1. IP packet fragmentation .................................. 63 6.1.1. Generating "Packet too Big" ICMP error Message .... 64 6.1.2. Forwarding "Packet too big" ICMP Error Message .... 65 6.2. Generating "Time Exceeded" Error Message ................. 66 6.3. RFC 1812 Conformance Requirements summary ................ 67 7. Summary of Requirements ....................................... 68 8. Security Considerations ....................................... 69 9. Acknowledgements .............................................. 71 1. Introduction and Scope 73 This document is an adjunct to [BEH-UDP] and [BEH-TCP], which define 74 requirements for NATs when handling unicast UDP and TCP traffic. 75 The purpose of this document is to set requirements for NATs with 76 regard to ICMP messages. 78 The requirements of this specification apply to Traditional NATs as 79 described in RFC 2663 [2]. 81 This document only covers the ICMP aspects of NAT traversal. 82 Traditional NAT inherently mandates a certain level of firewall like 83 functionality. However, firewall functionality in general or any 84 other middlebox functionality is out of the scope of this 85 specification. Application and Operating System (OS) aspects of ICMP 86 NAT traversal are out of scope. 88 NAT traversal strategies that involve explicit signaling between 89 applications and NAT devices, namely [SOCKS, RSIP, MIDCOM, UPNP] are 90 also out of the scope of this document. 92 This document focuses strictly on the behavior of the NAT device, 93 and not on the behavior of applications that traverse NATs. 94 A separate companion document [BEH-APP] provides recommendations for 95 application designers on how to make applications work robustly over 96 NATs that follow the behavioral requirements specified here and the 97 companion Behave documents. 99 Even though ICMP is a transport protocol on top of IP, ICMP message 100 processing is often considered an integral of IP and is independent 101 of other transport protocols. As such, many of the ICMP behavioral 102 requirements for NAT devices apply to all IP protocols. In case 103 a requirement in this document conflicts with protocol specific 104 behave requirement(s), protocol specific behave documents will take 105 precedence. Note, the authors are not aware of any conflicts between 106 this and any other IETF document at the time of this writing. 108 Section 2 describes the terminology used throughout the document. 109 Sections 3, 4 and 5 discuss the behavioral requirements for a NAT 110 device when processing ICMP packets. Section 3 summarizes all the 111 requirements in one place. 113 2. Terminology 115 Definitions for the NAT terms used throughout the document may be 116 found in [RFC2663] and [BEH-UDP]. 118 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 119 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 120 document are to be interpreted as described in [RFC2119]. 122 ICMP messages are broadly grouped into two classes, namely "ICMP 123 Query" messages and "ICMP Error" messages in section 3.2.2 of 124 [RFC1122]. The following explanations further illustrate these 125 ICMP message classes. 127 ICMP Query Messages - All ICMP query messages are characterized 128 by the fact that have an Identifier field in the ICMP header. The 129 Identifier field used by the ICMP Query messages is also referred 130 as "Query Identifier" or "Query Id", for short throughout the 131 document. A Query Id is used by query senders and responders as 132 the equivalent of a TCP/UDP port to identify an ICMP Query session. 134 ICMP Error Messages - All ICMP error messages are characterized by 135 the fact that they embed an IP packet (a minimum of 64 bits) that 136 triggered the ICMP error message. 138 3. ICMP Query Handling 139 This section lists the behavioral requirements for a NAT device 140 when processing ICMP Query packets. The following sub sections 141 discuss requirements specific to ICMP Query handling in detail. 143 3.1. ICMP Query Mapping 145 A NAT device MUST transparently forward any ICMP Query packets 146 initiated from the nodes behind NAT devices and the responses to 147 these Query packets in the opposite direction. This requires 148 translating the IP header. A NAPT device SHOULD additionally 149 modify the ICMP Query Identifier (also referred simply as 150 'Query Id') and the associated checksum in the ICMP header prior 151 to forwarding. 153 The mapping of ICMP Query identifier within the NAT device SHOULD 154 be external endpoint independent. Say, an internal host A sent an 155 ICMP query out to an external host B using Query Id X. And, say, 156 the NAT assigned this an external mapping of Query id X' on NAT's 157 public address. If host A reused the Query Id X to send ICMP queries 158 to the same or different external host, the NAT device SHOULD reuse 159 the same Query Id mapping (i.e., map private host's Query id X to 160 Query id X' on NAT's public IP address) instead of assigning a 161 different mapping. This is similar to the "endpoint independent 162 mapping" requirement specified in the TCP and UDP drafts([BEH-TCP, 163 BEH-UDP]). 165 REQ-1: A NAT device MUST permit ICMP query based applications to be 166 initiated from private hosts to the external hosts. 167 a) NAT mapping of ICMP Query identifiers SHOULD be external host 168 independent. 170 3.2. ICMP Query Session Timeouts 172 It is to RECOMMENDED that the administrator be allowed to configure 173 the ICMP Query session timeout on the NAT devices. Typically, the 174 ICMP NAT Session timeout is set to 60 seconds. Setting the ICMP NAT 175 Session timeout to a very large duration (say, much larger than 60 176 secs) could potentially tie up NAT resources. Caution is warranted 177 as applications such as ICMP Ping and ICMP traceroute [RFC 1147], 178 built on top of ICMP query messages typically complete within a few 179 seconds. By setting the timeout to a large value, the NAT device 180 could be holding up precious NAT resources such as mappings and NAT 181 Sessions for the whole duration. 183 REQ-2: An ICMP Query session mapping timer MUST NOT expire in less 184 than 60 seconds. 185 a) The value of NAT ICMP mapping timer MAY be configurable. 187 4. ICMP Error Forwarding 189 Applications depend on ICMP error messages from end hosts and 190 intermediate devices being forwarded reliably by the NAT devices. 191 A NAT device MUST confirm to a number of requirements to ensure 192 reliable forwarding. The following sub-sections discuss the 193 requirements in detail. 195 4.1. ICMP Error Payload Validation 197 Appendix C of [ICMP-ATK] points out that newer revision end host 198 TCP stacks donot accept ICMP error messages with a mismatched 199 IP or TCP checksum in the embedded payload. NAT devices should 200 ensure that the embedded payload is not corrupted. Only after the 201 embedded payload is validated, should the NAT proceed to consider 202 the error packet for forwarding. 204 The NAT device SHOULD verify the IP checksum of the embedded payload 205 and if the IP checksum does not match, the NAT MUST simply drop the 206 error packet. [ICMP] stipulates that an ICMP error message should 207 embed IP header and a minimum of 8 bytes of the IP payload. 208 Section 4.3.2.3 of [RFC1812] further recommends that an ICMP error 209 originator SHOULD include as much of the original packet as possible 210 in the payload without the length of the ICMP datagram exceeding 211 576 bytes. If the embedded payload is a complete IP packet, the NAT 212 device SHOULD further validate the applicable transport checksum. 213 If the transport checksum fails, the NAT MUST once again drop the 214 error packet. 216 REQ-3: When an ICMP error packet is received, the NAT device SHOULD 217 verify that the checksum(s) of the embedded IP packet is not 218 corrupted. 219 a) If the IP checksum of the embedded payload fails, the NAT 220 MUST drop the error packet. 221 b) If the embedded payload is a complete TCP segment, the NAT device 222 SHOULD validate the TCP checksum. If the transport checksum fails, 223 the NAT device MUST drop the error packet. 224 c) If the embedded payload is a complete UDP datagram and the UDP 225 datagram contains non-zero checksum, the NAT device SHOULD validate 226 the UDP checksum. If the transport checksum fails, the NAT device 227 MUST drop the error packet. 229 4.2. ICMP Error Packet Translation 231 Section 4.3 of the RFC 3022 describes the various fields within 232 an ICMP error message a NAT device MUST translate. In this section, 233 we describe the requirements a NAT device must conform to while 234 doing the translations. 236 Consider the following scenario in figure 1. Say, NAT-xy is a 237 traditional NAT device connecting hosts in private and external 238 networks. Router-x and Host-x are in the external network. Router-y 239 and Host-y are in the private network. The subnets in the external 240 network are routable from the private as well as the external 241 domains. Whereas, the subnets in the private network are only 242 routable within the private domain. When Host-y initiated a session 243 to Host-x, let us say that the NAT device assigned an IP address of 244 Host-y' to associate with Host-y in the external network. 246 Host-x 247 | 248 ---------------+------------------- 249 | 250 +-------------+ 251 | Router-x | 252 +-------------+ 253 External Network | 254 --------------------+--------+------------------- 255 | ^ | 256 | | (Host-y', Host-x) | 257 | | v 258 +-------------+ 259 | NAT-xy | 260 +-------------+ 261 | 262 | Private Network 263 ----------------+------------+---------------- 264 | 265 +-------------+ 266 | Router-y | 267 +-------------+ 268 | 269 ----------------+-------+-------- 270 | ^ | 271 | | (Host-y, Host-x) | 272 | | v 273 Host-y 275 Figure 1. NAT topology with routers in private & external realms 277 4.2.1. ICMP Error Packet Received from External Realm 278 Say, a packet from Host-y to Host-x triggered an ICMP error message 279 from one of Router-x or Host-x (both of which are in the external 280 domain). Such an ICMP error packet will have one of Router-x or 281 Host-x as the source IP address and Host-y' as the destination IP 282 address. 284 When the NAT device receives the ICMP error packet, the 285 NAT device must use the packet embedded within the ICMP error 286 message (i.e., the IP packet from Host-y to Host-x) to look up the 287 NAT Session the embedded packet belongs to and use the NAT Session 288 to translate the embedded payload. 290 The NAT device must also use the NAT Session to translate the 291 destination IP address in the outer IP header. In the outer header, 292 the source IP address will remain unchanged because the originator 293 of the ICMP error message (Host-x or Router-x) is in external 294 domain and routable from the private domain. The destination IP 295 address Host-y' must however be translated to Host-y using the NAT 296 Session parameters. 298 REQ-4: If a NAT device receives an ICMP error packet from external 299 realm, and the NAT does not have an active mapping for the embedded 300 payload, the NAT SHOULD silently drop the ICMP error packet. If the 301 the NAT has active mapping for the embedded payload, then the NAT 302 MUST transparently forward the ICMP error message, without modifying 303 the ICMP error type or code as follows. 304 a) The NAT MUST revert the IP and transport headers of the embedded 305 IP packet to their original form, using the matching mapping. 306 b) The NAT device MUST modify the destination IP address of the 307 outer IP header to be same as the source IP address of the embedded 308 IP packet. 309 c) Lastly, the NAT MUST update the IP and ICMP checksums in the 310 outer headers to reflect the above changes. 312 4.2.2. ICMP Error Packet Received from Private Realm 314 Now, say, a packet from Host-x to Host-y triggered an ICMP error 315 message from one of Router-y or Host-y (both of which are in the 316 private domain). Such an ICMP error packet will have one of 317 Router-y or Host-y as the source IP address and Host-x as the 318 destination IP address. 320 When the NAT device receives the ICMP error packet, the NAT device 321 must use the packet embedded within the ICMP error message (i.e., 322 the IP packet from Host-x to Host-y) to look up the NAT Session the 323 embedded packet belongs to and use the NAT Session to translate the 324 embedded payload. 326 In the outer header, the destination IP address will remain 327 unchanged, as the IP addresses for Host-x is already in the external 328 domain. If the ICMP error message is generated by Host-y, the NAT 329 device must simply use the NAT Session to translate the source IP 330 address Host-y to Host-y'. However, if the ICMP error message is 331 generated by the intermediate node Router-y, and the NAT device 332 does not have a translation entry for Router-y within NAT, the NAT 333 device must simply use its own IP address in the external domain to 334 translate the source IP address. 336 REQ-5: If a NAT device receives an ICMP error packet from private 337 realm, and the NAT does not have an active mapping for the embedded 338 payload, the NAT SHOULD silently drop the ICMP error packet. If the 339 the NAT has active mapping for the embedded payload, then the NAT 340 MUST transparently forward the ICMP error message, without modifying 341 the ICMP error type or code as follows. 342 a) The NAT MUST revert the IP and transport headers of the embedded 343 IP packet to their original form, using the matching mapping. 344 b) If the NAT device has active mapping for the ICMP error packet 345 originator, the NAT MUST translate the source IP address of the 346 ICMP error packet with the public IP address in the mapping. 347 Otherwise, the NAT MUST translate the source IP address of the ICMP 348 error packet with its own public IP address. 349 c) Lastly, the NAT MUST update the IP and ICMP checksums in the 350 outer headers to reflect the above changes. 352 4.3. NAT Sessions Pertaining to ICMP Error Payload 354 While processing an ICMP error packet, a NAT device MUST NOT 355 refresh or delete the NAT Session that pertains to the embedded 356 payload within the ICMP error packet. This is in spite of the 357 fact that the NAT device uses the NAT Session to translate the 358 embedded payload. By not effecting the NAT Sessions, the NAT 359 device is able to retain them, even as someone spoofs ICMP error 360 messages pertaining to the NAT Sessions. 362 REQ-6: While processing an ICMP error packet, a NAT device MUST NOT 363 refresh or delete the NAT Session that pertains to the embedded 364 payload within the ICMP error packet. 366 5. Rejection of Outbound Flows Disallowed by NAT 368 A NAT device typically permits all outbound sessions. However, 369 a NAT device may disallow some outbound sessions due to resource 370 constraints. For example, a NAT device may not permit the first 371 packet of a new outbound session, if the NAT device is out of 372 resources (out of addresses or TCP/UDP ports or a NAT Session 373 resource) to set up a state for the session, or, the specific 374 session is administratively restricted by the NAT device. 376 When the first packet of an outbound flow is prohibited by a NAT 377 device due to resource or administration considerations, 378 the NAT device SHOULD send ICMP destination unreachable message. 379 Section 5.2.7.1 of [RFC1812] recommends routers to use ICMP code 13 380 (Communication administratively prohibited) when they 381 administratively filter packets. As such, a NAT device MUST use 382 ICMP code 13 when generating an ICMP error message. 384 REQ-7: When an outbound flow is prohibited by a NAT device due to 385 resource or authorization consideration, the NAT device SHOULD send 386 ICMP destination unreachable message, with a code of 13 387 (Communication administratively prohibited) to the sender prior to 388 dropping the original packet. 390 6. Conformance to RFC 1812 392 A NAT device is inherently an intermediate router that forwards 393 IP packets between private and public realms. As such, the NAT 394 device MUST confirm to all the requirements of a router, as 395 specified in [RFC1812]. Section 5.2.7.1 of [RFC1812] states that 396 a router MUST also be able to generate ICMP Destination Unreachable 397 messages and SHOULD choose a response code that most closely matches 398 the reason the message is being generated. 400 Note, however, NAT devices also function as hosts on the Internet 401 and are bound by the conformance requirements in [RFC1122]. Protocol 402 specific Behave documents ([BEH-UDP], [BEH-TCP]) identify instances 403 where a NAT device should deviate from RFC 1122. As such, the host 404 behavior requirements of NAT devices specified in the protocol 405 specific behave drafts take precedence over RFC 1122. 407 The focus of this section is on conformance to router requirements. 408 The following sub sections identify specific instances where a NAT 409 device would be expected to confirm to RFC 1812. 411 6.1. IP packet fragmentation 413 IP fragmentation by intermediate nodes often results in 414 degraded performance. In some cases, IP fragmentation by the 415 intermediate nodes could even cause end-to-end communication 416 to entirely fail. Many applications avoid fragmentation in 417 the network by originating IP packets that fit within the 418 maximum Path MTU enroute and setting the DF (Don't Fragment) 419 bit so the intermediate nodes enroute do not fragment the 420 packets. Path discovery is not restricted to TCP or UDP based 421 application and applies to all IP protocols. For instance, TCP 422 connections often set the DF bit set in the IP header of the 423 TCP segments they transmit. Likewise, IP based VPN tunnels 424 also often set the DF bit on the external IP encapsulation. 426 6.1.1. Generating "Packet too Big" ICMP error Message 428 When a router is unable to forward a datagram because it exceeds 429 the MTU of the nexthop network and its Don't Fragment (DF) bit is 430 set, the router is required to return an ICMP Destination 431 Unreachable message to the source of the datagram, with the Code 432 indicating "fragmentation needed and DF set". Further, the router 433 MUST include the MTU of that nexthop network in the low order 434 16 bits of the ICMP header, as specified in RFC 1191. 436 A NAT device MUST honor the DF bit in the IP header of the 437 packets transiting the device. If the DF bit is set and the 438 MTU on the forwarding interface of the NAT device is such that 439 the IP datagram cannot be forwarded without fragmentation, the 440 NAT device MUST issue a "packet too big" ICMP message (ICMP 441 type 3, Code 4) with a suggested MTU back to the sender and 442 drop the original IP packet. The sender will resend after 443 taking the appropriate corrective action. 445 If the DF bit is not set and the MTU on the forwarding interface 446 of the NAT device mandates fragmentation, the NAT device must 447 simply send this fragmented, just as any router does [RFC1812]. 449 6.1.2. Forwarding "Packet too big" ICMP Error Message 451 This is flip side of the argument for the above section. By 452 virtue of the address translation NAT performs, NAT may end 453 up being the recipient of "Packet too big" message. 455 When NAT device is the recipient of "Packet too big" 456 ICMP message from the network, the NAT device MUST forward the 457 ICMP message back to the intended recipient, pursuant to the 458 previosuly stated requirements REQ-3, REQ-4, REQ-5 and REQ-6. 460 6.2. Generating "Time Exceeded" Error Message 462 Section 5.2.7.3 of RFC 1812 says that a router MUST generate 463 "Time Exceeded" ICMP error message when it discards a packet due 464 to an expired TTL field. A router MAY have a per interface option 465 to disable origination of these messages on that interface, but that 466 option MUST default to allowing the messages to be originated. 468 6.3. RFC 1812 Conformance Requirements summary 470 REQ-8: A NAT device MUST confirm to RFC 1812 in IP packet handling. 471 Below are specific instances where a NAT device MUST confirm to 472 RFC 1812. 473 a) If DF bit is set on a transit IP packet and the NAT 474 device cannot forward the packet without fragmentation, the 475 NAT device MUST send a "Packet too big" ICMP message (ICMP 476 type 3, Code 4) with a suggested MTU back to the sender and 477 drop the original IP packet. 478 b) A NAT device MUST generate "Time Exceeded" ICMP error message 479 when it discards a packet due to an expired TTL field. 481 7. Summary of Requirements 483 This section summarizes the requirements discussed in the preceding 484 sections. 486 REQ-1: A NAT device MUST permit ICMP query based applications to be 487 initiated from private hosts to the external hosts. 488 a) NAT mapping of ICMP Query identifiers SHOULD be external host 489 independent. 491 REQ-2: An ICMP Query session mapping timer MUST NOT expire in less 492 than 60 seconds. 493 a) The value of NAT ICMP mapping timer MAY be configurable. 495 REQ-3: When an ICMP error packet is received, the NAT device SHOULD 496 verify that the checksum(s) of the embedded IP packet is not 497 corrupted. 498 a) If the IP checksum of the embedded payload fails, the NAT 499 MUST drop the error packet. 500 b) If the embedded payload is a complete TCP segment, the NAT device 501 SHOULD validate the TCP checksum. If the transport checksum fails, 502 the NAT device MUST drop the error packet. 503 c) If the embedded payload is a complete UDP datagram and the UDP 504 datagram contains non-zero checksum, the NAT device SHOULD validate 505 the UDP checksum. If the transport checksum fails, the NAT device 506 MUST drope the error packet. 508 REQ-4: If a NAT device receives an ICMP error packet from external 509 realm, and the NAT does not have an active mapping for the embedded 510 payload, the NAT SHOULD silently drop the ICMP error packet. If the 511 the NAT has active mapping for the embedded payload, then the NAT 512 MUST transparently forward the ICMP error message, without modifying 513 the ICMP error type or code as follows. 514 a) The NAT MUST revert the IP and transport headers of the embedded 515 IP packet to their original form, using the matching mapping. 516 b) The NAT device MUST modify the destination IP address of the 517 outer IP header to be same as the source IP address of the embedded 518 IP packet. 519 c) Lastly, the NAT MUST update the IP and ICMP checksums in the 520 outer headers to reflect the above changes. 522 REQ-5: If a NAT device receives an ICMP error packet from private 523 realm, and the NAT does not have an active mapping for the embedded 524 payload, the NAT SHOULD silently drop the ICMP error packet. If the 525 the NAT has active mapping for the embedded payload, then the NAT 526 MUST transparently forward the ICMP error message, without modifying 527 the ICMP error type or code as follows. 528 a) The NAT MUST revert the IP and transport headers of the embedded 529 IP packet to their original form, using the matching mapping. 530 b) If the NAT device has active mapping for the ICMP error packet 531 originator, the NAT MUST translate the source IP address of the 532 ICMP error packet with the public IP address in the mapping. 533 Otherwise, the NAT MUST translate the source IP address of the ICMP 534 error packet with its own public IP address. 535 c) Lastly, the NAT MUST update the IP and ICMP checksums in the 536 outer headers to reflect the above changes. 538 REQ-6: While processing an ICMP error packet, a NAT device MUST NOT 539 refresh or delete the NAT Session that pertains to the embedded 540 payload within the ICMP error packet. 542 REQ-7: When an outbound flow is prohibited by a NAT device due to 543 resource or authorization consideration, the NAT device SHOULD send 544 ICMP destination unreachable message, with a code of 13 545 (Communication administratively prohibited) to the sender prior to 546 dropping the original packet. 548 REQ-8: A NAT device MUST confirm to RFC 1812 in IP packet handling. 549 Below are specific instances where a NAT device MUST confirm to 550 RFC 1812. 551 a) If DF bit is set on a transit IP packet and the NAT 552 device cannot forward the packet without fragmentation, the 553 NAT device MUST send a "Packet too big" ICMP message (ICMP 554 type 3, Code 4) with a suggested MTU back to the sender and 555 drop the original IP packet. 556 b) A NAT device MUST generate "Time Exceeded" ICMP error message 557 when it discards a packet due to an expired TTL field. 559 8. Security Considerations 561 This document does not introduce any new security concerns related 562 to ICMP error message handling in the NAT devices. However, the 563 document does propose cunter measures to mitigate security concerns 564 that already exist with ICMP error messages. 566 [ICMP-ATK] lists a number of ICMP attacks that can be directed 567 against end host TCP stacks and suggests remedies to counter the 568 attacks. [TCP-SOFT] describes improvements to the handling of 569 ICMP error messages in many of the existing TCP/IP stacks, including 570 Linux. Section 4 of this document decribes a number of measures by 571 which NAT devices should validate and update the embedded payload 572 in ICMP error messages prior to forwarding. These measure ensure 573 that NATs forward the ICMP error messages reliably, as stipulated 574 in [ICMP-ATK]. 576 For example, a rogue entity could bombard the NAT device with a 577 large number of ICMP errors. If the NAT device did not 578 validate the legitimacy of the ICMP error packets, the ICMP errors 579 would be forwarded directly to the end nodes. End hosts not capable 580 of defending themselves against such bogus ICMP error attacks could 581 be adversely impacted by such attacks. Req-3 recommends validating 582 embedded payload prior to forwarding. Checksum validation by itself 583 does not protect end hosts from attacks. However, checksum 584 validation mitigates endhosts from malformed ICMP error attacks. 585 Req-4 and Req-5 further mandate that when a NAT device does not find 586 a mapping selection for the embedded payload, the NAT should drop 587 the ICMP error packets, without forwarding. 589 A rogue source could also try and send bogus ICMP error messages for 590 the active NAT sessions, with an intent to destroy the sessions. 591 Req-6 averts such an attack by ensuring that an ICMP error message 592 does not effect the state of a session on the NAT device. 594 9. Acknowledgements 596 The authors wish to thank Fernando Gont and Dan Wing for providing 597 valuable input and offering generous amount of their time in shaping 598 the ICMP requirements. Their valuable feedback makes this document a 599 better read. The authors highly appreciate that. 601 Normative References 603 [BEH-UDP] F. Audet and C. Jennings, "NAT Behavioral Requirements for 604 Unicast UDP", draft-ietf-behave-nat-udp-04.txt (Work In 605 Progress), September 2005. 607 [BEH-TCP] Guha, S., Biswas, K., Ford, B., Francis, P., Sivakumar, S., 608 and Srisuresh, P., "NAT Behavioral Requirements for 609 Unicast TCP", draft-ietf-behave-tcp-00.txt (Work In 610 Progress), February 2006. 612 [ICMP] Postel, J., "Internet Control Message Protocol", STD 5, 613 RFC 792, September 1981. 615 [KEYWORDS] S. Bradner, "Key words for use in RFCs to Indicate 616 Requirement Levels", RFC 2119, March 1997. 618 [NAT-TERM] P. Srisuresh and M. Holdrege, "IP Network Address Translator 619 (NAT) Terminology and Considerations", RFC 2663, August 620 1999. 622 [NAT-TRAD] P. Srisuresh and K. Egevang, "Traditional IP Network Address 623 Translator (Traditional NAT)", RFC 3022, January 2001. 625 [PMTU] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 626 November 1990. 628 [PRIV-ADDR] Y. Rekhter, B. Moskowitz, D. Karrenberg, G. J. de Groot, and 629 E. Lear, "Address Allocation for Private Internets", RFC 630 1918, February 1996. 632 [RFC1191] Mogul, J., and Deering, S., "Path MTU Discovery", RFC 1191, 633 November 1990. 635 [RFC1147] Stine, R., "FYI on a Network Management Tool Catalog: Tools 636 for Monitoring and Debugging TCP/IP Internets and 637 Interconnected Devices", RFC 1147, April 1990. 639 [RFC1812] Baker, F., "Requirements for IP Version 4 Routers", 640 RFC 1812, June 1995. 642 Informative References 644 [BEH-APP] Ford, B., Srisuresh, P., and Kegel, D., "Application Design 645 Guidelines for Traversal through Network Address 646 Translators", draft-ford-behave-app-02.txt (Work In 647 Progress), March 2006. 649 [RFC1122] Braden, R., "Requirements for Internet Hosts -- 650 Communication Layers", RFC 1122, October 1989. 652 [UNSAF] Daigle, L., and IAB, "IAB Considerations for UNilateral 653 Self-Address Fixing (UNSAF) Across Network Address 654 Translation", RFC 3424, November 2002. 656 [ICMP-ATK] Gont, F., "ICMP attacks against TCP", 657 draft-ietf-tcpm-icmp-attacks-00.txt (Work In Progress), 658 February 2006. 660 [TCP-SOFT] Gont, F., "TCP's Reaction to Soft Errors", 661 draft-ietf-tcpm-tcp-soft-errors-00.txt (Work In Progress), 662 February 2006. 664 Author's Addresses: 666 Pyda Srisuresh 667 Consultant 668 20072 Pacifica Dr. 669 Cupertino, CA 95014 670 U.S.A. 671 Phone: (408)836-4773 672 E-mail: srisuresh@yahoo.com 674 Bryan Ford 675 Computer Science and Artificial Intelligence Laboratory 676 Massachusetts Institute of Technology 677 77 Massachusetts Ave. 678 Cambridge, MA 02139 679 U.S.A. 680 Phone: (617) 253-5261 681 E-mail: baford@mit.edu 682 Web: http://www.brynosaurus.com/ 684 Senthil Sivakumar 685 Cisco Systems, Inc. 686 7100-8 Kit Creek Road 687 PO Box 14987 688 Research Triangle Park, NC 27709-4987 689 U.S.A. 690 Phone: +1 919 392 5158 691 Email: ssenthil@cisco.com 693 Saikat Guha 694 Cornell University 695 331 Upson Hall 696 Ithaca, NY 14853 697 U.S.A. 698 Email: saikat@cs.cornell.edu 700 Intellectual Property Statement 701 The IETF takes no position regarding the validity or scope of any 702 Intellectual Property Rights or other rights that might be claimed to 703 pertain to the implementation or use of the technology described in 704 this document or the extent to which any license under such rights 705 might or might not be available; nor does it represent that it has 706 made any independent effort to identify any such rights. Information 707 on the procedures with respect to rights in RFC documents can be 708 found in BCP 78 and BCP 79. 710 Copies of IPR disclosures made to the IETF Secretariat and any 711 assurances of licenses to be made available, or the result of an 712 attempt made to obtain a general license or permission for the use of 713 such proprietary rights by implementers or users of this 714 specification can be obtained from the IETF on-line IPR repository at 715 http://www.ietf.org/ipr. 717 The IETF invites any interested party to bring to its attention any 718 copyrights, patents or patent applications, or other proprietary 719 rights that may cover technology that may be required to implement 720 this standard. Please address the information to the IETF at 721 ietf-ipr@ietf.org. 723 Copyright Statement 725 Copyright (C) The Internet Society (2006). 727 This document is subject to the rights, licenses and restrictions 728 contained in BCP 78, and except as set forth therein, the authors 729 retain all their rights. 731 This document and the information contained herein are provided on an 732 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 733 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 734 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 735 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 736 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 737 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 739 Acknowledgment 741 Funding for the RFC Editor function is currently provided by the 742 Internet Society.