BEHAVE WG P. Srisuresh
Internet Draft Consultant
Expires: December 8, 2006 B. Ford
M.I.T.
S. Sivakumar
Cisco Systems
S. Guha
Cornell U.
May 2006
NAT Behavioral Requirements for ICMP protocol
<draft-srisuresh-behave-nat-icmp-02.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. Acknowledgements ..............................................
1. Introduction and Scope
This document is an adjunct to [BEH-UDP] and [BEH-TCP], which define
requirements for NATs when handling 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
applications and NAT devices, namely [SOCKS, RSIP, MIDCOM, UPNP] are
also out of the scope of this document.
This document focuses strictly on the behavior of the NAT device,
Srisuresh, et. al [Page 2]
Internet-Draft NAT Behavioral Requirements for ICMP May 2006
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.
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 for NAT devices 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 [RFC2663] 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 [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 the fact that have 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 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.
3. ICMP Query Handling
Srisuresh, et. al [Page 3]
Internet-Draft NAT Behavioral Requirements for ICMP May 2006
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 Identifier (also referred simply as
'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 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
Session timeout to a very large duration (say, much larger than 60
secs) could potentially tie up NAT resources. Caution is warranted
as applications such as ICMP Ping and ICMP traceroute [RFC 1147],
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.
Srisuresh, et. al [Page 4]
Internet-Draft NAT Behavioral Requirements for ICMP May 2006
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 confirm 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 donot 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 8 bytes 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
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,
Srisuresh, et. al [Page 5]
Internet-Draft NAT Behavioral Requirements for ICMP May 2006
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 |
+-------------+
|
----------------+-------+--------
| ^ |
| | (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
Srisuresh, et. al [Page 6]
Internet-Draft NAT Behavioral Requirements for ICMP May 2006
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
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.
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
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.
Srisuresh, et. al [Page 7]
Internet-Draft NAT Behavioral Requirements for ICMP May 2006
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
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. For example, a NAT device may not permit the first
packet of a new outbound session, if the NAT device is out of
Srisuresh, et. al [Page 8]
Internet-Draft NAT Behavioral Requirements for ICMP May 2006
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 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 an outbound flow is prohibited by a NAT device due to
resource or authorization consideration, the NAT device SHOULD send
ICMP destination unreachable message, with a code of 13
(Communication administratively prohibited) to the sender prior to
dropping 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 confirm 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
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 confirm to RFC 1812.
6.1. IP packet fragmentation
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
Srisuresh, et. al [Page 9]
Internet-Draft NAT Behavioral Requirements for ICMP May 2006
packets. Path discovery is not restricted to TCP or UDP based
application and applies to all IP protocols. For instance, TCP
connections often set 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.
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 RFC 1191.
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
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
previosuly 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.
Srisuresh, et. al [Page 10]
Internet-Draft NAT Behavioral Requirements for ICMP May 2006
6.3. RFC 1812 Conformance Requirements summary
REQ-8: A NAT device MUST confirm to RFC 1812 in IP packet handling.
Below are specific instances where a NAT device MUST confirm 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 generate "Time Exceeded" ICMP error message
when it discards a packet due to an expired TTL field.
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
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 drope 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
Srisuresh, et. al [Page 11]
Internet-Draft NAT Behavioral Requirements for ICMP May 2006
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.
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 an outbound flow is prohibited by a NAT device due to
resource or authorization consideration, the NAT device SHOULD send
ICMP destination unreachable message, with a code of 13
(Communication administratively prohibited) to the sender prior to
dropping the original packet.
REQ-8: A NAT device MUST confirm to RFC 1812 in IP packet handling.
Below are specific instances where a NAT device MUST confirm 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 generate "Time Exceeded" ICMP error message
when it discards a packet due to an expired TTL field.
8. Security Considerations
This document does not introduce any new security concerns related
Srisuresh, et. al [Page 12]
Internet-Draft NAT Behavioral Requirements for ICMP May 2006
to ICMP error message handling in the NAT devices. However, the
document does propose cunter 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 decribes 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.
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. 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.,
Srisuresh, et. al [Page 13]
Internet-Draft NAT Behavioral Requirements for ICMP May 2006
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.
[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.
[RFC1191] Mogul, J., and Deering, S., "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.
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.
[RFC1122] Braden, R., "Requirements for Internet Hosts --
Communication Layers", RFC 1122, October 1989.
[UNSAF] Daigle, L., and IAB, "IAB Considerations for UNilateral
Srisuresh, et. al [Page 14]
Internet-Draft NAT Behavioral Requirements for ICMP May 2006
Self-Address Fixing (UNSAF) Across Network Address
Translation", RFC 3424, November 2002.
[ICMP-ATK] Gont, F., "ICMP attacks against TCP",
draft-ietf-tcpm-icmp-attacks-00.txt (Work In Progress),
February 2006.
[TCP-SOFT] Gont, F., "TCP's Reaction to Soft Errors",
draft-ietf-tcpm-tcp-soft-errors-00.txt (Work In Progress),
February 2006.
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
Srisuresh, et. al [Page 15]
Internet-Draft NAT Behavioral Requirements for ICMP May 2006
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
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 16]