Network
Address Translation (NAT) Behavioral Requirements UpdatesCisco Systems, Inc.170 West Tasman DriveSan JoseCalifornia95134USArepenno@cisco.comJive CommunicationsCanadasperreault@jive.comFrance TelecomRennes35000Francemohamed.boucadair@orange.comCisco Systems, Inc.United Statesssenthil@cisco.comNTTTokyoJapank.naito@nttv6.jp
Transport Area
TSVWGaddress sharingIPv4 service continuityCarrier Grade NATCGNLSNNAT traversalThis document clarifies and updates several requirements of RFC4787,
RFC5382 and RFC5508 based on operational and development experience. The
focus of this document is NAT44., and
greatly advanced NAT interoperability and
conformance. But with widespread deployment and evolution of Network
Address Translation (NAT) more development and operational experience
was acquired some areas of the original documents need further
clarification or updates. This document provides such clarifications and
updates.The goal of this document is to clarify and update the set of
requirements listed in , and . The
document focuses exclusively 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.
Carrier-Grade NAT (CGN) related requirements are defined in .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 .The reader is assumed to be familiar withe terminology defined in:
,,, and .In this document, the term "NAT" refers to both "Basic NAT" and
"Network Address/Port Translator (NAPT)" (see Section 3 of ). As a reminder, Basic NAT and NAPT are two
variations of traditional NAT, in that translation in Basic NAT is
limited to IP addresses alone, whereas translation in NAPT is extended
to include IP address and Transport identifier (such as TCP/UDP port
or ICMP query ID) (refer to Section 2 of ). specifies TCP timers associated with
various connection states but does not specify the TCP state machine a
NAT44 should follow as a basis to apply such timers. The TCP state machine depicted in , adapted from ,
SHOULD be implemented by a NAT for TCP session tracking
purposes.The transitory connection idle-timeout 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 (REQ-5 of ). But
does not clearly state whether these
can be configured separately.This document clarifies that a NAT
SHOULD provide different configurable parameters for configuring
the open and closing idle timeouts.To
accommodate deployments that consider a partially open timeout of
4 minutes as being excessive from a security standpoint, a NAT MAY
allow to configure the timeout to be less than 4 minutes. Still,
this specification recommends the default "transitory connection
idle-timeout" minimum value to be set to 4 minutes. leaves the handling of TCP RST
packets unspecified.This document adopts a similar default
behavior as in . Concretely, when
the NAT receives a TCP RST matching an existing mapping, it MUST
translate the packet according the NAT mapping entry. Moreover,
the NAT SHOULD wait for 4 minutes before deleting the session and
removing any state associate with it if no packets are received
during that 4 minutes timeout. Admittedly, the NAT has to verify whether
received TCP RST packets belong to a connection. These
verification checks are required to avoid off-path attacks.If the NAT removes immediately 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.REQ-1 from and REQ-1 from specify a specific port overlapping behavior;
that is the external IP address and port can be reused for connections
originating from the same internal source IP address and port
irrespective of the destination. This is known as endpoint-independent
mapping (EIM). This document clarifies that this port
overlapping behavior may be extended to connections originating 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,
destination port).This enables concurrent use of a
single NAT external port for multiple transport sessions, which
allows a NAT to successfully process packets in an IP address
resource limited network (e.g., deployment with high address space
multiplicative factor (refer to Appendix B.
of )).The Address Pooling Paired (APP) behavior for a NAT was recommended
in REQ-2 from , but the behavior when a
public IPv4 runs out of ports was left undefined.This document clarifies that if APP is
enabled, new sessions from a host that already has a mapping
associated with an external IP that ran out of ports SHOULD be
dropped. The administrator MAY provide a
configurable parameter that allows a NAT to starting using ports
from another external IP address when the one that anchored the APP
mapping ran out of ports. This is a trade-off between service
continuity and APP strict enforcement. (Note, this behavior is
sometimes referred as 'soft-APP'.)This behavior SHOULD apply also for TCP.REQ-8 from and REQ-3 from do not specify whether EIF mappings are
protocol-independent. In other words, if an outbound TCP SYN creates a
mapping, it is left undefined whether inbound UDP packets destined to
that mapping should be forwarded.This document specifies that EIF mappings
SHOULD be protocol-independent in order allow inbound packets for
protocols that multiplex TCP and UDP over the same IP address and
port through the NAT and also maintain compatibility with stateful
NAT64 . The administrator MAY provide a configuration parameter to
make it protocol-dependent. The default value of this configuration
parameter is to allow for protocol-independent EIF.Applications that can be transported over a variety
of transport protocols and/or support transport fall back schemes
won't experience connectivity failures as a function of the
underlying transport protocol or the filtering mode enabled at the
NAT.The NAT mapping Refresh direction may have a "NAT Inbound refresh
behavior" of "True" according to REQ-6 from , but does not
clarify how this behavior applies to EIF mappings. The issue in question
is whether inbound packets that match an EIF mapping but do not create a
new session due to a security policy should refresh the mapping
timer.This document 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 a
packet every 2 minutes can keep the mapping indefinitely.This behavior SHOULD apply also for TCP.In the case of NAT outbound refresh behavior
there are certain types of packets that should not refresh the
mapping even if their direction is outbound. For example, if the
mapping is kept alive by ICMP Errors or TCP RST outbound packets
sent as response to inbound packets, these SHOULD NOT refresh the
mapping.REQ-1 from and REQ-1 from do not specify whether EIM are
protocol-independent. In other words, if a outbound TCP SYN creates a
mapping it is left undefined whether outbound UDP can reuse such mapping
and create session. On the other hand, stateful NAT64 clearly specifies three binding information
bases (TCP, UDP, ICMP).EIM mappings SHOULD be protocol-dependent. A
configuration parameter MAY be provided in order allow protocols
that multiplex TCP and UDP over the same source IP address and port
number to use a single mapping.A NAT MAY disable port parity preservation for
all dynamic mappings. Nevertheless, A NAT SHOULD support means to
explicitly request to preserve port parity (e.g., ).Note: According to , dynamic
mappings are said to be dynamic in the sense that they are created
on demand, either implicitly or explicitly:Implicit dynamic mappings refer to mappings that are created
as a side effect of traffic such as an outgoing TCP SYN or
outgoing UDP packet. Implicit dynamic mappings usually have a
finite lifetime, though this lifetime is generally not known to
the client using them.Explicit dynamic mappings refer to mappings that are created
as a result, for example, of explicit PCP MAP and PEER requests.
Explicit dynamic mappings have a finite lifetime, and this
lifetime is communicated to the client.A NAT SHOULD follow the recommendations
specified in Section 4 of ,
especially: "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 being already 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)."A NAT SHOULD handle the Identification field
of translated IPv4 packets as specified in Section 5.3.1 of .Section 3.1 of precises that ICMP
Query Mappings are to be maintained by a NAT. However, the specification
doesn't discuss Query Mapping timeout values. Section 3.2 of only discusses ICMP Query Session Timeouts.ICMP Query Mappings MAY be deleted once the
last the session using the mapping is deleted.REQ-7 from specifies that a NAT
enforcing 'Basic NAT' must support traversal of hairpinned ICMP Query
sessions.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 to an internal IP.REQ-7 from specifies that all
NATs must support the traversal of hairpinned ICMP Error messages.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 .This document does not require any IANA action.NAT behavioral considerations are discussed in , , and .Because some of the clarifications and updates (e.g., ) are inspired from NAT64, the security
considerations discussed in Section 5 of
apply also for this specification.The update in allows for an
optimized NAT resource usage. In order to avoid service disruption, the
NAT MUST invoke this functionality only if packets are to be sen to
distinct destination addresses. Some of the updates (e.g., , , and ) allow
for an increased security compared to ,
, and .
Particularly:The updates in and prevent an illegitimate node to maintain
mappings activated in the NAT while these mappings should be
cleared.Port randomization ()
complicates tracking hosts located behind a NAT. and
propose updates that increase the serviceability of a host located
behind a NAT. These updates do not introduce any additional security
concerns to , , and .The updates in and allow for a better NAT transparency from an
application standpoint. Hosts which require a restricted filtering
behavior should enable security-dedicated features (e.g., ACL) either
locally or by soliciting a dedicated security device (e.g., firewall).
The update in 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 should be taken into account.The update in may have undesired effects on
the performance of the NAT in environments in which fragmentation is
massively experienced. Such issue may be used as an attack vector
against NATs.Thanks to Dan Wing, Suresh Kumar, Mayuresh Bakshi, Rajesh Mohan, Lars
Eggert, and Gorry Fairhurst for their review and discussion.The following individual contributed text to the document: Sarat Kamiset, Insieme Networks, United States