RFC 5382

NAT Behavioral Requirements for TCP

📅 published October 2008, from ietf

NAT Behavioral Requirements for TCP ✨

Okay bestie, this is RFC 5382 🦋, a Best Current Practice (BCP 142), so it's the community's go-to guidance 💅. It came out of the Network Working Group in October 2008. S. Guha of Cornell U. is the editor 🎀, and the co-authors are K. Biswas (Cisco Systems), B. Ford (MPI-SWS), S. Sivakumar (Cisco Systems), and P. Srisuresh (Kazeon Systems) 🫶. The header doesn't list anything it obsoletes or updates, so it's standing on its own 👑.

Status of This Memo 📜

This doc is a Best Current Practice for the Internet Community 🌈, and it's asking everyone for discussion and suggestions to make it better. Distribution of this memo is unlimited 💜.

Abstract 💖

This doc lays out a set of requirements for NATs that handle TCP so that lots of apps, like peer-to-peer stuff and online games 🎮, can work consistently. If NATs meet these requirements, those apps are way more likely to function properly. It's giving reliability ✨.

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

1. Applicability Statement 🎀

This doc is an add-on to [BEHAVE-UDP] 📎. That one defines a lot of NAT terms, lays out general requirements for all NATs, and sets requirements for NATs that handle IP and unicast UDP traffic. This doc's whole job is setting requirements for NATs that handle TCP traffic.

The requirements here apply to traditional NATs as described in [RFC2663].

This doc only covers the TCP side of NAT traversal. Middlebox behavior that isn't needed to translate TCP is out of scope 🙅. Packet inspection above the TCP layer and firewalls are also 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 too. Signaling-based approaches that directly control the NAT, like Middlebox Communication (MIDCOM) and Universal Plug and Play (UPnP), are out of scope. Lastly, TCP connections meant for the NAT itself (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) make connectivity harder for applications where sessions might be started toward internal hosts 😤. If you want the details on traditional NATs, check out [RFC3022]. [BEHAVE-UDP] lays out the terminology and requirements for NATs in the context of IP and UDP. This doc builds on that by setting requirements for NATs that handle TCP traffic, and everything defined and required in [BEHAVE-UDP] is inherited here 🫶.

[RFC4614] chronicles how TCP evolved from the original definition in [RFC0793] to today's implementations. A lot has changed with congestion control, flow control, security, and support for high-bandwidth networks 🔥. But the way a connection gets started (the 3-way handshake or simultaneous-open) has barely changed, and that's exactly the part NATs mess with the most 💀. Experimental approaches like T/TCP [RFC1644] proposed different ways to start connections, but they turned out to be complex and open to denial-of-service attacks 🙈. So modern operating systems and NATs mostly stick with the 3-way handshake and simultaneous-open modes described in [RFC0793] 💅.

A bunch of techniques have been cooked up lately to make peer-to-peer TCP apps work across NATs ✨. [STUNT], [NATBLASTER], and [P2PNAT] describe Unilateral Self-Address Fixing (UNSAF) mechanisms that let peer-to-peer apps establish TCP through NATs. These only need the endpoint apps to be modified and they work with standards-compliant OS stacks 🙌. The catch is that they depend on specific NAT behavior that's usually, but not always, supported (see [TCPTRAV] and [P2PNAT] for details). So a complete TCP NAT traversal solution sometimes ends up relying on public TCP relays to get through NATs that won't cooperate 😭. This document defines requirements so TCP NAT traversal approaches aren't 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 spec covers 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 provides the translation glue between the two session representations 🧩.

This doc 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 doc uses the term "address and port mapping" (or just "mapping") as defined in [BEHAVE-UDP] to mean the state at the NAT needed for network address and port translation of TCP connections 🗺️. It also uses these terms as defined in [BEHAVE-UDP]: "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" 💜.

4. TCP Connection Initiation 🚀

This section describes the various NAT behaviors that apply to TCP connection initiation 🌟.

4.1. Address and Port Mapping Behavior 🗺️

A NAT uses a mapping to translate packets for each TCP connection 💫. Mappings get dynamically allocated for connections started from the internal side, and they can potentially be reused for certain later connections. When a mapping can be reused depends on the NAT, and [BEHAVE-UDP] explains the differences 💅.

Here's the setup. An internal IP address and TCP port X:x starts a TCP connection to an external Y1:y1 tuple, and the NAT gives that connection the mapping X1':x1'. Shortly after, the same X:x opens a connection to an external address Y2:y2 and gets the mapping X2':x2' on the NAT 👀. Per [BEHAVE-UDP], here's how the NAT gets classified:

  • If X1':x1' equals X2':x2' for all values of Y2:y2, the NAT has "Endpoint-Independent Mapping" behavior ✨.
  • If X1':x1' equals X2':x2' only when Y2 equals Y1, the NAT has "Address-Dependent Mapping" behavior 🎀.
  • If X1':x1' equals X2':x2' only when (Y2:y2) equals (Y1:y1), the NAT has "Address and Port-Dependent Mapping" behavior 🌸. This only happens for consecutive connections to the same external address shortly after the first one ends, and only if the NAT keeps state for connections in TIME_WAIT state 🙈.
  • This doc introduces one more behavior, where X1':x1' never equals X2':x2'. That is, every connection gets a brand-new mapping. In that case the NAT has "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 lets peer-to-peer apps learn and advertise the external IP address and port allocated to an internal endpoint, so external peers can contact it (subject to the NAT's security policy) 🤝. The NAT's security policy is independent of its mapping behavior, and it's discussed later in Section 4.3 🔐. So with Endpoint-Independent Mapping, peer-to-peer apps can work consistently without compromising the security benefits of the NAT 👑.

4.2. Internally Initiated Connections ✨

okay so an internal endpoint starts a TCP connection through a NAT by sending a SYN packet 📤. The NAT then makes a new mapping for that connection (or reuses one it already has), like we talked about in the last section 🗺️. That mapping decides which external IP address and port get used to translate every packet for the connection 🫶. For the classic client-server setup, where an internal client calls out to an external server, the NAT uses that same mapping to translate the outbound SYN, the inbound SYN-ACK that comes back, the outbound ACK that follows, and everything else on the connection. This is the regular 3-way handshake from [RFC0793], and literally every NAT supports it 💅.

Peer-to-peer apps need a different trick to get through NATs, and it's called simultaneous-open (Fig. 8, [RFC0793]) 🦋. Both peers send a SYN for the same TCP connection at the same time, so the SYNs cross in the network 🌀. When each end gets the other's SYN, it answers with a SYN-ACK, and those cross too. The connection counts as established once the SYN-ACKs arrive 🎉. From the NAT's point of view, the internal host's SYN gets met by an inbound SYN for the same connection, instead of the SYN-ACK you'd see in a normal 3-way handshake 👀. After that, the NAT sees both an outbound SYN-ACK and an inbound SYN-ACK for the connection. Some NATs wrongly block the inbound SYN for a connection that's already in progress 🙅‍♀️, and some NATs block or mistranslate the outbound SYN-ACK 💀. Behavior like that breaks TCP simultaneous-open and stops peer-to-peer apps from working properly behind a NAT 😭.

To give network address translation for TCP at all, a NAT has to correctly receive, translate, and forward every packet on a connection that follows a valid transition in the TCP State-Machine (Fig. 6, [RFC0793]) 🧩. No skipping steps!

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 point of this requirement is to let standards-compliant TCP stacks get through NATs no matter which path they take through the TCP state-machine, and no matter which end starts the connection, as long as the NAT's filtering policy allows the connection (filtering policy is covered in the next 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 🌸.

4.3. Externally Initiated Connections 🌈

the NAT makes a mapping for the first connection an internal endpoint starts to an external endpoint 🗺️. Depending on the scenario, the NAT's policy might let that same mapping be reused for connections that start from the outside and head to the internal endpoint 🔄. Picture the same setup as before: an internal IP address and port (X:x) gets a mapping (X1':x1') when it opens a connection to an external Y1:y1. Now an external endpoint (Y2:y2) tries to start a connection to the internal endpoint by sending a SYN to X1':x1' 📨. The NAT can either let the connection go through or block it 🚦. If it lets it through, the NAT translates the inbound SYN and routes it to X:x based on the existing mapping. It also translates the SYN-ACK that X:x sends back and routes it to Y2:y2, and the rest of the handshake follows the same path 🤝. Or the NAT can block the connection by filtering out the inbound SYN 🛑.

A NAT may let an existing mapping be reused for an externally initiated connection if its security policy allows it, and [BEHAVE-UDP] describes several different policies that are possible 🔐. If a NAT allows connection initiations from any Y2:y2, it's defined to have "Endpoint-Independent Filtering" behavior 🌍. If it only allows connection initiations when Y2 equals Y1, it's defined to have "Address-Dependent Filtering" behavior 🏠. If it only allows connection initiations when (Y2:y2) equals (Y1:y1), it's defined to have "Address and Port-Dependent Filtering" behavior 🎯. That last one is only possible shortly after the first connection has ended, while the mapping is still hanging around ⏳. This document also defines one more filtering behavior: when the NAT doesn't allow any connection initiations from the external side at all, it's defined to have "Connection-Dependent Filtering" behavior 🔒. The difference between "Address and Port-Dependent Filtering" and "Connection-Dependent Filtering" is that the first one lets an inbound SYN during the TIME_WAIT state of the first connection start a new connection, and the second one doesn't 🧐.

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.

Justification: The point of this requirement is to let peer-to-peer apps that don't always start connections from the internal side of the NAT keep working through NATs 🫧. It also lets apps behind a BEHAVE compliant NAT talk to remote endpoints that sit behind non-BEHAVE compliant (legacy) NATs 🤝. If the remote endpoint's NAT doesn't have Endpoint-Independent Mapping behavior but has only one external IP address, an app can still get through both NATs as long as the local NAT has Address-Dependent Filtering 💖. Section 9 goes deep on the security implications of this requirement 🛡️.

If the inbound SYN packet gets filtered out, either because there's no matching mapping or because of the NAT's filtering behavior, the NAT has two basic options: silently ignore the packet, or send an error back to the sender 🙈. Sending an error through ICMP messages lets the sender find out quickly that the SYN never reached its destination ⚡. Silently dropping the packet, on the other hand, helps applications do simultaneous-open more reliably 🫶.

Silently dropping the SYN helps simultaneous-open like this. Imagine an app trying a simultaneous-open where the outbound SYN from the internal endpoint hasn't made it through the NAT yet, maybe because of network congestion or clock skew between the two endpoints 🕰️. That outbound SYN would have created the mapping the NAT needs to translate the inbound SYN. Since the outbound SYN didn't reach the NAT in time, the inbound SYN can't be processed yet 😵. If the NAT answers that early inbound SYN with an error that makes the external endpoint give up on the connection attempt, it gets in the way of TCP simultaneous-open 🚫. But if the NAT quietly ignores the inbound SYN, the external endpoint just retransmits the SYN after a TCP timeout ⏰. In the meantime, the NAT creates the mapping from the delayed outbound SYN, so the retransmitted inbound SYN can be routed and the simultaneous-open can succeed 🎉. The downside is that if the inbound SYN really is an error, the remote side doesn't find out until after several TCP timeouts 😩.

Both NAT support for simultaneous-open and quickly signaling errors matter to applications 💅. Sadly, there's no way for a NAT to send an error without forcing the endpoint to abort a potential simultaneous-open. TCP RST and ICMP Port Unreachable packets make the endpoint abort the attempt, while the ICMP Host and Network Unreachable errors might hurt other connections to the same host or network [RFC1122] 💔.

On top of that, when the NAT gets an unsolicited SYN, it may not be able to tell whether the app is attempting a simultaneous-open (in which case it should quietly drop the SYN) or whether the SYN is just in error (in which case it should tell 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 point of this requirement is to let simultaneous-open work reliably through NATs and also to quickly signal an error when the unsolicited SYN really is in error 🌟. As of writing this memo, it isn't possible to get both, so this requirement is a compromise 🫠. The NAT should put up with some delay in the outbound SYN for a TCP simultaneous-open, which might come from network congestion or loose synchronization between the endpoints ⏳. If the unsolicited SYN isn't part of a simultaneous-open attempt and it's in error, the NAT should try to signal the error in line with [RFC1122] 📣.

a) There may, however, be reasons for the NAT to rate-limit or skip those error notifications, for example during an attack 🚨. Silently dropping the SYN packet when under attack lets simultaneous-open keep working without using any extra network bandwidth or revealing the NAT's presence to attackers 🥷. Section 9 covers the security considerations for this requirement 🔐.

For NATs that also do end-host work (like an end-host that acts as a NAT for other hosts behind it), REQ-4 above only applies to SYNs meant for the NAT'ed hosts, not to SYNs meant for the NAT itself 🏰. One way to tell whether an inbound SYN is meant 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 are also possible ✨.

5. NAT Session Refresh ✨

okay so a NAT keeps state for connections that are still in progress AND for ones that are already established 🧠. That makes it kinda vulnerable to a resource-exhaustion attack, where an attacker (or a virus 🦠) on the inside tries to make the NAT create more state than it has room for 💀. To stop that, a NAT needs to abandon sessions so it can free up those state resources 🧹.

A common method, and this one only works for TCP 🎀, is to go after sessions for crashed endpoints first, then closed TCP connections, then partially open connections. A NAT can check whether an endpoint for a session has crashed by sending a TCP keep-alive packet and getting a TCP RST packet back. If the NAT can't tell whether the endpoint is active, it should not abandon the session until the TCP connection has been idle for some time. ngl this part matters a lot: an established TCP connection can sit idle (but still be alive) indefinitely 🦋, so there's no single idle-timeout value that works for every application. Still, a large idle-timeout based on the recommendations in [RFC1122] can cut down on the chances of killing a live session 🙈.

A TCP connection goes through three phases: partially open, established, and closing. During the partially open phase, the endpoints synchronize their initial sequence numbers 🤝. This phase starts with the first SYN for the connection and keeps going 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 start 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 once both endpoints have ended their half of the connection by sending a FIN packet. Once FIN packets are seen in both directions, application data can't be exchanged anymore, but the stacks still have to make sure those FIN packets actually get received (TCP states: CLOSING and LAST_ACK).

TCP connections can stay in the established phase indefinitely without exchanging any packets. Some end-hosts can be configured to send keep-alive packets on these idle connections; by default, those keep-alive packets go out every 2 hours if enabled [RFC1122]. So a NAT that waits for slightly over 2 hours can detect idle connections through keep-alive packets 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 they wait for in-flight packets to be delivered [RFC1122].

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) so 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 the TIME_WAIT state, is left unspecified. A NAT MAY hold state for a connection in the 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 that have no active mapping is left unspecified. Such packets may be received if the NAT silently abandons a live connection, or abandons a connection in the TIME_WAIT state before the 4 minute TIME_WAIT period expires. The decision to either silently drop such packets or respond with a TCP RST packet is left up to the implementation 🤷‍♀️.

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 an RST notification lets endpoint applications 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. These ALGs may interfere with UNSAF methods or with protocols that try to be NAT-aware, so they 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 is described in [BEHAVE-UDP]. A list of ICMP-specific NAT behavioral requirements is 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] as having a "Port assignment" behavior of "Port overloading". This behavior is undesirable, because 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.

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.) is an example. NATs that preserve the range from which the source port is picked let such applications 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. The "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 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 🎀

okay bestie, this is the checklist part 📋 ngl the big words here are the "MUST" and "RECOMMENDED" ones, so pay attention 💅 a NAT that supports all of the mandatory stuff (the "MUST" ones) and is compliant with [BEHAVE-UDP] is "compliant with this specification". a NAT that supports everything in this spec, including the "RECOMMENDED" ones, 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. the main point is that it has to handle the whole TCP dance, not just the easy version 💃 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. 🌸

  • 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]. so these are repeats from the other specs, but they still apply to TCP 🫶

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

9. Security Considerations 🔐

this part is serious, so we're going full drama 😭 [BEHAVE-UDP] already covers security for NATs handling IP and unicast UDP traffic. this section is for the security stuff that's specific to TCP packets.

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. ⚠️

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. Huge 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. the real MVPs 🫶

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

Authors' Addresses 💌

okay so here are the lovely humans who wrote this, bestie 🫶 I'm keeping every address, phone number, and email exactly as it was so you can reach them if you ever need to. 🎀

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

okay the legal bit, but make it cute 🎀 The copyright for this doc is (C) The IETF Trust (2008). 💖

This document is subject to the rights, licenses and restrictions contained in BCP 78. Except as set out there, the authors keep 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 🌈

so the IETF is basically saying "we don't know if there's a patent or any other rights hiding in here, and we didn't go digging for them" 🙈 They take no position on whether any of those rights are valid or how far they reach, and they don't say whether a license is available either. 💅

Stuff about rights in RFC documents lives in BCP 78 and BCP 79, so go look there if you need the details. ✨

Want the IPR disclosures, the license assurances, or the results of any attempt to get a general license or permission for implementers and users? Those are at http://www.ietf.org/ipr, which is the IETF online IPR repository. 🔥

The IETF also invites anyone to flag any copyrights, patents, patent applications, or other proprietary rights that might cover technology needed to implement this standard. Send that to ietf-ipr@ietf.org. 🫶

That's the whole thing, bestie! 🌈👑

📦 where this page comes from