Negotiation of NAT-Traversal in the IKE
Extracted elements (28)
Cookies (CKY-I and CKY-R) are included in the NAT-D hash computation to make precomputation attacks against the IP address and port values impossible. Without cookies, an attacker could precompute hashes for all possible IP/port combinations.
IKE traffic is moved off port 500 to port 4500 as soon as NAT is detected to avoid IPsec-aware NAT special-casing. Some NATs refuse to change IKE source port 500 or use IKE cookies to demultiplex instead of source port, both of which break generic NAT transparency; moving ports immediately minimizes the exposure window.
The final decision to use NAT-Traversal encapsulation is deferred to Quick Mode (not Phase 1) because Phase 1 only detects NAT presence; Quick Mode allows per-SA negotiation of whether UDP encapsulation is actually needed and which mode (tunnel vs. transport) to use.
In combination with RFC 3948 (UDP Encapsulation of IPsec Packets), RFC 3947 represents an 'unconditionally compliant' solution to the requirements defined by RFC 3715 (IPsec-NAT Compatibility Requirements). Implementations must also support RFC 3948's non-ESP marker for demultiplexing IKE and ESP traffic on port 4500.
For INITIAL-CONTACT notifications from a host behind NAT, the source IP and port MUST NOT be used to determine which IKE/IPsec SAs to remove, because NAT can change them. Instead, the ID payload from the other end SHOULD be used to identify SAs to remove.
If a NAT is present between hosts, UDP-Encapsulation SHOULD be used; if no NAT is present, UDP-Encapsulation SHOULD NOT be used to avoid wasting bandwidth. The initiator SHOULD NOT propose both normal tunnel/transport and UDP-Encapsulated modes simultaneously.
If NAT-Traversal support is enabled, the port field in the ID payload in Main Mode and Aggressive Mode MUST be set to 0.
If the sender does not know its own IP address (e.g., multiple interfaces), it MAY include multiple local hashes as separate NAT-D payloads. NAT is detected if and only if none of those hashes match the remote's payload.
In Main Mode, if NAT is detected, the initiator MUST change both UDP source and destination ports to 4500 when sending the ID payload. All subsequent packets to the peer (including informational notifications) MUST be sent on port 4500, and IKE data MUST be prepended with the non-ESP marker from RFC 3948.
In transport mode, both ends MUST send both original Initiator and Responder NAT-OA addresses to the other end. For tunnel mode, both ends SHOULD NOT send original addresses. The initiator MUST send NAT-OA payloads if it proposes any UDP-Encapsulated-Transport mode; the responder MUST send them only if it selects UDP-Encapsulated-Transport mode.
Recipients MUST be able to process IKE packets whose source port is different from 500, because a NAT may change the UDP source port. When rekeying or sending notifications, the original responder MUST use the same IP and port numbers used when the IKE SA was last used.
The Vendor ID payload for NAT-Traversal support MUST be sent in the first two messages of Phase 1 if supported, and MUST be received by both sides for the NAT-Traversal probe to continue. The payload content is the MD5 hash of the string 'RFC 3947' (hex: 4a131c81070358455c5728f20e95452f).
To recover from expired NAT mappings, hosts NOT behind NAT SHOULD use the last valid UDP-encapsulated IKE or IPsec packet to determine current IP and port addresses. Hosts behind dynamic NAT MUST NOT do this, as it opens a DoS attack vector since the non-NAT peer's address does not change.
When the responder successfully processes the port-changed packet, it MUST update local state so all subsequent packets to the peer use the new port (and possibly new IP address). Any implementation supporting NAT traversal MUST support negotiations that begin on port 4500.
Sending the original source address in Quick Mode NAT-OA payloads reveals the internal IP address behind the NAT to the authenticated remote peer. This disclosure is only required in transport mode, and the peer has already been authenticated at that point.
NAT detection uses NAT-D (NAT Discovery) payloads, each containing a hash computed as HASH(CKY-I | CKY-R | IP | Port) using the negotiated hash algorithm. The first NAT-D payload contains the remote end's address/port; remaining payloads contain possible local addresses/ports. NAT is detected when hashes do not match.
NAT-OA (NAT Original Address) payloads carry the original pre-NAT IP addresses of both initiator and responder, sent in Quick Mode to enable incremental TCP/IP checksum updates after NAT transformation. The initiator NAT-OA is sent first, the responder NAT-OA second.
Two new ISAKMP encapsulation modes are defined for Quick Mode NAT-T negotiation: UDP-Encapsulated-Tunnel (value 3) and UDP-Encapsulated-Transport (value 4). The final decision to use NAT-Traversal is made in Quick Mode via the SA payload.
Port 4500 (TCP and UDP) is registered as 'ipsec-nat-t' for IPsec NAT-Traversal use, renaming the previously registered entry for this port.
Two new encapsulation mode values are added to the ISAKMP Identifiers Encapsulation Mode registry: UDP-Encapsulated-Tunnel (value 3) and UDP-Encapsulated-Transport (value 4).
Two new IKE Next Payload Type values are registered: NAT-D (value 20) for the NAT Discovery Payload, and NAT-OA (value 21) for the NAT Original Address Payload.
Because the internal IPv4 address space is only 32 bits and often sparse, an attacker can enumerate internal addresses behind NAT by brute-forcing all 2^32 possible IP addresses to find a matching NAT-D hash. With an educated guess of the private address range, the search space reduces to approximately 2^24 + 2*(2^16).
NAT-D and Vendor ID payloads are not authenticated in Main Mode or Aggressive Mode, allowing an attacker to remove, add, or modify them. Removal or addition can cause DoS; modification of NAT-D payloads can force both ends to use UDP-Encapsulated modes unnecessarily, wasting bandwidth.
Pre-shared key authentication in Main Mode behind NAT requires group-shared keys for all hosts behind the NAT box. This is a critical risk: any group member can impersonate any other member (e.g., a user impersonating a VPN gateway to perform MitM). Use of group-shared keys is NOT RECOMMENDED.
Updating IKE SA/ESP UDP encapsulation addresses/ports on each valid authenticated packet can be exploited by an on-path attacker who reorders or replays packets with modified source/destination addresses, causing the non-NAT peer to send traffic to the wrong host or port. Implementations SHOULD AUDIT each mapping change.
In Main Mode, when NAT is detected, the initiator transitions from UDP port 500 to port 4500 when sending the ID payload. The state change sets both source and destination UDP ports to 4500 for all subsequent packets, including informational notifications, and prepends the non-ESP marker.
The NAT-D payload has a standard ISAKMP generic header (Next Payload, RESERVED, Payload Length) followed by the variable-length HASH of the IP address and port. The IP field is 4 octets for IPv4 or 16 octets for IPv6; port is 2 octets in network byte order. Payload type is 20.
The NAT-OA payload has a standard ISAKMP header, then an ID Type byte (RESERVED byte, RESERVED 2 bytes), followed by the IPv4 address (4 octets) or IPv6 address (16 octets). Only ID_IPV4_ADDR and ID_IPV6_ADDR types are allowed. Payload type is 21.