diff options
Diffstat (limited to 'doc/rfc/rfc5382.txt')
| -rw-r--r-- | doc/rfc/rfc5382.txt | 1179 |
1 files changed, 1179 insertions, 0 deletions
diff --git a/doc/rfc/rfc5382.txt b/doc/rfc/rfc5382.txt new file mode 100644 index 0000000..995986c --- /dev/null +++ b/doc/rfc/rfc5382.txt @@ -0,0 +1,1179 @@ + + + + + + +Network Working Group S. Guha, Ed. +Request for Comments: 5382 Cornell U. +BCP: 142 K. Biswas +Category: Best Current Practice Cisco Systems + B. Ford + MPI-SWS + S. Sivakumar + Cisco Systems + P. Srisuresh + Kazeon Systems + October 2008 + + + NAT Behavioral Requirements for TCP + +Status of This Memo + + This document specifies an Internet Best Current Practices for the + Internet Community, and requests discussion and suggestions for + improvements. Distribution of this memo is unlimited. + +Abstract + + This document defines a set of requirements for NATs that handle TCP + that would allow many applications, such as peer-to-peer applications + and online games to work consistently. Developing NATs that meet + this set of requirements will greatly increase the likelihood that + these applications will function properly. + + + + + + + + + + + + + + + + + + + + + + + +Guha, et al. Best Current Practice [Page 1] + +RFC 5382 NAT TCP Requirements October 2008 + + +Table of Contents + + 1. Applicability Statement . . . . . . . . . . . . . . . . . . . 3 + 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 4. TCP Connection Initiation . . . . . . . . . . . . . . . . . . 4 + 4.1. Address and Port Mapping Behavior . . . . . . . . . . . . 5 + 4.2. Internally Initiated Connections . . . . . . . . . . . . . 5 + 4.3. Externally Initiated Connections . . . . . . . . . . . . . 7 + 5. NAT Session Refresh . . . . . . . . . . . . . . . . . . . . . 10 + 6. Application Level Gateways . . . . . . . . . . . . . . . . . . 12 + 7. Other Requirements Applicable to TCP . . . . . . . . . . . . . 12 + 7.1. Port Assignment . . . . . . . . . . . . . . . . . . . . . 12 + 7.2. Hairpinning Behavior . . . . . . . . . . . . . . . . . . . 13 + 7.3. ICMP Responses to TCP Packets . . . . . . . . . . . . . . 13 + 8. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 14 + 9. Security Considerations . . . . . . . . . . . . . . . . . . . 16 + 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 + 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 + 11.1. Normative References . . . . . . . . . . . . . . . . . . . 18 + 11.2. Informational References . . . . . . . . . . . . . . . . . 18 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Guha, et al. Best Current Practice [Page 2] + +RFC 5382 NAT TCP Requirements October 2008 + + +1. Applicability Statement + + This document is adjunct to [BEHAVE-UDP], which defines many terms + relating to NATs, lays out general requirements for all NATs, and + sets requirements for NATs that handle IP and unicast UDP traffic. + The purpose of this document is to set requirements for NATs that + handle TCP traffic. + + The requirements of this specification apply to traditional NATs as + described in [RFC2663]. + + This document only covers the TCP aspects of NAT traversal. + Middlebox behavior that is not necessary for network address + translation of TCP is out of scope. Packet inspection above the TCP + layer and firewalls are out of scope except for Application Level + Gateway (ALG) behavior that may interfere with NAT traversal. + Application and OS aspects of TCP NAT traversal are out of scope. + Signaling-based approaches to NAT traversal, such as Middlebox + Communication (MIDCOM) and Universal Plug and Play (UPnP), that + directly control the NAT are out of scope. Finally, TCP connections + intended for the NAT (e.g., an HTTP or Secure Shell Protocol (SSH) + management interface) and TCP connections initiated by the NAT (e.g., + reliable syslog client) are out of scope. + +2. Introduction + + Network Address Translators (NATs) hinder connectivity in + applications where sessions may be initiated to internal hosts. + Readers may refer to [RFC3022] for detailed information on + traditional NATs. [BEHAVE-UDP] lays out the terminology and + requirements for NATs in the context of IP and UDP. This document + supplements these by setting requirements for NATs that handle TCP + traffic. All definitions and requirements in [BEHAVE-UDP] are + inherited here. + + [RFC4614] chronicles the evolution of TCP from the original + definition [RFC0793] to present-day implementations. While much has + changed in TCP with regards to congestion control and flow control, + security, and support for high-bandwidth networks, the process of + initiating a connection (i.e., the 3-way handshake or simultaneous- + open) has changed little. It is the process of connection initiation + that NATs affect the most. Experimental approaches such as T/TCP + [RFC1644] have proposed alternate connection initiation approaches, + but have been found to be complex and susceptible to denial-of- + service attacks. Modern operating systems and NATs consequently + primarily support the 3-way handshake and simultaneous-open modes of + connection initiation as described in [RFC0793]. + + + + +Guha, et al. Best Current Practice [Page 3] + +RFC 5382 NAT TCP Requirements October 2008 + + + Recently, many techniques have been devised to make peer-to-peer TCP + applications work across NATs. [STUNT], [NATBLASTER], and [P2PNAT] + describe Unilateral Self-Address Fixing (UNSAF) mechanisms that allow + peer-to-peer applications to establish TCP through NATs. These + approaches require only endpoint applications to be modified and work + with standards compliant OS stacks. The approaches, however, depend + on specific NAT behavior that is usually, but not always, supported + by NATs (see [TCPTRAV] and [P2PNAT] for details). Consequently, a + complete TCP NAT traversal solution is sometimes forced to rely on + public TCP relays to traverse NATs that do not cooperate. This + document defines requirements that ensure that TCP NAT traversal + approaches are not forced to use data relays. + +3. Terminology + + 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]. + + "NAT" in this specification includes both "Basic NAT" and "Network + Address/Port Translator (NAPT)" [RFC2663]. The term "NAT Session" is + adapted from [NAT-MIB] and is defined as follows. + + NAT Session - A NAT session is an association between a TCP session + as seen in the internal realm and a TCP session as seen in the + external realm, by virtue of NAT translation. The NAT session will + provide the translation glue between the two session representations. + + This document uses the term "TCP connection" (or just "connection") + to refer to individual TCP flows identified by the 4-tuple (source + and destination IP address and TCP port) and the initial sequence + numbers (ISN). + + This document uses the term "address and port mapping" (or just + "mapping") as defined in [BEHAVE-UDP] to refer to state at the NAT + necessary for network address and port translation of TCP + connections. This document also uses the terms "Endpoint-Independent + Mapping", "Address-Dependent Mapping", "Address and Port-Dependent + Mapping", "filtering behavior", "Endpoint-Independent Filtering", + "Address-Dependent Filtering", "Address and Port-Dependent + Filtering", "Port assignment", "Port overloading", "hairpinning", and + "External source IP address and port" as defined in [BEHAVE-UDP]. + +4. TCP Connection Initiation + + This section describes various NAT behaviors applicable to TCP + connection initiation. + + + + +Guha, et al. Best Current Practice [Page 4] + +RFC 5382 NAT TCP Requirements October 2008 + + +4.1. Address and Port Mapping Behavior + + A NAT uses a mapping to translate packets for each TCP connection. A + mapping is dynamically allocated for connections initiated from the + internal side, and potentially reused for certain subsequent + connections. NAT behavior regarding when a mapping can be reused + differs for different NATs as described in [BEHAVE-UDP]. + + Consider an internal IP address and TCP port (X:x) that initiates a + TCP connection to an external (Y1:y1) tuple. Let the mapping + allocated by the NAT for this connection be (X1':x1'). Shortly + thereafter, the endpoint initiates a connection from the same (X:x) + to an external address (Y2:y2) and gets the mapping (X2':x2') on the + NAT. As per [BEHAVE-UDP], if (X1':x1') equals (X2':x2') for all + values of (Y2:y2), then the NAT is defined to have "Endpoint- + Independent Mapping" behavior. If (X1':x1') equals (X2':x2') only + when Y2 equals Y1, then the NAT is defined to have "Address-Dependent + Mapping" behavior. If (X1':x1') equals (X2':x2') only when (Y2:y2) + equals (Y1:y1), possible only for consecutive connections to the same + external address shortly after the first is terminated and if the NAT + retains state for connections in TIME_WAIT state, then the NAT is + defined to have "Address and Port-Dependent Mapping" behavior. This + document introduces one additional behavior where (X1':x1') never + equals (X2':x2'), that is, for each connection a new mapping is + allocated; in such a case, the NAT is defined to have "Connection- + Dependent Mapping" behavior. + + REQ-1: A NAT MUST have an "Endpoint-Independent Mapping" behavior + for TCP. + + Justification: REQ-1 is necessary for UNSAF methods to work. + Endpoint-Independent Mapping behavior allows peer-to-peer + applications to learn and advertise the external IP address and + port allocated to an internal endpoint such that external peers + can contact it (subject to the NAT's security policy). The + security policy of a NAT is independent of its mapping behavior + and is discussed later in Section 4.3. Having Endpoint- + Independent Mapping behavior allows peer-to-peer applications to + work consistently without compromising the security benefits of + the NAT. + +4.2. Internally Initiated Connections + + An internal endpoint initiates a TCP connection through a NAT by + sending a SYN packet. The NAT allocates (or reuses) a mapping for + the connection, as described in the previous section. The mapping + defines the external IP address and port used for translation of all + packets for that connection. In particular, for client-server + + + +Guha, et al. Best Current Practice [Page 5] + +RFC 5382 NAT TCP Requirements October 2008 + + + applications where an internal client initiates the connection to an + external server, the mapping is used to translate the outbound SYN, + the resulting inbound SYN-ACK response, the subsequent outbound ACK, + and other packets for the connection. This method of connection + initiation corresponds to the 3-way handshake (defined in [RFC0793]) + and is supported by all NATs. + + Peer-to-peer applications use an alternate method of connection + initiation termed simultaneous-open (Fig. 8, [RFC0793]) to traverse + NATs. In the simultaneous-open mode of operation, both peers send + SYN packets for the same TCP connection. The SYN packets cross in + the network. Upon receiving the other end's SYN packet, each end + responds with a SYN-ACK packet, which also cross in the network. The + connection is considered established once the SYN-ACKs are received. + From the perspective of the NAT, the internal host's SYN packet is + met by an inbound SYN packet for the same connection (as opposed to a + SYN-ACK packet during a 3-way handshake). Subsequent to this + exchange, both an outbound and an inbound SYN-ACK are seen for the + connection. Some NATs erroneously block the inbound SYN for the + connection in progress. Some NATs block or incorrectly translate the + outbound SYN-ACK. Such behavior breaks TCP simultaneous-open and + prevents peer-to-peer applications from functioning correctly behind + a NAT. + + In order to provide network address translation service for TCP, it + is necessary for a NAT to correctly receive, translate, and forward + all packets for a connection that conform to valid transitions of the + TCP State-Machine (Fig. 6, [RFC0793]). + + REQ-2: A NAT MUST support all valid sequences of TCP packets + (defined in [RFC0793]) for connections initiated both internally + as well as externally when the connection is permitted by the NAT. + In particular: + a) In addition to handling the TCP 3-way handshake mode of + connection initiation, A NAT MUST handle the TCP simultaneous- + open mode of connection initiation. + + Justification: The intent of this requirement is to allow standards + compliant TCP stacks to traverse NATs no matter what path the + stacks take through the TCP state-machine and no matter which end + initiates the connection as long as the connection is permitted by + the filtering policy of the NAT (filtering policy is described in + the following section). + a) In addition to TCP packets for a 3-way handshake, A NAT must be + prepared to accept an inbound SYN and an outbound SYN-ACK for + an internally initiated connection in order to support + simultaneous-open. + + + + +Guha, et al. Best Current Practice [Page 6] + +RFC 5382 NAT TCP Requirements October 2008 + + +4.3. Externally Initiated Connections + + The NAT allocates a mapping for the first connection initiated by an + internal endpoint to an external endpoint. In some scenarios, the + NAT's policy may allow this mapping to be reused for connections + initiated from the external side to the internal endpoint. Consider + as before an internal IP address and port (X:x) that is assigned (or + reuses) a mapping (X1':x1') when it initiates a connection to an + external (Y1:y1). An external endpoint (Y2:y2) attempts to initiate + a connection with the internal endpoint by sending a SYN to + (X1':x1'). A NAT can choose to either allow the connection to be + established, or to disallow the connection. If the NAT chooses to + allow the connection, it translates the inbound SYN and routes it to + (X:x) as per the existing mapping. It also translates the SYN-ACK + generated by (X:x) in response and routes it to (Y2:y2), and so on. + Alternately, the NAT can disallow the connection by filtering the + inbound SYN. + + A NAT may allow an existing mapping to be reused by an externally + initiated connection if its security policy permits. Several + different policies are possible as described in [BEHAVE-UDP]. If a + NAT allows the connection initiation from all (Y2:y2), then it is + defined to have "Endpoint-Independent Filtering" behavior. If the + NAT allows connection initiations only when Y2 equals Y1, then the + NAT is defined to have "Address-Dependent Filtering" behavior. If + the NAT allows connection initiations only when (Y2:y2) equals + (Y1:y1), then the NAT is defined to have "Address and Port-Dependent + Filtering" behavior (possible only shortly after the first connection + has been terminated but the mapping is still active). One additional + filtering behavior defined in this document is when the NAT does not + allow any connection initiations from the external side; in such + cases, the NAT is defined to have "Connection-Dependent Filtering" + behavior. The difference between "Address and Port-Dependent + Filtering" and "Connection-Dependent Filtering" behavior is that the + former permits an inbound SYN during the TIME_WAIT state of the first + connection to initiate a new connection while the latter does not. + + REQ-3: If application transparency is most important, it is + RECOMMENDED that a NAT have an "Endpoint-Independent Filtering" + behavior for TCP. If a more stringent filtering behavior is most + important, it is RECOMMENDED that a NAT have an "Address-Dependent + Filtering" behavior. + a) The filtering behavior MAY be an option configurable by the + administrator of the NAT. + b) The filtering behavior for TCP MAY be independent of the + filtering behavior for UDP. + + + + + +Guha, et al. Best Current Practice [Page 7] + +RFC 5382 NAT TCP Requirements October 2008 + + + Justification: The intent of this requirement is to allow peer-to- + peer applications that do not always initiate connections from the + internal side of the NAT to continue to work in the presence of + NATs. This behavior also allows applications behind a BEHAVE + compliant NAT to inter-operate with remote endpoints that are + behind non-BEHAVE compliant (legacy) NATs. If the remote + endpoint's NAT does not have Endpoint-Independent Mapping behavior + but has only one external IP address, then an application can + still traverse the combination of the two NATs if the local NAT + has Address-Dependent Filtering. Section 9 contains a detailed + discussion on the security implications of this requirement. + + If the inbound SYN packet is filtered, either because a corresponding + mapping does not exist or because of the NAT's filtering behavior, a + NAT has two basic choices: to ignore the packet silently, or to + signal an error to the sender. Signaling an error through ICMP + messages allows the sender to quickly detect that the SYN did not + reach the intended destination. Silently dropping the packet, on the + other hand, allows applications to perform simultaneous-open more + reliably. + + Silently dropping the SYN aids simultaneous-open as follows. + Consider that the application is attempting a simultaneous-open and + the outbound SYN from the internal endpoint has not yet crossed the + NAT (due to network congestion or clock skew between the two + endpoints); this outbound SYN would otherwise have created the + necessary mapping at the NAT to allow translation of the inbound SYN. + Since the outbound SYN did not reach the NAT in time, the inbound SYN + cannot be processed. If a NAT responds to the premature inbound SYN + with an error message that forces the external endpoint to abandon + the connection attempt, it hinders applications performing a TCP + simultaneous-open. If instead the NAT silently ignores the inbound + SYN, the external endpoint retransmits the SYN after a TCP timeout. + In the meantime, the NAT creates the mapping in response to the + (delayed) outbound SYN such that the retransmitted inbound SYN can be + routed and simultaneous-open can succeed. The downside to this + behavior is that in the event the inbound SYN is erroneous, the + remote side does not learn of the error until after several TCP + timeouts. + + NAT support for simultaneous-open as well as quickly signaling errors + are both important for applications. Unfortunately, there is no way + for a NAT to signal an error without forcing the endpoint to abort a + potential simultaneous-open: TCP RST and ICMP Port Unreachable + packets require the endpoint to abort the attempt while the ICMP Host + and Network Unreachable errors may adversely affect other connections + to the same host or network [RFC1122]. + + + + +Guha, et al. Best Current Practice [Page 8] + +RFC 5382 NAT TCP Requirements October 2008 + + + In addition, when an unsolicited SYN is received by the NAT, the NAT + may not know whether the application is attempting a simultaneous- + open (and that it should therefore silently drop the SYN) or whether + the SYN is in error (and that it should notify the sender). + + REQ-4: A NAT MUST NOT respond to an unsolicited inbound SYN packet + for at least 6 seconds after the packet is received. If during + this interval the NAT receives and translates an outbound SYN for + the connection the NAT MUST silently drop the original unsolicited + inbound SYN packet. Otherwise, the NAT SHOULD send an ICMP Port + Unreachable error (Type 3, Code 3) for the original SYN, unless + REQ-4a applies. + a) The NAT MUST silently drop the original SYN packet if sending a + response violates the security policy of the NAT. + + Justification: The intent of this requirement is to allow + simultaneous-open to work reliably in the presence of NATs as well + as to quickly signal an error in case the unsolicited SYN is in + error. As of writing this memo, it is not possible to achieve + both; the requirement therefore represents a compromise. The NAT + should tolerate some delay in the outbound SYN for a TCP + simultaneous-open, which may be due to network congestion or loose + synchronization between the endpoints. If the unsolicited SYN is + not part of a simultaneous-open attempt and is in error, the NAT + should endeavor to signal the error in accordance with [RFC1122]. + a) There may, however, be reasons for the NAT to rate-limit or + omit such error notifications, for example, in the case of an + attack. Silently dropping the SYN packet when under attack + allows simultaneous-open to work without consuming any extra + network bandwidth or revealing the presence of the NAT to + attackers. Section 9 mentions the security considerations for + this requirement. + + For NATs that combine NAT functionality with end-host functionality + (e.g., an end-host that also serves as a NAT for other hosts behind + it), REQ-4 above applies only to SYNs intended for the NAT'ed hosts + and not to SYNs intended for the NAT itself. One way to determine + whether the inbound SYN is intended for a NAT'ed host is to allocate + NAT mappings from one port range, and allocate ports for local + endpoints from a different non-overlapping port range. More dynamic + implementations can be imagined. + + + + + + + + + + +Guha, et al. Best Current Practice [Page 9] + +RFC 5382 NAT TCP Requirements October 2008 + + +5. NAT Session Refresh + + A NAT maintains state associated with in-progress and established + connections. Because of this, a NAT is susceptible to a resource- + exhaustion attack whereby an attacker (or virus) on the internal side + attempts to cause the NAT to create more state than for which it has + resources. To prevent such an attack, a NAT needs to abandon + sessions in order to free the state resources. + + A common method that is applicable only to TCP is to preferentially + abandon sessions for crashed endpoints, followed by closed TCP + connections and partially open connections. A NAT can check if an + endpoint for a session has crashed by sending a TCP keep-alive packet + and receiving a TCP RST packet in response. If the NAT cannot + determine whether the endpoint is active, it should not abandon the + session until the TCP connection has been idle for some time. Note + that an established TCP connection can stay idle (but live) + indefinitely; hence, there is no fixed value for an idle-timeout that + accommodates all applications. However, a large idle-timeout + motivated by recommendations in [RFC1122] can reduce the chances of + abandoning a live session. + + A TCP connection passes through three phases: partially open, + established, and closing. During the partially open phase, endpoints + synchronize initial sequence numbers. The phase is initiated by the + first SYN for the connection and extends until both endpoints have + sent a packet with the ACK flag set (TCP states: SYN_SENT and + SYN_RCVD). ACKs in both directions mark the beginning of the + established phase where application data can be exchanged + indefinitely (TCP states: ESTABLISHED, FIN_WAIT_1, FIN_WAIT_2, and + CLOSE_WAIT). The closing phase begins when both endpoints have + terminated their half of the connection by sending a FIN packet. + Once FIN packets are seen in both directions, application data can no + longer be exchanged, but the stacks still need to ensure that the FIN + packets are received (TCP states: CLOSING and LAST_ACK). + + TCP connections can stay in established phase indefinitely without + exchanging any packets. Some end-hosts can be configured to send + keep-alive packets on such idle connections; by default, such keep- + alive packets are sent every 2 hours if enabled [RFC1122]. + Consequently, a NAT that waits for slightly over 2 hours can detect + idle connections with keep-alive packets being sent at the default + rate. TCP connections in the partially open or closing phases, on + the other hand, can stay idle for at most 4 minutes while waiting for + in-flight packets to be delivered [RFC1122]. + + + + + + +Guha, et al. Best Current Practice [Page 10] + +RFC 5382 NAT TCP Requirements October 2008 + + + The "established connection idle-timeout" for a NAT is defined as the + minimum time a TCP connection in the established phase must remain + idle before the NAT considers the associated session a candidate for + removal. The "transitory connection idle-timeout" for a NAT is + defined as the minimum time a TCP connection in the partially open or + closing phases must remain idle before the NAT considers the + associated session a candidate for removal. TCP connections in the + TIME_WAIT state are not affected by the "transitory connection idle- + timeout". + + REQ-5: If a NAT cannot determine whether the endpoints of a TCP + connection are active, it MAY abandon the session if it has been + idle for some time. In such cases, the value of the "established + connection idle-timeout" MUST NOT be less than 2 hours 4 minutes. + The value of the "transitory connection idle-timeout" MUST NOT be + less than 4 minutes. + a) The value of the NAT idle-timeouts MAY be configurable. + + Justification: The intent of this requirement is to minimize the + cases where a NAT abandons session state for a live connection. + While some NATs may choose to abandon sessions reactively in + response to new connection initiations (allowing idle connections + to stay up indefinitely in the absence of new initiations), other + NATs may choose to proactively reap idle sessions. In cases where + the NAT cannot actively determine if the connection is alive, this + requirement ensures that applications can send keep-alive packets + at the default rate (every 2 hours) such that the NAT can + passively determine that the connection is alive. The additional + 4 minutes allows time for in-flight packets to cross the NAT. + + NAT behavior for handling RST packets, or connections in TIME_WAIT + state is left unspecified. A NAT MAY hold state for a connection in + TIME_WAIT state to accommodate retransmissions of the last ACK. + However, since the TIME_WAIT state is commonly encountered by + internal endpoints properly closing the TCP connection, holding state + for a closed connection may limit the throughput of connections + through a NAT with limited resources. [RFC1337] describes hazards + associated with TIME_WAIT assassination. + + The handling of non-SYN packets for connections for which there is no + active mapping is left unspecified. Such packets may be received if + the NAT silently abandons a live connection, or abandons a connection + in TIME_WAIT state before the 4 minute TIME_WAIT period expires. The + decision to either silently drop such packets or to respond with a + TCP RST packet is left up to the implementation. + + + + + + +Guha, et al. Best Current Practice [Page 11] + +RFC 5382 NAT TCP Requirements October 2008 + + + NAT behavior for notifying endpoints when abandoning live connections + is left unspecified. When a NAT abandons a live connection, for + example due to a timeout expiring, the NAT MAY either send TCP RST + packets to the endpoints or MAY silently abandon the connection. + + Sending a RST notification allows endpoint applications to recover + more quickly; however, notifying the endpoints may not always be + possible if, for example, session state is lost due to a power + failure. + +6. Application Level Gateways + + Application Level Gateways (ALGs) in certain NATs modify IP addresses + and TCP ports embedded inside application protocols. Such ALGs may + interfere with UNSAF methods or protocols that try to be NAT-aware + and must therefore be used with extreme caution. + + REQ-6: If a NAT includes ALGs that affect TCP, it is RECOMMENDED + that all of those ALGs (except for FTP [RFC0959]) be disabled by + default. + + Justification: The intent of this requirement is to prevent ALGs + from interfering with UNSAF methods. The default state of an FTP + ALG is left unspecified because of legacy concerns: as of writing + this memo, a large fraction of legacy FTP clients do not enable + passive (PASV) mode by default and require an ALG to traverse + NATs. + +7. Other Requirements Applicable to TCP + + A list of general and UDP-specific NAT behavioral requirements are + described in [BEHAVE-UDP]. A list of ICMP-specific NAT behavioral + requirements are described in [BEHAVE-ICMP]. The requirements listed + below reiterate the requirements from these two documents that + directly affect TCP. The following requirements do not relax any + requirements in [BEHAVE-UDP] or [BEHAVE-ICMP]. + +7.1. Port Assignment + + NATs that allow different internal endpoints to simultaneously use + the same mapping are defined in [BEHAVE-UDP] to have a "Port + assignment" behavior of "Port overloading". Such behavior is + undesirable, as it prevents two internal endpoints sharing the same + mapping from establishing simultaneous connections to a common + external endpoint. + + REQ-7: A NAT MUST NOT have a "Port assignment" behavior of "Port + overloading" for TCP. + + + +Guha, et al. Best Current Practice [Page 12] + +RFC 5382 NAT TCP Requirements October 2008 + + + Justification: This requirement allows two applications on the + internal side of the NAT to consistently communicate with the same + destination. + + NAT behavior for preserving the source TCP port range for connections + is left unspecified. Some applications expect the source TCP port to + be in the well-known range (TCP ports from 0 to 1023). The "r" + series of commands (rsh, rcp, rlogin, etc.) are an example. NATs + that preserve the range from which the source port is picked allow + such applications to function properly through the NAT; however, by + doing so the NAT may compromise the security of the application in + certain situations; applications that depend only on the IP address + and source TCP port range for security (the "r" commands, for + example) cannot distinguish between an attacker and a legitimate user + behind the same NAT. + +7.2. Hairpinning Behavior + + NATs that forward packets originating from an internal address, + destined for an external address that matches the active mapping for + an internal address, back to that internal address are defined in + [BEHAVE-UDP] as supporting "hairpinning". If the NAT presents the + hairpinned packet with an external source IP address and port (i.e., + the mapped source address and port of the originating internal + endpoint), then it is defined to have "External source IP address and + port" for hairpinning. Hairpinning is necessary to allow two + internal endpoints (known to each other only by their external mapped + addresses) to communicate with each other. "External source IP + address and port" behavior for hairpinning avoids confusing + implementations that expect the external source IP address and port. + + REQ-8: A NAT MUST support "hairpinning" for TCP. + a) A NAT's hairpinning behavior MUST be of type "External source + IP address and port". + + Justification: This requirement allows two applications behind the + same NAT that are trying to communicate with each other using + their external addresses. + a) Using the external source address and port for the hairpinned + packet is necessary for applications that do not expect to + receive a packet from a different address than the external + address they are trying to communicate with. + +7.3. ICMP Responses to TCP Packets + + Several TCP mechanisms depend on the reception of ICMP error messages + triggered by the transmission of TCP segments. One such mechanism is + path MTU discovery [RFC1191], which is required for the correct + + + +Guha, et al. Best Current Practice [Page 13] + +RFC 5382 NAT TCP Requirements October 2008 + + + operation of TCP. The current path MTU discovery mechanism requires + the sender of TCP segments to be notified of ICMP "Datagram Too Big" + responses. + + REQ-9: If a NAT translates TCP, it SHOULD translate ICMP Destination + Unreachable (Type 3) messages. + + Justification: Translating ICMP Destination Unreachable messages, + particularly the "Fragmentation Needed and Don't Fragment was Set" + (Type 3, Code 4) message avoids communication failures ("black + holes" [RFC2923]). Furthermore, TCP's connection establishment + and maintenance mechanisms also behave much more efficiently when + ICMP Destination Unreachable messages arrive in response to + outgoing TCP segments. + + REQ-10: Receipt of any sort of ICMP message MUST NOT terminate the + NAT mapping or TCP connection for which the ICMP was generated. + + Justification: This is necessary for reliably performing TCP + simultaneous-open where a remote NAT may temporarily signal an + ICMP error. + +8. Requirements + + A NAT that supports all of the mandatory requirements of this + specification (i.e., the "MUST") and is compliant with [BEHAVE-UDP], + is "compliant with this specification". A NAT that supports all of + the requirements of this specification (i.e., included the + "RECOMMENDED") and is fully compliant with [BEHAVE-UDP] is "fully + compliant with all the mandatory and recommended requirements of this + specification". + + REQ-1: A NAT MUST have an "Endpoint-Independent Mapping" behavior + for TCP. + + REQ-2: A NAT MUST support all valid sequences of TCP packets + (defined in [RFC0793]) for connections initiated both internally + as well as externally when the connection is permitted by the NAT. + In particular: + a) In addition to handling the TCP 3-way handshake mode of + connection initiation, A NAT MUST handle the TCP simultaneous- + open mode of connection initiation. + + REQ-3: If application transparency is most important, it is + RECOMMENDED that a NAT have an "Endpoint-Independent Filtering" + behavior for TCP. If a more stringent filtering behavior is most + important, it is RECOMMENDED that a NAT have an "Address-Dependent + Filtering" behavior. + + + +Guha, et al. Best Current Practice [Page 14] + +RFC 5382 NAT TCP Requirements October 2008 + + + a) The filtering behavior MAY be an option configurable by the + administrator of the NAT. + b) The filtering behavior for TCP MAY be independent of the + filtering behavior for UDP. + + REQ-4: A NAT MUST NOT respond to an unsolicited inbound SYN packet + for at least 6 seconds after the packet is received. If during + this interval the NAT receives and translates an outbound SYN for + the connection the NAT MUST silently drop the original unsolicited + inbound SYN packet. Otherwise, the NAT SHOULD send an ICMP Port + Unreachable error (Type 3, Code 3) for the original SYN, unless + REQ-4a applies. + a) The NAT MUST silently drop the original SYN packet if sending a + response violates the security policy of the NAT. + + REQ-5: If a NAT cannot determine whether the endpoints of a TCP + connection are active, it MAY abandon the session if it has been + idle for some time. In such cases, the value of the "established + connection idle-timeout" MUST NOT be less than 2 hours 4 minutes. + The value of the "transitory connection idle-timeout" MUST NOT be + less than 4 minutes. + a) The value of the NAT idle-timeouts MAY be configurable. + + REQ-6: If a NAT includes ALGs that affect TCP, it is RECOMMENDED + that all of those ALGs (except for FTP [RFC0959]) be disabled by + default. + + The following requirements reiterate requirements from [BEHAVE-UDP] + or [BEHAVE-ICMP] that directly affect TCP. This document does not + relax any requirements in [BEHAVE-UDP] or [BEHAVE-ICMP]. + + REQ-7: A NAT MUST NOT have a "Port assignment" behavior of "Port + overloading" for TCP. + + REQ-8: A NAT MUST support "hairpinning" for TCP. + a) A NAT's hairpinning behavior MUST be of type "External source + IP address and port". + + REQ-9: If a NAT translates TCP, it SHOULD translate ICMP Destination + Unreachable (Type 3) messages. + + REQ-10: Receipt of any sort of ICMP message MUST NOT terminate the + NAT mapping or TCP connection for which the ICMP was generated. + + + + + + + + +Guha, et al. Best Current Practice [Page 15] + +RFC 5382 NAT TCP Requirements October 2008 + + +9. Security Considerations + + [BEHAVE-UDP] discusses security considerations for NATs that handle + IP and unicast UDP traffic. Security concerns specific to handling + TCP packets are discussed in this section. + + Security considerations for REQ-1: This requirement does not + introduce any TCP-specific security concerns. + + Security considerations for REQ-2: This requirement does not + introduce any TCP-specific security concerns. Simultaneous-open + and other transitions in the TCP state machine are by-design and + necessary for TCP to work correctly in all scenarios. Further, + this requirement only affects connections already in progress as + authorized by the NAT in accordance with its policy. + + Security considerations for REQ-3: The security provided by the NAT + is governed by its filtering behavior as addressed in + [BEHAVE-UDP]. Connection-Dependent Filtering behavior is most + secure from a firewall perspective, but severely restricts + connection initiations through a NAT. Endpoint-Independent + Filtering behavior, which is most transparent to applications, + requires an attacker to guess the IP address and port of an active + mapping in order to get his packet to an internal host. Address- + Dependent Filtering, on the other hand, is less transparent than + Endpoint-Independent Filtering but more transparent than + Connection-Dependent Filtering; it is more secure than Endpoint- + Independent Filtering as it requires an attacker to additionally + guess the address of the external endpoint for a NAT session + associated with the mapping and be able to receive packets + addressed to the same. While this protects against most attackers + on the Internet, it does not necessarily protect against attacks + that originate from behind a remote NAT with a single IP address + that is also translating a legitimate connection to the victim. + + Security considerations for REQ-4: This document recommends that a + NAT respond to unsolicited inbound SYN packets with an ICMP error + delayed by a few seconds. Doing so may reveal the presence of a + NAT to an external attacker. Silently dropping the SYN makes it + harder to diagnose network problems and forces applications to + wait for the TCP stack to finish several retransmissions before + reporting an error. An implementer must therefore understand and + carefully weigh the effects of not sending an ICMP error or rate- + limiting such ICMP errors to a very small number. + + + + + + + +Guha, et al. Best Current Practice [Page 16] + +RFC 5382 NAT TCP Requirements October 2008 + + + Security considerations for REQ-5: This document recommends that a + NAT that passively monitors TCP state keep idle sessions alive for + at least 2 hours 4 minutes or 4 minutes depending on the state of + the connection. If a NAT is under attack, it may attempt to + actively determine the liveliness of a TCP connection or let the + NAT administrator configure more conservative timeouts. + + Security considerations for REQ-6: This requirement does not + introduce any TCP-specific security concerns. + + Security considerations for REQ-7: This requirement does not + introduce any TCP-specific security concerns. + + Security considerations for REQ-8: This requirement does not + introduce any TCP-specific security concerns. + + Security considerations for REQ-9: This requirement does not + introduce any TCP-specific security concerns. + + Security considerations for REQ-10: This requirement does not + introduce any TCP-specific security concerns. + + NAT implementations that modify TCP sequence numbers (e.g., for + privacy reasons or for ALG support) must ensure that TCP packets with + Selective Acknowledgement (SACK) notifications [RFC2018] are properly + handled. + + NAT implementations that modify local state based on TCP flags in + packets must ensure that out-of-window TCP packets are properly + handled. [RFC4953] summarizes and discusses a variety of solutions + designed to prevent attackers from affecting TCP connections. + +10. Acknowledgments + + Joe Touch contributed the mechanism for handling unsolicited inbound + SYNs. Thanks to Mark Allman, Francois Audet, Lars Eggert, Paul + Francis, Fernando Gont, Sam Hartman, Paul Hoffman, Dave Hudson, + Cullen Jennings, Philip Matthews, Tom Petch, Magnus Westerlund, and + Dan Wing for their many contributions, comments, and suggestions. + + + + + + + + + + + + +Guha, et al. Best Current Practice [Page 17] + +RFC 5382 NAT TCP Requirements October 2008 + + +11. References + +11.1. Normative References + + [BEHAVE-UDP] Audet, F. and C. Jennings, "Network Address + Translation (NAT) Behavioral Requirements for Unicast + UDP", BCP 127, RFC 4787, January 2007. + + [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, + RFC 793, September 1981. + + [RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol", + STD 9, RFC 959, October 1985. + + [RFC1122] Braden, R., "Requirements for Internet Hosts - + Communication Layers", STD 3, RFC 1122, October 1989. + + [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", + RFC 1191, November 1990. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + +11.2. Informational References + + [BEHAVE-ICMP] Srisuresh, P., Ford, B., Sivakumar, S., and S. Guha, + "NAT Behavioral Requirements for ICMP protocol", Work + in Progress, June 2008. + + [NAT-MIB] Rohit, R., Srisuresh, P., Raghunarayan, R., Pai, N., + and C. Wang, "Definitions of Managed Objects for + Network Address Translators (NAT)", RFC 4008, + March 2005. + + [NATBLASTER] Biggadike, A., Ferullo, D., Wilson, G., and A. Perrig, + "NATBLASTER: Establishing TCP connections between + hosts behind NATs", Proceedings of the ACM SIGCOMM + Asia Workshop (Beijing, China), April 2005. + + [P2PNAT] Ford, B., Srisuresh, P., and D. Kegel, "Peer-to-peer + communication across network address translators", + Proceedings of the USENIX Annual Technical + Conference (Anaheim, CA), April 2005. + + [RFC1337] Braden, B., "TIME-WAIT Assassination Hazards in TCP", + RFC 1337, May 1992. + + + + + +Guha, et al. Best Current Practice [Page 18] + +RFC 5382 NAT TCP Requirements October 2008 + + + [RFC1644] Braden, B., "T/TCP -- TCP Extensions for Transactions + Functional Specification", RFC 1644, July 1994. + + [RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, + "TCP Selective Acknowledgment Options", RFC 2018, + October 1996. + + [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address + Translator (NAT) Terminology and Considerations", + RFC 2663, August 1999. + + [RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery", + RFC 2923, September 2000. + + [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network + Address Translator (Traditional NAT)", RFC 3022, + January 2001. + + [RFC4614] Duke, M., Braden, R., Eddy, W., and E. Blanton, "A + Roadmap for Transmission Control Protocol (TCP) + Specification Documents", RFC 4614, September 2006. + + [RFC4953] Touch, J., "Defending TCP Against Spoofing Attacks", + RFC 4953, July 2007. + + [STUNT] Guha, S. and P. Francis, "NUTSS: A SIP based approach + to UDP and TCP connectivity", Proceedings of the ACM + SIGCOMM Workshop on Future Directions in Network + Architecture (Portland, OR), August 2004. + + [TCPTRAV] Guha, S. and P. Francis, "Characterization and + Measurement of TCP Traversal through NATs and + Firewalls", Proceedings of the Internet Measurement + Conference (Berkeley, CA), October 2005. + + + + + + + + + + + + + + + + + +Guha, et al. Best Current Practice [Page 19] + +RFC 5382 NAT TCP Requirements October 2008 + + +Authors' Addresses + + Saikat Guha (editor) + Cornell University + 331 Upson Hall + Ithaca, NY 14853 + US + Phone: +1 607 255 1008 + EMail: saikat@cs.cornell.edu + + Kaushik Biswas + Cisco Systems, Inc. + 170 West Tasman Dr. + San Jose, CA 95134 + US + Phone: +1 408 525 5134 + EMail: kbiswas@cisco.com + + Bryan Ford + Max Planck Institute for Software Systems + Campus Building E1 4 + D-66123 Saarbruecken + Germany + Phone: +49-681-9325657 + EMail: baford@mpi-sws.org + + Senthil Sivakumar + Cisco Systems, Inc. + 7100-8 Kit Creek Road + PO Box 14987 + Research Triangle Park, NC 27709-4987 + US + Phone: +1 919 392 5158 + EMail: ssenthil@cisco.com + + Pyda Srisuresh + Kazeon Systems, Inc. + 1161 San Antonio Rd. + Mountain View, CA 94043 + US + Phone: +1 408 836 4773 + EMail: srisuresh@yahoo.com + + + + + + + + + +Guha, et al. Best Current Practice [Page 20] + +RFC 5382 NAT TCP Requirements October 2008 + + +Full Copyright Statement + + Copyright (C) The IETF Trust (2008). + + 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, THE IETF TRUST 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. + +Intellectual Property + + 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. + + + + + + + + + + + + +Guha, et al. Best Current Practice [Page 21] + |