Separate Transports for IKE and ESP

The Internet Key Exchange protocol version 2 (IKEv2) originally used unreliable transport (UDP) for its messages. Later it was extended to use TCP 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 . 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 (, , ). When IKE messages grow to tens or even hundreds of kilobytes, using UDP as a transport becomes challenging. The use of IKE fragmentation 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. Using reliable transport (e.g., TCP) for IKEv2 could be a solution to the problem. However, the current use of TCP as defined in implies that ESP SAs are also encapsulated in TCP, which has negative impact on IPsec performance (see Section 9 of ). 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 exchnage, 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. The proposed mechanism enables the use of all parameter sets of a post-quantum key exchange algorithm in IKE_SA_INIT as a quantum-resistant-only key exchange. Unlike approaches that limit the parameter sets based on message size constraints, this specification supports the use of larger parameter sets when IKEv2 is transported over TCP. 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. 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 idea to decouple IKE and IPsec transports was originally presented in .

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.

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 port 4500, as per . 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.

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 if possible, else over TCP ]]>

Alternatively, the initiator may start IKE_SA_INIT over TCP port 4500 directly, as specified in , for example, when large key exchange payloads (with large public keys) are expected. 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 , 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 . If the responder does not support the SEPARATE_TRANSPORTS notification (i.e., the notification is not echoed in the 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 . In both scenarios, once the IKEv2 exchange 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.

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 ]]>

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 . 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 . Peers are responsible for maintaining NAT mappings by sending NAT keepalive packets (see Section 2.23 of ) when ESP over UDP is used. 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 MAY be used.

MOBIKE allows an IKE SA, along with its Child SAs, to migrate from one IP address to another. Section 7.1 of 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.

Section 10 of 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:

SEPARATE_TRANSPORTS ]]>