UDP Encapsulation of IPsec ESP Packets
Extracted elements (24)
IPsec AH was excluded from the scope of this specification because AH's protection of outer IP addresses is inherently incompatible with NAT, which rewrites those addresses.
The same UDP port numbers (4500) are shared for both IKE and UDP-encapsulated ESP traffic to improve scaling (one NAT mapping), simplify configuration (one firewall port), and ease implementation, rather than using separate ports for each protocol.
This protocol assumes IKE (IKEv1 or IKEv2) is used to negotiate IPsec SAs; manual keying is not supported for UDP-encapsulated ESP.
While the encapsulation is written in terms of IPv4 outer and inner headers, there is no technical reason why IPv6 cannot be used as either the outer or inner header.
A peer MAY send a NAT-keepalive packet if one or more phase I or phase II SAs exist between the peers, or if such an SA has existed within the last N minutes (default N=5, locally configurable).
A peer SHOULD send a NAT-keepalive packet if NAT traversal is detected (per RFC 3947) and no other packet to the peer has been sent in M seconds, where M defaults to 20 seconds and is locally configurable.
An IKE implementation supporting this protocol MUST NOT use the ESP SPI field zero for ESP packets, ensuring IKE packets and ESP packets can be distinguished from each other.
For transport mode decapsulation, one of three checksum correction procedures MUST be applied: incrementally recompute the TCP/UDP checksum using NAT-OA addresses from IKE, fully recompute the checksum, or zero the UDP checksum (with TCP checksum bypass allowed only if the packet is integrity-protected).
For tunnel mode decapsulation, depending on local policy, one of three actions MUST be taken: validate the inner source IP against policy, verify it matches an assigned address for the peer, or perform NAT to make the packet suitable for the local network.
In the UDP-encapsulated ESP header format, the IPv4 UDP Checksum SHOULD be transmitted as a zero value, but receivers MUST NOT depend on the UDP checksum being a zero value.
L2TP/IPsec clients MUST support transport and tunnel modes as defined in RFC 3193. IPsec tunnel mode clients MUST support tunnel mode.
Reception of NAT-keepalive packets MUST NOT be used to detect whether a connection is live; their sole purpose is to maintain NAT mapping state.
The NAT-keepalive sender MUST use a one-octet-long payload with the value 0xFF; the receiver SHOULD ignore a received NAT-keepalive packet.
Tunnel mode TCP checksums MUST be verified even when the implementation uses the checksum-bypass option; the bypass is only permitted for transport mode on integrity-protected packets.
Transport mode ESP decapsulation removes the UDP header, updates IP header fields (Total Length, Protocol, Header Checksum), applies ordinary ESP decapsulation, and then applies the transport mode decapsulation NAT procedure.
Transport mode ESP encapsulation inserts a UDP header between the original IP header and the ESP header. After encapsulation the IP header fields Total Length, Protocol, and Header Checksum are updated to reflect the new packet structure.
Tunnel mode ESP decapsulation removes the UDP header, updates outer IP header fields, applies ordinary ESP decapsulation, and then applies the tunnel mode decapsulation NAT procedure.
Tunnel mode ESP encapsulation inserts a UDP header between the new outer IP header and the ESP header, then updates Total Length, Protocol, and Header Checksum in the outer IP header.
In transport mode, if traffic descriptors for two clients behind the same NAT overlap, simple filter lookups may be insufficient to select the correct SA for outbound traffic. Implementations MUST handle this situation by disallowing conflicting connections or by other means.
In tunnel mode, two clients behind different NATs with the same inner IP address can cause a security gateway (SGW) to become confused about which SA to use for return traffic. Implementors MUST devise ways to prevent this, with the RECOMMENDED approach being to assign locally unique IP addresses (e.g., via DHCP over IPsec) or use NAT at the SGW.
It is impossible to guarantee security for some clients behind a NAT while allowing cleartext from different clients behind the same NAT, because the server sees all clients as the same IP. The scenario of mixing secured and cleartext policies for the same traffic descriptor MUST NOT be allowed on servers requiring security guarantees; it MAY be used for best-effort security only.
IKE packets on port 4500 are prefixed with a Non-ESP Marker: 4 zero-valued bytes that align with the SPI field of an ESP packet, allowing receivers to distinguish IKE from ESP traffic on the same port.
NAT-Keepalive packets consist of a standard UDP header followed by exactly one octet with value 0xFF. The Source and Destination Ports MUST match those used for UDP-ESP encapsulation.
The UDP-Encapsulated ESP packet format places a standard UDP header (Source Port, Destination Port, Length, Checksum — each 16 bits) immediately before the ESP header. The Source and Destination Ports MUST match those used by IKE traffic; the ESP SPI MUST NOT be zero.