RFC 7857

Updates to Network Address Translation (NAT) Behavioral Requirements

📅 published April 2016, from ietf

RFC 7857: Updates to Network Address Translation (NAT) Behavioral Requirements 🎀

okay bestie, this one is the Internet Engineering Task Force (IETF) being the best group chat ever 💅 It's RFC 7857, a Best Current Practice (that's BCP 127 🦋), published in April 2016. It's the IETF's official update to the NAT rules from RFC 4787, RFC 5382, and RFC 5508. The authors are R. Penno (Cisco) 💜, S. Perreault (Jive Communications) 🌸, M. Boucadair, Ed. (Orange) 🍓, S. Sivakumar (Cisco) ✨, and K. Naito (NTT) 🧚. It's an ISSN 2070-1721 thing, and it updates RFCs 4787, 5382, and 5508. It doesn't just tweak them lightly either, it actually changes how they apply. The status is still "Best Current Practice," so this is the community's recommended way of doing things rn 👑

Abstract

okay so the abstract is short and sweet 🌈 This doc clarifies and updates a bunch of requirements from RFCs 4787, 5382, and 5508, based on what people have learned from actually running and building NATs. The main focus is NAT44, which means Network Address Translation from IPv4 to IPv4 🦋

This document updates RFCs 4787, 5382, and 5508.

Status of This Memo

okay this is the legal-ish bit, but it's giving "official stamp" 💅

This memo documents an Internet Best Current Practice.

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It went through public review and got approved for publication by the Internet Engineering Steering Group (IESG) 🫶 More info about BCPs is in Section 2 of RFC 5741. Info about the current status of this document, any errata, and how to give feedback on it is at http://www.rfc-editor.org/info/rfc7857 ✨

the copyright stuff is a lot, but I'm keeping every bit of it 🙈

Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, since they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they are provided without warranty as described in the Simplified BSD License.

This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.

Table of Contents 📑

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Scope . . . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.2.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   4
   2.  TCP Session Tracking  . . . . . . . . . . . . . . . . . . . .   4
     2.1.  TCP Transitory Connection Idle-Timeout  . . . . . . . . .   6
     2.2.  TCP RST . . . . . . . . . . . . . . . . . . . . . . . . .   6
   3.  Port Overlapping Behavior . . . . . . . . . . . . . . . . . .   6
   4.  Address Pooling Paired (APP)  . . . . . . . . . . . . . . . .   7
   5.  Endpoint-Independent Mapping (EIM) Protocol Independence  . .   8
   6.  Endpoint-Independent Filtering (EIF) Protocol Independence  .   8
   7.  Endpoint-Independent Filtering (EIF) Mapping Refresh  . . . .   8
     7.1.  Outbound Mapping Refresh and Error Packets  . . . . . . .   9
   8.  Port Parity . . . . . . . . . . . . . . . . . . . . . . . . .   9
   9.  Port Randomization  . . . . . . . . . . . . . . . . . . . . .   9
   10. IP Identification (IP ID) . . . . . . . . . . . . . . . . . .  10
   11. ICMP Query Mappings Timeout . . . . . . . . . . . . . . . . .  10
   12. Hairpinning Support for ICMP Packets  . . . . . . . . . . . .  10
   13. Security Considerations . . . . . . . . . . . . . . . . . . .  11
   14. References  . . . . . . . . . . . . . . . . . . . . . . . . .  12
     14.1.  Normative References . . . . . . . . . . . . . . . . . .  12
     14.2.  Informative References . . . . . . . . . . . . . . . . .  12
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  13
   Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . .  14
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  14

1. Introduction ✨

okay so [RFC4787], [RFC5382], and [RFC5508] all helped make Network Address Translation (NAT) work together better and follow the rules 🫶 But once NATs got deployed everywhere and kept evolving, people noticed some parts of those docs needed more clarity or updates. This document is where those clarifications and updates live 💖

1.1. Scope

the goal here is to clarify and update the requirements listed in [RFC4787], [RFC5382], and [RFC5508] 🎀 This doc focuses only on NAT44.

The scope of this document has been set so that it does not create new requirements beyond those specified in the documents cited above.

Requirements related to Carrier-Grade NAT (CGN) are defined in [RFC6888]. 🌸

1.2. 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]. 🦋

The reader is assumed to be familiar with the terminology defined in [RFC2663], [RFC4787], [RFC5382], and [RFC5508]. 📚

In this document, the term "NAT" covers both "Basic NAT" and "Network Address/Port Translator (NAPT)" (see Section 3 of [RFC4787]). quick reminder: Basic NAT and NAPT are two flavors of traditional NAT. Basic NAT only translates IP addresses, while NAPT goes further and translates transport identifiers too (like a TCP/UDP port or an ICMP query ID). Check Section 2 of [RFC3022] if you want the full picture 🧚

2. TCP Session Tracking 💜

so [RFC5382] sets TCP timers for different connection states, but it doesn't spell out the TCP state machine a NAT44 is supposed to use as the basis for applying those timers. That's where this section comes in 🙈

Update: The TCP state machine depicted in Figure 1, adapted from [RFC6146], SHOULD be implemented by a NAT for TCP session tracking purposes.

                    +----------------------------+
                    |                            |
                    V                            |
                 +------+   Client               |
                 |CLOSED|-----SYN------+         |
                 +------+              |         |
                     ^                 |         |
                     |TCP_TRANS T.O.   |         |
                     |                 V         |
                 +-------+          +-------+    |
                 | TRANS |          |  INIT |    |
                 +-------+          +-------+    |
                   |    ^               |        |
             data pkt   |               |        |
                   | Server/Client RST  |        |
                   |  TCP_EST T.O.      |        |
                   V    |           Server SYN   |
              +--------------+          |        |
              | ESTABLISHED  |<---------+        |
              +--------------+                   |
               |           |                     |
         Client FIN    Server FIN                |
               |           |                     |
               V           V                     |
        +---------+   +----------+               |
        |  C FIN  |   |  S FIN   |               |
        |   RCV   |   |    RCV   |               |
        +---------+   +----------+               |
            |             |                      |
        Server FIN      Client FIN            TCP_TRANS
            |             |                    T.O.
            V             V                      |
        +----------------------+                 |
        |   C FIN + S FIN RCV  |-----------------+
        +----------------------+

           Figure 1: Simplified Version of the TCP State Machine

here's the legend for the diagram, so you can read it like a pro 🔥

  • Messages sent or received from the server are prefixed with "Server".
  • Messages sent or received from the client are prefixed with "Client".
  • "C" means "Client-side".
  • "S" means "Server-side".
  • TCP_EST T.O. refers to the established connection idle-timeout as defined in [RFC5382].
  • TCP_TRANS T.O. refers to the transitory connection idle-timeout as defined in [RFC5382].

2.1. TCP Transitory Connection Idle-Timeout ⏳

the transitory connection idle-timeout is the minimum time a TCP connection in the partially open or closing phases has to sit idle before the NAT can consider the session a candidate for removal (REQ-5 of [RFC5382]). The tea is that [RFC5382] doesn't clearly say whether these two timeouts can be configured separately 👀

Clarification: This document clarifies that a NAT SHOULD provide different configurable parameters for configuring the open and closing idle timeouts.

Some deployments think a partially open timeout of 4 minutes is excessive from a security standpoint 😤 To accommodate them, a NAT MAY allow the configured timeout to be less than 4 minutes. That said, a minimum default transitory connection idle-timeout of 4 minutes is RECOMMENDED. 💅

2.2. TCP RST 🚫

[RFC5382] leaves the handling of TCP RST packets unspecified, so this is the gap being filled 🫶

Update: This document adopts a default behavior similar to the one in [RFC6146]. Concretely, when the NAT receives a TCP RST matching an existing mapping, it MUST translate the packet according to the NAT mapping entry. Also, the NAT SHOULD wait for 4 minutes before deleting the session and removing any state associated with it, if no packets are received during that 4-minute timeout. ⏰

Notes:

  • Admittedly, the NAT has to verify whether received TCP RST packets belong to a connection. This verification check is required to avoid off-path attacks. 🛡️
  • If the NAT immediately removes the NAT mapping upon receipt of a TCP RST message, stale connections may be maintained by endpoints if the first RST message is lost between the NAT and the recipient. 🥺

3. Port Overlapping Behavior 🎀

okay so REQ-1 from [RFC4787] and REQ-1 from [RFC5382] already define a port overlapping behavior 💅 The external IP address and port can be reused for connections from the same internal source IP address and port, no matter where they're going. This is called Endpoint-Independent Mapping (EIM) ✨

Update: this doc clarifies that the overlapping can go further, to connections from different internal source IP addresses and ports, as long as their destinations are different 🦋

The following mechanism MAY be implemented by a NAT:

If destination addresses and ports are different for outgoing connections started by local clients, a NAT MAY assign the same external port as the source ports for the connections. The port overlapping mechanism manages mappings between external packets and internal packets by looking at and storing their 5-tuple (protocol, source address, source port, destination address, and destination port).

This lets a single NAT external port be used by multiple transport sessions at once 🌸 which is super helpful when a network has a limited number of IP addresses (think a deployment with a high address space multiplicative factor, see Appendix B of [RFC6269]). iconic resource management 👑

4. Address Pooling Paired (APP) 💖

REQ-2 from [RFC4787] recommended the "IP address pooling" behavior of "Paired" (APP), but what happens when an external IPv4 address runs out of ports was left undefined 🙈

Clarification: this doc clarifies that if APP is enabled, new sessions from a host that already has a mapping tied to an external IP that ran out of ports SHOULD be dropped. A configuration parameter MAY be provided to let a NAT start using ports from another external IP address when the one that anchored the APP mapping ran out of ports. Tweaking this parameter is a trade-off between service continuity and strict APP enforcement ⚖️ This behavior is sometimes called "soft-APP" 🧚

As a reminder, for the particular case of a CGN, the recommendation is that an implementation must use the same external IP address mapping for all sessions associated with the same internal IP address, whether they're TCP, UDP, ICMP, something else, or a mix of protocols [RFC6888] 🫶

Update: this behavior SHOULD apply also for TCP 💜

5. Endpoint-Independent Mapping (EIM) Protocol Independence 🌈

REQ-1 from [RFC4787] and REQ-1 from [RFC5382] don't say whether EIM is protocol dependent or protocol independent 😭 For example, if an outbound TCP SYN creates a mapping, it's left undefined whether outbound UDP packets can reuse that mapping. Messy!

Update: EIM mappings SHOULD be protocol dependent. A configuration parameter MAY be provided to let protocols that multiplex TCP and UDP over the same source IP address and port number use a single mapping. The default value of this configuration parameter MUST be protocol-dependent EIM 🔥

This update matches the stateful Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers (NAT64) [RFC6146], which clearly specifies three binding information bases (TCP, UDP, and ICMP) 🎀

6. Endpoint-Independent Filtering (EIF) Protocol Independence 🦋

REQ-8 from [RFC4787] and REQ-3 from [RFC5382] don't specify whether mappings with Endpoint-Independent Filtering (EIF) are protocol independent or protocol dependent 🙃 For example, if an outbound TCP SYN creates a mapping, it's left undefined whether inbound UDP packets matching that mapping should be accepted or rejected.

Update: EIF filtering SHOULD be protocol dependent. A configuration parameter MAY be provided to make it protocol independent. The default value of this configuration parameter MUST be protocol-dependent EIF ✨

This behavior lines up with the update in Section 5 💅

Applications that can be carried over a variety of transport protocols and/or that support transport fallback schemes won't run into connectivity failures if the NAT is configured with protocol-independent EIM and protocol-independent EIF. no cap, that's a whole vibe 🌸

7. Endpoint-Independent Filtering (EIF) Mapping Refresh 💀

The NAT mapping Refresh direction may have a "NAT Inbound refresh behavior" of "True" according to REQ-6 from [RFC4787], but [RFC4787] doesn't clarify how that applies to EIF mappings. The question is whether inbound packets that match an EIF mapping but don't create a new session because of a security policy should refresh the mapping timer 🤔

Clarification: this doc clarifies that even when a NAT has an inbound refresh behavior set to "TRUE", such packets SHOULD NOT refresh the mapping. Otherwise, a simple attack of one packet every two minutes could keep the mapping alive indefinitely 🚨

Update: this behavior SHOULD apply also for TCP 🫶

7.1. Outbound Mapping Refresh and Error Packets 🍓

Update: for NAT outbound refresh behavior, ICMP Errors or TCP RST outbound packets sent in response to inbound packets SHOULD NOT refresh the mapping. Other packets that indicate the host isn't interested in receiving packets MAY be configurable to also not refresh state, such as a Session Traversal Utilities for NAT (STUN) error response [RFC5389] or IKE INVALID_SYNTAX [RFC7296] 🧠

8. Port Parity 👑

Update: a NAT MAY disable port parity preservation for all dynamic mappings. Nevertheless, A NAT SHOULD support means to explicitly request port parity preservation (e.g., [RFC7753]) 💅

Note: according to [RFC6887], dynamic mappings are called dynamic because they're created on demand, either implicitly or explicitly 🎀

  1. Implicit dynamic mappings are created as a side effect of traffic such as an outgoing TCP SYN or outgoing UDP packet. They usually have a finite lifetime, though that lifetime is generally not known to the client using them 👀
  2. Explicit dynamic mappings are created as a result of, for example, explicit Port Control Protocol (PCP) MAP and PEER requests. They have a finite lifetime, and that lifetime is communicated to the client 📣

9. Port Randomization 🌈

Update: a NAT SHOULD follow the recommendations in Section 4 of [RFC6056], especially these 🔐

A NAPT that does not implement port preservation [RFC4787] [RFC5382] SHOULD obfuscate selection of the ephemeral port of a packet when it is changed during translation of that packet.

A NAPT that does implement port preservation SHOULD obfuscate the ephemeral port of a packet only if the port must be changed as a result of the port already being in use for some other session.

A NAPT that performs parity preservation and that must change the ephemeral port during translation of a packet SHOULD obfuscate the ephemeral ports. The algorithms described in this document could be easily adapted such that the parity is preserved (i.e., force the lowest order bit of the resulting port number to 0 or 1 according to whether even or odd parity is desired).

10. IP Identification (IP ID) 🦋

Update: a NAT SHOULD handle the Identification field of translated IPv4 packets as specified in Section 5.3.1 of [RFC6864] ✨

11. ICMP Query Mappings Timeout ⏰

Section 3.1 of [RFC5508] specifies that ICMP Query mappings are to be maintained by a NAT. However, the spec doesn't discuss Query mapping timeout values. Section 3.2 of [RFC5508] only discusses ICMP Query session timeouts 🫠

Update: ICMP Query mappings MAY be deleted once the last session using the mapping is deleted 🧹

12. Hairpinning Support for ICMP Packets 🔁

REQ-7 from [RFC5508] specifies that a NAT enforcing Basic NAT must support traversal of hairpinned ICMP Query sessions 💖

Clarification: this implicitly means that address mappings from external address to internal address (similar to Endpoint-Independent Filters) must be maintained to allow inbound ICMP Query sessions. If an ICMP Query is received on an external address, a NAT can then translate it to an internal IP 🧚

REQ-7 from [RFC5508] specifies that all NATs must support the traversal of hairpinned ICMP Error messages 😤

Clarification: this behavior requires a NAT to maintain address mappings from external IP address to internal IP address, in addition to the ICMP Query mappings described in Section 3.1 of [RFC5508] 💜

13. Security Considerations 🚨

NAT behavioral considerations are discussed in [RFC4787], [RFC5382], and [RFC5508]. the security vibes here are SERIOUS, bestie 😭

Because some of the clarifications and updates (e.g., Section 2) are inspired by NAT64, the security considerations discussed in Section 5 of [RFC6146] also apply to this specification 🛡️

The update in Section 3 allows for optimized NAT resource usage. To avoid service disruption, the NAT must not invoke this functionality unless the packets are to be sent to distinct destination addresses. ⚠️

Some of the updates (e.g., Sections 7, 9, and 11) allow for increased security compared to [RFC4787], [RFC5382], and [RFC5508]. In particular:

  • the updates in Sections 7 and 11 prevent an illegitimate node from keeping mappings active in the NAT when those mappings should be cleared, and
  • port randomization (Section 9) complicates tracking hosts located behind a NAT.

Sections 4 and 12 propose updates that increase the serviceability of a host located behind a NAT. These updates don't introduce any additional security concerns compared to [RFC4787], [RFC5382], and [RFC5508] 🌸

The updates in Sections 5 and 6 allow for better NAT transparency from an application standpoint. Hosts that require a restricted filtering behavior should enable specific policies (e.g., Access Control List (ACL)) either locally or by soliciting a dedicated security device (e.g., firewall). How a host updates its filtering policies is out of scope of this document 🔒

The update in Section 8 induces security concerns that are specific to the protocol used to interact with the NAT. For example, if PCP is used to explicitly request parity preservation for a given mapping, the security considerations discussed in [RFC6887] should be taken into account 🧐

The update in Section 10 may have undesired effects on the performance of the NAT in environments where fragmentation is massively experienced. Such an issue may be used as an attack vector against NATs. 💀

14. References 📚

14.1. Normative References

okay so these are the must-reads, bestie 📚✨ if you're implementing this, you need every single one of these, no skipping 💅

14.2. Informative References

these ones are the extra reading, the "ooh tell me more" section 🤓🫶 not strictly required, but so good for context

Acknowledgements ✨

big thank-you bundle time 🫶 Thanks to Dan Wing, Suresh Kumar, Mayuresh Bakshi, Rajesh Mohan, Lars Eggert, Gorry Fairhurst, Brandon Williams, and David Black for their review and discussion. 💖

Many thanks to Ben Laurie for the SecDir review and Dan Romascanu for the Gen-ART review. 🙈

Dan Wing proposed some text for the configurable errors in Section 7.1. the MVP of error handling, honestly 👑

Contributors

The following individual contributed text to the document: 🌸

   Sarat Kamiset
   Insieme Networks
   United States

Authors' Addresses

the people behind it all, the squad that made this happen 🧚💜

   Reinaldo Penno
   Cisco Systems, Inc.
   170 West Tasman Drive
   San Jose, California  95134
   United States

   Email: repenno@cisco.com


   Simon Perreault
   Jive Communications
   Canada

   Email: sperreault@jive.com


   Mohamed Boucadair (editor)
   Orange
   Rennes  35000
   France

   Email: mohamed.boucadair@orange.com


   Senthil Sivakumar
   Cisco Systems, Inc.
   United States

   Email: ssenthil@cisco.com


   Kengo Naito
   NTT
   Tokyo
   Japan

   Email: k.naito@nttv6.jp
📦 where this page comes from