< draft-ietf-behave-nat-icmp-03.txt   draft-ietf-behave-nat-icmp-04.txt >
Intended Status: Best Current Practice Intended Status: Best Current Practice
BEHAVE WG P. Srisuresh BEHAVE WG P. Srisuresh
Internet Draft Kazeon Systems Internet Draft Kazeon Systems
Expires: September 1, 2007 B. Ford Expires: December 30, 2007 B. Ford
M.I.T. M.I.T.
S. Sivakumar S. Sivakumar
Cisco Systems Cisco Systems
S. Guha S. Guha
Cornell U. Cornell U.
March 1, 2007 June 30, 2007
NAT Behavioral Requirements for ICMP protocol NAT Behavioral Requirements for ICMP protocol
<draft-ietf-behave-nat-icmp-03.txt> <draft-ietf-behave-nat-icmp-04.txt>
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 2, line 10 skipping to change at page 2, line 10
ICMP protocol. The objective of this memo is to make NAT devices ICMP protocol. The objective of this memo is to make NAT devices
more predictable and compatible with diverse application protocols more predictable and compatible with diverse application protocols
that traverse the devices. Companion documents provide behavioral that traverse the devices. Companion documents provide behavioral
recommendations specific to TCP, UDP and other protocols. recommendations specific to TCP, UDP and other protocols.
Table of Contents Table of Contents
1. Introduction and Scope ....................................... 1. Introduction and Scope .......................................
2. Terminology .................................................. 2. Terminology ..................................................
3. ICMP Query Handling .......................................... 3. ICMP Query Handling ..........................................
3.1. ICMP Query Mapping .....,,............................... 3.1. ICMP Query Mapping ......................................
3.2. ICMP Query Session Timeouts ............................. 3.2. ICMP Query Session Timeouts .............................
4. ICMP Error Forwarding ........................................ 4. ICMP Error Forwarding ........................................
4.1. ICMP Error Payload Validation .....,,.................... 4.1. ICMP Error Payload Validation ...........................
4.2. ICMP Error Packet Translation ........................... 4.2. ICMP Error Packet Translation ...........................
4.2.1. ICMP Error Packet Received from External Realm .... 4.2.1. ICMP Error Packet Received from External Realm ....
4.2.2. ICMP Error Packet Received from Private Realm ..... 4.2.2. ICMP Error Packet Received from Private Realm .....
4.3. NAT Sessions Pertaining to ICMP Error Payload ........... 4.3. NAT Sessions Pertaining to ICMP Error Payload ...........
5. Hairpinning Support for ICMP packets ......................... 5. Hairpinning Support for ICMP packets .........................
6. Rejection of Outbound Flows Disallowed by NAT ................ 6. Rejection of Outbound Flows Disallowed by NAT ................
7. Conformance to RFC 1812 ...................................... 7. Conformance to RFC 1812 ......................................
7.1. IP packet fragmentation ................................. 7.1. IP packet fragmentation .................................
7.1.1. Generating "Packet too Big" ICMP error Message .... 7.1.1. Generating "Packet too Big" ICMP error Message ....
7.1.2. Forwarding "Packet too big" ICMP Error Message .... 7.1.2. Forwarding "Packet too big" ICMP Error Message ....
skipping to change at page 2, line 50 skipping to change at page 2, line 50
define requirements for NATs when handling protocol-specific define requirements for NATs when handling protocol-specific
traffic. traffic.
The requirements of this specification apply to Traditional NATs as The requirements of this specification apply to Traditional NATs as
described in [NAT-TRAD]. Traditional NAT has two variations, namely, described in [NAT-TRAD]. Traditional NAT has two variations, namely,
Basic NAT and Network Address Port Translator (NAPT). Of these, NAPT Basic NAT and Network Address Port Translator (NAPT). Of these, NAPT
is by far the most commonly deployed NAT device. NAPT allows is by far the most commonly deployed NAT device. NAPT allows
multiple private hosts to share a single public IP address multiple private hosts to share a single public IP address
simultaneously. simultaneously.
This document only covers the ICMP aspects of NAT traversal. This document only covers the ICMP aspects of NAT traversal,
specifically the traversal of ICMP Query Messages and ICMP Error
messages. 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 document.
Traditional NAT inherently mandates a certain level of firewall-like In some cases, ICMP Message traversal behavior on a NAT device may
functionality. However, firewall functionality in general or any be overridden by local administrative policies. Some administrators
other middlebox functionality is out of the scope of this may choose to entirely prohibit forwarding of ICMP error messages
specification. across a NAT device. Some others may choose to prohibit ICMP query
based applications across a NAT device. These are local policies
and not within the scope of this document. For this reason, some
of the ICMP behave requirements listed in the document are preceded
with a constraint of local policy permitting.
This document focuses strictly on the behavior of the NAT device, This document focuses strictly on the behavior of the NAT device,
and not on the behavior of applications that traverse NATs. A and not on the behavior of applications that traverse NATs. A
separate document [BEH-APP] provides recommendations for application separate document [BEH-APP] provides recommendations for application
designers on how to make applications work robustly over NATs that designers on how to make applications work robustly over NATs that
follow the behavioral requirements specified here and the adjunct follow the behavioral requirements specified here and the adjunct
BEHAVE documents. BEHAVE documents.
ICMP is a signaling protocol for IP. ICMP message processing is Per [RFC1812], ICMP is a control protocol that is considered to be
often considered an integral of IP and is independent of other IP an integral part of IP, although it is architecturally layered upon
protocols. As such, many of the ICMP behavioral requirements IP - it uses IP to carry its data end-to-end. As such, many of the
discussed in this document apply to all IP protocols. ICMP behavioral requirements discussed in this document apply to all
IP protocols.
In case a requirement in this document conflicts with In case a requirement in this document conflicts with
protocol-specific BEHAVE requirement(s), protocol specific BEHAVE protocol-specific BEHAVE requirement(s), protocol specific BEHAVE
documents will take precedence. Note, the authors are not aware of documents will take precedence. The authors are not aware of any
any conflicts between this and any other IETF document at the time conflicts between this and any other IETF document at the time of
of this writing. this writing.
Section 2 describes the terminology used throughout the document. Section 2 describes the terminology used throughout the document.
Sections 3 is focused on requirements concerning ICMP query based Sections 3 is focused on requirements concerning ICMP query based
applications traversing a NAT device. Sections 4 and 5 describe applications traversing a NAT device. Sections 4 and 5 describe
requirements concerning ICMP error messages that traverse a NAT requirements concerning ICMP error messages traversing a NAT
device. Sections 6 and 7 describe requirements concerning ICMP error device. Sections 6 and 7 describe requirements concerning ICMP error
messages generated by a NAT device. Section 8 summarizes all the messages generated by a NAT device. Section 8 summarizes all the
requirements in one place. Section 9 has a discussion on security requirements in one place. Section 9 has a discussion on security
considerations. considerations.
2. Terminology 2. Terminology
Definitions for majority of the NAT terms used throughout the Definitions for majority of the NAT terms used throughout the
document may be found in [NAT-TERM] and [BEH-UDP]. The term document may be found in [NAT-TERM] and [BEH-UDP]. The term
"NAT Session" is adapted from [NAT-MIB] and denotes the entity "NAT Session" is adapted from [NAT-MIB] and denotes the entity
within a NAT device that represents the translation glue for a within a NAT device that represents the translation glue for a
session traversing the NAT device. session traversing the NAT device.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
ICMP messages are broadly grouped into two classes, namely "ICMP Section 3.2.2 of [RFC1122] broadly groups ICMP messages into two
Query" messages and "ICMP Error" messages in section 3.2.2 of classes, namely "ICMP Query" messages and "ICMP Error" messages.
[RFC1122]. The following explanations further illustrate these In addition, there are ICMP messages, created after [RFC1122] that
ICMP message classes. do not fall under either category. We refer them as "Post-1122 ICMP
Messages". All three ICMP message classes are described as follows.
ICMP Query Messages - All ICMP query messages are characterized ICMP Query Messages - ICMP query messages are characterized by an
by an Identifier field in the ICMP header. The Identifier field used Identifier field in the ICMP header. The Identifier field used
by the ICMP Query messages is also referred as "Query Identifier" or 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 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 query senders and responders as the equivalent of a TCP/UDP port to
identify an ICMP Query session. identify an ICMP Query session.
ICMP Error Messages - ICMP error messages provide signaling for IP. ICMP Error Messages - ICMP error messages provide signaling for IP.
All ICMP error messages are characterized by the fact that they All ICMP error messages are characterized by the fact that they
embed the original datagram that triggered the ICMP error message. embed the original datagram that triggered the ICMP error message.
The original datagram embedded within the ICMP Error payload is The original datagram embedded within the ICMP Error payload is
also referred as "Embedded packet", throughout the document. Unlike also referred as "Embedded packet", throughout the document. Unlike
ICMP Query messages, ICMP error messages do not have a Query Id in ICMP Query messages, ICMP error messages do not have a Query Id in
the ICMP header. the ICMP header.
Post-1122 ICMP Messages - ICMP messages that do not fall under
either of the above two classes are referred as "Post-1122 ICMP
Messages" throughout the document. For example, discovery ICMP
messages ([RFC1256]) are "request/response" type ICMP messages.
However, they are not characterized as ICMP Query Messages as they
do not have an "Identifier" field within the messages. Likewise,
there are other ICMP messages defined in [RFC4065] that do not
fall in either of ICMP Query or ICMP Error message categories, but
will be referred as Post-1122 ICMP error messages. A NAT MAY drop
or appropriately handle a post-1122 ICMP messages.
3. ICMP Query Handling 3. ICMP Query Handling
This section lists the behavioral requirements for a NAT device This section lists the behavioral requirements for a NAT device
when processing ICMP Query packets. The following sub sections when processing ICMP Query packets. The following sub sections
discuss requirements specific to ICMP Query handling in detail. discuss requirements specific to ICMP Query handling in detail.
3.1. ICMP Query Mapping 3.1. ICMP Query Mapping
A NAT device MUST permit ICMP query based applications to be A NAT device MUST permit ICMP query based applications to be
initiated from private hosts to the external hosts. ICMP Query initiated from private hosts to the external hosts. ICMP Query
mapping by NAT devices is necessary for current ICMP query based mapping by NAT devices is necessary for current ICMP query based
applications to work. Specifically, a NAT device must transparently applications to work. Specifically, a NAT device MUST transparently
forward any ICMP Query packets initiated from the nodes behind NAT forward any ICMP Query packets initiated from the nodes behind NAT
devices and the responses to these Query packets in the opposite devices and the responses to these Query packets in the opposite
direction. As specified in [NAT-TRAD], this requires translating the direction. As specified in [NAT-TRAD], this requires translating the
IP header. A NAPT device further translates the ICMP Query Id and IP header. A NAPT device further translates the ICMP Query Id and
the associated checksum in the ICMP header prior to forwarding. the associated checksum in the ICMP header prior to forwarding.
The mapping of ICMP Query identifier within the NAT device SHOULD The mapping of ICMP Query identifier within the NAT device SHOULD
be external endpoint independent. Say, an internal host A sent an 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, 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 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 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 queries to the same or different external host, the NAT device
SHOULD reuse the same Query Id mapping (i.e., map private host's 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 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 assigning a different mapping. This is similar to the "endpoint
independent mapping" requirement specified in the TCP and UDP independent mapping" requirement specified in the TCP and UDP
BEHAVE requirements [BEH-TCP, BEH-UDP]. BEHAVE requirements [BEH-TCP, BEH-UDP].
Below is justification for making the endpoint independent mapping Below is justification for making the endpoint independent mapping
for ICMP query IDs a SHOULD [RFC2119] requirement. ICMP Ping and for ICMP query IDs a SHOULD [RFC2119] requirement. ICMP Ping
ICMP traceroute ([RFC1470]) are two most commonly known legacy ([RFC1470]) and ICMP traceroute ([MS-TRCRT]) are two most commonly
applications built on top of ICMP query messages. Neither of these known legacy applications built on top of ICMP query messages.
applications require the ICMP Query Id to be retained across Neither of these applications require the ICMP Query Id to be
different sessions with external hosts. But, that may not be case retained across different sessions with external hosts. But, that
with future applications. In the future, when an endhost may not be case with future applications. In the future, when an
application reuses the same Query identifier in sessions with end host application reuses the same Query identifier in sessions
different target hosts, the endhost application might require that with different target hosts, the end host application might require
the endpoint identity (i.e., the tuple of IP address and Query that the endpoint identity (i.e., the tuple of IP address and Query
Identifier) appears the same across all its target hosts. Such a Identifier) appears the same across all its target hosts. Such a
requirement will be valid to make in an IP network without NAT requirement will be valid to make in an IP network without NAT
devices. When NAT devices enforce endpoint mapping that is external devices. When NAT devices enforce endpoint mapping that is external
host independent, the above assumption will be valid to make even in host independent, the above assumption will be valid to make even in
a world with NAT devices. Given the dichotomy between legacy a world with NAT devices. Given the dichotomy between legacy
applications not requiring endpoint independent mapping and future applications not requiring endpoint independent mapping and future
applications that might require it, the requirement level is kept applications that might require it, the requirement level is kept
at SHOULD [RFC2119]. at SHOULD [RFC2119].
REQ-1: A NAT device MUST permit ICMP query based applications to be REQ-1: When local policy permits, a NAT device MUST permit ICMP
initiated from private hosts to the external hosts. queries and their associated responses, when the query is initiated
from a private host.
a) NAT mapping of ICMP Query identifiers SHOULD be external host a) NAT mapping of ICMP Query identifiers SHOULD be external host
independent. independent.
3.2. ICMP Query Session Timeouts 3.2. ICMP Query Session Timeouts
When an application initiates an ICMP query that transits a NAT When an application initiates an ICMP query that transits a NAT
device, the NAT associates a timer to the ICMP query NAT session. device, the NAT associates a timer to the ICMP query NAT session.
This is so the ICMP query NAT session is freed up if the NAT session This is so the ICMP query NAT session is freed up if the NAT session
remains idle for longer than the timeout set by the timer. Query remains idle for longer than the timeout set by the timer. Query
response times can vary. ICMP query based application are primarily response times can vary. ICMP query based application are primarily
request/response driven. The ICMP Query session timeout requirement request/response driven. The ICMP Query session timeout requirement
is necessary for current ICMP query applications to work. is necessary for current ICMP query applications to work.
Ideally, the timeout should be set to Maximum Round Trip Time Ideally, the timeout should be set to Maximum Round Trip Time
(Maximum RTT). For an application initiating ICMP query message and (Maximum RTT). For the purposes of constraining the maximum RTT, the
waiting for a response for the query, the Maximum RTT would be the Maximum Segment Lifetime (MSL), defined in [RFC793] could be
sum total of Maximum Segment Lifetime (MSL) for the Query message considered a guideline to set packet lifetime. Per [RFC793], MSL is
and the MSL for the response message. In other words, Maximum RTT is the maximum amount of time a TCP segment can exist in a network
2x MSL. As per RFC 793, MSL is the maximum amount of time a TCP before being delivered to the intended recipient. This is the maximum
segment can exist in a network before being delivered to the duration an IP packet can be assumed to take to reach the intended
intended recipient. This is the maximum duration of time an IP destination node before declaring that the packet will no longer be
packet can be assumed to take to reach the intended destination node delivered. For an application initiating ICMP query message and
before declaring that the packet will no longer be delivered. The waiting for a response for the query, the Maximum RTT could in
recommended value for MSL is 120 seconds, even though several practice be constrained to be sum total of MSL for the Query message
implementations set this to 60 seconds or 30 seconds. When MSL is and MSL for the response message. In other words, Maximum RTT could
120 seconds, the Maximum RTT (2x MSL) would be 240 seconds. be constrained to no more than 2x MSL. The recommended value for MSL
in [RFC793] is 120 seconds, even though several implementations set
this to 60 seconds or 30 seconds. When MSL is 120 seconds, the
Maximum RTT (2x MSL) would be 240 seconds.
In practice, ICMP Ping and ICMP traceroute ([RFC1470]), the two most In practice, ICMP Ping ([RFC1470]) and ICMP traceroute ([MS-TRCRT]),
commonly known legacy applications built on top of ICMP query the two most commonly known legacy applications built on top of ICMP
messages take less than 10 seconds to complete a round trip, when query messages take less than 10 seconds to complete a round trip,
the target node is operational on the network. when the target node is operational on the network.
Setting the ICMP NAT session timeout to a very large duration (say, Setting the ICMP NAT session timeout to a very large duration (say,
240 seconds) could potentially tie up precious NAT resources such as 240 seconds) could potentially tie up precious NAT resources such as
query mappings and NAT Sessions for the whole duration. On the other query mappings and NAT Sessions for the whole duration. On the other
hand, setting the timeout very low can result in premature freeing hand, setting the timeout very low can result in premature freeing
of NAT resources and applications failing to complete gracefully. of NAT resources and applications failing to complete gracefully.
The ICMP Query session timeout needs to be a balance between the two The ICMP Query session timeout needs to be a balance between the two
extremes. 60 seconds timeout is a balance between the two extremes. extremes. 60 seconds timeout is a balance between the two extremes.
ICMP query session timer MUST not expire in less than 60 seconds. We ICMP query session timer MUST not expire in less than 60 seconds. We
RECOMMEND however that the administrator(s) be allowed to configure RECOMMEND however that the administrator(s) be allowed to configure
the timer. the timer.
REQ-2: An ICMP Query session timer MUST NOT expire in less than 60 REQ-2: An ICMP Query session timer MUST NOT expire in less than 60
seconds. seconds.
a) It is RECOMMENDED that the ICMP Query session timer be made a) It is RECOMMENDED that the ICMP Query session timer be made
configurable. configurable.
4. ICMP Error Forwarding 4. ICMP Error Forwarding
Applications depend on ICMP error messages from end hosts and Many applications make use of ICMP error messages from end hosts and
intermediate devices being forwarded reliably by the NAT devices. intermediate devices to shorten application timeouts. Some
A NAT device MUST conform to a number of requirements to ensure applications will not operate correctly without the receipt of ICMP
reliable forwarding. The following sub-sections discuss the error messages. The following sub-sections discuss the requirements
requirements in detail. a NAT device MUST conform to in order to ensure reliable forwarding.
4.1. ICMP Error Payload Validation 4.1. ICMP Error Payload Validation
Appendix C of [ICMP-ATK] points out that newer revision end host Appendix C of [ICMP-ATK] points out that newer revision end host
TCP stacks do not accept ICMP error messages with a mismatched TCP stacks do not accept ICMP error messages with a mismatched
IP or TCP checksum in the embedded packet. NAT devices should IP or TCP checksum in the embedded packet, if the embedded datagram
ensure that ICMP Error payload is not corrupted. Only after the contains full IP packet and the TCP checksum can be calculated.
payload is validated, should the NAT proceed to forward the ICMP Whenever validation is possible, NAT devices should ensure that ICMP
error packet. This requirement is meant primarily for future Error payload is not corrupted. Only after the payload is validated,
applications. Current applications may not be checking for should the NAT proceed to forward the ICMP error packet. This
mismatched checksum. requirement is meant primarily for future applications. Current
applications may not be checking for mismatched checksum.
If the IP checksum of the embedded packet does not validate, the If the IP checksum of the embedded packet does not validate, the
NAT device SHOULD simply drop the error packet. [ICMP] stipulates NAT device SHOULD simply drop the error packet. [ICMP] stipulates
that an ICMP error message should embed IP header and a minimum of 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 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 recommends that an ICMP error originator SHOULD include as much of
the original packet as possible in the payload without the length of the original packet as possible in the payload without the length of
the ICMP datagram exceeding 576 bytes. If the embedded packet is a the ICMP datagram exceeding 576 bytes. If the embedded packet is a
complete IP packet, including the entire transport segment, and the complete IP packet, including the entire transport segment, and the
transport protocol of the embedded packet requires the recipient to transport protocol of the embedded packet requires the recipient to
skipping to change at page 7, line 18 skipping to change at page 7, line 46
zero, the UDP protocol does not require the recipient to validate zero, the UDP protocol does not require the recipient to validate
the UDP checksum. In the case the ICMP Error payload includes ICMP the UDP checksum. In the case the ICMP Error payload includes ICMP
extensions ([ICMP-EXT]), the NAT device SHOULD exclude the optional extensions ([ICMP-EXT]), the NAT device SHOULD exclude the optional
zero-padding and the ICMP extensions when evaluating transport zero-padding and the ICMP extensions when evaluating transport
checksum for the embedded packet. If the transport checksum fails, checksum for the embedded packet. If the transport checksum fails,
the NAT device SHOULD drop the error packet. Readers are urged to the NAT device SHOULD drop the error packet. Readers are urged to
refer [ICMP-EXT] for identifying the presence of ICMP extensions in refer [ICMP-EXT] for identifying the presence of ICMP extensions in
an ICMP message. an ICMP message.
When the IP packet embedded within the ICMP error message includes When the IP packet embedded within the ICMP error message includes
IP options, the NAT device must not assume that the transport header IP options, the NAT device MUST NOT assume that the transport header
of the embedded packet is at a fixed offset (as would be the case of the embedded packet is at a fixed offset (as would be the case
when there are no IP options associated with the packet) from the when there are no IP options associated with the packet) from the
start of the embedded packet. Specifically, the NAT device SHOULD start of the embedded packet. Specifically, the NAT device SHOULD
index past all IP options when locating the start of transport index past all IP options when locating the start of transport
header for the embedded packet. header for the embedded packet.
REQ-3: When an ICMP error packet is received, the NAT device REQ-3: When an ICMP error packet is received, the NAT device
SHOULD do the following. SHOULD do the following.
a) If the IP checksum of the embedded packet fails to validate, drop a) If the IP checksum of the embedded packet fails to validate, drop
the error packet; and the error packet; and
skipping to change at page 7, line 44 skipping to change at page 8, line 24
evaluating transport checksum for the embedded packet; and evaluating transport checksum for the embedded packet; and
d) If the embedded packet contains the entire transport segment, d) If the embedded packet contains the entire transport segment,
and the transport protocol of the embedded packet requires the and the transport protocol of the embedded packet requires the
recipient to validate the transport checksum, and the checksum recipient to validate the transport checksum, and the checksum
fails to validate, drop the error packet. fails to validate, drop the error packet.
4.2. ICMP Error Packet Translation 4.2. ICMP Error Packet Translation
Section 4.3 of RFC 3022 describes the fields of an ICMP error Section 4.3 of RFC 3022 describes the fields of an ICMP error
message that a NAT device translates. In this section, we describe message that a NAT device translates. In this section, we describe
the requirements a NAT device must conform to while performing the the requirements a NAT device MUST conform to while performing the
translations. Requirements identified in this section are necessary translations. Requirements identified in this section are necessary
for the current applications to work correctly. for the current applications to work correctly.
Consider the following scenario in figure 1. Say, NAT-xy is a NAT Consider the following scenario in figure 1. Say, NAT-xy is a NAT
device connecting hosts in private and external networks. device connecting hosts in private and external networks.
Router-x and Host-x are in the external network. Router-y and 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 Host-y are in the private network. The subnets in the external
network are routable from the private as well as the external network are routable from the private as well as the external
domains. By contrast, the subnets in the private network are only domains. By contrast, the subnets in the private network are only
routable within the private domain. When Host-y initiated a session routable within the private domain. When Host-y initiated a session
skipping to change at page 10, line 34 skipping to change at page 10, line 34
| Router-y | | Router-y |
+-------------+ +-------------+
| |
----------------+-------+-------- ----------------+-------+--------
| |
Host-y Host-y
Figure 2. ICMP error Packet Received from External Network Figure 2. ICMP error Packet Received from External Network
When the NAT device receives the ICMP error packet, the NAT device When the NAT device receives the ICMP error packet, the NAT device
must use the packet embedded within the ICMP error message (i.e., 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 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 embedded packet belongs to. If the NAT device does not have an
active mapping for the embedded packet, the NAT SHOULD silently active mapping for the embedded packet, the NAT SHOULD silently
drop the ICMP error packet. Otherwise, the NAT device MUST use drop the ICMP error packet. Otherwise, the NAT device MUST use
the matching NAT Session to translate the embedded packet. the matching NAT Session to translate the embedded packet. That is,
translate the source IP address of the embedded packet (e.g.,
Host-y' -> Host-y) and transport headers.
In addition, if the ICMP Error payload contains ICMP extensions In addition, if the ICMP Error payload contains ICMP extensions
([ICMP-EXT]), and any of the standard ICMP extensions contain realm ([ICMP-EXT]), the NATs are encouraged to support ICMP extension
specific information, the NAT MUST transparently translate each objects. At the time of this writing, the authors are not aware
such ICMP extension, as mandated by the ICMP extension. The NAT of any standard ICMP extension objects containing realm
MUST also recalculate "ICMP extension Header" checksum when any of specific information.
the ICMP extension objects is modified. At the time of this writing,
the authors are not aware of any standard ICMP extension containing
realm specific information. Note, whenever the payload is modified,
the ICMP checksums will also need updating.
The NAT device MUST also use the matching NAT Session to translate The NAT device MUST also use the matching NAT Session to translate
the destination IP address in the outer IP header. In the outer the destination IP address in the outer IP header. In the outer
header, the source IP address will remain unchanged because the header, the source IP address will remain unchanged because the
originator of the ICMP error message (Host-x or Router-x) is in originator of the ICMP error message (Host-x or Router-x) is in
external domain and routable from the private domain. external domain and routable from the private domain.
REQ-4: If a NAT device receives an ICMP error packet from external 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 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 payload, the NAT SHOULD silently drop the ICMP error packet. If the
the NAT has active mapping for the embedded payload, then the NAT NAT has active mapping for the embedded payload and local policy
MUST do the following prior to forwarding the packet. permits, then the NAT MUST do the following prior to forwarding the
packet.
a) Revert the IP and transport headers of the embedded IP packet to a) Revert the IP and transport headers of the embedded IP packet to
their original form, using the matching mapping; and their original form, using the matching mapping; and
b) Leave the ICMP error type and code unchanged; and b) Leave the ICMP error type and code unchanged; and
c) If the ICMP Error payload contains ICMP extensions([ICMP-EXT]), c) Modify the destination IP address of the outer IP header to be
and any of the standard ICMP extensions contain realm specific
information, transparently translate each such ICMP extension, as
mandated by the ICMP extension, and recalculate ICMP extension
Header checksum; and
d) Modify the destination IP address of the outer IP header to be
same as the source IP address of the embedded packet after same as the source IP address of the embedded packet after
translation. translation.
4.2.2. ICMP Error Packet Received from Private Realm 4.2.2. ICMP Error Packet Received from Private Realm
Now, say, a packet from Host-x to Host-y triggered an ICMP error 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 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 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 Router-y or Host-y as the source IP address and Host-x as the
destination IP address as specified in figure 3 below. destination IP address as specified in figure 3 below.
skipping to change at page 12, line 35 skipping to change at page 12, line 35
| Router-y | | Router-y |
+-------------+ +-------------+
| |
----------------+-------+-------- ----------------+-------+--------
| |
Host-y Host-y
Figure 3. ICMP Error Packet Received from Private Network Figure 3. ICMP Error Packet Received from Private Network
When the NAT device receives the ICMP error packet, the NAT device When the NAT device receives the ICMP error packet, the NAT device
must use the packet embedded within the ICMP error message (i.e., 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 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 embedded packet belongs to. If the NAT device does not have an
active mapping for the embedded packet, the NAT SHOULD silently active mapping for the embedded packet, the NAT SHOULD silently
drop the ICMP error packet. Otherwise, the NAT device MUST use drop the ICMP error packet. Otherwise, the NAT device MUST use
the matching NAT Session to translate the embedded packet. the matching NAT Session to translate the embedded packet.
In addition, if the ICMP Error payload contains ICMP extensions In addition, if the ICMP Error payload contains ICMP extensions
([ICMP-EXT]), and any of the standard ICMP extensions contain realm ([ICMP-EXT]), the NATs are encouraged to support ICMP extension
specific information, the NAT MUST transparently translate each objects. At the time of this writing, the authors are not aware
such ICMP extension, as mandated by the ICMP extension. The NAT of any standard ICMP extension objects containing realm
MUST also recalculate "ICMP extension Header" checksum when any of specific information.
the ICMP extension objects is modified. At the time of this writing,
the authors are not aware of any standard ICMP extension containing
realm specific information. Note, whenever the payload is modified,
the ICMP checksums will also need updating.
In the outer header, the destination IP address will remain In the outer header, the destination IP address will remain
unchanged, as the IP addresses for Host-x is already in the external 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 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 device must simply use the NAT Session to translate the source IP
address Host-y to Host-y'. address Host-y to Host-y'. If the ICMP error message is originated
by the intermediate node Router-y, translation of the source IP
If the ICMP error message is originated by the intermediate node address varies depending on whether Basic NAT or NAPT function
Router-y, translation of the source IP address varies depending on ([NAT-TRAD]) is enforced by the NAT device. A NAT device enforcing
whether Basic NAT or NAPT function ([NAT-TRAD]) is enforced by the Basic NAT function has a pool of public IP addresses and enforces
NAT device. A NAT device enforcing Basic NAT function has a pool of address mapping (which is different from the endpoint mapping
public IP addresses and enforces address mapping (which is different enforced by NAPT) when a private node initiates an outgoing session
from the endpoint mapping enforced by NAPT) when a private node via the NAT device. So, if the NAT device has active mapping for
initiates an outgoing session via the NAT device. So, if the NAT the IP address of the intermediate node Router-y, the NAT device
device has active mapping for the IP address of the intermediate MUST translate the source IP address of the ICMP error packet with
node Router-y, the NAT device MUST translate the source IP address the public IP address in the mapping. In all other cases, the NAT
of the ICMP error packet with the public IP address in the mapping. device MUST simply use its own IP address in the external domain
Otherwise, the NAT device MUST simply use its own IP address in the to translate the source IP address.
external domain to translate the source IP address.
REQ-5: If a NAT device receives an ICMP error packet from private 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 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 payload, the NAT SHOULD silently drop the ICMP error packet. If the
the NAT has active mapping for the embedded payload, then the NAT NAT has active mapping for the embedded payload and local policy
MUST do the following prior to forwarding the packet. permits, then the NAT MUST do the following prior to forwarding the
packet.
a) Revert the IP and transport headers of the embedded a) Revert the IP and transport headers of the embedded
IP packet to their original form, using the matching mapping; and IP packet to their original form, using the matching mapping; and
b) Leave the ICMP error type and code unchanged; and b) Leave the ICMP error type and code unchanged; and
c) If the ICMP Error payload contains ICMP extensions([ICMP-EXT]), c) If the NAT enforces Basic NAT function ([NAT-TRAD]), and the NAT
and any of the standard ICMP extensions contain realm specific
information, transparently translate each such ICMP extension, as
mandated by the ICMP extension, and recalculate ICMP extension
Header checksum; and
d) If the NAT enforces Basic NAT function ([NAT-TRAD]), and the NAT
has active mapping for the IP address that sent the ICMP error, has active mapping for the IP address that sent the ICMP error,
translate the source IP address of the ICMP error packet with the translate the source IP address of the ICMP error packet with the
public IP address in the mapping. In all other cases, translate the public IP address in the mapping. In all other cases, translate the
source IP address of the ICMP error packet with its own public IP source IP address of the ICMP error packet with its own public IP
address. address.
4.3. NAT Sessions Pertaining to ICMP Error Payload 4.3. NAT Sessions Pertaining to ICMP Error Payload
While processing an ICMP error packet pertaining to an ICMP Query While processing an ICMP error packet pertaining to an ICMP Query
or Query response message, a NAT device MUST NOT refresh or delete or Query response message, a NAT device MUST NOT refresh or delete
skipping to change at page 15, line 22 skipping to change at page 15, line 14
if the NAT device is out of resources (out of addresses or TCP/UDP if the NAT device is out of resources (out of addresses or TCP/UDP
ports or NAT Session resources) to set up a state for the session, ports or NAT Session resources) to set up a state for the session,
or, the specific session is administratively restricted by the NAT or, the specific session is administratively restricted by the NAT
device. device.
When the first packet of an outbound flow is prohibited by a NAT When the first packet of an outbound flow is prohibited by a NAT
device due to resource constraints or administration considerations, device due to resource constraints or administration considerations,
the NAT device SHOULD send ICMP destination unreachable message. the NAT device SHOULD send ICMP destination unreachable message.
Section 5.2.7.1 of [RFC1812] recommends routers to use ICMP code 13 Section 5.2.7.1 of [RFC1812] recommends routers to use ICMP code 13
(Communication administratively prohibited) when they (Communication administratively prohibited) when they
administratively filter packets. As such, a NAT device SHOULD use administratively filter packets. ICMP code 13 is a soft error and
ICMP code 13 when generating an ICMP error message. This requirement is on par with other soft error codes generated in response to
is meant primarily for future use. Current applications do not transient events such as 'network unreachable' (ICMP type=3,
require this for them to work correctly. code=0). A NAT device SHOULD use ICMP code 13 when generating an
ICMP error message. This requirement is meant primarily for future
use. Current applications do not require this for them to work
correctly.
Some NAT designers opt to never reject an outbound flow. When a Some NAT designers opt to never reject an outbound flow. When a
NAT runs short of resources, they prefer to steal a resource NAT runs short of resources, they prefer to steal a resource
from an existing NAT Session rather than reject the outbound flow. from an existing NAT Session rather than reject the outbound flow.
Such a design choice may appear conformant to REQ-8 below. However, Such a design choice may appear conformant to REQ-8 below. However,
the design choice is in violation of the spirit of both REQ-8 and the design choice is in violation of the spirit of both REQ-8 and
REQ-2. Such a design choice is strongly discouraged. REQ-2. Such a design choice is strongly discouraged.
REQ-8: When a NAT device is unable to establish a NAT Session for a REQ-8: When a NAT device is unable to establish a NAT Session for a
new flow due to resource constraints or administrative restrictions, new transport-layer (TCP, UDP, ICMP, etc.) flow due to resource
the NAT device SHOULD send an ICMP destination unreachable message, constraints or administrative restrictions, the NAT device SHOULD
with a code of 13 (Communication administratively prohibited) to the send an ICMP destination unreachable message, with a code of 13
sender, and drop the original packet. (Communication administratively prohibited) to the sender, and drop
the original packet.
7. Conformance to RFC 1812 7. Conformance to RFC 1812
A NAT device is inherently an intermediate router that forwards A NAT device is inherently an intermediate router that forwards
IP packets between private and public realms. As such, the NAT IP packets between private and external realms. As such, the NAT
device MUST conform to all the requirements of a router, as device MUST conform to all the requirements of a router, as
specified in [RFC1812]. Section 5.2.7.1 of [RFC1812] states that specified in [RFC1812]. Section 5.2.7.1 of [RFC1812] states that
a router MUST also be able to generate ICMP Destination Unreachable a router MUST also be able to generate ICMP Destination Unreachable
messages and SHOULD choose a response code that most closely matches messages and SHOULD choose a response code that most closely matches
the reason the message is being generated. the reason the message is being generated.
Note, however, NAT devices also function as hosts on the Internet Note, however, NAT devices also function as hosts on the Internet
and are bound by the conformance requirements in [RFC1122]. and are bound by the conformance requirements in [RFC1122].
Protocol-specific BEHAVE documents ([BEH-UDP], [BEH-TCP]) identify Protocol-specific BEHAVE documents ([BEH-UDP], [BEH-TCP]) identify
instances where a NAT device should deviate from RFC 1122. As such, instances where a NAT device should deviate from RFC 1122. As such,
skipping to change at page 17, line 34 skipping to change at page 17, line 29
7.3. RFC 1812 Conformance Requirements summary 7.3. RFC 1812 Conformance Requirements summary
The requirements outlined in sections 7.1 and 7.2 are necessary for The requirements outlined in sections 7.1 and 7.2 are necessary for
the current applications to work correctly. The following summarizes the current applications to work correctly. The following summarizes
the requirements specified in sections 7.1 and 7.2, the requirements specified in sections 7.1 and 7.2,
REQ-9: A NAT device MUST conform to RFC 1812 in IP packet handling. REQ-9: A NAT device MUST conform to RFC 1812 in IP packet handling.
Below are specific instances where a NAT device MUST conform to Below are specific instances where a NAT device MUST conform to
RFC 1812. RFC 1812.
a) If DF bit is set on a transit IP packet and the NAT a) A NAT MUST honor the DF bit in the IP header. If the DF bit is set
device cannot forward the packet without fragmentation, the on a transit IP packet and the NAT device cannot forward the packet
NAT device MUST send a "Packet too big" ICMP message (ICMP without fragmentation, the NAT device MUST send a "Packet too big"
type 3, Code 4) with a suggested MTU back to the sender and ICMP message (ICMP type 3, Code 4) with a suggested MTU back to the
drop the original IP packet. sender and drop the original IP packet. If the DF-bit is clear and
MTU mandates fragmentation, the NAT device MUST fragment the packet
and forward the fragments.
b) A NAT device MUST, by default, generate "Time Exceeded" ICMP b) A NAT device MUST, by default, generate "Time Exceeded" ICMP
error message when it discards a packet due to an expired TTL field, error message when it discards a packet due to an expired TTL field,
unless explicitly configured otherwise. unless explicitly configured otherwise.
8. Summary of Requirements 8. Summary of Requirements
This section summarizes the requirements discussed in the preceding This section summarizes the requirements discussed in the preceding
sections. sections.
REQ-1: A NAT device MUST permit ICMP query based applications to be REQ-1: When local policy permits, a NAT device MUST permit ICMP
initiated from private hosts to the external hosts. queries and their associated responses, when the query is initiated
from a private host.
a) NAT mapping of ICMP Query identifiers SHOULD be external host a) NAT mapping of ICMP Query identifiers SHOULD be external host
independent. independent.
REQ-2: An ICMP Query session timer MUST NOT expire in less than 60 REQ-2: An ICMP Query session timer MUST NOT expire in less than 60
seconds. seconds.
a) It is RECOMMENDED that the ICMP Query session timer be made a) It is RECOMMENDED that the ICMP Query session timer be made
configurable. configurable.
REQ-3: When an ICMP error packet is received, the NAT device REQ-3: When an ICMP error packet is received, the NAT device
SHOULD do the following. SHOULD do the following.
skipping to change at page 18, line 29 skipping to change at page 18, line 28
exclude the optional zero-padding and the ICMP extensions when exclude the optional zero-padding and the ICMP extensions when
evaluating transport checksum for the embedded packet; and evaluating transport checksum for the embedded packet; and
d) If the embedded packet contains the entire transport segment, d) If the embedded packet contains the entire transport segment,
and the transport protocol of the embedded packet requires the and the transport protocol of the embedded packet requires the
recipient to validate the transport checksum, and the checksum recipient to validate the transport checksum, and the checksum
fails to validate, drop the error packet. fails to validate, drop the error packet.
REQ-4: If a NAT device receives an ICMP error packet from external 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 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 payload, the NAT SHOULD silently drop the ICMP error packet. If the
the NAT has active mapping for the embedded payload, then the NAT NAT has active mapping for the embedded payload and local policy
MUST do the following prior to forwarding the packet. permits, then the NAT MUST do the following prior to forwarding the
packet.
a) Revert the IP and transport headers of the embedded IP packet to a) Revert the IP and transport headers of the embedded IP packet to
their original form, using the matching mapping; and their original form, using the matching mapping; and
b) Leave the ICMP error type and code unchanged; and b) Leave the ICMP error type and code unchanged; and
c) If the ICMP Error payload contains ICMP extensions([ICMP-EXT]), c) Modify the destination IP address of the outer IP header to be
and any of the standard ICMP extensions contain realm specific
information, transparently translate each such ICMP extension, as
mandated by the ICMP extension, and recalculate ICMP extension
Header checksum; and
d) Modify the destination IP address of the outer IP header to be
same as the source IP address of the embedded packet after same as the source IP address of the embedded packet after
translation. translation.
REQ-5: If a NAT device receives an ICMP error packet from private 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 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 payload, the NAT SHOULD silently drop the ICMP error packet. If the
the NAT has active mapping for the embedded payload, then the NAT NAT has active mapping for the embedded payload and local policy
MUST do the following prior to forwarding the packet. permits, then the NAT MUST do the following prior to forwarding the
packet.
a) Revert the IP and transport headers of the embedded a) Revert the IP and transport headers of the embedded
IP packet to their original form, using the matching mapping; and IP packet to their original form, using the matching mapping; and
b) Leave the ICMP error type and code unchanged; and b) Leave the ICMP error type and code unchanged; and
c) If the ICMP Error payload contains ICMP extensions([ICMP-EXT]), c) If the NAT enforces Basic NAT function ([NAT-TRAD]), and the NAT
and any of the standard ICMP extensions contain realm specific
information, transparently translate each such ICMP extension, as
mandated by the ICMP extension, and recalculate ICMP extension
Header checksum; and
d) If the NAT enforces Basic NAT function ([NAT-TRAD]), and the NAT
has active mapping for the IP address that sent the ICMP error, has active mapping for the IP address that sent the ICMP error,
translate the source IP address of the ICMP error packet with the translate the source IP address of the ICMP error packet with the
public IP address in the mapping. In all other cases, translate the public IP address in the mapping. In all other cases, translate the
source IP address of the ICMP error packet with its own public IP source IP address of the ICMP error packet with its own public IP
address. address.
REQ-6: While processing an ICMP error packet pertaining to an ICMP REQ-6: While processing an ICMP error packet pertaining to an ICMP
Query or Query response message, a NAT device MUST NOT refresh or Query or Query response message, a NAT device MUST NOT refresh or
delete the NAT Session that pertains to the embedded payload within delete the NAT Session that pertains to the embedded payload within
the ICMP error packet. the ICMP error packet.
skipping to change at page 19, line 30 skipping to change at page 19, line 20
REQ-7: NAT devices enforcing Basic NAT ([NAT-TRAD]) MUST support the REQ-7: NAT devices enforcing Basic NAT ([NAT-TRAD]) MUST support the
traversal of hairpinned ICMP query sessions. All NAT devices (i.e., traversal of hairpinned ICMP query sessions. All NAT devices (i.e.,
Basic NAT as well as NAPT devices) MUST support the traversal of Basic NAT as well as NAPT devices) MUST support the traversal of
hairpinned ICMP error messages. hairpinned ICMP error messages.
a) When forwarding a hairpinned ICMP error message, the NAT device a) When forwarding a hairpinned ICMP error message, the NAT device
MUST translate the destination IP address of the outer IP header to MUST translate the destination IP address of the outer IP header to
be same as the source IP address of the embedded IP packet after be same as the source IP address of the embedded IP packet after
the translation. the translation.
REQ-8: When a NAT device is unable to establish a NAT Session for a REQ-8: When a NAT device is unable to establish a NAT Session for a
new flow due to resource constraints or administrative restrictions, new transport-layer (TCP, UDP, ICMP, etc.) flow due to resource
the NAT device SHOULD send an ICMP destination unreachable message, constraints or administrative restrictions, the NAT device SHOULD
with a code of 13 (Communication administratively prohibited) to the send an ICMP destination unreachable message, with a code of 13
sender, and drop the original packet. (Communication administratively prohibited) to the sender, and drop
the original packet.
REQ-9: A NAT device MUST conform to RFC 1812 in IP packet handling. REQ-9: A NAT device MUST conform to RFC 1812 in IP packet handling.
Below are specific instances where a NAT device MUST conform to Below are specific instances where a NAT device MUST conform to
RFC 1812. RFC 1812.
a) If DF bit is set on a transit IP packet and the NAT a) A NAT MUST honor the DF bit in the IP header. If the DF bit is set
device cannot forward the packet without fragmentation, the on a transit IP packet and the NAT device cannot forward the packet
NAT device MUST send a "Packet too big" ICMP message (ICMP without fragmentation, the NAT device MUST send a "Packet too big"
type 3, Code 4) with a suggested MTU back to the sender and ICMP message (ICMP type 3, Code 4) with a suggested MTU back to the
drop the original IP packet. sender and drop the original IP packet. If the DF-bit is clear and
MTU mandates fragmentation, the NAT device MUST fragment the packet
and forward the fragments.
b) A NAT device MUST, by default, generate "Time Exceeded" ICMP b) A NAT device MUST, by default, generate "Time Exceeded" ICMP
error message when it discards a packet due to an expired TTL field, error message when it discards a packet due to an expired TTL field,
unless explicitly configured otherwise. unless explicitly configured otherwise.
9. Security Considerations 9. Security Considerations
This document does not introduce any new security concerns related This document does not introduce any new security concerns related
to ICMP error message handling in the NAT devices. However, the to ICMP error message handling in the NAT devices. However, the
document does propose counter measures to mitigate security concerns document does propose counter measures to mitigate security concerns
that already exist with ICMP error messages. that already exist with ICMP error messages.
skipping to change at page 20, line 25 skipping to change at page 20, line 18
in [ICMP-ATK]. in [ICMP-ATK].
For example, a rogue entity could bombard the NAT device with a For example, a rogue entity could bombard the NAT device with a
large number of ICMP errors. If the NAT device did not large number of ICMP errors. If the NAT device did not
validate the legitimacy of the ICMP error packets, the ICMP errors validate the legitimacy of the ICMP error packets, the ICMP errors
would be forwarded directly to the end nodes. End hosts not capable would be forwarded directly to the end nodes. End hosts not capable
of defending themselves against such bogus ICMP error attacks could of defending themselves against such bogus ICMP error attacks could
be adversely impacted by such attacks. Req-3 recommends validating be adversely impacted by such attacks. Req-3 recommends validating
embedded payload prior to forwarding. Checksum validation by itself embedded payload prior to forwarding. Checksum validation by itself
does not protect end hosts from attacks. However, checksum does not protect end hosts from attacks. However, checksum
validation mitigates endhosts from malformed ICMP error attacks. validation mitigates end hosts from malformed ICMP error attacks.
Req-4 and Req-5 further mandate that when a NAT device does not find 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 a mapping selection for the embedded payload, the NAT should drop
the ICMP error packets, without forwarding. the ICMP error packets, without forwarding.
A rogue source could also try and send bogus ICMP error messages for A rogue source could also try and send bogus ICMP error messages for
the active NAT sessions, with an intent to destroy the sessions. the active NAT sessions, with an intent to destroy the sessions.
Req-6 averts such an attack by ensuring that an ICMP error message 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. does not effect the state of a session on the NAT device.
Req-8 recommends a NAT device sending ICMP error message when the Req-8 recommends a NAT device sending ICMP error message when the
NAT device is unable to create a NAT session due to lack of NAT device is unable to create a NAT session due to lack of
resources. Some administrators may choose not to have the NAT device resources. Some administrators may choose not to have the NAT device
send ICMP error message, as doing so could confirm to a malicious send ICMP error message, as doing so could confirm to a malicious
attacker that the attack has succeeded. For this reason, sending attacker that the attack has succeeded. For this reason, sending
ICMP error message as specified in REQ-8 should be left to the of the specific ICMP error message stated in REQ-8 should be
discretion of the NAT device administrator. left to the discretion of the NAT device administrator.
Unfortunately, ICMP messages are sometimes blocked at network
boundaries due to local security policy. Thus, some of the
requirements in this document allow local policy to override the
recommendations of this document. Blocking such ICMP messages is
known to break some protocol features (most notably Path MTU
Discovery) and some applications (e.g., ping, traceroute), and
such blocking is NOT RECOMMENDED.
10. IANA Considerations 10. IANA Considerations
There are no IANA considerations. There are no IANA considerations.
11. Acknowledgements 11. Acknowledgements
The authors wish to thank Fernando Gont, Dan Wing, Carlos Pignataro,
The authors wish to thank Fernando Gont, Dan Wing and Philip Philip Matthews and members of the BEHAVE work group for doing a
Matthews for doing a thorough review of the document and providing thorough review of the document and providing valuable input and
valuable input and offering generous amount of their time in shaping offering generous amount of their time in shaping the ICMP
the ICMP requirements. Their valuable feedback makes this document a requirements. Their valuable feedback makes this document a better
better read. The authors highly appreciate that. Dan and Fernando read. The authors highly appreciate that. Dan Wing and Fernando Gont
have been a steady source of inspiration throughout, for each rev of have been a steady source of inspiration throughout, for each rev of
the document. Fernando Gont spent many hours preparing slides and the document. Fernando Gont spent many hours preparing slides and
presenting the document in the IETF on behalf of the authors. For presenting the document in the IETF on behalf of the authors. For
this, the authors are grateful to Fernando. The authors also thank this, the authors are grateful to Fernando. The authors also thank
and sincerely appreciate Dan Tappan and Carlos Pignataro, the and sincerely appreciate Dan Tappan and Carlos Pignataro, the
authors of the [ICMP-EXT] document for their feedback on operational authors of the [ICMP-EXT] document for their feedback on operational
experience with ICMP extensions across NAT devices. experience with ICMP extensions across NAT devices.
Normative References Normative References
[BEH-UDP] F. Audet and C. Jennings, "NAT Behavioral Requirements for [BEH-UDP] F. Audet and C. Jennings, "NAT Behavioral Requirements for
Unicast UDP", RFC 4787, January 2007. Unicast UDP", RFC 4787, January 2007.
[ICMP] Postel, J., "Internet Control Message Protocol", STD 5, [ICMP] Postel, J., "Internet Control Message Protocol", STD 5,
RFC 792, September 1981. RFC 792, September 1981.
[ICMP-EXT] Bonica, R., Gan, D., Nikander, P., Tappan, D., and [ICMP-EXT] Bonica, R., Gan, D., Nikander, P., Tappan, D., and
Pignataro, C., "Extended ICMP to Support Multi-part Pignataro, C., "Extended ICMP to Support Multi-part
Messages", draft-bonica-internet-icmp-16.txt (Work in Messages", RFC 4884, April 2007.
progress), January 2007.
[NAT-MIB] Rohit, R., Srisuresh, P., Raghunarayan, R., Pai, N., [NAT-MIB] Rohit, R., Srisuresh, P., Raghunarayan, R., Pai, N.,
and Wang, C., "Definitions of Managed Objects for Network and Wang, C., "Definitions of Managed Objects for Network
Address Translators (NAT)", RFC 4008, March 2005. Address Translators (NAT)", RFC 4008, March 2005.
[RFC793] "Transmission Control Protocol DARPA Internet Program
Protocol Specification", RFC 793, September 1981.
[RFC1812] Baker, F., "Requirements for IP Version 4 Routers", [RFC1812] Baker, F., "Requirements for IP Version 4 Routers",
RFC 1812, June 1995. RFC 1812, June 1995.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
Informative References Informative References
[BEH-APP] Ford, B., Srisuresh, P., and Kegel, D., "Application Design [BEH-APP] Ford, B., Srisuresh, P., and Kegel, D., "Application Design
Guidelines for Traversal through Network Address Guidelines for Traversal through Network Address
Translators", draft-ford-behave-app-04.txt (Work In Translators", draft-ford-behave-app-05.txt (Work In
Progress), October 2006. Progress), March 2007.
[BEH-TCP] Guha, S., Biswas, K., Ford, B., Francis, P., Sivakumar, S., [BEH-TCP] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and
and Srisuresh, P., "NAT Behavioral Requirements for Srisuresh, P., "NAT Behavioral Requirements for TCP",
Unicast TCP", draft-ietf-behave-tcp-00.txt (Work In draft-ietf-behave-tcp-07.txt (Work In Progress),
Progress), February 2006. April 2007.
[ICMP-ATK] Gont, F., "ICMP attacks against TCP", [ICMP-ATK] Gont, F., "ICMP attacks against TCP",
draft-ietf-tcpm-icmp-attacks-01.txt (Work In Progress), draft-ietf-tcpm-icmp-attacks-02.txt (Work In Progress),
October 2006. May 2007.
[MS-TRCRT] Microsoft Support, "How to use the Tracert
command-line utility to troubleshoot TCP/IP problems
in Windows", http://support.microsoft.com/kb/162326,
October, 2006.
[NAT-TERM] Srisuresh, P. and Holdrege, M., "IP Network Address [NAT-TERM] Srisuresh, P. and Holdrege, M., "IP Network Address
Translator (NAT) Terminology and Considerations", RFC 2663, Translator (NAT) Terminology and Considerations", RFC 2663,
August 1999. August 1999.
[NAT-TRAD] Srisuresh, P., and Egevang, K., "Traditional IP Network [NAT-TRAD] Srisuresh, P., and Egevang, K., "Traditional IP Network
Address Translator (Traditional NAT)", RFC 3022, Address Translator (Traditional NAT)", RFC 3022,
January 2001. January 2001.
[PMTU] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, [PMTU] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
November 1990. November 1990.
[RFC1122] Braden, R., "Requirements for Internet Hosts -- [RFC1122] Braden, R., "Requirements for Internet Hosts --
Communication Layers", RFC 1122, October 1989. Communication Layers", RFC 1122, October 1989.
[RFC1256] Deering, S., "ICMP Router Discovery Messages", RFC1256,
September 1991.
[RFC1470] Stine, R., "FYI on a Network Management Tool Catalog: Tools [RFC1470] Stine, R., "FYI on a Network Management Tool Catalog: Tools
for Monitoring and Debugging TCP/IP Internets and for Monitoring and Debugging TCP/IP Internets and
Interconnected Devices", RFC 1470, June 1993. Interconnected Devices", RFC 1470, June 1993.
[RFC4065] Kempf, J., "Instructions for Seamoby and Experimental
Mobility Protocol IANA Allocations", RFC 4065, July 2005.
[TCP-SOFT] Gont, F., "TCP's Reaction to Soft Errors", [TCP-SOFT] Gont, F., "TCP's Reaction to Soft Errors",
draft-ietf-tcpm-tcp-soft-errors-03.txt (Work In Progress), draft-ietf-tcpm-tcp-soft-errors-06.txt (Work In Progress),
January 2007. June 2007.
[UNSAF] Daigle, L., and IAB, "IAB Considerations for UNilateral [UNSAF] Daigle, L., and IAB, "IAB Considerations for UNilateral
Self-Address Fixing (UNSAF) Across Network Address Self-Address Fixing (UNSAF) Across Network Address
Translation", RFC 3424, November 2002. Translation", RFC 3424, November 2002.
Author's Addresses: Author's Addresses:
Pyda Srisuresh Pyda Srisuresh
Kazeon Systems, Inc. Kazeon Systems, Inc.
1161 San Antonio Rd. 1161 San Antonio Rd.
 End of changes. 55 change blocks. 
178 lines changed or deleted 212 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/