BEHAVE WG P. Srisuresh
Internet Draft Consultant
Expires: April 20, 2006 B. Ford
M.I.T.
S. Sivakumar
Cisco Systems
October 2005
ICMP Protocol Behavioral Requirements
for Network Address Translators
<draft-srisuresh-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/1id-abstracts.html
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 ICMP
protocol. The objective of this memo is to make NAT middleboxes
more predictable and compatible with diverse application protocols
that traverse the device. Companion documents provide behavioral
recommendations specific to TCP and UDP.
Srisuresh, Ford, Sivakumar [Page 1]
Internet=Draft NAT Behavioral Requirements for ICMP October 2005
Table of Contents
1. Introduction & Scope ..........................................
2. ICMP Behavioral Requirements ..................................
2.1. ICMP query packet handling .....,,.......................
2.2. ICMP Error packet handling .....,,.......................
2.3. Rejection of IP packets not permitted by NAT ............
2.4. Path MTU Discovery ......................................
3. Summary of Requirements .......................................
4. Security Considerations .......................................
1. Introduction & Scope
As pointed out in RFC 3424 [UNSAF], "From observations of deployed
networks, it is clear that different NAT boxes' implementation vary
widely in terms of how they handle different traffic and addressing
cases." This wide degree of variability is one part of what
contributes to the overall brittleness introduced by NATs and makes
it extremely difficult to predict how any given protocol will behave
on a network traversing NATs. This document defines a specific set
of requirements for NAT behavior that will reduce unpredictability
and enable applications to traverse them reliably.
The requirements specified here apply to all NAT variations
described in RFC 2663 [NAT-TERM], including Traditional
NAT (i.e., Basic NAT and NAPT), Bi-directional NAT, and Twice NAT.
Traditional NAT inherently mandates a certain level of firewall like
functionality. However, firewall functionality in general is out of
the scope of this specification.
NAT traversal strategies that involve explicit signalling between the
application and the NAT [SOCKS, RSIP, MIDCOM, UPNP] are out of the
scope of this document.
This document focusses 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, Ford, Sivakumar [Page 2]
Internet=Draft NAT Behavioral Requirements for ICMP October 2005
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 MUST transparantly forward ICMP query packets between
endnodes. This involves translating the IP header. The NAPT device
MUST additionally modify the query ID and the associated checksum
in the ICMP header. The ICMP NAT Session timeout must be 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. This is
because applications (such as ping and traceroute) that are 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 Bindings and
the NAT Sessions for the whole duration.
REQ-1: A NAT device MUST transparantly forward all ICMP query
packets. The ICMP NAT Session timeout MUST be 30 seconds or
longer.
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 endnode. 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
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.
Srisuresh, Ford, Sivakumar [Page 3]
Internet=Draft NAT Behavioral Requirements for ICMP October 2005
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
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.
Srisuresh, Ford, Sivakumar [Page 4]
Internet=Draft NAT Behavioral Requirements for ICMP October 2005
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 Binding 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. The NAT device MUST translate not only the
outer IP header, but also the embedded payload within the ICMP error
packet. In the case the ICMP error packet is originated by a node
for which the NAT device has no Binding, the NAT device MUST use
its own IP address in the realm of the target node to translate
the originating node IP address.
2.2.1. NAT Sessions pertaining to ICMP error packets
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
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
Srisuresh, Ford, Sivakumar [Page 5]
Internet=Draft NAT Behavioral Requirements for ICMP October 2005
payload within the ICMP error packet.
2.3. Rejection of IP packets not permitted by NAT
Unlike a router, a NAT device is session oriented and is restrictive
in the packes it permits. A NAT device may also be restrictive due
to NAT specific resource constraints. For example, a NAT device may
not permit a packet across, if the packet happens to be the first
packet of a new session and 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.
In the case where a packet is prohibited by a NAT device to
traverse through it due to resource/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 prior to dropping the
packet. 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 inbound 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
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
Srisuresh, Ford, Sivakumar [Page 6]
Internet=Draft NAT Behavioral Requirements for ICMP October 2005
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 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 MUST transparantly forward all ICMP query
packets. The ICMP NAT Session timeout MUST be 30 seconds or
longer.
REQ-2: A NAT device MUST transparently forward ICMP error packets
to the target end node. The NAT device MUST translate not only the
outer IP header, but also the embedded payload within the ICMP error
packet. In the case the ICMP error packet is originated by a node
for which the NAT device has no Binding, the NAT device MUST use
its own IP address in the realm of the target node to translate
the originating node IP address.
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 inbound packet is prohibited by a NAT device due to
resource/authorization considerations, the NAT device SHOULD send
Srisuresh, Ford, Sivakumar [Page 7]
Internet=Draft NAT Behavioral Requirements for ICMP October 2005
ICMP destination unreachable message, with a code of 10 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
None yet.
Normative References
[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.
[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.
[PRIV-ADDR] Y. Rekhter, B. Moskowitz, D. Karrenberg, G. J. de Groot, and
E. Lear, "Address Allocation for Private Internets", RFC
1918, February 1996.
Informative References
[BEH-APP] B. Ford, P. Srisuresh, and D. Kegel, "Application Design
Guidelines for Traversal of Network Address Translators",
draft-ford-behave-nat-app-01.txt (Work In Progress),
October 2005.
[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] P. Srisuresh, S. Sivakumar, K. Biswas, and, B. Ford, "NAT
Behavioral Requirements for TCP",
Srisuresh, Ford, Sivakumar [Page 8]
Internet=Draft NAT Behavioral Requirements for ICMP October 2005
draft-sivakumar-behave-nat-tcp-req-02.txt (Work In
Progress), October 2005.
[PMTU] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
November 1990.
[RFC1812] Baker, F., "Requirements for IP Version 4 Routers",
RFC 1812, June 1995.
[UNSAF] L. Daigle and IAB, "IAB Considerations for UNilateral Self-
Address Fixing (UNSAF) Across Network Address Translation",
RFC 3424, November 2002.
Author's Address
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/
Pyda Srisuresh
Consultant
20072 Pacifica Dr.
Cupertino, CA 95014
U.S.A.
Phone: (408)836-4773
E-mail: srisuresh@yahoo.com
Senthil Sivakumar
Cisco Systems, Inc.
170 West Tasman Dr.
San Jose, CA 95134
U.S.A.
Phone:
Email: ssenthil@cisco.com
Copyright Statement
Copyright (C) The Internet Society (2005).
This document is subject to the rights, licenses and restrictions
Srisuresh, Ford, Sivakumar [Page 9]
Internet=Draft NAT Behavioral Requirements for ICMP October 2005
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.
Srisuresh, Ford, Sivakumar [Page 10]