IPsec is the protocol family that builds Virtual Private Networks at the IP layer. Where TLS protects an individual TCP connection between client and server, IPsec protects entire IP streams between two endpoints, typically two routers, or a remote-access client and a corporate gateway. Most enterprise site-to-site VPNs run IPsec. Most government and military VPN infrastructure runs IPsec. Many cloud-to-on-prem hybrid networks run IPsec.
The signaling protocol that sets up IPsec security associations is IKEv2 (Internet Key Exchange version 2), defined in RFC 7296. And IKEv2 had a particularly elegant solution to post-quantum migration ready before TLS did, codified in RFC 9242 in May 2022.
This blog post explains how IPsec IKEv2 handles PQC, why the multi-KE approach (RFC 9242 + RFC 9370) is well-suited to PQC, and what the operational picture looks like.
IKEv2 In Two Paragraphs
IKEv2 is the negotiation protocol for IPsec. Two endpoints (often two routers, or a client and a gateway) exchange IKEv2 messages to authenticate each other, negotiate cryptographic parameters, and derive session keys for the actual ESP (Encapsulating Security Payload) traffic that follows. The IKE_SA_INIT exchange establishes the initial security association; IKE_AUTH authenticates both parties; CREATE_CHILD_SA establishes data-protection associations; INFORMATIONAL handles housekeeping and rekey.
The cryptographic core of IKEv2 is a Diffie-Hellman exchange (typically over Curve25519, P-256, or P-384) that produces a shared secret, plus signatures or pre-shared keys for authentication. As with TLS, both the DH exchange and the authentication signatures are vulnerable to quantum attack.
RFC 9242: Multiple Key Exchanges In IKEv2
RFC 9242, "Intermediate Exchange in the Internet Key Exchange Protocol Version 2 (IKEv2)", introduced a mechanism for performing additional cryptographic operations between the initial IKE_SA_INIT and the IKE_AUTH exchanges. The original use case was specifically PQC: do a classical Diffie-Hellman first, then do additional key exchanges layered on top, then authenticate.
RFC 9370, "Multiple Key Exchanges in the Internet Key Exchange Protocol Version 2 (IKEv2)", builds on this and specifies the actual mechanism for combining multiple key exchanges. It allows up to 7 additional key exchanges (KE2, KE3, ..., KE8) following the initial KE1, with each contributing entropy to the final session key.
The genius of the RFC 9370 design is that each additional key exchange is independent. You can mix:
- KE1 = X25519 (classical DH)
- KE2 = ML-KEM-768 (post-quantum KEM)
- KE3 = HQC-256 (alternative post-quantum KEM, defense in depth)
If any one of these holds, the session is secure. This is "hybrid-of-hybrids", a stronger version of the simpler hybrid construction used in TLS.
Why IKEv2 Was Better Positioned Than TLS
IKEv2 had two structural advantages for PQC migration:
First, the IKEv2 exchange model is naturally multi-round. TLS 1.3 handshakes are 1-RTT in the common case, which constrains how much data fits in the initial messages. IKEv2 normally takes 4 messages just for IKE_SA_INIT + IKE_AUTH, so adding a few more exchanges for PQC is not a paradigm shift.
Second, IKEv2 is mostly used between known peers. A site-to-site VPN endpoint knows the configuration of the other end. Both sides can be upgraded simultaneously by an administrator. There is no public-internet "you don't know who's connecting" problem.
This means PQC IKEv2 deployments can be aggressive. Operators can require PQC and refuse classical fallback, knowing both ends are under their control.
The IKE_INTERMEDIATE Message
RFC 9242 introduces a new IKEv2 exchange called IKE_INTERMEDIATE. It sits between IKE_SA_INIT and IKE_AUTH:
`` IKE_SA_INIT (KE1 - classical, e.g. X25519) IKE_INTERMEDIATE (KE2 - post-quantum, e.g. ML-KEM-768) IKE_INTERMEDIATE (KE3 - optional second PQC, e.g. HQC-192) IKE_AUTH (signature-based authentication) ``
Each IKE_INTERMEDIATE exchange is encrypted under the keys derived from previous exchanges, providing forward secrecy at each step. The session key keeps mixing in additional entropy, so by the time IKE_AUTH happens, the keys are derived from all the key exchanges combined.
Why Multi-KE Is Useful For PQC
The argument for multiple key exchanges, beyond the obvious belt-and-braces of one classical plus one PQC, is hedging against PQC-vs-PQC algorithm risk. ML-KEM is based on Module-LWE. HQC is based on coding theory (quasi-cyclic codes with concatenated Reed-Muller and Reed-Solomon decoding). If one mathematical family is later broken, the other remains.
This is not theoretical paranoia. The PQC standardization process has seen candidates fall: SIKE (supersingular isogeny) was broken by an attack from researchers at KU Leuven in 2022, after years of being considered a strong candidate. NTRU Prime did not advance to the final NIST selection. The history of cryptography is littered with algorithms that were "obviously secure" until they weren't.
For high-assurance environments, government, military, financial, having two independently-secure PQC mechanisms provides much stronger guarantees than relying on any single one. RFC 9370 makes this practical.
Cryptographic Combiner: HKDF Chain
The way RFC 9370 actually combines the multiple shared secrets is via repeated HKDF extraction:
`` SK_1 = prf(SK_seed, KE1_shared_secret) SK_2 = prf(SK_1, KE2_shared_secret) SK_3 = prf(SK_2, KE3_shared_secret) SK_d = SK_3 ``
Where prf is the negotiated pseudorandom function (typically HMAC-SHA-256 or HMAC-SHA-512). Each new shared secret refines the working key material. The final SK_d is used to derive the actual session keys for ESP traffic.
This chained extraction means even if KE1 and KE2 are both broken, KE3 alone provides full security. The construction is conservatively secure.
Authentication Side: ML-DSA For IKEv2
IKEv2's authentication step (IKE_AUTH) uses signatures, typically RSA, ECDSA, or Ed25519. These need to migrate to ML-DSA on roughly the same timeline as the key exchange.
The IETF IPSECME WG is working on draft-ietf-ipsecme-ikev2-pqc-auth and related documents to specify ML-DSA authentication for IKEv2. The signatures are placed in the AUTH payload of IKE_AUTH, with new identifiers in the IKEv2 Authentication Method Registry.
ML-DSA-65 produces 3,309-byte signatures. IKEv2 can handle this, there is no hard size constraint like QUIC's 1,200-byte limit. But the IKE_AUTH message becomes larger, which can stress middleboxes or fragmented-UDP behavior on certain network paths.
ESP Itself Does Not Need PQC
ESP (Encapsulating Security Payload), the protocol that actually carries encrypted IP traffic, uses symmetric encryption (typically AES-GCM or ChaCha20-Poly1305). Symmetric encryption is not significantly weakened by quantum computers, Grover's algorithm halves the security bits, leaving AES-256 with effectively 128-bit security, which is still considered safe.
So ESP itself does not migrate to PQC. The migration is entirely in the IKEv2 negotiation that establishes the ESP session keys.
Performance Profile Of Multi-KE Handshakes
A multi-KE IKEv2 handshake using X25519 + ML-KEM-768 + HQC-192 has roughly the following performance characteristics on modern hardware:
- X25519 ECDH: under 0.1 ms per side.
- ML-KEM-768 keygen + encapsulation/decapsulation: under 1 ms total per side.
- HQC-192 keygen + encapsulation/decapsulation: markedly slower than ML-KEM, from several milliseconds to a few tens of milliseconds per side depending on implementation and hardware.
- Combined HKDF chain: under 0.1 ms.
So the cryptographic CPU cost of a triple-KE handshake is on the order of 3-4 ms on modern x86. The dominant latency contribution is network round-trip time for the additional IKE_INTERMEDIATE exchange, which adds one full RTT per additional key exchange.
For a tunnel between two routers connected by a 50 ms RTT link, a triple-KE handshake takes roughly 200 ms total versus 50 ms for a single-KE handshake. Once the tunnel is established, ESP throughput is unaffected.
Pre-Shared Key And Authentication Migration
IKEv2 supports pre-shared key (PSK) authentication as an alternative to signature-based authentication. PSKs are quantum-safe by virtue of being symmetric. For high-assurance deployments, using a PSK-authenticated IKEv2 with multi-KE provides full PQC properties today, without waiting for ML-DSA standardization in IKEv2.
The downside is operational: managing PSKs at scale is hard. Each pair of peers needs a unique PSK, and PSK distribution requires an out-of-band secure channel. For small site-to-site VPN deployments, this is workable. For large meshes, it becomes the bottleneck.
The signature-based authentication path (eventually with ML-DSA) is more scalable but requires the IETF and vendor work to complete. Most enterprises will use a combination: PSKs for the most sensitive tunnels today, ML-DSA signatures once available.
Vendor Support Status
As of late 2025, the major IPsec implementations have varying levels of PQC support:
- strongSwan: implements RFC 9242 and RFC 9370. Hybrid key exchange with ML-KEM and other PQC KEMs is supported. Authentication PQC is in development.
- Libreswan: tracking the IETF specifications, with experimental PQC support.
- Cisco IOS / IOS-XE: roadmap items, with announcements expected over 2025-2026.
- Juniper Junos: similar roadmap status.
- Microsoft Windows Server VPN: tracking but no shipped PQC yet.
- Windows native IKEv2 client: tracking the same timeline.
The strongSwan project has been the open-source leader on PQC IKEv2, with experimental support shipped for years before the RFCs were finalized.
Configuration Example: strongSwan
A strongSwan configuration with hybrid PQC IKEv2 looks roughly like this in the swanctl.conf syntax:
`` connections { pqc-tunnel { proposals = aes256-sha512-x25519-mlkem768-hqc192 ... } } ``
The proposals line specifies the cryptographic algorithm suite: AES-256 for ESP, SHA-512 for integrity, X25519 + ML-KEM-768 + HQC-192 for the multi-KE key exchange.
Path MTU And Fragmentation
IKEv2 runs over UDP port 500 (or 4500 with NAT traversal). UDP packets are subject to IP-level fragmentation, which is unreliable on the public internet. Larger IKE_INTERMEDIATE messages can hit MTU limits.
RFC 7383 specifies IKEv2 message fragmentation, allowing the IKE layer to fragment its own messages independently of IP fragmentation. This is widely deployed and handles PQC's larger messages cleanly.
For very large key exchanges (multiple PQC KEMs combined), IKEv2 fragmentation kicks in and the protocol still works. But the round-trip count goes up because fragments are acknowledged independently.
What QNSQY Does
QNSQY itself does not run IPsec: our product encrypts data at rest, not network tunnels. The two defenses are complementary. PQC IKEv2 protects data in motion between sites; post-quantum data encryption protects the files, backups, and archives those tunnels carry once they land on disk.
For customers running site-to-site VPNs to protect QNSQY-encrypted file transfers, we recommend:
- Use IKEv2 (not IKEv1, which is deprecated).
- Deploy strongSwan or another PQC-capable IPsec stack at both ends.
- Configure RFC 9370 multi-KE with X25519 + ML-KEM-768 at minimum.
- Plan to add ML-DSA authentication when your stack supports it.
- Continue using AES-256-GCM for ESP, that remains quantum-safe.
The combination of PQC IPsec at the network layer plus PQC encryption at the file layer (QNSQY's hybrid encryption) provides defense in depth.
Frequently Asked Questions
Q: Is IKEv1 going to get PQC support? No. IKEv1 was formally deprecated by RFC 9395. Enterprises still using IKEv1 should migrate to IKEv2 regardless of PQC concerns.
Q: Can I use only ML-KEM, without classical DH? Technically yes, but not recommended. The hybrid model is conservative. ML-KEM has been NIST-standardized for less than two years; classical DH has decades of public scrutiny. Belt and braces.
Q: How much does multi-KE slow down my VPN? The handshake takes longer, roughly 1-2 additional round trips and a few KB of additional bandwidth. ESP throughput is unaffected once the tunnel is up. For long-lived tunnels, this is negligible.
Q: Does NAT traversal still work with PQC IKEv2? Yes. NAT-T uses UDP port 4500 and works with any IKEv2 cryptographic configuration. PQC's larger messages are fragmented as needed.
Q: What about OpenVPN, WireGuard, and other VPN protocols? OpenVPN runs over TLS, so PQC inherits from TLS. WireGuard's PQC roadmap is more constrained, see our WireGuard PQC article for details.
Sources
- RFC 9242, Intermediate Exchange in IKEv2. https://datatracker.ietf.org/doc/html/rfc9242
- RFC 9370, Multiple Key Exchanges in IKEv2. https://datatracker.ietf.org/doc/html/rfc9370
- RFC 7296, Internet Key Exchange Protocol Version 2 (IKEv2). https://datatracker.ietf.org/doc/html/rfc7296
- RFC 7383, IKEv2 Message Fragmentation. https://datatracker.ietf.org/doc/html/rfc7383
- NIST FIPS 203, Module-Lattice-Based Key-Encapsulation Mechanism. https://csrc.nist.gov/pubs/fips/203/final
- strongSwan documentation. https://docs.strongswan.org/
Related Articles
Protect Your Data Before Q-Day Arrives
QNSQY's NIST-standardized post-quantum encryption protects files against both current and quantum-era threats.