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

Versions: 00 01 02 draft-ietf-behave-nat-icmp

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


                NAT Behavioral Requirements for ICMP protocol
                <draft-srisuresh-behave-nat-icmp-01.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 middleboxes
   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        March 2006



Table of Contents

   1. Introduction & Scope ..........................................
   2. ICMP Behavioral Requirements ..................................
      2.1. ICMP Query Packet Handling .....,,........................
      2.2. ICMP Error Packet Handling .....,,........................
           2.2.1. NAT Sessions Pertaining to ICMP Error Packets .....
      2.3. Rejection of Outbound IP Packets Disallowed by NAT .......
      2.4. Path MTU Discovery .......................................
           2.4.1. Honoring the DF Bit in IP header ..................
           2.4.2. Honoring the "Packet too big" ICMP Error Message ..
   3. Summary of Requirements .......................................
   4. Security Considerations .......................................


1. Introduction & Scope

   This document is adjunct to [BEH-UDP] and [BEH-TCP], which define
   requirements for NATs that handle unicast UDP and TCP traffic.
   The purpose of this document is to set requirements for NATs with
   regard to ICMP messages.

   The requirements of this specification apply to Traditional NATs as
   described in RFC 2663 [2].

   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. Application and Operating System (OS) aspects of ICMP
   NAT traversal are out-of-scope.

   NAT traversal strategies that involve explicit signaling between the
   application and the NAT [SOCKS, RSIP, MIDCOM, UPNP] are 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
   companion Behave documents.

   The following section lists the behavioral recommendations to the
   NAT device vendors in conjunction with handling ICMP protocol.
   Section 3 summarizes all the requirements in one place.




Srisuresh et. al.                                               [Page 2]


Internet-Draft    NAT Behavioral requirements for ICMP        March 2006



2. ICMP Behavioral Requirements

   This section lists the behavioral requirements for a NAT device
   when processing ICMP packets. Even though ICMP is a transport
   protocol on top of IP, ICMP packet processing is often considered
   an integral of IP and is independent of other transport
   protocols. In the following sub sections, requirements are
   discussed in detail along with the rationale behind them.

2.1. ICMP Query Packet Handling

   A NAT device SHOULD 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
   involves translating the IP header. The NAPT device SHOULD
   additionally modify the query ID and the associated checksum in the
   ICMP header if there is an outstanding query with the same ID.

   It is to RECOMMENDED that the administrator be allowed to configure
   the ICMP session timeout. Typically, the ICMP NAT Session timeout
   is set to 30 seconds or longer. Setting the ICMP NAT Session timeout
   to a very large duration (say, much larger than 30 secs) longer
   could potentially tie up NAT resources. Caution is warranted as
   applications (such as ping and traceroute) built on top of ICMP
   query messages 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-1: A NAT device SHOULD transparently forward any ICMP query
   packets initiated from the nodes behind NAT devices and the
   responses to these query packets in the opposite direction. It is
   RECOMMENDED that the administrator be allowed to configure the
   ICMP session timeout.

2.2. ICMP Error Packet Handling

   A NAT device MUST transparently forward ICMP error messages ([ICMP])
   it receives from intermediate or end nodes in either realm to the
   intended end node. Unlike other IP packets, the basis for
   translation of an ICMP error packet is the NAT Session to which the
   packet embedded within the ICMP error message payload belongs to,
   not the IP and ICMP headers in the outer layer.

   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



Srisuresh et. al.                                               [Page 3]


Internet-Draft    NAT Behavioral requirements for ICMP        March 2006


   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    |
               +-------------+
                      |
      ----------------+-------+--------
                              | ^                  |
                              | | (Host-y, Host-x) |
                              | |                  v
                            Host-y

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


   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 and use the NAT Session
   to translate the embedded payload. The NAT device must also use the



Srisuresh et. al.                                               [Page 4]


Internet-Draft    NAT Behavioral requirements for ICMP        March 2006


   NAT Session to translate 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.

   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 and use the NAT
   Session to translate the embedded payload. The NAT device must also
   use the NAT Session to translate the outer IP header. 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, the NAT device will not have had a
   translation entry for Router-y within the NAT Session. The NAT may
   also not have an Address mapping in place for Router-y. In such a
   case, the NAT device must simply use its own IP address in the
   external domain to translate the source IP address.

   Changes to ICMP error message ([ICMP]) MUST include changes to IP and
   ICMP headers on the outer layer as well as changes to the relevant
   IP and transport headers of the packet embedded within the ICMP-error
   message payload. Section 4.3 of the RFC 3022 describes the various
   items within the ICMP error message that MUST be translated by the
   NAT device.

   REQ-2: A NAT device MUST transparently forward ICMP error packets
   to the target end node, so long as the NAT has active mapping for
   for the embedded payload. If the NAT does not have an active
   mapping for the embedded payload, the NAT should silently drop the
   ICMP error packet. In the case the ICMP error packet is originated
   by a node in the private realm for which the NAT device has no
   mapping, the NAT device MUST use its own IP address in the public
   realm to translate the originating node IP address in the outer
   IP header.

2.2.1. NAT Sessions Pertaining to ICMP Error Packets

   While processing an ICMP error packet, a NAT device MUST NOT



Srisuresh et. al.                                               [Page 5]


Internet-Draft    NAT Behavioral requirements for ICMP        March 2006


   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
   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-3: 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.


2.3. Rejection of Outbound IP Packets Disallowed by NAT

   A NAT device typically permits all outbound sessions. However,
   a NAT device may disallow some outbound sessions due to resource
   constraints. 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 may be administratively restricted by the NAT device.

   When a packet is prohibited by a NAT device due to resource or
   administration considerations, the NAT device SHOULD send ICMP
   destination unreachable message, with a code of 10 (Communication
   with destination host administratively prohibited) to the sender.
   Unfortunately, there is not another ICMP code  currently defined to
   indicate  "Communication with destination host port administratively
   prohibited". So, the same code should be used  for host as well as
   port filtering.

   REQ-4: When an outbound packet is prohibited by a NAT device due to
   resource/authorization consideration, the NAT device SHOULD send
   ICMP destination unreachable message, with a code of 10
   (Communication with destination host administratively prohibited)
   to the sender prior to dropping the packet.


2.4. Path MTU support

   IP fragmentation by intermediate nodes often results in
   degraded performance. In some cases, IP fragmentation by the
   intermediate nodes could even cause end-to-end communication
   to entirely fail. Many applications avoid fragmentation in
   the network by originating IP packets that fit within the
   maximum Path MTU enroute and setting the DF (Don't Fragment)
   bit so the intermediate nodes enroute do not fragment the
   packets. For example, a number of TCP connections have the



Srisuresh et. al.                                               [Page 6]


Internet-Draft    NAT Behavioral requirements for ICMP        March 2006


   DF bit set in the IP header of the TCP segments they
   transmit. Likewise, IP based VPN tunnels also often set the
   DF bit on the external IP encapsulation.

2.4.1. Honoring the DF Bit in IP header

   A NAT device MUST honor the DF bit in the IP header of the
   packets that transit 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]

   REQ-5: 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.

2.4.2. Honoring the "Packet too big" ICMP Error Message

   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 simply
   forward the ICMP message back to the intended recipient, as
   stated in REQ-2.


3. Summary of Requirements

   This section summarizes the requirements discussed at length in the
   preceding section.

   REQ-1: A NAT device SHOULD transparently forward any ICMP query
   packets initiated from the nodes behind NAT devices and the
   responses to these query packets in the opposite direction. It is
   RECOMMENDED that the administrator be allowed to configure the
   ICMP session timeout.

   REQ-2: A NAT device MUST transparently forward ICMP error packets



Srisuresh et. al.                                               [Page 7]


Internet-Draft    NAT Behavioral requirements for ICMP        March 2006


   to the target end node, so long as the NAT has active mapping for
   for the embedded payload. If the NAT does not have an active
   mapping for the embedded payload, the NAT should silently drop the
   ICMP error packet. In the case the ICMP error packet is originated
   by a node in the private realm for which the NAT device has no
   mapping, the NAT device MUST use its own IP address in the public
   realm to translate the originating node IP address in the outer
   IP header.

   REQ-3: 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-4: When an outbound packet is prohibited by a NAT device due to
   resource/authorization consideration, the NAT device SHOULD send
   ICMP destination unreachable message, with a code of 10
   (Communication with destination host administratively prohibited)
   to the sender prior to dropping the packet.

   REQ-5: 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.


4. Security Considerations

   This memo raises no new security issues.


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.

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




Srisuresh et. al.                                               [Page 8]


Internet-Draft    NAT Behavioral requirements for ICMP        March 2006


[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.

[PRIV-ADDR] Y. Rekhter, B. Moskowitz, D. Karrenberg, G. J. de Groot, and
            E. Lear, "Address Allocation for Private Internets", RFC
            1918, February 1996.

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


Informative References

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


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



Srisuresh et. al.                                               [Page 9]


Internet-Draft    NAT Behavioral requirements for ICMP        March 2006


   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
   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



Srisuresh et. al.                                              [Page 10]


Internet-Draft    NAT Behavioral requirements for ICMP        March 2006


   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 11]


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