QUIC speeds two IKEv2 key types, but huge keys still struggle
Embedding Large PQC KEMs in IKEv2 · arXiv:2610.32356
In plain words
IKEv2 is a protocol that sets up secure network connections, but it cannot split up the first message of its setup. Some post-quantum keys are too large to fit easily in that message.
The paper reviews proposals and introduces three approaches, including using QUIC, a reliable way to carry the setup messages.
In tests, the combined QUIC approach had the shortest average setup time for two of the three key types tested. With the largest keys, every approach struggled on difficult network links.
The research
How can IKEv2 carry large post-quantum key data if its first exchange cannot be fragmented at the protocol level? The answer matters because key sizes differ sharply, and network delay, bandwidth, and packet loss can change whether an exchange completes quickly or creates congestion.
The authors review IETF proposals, add three protocol approaches, and compare how they carry post-quantum keys over challenging networks.
The central question is how IKEv2 can carry large post-quantum key data when its first exchange cannot use protocol-level fragmentation, especially over slow or lossy links.
The authors review IETF proposals, add three approaches, and compare their performance and resilience under emulated network conditions.
Across ML-KEM and FrodoKEM tests, the combined QUIC approach had the shortest mean handshake time among those tested. The means average configuration-level results across bandwidths and delays at each loss level.
But for Classic McEliece keys, every approach either averaged over a minute per handshake or congested the network under worsening conditions.
The tests used static pre-shared-key authentication and randomly scattered packet loss. They do not measure the extra traffic from signatures and certificate chains or show how the approaches perform with burst losses.
What the evidence shows
- A large key exchange problem
The paper combines a systematic review of IETF proposals for post-quantum key exchanges in IKEv2, three new protocol approaches, and a comparative evaluation. IKEv2 cannot use its own fragmentation mechanism in the first exchange, where large key data may need to travel. The authors ask how different approaches handle that constraint and challenging network conditions.
- Three ways to carry keys
The new approaches change how handshake messages travel. One adds redundant data to UDP messages to help recover from loss.
Two use QUIC, a reliable transport, to carry IKEv2 handshake messages; one of those combines the classical and post-quantum key shares in a single exchange. These designs are compared with proposals found in the IETF review.
- The smaller keys favor one approach
The authors measured 1,296 configurations that varied key type, delay, bandwidth, and packet loss, with reordering fixed. The test controller ran 126,500 handshakes across two connected Linux hosts with emulated network conditions.
For ML-KEM and FrodoKEM, QUIKE-composite had the shortest mean handshake duration among the tested approaches when configuration means were averaged across bandwidths and delays at each loss level.
- The largest keys remain difficult
That result has a clear boundary. For Classic McEliece, under worsening network conditions every tested approach either averaged more than a minute per handshake or congested the network.
The authors trace the difficulty to the much larger key data: datagram retransmissions could add congestion, while transport approaches slowed down in response to loss.
- Performance comes with trade-offs
The authors frame the choice as a trade-off for ML-KEM and FrodoKEM. Existing IKEv2 extensions preserve continuity and compatibility but may need optimization; changing transport can improve performance and simplify the design, at the cost of continuity and new dependencies. The test setup and the review's IETF-only search scope limit how broadly these findings apply.
Deep
- Original paper authors
- Daniel Herzinger, Marco Thomas, Tobias Handirk, Stefan-Lukas Gazdag, Daniel Loebenberger
- Submitted to arXiv
- License
- arXiv non-exclusive