IPSECME Working Group A. Antony Internet-Draft S. Klassert Updates: 3948 7296 (if approved) secunet Intended status: Standards Track 18 August 2026 Expires: 19 February 2027 Multiple Ephemeral UDP Source Ports for ESP in UDP Encapsulation (MUSE) draft-antony-ipsecme-muse-00 Abstract This document specifies a mechanism to improve network path distribution and host receive-queue load distribution for IPsec traffic using ESP in UDP encapsulation [RFC3948]. Using the per- resource Child SA mechanism of [RFC9611], peers negotiate multiple Child SAs each bound to a distinct UDP source port. The resulting entropy in the UDP source port enables network devices to distribute per-resource traffic across distinct paths (equal-cost multi-path, ECMP) and lets the host NIC steer each per-resource flow to a distinct receive queue via receive-side scaling (RSS), supporting efficient per-CPU IPsec processing. This document specifies the IKEv2 negotiation, NAT traversal behavior, and operational requirements for this mechanism. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 19 February 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. Antony & Klassert Expires 19 February 2027 [Page 1] Internet-Draft MUSE August 2026 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5 3. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 5 4. Updates to RFC3948 and RFC7296 . . . . . . . . . . . . . . . 6 4.1. Update to RFC3948 . . . . . . . . . . . . . . . . . . . . 6 4.2. Update to RFC7296 . . . . . . . . . . . . . . . . . . . . 6 5. Fallback SA . . . . . . . . . . . . . . . . . . . . . . . . . 7 6. Per-Resource Child SA Negotiation . . . . . . . . . . . . . . 7 6.1. Capability Announcement . . . . . . . . . . . . . . . . . 8 6.2. Creating Per-Resource Child SAs . . . . . . . . . . . . . 8 6.3. Responder Behavior . . . . . . . . . . . . . . . . . . . 8 6.4. Implementation Considerations . . . . . . . . . . . . . . 9 6.5. Path Validation . . . . . . . . . . . . . . . . . . . . . 9 6.6. Alternative Path Detection . . . . . . . . . . . . . . . 10 6.7. NIC Queue Steering . . . . . . . . . . . . . . . . . . . 11 7. NAT Traversal Considerations . . . . . . . . . . . . . . . . 11 7.1. Initiator Behind NAT . . . . . . . . . . . . . . . . . . 12 7.2. No NAT . . . . . . . . . . . . . . . . . . . . . . . . . 12 7.3. Bidirectional NAT . . . . . . . . . . . . . . . . . . . . 12 7.4. Responder-Initiated SA Blocked by NAT . . . . . . . . . . 12 7.5. NAT Mapping Change . . . . . . . . . . . . . . . . . . . 13 7.6. NAT Mapping Loss . . . . . . . . . . . . . . . . . . . . 14 8. Operational Considerations . . . . . . . . . . . . . . . . . 14 8.1. NAT Keepalives . . . . . . . . . . . . . . . . . . . . . 14 8.2. Dead Peer Detection and Liveness . . . . . . . . . . . . 14 8.3. Child SA Rekeying . . . . . . . . . . . . . . . . . . . . 15 8.4. Deletion . . . . . . . . . . . . . . . . . . . . . . . . 15 9. EESP Considerations . . . . . . . . . . . . . . . . . . . . . 15 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 11. Implementation Status . . . . . . . . . . . . . . . . . . . . 16 11.1. strongSwan (prototype) . . . . . . . . . . . . . . . . . 16 12. Security Considerations . . . . . . . . . . . . . . . . . . . 17 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 14. Normative References . . . . . . . . . . . . . . . . . . . . 18 15. Informative References . . . . . . . . . . . . . . . . . . . 19 Antony & Klassert Expires 19 February 2027 [Page 2] Internet-Draft MUSE August 2026 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 1. Introduction 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 [RFC3948] 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 [RFC9611]. 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 [RFC9611]. This mechanism is defined for ESP [RFC4303] in UDP encapsulation [RFC3948]; its applicability to EESP [I-D.ietf-ipsecme-eesp][I-D.ietf-ipsecme-eesp-ikev2] is discussed in Section 9. 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 [RFC7296] Section 2.23. NAT keepalives ([RFC3948] 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. Antony & Klassert Expires 19 February 2027 [Page 3] Internet-Draft MUSE August 2026 1.1. Requirements Language 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 1.2. Terminology This document uses the following terms from IKEv2 [RFC7296]: Child SA, CREATE_CHILD_SA exchange, IKE_AUTH exchange, INFORMATIONAL exchange. This document uses the following terms from [RFC3948]: UDP- encapsulated ESP, Non-ESP Marker. This document uses the following terms defined in [RFC9611]: per- resource Child SA, Resource, SA_RESOURCE_INFO, TS_MAX_QUEUE. Fallback SA The initial Child SA established during IKE_AUTH (per [RFC9611] Section 3), in the case where it carries no resource binding -- an SA without resource specification, as opposed to the per-resource Child SAs of this document. It uses UDP source port 4500 and destination port 4500 and 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 [RFC9611]. See Section 10. Antony & Klassert Expires 19 February 2027 [Page 4] Internet-Draft MUSE August 2026 2. Problem Statement ESP in UDP encapsulation [RFC3948] 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 [I-D.ietf-ipsecme-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 [RFC6438] 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. 3. Solution Overview 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 Section 6.1) in the IKE_AUTH exchange. Antony & Klassert Expires 19 February 2027 [Page 5] Internet-Draft MUSE August 2026 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 [RFC9611]. 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 [RFC9611]. 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 [RFC7296] Section 2.23, updating the IKE SA peer port and disrupting all subsequent IKE communication. 4. Updates to RFC3948 and RFC7296 4.1. Update to RFC3948 [RFC3948] 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 Section 6. 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 [RFC3948]. 4.2. Update to RFC7296 [RFC7296] Section 2.23 requires that "The peer MUST also send all subsequent IKEv2 traffic on UDP port 4500." Antony & Klassert Expires 19 February 2027 [Page 6] Internet-Draft MUSE August 2026 [RFC7296] 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 [RFC7296]. 5. Fallback SA The Fallback SA is the initial Child SA established during the IKE_AUTH exchange using UDP source port 4500 and destination port 4500, following [RFC3948] and [RFC7296]. It is the initial Child SA of [RFC9611] Section 3 in the case where it carries no resource binding: 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). Implementation note: by this definition, the Fallback SA differs from a per-resource Child SA only in having no resource bound. Implementations that share Child SA installation logic between the two MUST gate Ephemeral Source Port assignment (and any other resource-specific behavior) on a resource actually being bound, not on some other marker of "is this the first SA." 6. Per-Resource Child SA Negotiation Antony & Klassert Expires 19 February 2027 [Page 7] Internet-Draft MUSE August 2026 6.1. Capability Announcement 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. 6.2. Creating Per-Resource Child SAs 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 [RFC9611]. The Ephemeral Source Port MUST be selected from the dynamic port range (49152-65535) per [RFC6056] 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 of the same IKE SA. Coordination across different IKE SAs (e.g. with other peers) is not required: the SAD and socket layer disambiguate SAs by the full address/port tuple, not by port alone, so reuse of an Ephemeral Source Port by an unrelated IKE SA does not cause a collision. The port SHOULD be selected randomly within the dynamic range per [RFC6056]. 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 ([RFC9611]). Creating additional per- resource Child SAs beyond available resources provides no benefit and increases IKE state on both peers. 6.3. Responder Behavior 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: Antony & Klassert Expires 19 February 2027 [Page 8] Internet-Draft MUSE August 2026 1. Respond to the initiator's Ephemeral Source Port from its own port 4500. 2. Install the Child SA with the IP and port tuple (initiator-IP, responder-IP, Ephemeral-Source-Port, 1. as the UDP binding. 3. 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. 6.4. Implementation Considerations 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, except for the liveness check of Section 6.6, which MUST be validated against the same IKE SA cookies. All other subsequent IKE traffic for the Child SA uses the Fallback SA's port pair (4500 to 4500). 6.5. Path Validation 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, using the default mechanism below or the Alternative Path Detection mechanism of Section 6.6. Antony & Klassert Expires 19 February 2027 [Page 9] Internet-Draft MUSE August 2026 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 ([I-D.ietf-ipsecme-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. 6.6. Alternative Path Detection As an alternative to waiting for real ESP traffic, the responder MAY actively confirm reachability toward the initiator immediately after completing the CREATE_CHILD_SA exchange, rather than deferring installation of the outbound SA until real traffic arrives. The responder sends an IKEv2 liveness check -- an empty INFORMATIONAL request per [RFC7296] Section 2.4 -- from its own port 4500 to the initiator's Ephemeral Source Port, reusing the NAT mapping already opened by the initiator's CREATE_CHILD_SA request. This tests exactly the direction that matters: whether the responder can reach the initiator through that specific port pair, which is the direction of the deferred outbound SA. The reverse direction needs no separate test: the responder's own CREATE_CHILD_SA response already crossed that path, per Section 6.3. Upon receiving a valid reply, the responder installs the outbound SA. If no reply arrives, the responder MUST fall back to the default mechanism of Section 6.5. This liveness check is an exception to the rule in Section 6.4 that no further IKEv2 messages are processed on the Ephemeral Source Port after CREATE_CHILD_SA completes: this specific exchange MUST still be validated against the IKE SA's cookies as described there. Implementations also need to extend the NAT-remapping guard of Section 4.2 to this exchange, so that the reply's source port is not mistaken for IKE SA roaming or a NAT mapping change. Implementations SHOULD prefer this mechanism when low-latency confirmation is desired, since it does not require an application data packet to arrive before the outbound SA is usable. Antony & Klassert Expires 19 February 2027 [Page 10] Internet-Draft MUSE August 2026 6.7. NIC Queue Steering 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: On initiator: ethtool --config-ntuple eth0 flow-type udp4 \ src-port 4500 dst-port 50001 action 20 On responder: ethtool --config-ntuple eth0 flow-type udp4 \ src-port 50001 dst-port 4500 action 20 Figure 1: NIC Steering Rules (Ephemeral Source Port 50001) 7. NAT Traversal Considerations 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. Antony & Klassert Expires 19 February 2027 [Page 11] Internet-Draft MUSE August 2026 7.1. Initiator Behind NAT When the initiator A is behind a NAT gateway N, and A creates a per- resource Child SA from Ephemeral Source Port P: A:P --> NAT --> N:Q --> B:4500 (initiator to responder) B:4500 --> N:Q --> A:P (responder to initiator) Figure 2: Initiator-Behind-NAT Port Mapping 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 Section 6.2 applies. 7.2. No NAT When there is no NAT between peers, per-resource Child SA creation proceeds as described in Section 6.2. 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: A:50001 --> B:4500 (A to B ESP traffic) B:4500 --> A:50001 (B to A ESP traffic) Figure 3: Port Tuples without NAT 7.3. Bidirectional NAT 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. 7.4. Responder-Initiated SA Blocked by NAT 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 [RFC7296] Section 2.1, B MUST abandon the attempt. Antony & Klassert Expires 19 February 2027 [Page 12] Internet-Draft MUSE August 2026 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 ([RFC6311] Section 5.1) and a Delete payload ([RFC7296] Section 3.11) carrying the SPI that B proposed in the failed CREATE_CHILD_SA. INF( N(IKEV2_MESSAGE_ID_SYNC), D(ESP, SPI) ) Figure 4: 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 [RFC6311] and processes the Delete payload per [RFC7296] 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 [RFC7296] 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. 7.5. NAT Mapping Change 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 [RFC4555] or the [RFC7296] 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 Section 6.2. Path validation (Section 6.5) 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. Antony & Klassert Expires 19 February 2027 [Page 13] Internet-Draft MUSE August 2026 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 (Section 8.1), DPD (Section 8.2), or path validation (Section 6.5) 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. 7.6. NAT Mapping Loss 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 Section 8.2 or via path validation (Section 6.5), 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. 8. Operational Considerations 8.1. NAT Keepalives When NAT traversal keepalives are required ([RFC3948] 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. 8.2. Dead Peer Detection and Liveness 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. Antony & Klassert Expires 19 February 2027 [Page 14] Internet-Draft MUSE August 2026 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 ([RFC7296] Section 1.4) applies. 8.3. Child SA Rekeying 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. 8.4. Deletion 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. 9. EESP Considerations This mechanism applies equally to EESP [I-D.ietf-ipsecme-eesp][I-D.ietf-ipsecme-eesp-ikev2] 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 [RFC9611] 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. Antony & Klassert Expires 19 February 2027 [Page 15] Internet-Draft MUSE August 2026 10. IANA Considerations 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 | +-------+----------------------------+---------------+ Table 1 11. Implementation Status Note to RFC Editor: please remove this section, and the reference to [RFC7942], before publication as an RFC. This section records the status of a known implementation of the mechanism described in this document, per the guidelines in [RFC7942]. The description of this implementation is provided by the authors and has not been independently verified; per RFC 7942 its inclusion is not to be construed as an endorsement of any particular implementation. 11.1. strongSwan (prototype) Name strongSwan Implementation link https://github.com/antonyantony/strongswan/tree/ ikev2-muse-20270730 A prototype implementation exists in strongSwan (charon), on a development branch not yet merged upstream. It implements: * Capability announcement (TBD1) in IKE_AUTH, and fallback to unnegotiated per_cpu_sas = encap behavior when the peer does not support it. * Ephemeral Source Port selection and per-resource CREATE_CHILD_SA as described in Section 6.2, including the NAT-remapping guard of Section 4.2. * Port placement on the installed Child SA per Section 6.3. * The Fallback SA port-pinning requirement of Section 5. Antony & Klassert Expires 19 February 2027 [Page 16] Internet-Draft MUSE August 2026 The following normative requirements are not yet implemented in this prototype: * Deferred outbound SA installation pending data-plane reachability confirmation (Section 6.5); both directions currently install immediately. Whether to implement the encrypted ESP ping ([I-D.ietf-ipsecme-encrypted-esp-ping]) or the IKEv2 liveness check of Section 6.6 to validate the path is still to be decided. * Independent NAT keepalives per active port pair (Section 8.1); only the Fallback SA's port pair is currently kept alive. * TS_MAX_QUEUE rejection when a peer requests too many per-resource Child SAs (Section 6.2). * Abandoned-SA recovery over NAT (Section 7.4). * Socket-level enforcement that no further IKEv2 messages are processed on an Ephemeral Source Port after its CREATE_CHILD_SA exchange completes (Section 6.4); the socket remains open and bound for the life of the process. Live two-peer interoperability testing (this implementation against itself) confirms the capability negotiation, per-resource Child SA establishment, and asymmetric port placement described in this document, path validation, or the failure-recovery procedures of Section 7. Testing used a standard Linux kernel with perCPU XFRM SA support; each per-resource Child SA of Section 6.2 is installed as an ordinary XFRM state. 12. Security Considerations Per-resource Child SAs have independent key material, inheriting the security properties of ESP-in-UDP [RFC3948]. The Ephemeral Source Port provides entropy in the outer UDP header but carries no cryptographic material. The path validation requirement (see Section 6.5) 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 Section 7.4 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. Antony & Klassert Expires 19 February 2027 [Page 17] Internet-Draft MUSE August 2026 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. 13. Acknowledgments This document evolved from discussions at several IETF meetings and from review of [I-D.xu-ipsecme-esp-in-udp-lb]. 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. 14. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. Stenberg, "UDP Encapsulation of IPsec ESP Packets", RFC 3948, DOI 10.17487/RFC3948, January 2005, . [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, DOI 10.17487/RFC4303, December 2005, . [RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport- Protocol Port Randomization", BCP 156, RFC 6056, DOI 10.17487/RFC6056, January 2011, . [RFC6311] Singh, R., Ed., Kalyani, G., Nir, Y., Sheffer, Y., and D. Zhang, "Protocol Support for High Availability of IKEv2/ IPsec", RFC 6311, DOI 10.17487/RFC6311, July 2011, . [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. Kivinen, "Internet Key Exchange Protocol Version 2 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 2014, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . Antony & Klassert Expires 19 February 2027 [Page 18] Internet-Draft MUSE August 2026 [RFC9611] Antony, A., Brunner, T., Klassert, S., and P. Wouters, "Internet Key Exchange Protocol Version 2 (IKEv2) Support for Per-Resource Child Security Associations (SAs)", RFC 9611, DOI 10.17487/RFC9611, July 2024, . 15. Informative References [I-D.ietf-ipsecme-eesp] Klassert, S., Antony, A., and C. Hopps, "Enhanced Encapsulating Security Payload (EESP)", Work in Progress, Internet-Draft, draft-ietf-ipsecme-eesp-03, 2 March 2026, . [I-D.ietf-ipsecme-eesp-ikev2] Klassert, S., Antony, A., Brunner, T., and V. Smyslov, "IKEv2 negotiation for Enhanced Encapsulating Security Payload (EESP)", Work in Progress, Internet-Draft, draft- ietf-ipsecme-eesp-ikev2-02, 2 March 2026, . [I-D.ietf-ipsecme-encrypted-esp-ping] Antony, A. and S. Klassert, "Encrypted ESP Echo Protocol", Work in Progress, Internet-Draft, draft-ietf-ipsecme- encrypted-esp-ping-03, 4 May 2026, . [I-D.xu-ipsecme-esp-in-udp-lb] Xu, X., Hegde, S., Pismenny, B., Zhang, D., Xia, L., and M. Puttaswamy, "Encapsulating IPsec ESP in UDP for Load- balancing", Work in Progress, Internet-Draft, draft-xu- ipsecme-esp-in-udp-lb-15, 26 February 2026, . [RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol (MOBIKE)", RFC 4555, DOI 10.17487/RFC4555, June 2006, . [RFC6438] Carpenter, B. and S. Amante, "Using the IPv6 Flow Label for Equal Cost Multipath Routing and Link Aggregation in Tunnels", RFC 6438, DOI 10.17487/RFC6438, November 2011, . Antony & Klassert Expires 19 February 2027 [Page 19] Internet-Draft MUSE August 2026 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running Code: The Implementation Status Section", BCP 205, RFC 7942, DOI 10.17487/RFC7942, July 2016, . Authors' Addresses Antony Antony secunet Security Networks AG Email: antony.antony@secunet.com Steffen Klassert secunet Security Networks AG Email: steffen.klassert@secunet.com Antony & Klassert Expires 19 February 2027 [Page 20]