Multiple UDP Source Ports for ESP in UDP Encapsulation

In high-speed IPsec deployments, endpoints exchange traffic at multi-gigabit rates and must distribute cryptographic processing across multiple CPU cores. ESP in UDP encapsulation is widely deployed in cloud environments and across NAT gateways. However, when ESP is encapsulated in UDP using port 4500 for both source and destination, all traffic between a given pair of peers shares a single 4-tuple (src-IP, dst-IP, src-port=4500, dst-port=4500). This eliminates the 4-tuple diversity required for effective NIC receive-side scaling (RSS) and ECMP path selection. This document specifies a mechanism whereby IKEv2 peers establish multiple Child Security Associations (SAs), each bound to a distinct UDP source port, using the per-resource Child SA mechanism of . Each per-resource Child SA is created via a CREATE_CHILD_SA exchange sent from a new ephemeral UDP source port. The resulting UDP flows, with varying source ports, enable NIC hardware and network infrastructure to distribute IPsec traffic across RSS queues and ECMP paths. A Fallback SA on the standard port pair (4500 to 4500) is always maintained per . This mechanism is defined for ESP in UDP encapsulation ; its applicability to EESP is discussed in . Varying the UDP source port without IKEv2 coordination is insufficient. Without a negotiated binding between a UDP source port and a specific Child SA, the responder cannot distinguish an intentional port change from a NAT remapping event, which would trigger IKE SA roaming procedures per Section 2.23. NAT keepalives ( Section 6) must be maintained per active port pair; without IKEv2 signaling, the IKEd has no record of which port pairs exist. NIC and kernel queue-steering rules require both peers to agree on the port-to-resource binding; without negotiation, consistent steering configuration across peers is not achievable. This document specifies the IKEv2 exchanges and behavioral rules that establish deterministic port-to-SA bindings, providing the coordination that unilateral port variation cannot.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

This document uses the following terms from IKEv2 : Child SA, CREATE_CHILD_SA exchange, IKE_AUTH exchange, INFORMATIONAL exchange. This document uses the following terms from : UDP-encapsulated ESP, Non-ESP Marker. This document uses the following terms defined in : per-resource Child SA, Resource, SA_RESOURCE_INFO, TS_MAX_QUEUE.

Fallback SA: The standard UDP-encapsulated ESP Child SA using UDP source port 4500 and destination port 4500, established during IKE_AUTH. It remains active for the lifetime of the IKE SA.
Per-Resource Child SA: A Child SA established via CREATE_CHILD_SA from an Ephemeral Source Port, bound to that port for data-plane entropy and traffic-steering purposes. In this document, the resource is a CPU core or NIC receive queue.
Ephemeral Source Port: A UDP source port selected by the IKEd for a per-resource Child SA, distinct from port 4500 and from the source ports of all other active per-resource Child SAs.
IKEd: The IKEv2 implementation on a host responsible for IKE SA and Child SA lifecycle management.
TBD1: The IKEv2 Notify Message Status Type defined in this document that signals support for the UDP Ephemeral Source Port mechanism. A peer including TBD1 in IKE_AUTH implicitly signals support for the per-resource Child SA mechanism of . See .

ESP in UDP encapsulation deploys ESP packets in UDP with source port 4500 and destination port 4500. Because all IPsec traffic between two peers shares this single 4-tuple, no port entropy is present in the outer UDP header. Modern NIC hardware uses the outer UDP 4-tuple for RSS queue assignment. Without source port entropy, all IPsec traffic between two peers is directed to a single NIC RSS queue and processed by a single CPU core, creating a throughput bottleneck even when multiple cores are available. Native ESP carries the SPI at a fixed header offset and can serve as an ntuple steering key for per-resource flow distribution. EESP can carry explicit resource identifiers. However, support for ESP SPI and EESP resource identifier filtering in current network devices is limited. UDP source and destination port ntuple filtering scales well and is broadly supported across current NIC drivers and network equipment, making ESP in UDP encapsulation the practical foundation for per-resource flow steering. Multi-path networks using ECMP similarly rely on flow 5-tuple entropy to spread traffic across links. A single UDP flow between two peers concentrates all traffic on one ECMP path, underutilizing available bandwidth. The IPv6 flow label addresses load distribution for tunnel traffic in IPv6 environments. It does not apply to ESP-in-UDP deployments, which are used specifically where NAT traversal is required. NAT devices do not preserve the IPv6 flow label, and many such deployments remain on IPv4. Varying the UDP source port per CPU or per NIC queue resolves both problems. Each per-resource Child SA has a distinct UDP source port, providing the entropy needed for RSS and ECMP distribution without modifying the inner ESP payload or changing traffic selectors. Each per-resource Child SA also maintains an independent ESP sequence number counter and replay window, eliminating cross-CPU synchronization of cryptographic state.

Two IKEv2 peers first establish a standard IKE SA and a Fallback SA using UDP-encapsulated ESP on port 4500. Both peers signal support for this mechanism by including TBD1 (see ) in the IKE_AUTH exchange. When per-resource Child SAs are desired, the initiator sends a CREATE_CHILD_SA exchange from a new ephemeral UDP source port, including SA_RESOURCE_INFO per . The responder treats the resulting Child SA as a per-resource Child SA bound to that port tuple. The responder MUST send the CREATE_CHILD_SA response back to the same source port and IP address from which the request was received, using its own port 4500 as the source. All other IKE communication continues on the main port pair (4500 to 4500). The initiator MAY request additional per-resource Child SAs via further CREATE_CHILD_SA exchanges. If the responder is unwilling to create more per-resource Child SAs for the Traffic Selector pair, it returns TS_MAX_QUEUE per . The Fallback SA remains active throughout. The initiator MUST NOT send CREATE_CHILD_SA from an Ephemeral Source Port unless both peers have exchanged TBD1 in the IKE_AUTH exchange. Without this exchange, a CREATE_CHILD_SA from a non-4500 source port would be misinterpreted by the responder as a NAT mapping change per Section 2.23, updating the IKE SA peer port and disrupting all subsequent IKE communication.

Section 2.1 requires that the UDP Source Port and Destination Port of ESP-in-UDP packets "MUST be the same as that used by IKE traffic." This document updates that requirement as follows. When two IKEv2 peers have enabled the mechanism defined in this document by exchanging TBD1 in the IKE_AUTH exchange, ESP-in-UDP packets belonging to a per-resource Child SA MAY use a UDP source port different from the source port used for IKE traffic. The UDP source port for such packets MUST be the Ephemeral Source Port bound to that per-resource Child SA as negotiated in . This relaxation applies only to per-resource Child SAs negotiated per this document. The Fallback SA and all other Child SAs MUST continue to use the same port as IKE traffic, as required by .

Section 2.23 requires that "The peer MUST also send all subsequent IKEv2 traffic on UDP port 4500." Section 2.11 already requires that a responder MUST accept IKEv2 requests regardless of the UDP source port and reply to the address and port from which the request was received. The responder-side behavior required by this document therefore needs no change to existing implementations. This document updates the initiator-side requirement of Section 2.23. When the mechanism defined in this document is in use, CREATE_CHILD_SA exchanges used to negotiate per-resource Child SAs MAY be sent from an Ephemeral Source Port other than 4500. The responder MUST reply to the same Ephemeral Source Port from its own port 4500. All other IKEv2 traffic, including INFORMATIONAL exchanges, the IKE SA, and all exchanges not related to per-resource Child SA negotiation, MUST continue to use port 4500 as required by .

The Fallback SA is the initial Child SA established during the IKE_AUTH exchange using UDP source port 4500 and destination port 4500, following and . It serves the role of the shared Child SA described in : a single SA usable by all resources while per-resource Child SAs are being negotiated or when no per-resource Child SA exists for a given resource. The Fallback SA MUST remain active for the lifetime of the IKE SA. It MUST NOT be deleted while per-resource Child SAs are active. IKE control messages, rekeying exchanges, and deletion messages for per-resource Child SAs MUST be sent using the Fallback SA's port pair (4500 to 4500).

Support for the UDP Ephemeral Source Port mechanism defined in this document is signaled by including the TBD1 notification in the IKE_AUTH exchange. Both peers MUST include TBD1 to enable the mechanism. If either peer omits TBD1 from IKE_AUTH, the initiator MUST NOT send CREATE_CHILD_SA from an Ephemeral Source Port; both peers MUST use the Fallback SA for all traffic. TBD1 has no notification data.

To create a per-resource Child SA, the initiator IKEd opens a new UDP socket bound to an Ephemeral Source Port and sends a CREATE_CHILD_SA exchange from that port to the responder's port 4500. The CREATE_CHILD_SA exchange MUST include an SA_RESOURCE_INFO notification per . The Ephemeral Source Port MUST be selected from the dynamic port range (49152-65535) per and MUST NOT be a well-known port (0-1023). The port MUST be distinct from port 4500 and from the source ports of all currently active per-resource Child SAs. The port SHOULD be selected randomly within the dynamic range per . Because the port value is exchanged in the IKE handshake and bound to an SA known to both peers, randomization does not provide confidentiality; it prevents predictable allocation patterns that expose implementation state. The IKEd MUST retain the socket binding to the Ephemeral Source Port for the lifetime of the SA, preventing the operating system from assigning that port to other applications. The initiator SHOULD create one per-resource Child SA per CPU core or NIC receive queue available for IPsec processing, up to the limit indicated by TS_MAX_QUEUE (). Creating additional per-resource Child SAs beyond available resources provides no benefit and increases IKE state on both peers.

Upon receiving a CREATE_CHILD_SA containing SA_RESOURCE_INFO from a new UDP source port, and having exchanged TBD1 in IKE_AUTH, the responder MUST:

Respond to the initiator's Ephemeral Source Port from its own port 4500.
Install the Child SA with the IP and port tuple (initiator-IP, responder-IP, Ephemeral-Source-Port,
1. as the UDP binding.
NOT update the IKE SA's IP address or port based on this message. Per-resource Child SA creation from a new source port MUST NOT be interpreted as IKE SA roaming or NAT mapping change.

The IKEd MUST open a socket bound to the Ephemeral Source Port only when initiating a CREATE_CHILD_SA exchange from that port. The socket MUST NOT be opened speculatively or in advance of the exchange. During the CREATE_CHILD_SA exchange, the IKEd MUST only accept IKEv2 messages received on the Ephemeral Source Port socket that carry the IKE SA cookies (initiator and responder SPIs) of the IKE SA under which the Child SA is being negotiated. Messages with unknown or mismatched IKE SA cookies MUST be silently discarded. This prevents an attacker from injecting IKEv2 messages via the ephemeral port. After the CREATE_CHILD_SA exchange completes, the IKEd MUST retain the socket binding to prevent the operating system from assigning the port to another application, but MUST NOT process further IKEv2 messages received on the ephemeral port. All subsequent IKE traffic for the Child SA uses the Fallback SA's port pair (4500 to 4500).

Completion of the CREATE_CHILD_SA exchange does not establish that the data path for a per-resource Child SA is viable. A NAT gateway may silently drop ESP traffic on the new port pair even when the IKE exchange succeeded. Forwarding traffic on an unconfirmed path will result in blackholing. The responder MUST install only the inbound SA upon completing the CREATE_CHILD_SA exchange. Installation of the outbound SA MUST be deferred until data-plane reachability is confirmed. Data-plane reachability is confirmed when the responder receives the first ESP packet on the new inbound SA. The SAD MAY enforce a soft limit of one incoming packet on the inbound SA; when this limit triggers, the kernel signals the IKEd (e.g., via an XFRM acquire event), which then installs the outbound SA. Alternatively, the initiator MAY send an encrypted ESP ping () immediately after the CREATE_CHILD_SA exchange completes, providing explicit confirmation of data-plane reachability to the responder. Until the outbound SA is installed, the responder MUST use the Fallback SA for traffic destined to the initiator.

When a per-resource Child SA is established, each peer programs its NIC or kernel packet classifier to steer incoming ESP traffic for that UDP port pair to the target CPU or queue. Because the same Ephemeral Source Port appears in different header fields on each side, the steering rules are asymmetric:

On the initiator: incoming ESP traffic from the responder arrives with dst-port = Ephemeral-Source-Port. Steer on dst-port = Ephemeral-Source-Port.
On the responder: incoming ESP traffic from the initiator arrives with src-port = Ephemeral-Source-Port. Steer on src-port = Ephemeral-Source-Port.

Example using ethtool ntuple rules, where the Ephemeral Source Port is 50001 and queue index is 20:

NIC Steering Rules (Ephemeral Source Port 50001)

The design requires that only the initiator selects the Ephemeral Source Port for a per-resource Child SA. If both peers were to independently choose their own ephemeral ports, the responder would install the Child SA bound to the initiator's private address before any traffic has flowed. When a NAT is present, the responder does not yet know the NAT-translated address and port for the new flow: no mapping exists until the initiator sends the first packet. The responder may also have no route to the initiator's private address and cannot send traffic until the NAT mapping is established. By requiring the initiator to select the port and send first, the NAT mapping is created before the responder installs the outbound SA, avoiding this failure mode.

When the initiator A is behind a NAT gateway N, and A creates a per-resource Child SA from Ephemeral Source Port P:

Initiator-Behind-NAT Port Mapping NAT --> N:Q --> B:4500 (initiator to responder) B:4500 --> N:Q --> A:P (responder to initiator) ]]> The NAT gateway creates a new mapping for source port P, translating it to external port Q. The responder B receives CREATE_CHILD_SA from N:Q and responds to N:Q. The per-resource Child SA's port binding at the responder is (N:Q, B:4500). No special handling is required; the standard procedure of applies.

When there is no NAT between peers, per-resource Child SA creation proceeds as described in . IP and port tuples are used directly for NIC steering and SAD lookups. The source and destination ports are symmetric in the ESP flow, as illustrated for Ephemeral Source Port 50001:

Port Tuples without NAT B:4500 (A to B ESP traffic) B:4500 --> A:50001 (B to A ESP traffic) ]]>

Some NAT deployments (e.g., certain cloud environments) allow mapping creation from either direction. In such environments, the responder MAY initiate per-resource Child SA creation using its own Ephemeral Source Port, with the NAT gateway creating the necessary mapping. The procedure is identical to the initiator case and no special handling is required.

When the responder B initiates a per-resource Child SA from a new Ephemeral Source Port and the NAT gateway does not support mapping creation in the B-to-A direction, the CREATE_CHILD_SA request is silently dropped. After retransmission attempts are exhausted per Section 2.1, B MUST abandon the attempt. A dropped CREATE_CHILD_SA leaves the IKE Message ID sequence in an inconsistent state. B MUST recover by sending an INFORMATIONAL exchange over the main IKE SA (UDP port 4500 to 4500), containing both an IKEV2_MESSAGE_ID_SYNC notification ( Section 5.1) and a Delete payload ( Section 3.11) carrying the SPI that B proposed in the failed CREATE_CHILD_SA.

INFORMATIONAL for Abandoned Per-Resource Child SA Multiple SPIs MAY be carried in a single Delete payload when several per-resource Child SA attempts are abandoned. On receiving this INFORMATIONAL, A processes IKEV2_MESSAGE_ID_SYNC per and processes the Delete payload per Section 3.11. If A has installed a Child SA for the indicated SPI, A MUST delete it. If the SPI is unknown to A, A silently ignores it per Section 3.11. B MUST be prepared to receive a delayed CREATE_CHILD_SA response even after sending this INFORMATIONAL. If such a response arrives and B installs the Child SA, B MUST delete it immediately. B MAY retry per-resource Child SA creation from a different Ephemeral Source Port, as individual ports may be selectively blocked by NAT policy. B SHOULD cease responder-initiated per-resource Child SA creation after repeated consecutive failures and rely on A to create additional per-resource Child SAs.

NAT mapping changes affecting per-resource Child SAs fall into two cases. When the peer's IP address changes (e.g., after network roaming), MOBIKE or the Section 2.23 address-change procedure detects the change on the Fallback SA's port pair (4500 to 4500). Per-resource Child SAs have no independent IKE channel and rely entirely on the Fallback SA for detection. Upon completing a MOBIKE UPDATE_SA_ADDRESSES exchange, the IKEd MUST delete all per-resource Child SAs associated with the affected IKE SA and SHOULD recreate them via CREATE_CHILD_SA exchanges from the new source address, following . Path validation () MUST be performed for each new per-resource Child SA before its outbound SA is installed. Until recreation is complete, the Fallback SA MUST be used for all traffic. When only an ephemeral port mapping changes (the IP address remains the same but the NAT gateway remaps a specific ephemeral port), the Fallback SA is unaffected and MOBIKE does not fire. Detection relies on NAT keepalive failure for that port pair (), DPD (), or path validation () timeout on the affected per-resource Child SA. Upon detecting the failure, the IKEd SHOULD delete the affected per-resource Child SA and recreate it via a new CREATE_CHILD_SA exchange.

A NAT gateway reboot or mapping table reset silently invalidates all per-resource Child SA port mappings. The Fallback SA is more resilient: IKE keepalives on the 4500 to 4500 port pair will naturally re-establish the NAT mapping on the first exchange after the reboot. Per-resource Child SAs on ephemeral ports have no independent keepalive that recreates their NAT mapping. Once a mapping is lost, inbound ESP traffic for those SAs is silently dropped. The IKEd SHOULD detect the failure via the DPD procedure described in or via path validation (), delete the affected per-resource Child SAs, and create replacements via CREATE_CHILD_SA exchanges sent from the Fallback SA's port pair (4500 to 4500). The first such exchange will re-establish the NAT mapping for the new Ephemeral Source Port.

When NAT traversal keepalives are required ( Section 6), a one-byte NAT keepalive packet MUST be sent for every active UDP source and destination port pair, not only for the Fallback SA's port pair (4500 to 4500). If N per-resource Child SAs and one Fallback SA are active, N+1 independent keepalive flows MUST be maintained, one per unique (src-IP, dst-IP, src-port, dst-port) tuple.

Liveness checking MAY be performed per per-resource Child SA port pair, or only on the Fallback SA port pair (4500 to 4500), as a local policy choice. If a liveness failure is detected on a per-resource Child SA path, only that SA and its associated port pair SHOULD be considered failed. The IKEd SHOULD delete the failed per-resource Child SA and MAY create a replacement. If a liveness failure is detected on the Fallback SA, all per-resource Child SAs associated with the same IKE SA SHOULD be considered failed, and the IKE SA teardown procedure ( Section 1.4) applies.

Rekeying of per-resource Child SAs MUST be initiated via the main IKE SA, using port pair 4500 to 4500. This ensures rekeying messages are not affected by per-resource Child SA path failures. The rekeyed Child SA MUST reuse the same Ephemeral Source Port as the SA being rekeyed, preserving the UDP binding and NIC queue steering configuration.

Delete exchanges for per-resource Child SAs MUST be sent via the main IKE SA port pair (4500 to 4500), ensuring delivery even when the per-resource Child SA path is no longer viable.

This mechanism applies equally to EESP when Sub SAs are not in use. Each per-resource Child SA is a separate EESP Child SA with its own SPI negotiated via CREATE_CHILD_SA, and applies identically to the ESP case. When EESP Sub SAs are in use (an SSKDF transform is negotiated), the mechanism defined in this document does not apply. Sub SAs are derived from a parent EESP SA and have no independent SPIs or IKEv2 lifecycle; they do not participate in CREATE_CHILD_SA exchanges and cannot be bound to an Ephemeral Source Port. Note: if a future revision of EESP Sub SA negotiation includes support for resource binding and UDP source port assignment, the per-resource distribution function provided by this document could be subsumed into the base Sub SA mechanism, eliminating the need for separate CREATE_CHILD_SA exchanges per resource.

This document requests IANA to assign a value for TBD1 in the "IKEv2 Notify Message Status Types" registry:

Value	Notify Message Status Type	Reference
TBD1	UDP_EPHEMERAL_SOURCE_PORT	This document

Per-resource Child SAs have independent key material, inheriting the security properties of ESP-in-UDP . The Ephemeral Source Port provides entropy in the outer UDP header but carries no cryptographic material. The path validation requirement (see ) ensures that traffic is not forwarded on an SA whose data path has not been confirmed. Bypassing path validation risks traffic blackholing when paths are blocked by NAT or firewall policy. The abandoned-SA recovery procedure in uses a standard Delete payload over the main IKE SA. Implementations MUST handle a delayed CREATE_CHILD_SA response arriving after the recovery INFORMATIONAL has been sent, as specified in that section. UDP source port variation increases the set of flows observable by on-path devices. ESP encryption and integrity protection prevent payload manipulation, but per-flow traffic analysis based on port patterns remains possible. The varying source port is a performance mechanism; it MUST NOT be relied upon as a security mechanism.

This document evolved from discussions at several IETF meetings and from review of . The authors thank the IPSECME working group participants for their input and feedback, with particular thanks to Valery Smyslov, Tero Kivinen, Paul Wouters, and Paul Bottorff.