Post-Quantum Cryptography in IPsec and IKEv2

An adversary recording VPN traffic today can decrypt it later once a cryptographically relevant quantum computer exists - the harvest-now-decrypt-later problem. The fix is to exchange at least one post-quantum key during the handshake so the session secret depends on a problem that quantum computers do not solve. Concretely that means ML-KEM (the standardised module-lattice KEM in FIPS 203) carried inside IKEv2 using the multiple key exchange extension in RFC 9370. This article explains the mechanism and what to plan for, without over-promising vendor timelines.

Why ML-KEM and Not a New Cipher

• ML-KEM is a key encapsulation mechanism, so it replaces the key agreement part of the handshake, not the bulk cipher.
• AES-256-GCM stays exactly as it is: symmetric crypto is only weakened by Grover's algorithm, which effectively halves key length and leaves AES-256 at a comfortable margin.
• ECDH is not broken today, but the recorded traffic of today is what has to survive tomorrow - hence hybridising now.
• Signatures are the harder problem (ML-DSA for certificates, plus long-lived root continuity). Plan for KEM first; authentication migration follows the PKI upgrade cycle.

IKEv2 Multiple Key Exchanges (RFC 9370)

Classic IKEv2 completes one key exchange in IKE_SA_INIT. RFC 9370 allows additional IKE_INTERMEDIATE exchanges, each contributing its own KEM to the final secret. That gives you the hybrid you actually want:

• IKE_SA_INIT carries the classic ECDH share (still protecting against today's attackers).
• IKE_INTERMEDIATE carries ML-KEM encapsulated keys.
• The resulting keys are derived from the combination, so a break in either algorithm alone is not enough.

# conceptual configuration shape (syntax varies by vendor/version)
crypto ikev2 proposal HYBRID-PQ
 encryption aes-cbc-256
 integrity sha512
 group 20                          ! keep ECDH in the initial exchange

crypto ikev2 policy 10
 proposal HYBRID-PQ
 additional-key-exchange ml-kem-768   ! IKE_INTERMEDIATE with ML-KEM

crypto ipsec profile HYBRID
 set ikev2-profile HYBRID-PQ
 set pfs group20

! Junos equivalent direction:
set security ike proposal HYBRID-PQ authentication-method pre-shared-keys
set security ike proposal HYBRID-PQ dh-group group20
set security ike proposal HYBRID-PQ encryption-algorithm aes-256-cbc
set security ike gateway GW-1 ike-policy HYBRID-PQ

Check your platform's release notes for the exact keyword - implementations normally name the KEM explicitly (ml-kem-512/768/1024) and require a matching IKEv2 version that supports IKE_INTERMEDIATE.

Verification

show crypto ikev2 sa detailed | include KEM
show crypto ikev2 sa detailed | include INTERMEDIATE
show crypto ipsec sa | include PFS

! Junos
show security ike security-associations detail
show log kmd | match ml-kem

The association should report both the classical DH group and the additional KEM exchange. If only the DH group appears, the peer negotiated a fallback, which is expected during transition - log it and fix the peer rather than assuming protection.

Migration Plan That Does Not Break the Network

• Inventory every IPsec endpoint and its software version; PQ support is version gated, not configuration gated.
• Start with tunnels carrying data with a long confidentiality lifetime (backups, replication, telemetry archives, anything crossing an untrusted carrier).
• Deploy hybrid, not PQ-only. Hybrid keeps you interoperable and avoids a single new algorithm carrying all the risk.
• Expect larger handshake packets: ML-KEM public keys and ciphertexts are kilobytes, which can push an IKE_SA_INIT message past a 1500-byte path. Fragmentation and MTU behaviour needs testing on tunnels over the internet, and some middleboxes drop fragmented UDP 500.
• Track certificate and PKI readiness separately: KEM protects the session key today, but only ML-DSA certificates protect authentication against a future quantum attacker forging identities.
• Keep a documented fallback profile so an outage in one vendor's PQ implementation does not take the tunnel down permanently.

What to Tell Management

The honest version: no production quantum computer can break IPsec today, but traffic captured today can be decrypted later, and the migration touches both endpoints and the PKI, so it takes years. Beginning with hybrid key exchange on the highest-value tunnels is cheap now and expensive to retrofit later.

Related: IPsec/IKEv2 troubleshooting with debug output for reading handshake failures, route-based IPsec VPN on Juniper SRX, Cisco ASA site-to-site IPsec, and MACsec link encryption for hop-by-hop protection in the same estate.

原文链接：FIPS 203 (ML-KEM) ｜ RFC 9370