[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-srisuresh-behave-nat-icmp) 00 01 02 03 04 05 06 07 08 09 10 11 12 RFC 5508

BEHAVE WG                                                   P. Srisuresh
Internet Draft                                                Consultant
Expires: December 24, 2006                                       B. Ford
                                                                  M.I.T.
                                                            S. Sivakumar
                                                           Cisco Systems
                                                                 S. Guha
                                                              Cornell U.
                                                                May 2006


                NAT Behavioral Requirements for ICMP protocol
                <draft-ietf-behave-nat-icmp-00.txt>


Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.


Abstract

   This document identifies the behavioral properties required of the
   Network Address Translator devices (NATs) in conjunction with the
   ICMP protocol. The objective of this memo is to make NAT devices
   more predictable and compatible with diverse application protocols
   that traverse the devices. Companion documents provide behavioral
   recommendations specific to TCP and UDP.




Srisuresh, et. al.                                              [Page 1]


Internet-Draft    NAT Behavioral Requirements for ICMP          May 2006



Table of Contents

   1. Introduction and Scope ........................................
   2. Terminology ...................................................
   3. ICMP Query Handling ...........................................
      3.1. ICMP Query Mapping .....,,................................
      3.2. ICMP Query Session Timeouts ..............................
   4. ICMP Error Forwarding .........................................
      4.1. ICMP Error Payload Validation .....,,.....................
      4.2. ICMP Error Packet Translation ............................
           4.2.1. ICMP Error Packet Received from External Realm ....
           4.2.2. ICMP Error Packet Received from Private Realm .....
      4.3. NAT Sessions Pertaining to ICMP Error Payload ............
   5. Rejection of Outbound Flows Disallowed by NAT .................
   6. Conformance to RFC 1812 .......................................
      6.1. IP packet fragmentation ..................................
           6.1.1. Generating "Packet too Big" ICMP error Message ....
           6.1.2. Forwarding "Packet too big" ICMP Error Message ....
      6.2. Generating "Time Exceeded" Error Message .................
      6.3. RFC 1812 Conformance Requirements summary ................
   7. Summary of Requirements .......................................
   8. Security Considerations .......................................
   9. IANA Considerations ...........................................
   10. Acknowledgements .............................................


1. Introduction and Scope

   As pointed out in RFC 3424 [UNSAF], NAT implementations vary
   widely in terms of how they handle different traffic. The purpose
   of this document is to define a specific set of requirements for NAT
   behavior with regard to ICMP messages. The objective is to reduce
   the unpredictability and brittleness the NATs introduce.
   This document is an adjunct to [BEH-UDP] and [BEH-TCP], and other
   protocol specific behave document(s) in the future which define
   requirements for NATs when handling protocol specific traffic.

   The requirements of this specification apply to Traditional NATs as
   described in [NAT-TRAD]. Traditional NATs include the popular NAPT
   devices which use a single public IP address to translate multiple
   private IP addresses.

   This document only covers the ICMP aspects of NAT traversal.
   Traditional NAT inherently mandates a certain level of firewall like
   functionality. However, firewall functionality in general or any
   other middlebox functionality is out of the scope of this
   specification.



Srisuresh, et. al.                                              [Page 2]


Internet-Draft    NAT Behavioral Requirements for ICMP          May 2006



   NAT traversal strategies that involve explicit signaling between
   applications and  NAT devices, namely [NAT-PMP], [NSIS-NSLP],
   [SOCKS], [RSIP], [MIDCOM], [UPNP] are also out of the scope of
   this document.

   This document focuses strictly on the behavior of the NAT device,
   and not on the behavior of applications that traverse NATs.
   A separate companion document [BEH-APP] provides recommendations for
   application designers on how to make applications work robustly over
   NATs that follow the behavioral requirements specified here and the
   adjunct Behave documents.

   Even though ICMP is a transport protocol on top of IP, ICMP message
   processing is often considered an integral of IP and is independent
   of other transport protocols. As such, many of the ICMP behavioral
   requirements discussed in this document apply to all IP protocols.

   In case a requirement in this document conflicts with protocol
   specific behave requirement(s), protocol specific behave documents
   will take precedence. Note, the authors are not aware of any
   conflicts between this and any other IETF document at the time of
   this writing.

   Section 2 describes the terminology used throughout the document.
   Sections 3, 4 and 5 discuss the behavioral requirements for a NAT
   device when processing ICMP packets. Section 3 summarizes all the
   requirements in one place.

2. Terminology

   Definitions for the NAT terms used throughout the document may be
   found in [NAT-TERM] and [BEH-UDP].

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

   ICMP messages are broadly grouped into two classes, namely "ICMP
   Query" messages and "ICMP Error" messages in section 3.2.2 of
   [RFC1122]. The following explanations further illustrate these
   ICMP message classes.

   ICMP Query Messages - All ICMP query messages are characterized
   by an Identifier field in the ICMP header. The Identifier field used
   by the ICMP Query messages is also referred as "Query Identifier" or
   "Query Id", for short throughout the document. A Query Id is used by
   query senders and responders as the equivalent of a TCP/UDP port to



Srisuresh, et. al.                                              [Page 3]


Internet-Draft    NAT Behavioral Requirements for ICMP          May 2006


   identify an ICMP Query session.

   ICMP Error Messages - All ICMP error messages are characterized by
   the fact that they embed an IP packet (a minimum of 64 bits) that
   triggered the ICMP error message. Unlike ICMP Query messages, ICMP
   error messages do not have a Query Id in the ICMP header.


3. ICMP Query Handling

   This section lists the behavioral requirements for a NAT device
   when processing ICMP Query packets. The following sub sections
   discuss requirements specific to ICMP Query handling in detail.

3.1. ICMP Query Mapping

   A NAT device MUST transparently forward any ICMP Query packets
   initiated from the nodes behind NAT devices and the responses to
   these Query packets in the opposite direction. This requires
   translating the IP header. A NAPT device SHOULD additionally
   modify the ICMP Query Id and the associated checksum in the ICMP
   header prior to forwarding.

   The mapping of ICMP Query identifier within the NAT device SHOULD
   be external endpoint independent.

      Say, an internal host A sent an ICMP query out to an external
      host B using Query Id X. And, say, the NAT assigned this an
      external mapping of Query id X' on the NAT's public address. If
      host A reused the Query Id X to send ICMP queries to the same or
      different external host, the NAT device SHOULD reuse the same
      Query Id mapping (i.e.,  map private host's Query id X to Query
      id X' on NAT's public IP address) instead of assigning a
      different mapping. This is similar to the "endpoint independent
      mapping" requirement specified in the TCP and UDP drafts
      [BEH-TCP, BEH-UDP].

   REQ-1: A NAT device MUST permit ICMP query based applications to be
   initiated from private hosts to the external hosts.
   a) NAT mapping of ICMP Query identifiers SHOULD be external host
   independent.


3.2. ICMP Query Session Timeouts

   It is to RECOMMENDED that the administrator be allowed to configure
   the ICMP Query session timeout on the NAT devices. Typically, the
   ICMP NAT Session timeout is set to 60 seconds. Setting the ICMP NAT



Srisuresh, et. al.                                              [Page 4]


Internet-Draft    NAT Behavioral Requirements for ICMP          May 2006


   Session timeout to a very large duration (say, much larger than 60
   seconds) could potentially tie up NAT resources. Caution is
   warranted as applications such as ICMP Ping and ICMP traceroute
   [RFC1147], built on top of ICMP query messages typically complete
   within a few seconds. By setting the timeout to a large value, the
   NAT device could be holding up precious NAT resources such as
   mappings and NAT Sessions for the whole duration.

   REQ-2: An ICMP Query session mapping timer MUST NOT expire in less
   than 60 seconds.
   a) The value of NAT ICMP mapping timer MAY be configurable.


4. ICMP Error Forwarding

   Applications depend on ICMP error messages from end hosts and
   intermediate devices being forwarded reliably by the NAT devices.
   A NAT device MUST conform to a number of requirements to ensure
   reliable forwarding. The following sub-sections discuss the
   requirements in detail.

4.1. ICMP Error Payload Validation

   Appendix C of [ICMP-ATK] points out that newer revision end host
   TCP stacks do not accept ICMP error messages with a mismatched
   IP or TCP checksum in the embedded payload. NAT devices should
   ensure that the embedded payload is not corrupted. Only after the
   embedded payload is validated, should the NAT proceed to consider
   the error packet for forwarding.

   The NAT device SHOULD verify the IP checksum of the embedded payload
   and if the IP checksum does not match, the NAT MUST simply drop the
   error packet. [ICMP] stipulates that an ICMP error message should
   embed IP header and a minimum of 64 bits of the IP payload.
   Section 4.3.2.3 of [RFC1812] further recommends that an ICMP error
   originator SHOULD include as much of the original packet as possible
   in the payload without the length of the ICMP datagram exceeding
   576 bytes. If the embedded payload is a complete IP packet, the NAT
   device SHOULD further validate the applicable transport checksum.
   If the transport checksum fails, the NAT MUST once again drop the
   error packet.

   REQ-3:  When an ICMP error packet is received, the NAT device SHOULD
   verify that the checksum(s) of the embedded IP packet is not
   corrupted.
   a) If the IP checksum of the embedded payload fails, the NAT
   MUST drop the error packet.
   b) If the embedded payload is a complete TCP segment, the NAT device



Srisuresh, et. al.                                              [Page 5]


Internet-Draft    NAT Behavioral Requirements for ICMP          May 2006


   SHOULD validate the TCP checksum. If the transport checksum fails,
   the NAT device MUST drop the error packet.
   c) If the embedded payload is a complete UDP datagram and the UDP
   datagram contains non-zero checksum, the NAT device SHOULD validate
   the UDP checksum. If the transport checksum fails, the NAT device
   MUST drop the error packet.

4.2. ICMP Error Packet Translation

   Section 4.3 of the RFC 3022 describes the various fields within
   an ICMP error message a NAT device MUST translate. In this section,
   we describe the requirements a NAT device must conform to while
   doing the translations.

   Consider the following scenario in figure 1. Say, NAT-xy is a
   traditional NAT device connecting hosts in private and external
   networks. Router-x and Host-x are in the external network. Router-y
   and Host-y are in the private network. The subnets in the external
   network are routable from the private as well as the external
   domains. Whereas, the subnets in the private network are only
   routable within the private domain. When Host-y initiated a session
   to Host-x, let us say that the NAT device assigned an IP address of
   Host-y' to associate with Host-y in the external network.


                                  Host-x
                                     |
                             ---------------+-------------------
                                            |
                                     +-------------+
                                     |  Router-x   |
                                     +-------------+
               External Network             |
               --------------------+--------+-------------------
                                   |   ^                   |
                                   |   | (Host-y', Host-x) |
                                   |   |                   v
                             +-------------+
                             |    NAT-xy   |
                             +-------------+
                                   |
                                   | Private Network
      ----------------+------------+----------------
                      |
               +-------------+
               | Router-y    |
               +-------------+
                      |



Srisuresh, et. al.                                              [Page 6]


Internet-Draft    NAT Behavioral Requirements for ICMP          May 2006


      ----------------+-------+--------
                              | ^                  |
                              | | (Host-y, Host-x) |
                              | |                  v
                            Host-y

   Figure 1. NAT topology with routers in private & external realms


4.2.1. ICMP Error Packet Received from External Realm

   Say, a packet from Host-y to Host-x triggered an ICMP error message
   from one of Router-x or Host-x (both of which are in the external
   domain). Such an ICMP error packet will have one of Router-x or
   Host-x as the source IP address and Host-y' as the destination IP
   address.

   When the NAT device receives the ICMP error packet, the NAT device
   must use the packet embedded within the ICMP error message (i.e.,
   the IP packet from Host-y to Host-x) to look up the NAT Session the
   embedded packet belongs to. If the NAT device does not have an
   active mapping for the embedded payload, the NAT SHOULD silently
   drop the ICMP error packet. Otherwise, the NAT device SHOULD use
   the matching NAT Session to translate the embedded payload.

   The NAT device must also use the NAT Session to translate the
   destination IP address in the outer IP header. In the outer header,
   the source IP address will remain unchanged because the originator
   of the ICMP error message (Host-x or Router-x) is in external
   domain and routable from the private domain. The destination IP
   address Host-y' must however be translated to Host-y using the NAT
   Session parameters.

   REQ-4: If a NAT device receives an ICMP error packet from external
   realm, and the NAT does not have an active mapping for the embedded
   payload, the NAT SHOULD silently drop the ICMP error packet. If the
   the NAT has active mapping for the embedded payload, then the NAT
   MUST transparently forward the ICMP error message, without modifying
   the ICMP error type or code as follows.
   a) The NAT MUST revert the IP and transport headers of the embedded
   IP packet to their original form, using the matching mapping.
   b) The NAT device MUST modify the destination IP address of the
   outer IP header to be same as the source IP address of the embedded
   IP packet after the translation.
   c) Lastly, the NAT MUST update the IP and ICMP checksums in the
   outer headers to reflect the above changes.

4.2.2. ICMP Error Packet Received from Private Realm



Srisuresh, et. al.                                              [Page 7]


Internet-Draft    NAT Behavioral Requirements for ICMP          May 2006



   Now, say, a packet from Host-x to Host-y triggered an ICMP error
   message from one of Router-y or Host-y (both of which are in the
   private domain). Such an ICMP error packet will have one of
   Router-y or Host-y as the source IP address and Host-x as the
   destination IP address.

   When the NAT device receives the ICMP error packet, the NAT device
   must use the packet embedded within the ICMP error message (i.e.,
   the IP packet from Host-x to Host-y) to look up the NAT Session the
   embedded packet belongs to. If the NAT device does not have an
   active mapping for the embedded payload, the NAT SHOULD silently
   drop the ICMP error packet. Otherwise, the NAT device SHOULD use
   the matching NAT Session to translate the embedded payload.

   In the outer header, the destination IP address will remain
   unchanged, as the IP addresses for Host-x is already in the external
   domain. If the ICMP error message is generated by Host-y, the NAT
   device must simply use the NAT Session to translate the source IP
   address Host-y to Host-y'. However, if the ICMP error message is
   generated by the intermediate node Router-y, and the NAT device
   does not have a translation entry for Router-y within NAT, the NAT
   device must simply use its own IP address in the external domain to
   translate the source IP address.

   REQ-5: If a NAT device receives an ICMP error packet from private
   realm, and the NAT does not have an active mapping for the embedded
   payload, the NAT SHOULD silently drop the ICMP error packet. If the
   the NAT has active mapping for the embedded payload, then the NAT
   MUST transparently forward the ICMP error message, without modifying
   the ICMP error type or code as follows.
   a) The NAT MUST revert the IP and transport headers of the embedded
   IP packet to their original form, using the matching mapping.
   b) If the NAT device has active mapping for the ICMP error packet
   originator, the NAT MUST translate the source IP address of the
   ICMP error packet with the public IP address in the mapping.
   Otherwise, the NAT MUST translate the source IP address of the ICMP
   error packet with its own public IP address.
   c) Lastly, the NAT MUST update the IP and ICMP checksums in the
   outer headers to reflect the above changes.


4.3. NAT Sessions Pertaining to ICMP Error Payload

   While processing an ICMP error packet, a NAT device MUST NOT
   refresh or delete the NAT Session that pertains to the embedded
   payload within the ICMP error packet. This is in spite of the
   fact that the NAT device uses the NAT Session to translate the



Srisuresh, et. al.                                              [Page 8]


Internet-Draft    NAT Behavioral Requirements for ICMP          May 2006


   embedded payload. By not effecting the NAT Sessions, the NAT
   device is able to retain them, even as someone spoofs ICMP error
   messages pertaining to the NAT Sessions.

   REQ-6: While processing an ICMP error packet, a NAT device MUST NOT
   refresh or delete the NAT Session that pertains to the embedded
   payload within the ICMP error packet.


5. Rejection of Outbound Flows Disallowed by NAT

   A NAT device typically permits all outbound sessions. However,
   a NAT device may disallow some outbound sessions due to resource
   constraints or administration considerations. For example, a NAT
   device may not permit the first packet of a new outbound session,
   if the NAT device is out of resources (out of addresses or TCP/UDP
   ports or a NAT Session resource) to set up a state for the session,
   or, the specific session is administratively restricted by the NAT
   device.

   When the first packet of an outbound flow is prohibited by a NAT
   device due to resource constraints or administration considerations,
   the NAT device SHOULD send ICMP destination unreachable message.
   Section 5.2.7.1 of [RFC1812] recommends routers to use ICMP code 13
   (Communication administratively prohibited) when they
   administratively filter packets. As such, a NAT device MUST use
   ICMP code 13 when generating an ICMP error message.

   REQ-7: When a NAT device is unable to establish a NAT Session for a
   new flow due to resource constraints or administrative restrictions,
   the NAT device SHOULD send an ICMP destination unreachable message,
   with a code of 13 (Communication administratively prohibited) to the
   sender, and drop the original packet.

6. Conformance to RFC 1812

   A NAT device is inherently an intermediate router that forwards
   IP packets between private and public realms. As such, the NAT
   device MUST conform to all the requirements of a router, as
   specified in [RFC1812]. Section 5.2.7.1 of [RFC1812] states that
   a router MUST also be able to generate ICMP Destination Unreachable
   messages and SHOULD choose a response code that most closely matches
   the reason the message is being generated.

   Note, however, NAT devices also function as hosts on the Internet
   and are bound by the conformance requirements in [RFC1122]. Protocol
   specific Behave documents ([BEH-UDP], [BEH-TCP]) identify instances
   where a NAT device should deviate from RFC 1122. As such, the host



Srisuresh, et. al.                                              [Page 9]


Internet-Draft    NAT Behavioral Requirements for ICMP          May 2006


   behavior requirements of NAT devices specified in the protocol
   specific behave drafts take precedence over RFC 1122.

   The focus of this section is on conformance to router requirements.
   The following sub sections identify specific instances where a NAT
   device would be expected to conform to RFC 1812.

6.1. IP packet fragmentation

   Many networking applications (which include TCP as well as UDP based
   applications) depend on ICMP error messages from the network to
   perform end-to-end path MTU discovery [PMTU]. Once path MTU is
   discovered, an application that chooses to avoid fragmentation may
   do so by originating IP packets that fit within the maximum Path MTU
   enroute and setting the DF (Don't Fragment) bit in the IP header, so
   the intermediate nodes enroute do not fragment the IP packets. The
   following sub-sections discuss the need for NAT devices to honor the
   DF bit in the IP header and be able to generate "Packet too big"
   ICMP error message when they cannot forward the IP packet without
   fragmentation. Also discussed is the need to seamlessly forward
   ICMP error messages generated by other intermediate devices.


6.1.1. Generating "Packet too Big" ICMP error Message

   When a router is unable to forward a datagram because it exceeds
   the MTU of the nexthop network and its Don't Fragment (DF) bit is
   set, the router is required to return an ICMP Destination
   Unreachable message to the source of the datagram, with the Code
   indicating "fragmentation needed and DF set". Further, the router
   MUST include the MTU of that nexthop network in the low order
   16 bits of the ICMP header, as specified in [PMTU].

   A NAT device MUST honor the DF bit in the IP header of the
   packets transiting the device. If the DF bit is set and the
   MTU on the forwarding interface of the NAT device is such that
   the IP datagram cannot be forwarded without fragmentation, the
   NAT device MUST issue a "packet too big" ICMP message (ICMP
   type 3, Code 4) with a suggested MTU back to the sender and
   drop the original IP packet. The sender will resend after
   taking the appropriate corrective action.

   If the DF bit is not set and the MTU on the forwarding interface
   of the NAT device mandates fragmentation, the NAT device must
   simply send this fragmented, just as any router does [RFC1812].

6.1.2. Forwarding "Packet too big" ICMP Error Message




Srisuresh, et. al.                                             [Page 10]


Internet-Draft    NAT Behavioral Requirements for ICMP          May 2006


   This is flip side of the argument for the above section. By
   virtue of the address translation NAT performs, NAT may end
   up being the recipient of "Packet too big" message.

   When NAT device is the recipient of "Packet too big"
   ICMP message from the network, the NAT device MUST forward the
   ICMP message back to the intended recipient, pursuant to the
   previously stated requirements REQ-3, REQ-4, REQ-5 and REQ-6.


6.2. Generating "Time Exceeded" Error Message

   Section 5.2.7.3 of RFC 1812 says that a router MUST generate
   "Time Exceeded" ICMP error message when it discards a packet due
   to an expired TTL field. A router MAY have a per interface option
   to disable origination of these messages on that interface, but that
   option MUST default to allowing the messages to be originated.

6.3. RFC 1812 Conformance Requirements summary

   REQ-8: A NAT device MUST conform to RFC 1812 in IP packet handling.
   Below are specific instances where a NAT device MUST conform to
   RFC 1812.
   a) If DF bit is set on a transit IP packet and the NAT
   device cannot forward the packet without fragmentation, the
   NAT device MUST send a "Packet too big" ICMP message (ICMP
   type 3, Code 4) with a suggested MTU back to the sender and
   drop the original IP packet.
   b) A NAT device  MUST, by default, generate "Time Exceeded" ICMP
   error message when it discards a packet due to an expired TTL field,
   unless explicitly configured otherwise.

7. Summary of Requirements

   This section summarizes the requirements discussed in the preceding
   sections.

   REQ-1: A NAT device MUST permit ICMP query based applications to be
   initiated from private hosts to the external hosts.
   a) NAT mapping of ICMP Query identifiers SHOULD be external host
   independent.

   REQ-2: An ICMP Query session mapping timer MUST NOT expire in less
   than 60 seconds.
   a) The value of NAT ICMP mapping timer MAY be configurable.

   REQ-3:  When an ICMP error packet is received, the NAT device SHOULD
   verify that the checksum(s) of the embedded IP packet is not



Srisuresh, et. al.                                             [Page 11]


Internet-Draft    NAT Behavioral Requirements for ICMP          May 2006


   corrupted.
   a) If the IP checksum of the embedded payload fails, the NAT
   MUST drop the error packet.
   b) If the embedded payload is a complete TCP segment, the NAT device
   SHOULD validate the TCP checksum. If the transport checksum fails,
   the NAT device MUST drop the error packet.
   c) If the embedded payload is a complete UDP datagram and the UDP
   datagram contains non-zero checksum, the NAT device SHOULD validate
   the UDP checksum. If the transport checksum fails, the NAT device
   MUST drop the error packet.

   REQ-4: If a NAT device receives an ICMP error packet from external
   realm, and the NAT does not have an active mapping for the embedded
   payload, the NAT SHOULD silently drop the ICMP error packet. If the
   the NAT has active mapping for the embedded payload, then the NAT
   MUST transparently forward the ICMP error message, without modifying
   the ICMP error type or code as follows.
   a) The NAT MUST revert the IP and transport headers of the embedded
   IP packet to their original form, using the matching mapping.
   b) The NAT device MUST modify the destination IP address of the
   outer IP header to be same as the source IP address of the embedded
   IP packet after the translation.
   c) Lastly, the NAT MUST update the IP and ICMP checksums in the
   outer headers to reflect the above changes.

   REQ-5: If a NAT device receives an ICMP error packet from private
   realm, and the NAT does not have an active mapping for the embedded
   payload, the NAT SHOULD silently drop the ICMP error packet. If the
   the NAT has active mapping for the embedded payload, then the NAT
   MUST transparently forward the ICMP error message, without modifying
   the ICMP error type or code as follows.
   a) The NAT MUST revert the IP and transport headers of the embedded
   IP packet to their original form, using the matching mapping.
   b) If the NAT device has active mapping for the ICMP error packet
   originator, the NAT MUST translate the source IP address of the
   ICMP error packet with the public IP address in the mapping.
   Otherwise, the NAT MUST translate the source IP address of the ICMP
   error packet with its own public IP address.
   c) Lastly, the NAT MUST update the IP and ICMP checksums in the
   outer headers to reflect the above changes.

   REQ-6: While processing an ICMP error packet, a NAT device MUST NOT
   refresh or delete the NAT Session that pertains to the embedded
   payload within the ICMP error packet.

   REQ-7: When a NAT device is unable to establish a NAT Session for a
   new flow due to resource constraints or administrative restrictions,
   the NAT device SHOULD send an ICMP destination unreachable message,



Srisuresh, et. al.                                             [Page 12]


Internet-Draft    NAT Behavioral Requirements for ICMP          May 2006


   with a code of 13 (Communication administratively prohibited) to the
   sender, and drop the original packet.

   REQ-8: A NAT device MUST conform to RFC 1812 in IP packet handling.
   Below are specific instances where a NAT device MUST conform to
   RFC 1812.
   a) If DF bit is set on a transit IP packet and the NAT
   device cannot forward the packet without fragmentation, the
   NAT device MUST send a "Packet too big" ICMP message (ICMP
   type 3, Code 4) with a suggested MTU back to the sender and
   drop the original IP packet.
   b) A NAT device  MUST, by default, generate "Time Exceeded" ICMP
   error message when it discards a packet due to an expired TTL field,
   unless explicitly configured otherwise.


8. Security Considerations

   This document does not introduce any new security concerns related
   to ICMP error message handling in the NAT devices. However, the
   document does propose counter measures to mitigate security concerns
   that already exist with ICMP error messages.

   [ICMP-ATK] lists a number of ICMP attacks that can be directed
   against end host TCP stacks and suggests remedies to counter the
   attacks. [TCP-SOFT] describes improvements to the handling of
   ICMP error messages in many of the existing TCP/IP stacks, including
   Linux. Section 4 of this document describes a number of measures by
   which NAT devices should validate and update the embedded payload
   in ICMP error messages prior to forwarding. These measure ensure
   that NATs forward the ICMP error messages reliably, as stipulated
   in [ICMP-ATK].

   For example, a rogue entity could bombard the NAT device with a
   large number of ICMP errors. If the NAT device did not
   validate the legitimacy of the ICMP error packets, the ICMP errors
   would be forwarded directly to the end nodes. End hosts not capable
   of defending themselves against such bogus ICMP error attacks could
   be adversely impacted by such attacks. Req-3 recommends validating
   embedded payload prior to forwarding. Checksum validation by itself
   does not protect end hosts from attacks. However, checksum
   validation mitigates endhosts from malformed ICMP error attacks.
   Req-4 and Req-5 further mandate that when a NAT device does not find
   a mapping selection for the embedded payload, the NAT should drop
   the ICMP error packets, without forwarding.

   A rogue source could also try and send bogus ICMP error messages for
   the active NAT sessions, with an intent to destroy the sessions.



Srisuresh, et. al.                                             [Page 13]


Internet-Draft    NAT Behavioral Requirements for ICMP          May 2006


   Req-6 averts such an attack by ensuring that an ICMP error message
   does not effect the state of a session on the NAT device.


9.  IANA Considerations

   There are no IANA considerations.


10. Acknowledgements

   The authors wish to thank Fernando Gont and Dan Wing for providing
   valuable input and offering generous amount of their time in shaping
   the ICMP requirements. Their valuable feedback makes this document a
   better read. The authors highly appreciate that.


Normative References

[BEH-UDP]   F. Audet and C. Jennings, "NAT Behavioral Requirements for
            Unicast UDP", draft-ietf-behave-nat-udp-04.txt (Work In
            Progress), September 2005.

[BEH-TCP]   Guha, S., Biswas, K., Ford, B., Francis, P., Sivakumar, S.,
            and Srisuresh, P., "NAT Behavioral Requirements for
            Unicast TCP", draft-ietf-behave-tcp-00.txt (Work In
            Progress), February 2006.

[ICMP]      Postel, J., "Internet Control Message Protocol", STD 5,
            RFC 792, September 1981.

[NAT-TERM]  P. Srisuresh and M. Holdrege, "IP Network Address Translator
            (NAT) Terminology and Considerations", RFC 2663, August
            1999.

[NAT-TRAD]  P. Srisuresh and K. Egevang, "Traditional IP Network Address
            Translator (Traditional NAT)", RFC 3022, January 2001.

[PMTU]      Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
            November 1990.

[RFC1147]   Stine, R., "FYI on a Network Management Tool Catalog: Tools
            for Monitoring and Debugging TCP/IP Internets and
            Interconnected Devices", RFC 1147, April 1990.

[RFC1812]   Baker, F., "Requirements for IP Version 4 Routers",
            RFC 1812, June 1995.




Srisuresh, et. al.                                             [Page 14]


Internet-Draft    NAT Behavioral Requirements for ICMP          May 2006


[RFC2119]   Bradner, S., "Key words for use in RFCs to Indicate
            Requirement Levels", BCP 14, RFC 2119, March 1997.



Informative References

[BEH-APP]   Ford, B., Srisuresh, P., and Kegel, D., "Application Design
            Guidelines for Traversal through Network Address
            Translators", draft-ford-behave-app-02.txt (Work In
            Progress), March 2006.

[ICMP-ATK]  Gont, F., "ICMP attacks against TCP",
            draft-ietf-tcpm-icmp-attacks-00.txt (Work In Progress),
            February 2006.

[MIDCOM]    Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A. and
            Rayhan, A., "Middlebox communication architecture and
            framework", RFC 3303, August 2002.

[NAT-PMP]   Cheshire, S., Krochmal, M., and Sekar, K., "NAT Port
            Mapping Protocol (NAT-PMP)", draft-cheshire-nat-pmp-00.txt
            (Work In Progress), June 2005.

[NSIS-NSLP] Stiemerling,M., Tschofenig, H., Aoun, C., and, Davies, E.,
            "NAT/Firewall NSIS Signaling Layer Protocol (NSLP)",
            draft-ietf-nsis-nslp-natfw-11.txt (Work In Progress),
            April 2006.

[RFC1122]   Braden, R., "Requirements for Internet Hosts --
            Communication Layers", RFC 1122, October 1989.

[RSIP]      M. Borella, J. Lo, D. Grabelsky, and G. Montenegro, "Realm
            Specific IP: Framework", RFC 3102, October 2001.

[SOCKS]     Leech, M., Ganis, M., Lee, Y., Kuris, R.,Koblas, D., and,
            Jones, L., "SOCKS Protocol Version 5", RFC 1928,
            March 1996.

[TCP-SOFT]  Gont, F., "TCP's Reaction to Soft Errors",
            draft-ietf-tcpm-tcp-soft-errors-00.txt (Work In Progress),
            February 2006.

[UNSAF]     Daigle, L., and IAB, "IAB Considerations for UNilateral
            Self-Address Fixing (UNSAF) Across Network Address
            Translation", RFC 3424, November 2002.

[UPNP]      UPnP Forum, "Internet Gateway Device (IGD) Standardized



Srisuresh, et. al.                                             [Page 15]


Internet-Draft    NAT Behavioral Requirements for ICMP          May 2006


            Device Control Protocol V 1.0", November 2001.
            http://www.upnp.org/standardizeddcps/igd.asp


Author's Addresses:

   Pyda Srisuresh
   Consultant
   20072 Pacifica Dr.
   Cupertino, CA 95014
   U.S.A.
   Phone: (408)836-4773
   E-mail: srisuresh@yahoo.com

   Bryan Ford
   Computer Science and Artificial Intelligence Laboratory
   Massachusetts Institute of Technology
   77 Massachusetts Ave.
   Cambridge, MA 02139
   U.S.A.
   Phone: (617) 253-5261
   E-mail: baford@mit.edu
   Web: http://www.brynosaurus.com/

   Senthil Sivakumar
   Cisco Systems, Inc.
   7100-8 Kit Creek Road
   PO Box 14987
   Research Triangle Park, NC  27709-4987
   U.S.A.
   Phone: +1 919 392 5158
   Email: ssenthil@cisco.com

   Saikat Guha
   Cornell University
   331 Upson Hall
   Ithaca, NY  14853
   U.S.A.
   Email: saikat@cs.cornell.edu

Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information



Srisuresh, et. al.                                             [Page 16]


Internet-Draft    NAT Behavioral Requirements for ICMP          May 2006


   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Copyright Statement

   Copyright (C) The Internet Society (2006).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.













Srisuresh, et. al.                                             [Page 17]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/