Post-quantum interoperability testing VPN: how to do it

Post-quantum interoperability testing for VPNs is the structured process of checking that two independently built IKEv2/IPsec or TLS implementations negotiate the same hybrid key exchange (classical ECDHE combined with ML-KEM). Both sides have to use identical IANA code points, message formats and fallback rules before the setup is trusted on production or OT links.

For operators of substations, water treatment plants, pipelines and factory networks, this testing matters more than for a typical office network. OT links are long-lived and hard to touch once commissioned, and they often cross mixed equipment from different vendors and generations. One mismatched identifier can leave a link quietly on classical cryptography, or stop it from coming up at all during a maintenance window. This article covers the identifiers, the lab, the fallback checks and the public projects you can use.

How do you test whether two IKEv2 or TLS implementations can agree on hybrid ML-KEM?

Run real handshakes between every pair of implementations you plan to deploy. Then confirm from packet captures, not just dashboards, that the negotiated identifier is the hybrid ML-KEM one and that the derived keys actually protect the traffic.

TLS 1.3: read the ServerHello, not the config file

In TLS 1.3 the hybrid scheme is negotiated as a single “supported group”. draft-ietf-tls-ecdhe-mlkem defines three hybrid key agreement mechanisms for TLS 1.3, X25519MLKEM768, SecP256r1MLKEM768 and SecP384r1MLKEM1024, that combine ML-KEM with an ECDHE exchange. A successful test shows the client listing the hybrid group in both its supported_groups and key_share extensions, and the server answering with that same group in its key_share. If the server picks a classical group such as x25519, the connection works but is not post-quantum. A test that only checks “connection established” will not catch that.

Also check the size of what goes over the wire. A mismatch in how the two components are ordered is a classic interoperability bug: the ML-KEM shared secret is placed first in X25519MLKEM768, and the ECDH shared secret first in SecP256r1MLKEM768 and SecP384r1MLKEM1024. If an implementation gets this order wrong, the handshake fails with a decryption or Finished-message error, not a clean negotiation error. That makes it easy to misdiagnose.

IKEv2: proposals, transform slots and extra round trips

IKEv2 handles hybrids differently. RFC 9370 lets peers stack several key exchanges. It renames Transform Type 4 from “Diffie-Hellman Group (D-H)” to “Key Exchange Method (KE)”, and it adds Additional Key Exchange transform types. The common hybrid pattern is a classical ECDH group in Transform Type 4 during IKE_SA_INIT, with ML-KEM in ADDKE1 carried in a following IKE_INTERMEDIATE exchange. The current IETF draft specifies how to use ML-KEM by itself or as an additional key exchange in IKEv2 along with a traditional key exchange.

The interoperability question is therefore whether both peers place ML-KEM in the same slot and accept each other’s ordering. Your test cases should cover:

• Initiator A with responder B, and then the reverse. Initiator and responder code paths differ, and one-directional success is common.
• Initial IKE SA creation, Child SA rekey (CREATE_CHILD_SA) and IKE SA rekey. RFC 9370 also defines the IKE_FOLLOWUP_KE exchange type, value 44, which only shows up during rekeys.
• Proposals with several ADDKE options, to check that the responder picks one correctly and does not reject the whole proposal.

Which IANA code points must match for post-quantum key exchange interoperability?

For TLS, both peers must use the same value from the IANA TLS Supported Groups registry. For IKEv2, they must use the same Transform ID from the IANA IKEv2 Transform Type registry, “Transform Type 4 - Key Exchange Method Transform IDs”, in the same transform slot.

TLS Supported Groups registry

The registry entry for the most widely deployed hybrid is: X25519MLKEM768, value 4588 (0x11EC), DTLS-OK Y, Recommended Y. The other two hybrids in draft-ietf-tls-ecdhe-mlkem are SecP256r1MLKEM768 (4587, 0x11EB) and SecP384r1MLKEM1024 (4589, 0x11ED). Organisations that need both components produced by FIPS-approved mechanisms usually pick the NIST-curve variants, while internet-facing endpoints tend to favour X25519MLKEM768. Write the chosen group down in your crypto policy so every team configures the same one.

IKEv2 Transform Type registry

RFC 9370 does not create separate IDs for each additional slot. ADDKE Transform Types do not have Transform IDs specific to each Transform Type; instead they all share a single registry for Transform IDs, namely “Transform Type 4 - Key Exchange Method Transform IDs”. The IPSECME draft registers ML-KEM-512, ML-KEM-768 and ML-KEM-1024 there, with number 36 for ml-kem-768 (35 and 37 for the other two parameter sets).

• TLS: X25519MLKEM768 client share = 1216 bytes, server share = 1120 bytes (1184 bytes for ML-KEM plus 32 for X25519 on the client; 1088 plus 32 on the server; IETF draft-kwiatkowski-tls-ecdhe-mlkem-03, 2024).
• IKEv2: ML-KEM-768 KE payload = 1192 bytes (initiator) / 1096 bytes (responder) (Key Exchange Method number 36, data size 1184 / 1088 octets; IETF draft-ietf-ipsecme-ikev2-mlkem, 2025).
• RFC 9370 allows up to seven additional key exchanges (ADDKE1 with value 6 through ADDKE7; IETF, May 2023).

How do you build a test lab for quantum-safe encryption before deploying to OT networks?

Build a lab that copies the real network paths, MTUs, middleboxes and rekey timers of your OT links, not an idealised flat LAN. Then run each implementation pairing through scripted handshake, rekey, failure and recovery cases while capturing every packet.

Copy the path, not just the endpoints

Most post-quantum VPN failures in the field come from the path, not the cryptography. The IETF draft warns that ML-KEM-768 and ML-KEM-1024 public keys and ciphertexts may make UDP packet sizes larger than typical network MTUs. Your lab should therefore include:

• The same firewalls and NAT devices that sit in front of the real sites, with production rule sets. Some drop fragmented UDP/500 and UDP/4500.
• Links set to the real path MTU, including the smaller ones on cellular backhaul, satellite or MPLS overlays used at remote OT sites.
• Latency and loss emulation matching your worst link, because larger handshakes are more exposed to retransmission timers.
• An air-gapped segment if any production site is isolated, so you can check that nothing in the handshake or licensing depends on outside reachability.

Script the cases you cannot easily repeat in the field

Automate initial establishment, forced rekeys at short intervals, link drops during a rekey, and peer reboots. Run long soak tests (days, not minutes), because rekey-related interoperability bugs often show up only after hundreds of cycles. For OT, also measure added latency and jitter on the protected path with real protocol traffic such as Modbus/TCP or IEC 60870-5-104, not just synthetic throughput.

If you are evaluating a purpose-built gateway that uses its own hybrid protocol instead of IKEv2 or TLS, the focus moves from code point matching to behaviour under load. Quantum Network’s QPN, for example, combines a classical and an ML-KEM key exchange into one session key and renews both handshakes every two minutes. In a lab this means checking how traffic behaves across frequent rekeys and how routing changes interact with the gateway placement.

What fallback behaviour should you check when one peer does not support ML-KEM?

Check three things. Does the connection silently drop to classical-only key exchange? Does it fail loudly? Can it ever end up passing traffic without encryption? Each outcome should match a policy you chose on purpose, not a vendor default.

Silent classical downgrade

In TLS, a client offering both X25519MLKEM768 and x25519 will normally connect classically to a server without ML-KEM. That keeps things available, but the protection against harvest-now-decrypt-later is gone. Test it directly: point an upgraded client at a classical-only server, and make sure your monitoring logs which group was negotiated per session.

In IKEv2, how the hybrid behaves depends on whether ADDKE transforms are proposed as optional (with a “NONE” alternative) or required. If they are optional, a legacy responder simply ignores them. If they are required, the result is NO_PROPOSAL_CHOSEN. For peers you know have been upgraded, the IPSECME draft notes that an implementation can enforce a policy to not encrypt any data to one of these peers until an ML-KEM exchange has taken place, according to author Panos Kampanakis. Test both modes and record which one each site uses.

Failure must never mean cleartext

The most important negative test is the one teams tend to skip: break the post-quantum exchange on purpose (block the IKE_INTERMEDIATE message, corrupt a key share, restart a peer mid-rekey) and confirm that no payload leaves the protected interface unencrypted while the tunnel recovers. Check routing too. A tunnel that goes down can cause traffic to follow a default route around it. QPN is one example of a design where the connection never falls back to unencrypted traffic and retries automatically after a line failure. Whatever you deploy, verify this behaviour in your own lab.

Which public interoperability test projects exist for post-quantum protocols?

The main public efforts are the NCCoE Migration to Post-Quantum Cryptography project, IETF hackathons and working group interop activity (including the IETF PQUIP working group), and NIST’s algorithm validation programmes. They add to your own lab testing but do not replace it.

NCCoE Migration to Post-Quantum Cryptography project

The NCCoE project runs an industry consortium with a dedicated Interoperability and Performance of PQC Algorithms Workstream. According to the NCCoE, interoperability testing in this setting enables “resolution of compatibility issues in a controlled, non-production environment” and cuts the time individual organisations spend repeating the same tests. Its scope covers TLS, QUIC, SSH, code signing, public key certificates and hardware security modules, with results published in the NIST SP 1800-38C drafts. The published work focuses more on TLS than on IPsec, so treat it as a method reference for VPN testing, not as a completed result set.

IETF working groups and hackathons

Protocol drafts such as draft-ietf-tls-ecdhe-mlkem and draft-ietf-ipsecme-ikev2-mlkem are tested at IETF hackathons, where implementers run cross-implementation handshakes and report bugs back into the drafts. The IETF PQUIP (Post-Quantum Use In Protocols) working group does not define wire formats itself. It produces shared guidance and vocabulary, such as the PQ/T hybrid terminology draft (draft-ietf-pquip-pqt-hybrid-terminology) that the IKEv2 ML-KEM specification relies on. Reading these documents before writing test cases helps your team use the same terms as the specification authors.

Algorithm-level validation

Below the protocol layer, NIST’s Cryptographic Algorithm Validation Program tests ML-KEM implementations against FIPS 203 test vectors. A validated algorithm module is a necessary base, but it does not prove that two products agree on code points, slot ordering or fragmentation.

How should interoperability results shape the migration timeline?

Use the test results to sequence the migration. Links where every pairing passes can move first. Pairings that fail point to firmware updates or equipment replacement, and those need lead time in OT change windows.

• NIST IR 8547 timeline: 112-bit quantum-vulnerable algorithms deprecated after 2030 and disallowed after 2035 (NIST IR 8547 initial public draft, November 2024).

Because the IETF documents are still Internet-Drafts, plan to repeat the test suite after each significant draft revision or firmware release. A lab that is scripted, versioned and kept running after the first deployment is what makes this repeatable.