| Internet-Draft | Separate IKE and ESP Transports | April 2026 |
| Smyslov & Reddy | Expires 11 October 2026 | [Page] |
The Internet Key Exchange protocol version 2 (IKEv2) can operate either over unreliable (UDP) transport or over reliable (TCP) transport. If TCP is used, then IPsec tunnels created by IKEv2 also use TCP. This document specifies how to decouple IKEv2 and IPsec transports so that IKEv2 can operate over TCP, while IPsec tunnels use unreliable transport. This feature allows IKEv2 to effectively exchange large blobs of data (e.g., when post-quantum algorithms are employed) while avoiding performance problems that arise when IPsec uses TCP.¶
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 11 October 2026.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
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.¶
The Internet Key Exchange protocol version 2 (IKEv2) [RFC7296] originally used unreliable transport (UDP) for its messages. Later it was extended to use TCP [RFC9329] where UDP is blocked. UDP remains the preferred transport for IKEv2, and TCP is only used if UDP datagrams cannot get through.¶
Originally IKEv2 peers exchanged only a small amount of data, so that simple retransmission mechanism on top of UDP with no congestion control sufficed. The situation has changed when post-quantum cryptographic (PQC) algorithms began to be incorporated into IKEv2 using multiple key exchanges [RFC9370]. Most of post-quantum algorithms require IKE peers to exchange much more data, than classical algorithms, up to tens (or even hundreds) Kbytes. A few proposals exist that allow to overcome the 64 Kbytes limitation on the size of an IKE payload ([I-D.nir-ipsecme-big-payload], [I-D.smyslov-ipsecme-ikev2-extended-pld], [I-D.tjhai-ikev2-beyond-64k-limit]).¶
When IKE messages grow to tens or even hundreds of kilobytes, using UDP as a transport becomes challenging. The use of IKE fragmentation [RFC7383] helps mitigate IP fragmentation issues and ensures that each IKE message fragment fits into a UDP datagram, even if the original message does not. However, all IKE fragments are always sent (and retransmitted) simultaneously, meaning that as the number of fragments increases and congestion control remains absent, the simple retransmission mechanism of IKEv2 will perform poorly potentially causing even more problems for the network.¶
In some cases, a pure PQC Key Exchange may be required for specific deployments, particularly those governed by regulatory or compliance mandates that necessitate exclusive use of post-quantum cryptography. Examples include high-security environments or sectors governed by stringent cryptographic standards. In this case larger amount of data need to be sent in the IKE_SA_INIT exchange, that makes using UDP problematic. For PQ KEM algorithms, if TCP is used for IKEv2 and peers do not require traditional algorithms, then PQ KEM can be used directly within the IKE_SA_INIT message when TCP transport is enabled for IKEv2. This approach allows IKEv2 to avoid UDP fragmentation concerns while enabling a purely post-quantum key exchange for deployments requiring exclusive PQC use.¶
Using reliable transport (e.g., TCP) for IKEv2 could be a solution to the problem. However, the current use of TCP for IKE and ESP [RFC9329] implies that ESP SAs are also encapsulated in TCP, which has negative impact on IPsec performance (see Section 9 of TCP encapsulation of IKE and ESP packets [RFC9329]).¶
This specification allows to decouple IKE and IPsec transports, making it possible to use a reliable transport for IKEv2 while continuing to use an unreliable transport for IPsec.¶
The proposed mechanism would enable the use of all parameter sets of a post-quantum key exchange algorithm in IKE_SA_INIT as a quantum-resistant-only key exchange. This allows deployments requiring a pure post-quantum key exchange to establish keys during the IKE_SA_INIT exchange without concerns about exceeding typical network MTUs.¶
The idea to decouple IKE and IPsec transports was originally presented in [I-D.tjhai-ikev2-beyond-64k-limit].¶
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.¶
If the initiator supports this extension, is configured to use it, and does not know whether the responder supports IKEv2 over TCP, the initiator starts the IKE_SA_INIT exchange over UDP to responder's port 4500, as per IKEv2 [RFC7296]. In this case, the initiator includes the SEPARATE_TRANSPORTS notification (<TBA by IANA>) in the IKE_SA_INIT request. This allows the initiator to discover whether the responder supports the use of separate transports for IKE (over TCP) and ESP (over UDP). Using UDP port 4500 ensures that IPsec traffic can traverse NATs and intermediate devices that allow UDP encapsulation. If the responder supports this extension and receives the SEPARATE_TRANSPORTS notification in the IKE_SA_INIT request, it responds with the same notification in the IKE_SA_INIT response. Upon receiving the SEPARATE_TRANSPORTS notification in the response, the initiator MUST switch to TCP port 4500 for subsequent exchanges (IKE_INTERMEDIATE or IKE_AUTH). The responder MUST be prepared to receive these exchanges over TCP.¶
Initiator (UDP) Responder (UDP:4500)
-------------------------------------------------------------------
IKE_SA_INIT request:
HDR , SAi1, KEi1, Ni,
[N(NAT_DETECTION_SOURCE_IP),
N(NAT_DETECTION_DESTINATION_IP),]
N(SEPARATE_TRANSPORTS) --->
IKE_SA_INIT response:
HDR, SAr1, KEr1, Nr,
[N(NAT_DETECTION_SOURCE_IP),
N(NAT_DETECTION_DESTINATION_IP),]
<--- N(SEPARATE_TRANSPORTS)
=> Initiator switches to TCP:4500 for IKE_INTERMEDIATE /
IKE_AUTH / subsequent IKEv2 exchanges
=> ESP over UDP or IP depending on the presence of NATs
¶
Alternatively, the initiator MAY start IKE_SA_INIT over TCP port 4500 directly, as specified in TCP encapsulation of IKE and ESP packets [RFC9329], for example, when large key exchange payloads (with large public keys) are used in IKE_SA_INIT. In this case, the initiator includes the SEPARATE_TRANSPORTS notification in the IKE_SA_INIT request to indicate its preference to use separate transports; IKEv2 over TCP and ESP over UDP, provided that UDP is not blocked in the network path.¶
If the responder supports this extension, it includes the SEPARATE_TRANSPORTS notification in the IKE_SA_INIT response. In this case, Child SAs are created as specified in IKEv2 [RFC7296], with ESP sent over UDP (or directly over IP) if possible. If both UDP and IP are blocked, ESP is sent over TCP as described in TCP encapsulation of IKE and ESP packets [RFC9329].¶
If the responder does not return the SEPARATE_TRANSPORTS notification in the IKE_SA_INIT response, the initiator MUST treat this as an indication that the responder does not support separate transports. In this case, both IKEv2 and ESP MUST use TCP transport for all subsequent exchanges, as per TCP encapsulation of IKE and ESP packets [RFC9329].¶
Initiator (TCP) Responder (TCP:4500)
-------------------------------------------------------------------
IKE_SA_INIT request:
HDR , SAi1, KEi1, Ni,
[N(NAT_DETECTION_SOURCE_IP),
N(NAT_DETECTION_DESTINATION_IP),]
N(SEPARATE_TRANSPORTS) --->
IKE_SA_INIT response:
HDR, SAr1, KEr1, Nr,
[N(NAT_DETECTION_SOURCE_IP),
N(NAT_DETECTION_DESTINATION_IP),]
<--- N(SEPARATE_TRANSPORTS)
=> All subsequent IKEv2 messages continue over TCP
=> ESP over UDP or IP if possible, else over TCP
¶
In both scenarios described above (Section 3.1 and Section 3.2), once the IKEv2 SA switches to TCP transport, either after IKE_SA_INIT or if TCP was used from the beginning, all subsequent IKEv2 exchanges MUST continue to use TCP. The interaction with MOBIKE is described in Section 4.1.¶
The SEPARATE_TRANSPORTS notification has Protocol ID set to 0 and SPI Size set to 0. This specification does not define any notification data, the notification is sent with no data. Future specifications may define data for this notification. Peers conforming to this specification MUST ignore any data if present.¶
Child SAs are created as specified in IKEv2 [RFC7296]. ESP packets either use direct transport over IP or are UDP encapsulated if NAT is detected. If UDP transport for ESP becomes unavailable (e.g., blocked by a firewall), peers MAY switch ESP to use TCP transport as specified in [RFC9329]. If ESP is transported over a different protocol than IKE, intermediate devices might apply different filtering rules. To detect possible connectivity issues with ESP traffic, the encrypted ESP ping mechanism defined in [I-D.ietf-ipsecme-encrypted-esp-ping] MAY be used.¶
When separate transports are used for IKEv2 and ESP, NAT traversal for each transport must be handled independently, as intermediate devices maintain NAT state per transport.¶
NAT detection follows the standard mechanism defined in Section 2.23 of [RFC7296]. The initiator SHOULD include NAT_DETECTION_SOURCE_IP and NAT_DETECTION_DESTINATION_IP notifications in IKE_SA_INIT, regardless of whether IKE_SA_INIT is sent over UDP or TCP. NAT detection MAY be omitted only if it is known by other means that no NAT is present on the path between the peers. If a NAT is detected, ESP MUST use UDP encapsulation on port 4500 [RFC3948]. Peers MUST maintain NAT mappings for the ESP path by sending NAT keepalive packets as specified in Section 2.23 of [RFC7296], and MUST NOT assume that the TCP connection used for IKEv2 provides any keepalive benefit for the ESP UDP path.¶
MOBIKE [RFC4555] allows an IKE SA, along with its Child SAs, to migrate from one IP address to another. Section 7.1 of TCP encapsulation of IKE and ESP packets [RFC9329] specifies that when using TCP as the IKE transport, a peer should attempt to switch back to UDP in the event of an IP address change. This specification updates that requirement: when separate transports are used for IKE and ESP, peers MUST NOT attempt to switch the IKE SA transport from TCP to UDP. However, an ESP SA MAY switch from UDP to TCP if UDP is blocked at the new IP address.¶
Ike session resumption [RFC5723] allows peers to quicly re-establish IKE SA after the connection is broken. Since network condition may change while the client is inactive, the use of separate transports MUST NOT be stored in the resumption ticket and MUST be re-negotiated during session resumption. Since no large public keys are transferred in the IKE_SESSION_RESUME exchange, then, unless configured to use TCP only, the initiator, when resuming, MUST start using UDP with destination port 4500, as discussed in Section 3.1. This enables NAT detection for UDP and UDP reachability testing before switching to TCP.¶
Section 10 of TCP encapsulation of IKE and ESP packets [RFC9329] discusses security implications of using TCP as IKE transport.¶
This document defines a new Notify Message Type in the "IKEv2 Notify Message Status Types" registry:¶
<TBA> SEPARATE_TRANSPORTS¶