Classic McEliece IKEv2 handshakes can take up to two minutes, no method fully mitigates large PQC key size
The claim
The authors assert that none of the evaluated IKEv2 adjustments fully compensate for the performance impact of large post-quantum KEM keys, and Classic McEliece fails under challenging network conditions
Published as: “Embedding Large PQC KEMs in IKEv2”
So what
Implementers of post-quantum VPNs can use the QUIKE composite design to achieve better performance for typical KEM sizes, but must consider compatibility trade-offs and the lack of real-world validation.
The five-minute version
For the largest post-quantum KEMs, none of the evaluated IKEv2 adaptations achieve acceptably stable handshake performance; for smaller and medium-sized KEMs, the QUIKE composite key-exchange design provides the highest and most stable performance while breaking compatibility with the existing IKEv2 design. The evidence comes from a systematic testbed evaluation of 1,296 configurations (80-200 runs each) showing rare failures (101 of 126,500 handshakes) confined to >5% loss and detailed latency/bandwidth impact analysis. The paper does not provide real-world deployment data, so the findings are limited to the simulated environment.
What they found 3
- For the largest KEMs, no approach offers acceptably stable performance; for smaller/medium KEMs, QUIKE composite yields the highest and most stable performance while breaking compatibility.
“It shows that for the largest KEMs, no approach offers acceptably stable performance. For smaller and medium-sized KEMs, two pathways arise: One follows the already standardized way, adhering to design decisions and keeping continuity, but requires more complex adjustments and optimizations to provide performance and stability. The other moves away from existing design decisions and breaks compatibility, but offers the highest and most stable performance with an overall simpler design, especially QUIKE with a composite key exchange.”
- Handshake failures are rare and only occur at high packet loss levels.
“Failures are rare and confined to the two highest loss levels: 101 of 126 500 handshakes failed after timing out or reaching a retransmission limit, none below 5% packet loss.”
- Latency primarily affects smaller KEMs while bandwidth limits larger KEMs, with quantified mean duration factors.
“Latency affects smaller KEMs and bandwidth limits the larger ones. Varying the bandwidth changes the mean by a median factor of 1.11 for MLKEM and 7.39 for Classic McEliece, varying the latency by 3.29 and 1.73 respectively.”
What undercuts it the paper’s own results
- The FEC approach cannot recover if the first fragment is lost, limiting its reliability despite added redundancy.
- The implementations omit negotiation of the new transports and assume all peers start over TCP, which may affect real-world applicability.
Stated limits 3
- If the first fragment is lost in transmission, the exchange cannot proceed as it contains information about the inner IKEv2 payload type.
- The fourth change to the QUIC library (initial congestion window of 30 datagrams) deviates from the specification’s SHOULD.
- Our implementations do not include negotiation (like proposed by the separate transports draft) but assume all peers begin their handshake over TCP.
What’s new here 3
- A forward error-correcting code (RaptorQ) based approach to stabilize transmission of fragmented large KEM keys in IKEv2.
- Two QUIKE designs that fuse IKEv2 with QUIC, including a composite key-exchange variant.
- Systematic measurement of handshake performance across latency, bandwidth, and loss for multiple KEMs and protocol adaptations.
Artifacts & methods 5
- openiked-portable implementationsystem
- RaptorQ fountain codes via nanorq libraryprimitive
- QUIC library ngtcp2 (patched)system
- status-ACK and notify-ACK retransmission schemesprimitive
- Testbed measuring handshake duration under varying latency, bandwidth, and packet lossevaluation