Skip to content

SYSTEM Cited by 1 source

IKEv2 (Internet Key Exchange v2)

What

IKEv2 (Internet Key Exchange version 2) is the IETF-standardised key-exchange and security-association management protocol for IPsec, defined in RFC 7296 (2014). IKEv2 negotiates the cryptographic parameters (ciphersuites, keys, algorithms, SA lifetimes) that secure subsequent IPsec data- plane traffic delivered over the Encapsulating Security Payload (ESP) protocol.

IKEv2 is IPsec's TLS-equivalent handshake layer: both run before bulk encrypted traffic, both negotiate algorithms, both derive session keys, both authenticate the parties. The protocols diverge in transport shape (TLS over TCP; IKEv2 over UDP on port 500 / 4500) and in what the resulting session protects (TLS carries application-layer TCP/HTTP; IPsec carries arbitrary IP traffic).

Role in the wiki

IKEv2 is the handshake where the 2026 post-quantum IPsec rollout lands. Cloudflare's 2026-04-30 IPsec GA post uses IKEv2 as the named extension point for hybrid ML-KEM:

"Cloudflare IPsec now uses post-quantum encryption with hybrid ML-KEM (FIPS 203) to stop harvest-now-decrypt-later attacks… draft-ietf-ipsecme-ikev2-mlkem specifies post-quantum encryption for IPsec using hybrid ML-KEM, which combines the well-understood security of classical Diffie-Hellman and the post-quantum security of ML-KEM in a single, standards-compliant handshake." (Source: sources/2026-04-30-cloudflare-post-quantum-encryption-for-cloudflare-ipsec-is-ga)

The relevant IKEv2 machinery for PQ rollout:

  • Security Association (SA) payload carries the ciphersuite advertisement — algorithm negotiation at IKE layer. This is where MLKEM768 gets added to the advertised KEM list.
  • Key Exchange (KE) payload carries the DH / KEM public keys on the wire. Hybrid ML-KEM requires two KE payloads — one for classical DH, one for ML-KEM.
  • ESP protocol delivers the bulk encrypted IP traffic whose session keys IKEv2 derived.
  • CHILD_SA / IKE_SA rekey events periodically refresh keys; these also use the hybrid handshake post-2026.

RFC 9370 vs draft-ietf-ipsecme-ikev2-mlkem

Two IETF publications sit between vanilla IKEv2 and today's post-quantum IPsec:

  • RFC 9370 (2023) — Multiple Key Exchanges in IKEv2. Generic mechanism allowing up to seven additional key exchanges to run in parallel with classical DH. Does not specify which ciphersuites. This is the extension-mechanism-without-named-default publication that caused ciphersuite bloat — vendors shipped non-interoperable PQ implementations against it (most prominently Palo Alto Networks).
  • draft-ietf-ipsecme-ikev2-mlkem (late 2025). Names ML-KEM specifically as the parallel KEM and pins its parameters. Fills RFC 9370's gap. This is the draft Cloudflare's 2026-04-30 GA post implements; Cisco 8000 Series (26.1.1+) and Fortinet FortiOS (7.6.6+) branch connectors also implement it.

The hybrid handshake

draft-ietf-ipsecme-ikev2-mlkem specifies the following ordering:

IKE_SA_INIT (classical DH exchange)
    ↓
IKE_INTERMEDIATE (new IKEv2 message type for the PQ second exchange)
    ├─ encrypted under key derived from classical DH
    └─ carries ML-KEM public key / ciphertext
    ↓
IKE_AUTH (authentication + CHILD_SA creation)
    ├─ uses session keys derived from KDF(K_cl || K_pq || transcript)
    ↓
ESP (IPsec data plane) flows over the resulting SA

Three structural properties:

  1. Classical DH runs first. The resulting shared secret encrypts the subsequent ML-KEM exchange, so an observer sees only ciphertext for the PQ half.
  2. Both halves mix into the session key. The final IPsec session key depends on both the classical DH output and the ML-KEM output — neither alone suffices. This is the hybrid KEM property.
  3. IKE_INTERMEDIATE is the extension point. RFC 9242 added the IKE_INTERMEDIATE exchange specifically to carry PQ material between IKE_SA_INIT and IKE_AUTH — the composition point for algorithm-agnostic extensions.

IKEv2 features relevant to PQ rollout

  • SA lifetime + rekey. IKEv2 SAs have bounded lifetimes; rekeys re-run the handshake. Post-2026 rekeys use the hybrid. This means the per-tunnel PQ coverage grows continuously as long-lived tunnels rekey, not just at fresh SA establishment.
  • Dead peer detection (DPD). Liveness probes don't affect the PQ handshake; they run on established SAs.
  • EAP authentication. IKEv2 supports EAP-based authentication (RADIUS-backed, certificate-based, pre-shared keys). Post-quantum authentication for IKEv2 is not yet specified in IETF drafts — this is the gap Cloudflare's 2026-04 post flags for future work.
  • Mobility (MOBIKE, RFC 4555). IKEv2 supports IP-address changes on the client side without tearing down the SA — important for mobile VPN clients. Orthogonal to the PQ handshake.

IKEv2 vs TLS 1.3 handshake shape

Axis TLS 1.3 IKEv2
Transport TCP UDP (port 500 / 4500)
Round trips (classical) 1-RTT 2 RTT (SA_INIT + AUTH)
Algorithm advertisement supported_groups / key_share SA payload (Transform substructure)
Hybrid PQ extension point Same key_share slot IKE_INTERMEDIATE (RFC 9242)
Cert-chain signature Single per handshake Cert-based auth in IKE_AUTH
Rekey mechanism Session resumption / new handshake CHILD_SA / IKE_SA rekey
Named PQ ciphersuite X25519MLKEM768 (2022) ML-KEM hybrid draft (late 2025)
Time from NIST FIPS 203 to deployment ~2 years (pre-FIPS actually) ~2 years post-FIPS

Seen in

  • sources/2026-04-30-cloudflare-post-quantum-encryption-for-cloudflare-ipsec-is-ga — canonical wiki instance. Cloudflare's 2026-04-30 IPsec GA post implements draft-ietf-ipsecme-ikev2-mlkem on IKEv2, with interoperability verified against Cisco 8000 Series (26.1.1+) and Fortinet FortiOS (7.6.6+) branch connectors and earlier against strongswan reference implementation. The post articulates the RFC 9370 (generic mechanism) vs draft-ietf-ipsecme-ikev2-mlkem (named ciphersuite) distinction + PANW-non-interop consequence of the gap between them.
Last updated · 433 distilled / 1,256 read