Embedding Large PQC KEMs in IKEv2

Digital Object Identifier

Embedding Large PQC KEMs in IKEv2 DANIEL HERZINGER1 , MARCO THOMAS1 , TOBIAS HANDIRK1 , STEFAN-LUKAS GAZDAG1 , DANIEL LOEBENBERGER2 , MARIAN MARGRAF2

1

2

genua GmbH, Kirchheim, 85551 Germany Fraunhofer AISEC, Garching, 85748 Germany

Corresponding author: Daniel Herzinger (e-mail: daniel_herzinger@genua.de)

arXiv:2610.32356v1 [cs.CR] 23 Oct 2026

Part of this work was funded by the German Federal Ministry of Education and Research respectively the German Federal Ministry of Research, Technology and Space in the projects AMiQuaSy (project ID 16KIS1817) and SUSTAINET (project ID 16KIS2242 under the CELTIC-next program).

ABSTRACT Post-quantum key encapsulation mechanisms carry public keys far larger than the established VPN handshake protocol IKEv2 was designed for. At the same time, its initial exchange comprising the public keys cannot be fragmented. In response, the IETF discusses a range of protocol adjustments, yet these proposals have never been compared in terms of their performance and stability under identical conditions. We systematically screened the IETF document corpus for such proposals, added three of our own (one using forward error correction and two using IKEv2 with QUIC, namely QUIKE and QUIKE with a composite key exchange), identified two specification gaps in existing acknowledgment drafts, and implemented all eight on the same open-source codebase. Measurements across different bandwidths, latencies, and packet loss rates, and with ML-KEM, FrodoKEM, and Classic McEliece, total 126 500 handshakes in 1296 different configurations and show that no mechanism fully compensates for the effect of the key size on performance. For Classic McEliece, no approach handles challenging conditions acceptably. The approaches either congest the link or take up to nearly two minutes per handshake on average. For ML-KEM and FrodoKEM, there are two ways forward: building on already standardized extensions or delegating the transport. The former requires the larger implementation change and needs further optimization, such as acknowledgment mechanisms or error-correcting codes, but grants continuity and compatibility. The latter can use a composite key exchange to avoid these drawbacks and achieve a faster, more resilient handshake and leaner implementation, with QUIKE-composite offering the best overall performance. INDEX TERMS Cryptography, Forward error-correcting codes, IKEv2, IPsec, PQC, QUIC, VPN

I. INTRODUCTION

Virtual Private Networks (VPNs) securely interconnect IT infrastructure over public networks like the Internet, representing a backbone for modern distributed systems. However, the prospect of a large Quantum Computer (QC) threatens the asymmetric cryptography building blocks vital for establishing secure VPN connections. Even more urgently, an attacker can perform store-now, decrypt-later attacks, recording VPN connections today and using a QC to break the key agreement and decrypt the data in the future. New Post-Quantum Cryptography (PQC) key agreement mechanisms also protect against the QC threat. They typically consist of Key Encapsulation Mechanisms (KEMs) [1]. Compared to classical Diffie-Hellman (DH) constructs, they use a new syntax and both their public keys and ciphertexts are This work has been submitted to the IEEE for possible publication. Copyright may be transferred without notice, after which this version may no longer be accessible. VOLUME X, X

drastically larger. This complicates integrating them into the prevalent VPN protocols designed and optimized for classical cryptography. One example is IPsec’s handshaking protocol IKEv2 [2], first published in 2005. Its IETF working group acknowledged the need for adaptation, publishing the first PQC key agreement RFC [3] in 2023 and discussing further optimizations and alternatives since. Yet, these approaches are complex and face reliability issues, especially considering large PQC KEMs and difficult network environments [4, 5]. Such a fundamental change to a VPN protocol needs to balance requirements in terms of, but not limited to, performance, resilience, backwards compatibility, complexity, and implementation intrusiveness. The resulting situation is complex, exacerbated by a lack of comprehensive data even regarding the well-quantifiable dimensions of performance and network resilience. In response, we conducted a systematic search for all relevant proposals for PQC KEM protocol adjustments for IKEv2 discussed at the IETF. Additionally, we propose three 1

II. BACKGROUND AND RELATED WORK

This work focuses on PQC KEM integration into IKEv2, the current handshaking protocol of the IPsec suite. The other protocol widely used in IPsec is ESP [7]. It handles the payload encryption in the connections established by IKEv2. It relies on symmetric encryption schemes which, albeit not unaffected by QCs, are still able to provide sufficient security properties for those use cases. Thus, this paper concentrates on IKEv2 which is severely affected by the QC threat. 2

Responder

IKE_AUTH

IKE_SA_INIT

Initiator

Header, Parameter Proposal, Keyshare, Nonce Header, Parameter Selection, Keyshare, Nonce Encrypted

novel approaches: one using Forward Error-correcting Codes (FEC) and two versions of QUIKE, where we combine IKEv2 and QUIC. We evaluate all proposals in terms of performance and network resilience in one stable test environment. This yields clear and reproducible data for a fair comparison and discussion of the qualitative advantages and drawbacks of both the drafts already in discussion as well as our novel ones. 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. The results act as guidance and clarification for the standardization working group, the academic community, and implementers making trade-offs within their software. We enable this with the following contributions: • A systematic literature review across the IETF document corpus, identifying proposals for PQC KEMs in IKEv2. • An approach to stabilize the transmission of fragmented large KEM keys in IKEv2 using FEC. • Two approaches which fuse IKEv2 and QUIC [6] into QUIKE, a fast and reliable VPN key exchange protocol for IPsec; one using the previous ‘‘one-ke-per-round’’ semantics and one using a composite key agreement. • The identification of two specification gaps, concerning key retention and retransmission limits, in drafts adding acknowledgments to IKEv2 fragmentation, and a defect in the QUIC library we build on. • A reproducible evaluation of the handshake time of all approaches under varying latency, bandwidth, and packet loss as well as with three different KEMs. • A qualitative discussion of the approaches’ overall complexity, implementation intrusiveness, and practicability. The remainder of this paper is structured as follows: Section II gives an overview of IKEv2, PQC KEMs, FEC, QUIC, and related work. Section III states our research questions and describes both the systematic search and the measurement setup. Section IV presents the screened proposals and our three novel approaches; Section V covers their implementation and the measurement results, which Section VI puts into perspective. Finally, Section VII explores possible threats to the validity of our study and Section VIII concludes.

Header, ID, Child SA Parameter Proposal, Traffic Selectors Header, ID, Child SA Parameter Selection, Traffic Selectors

FIGURE 1. The message flow of a classic IKEv2 handshake.

A. CLASSIC IKEV2

IKEv2 is a UDP-based handshaking protocol defined in RFC 7296 [2]. It is part of the IPsec protocol suite and negotiates the used cryptographic parameters, derives the keys for symmetric encryption, and authenticates the connection. After completing a handshake, it installs Security Associations (SAs): data structures containing all necessary information, including the keys, for handling the encrypted traffic of one connection. They are divided into bidirectional IKE SAs which hold the information for the IKEv2 connection itself, and unidirectional Child SAs with the information for the actual payload data to be transmitted inside the VPN via ESP. Hence, after the IKEv2 handshake finishes, there is one IKE SA and a pair of Child SAs per peer. IKEv2 itself is structured into exchanges. In each exchange, both parties, the initiator and the responder, each send one message. Figure 1 illustrates the handshake structure. The first exchange (called IKE_SA_INIT ) starts the handshake, carries the negotiation of parameters and compatibility with possible IKEv2 extensions, and exchanges nonces and a first shared secret. All subsequent exchanges are then encrypted. The next exchange, i.e., IKE_AUTH, handles identity information, proposals for the first Child SAs, and a signature authenticating the handshake. Most subsequent actions, e.g., rekeying or creating additional Child SAs, are done via the CREATE_CHILD_SA exchange. To be as lean as possible and have no unnecessary roundtrips, IKEv2 uses UDP as its base. If packets get dropped on their path, the initiator notices that there is no answer from the responder which triggers a retransmission of their last exchange message. The responder, upon receiving a retransmitted message, assumes their answer got lost and retransmits theirs. As in classical setups most messages are small and the handshake is over after usually only two exchanges, transport features like congestion control are not considered necessary. One real limitation that comes with UDP is that no message can exceed the Maximum Transmission Unit (MTU) of the two VPN devices and of any of the middleboxes on the packet’s network path, which typically is at most 1500 bytes, sometimes 1280 bytes or less. Theoretically, IP fragmentation should solve this issue. However, that is unreliable in practice and, VOLUME X, X

TABLE 1. NIST security levels [12].

TABLE 2. Sizes of the transmitted objects, in bytes.

Level

Comparable difficulty

Scheme

Level

1 2 3 4 5

Comparable to a key search on AES-128. Comparable to a collision search on SHA3-256. Comparable to a key search on AES-192. Comparable to a collision search on SHA3-384. Comparable to a key search on AES-256.

Classical key agreements DH MODP-3072 DH MODP-8192 X25519 Post-quantum KEMs ML-KEM-768 ML-KEM-1024 FrodoKEM-976 FrodoKEM-1344 Classic McEliece 460896 Classic McEliece 8192128

thus, must be avoided [8]. RFC 1191 [9] gives techniques to determine the Path MTU (PMTU), yet as soon as an exchange message exceeds it, the handshake fails. To still be able to send, e.g., large certificate chains in IKE_AUTH, RFC 7383 [8] defines fragmentation on the IKEv2 level. However, it must not be used for the IKE_SA_INIT exchange [8] which is a major challenge for incorporating large PQC KEMs. B. POST-QUANTUM KEMS

Classical key agreement usually uses DH structures. There, both parties agree on public prime-order group G with generator g and compute their key shares as gx and gy for their uniformly random secrets x and y, respectively. Upon receiving the other party’s key share, they compute (gy )x and (gx )y , resulting in the same shared secret on both sides. However, if an attacker is able to solve the discrete logarithm problem in G, it is able to compute the shared secret gxy from the public key shares gx and gy . While there is no known efficient algorithm for calculating a solution for it on classical computers, a large QC is expected to be able to solve it in polynomial time [10, 11]. In response to the QC threat, the National Institute of Standards and Technology (NIST) started a competition to find the best quantum-safe, hence PQC, key agreement replacement focusing on KEMs [12]. This means that one party generates a public/private key pair KeyGen() → p, s and sends their ephemeral public key p to their peer. The peer encapsulates a random secret key k using the initiator’s public key Encaps(p) → k, c and sends the ciphertext c back to the initiator who uses their secret key s to also obtain the shared secret Decaps(c, s) → k. Apart from the new syntax, KEMs also have new properties that determine their security against chosen plain- or ciphertext attacks which need to be taken into account to prevent introducing new vulnerabilities [1]. The KEMs rely on the hardness of different mathematical problems in the field of unstructured or semistructured lattices and linear codes with errors, which are all assumed to be hard to solve, even with a QC. Yet, as cryptanalysis is not as advanced regarding them, they are still often only used in hybrid mode, i.e., in combination with a classical key agreement, to prevent the risk of actually downgrading security [13, 14]. Combining the classical and PQC shared secrets into one key is a well-studied problem with ready-made constructions [1, 15]. To classify the different algorithms and their parameters and give guidance regarding their security, NIST put them into categories, shown in Table 1. VOLUME X, X

Public key

Ciphertext

0 0 0

384 1 024 32

384* 1 024* 32*

3 5 3 5 3 5

1 184 1 568 15 632 21 520 524 160 1 357 824

1 088 1 568 15 744 21 632 156 208

* DH constructs send key shares with the same structure in both directions.

The different syntax and properties are mostly an implementation task. The biggest protocol-related difference is the PQC KEMs’ sizes. Table 2 compares prevalent classical DH key agreements with different PQC KEMs. It shows the symmetrical nature of DH constructs, while the KEMs sometimes are highly asymmetrical with the initiator usually transferring more data than the responder. The other big aspect for protocol design is the total size. A protocol which requires its first message to fit the MTU, i.e., 1500 bytes by default, sometimes less, needs modification to support almost any PQC KEM. We further show that the rudimentary fragmentation mechanism of RFC 7383 [8] is insufficient for dealing with packet loss or congestion at large KEM sizes. A Classic McEliece public key exceeds the size of an IKEv2 header length field, requiring even further modifications. Cryptanalysis advances published in concurrent work [16, 17] reduce the long-term trust in Classic McEliece’s security [18]. Still, it represents a good example for evaluation in the upper KEM-size regime, as similar advances might also affect other KEMs, potentially driving up the required KEM sizes across the schemes. Deployments with high security requirements and store-now, decrypt-later attacks in mind must take the risk of further (quantum-)cryptanalysis advances into account and require larger, more conservative KEMs. C. FORWARD ERROR-CORRECTING CODES

FEC is a well-established concept in the world of data transmission over lossy channels and storage media. FEC encodes source blocks and emits redundant encoded blocks, so the receiver does not need all of them to recover the data. The decoding success depends on the coding and loss pattern of the channel. In a VPN context, this recovery allows message reconstruction despite packet loss, minimizing handshake failure. The codes manifest in three primary groups: linear block codes, convolutional codes, and fountain codes. Linear block codes. Linear block codes generally possess the characteristics of being of a fixed rate. This means that once encoding parameters are established for a chunk of data, the resulting code is deterministically sized and cannot change in length or recovery power. 3

Reed-Solomon codes [19] from 1960 are well-known due to their simplicity and being a maximum distance separable (MDS) code [20, 21]. They use a fixed block sharding approach, where the quantity of excess shards determines recoverability. The shard size s is arbitrary but uniform across all shards. After chunking the source data into k shards of size s, a coding matrix yields the code. If at least k shards arrive at the destination, the message has a decoding probability of 100% and 0% otherwise. Also the probabilistic Low Density Parity Check (LDPC) code by Gallager from 1962 [22–24] is well-established in 5G radio access technology [25]. Convolutional codes. Convolutional codes do not encode fixed-length blocks independently, but rather generate each output symbol from a sliding window of the input stream. Turbo codes, introduced by Berrou et al. in 1993 [26, 27], are built from such codes: they are parallel concatenations of two recursive convolutional encoders. In practice, they are applied to fixed-size frames, as the interleaver and the iterative decoder operate on a whole block. Turbo codes achieve an error-correction performance close to the Shannon limit [28], but at the cost of iterative decoding. Further, they target noisy channels rather than pure erasure channels: the two encoders are separated by an interleaver, which decorrelates their inputs so that low-weight codewords are unlikely to occur in both encoders and the decoders can exchange largely independent information. This also spreads burst errors over the codeword. Rowshan et al. [29] show for the upcoming 6G mobile standard that the interleaver design has a substantial impact on the correction performance, and outline different designs for such codes. Fountain codes. Fountain codes, also called rateless codes, are the newest class of FEC. Luby et al. [30] published a precursor, the tornado codes, in 1997. They work by layering LDPC and Reed-Solomon codes to yield the best of both worlds in terms of efficiency and recovery chance. The result requires more symbols than Reed-Solomon, but performs many orders of magnitude faster [31]. After refinement, Luby published Luby Transform (LT) codes [32] in 2002. This represents the first version of modern fountain codes. Both Rapid Tornado (Raptor) [33] and its successor RaptorQ majorly improve encoding and decoding time, as well as decoding probability, as compared to LT coding. RaptorQ codes have been specified in RFC 6330 [34] and represent the most advanced version of fountain coding. LT coding can be represented as a bipartite graph, where encoding symbols represent linear combinations of source symbols with XOR operations, as shown in Figure 2. LT coding is inherently probabilistic, as the distribution of edges in this linear system is random. Qualcomm explains [35] the inner workings of edge selection and the specific encoding and decoding procedures. In summary, encoding symbols are formed by XOR operations, which correspond to addition in GF(2) but 4

x0

y0

x1

y1

x2

y2

x3

y3

x4

y4

x5

y5

y6

FIGURE 2. Bipartite graph with red source symbols and blue encoding symbols.

can be generalized to GF(q) [35]. For k source symbols, each encoding symbol corresponds to a coding vector ci = (ci,1 , ci,2 , . . . , ci,k ) ∈ GF(q)k , a vector space of dimension k containing qk elements. Recovering the source symbols therefore requires k linearly independent coding vectors. For uniformly random coding vectors, the probability that k + h received symbols suffice is approximately 1−q−(h+1) , an accurate estimate for large q. Each additional overhead symbol h therefore reduces the failure probability. As encoding symbols are mere linear combinations of the source symbols, an encoder can generate as many as needed, unlike Reed-Solomon codes, whose number of distinct code symbols is bounded by the field size. D. QUIC

Historically, most encrypted web traffic used SSL/TLS over TCP. This comes with disadvantages, one of them being additional Round-Trip Times (RTTs) for first the transport and only then the cryptography [6]. In response, QUIC was designed with the idea to integrate both handshakes into one protocol. It gives reliable, ordered, congestion-controlled delivery with its own loss detection [36] for the cryptographic handshake as well as the payload connections. QUIC was designed with the combination with TLS 1.3 in mind and to date only this one is standardized [37]. However, QUIC itself only defines a slot for the cryptographic protocol without mandating a specific one. The messages of QUIC’s handshaking phase travel in CRYPTO frames which are structured into three levels: Initial, Handshake, and 1-RTT. Each level has one byte stream which QUIC splits across packets. All packets are encrypted, although the key for the initial level’s frames is derived from the connection ID, which is sent in cleartext, thus providing obfuscation only. After finishing the initial level, the parties have established a fresh secret key that is then used for protecting the following messages. The handshake level completes the handshake and the 1-RTT level allows exchanging further CRYPTO frames or application data inside STREAM frames. QUIC requires the IP network to carry at least 1200-byte UDP datagrams and enforces each datagram carrying an initial packet to be padded to that size if necessary. This impedes Denial of Service (DoS) amplification attacks as it increases the cost for the client. Additionally, a responder must not send more than three times the number of bytes it has received from an address until that address’s return-routability is proven. VOLUME X, X

Under load, a responder may also frontload return-routability verification by answering a connection attempt with a Retry message, similar to IKEv2’s cookie mechanism. Furthermore, QUIC starts with a small congestion window. Afterwards, it adjusts it to the observed network path’s capabilities. Large messages in the initial level may, therefore, take more RTTs than in later handshaking stages. QUIC identifies connections by connection IDs instead of the used addresses. This gives roaming capabilitiesi, meaning adjusting to new addresses after validating the new path. A connection’s transport parameters, like the ID or flow control limits, usually ride a respective TLS extension. Further features of QUIC entail ordering application data into streams, reliably transmitting and multiplexing those streams, and 0-RTT session resumption. Those features allow QUIC’s integration into the HTTP/3 stack but do not affect any QUICIKEv2 interactions described in Section IV-C. E. RELATED WORK

There is exhaustive research about PQC migration and cryptographic agility. Näther et al. [38, 39] surveyed both areas and provide an overview of the current literature. Yet, the research about the PQC migration of secure protocols is more fractured, tailored toward the specific protocol and committee that maintains it. One prominent protocol to be migrated is TLS 1.3 [40]. Compared to IKEv2, it sits on top of TCP which automatically remedies IKEv2’s transport challenges. Classic McEliece, however, also does not fit into the header fields. Adding PQC authentication in TLS is rather straightforward, as the PQC signature schemes behave similarly to their classical counterparts except for their larger size, which is manageable with a TCP underlay. Sikeridis et al. [41] assess PQC authentication’s performance impact on TLS 1.3 and Paquin et al. [42] inspect the performance of PQC on TLS 1.3 overall. SSH uses TCP transport as well and chose similar hybrid key agreement schemes as TLS. Sowa et al. [43] concluded that TLS and SSH were the quickest to adopt (not necessarily standardized) PQC which we assume comes from them not having to solve as many transport challenges scaling with key/ciphertext size. In contrast, WireGuard [44] also relies on UDP which introduces the same challenges regarding the PMTU and middleboxes as in IKEv2. It already has a Pre-Shared Key (PSK) interface to be able to integrate keys exchanged outof-band. This, however, is more of a band-aid than a solution. Its full PQC version [45] solves this by selecting only KEMs that keep the in-band data small. WireGuard never allowed any algorithm selection and, hence, can just pick a small enough combination. It simply does not address needs for more conservative algorithm choices. WireGuard [44] and PQWireGuard [45] do not use signatures for authentication, in line with the Noise framework [46] and its post-quantum variant [47] or Rosenpass [48]. There, the authentication comes from the key agreement itself. For this, the parties store a static key share (DH) / key pair (KEM) which means that after key VOLUME X, X

agreement, only the actual peer is able to obtain the shared key, implicitly authenticating them (assuming no secret key got lost). They combine this with an ephemeral key agreement for forward secrecy. That authentication structure saves a second, separate cryptographic migration for signatures. Yet, for the KEMs, it faces the same size question as IKEv2. Schwabe et al. [49] also proposed a modified version of TLS, incorporating KEM authentication. Yet, this solution struggles with adoption, mostly as it represents a highly intrusive change with farreaching consequences for current deployments. IKEv2, despite its design decisions of classic UDP and high adjustability to different requirements, still took similar paths. One of the first proposals was to add a special PSK interface [50] to allow out-of-band exchange of keys, similar to WireGuard’s and IKEv1’s [51] PSK mechanism. Similarly, especially for the largest KEMs, the IETF working group discussed applying the Hash-and-URL mechanism, already standardized for large certificate chains [2], to key exchange payloads. There, the peers only send a hyperlink to the public key and a verification hash. Yet, merely moving the problem out of the protocol does not solve it, which is also why the IETF discarded the idea again [52]. For PQC authentication, there is one draft defining the integration of PQC signatures into IKEv2 [53]. As they do not need to ride the first, nonfragmentable IKE_SA_INIT exchange, the draft does not need to fundamentally alter the protocol. Alternatively, there is also a proposal for KEM-based authentication in IKEv2 [54] which especially makes use of an ML-KEM ciphertext being significantly smaller than an ML-DSA signature. However, this proposal is even more dependent on a fast and stable way to transmit PQC KEMs in the first place. Another set of proposals is concerned with hybrid key exchanges in the sense of combining cryptography with Quantum Key Distribution (QKD), i.e., using quantum physics to exchange secrets [55, 56]. These proposals, however, come with their own considerations and are outside of the scope of this study. Furthermore, there are several works analyzing specific approaches to integrating PQC key agreement into IKEv2 [4, 57–59] or in specific networking contexts, like 6G [60], automotive [61] or satellite connections [62]. Yet, none of them provides an evaluation of the whole breadth of the current proposals under equal and exhaustive circumstances. Whether new approaches regarding protocol adjustments get standardized or not ultimately depends on the respective IETF working group. Failing to meet their requirements leads to even a theoretically sound proposal remaining theory. Eliot Lear [63] and Welzl et al. [64] investigated the decisive factors for success or failure at the IETF. Their results show that practicality in terms of implementation and deployment is similarly important as measurable properties, like performance or theoretical security properties. This mandates this work to emphasize a holistic discussion about not only measured results but also empirical results regarding implementation and deployment.

5

III. METHODOLOGY

In this section, we detail our research questions including their meaning and how we aim to solve them. Further, we outline how we performed the systematic search for proposals regarding PQC in IKEv2, following the PRISMA 2020 guidelines [65]. Finally, we explain the measurement testbed and methodology used to evaluate the approaches’ performance and network resilience.

TABLE 3. The screening keywords for the IETF document search.

Category

Keywords

Protocol

ikev2, ike_sa_init, ike_auth, ike_intermediate, rfc 7296, ipsec post-quantum, quantum-resistant, kem, ml-kem, kyber, mceliece, frodo, sntrup, hybrid key exchange fragment, large, mtu, packet size, datagram, retransmi, congestion, amplificat, 65535, reliab, transport, compress, hash-and-url, out-of-band

KEM Size

A. RESEARCH QUESTIONS

In this work, we aim to address the following research questions: RQ1: Which protocol adjustments for transmitting or optimizing the transmission of PQC KEM-keys in IKEv2 have been proposed at the IETF? RQ1 examines all proposals for adding potentially large KEMs to IKEv2 via protocol adjustments. We focus on the IETF’s corpus as that is the place where the proposals are discussed and there is no significant hurdle to submitting a draft and be heard by the committee. Also, we focus on genuine protocol adjustments and not implementation optimizations that one party can unilaterally just do. RQ2: Which alternative protocol adjustments can further improve sending PQC KEMs over IKEv2? RQ2 asks for novel approaches that represent alternatives to the proposals found in RQ1. We address this research question by designing three new approaches, one using FEC, one utilizing QUIC features (QUIKE), and QUIKE with a composite key exchange. RQ3: Which performance implications do the different transmission techniques have, especially considering varying networking conditions? RQ3 investigates the performance and resilience to network faults of the approaches of RQ1 and RQ2. For that we implemented all approaches on the same open-source codebase and measured them under the same conditions. RQ4: What are the implications, considering both the performance as well as the implementation costs, for adopting the strategies to real-world VPN implementations and deployments? As discussed in Section II-E, the practicality in terms of both implementation and deployment is decisive for any approach to be considered for standardization. RQ4 takes the results from RQ3, adds the factors regarding the approaches’ implementation, and discusses all those implications, yielding a holistic view on the approaches. B. SYSTEMATIC IETF PROPOSAL SEARCH

The basis for our systematic search of the IETF’s IPsec working group’s document body for PQC integration proposals into IKEv2 consists of the PRISMA 2020 guidelines [65]. They were originally designed for a full systematic review of academic literature. We limited the scope to the respective IETF documents and transferred the guidelines to the new scope. 6

TABLE 4. Inclusion and exclusion criteria for the manual screening.

Code

Type

Criterion

I1 I2

inclusion inclusion

Proposals within official IETF documents Proposals for new protocol adjustments facilitating or optimizing the exchange of larger key agreement payloads over IKEv2

D1

dedupl.

D2

dedupl.

Duplicates of another in-scope document or mechanism Older versions of another in-scope document

E1

exclusion

E2 E3 E4 E5

exclusion exclusion exclusion exclusion

E6 E7

exclusion exclusion

E8 E9

exclusion exclusion

Non-IETF gray literature, i.e., blog posts, websites, RSS feeds, videos, podcasts and webinars Literature that is not available Literature in any language other than English Proposals that focus on QKD rather than PQC Proposals that focus on authentication rather than key agreement Proposals that rely on out-of-band key transmittal Proposals that rely on middleboxes supporting IP fragmentation Mere assessment or analysis of existing proposals Prerequisites for all other proposals, affecting them evenly (e.g., algorithm naming, larger header fields)

The objective is to find all IETF proposals for protocol adjustments to facilitate PQC KEM integration into IKEv2. We see the limitation as sensible, as the IPsec working group is where those are discussed and there is no significant barrier to submitting a respective draft. Hence, we assume any promising candidate potentially published elsewhere is also part of the IETF’s discussion. Adjustments to adjacent protocols, on the other hand, are discussed in Section II-E. For the search, we mirrored a snapshot of the Internet-Draft archive, including active and expired revisions, and RFC series via rsync1 . We scanned the resulting 189 328 documents for the keywords in Table 3, with inclusion requiring at least one hit in each category. Matching is case-insensitive, flattens whitespaces, and does not discriminate between hyphens and spaces. The keywords are comparatively broad and hence prioritize recall over precision. This is a trade-off to minimize the potential for missed proposals. Finally, the automatic selection process removed older revisions of one document, i.e., documents with the same name but a lower version index at the end of their name. For reproducibility, the replication package contains the script for screening, the snapshot timestamp, and the document counts at each stage. 1 rsync.ietf.org::(id-archive)|(rfc); Date: 27.08.2026 VOLUME X, X

TABLE 5. Grid of evaluated KEMs and networking conditions. Every combination of the different factors is tested.

Factor

Invariants

KEM One-way delay (ms) Bandwidth (Mbit/s) Packet loss (%)

ML-KEM-1024, FrodoKEM-1344, Classic McEliece 8192128 50 ± 5, 100 ± 10, 200 ± 20 1, 10, 100 0, 0.1, 0.5, 2, 5, 10

Reorder (%)

5 (fixed condition)

One author screened the entire resulting document set in two passes. In the first pass, they evaluated each document and applied the criteria listed in Table 4. A document is included if every inclusion criterion matches and no deduplication or exclusion criterion does. They first checked the documents’ scope (inclusion), then removed duplicates, and finally applied specific exclusion criteria. They noted the first criterion leading to exclusion and did not evaluate the remaining ones. A second pass then re-read the included documents and those excluded as prerequisites. Each document proposing more than one mechanism was split into one entry per mechanism. We evaluated those individually against the same criteria, and, if excluded, again noted the first failing one. Here, the inclusion criteria reflect RQ1 and deduplication and criteria E1 to E3 are literature review standards. Exclusion criteria E4 and E5 remove proposals for adjacent problems, E6 those that relocate the problem instead of solving it (analogous to the Hash-and-URL mechanism discarded in Section II-E), E7 is meant to catch impractical ones [8], and E8 drops literature proposing nothing new. E9 excludes those mechanisms from the comparison in RQ3 that affect all other proposals equally, and therefore do not need a standalone evaluation. To increase recall, we added a backward snowballing check, adding all IETF documents referenced by the seed set and by the documents proposing included mechanisms. The snowballing also excludes academic literature. Nevertheless, we validated a sample of referenced academic literature, none of which introduced any new mechanism but was background regarding PQC and IKEv2, further justifying our limitation to IETF documents. C. MEASUREMENT APPROACH

To answer RQ3, we first implemented all five approaches found in RQ1 together with our own three from RQ2 and then created a dedicated hardware testbed, in which we can compare the different implementations for PQC KEM integration under various networking conditions. Authentication is not in the scope of this study. Thus, we use static PSK authentication within the test setup. Our evaluation uses three KEMs: ML-KEM [66], FrodoKEM [67], and Classic McEliece [68], all in their largest parameter set classified as Level 5 by NIST [12]. Table 5 lists the evaluated KEMs and network conditions. Reordering is always to be expected when communicating over the Internet [69], so we kept that as a constant 5%. The delay’s jitter also does not further increase VOLUME X, X

the reordering as it is correlated by 90%. For each combination of factors, we measured the following metrics: • The handshake completion rate • The handshake completion time • The number of packets sent per direction The testbed used to perform the evaluation consists of two directly connected, bare-metal Linux hosts with a 7.0.0-30generic kernel on an Intel Xeon E-2236 CPU at 3.40 GHz with 2 × 8 GiB DDR4 RAM. The TCP arms use the kernel’s default CUBIC congestion control and all arms link OpenSSL 3.5.1. This setup grants a stable and fast networking environment. To prevent inflated packet counts on the interfaces, we set static ARP entries on both hosts. Also, both machines use a separate network connection for management and test orchestration. The link speed is 10 Gbit/s and the testbed’s unimpaired RTT stays below 1 ms, negligible against every combination of Table 5. The network emulation tool netem [70] applied the networking conditions to both hosts’ egress interface. Hence, the one-way delays d of Table 5 apply once per direction causing an RTT of about 2d. With hardware offloading (GRO/TSO/GSO/LRO) enabled, the network stack hands netem segments exceeding the MTU. The rate shaper mishandles them, empirically collapsing TCP results while leaving UDP-based ones intact. To keep a fair comparison, we turned off all hardware acceleration. The test setup uses random, uncorrelated loss [70]. Its lower variance increases comparability but depicts realworld loss events less accurately [71]. Testing starts with the controller, which runs on the machine of the initiator, copying each binary and its necessary libraries to the responder, making sure both machines test the exact same implementation. Then, it randomly schedules the order of different configurations to be tested and the, again random, order of implementations for each configuration. Both orders are seeded and therefore reproducible. The test is a systemd service which restarts automatically on reboot or other disruptions. After such an event, the testing continues where it stopped and keeps the initially determined ordering. At the beginning of every configuration, the controller first re-asserts both networking configurations, including addresses, ARP entries, offloading, and netem emulation. Then it creates the respective IKEv2 configurations, including the fixed PSK authentication. With those preconditions met, it starts the IKEv2 process on the responder side which runs until testing has finished for this configuration. To prevent the responder from sending keep-alives for its already completed handshake, inflating packet counts, it has dead peer detection turned off. Finally, it runs the IKEv2 daemon on the initiator side, freshly restarting it for each handshake. The controller attaches to the initiator’s log file, timestamping the exact moment it sends its initial packet and the moment it installs its first child SA. This interval represents the handshake completion time. One run finishes either with this event, which triggers the restart of the initiator, or alternatively any logged failure to perform the handshake, reducing the handshake completion rate. This can be, e.g., due to the maximum number of retries being reached, 7

Algorithm 1 The algorithm running one test configuration and deciding when the number of handshakes n is sufficient. hp and U are the half-width and the upper bound of the Wilson interval for the completion rate, hθ the bootstrap half-width of the median completion time. Require: batch size b=10, nmin =30, nmax =200 Require: targets ϵp =0.03, ϵθ =0.10, decisive bound u=0.20 1: run and discard one warmup handshake 2: s ← 0 // consecutive-check counter 3: n ← 0 // number of performed handshakes 4: repeat 5: run b handshakes 6: n ← n + b, k ← number of successful handshakes 7: θ̂ ← median of the completion time // failures counted as ∞, undefined if k ≤ n/2 8: if U (k, n) ≤ u then 9: m ← true // failing configuration → abort 10: else

11: m ← hp (k, n) ≤ ϵp ∧ θ̂ undefined ∨ hθ ≤ ϵθ θ̂ 12: end if 13: if n < nmin then 14: m ← false // only abort after at least nmin tries 15: end if 16: if m then 17: s←s+1 18: else 19: s←0 20: end if 21: until (m ∧ s ≥ 2) ∨ (n ≥ nmax ) 22: return

or aborting the run after 300 s, which is also the maximum exchange timeout of the IKEv2 implementation we used. After each handshake, the controller extracts the pre-drop packet count of each netem queue, yielding the packets sent for each direction. The number of handshake runs per configuration and approach n is not fixed. Instead, we focus on the test configurations with high variance, granting them more runs and spending less time on the decisive ones. So, n is theoretically in the interval of 40 ≤ n ≤ 200. Its specific number depends on the confidence intervals of both the success rate and the completion time’s median. In almost all configurations, the success rate is usually close to 1. There, a classical confidence interval lacks coverage and we instead use the Wilson score interval. The completion time does not follow a binomial model, hence its confidence interval comes from a percentile bootstrap. Algorithm 1 shows how n is exactly determined. After one discarded warmup handshake, it runs batches of size b = 10. After each batch, it verifies that at least nmin = 30 runs were conducted. Then, the completion criteria m are satisfied if either the configuration is failing decisively, or both confidence intervals are small enough. As soon as m is set for two consecutive batches, or as soon as n reaches nmax , testing finishes for this configuration. Note that because m has 8

TABLE 6. The screening results described in Section III-B and for the criteria as defined in Table 4. The documents come from the first and the mechanisms from the second pass.

Code

Outcome

Documents

Mechanisms

Screened

163

168

I1 I2

Not an IETF document Out of scope

0 127

0 130

In scope

36

38

D1 D2

Duplicate Superseded

0 9

2 9

Individual in scope

27

27

E1 E2 E3 E4 E5 E6 E7 E8 E9

Gray literature Not available Not English QKD rather than PQC Authentication Out-of-band key distribution Relies on middleboxes No new mechanism Prerequisite / even effect

0 0 0 1 11 2 0 0 8

0 0 0 1 11 2 0 0 8

Included

5

5

to be satisfied for two consecutive batches after finishing at least nmin runs, we have at least 40 runs, even though we set nmin = 30. The test and analysis scripts, as well as the complete results, are part of the replication package. These allow reproducing the same test setup. The exact testing order of the different configurations is seeded and thereby also reproducible. Within one configuration all approaches run back-to-back, mitigating testbed drift. However, in case outside disturbances occurred, we pruned the respective results and reran those specific configurations, taking them out of the initially planned order. Also, netem cannot be seeded, which gives statistical reproducibility only. Still, for our values of n, the measurements are expected to yield the same statistical results. IV. PQC IN IKEV2

This section answers RQ1 and RQ2. For RQ1 we present the results of the systematic search outlined in Section III-B and explain the found approaches in detail. For RQ2 we outline our novel approaches and how they differ from the existing ones found in RQ1. A. RESULTS OF THE SYSTEMATIC SEARCH

The automatic search for the keywords from Table 3 yielded 649 documents. After the automatic removal of older revisions, 163 documents were left for manual screening (Table 6). After deduplication, they offered 27 mechanisms related to PQC in IKEv2. Almost half (11) of the mechanisms were concerned with authentication, one with QKD, and two required out-ofband key distribution, leaving 13 actually addressing large PQC KEMs in IKEv2. We classified five of those as genuine new mechanisms for the comparison in RQ3 and eight as either technical prerequisites or optimizations that affect all branches similarly, as shown in Table 7. Only additional VOLUME X, X

Included proposals Additional key exchanges Separate IKE and ESP transports Per-fragment acknowledgment Selective retransmission Composite key exchange (TCP)

RFC WG individual individual individual

[3] [72] [73] [5] [74]

Excluded as prerequisites / even effect (E9) 32-bit payload length Extended payload header Split across adjacent payloads Denser payload encoding

individual individual individual individual

[75] [76] [52] [77]

Excluded as codepoint registrations (E9) ML-KEM FrodoKEM Classic McEliece NTRU

WG WG individual individual

[78] [79] [80] [81]

key exchanges has completed standardization. The drafts for separate transport layers for IKE and ESP and the codepoint registration for ML-KEM and FrodoKEM are adopted by the working group. Every other mechanism is, at the date of the snapshot, an individual draft, highlighting the still active discussion at the IETF. We implemented all included mechanisms and the 32-bit payload length draft to be able to encode a Classic McEliece public key for all other mechanisms. We opted for that one for mere implementation reasons, as none of the three proposals addressing that limit severely affects the transport. Finally, we added codepoints for all KEMs that we tested to our implementations. 1) PQC Prerequisites & Optimizations in IKEv2

A key exchange payload holding DH key shares or KEM public keys and ciphertexts has a header with a length field of 16 bits. This caps a payload, including its header, at 64 KiB. A Classic McEliece public key of ∼ 1.4 MB clearly exceeds this length. The first three proposals excluded by E9 address this gap using different mechanisms. The 32-bit payload length [75] uses one of the header’s reserved bits to indicate that the following payload has a double sized payload length field of 32 bits. Using reserved bits is always controversial but we saw it as the most straightforward implementation. Hence, we implemented this as the prerequisite for all the other proposals to enable their Classic McEliece test case. The other options are defining a new, extended header [76] or splitting one actual payload over several smaller, adjacent ones [52]. The decision about standardizing one of those solutions is up to the working group and not considered further in this study. The fourth mechanism marked as E9 allows to encode the payload header more densely [77]. It is meant for resourceconstrained environments where saving single bytes increases the devices’ availability. The overhead of payload headers is negligible compared to the tested PQC KEMs and the reduction is flat and does not scale with payload length. VOLUME X, X

IKE_SA_INIT

Doc.

IKE_INTERMEDIATE

Status

Header, Parameter Proposal, Keyshare, Nonce Header, Parameter Selection, Keyshare, Nonce

Header, Additional Data Header, Additional Data

Encrypted

Mechanism

Responder

Initiator

IKE_AUTH

TABLE 7. The mechanisms addressing large KEMs in IKEv2 found by the systematic search. Status is the standardization state at the time of the snapshot.

..

Header, Additional Data Header, Additional Data

Header, ID, Child SA Parameter Proposal, Traffic Selectors Header, ID, Child SA Parameter Selection, Traffic Selectors

FIGURE 3. The IKEv2 message flow including the IKE_INTERMEDIATE exchange.

Furthermore, even with that reduction each proposal with every KEM surpasses the fragmentation threshold, keeping the same exchange structure. Thus, we excluded it from further investigation during this study. One prerequisite that is designed with PQC KEMs in mind is the intermediate exchange (IKE_INTERMEDIATE) defined in RFC 9242 [82]. It does not define its interaction with PQC itself which excludes it from the survey but most included mechanisms rely on it as a basis. The intermediate exchange is a new exchange type in IKEv2 that sits between the initial and the authentication exchange. This position allows it to be fragmented, hence, also to carry payloads larger than the MTU. Figure 3 shows the resulting exchange structure of IKEv2. There can be seven intermediate exchanges in one handshake and each exchange is encrypted with the latest round of keying material, i.e., the first uses the key exchanged in the initial exchange. Each of these intermediate rounds costs one additional RTT in terms of performance and speed. Despite the encryption the peers are not yet authenticated, hence, we have to expect any peer to act maliciously during the intermediate exchange. The final prerequisite is the codepoint registrations. Before any IKEv2 implementation can negotiate a PQC KEM, it needs a transform identifier. There exists a draft for all three KEMs we test, as well as one for NTRU which we do not test, but none of them has an assigned identifier yet. Therefore, our implementations use identifiers from the private-use range which are then not interoperable with other implementations but prove the functionality for our tests in RQ3. 2) IETF PQC Proposals in IKEv2

The systematic search found the five approaches we included in our evaluation. The first is the already standardized RFC 9370 [3] allowing the Additional Key Exchanges (ADDKE) shown in Figure 3. It directly builds on the in9

termediate exchanges, allowing one additional key agreement per intermediate exchange, up to seven additional key agreements in total. After each key agreement, there is a new key derivation and the next exchange uses this new key. Hence, an attacker needs to break the different keys in order to be able to decrypt the next key agreement packets. IKEv2’s native fragmentation [8] can apply to intermediate exchanges, enabling the transmission of large KEMs. However, this approach is complex to implement due to the interaction of fragmentation and the handshake signature calculation and IKEv2 fragmentation struggles with large messages over constrained networks [4]. This comes from the retransmission logic described in Section II-A. There are two documents proposing optimizations to IKE fragmentation in the context of ADDKE. They try to improve the fragmentation performance especially under lossy networking conditions by adding transport-like features. The first is selective retransmission [5], referred to as status-ACK below. A peer that received some but not all fragments of a message can report which ones are missing by sending a status message under the same SA. This status message carries the first and the last fragment’s number addressed by this packet. Further, it contains a bit vector over that range, in which a 1 marks a successfully received fragment and a 0 one that is still missing. Upon receiving such a status message, the sender retransmits the missing fragments. This way, the approach reduces the time until loss is detected and at the same time minimizes redundant data on the wire. The status message also contains its own packet number, which the sender must increase with every status message within an exchange. Although the draft mandates no receiver-side check, this number enables detecting replayed status messages, which would otherwise trigger unwanted retransmissions. This approach is not negotiated but just assumed by a supporting peer. Its Integrity Check Value (ICV) is calculated in a way that leads to an unsupporting peer discarding and ignoring the messages. The per-fragment acknowledgment [73], correspondingly notify-ACK, follows a similar idea. Yet, instead of sending status messages, it sends distinct notify types for acknowledging request and response fragments and instead of a bit vector it sends intervals of the still missing packets. The intervals consist of a loss chunk’s first and last fragment number. Upon receiving such a notify, a peer resends all fragments marked as missing. The exact logic for when a peer should send these notifications is weakly defined and up to the implementation. The draft suggests that a responder may wait for retransmitted fragments as proof of packet loss before acknowledging, potentially still taking long to successfully transmit all fragments [73]. Unlike status-ACK, support for this approach is negotiated during the initial exchange. Further, the notify messages carry no message counter, so a receiver cannot detect replayed notifies. Also, it has an open issue with reusing the Authenticated Encryption with Associated Data (AEAD) nonce, which could break both confidentiality and authentication for that SA [73]. 10

The last two approaches both rely on TCP instead of UDP, offloading the transport challenges to a dedicated transport layer instead of selectively implementing transport features inside of the security protocol. Tunneling IPsec including IKEv2 over TCP is already standardized in RFC 9329 [83]. However, that approach is motivated by middleboxes that may block the UDP-based connections. Therefore, it tunnels both IKEv2 and ESP over one TCP connection. The payload data streams may also use TCP which means, in the case of RFC 9329, we might tunnel one TCP connection in another TCP connection. This can have unwanted side effects reducing the performance and availability of the connections [84]. The PQC-motivated drafts, on the other hand, propose only encapsulating the IKEv2 traffic in TCP while the ESP traffic remains on a datagram transport. The first of these two approaches is the separate transports draft [72]. It tunnels IKEv2 in TCP, removing the need for extra fragmentation and separate retransmission logic as TCP handles all these transport challenges. The message flow remains as proposed in RFC 9370 [3], shown in Figure 3, with the only difference being the additional TCP handshake. This can happen either after the initial exchange or before the IKEv2 handshake. The former lets the peers negotiate compatibility over UDP first, while the latter requires prior knowledge of the peer’s support as the handshake otherwise fails silently. The last proposal found in the systematic proposal search is a derivative of the separate transports approach. It uses the same transport layer assignment (IKEv2 over TCP, ESP over UDP) but instead of using intermediate exchanges it puts the PQC KEM into one composite key exchange payload together with the classical one [74]. The message flow therefore falls back to the classic one shown in Figure 1, without any intermediate exchange. Afterwards, both negotiated secret keys need to be combined in a suitable Key Derivation Function (KDF), also considering the KEM binding properties [1]. It removes additional RTTs at the cost of a first message exceeding the MTU. As the MTU limitation mainly comes from UDP-related considerations and secure KEM combiners are well-studied, the authors argue that this is a sensible trade-off and, hence, adjustment to TCP-based IKEv2 [74]. We implemented all five proposals identified in the IETF corpus to evaluate them together with the following novel approaches in terms of performance and resilience. B. FEC IN IKEV2

In the case of stabilizing VPN connections, FEC is used to absorb packet loss. This requires a burst-resistant code as, to a decoder, a lost packet always translates to a whole chunk of missing bytes, hence a burst. Realistically, packet loss also happens in streams, therefore this burst may be very long. The best results require a fitting FEC style that is wellsuited for this special loss pattern. Afterwards we propose an implementation for erasure codings in IKEv2.

VOLUME X, X

1) Choosing an Erasure Coding

Initially, hard resilience hints at a perfect use case for ReedSolomon codes, but they exhibit two major problems. First, their en- and decoding overhead is unattainable at the required throughput speeds of a VPN concentrator, and second, encoding KEM key material larger than 216 bytes is impossible without further complications. This leaves Reed-Solomon codes rather unattractive for this application. Subsequently, there is the consideration between LDPC and turbo codes, as both already compete in a similar domain of wireless data transmission. Still, they differ substantially outside the realm of random bit errors in channels. While LDPC performs exceptionally well in low noise environments [85], it usually struggles in burst scenarios [86]. The situation with turbo codes is more complicated. Shortly after their publication in 1993, new research determined the effectiveness of their interleaver in the case of burst channels [87, 88]. In the context of wireless radio transmission, such channel bursts usually occur in the form of fading channels, where a signal’s properties, such as amplitude or phase, change over time. Xia [89] analyzed turbo codes from a signal processing viewpoint and concluded that turbo codes perform better than conventional codes alone, but mentioned the interleavers’ dispersion of errors entering subsequent decoding steps, which may harm decoding success. As the potential of dealing with burst errors originates from the power of the interleaver, the design itself is not necessarily well-suited for packet loss-style bursts. RaptorQ coding, on the other hand, treats all erasures uniformly, regardless of temporal correlation. This results in missing packets never impacting others. This is a very enticing characteristic, as it enables recovery to be much more predictable and removes structural penalties which may be present in turbo decoding. Because of this predictability, RaptorQ fountain coding allows for the computation of how many encoding symbols are required for a highly successful decoding. This removes guesswork of how much redundant data is required, as the amount is constant for RaptorQ regardless of loss sequence, whereas for turbo codes it is not. Therefore RaptorQ fountain coding was chosen as the best fitting candidate. To encode data, RaptorQ splits up data into source blocks, which are then further split up into source symbols [34]. RaptorQ encoding is applied to each source block individually, which means that each block is able to reconstruct all data within itself. This is beneficial for streams of data, but no tangible gain on singular transmissions emerged, so we chose to use a single source block for each key material transmission. RaptorQ, being a probabilistic encoding, requires a few additional packets to dramatically decrease the chance of failing the decoding step, even if all sent packets are present. To differentiate between technically required overhead symbols and redundant extra symbols, the implementation separates them into two configurable values. Overhead symbols are an absolute additive, whereas extra symbols superimpose a proportional increase. Later, the implementation calculates VOLUME X, X

the total amount of fragments and generates that many encoding symbols accordingly. The remainder of this work uses the terms overhead and extra symbols. To depict either or both redundant symbol kinds, we use the term additional or redundancy packet. RaptorQ is covered by patents. For implementations of standards-track or experimental documents outside wireless wide-area standards, the patent holder has declared that it will not assert them, provided the implementation complies with RFC 6330 [34, 90]. Our implementation uses RaptorQ unmodified, so our use falls within this declaration. 2) Implementing FEC in IKEv2

To integrate the presented FEC into IKEv2, we propose the following adjustments to IKEv2 fragmentation [8]: Negotiation. Endpoints intending to use FEC-enhanced fragmentation should send a notification with the notify payload type of IKEV2_FEC_SUPPORTED. Without any IANA ID assignment of this type, both peers must use a unique and so far unused identifier. Using IKE Fragmentation. If both parties expressed willingness, they must also use FEC in order to prevent initial long timeouts. Message Fragmentation. Before fragmentation, the entire payload stream must be encoded with FEC. The header stays untouched. This results in a list of encoding symbols, each prepended with a small header containing the unique symbol identifier. These symbols are then encrypted, authenticated, and then also prepended with the Encrypted Fragment payload header, as before. Selecting the fragment size must account for that additional header, which may cause more fragments to be transmitted, even without symbol-redundancy. Receiving a Fragmented Message. A receiver identifies each Encrypted Fragment payload as FEC-encoded once both peers have signaled support. Unlike with classical fragmentation, decoding does not require all fragments. After decrypting a payload fragment and validating its authenticity, the content is buffered until reassembly. The number of fragments necessary for decoding depends on the used erasure coding and configuration. As soon as it is met, reassembly is triggered. Each fragment represents an encoded symbol, all of which are fed into the corresponding FEC decoder. The decoded stream is identical to the result of classical IKEv2 fragmentation. If decoding of a probabilistic FEC fails, the assumed number of necessary packets was too small. Newly arriving packets retrigger the reassembly until it succeeds. If there are no additional packets, then the configuration of the erasure coding is incompatible with the lossy channel and must be adjusted. Transport Considerations. When using FEC, single packets can be dropped up to the capability of the erasure coding and its used configuration. We expect a more resilient encoding configuration to be more time efficient than multiple elongated retransmits and timeouts. 11

Symmetric message protection. Both the encryption and the integrity protection from IKEv2 are handled by QUIC’s alternatives in QUIKE. This means that IKEv2 still negotiates the keys but instead of applying them itself, it derives per-level packet-protection secrets and hands those to QUIC. Dead peer detection. QUIC brings its own ping and idle timeout method, replacing IKEv2’s dead peer detection. Anti-DoS cookie. QUIC’s retry obsoletes the cookie mechanism in IKEv2. IKEv2 retransmission. QUIC brings its own loss recovery. IKEv2 fragmentation. Fragmentation happens inside the transport handling of QUIC. TCP encapsulation [83]. QUIC provides a reliable transport layer, removing the need for TCP encapsulation. In addition to the listed mechanisms, the MOBIKE extension [91] used for IP-address roaming of IKEv2 peers can also be replaced by QUIC’s native roaming mechanism but we did not fully specify these interactions. In QUIKE, all symmetric encryption is delegated from IKEv2 to QUIC, hence, we take the full unencrypted IKEv2 packets as the plaintext for QUIC. The encryption keys for QUIC are derived from seeds computed by IKEv2 during its normal key derivation step. The derivation of these seeds for QUIC replaces the derivation of the keys for symmetric encryption and integrity protection in IKEv2’s key schedule. The authentication keys and the IKE_AUTH in IKEv2 are untouched by QUIKE as only the symmetric encryption is delegated to QUIC. The encryption keys for QUIC’s initial level are computed exactly as in QUIC with TLS 1.3 with the only exception of changing a static KDF label from ‘‘tls13 ’’ to ‘‘ikev2 ’’. QUIC uses a TLS extension to transmit its transport parameters which is missing in QUIKE. Thus, in QUIKE we add a new QUIC_TRANSPORT_PARAMS notify message to the initial exchange. That placement automatically includes it in the authenticated transcript, ensuring its authenticity after IKE_AUTH finished. 12

Responder

Header, Selection, Keyshare, Nonce, Transport Parameters

Header, PQC Keyshare

Header, ID, Child SA Parameter Proposal, Traffic Selectors Header, ID, Child SA Parameter Selection, Traffic Selectors

1-RTT

Header, PQC Keyshare

Handshake

Initial

Header, Proposal, Keyshare, Nonce, Transport Parameters

Confidential

IKE_SA_INIT

Initiator

IKE_INTERMEDIATE

The FEC-based approach adds redundancy to the UDP-based messages, decreasing the likelihood of retransmissions being necessary. Most previous proposals, on the other hand, aim at improving the retransmission mechanism, either by optimizing IKEv2’s native one or by mounting it on top of TCP as a reliable transport channel. One drawback of TCP is that it adds another RTT before the actual handshake. Instead of TCP, we propose to use the newer QUIC protocol as the reliable transport for only the handshake, resulting in QUIKE — QUIC using IKEv2. As described in Section II-D, QUIC leaves the slot for its cryptographic handshake open rather than mandating TLS 1.3, allowing us to fill it with IKEv2. In contrast to TCP which is limited to providing transport features, QUIC requires deeper integration as it brings mechanisms which were originally part of IKEv2. So, QUIC subsumes the following IKEv2 mechanisms in QUIKE:

IKE_AUTH

C. QUIKE — QUIC USING IKEV2

FIGURE 4. The message flow of two-round QUIKE, with the IKEv2 exchanges on the left and the corresponding QUIC levels on the right.

Analogous to IPsec over TCP [83] and the composite TCP draft [74], there is no legacy discovery. The first packet is already a QUIC initial packet and an unsupporting peer discards it without recovery. So both peers must support QUIKE and activate it in their configuration. Further, QUIKE inherits QUIC’s requirement that the path carries 1200-byte datagrams, making it unusable on paths below that floor. Unlike an HTTP/3 deployment, QUIKE carries no payload traffic inside the QUIC connection. After completing the handshake, we install the ESP SAs into the kernel and the ESP traffic flows outside of it—just like in classic IPsec. Hence, QUIC serves only as the transport for the handshake. We propose two different approaches for the actual message flow, analogous to the two different TCP-based drafts (cf. Section IV-A2): the two-round approach spends one RTT per key agreement, as the additional key exchanges do, while the composite one carries both shares in a single key exchange payload, as the composite draft does. Which of the two variants applies is negotiated implicitly, by selecting either separate key exchange algorithms or a single, potentially composite identifier, as with the TCP proposals. 1) Two-Round QUIKE

The two-round QUIKE resembles the structure shown in Figure 3 but has exactly one intermediate exchange. This limits the amount of additional KEMs to one. We assume that this protocol simplification’s complexity reduction justifies limiting the number of chained key agreements. Thus, each of the IKEv2 exchanges maps to one QUIC level, as portrayed by Figure 4. In contrast to IKEv2, already the first exchange is technically encrypted but it only provides obfuscation, no confidentiality. The QUIC initial level carries the IKE_SA_INIT including the small classical key exchange. It additionally contains QUIC’s transport parameters in the respective notify. Thereafter, the first symmetric keys are derived and fed to QUIC’s key ratchet. The intermediate exchange rides QUIC’s VOLUME X, X

Responder

Header, Selection, Composite Keyshare, Nonce, Transport Parameters

Header, ID, Child SA Parameter Proposal, Traffic Selectors Header, ID, Child SA Parameter Selection, Traffic Selectors

Handshake

Initial

Header, Proposal, Composite Keyshare, Nonce, Transport Parameters

Confidential

IKE_AUTH

IKE_SA_INIT

Initiator

FIGURE 5. The message flow of composite QUIKE. The composite key exchange contains both key shares, so IKE_AUTH moves to the handshake level, completing it before 1-RTT.

handshake level, containing the large PQC KEM data. The peers use the exchanged secret to update the symmetric keys, providing QUIC with a new per-direction pair of domainseparated, quantum-secure keys which protect the subsequent messages. Finally, the 1-RTT level carries the IKE_AUTH message, authenticating the whole transcript. Further IKEv2 messages, like CREATE_CHILD_SA exchanges, also run inside 1-RTT. The actual child SAs, on the other hand, go into the kernel, allowing ESP traffic as in classic IPsec. The alignment of QUIC’s and IKEv2’s levels/exchanges and key generations allows an easier integration. Furthermore, QUIC’s initial level faces several constraints to impede amplification attacks (cf. Section II-D). Thus, the large PQC KEM avoids those by riding the handshake level. The RTTs represent those of the separate transports proposal [72] but without the preceding TCP handshake. 2) Composite QUIKE

Without the size constraint in IKE_SA_INIT (cf. Section II-A), removing the intermediate exchange and putting the PQC KEM into the first exchange within a composite construct saves one additional RTT. Figure 5 shows the resulting structure which resembles the one of classic IKEv2 shown in Figure 1 and the one of classic QUIC in conjunction with TLS [37]. IKE_AUTH rides QUIC’s handshake level. As the PQC KEM already finished, it is protected with quantumsecure keys. Despite including no message on the 1-RTT level during the handshake, 1-RTT is still necessary for later exchanges, like creating new child SAs. From the trade-off it resembles the one of the composite TCP proposal [74]: We spare an RTT for a larger initial exchange. However, QUIC’s constraints regarding its first messages (cf. Section II-D) may reduce the performance gain of this approach. Under load a responder might then be even more likely to demand a retry, re-introducing the saved RTT. Hence, the performance gain could be more visible with smaller KEMs where the RTTs still cost most of the time and could erode with large KEMs where the initial level’s constraints are more expensive.

V. EVALUATION

To answer RQ3 and RQ4, we evaluate the different approaches within the test environment described in Section III-C. Furthermore, we collect findings from the implementation regarding its overall complexity, the gap to the current codebase, and missing considerations within some early drafts necessary for a subsequent holistic discussion. In this section, we first describe the implementations, respective design choices, and practical challenges in detail, before moving on to the measurement results and their implications. A. IMPLEMENTATION

For our implementation we used the openiked-portable2 , which is a port of the openiked of the OpenBSD project3 to other operating systems, such as Linux4 . We implemented all drafts on top of the commit 4a71216cf3c6372a13451574d0ceb85c892e7376, which at the time of starting this work was the most recent commit. We used one branch per proposed mechanism but shared the commits for shared prerequisites, keeping the implementations of the different approaches as close and comparable as possible. One prerequisite for all branches is the encoding of Classic McEliece’s large public keys which exceed the maximum length addressable by an IKEv2 payload header (cf. Section IV-A1). Of the three current proposals, we implemented the 32-bit payload length draft using one reserved bit [75]. As this approach is not yet standardized, it does not yet have a status type identifier. We chose one from the private-use range to allow negotiating it with supporting peers. The first branch is the already standardized ADDKE [3] together with the intermediate exchange [82] which are also the basis for all later approaches except for the composite ones. Its standardization is already completed which gives a welldefined specification, easing implementation. Additionally, we added the codepoints for the KEMs from the private-userange. However, in line with previous analysis [4], signing a fragmented intermediate exchange requires complex code changes. The reason for this is the requirement that the receiver must sign the exchange as if it was not fragmented which means it needs to reconstruct the message without any fragmentation artifacts instead of immediately processing it, contradicting existing implementation flows. The next branches are the two retransmission optimizations [5, 73]. Both drafts leave design decisions to the implementer, especially regarding the exact definition of when to send their form of acknowledgment. Table 8 shows our choices for those gaps. For status-ACK, a receiver sends a status message once no new fragment of an incomplete message arrived for a quiet period of 500 ms, just above the largest RTT of our grid, and repeats it every 500 ms while fragments are missing. On a path whose RTT exceeds that period, it sends acknowledgments before a response can arrive, causing 2 https://github.com/openiked/openiked-portable [Accessed: 28.09.2026] 3 https://www.openbsd.org/ [Accessed: 28.09.2026] 4 https://www.linux.org/ [Accessed: 28.09.2026]

VOLUME X, X

13

TABLE 8. Open design choices of both acknowledgment proposals [5, 73].

Decision

Our choice

Consequence

Trigger (status-ACK)

A quiet period of 500 ms (above RTT), then every 500 ms

Below the RTT it triggers prematurely, far above it is slow

Reordering (status-ACK)

The same quiet period after reordering

A late straggler causes a premature trigger

Trigger After receiving a retransmit(notify-ACK) ted fragment

Waits for a retransmission; fragments still in flight count as missing

Regular retransmit

ACKs restart its timer

ACKs without progress defer give-up until an absolute deadline

Key retention

Retain the previous IKE SA keys

Required to decrypt ACKs

redundant retransmissions. For notify-ACK, we follow the draft’s conservative suggestion and only acknowledge after receiving a retransmitted fragment. Neither draft specifies how acknowledgments interact with the classical retransmission mechanism following an exponential backoff timer. In our implementation, an acknowledgment restarts that timer and for status-ACK lets the sender drop acknowledged fragments from its retransmission queue. Implementing both drafts further revealed two gaps that neither addresses. First, previous-key retention: in ADDKE, the initiator can only derive the next IKE SA keys after receiving the complete response [3, 82], so its acknowledgments for missing response fragments are still protected with the previous keys, which the responder thus has to retain beyond its own key update. Second, neither draft defines how acknowledgments affect the retransmission limit. If an acknowledgment restarts the retransmission timer, acknowledgments without progress keep the initiator from giving up until an absolute handshake deadline, which RFC 7296 does not mandate [2]. If acknowledgments are sent periodically and some fragments cannot reach the peer at all, this can even happen with honest peers. The FEC approach utilized RaptorQ fountain codes, as described in RFC 6330 [34]. For implementation, the opensource library nanorq5 was used which allows for easy enand decoding of IKE_INTERMEDIATE messages. Plain fragments act as source symbols to the encoder, producing many encoding symbols, which are sent over the wire instead of plain message fragments. The encoder outputs a total of s + o + e symbols, where s is the number of source symbols, o is the fixed number of overhead packets needed due to the probabilistic design of fountain codes, and e is the number of extra packets always taken as a fraction of s, adding redundant symbols acting as the resilience cushion. Decoding starts as soon as at least s + o encoding symbols arrive, to maximize the likelihood of success. The test environment used 5 overhead and 10% extra packets. 5 https://github.com/sleepybishop/nanorq [Accessed: 02.10.2026]

14

It is important to note that the redundancy only protects the message itself. If the first fragment is lost in transmission, the exchange cannot proceed as it contains information about the inner IKEv2 payload type. This inner payload type is required to tell the IKEv2 message parser the payload type of the first following payload. Each payload carries this information for the following one. This means a successful decoding of the actual payload stream is irrelevant for further processing if the type of payload cannot be determined. Adding payload type information to every fragment would violate RFC 7383 [8]. The two TCP-based proposals rely on the kernel’s TCP implementation which provides a robust transport of the messages. Hence, with TCP we never use IKEv2 fragmentation. TCP provides reliability but requires the application to manage its connection state and control its flows: the connection management, the mapping to the respective SAs, a handler for partial writes caused by full TCP write buffers, an accumulator reassembling the byte stream into IKEv2 messages, a TCP accept handler, and a watchdog for connections without an SA are left to the IKEv2 implementation. Additionally, we added a necessary stream prefix and additional message length field of RFC 9329 [83]. The composite approach further needs new identifiers for the composite key exchange, including its implementation and combiner. The other one requires the ADDKE logic including intermediate exchanges but without fragmentation, easing their implementation. Our implementations do not include negotiation (like proposed by the separate transports draft [72]) but assume all peers begin their handshake over TCP. To implement the QUIKE proposals, we first introduced the QUIC library ngtcp2 1.24.06 which has a comparatively loose coupling of QUIC and TLS, easing the IKEv2 integration. However, to make it compatible with our tests, we had to adjust four of its limits. The adjustments include raising the maximum size of the initial (composite QUIKE) and handshake level (two-round QUIKE), as well as the maximum reordering gap, all necessary to carry a Classic McEliece public key. None of these is mandated by the standard but chosen by the library, avoiding deviations from QUIC’s specification [6]. The fourth change is motivated by FrodoKEM and enlarges the initial congestion window to 30 datagrams. This allows the peers to send exactly one full FrodoKEM message in one flight, without waiting for the peer’s acknowledgment of the first packets, saving one unnecessary RTT. It deviates from a specification’s SHOULD [36] which proposes ten datagrams, based on RFC 6928 [92]. RFC 6928 recommends this window size based on measurements with applications aggressively opening concurrent connections causing congestion. The VPN usually initiates exactly one and still has more congestion control than the UDP-based approaches, legitimizing this change. In addition to the adjustments, we also fixed one ngtcp2 bug where lost ping messages could congest a sendqueue. Merging the fix upstream is future work. 6 https://github.com/ngtcp2/ngtcp2 [Accessed: 29.09.2026] VOLUME X, X

duration [s], log scale

16 8 4 2 1 0.5

E K K DK y-AC s-AC u AD t tif a o n st

FE

C

P E -c -c IK TC TCP KE QU QUI

FIGURE 6. Logarithmically ordered completion times of the FrodoKEM measurements over a 10 Mbit/s link at 100 ms one-way delay and 2% packet loss. Each implementation has between 80 and 200 runs, and -c marks the composite variants. Violin plots for adjacent configurations are in Appendix A.

For the QUIC integration we took the patched library and added an interface module. It gets the plain text messages and domain separated keys from IKEv2 to encapsulate them in the QUIC messages and transmit those reliably, or, on the receive path, hand IKEv2 the decrypted IKEv2 messages. Both the QUIC implementation and the interface module could theoretically live inside a separate process which then only sees its own keys but not the other domain separated ones for authentication or the ESP SAs. This would harden the implementation as it shields openiked from the large amount of new code. However, in our testing implementation we kept all modules in the openiked process, deferring that separation to future work. B. RESULTS

The tests for answering RQ3 span, for the matrix of different mechanisms, KEMs, and network parameters, 1296 different measured configurations. For each configuration, we measured between 80 and 200 handshakes, depending on their decisiveness regarding completion rate and duration. Even though we set the minimum number of runs in our testbed to 40, no configuration was decisive enough after fewer than 80 runs. 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. 76 of them happened in Classic McEliece, 24 in FrodoKEM, and 1 in ML-KEM. Our replication package contains the exact data for all runs [93]. Before calculating further statistics, we need to inspect each approach’s data structure, as it varies significantly. Figure 6 shows the distribution of handshake times on a logarithmic scale for one medium-network, medium-loss FrodoKEM configuration. Other configurations and KEMs exhibit a similar structure, as shown in the figures of Appendix A. The first clear observation regarding the data structure is that the results land in discrete plateaus, with the transport-based approaches having significantly more stragglers between plateaus and VOLUME X, X

the plateaus being closer together. The reason for that lies in the retransmission logic. Basic RFC 7383 [8] sends all fragments of a message and, receiving no answer, retransmits all of them after a blind timer that doubles with every attempt. A run’s duration is therefore roughly its loss-free duration plus a sum of those intervals, and which sum it lands on depends on two independent counts: how often a single message had to be retried, and how many different messages were hit at all. Losing several fragments of one flight still costs a single retry of 2 seconds, whereas losing one fragment in each of two messages costs a retry for each, and a retransmission that is hit again costs 2 + 4 seconds. The same logic applies to FEC. There, the first message is larger and slower but its redundancy prevents retransmissions. Hence, its plateau is a bit later but it almost never needs retransmission. The other two datagram approaches follow a similar logic until their own acknowledgment-based logic takes over, with the status-ACK doing so more aggressively as it already sends its acknowledgment after not receiving any more fragments for 500 ms (cf. Table 8) while the notify-ACK sends it only after getting the first retransmission. The transport-based approaches, on the other hand, react immediately to loss, hence the clusters’ distance comes from the RTT. More loss causes more RTTs until completion. For FrodoKEM, we can further see that the adjusted initial window size of QUIKE (cf. Section V-A) saves another RTT in comparison to TCP. This distribution discourages the use of percentile-based metrics, like the median, for the comparison. The median and its confidence are still well-suited to determine clear configurations, usually with low loss. Yet in a comparison, such a value could lie just at the bottom of a cluster and just at the top for another approach, making them falsely look equal. At the same time, it could be apart by a factor of two between two almost equally fast approaches. Instead, in the following we use the mean as the stronger indicator for an approach’s performance. There, failed runs could potentially distort the results as we exclude them from the mean, biasing for quicker run times in low-success configurations. However, the low overall failure rate confines this issue to only a few data points. Further, the mean duration of low-success configurations is also especially high. Thus, this does not affect any deductions. Appendix C contains all means and their respective cell’s failure rate for deeper scrutiny. From the different approaches’ structure and their means, we can make the following deductions: Datagram & Transport. The approaches split into the two classes of datagram- and transport-based ones. Latency & Loss. A higher latency mostly affects the lossrecovery of the transport-based approaches, while the others’ mechanisms depend mainly on their own timers. Latency & Bandwidth. 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. 15

ADDKE

notify-ACK

mlkem1024

status-ACK

FEC

TCP-c

QUIKE

QUIKE-c

frodokem1344

17.5

4

mean handshake duration [s]

TCP

15.0 12.5

3

10.0 2

7.5 5.0

1 0

2.5

0

0.1

0.5

2

packet loss [%]

5

10

0.0

0

0.1

0.5

2

packet loss [%]

5

10

FIGURE 7. Mean handshake duration across all bandwidths and latencies against packet loss for ML-KEM and FrodoKEM. Solid lines depict datagram-based approaches, dashed lines transport-based ones. Lines connect the measured loss levels and are not interpolation.

Loss & Congestion. Datagram-based approaches do not control any congestion. Transport-based ones interpret loss as congestion, sometimes unnecessarily limiting their own bandwidth. Loss Position. Loss spread over multiple IKEv2 messages costs more than the same amount confined to one. For the transport-based ones, early congestion events have more subsequent fragments to hamper than later ones. KEM Size. Across configurations, the KEM size is a stronger factor than the approach. 1) ML-KEM and FrodoKEM

All results for ML-KEM and FrodoKEM follow a similar structure, depicted in Figure 7. The data shown in Figure 7 is computed in two steps: first, we compute the mean handshake duration for each configuration (cf. Table 5), and second, for each combination of KEM and network loss we compute the mean of the mean handshake durations across all latencies and bandwidths. Nesting means gives each of the pooled means equal weight despite differing amounts of runs. Still, the different network configurations produce varying durations, which Appendix C shows in Figure 15. The data shows that with lower loss, the amount of necessary RTTs dominates the handshake duration. All datagram-based approaches fare equally in that scenario with also the additional overhead of FEC having no significant impact. TCP keeps the additional RTT for the IKE_INTERMEDIATE and adds the TCP handshake, slowing it down. For FrodoKEM, both TCP variants pay another RTT as it is limited by the kernel’s initial congestion window whereas QUIKE is optimized to fit exactly one FrodoKEM message, setting those two families apart. 16

TCP-composite eliminates the intermediate RTT. QUIKE still has it but QUIKE-composite spares all of them, making it the fastest approach across configurations. With increasing loss, the transport-based approaches overall cope significantly better than almost all datagram-based ones. The only exception is FEC for FrodoKEM, where its redundancy absorbs most loss until 5%. Only afterwards its slow retransmission logic bites. This is due to FEC’s redundancy being a fixed fraction of the message—10% in our testbed—so it only covers the losses reliably as long as the margin between the experienced loss and the added redundancy is big enough. With ML-KEM in contrast, there is only a single redundant packet because of the smaller message sizes, which a second loss already defeats, making its performance significantly worse there. The remaining three datagram approaches behave consistently under higher loss. The basic ADDKE one struggles most, notify-ACK’s effect only shows significantly for FrodoKEM under high loss, and status-ACK is overall closest to the transport-based ones. 2) Classic McEliece

The Classic McEliece results differ from the previous ones as network congestion or mechanisms to avoid it influence them. This impact changes significantly between the 1 and 10 Mbit/s measurements. Figure 8 shows the mean over the means of the different latencies for each loss configuration and the two bandwidths. For the smaller bandwidth, no datagram-based approach manages to be significantly faster than 40 s. At this bandwidth, serializing one Classic McEliece public key alone takes about 11 seconds. Their blind, exponential retransmission timer therefore expires twice while the first copy still VOLUME X, X

ADDKE

notify-ACK

1 Mbit/s

70

status-ACK

FEC

TCP

TCP-c

QUIKE

QUIKE-c

10 Mbit/s

mean handshake duration [s]

60 50 40 30 20 10 0

0

0.1

0.5

2

packet loss [%]

5

10

0

0.1

0.5

2

packet loss [%]

5

10

FIGURE 8. Mean of the per-latency means of the handshake durations at a given packet loss for Classic McEliece at 1 and 10 Mbit/s. The exact crossing point of the transport- and the datagram-based approaches for 1 Mbit/s depends on the latency. Appendix C shows the complete grid.

drains, sending the flight three times over and congesting the path. The subsequent authentication message needs to wait until the link is free again. FEC takes even longer as with every retransmission it also resends its redundancy packets. The loss, on the other hand, has less effect, as the biggest message is retransmitted several times anyway, reducing the probability of further retransmissions being necessary. FEC’s redundancy, again, absorbs the loss up to 5%, whereas the acknowledgment-based proposals degrade throughout while still staying significantly ahead of ADDKE. Here FEC’s fixed fraction works in its favor: roughly 3000 fragments carry close to 300 redundant symbols against an expected 150 losses at 5%, so it only breaks down at 10% once the expected losses are roughly the same as the number of redundant symbols. As soon as the bandwidth suffices to transmit every message before any blind timer triggers, the congestion events vanish and the datagram-based approaches’ duration collapses. The transport approaches avoid congestion entirely as they have integrated congestion control mechanisms. Yet, at low bandwidth and no loss, their initial congestion control window is still small, limiting the first messages, costing RTTs. A lower latency shortens the RTTs, reducing the initial window’s impact on duration. They, however, interpret higher loss as congestion and, in response, limit their sending speed significantly. In detail, they reduce the window size, which means they need to wait more often for acknowledgments. High latency increases these waiting times, further exacerbating the problem. This follows the Mathis model, which predicts a throughput √ proportional to MSS /(RTT p) for a Maximum Segment Size (MSS) and a loss probability p [94], so the durations at high loss and latency are congestion control working as VOLUME X, X

specified. As this slowdown scales with the RTT, the durations of the transport-based approaches diverge strongly across latencies at high loss whereas the datagram-based ones stay almost constant. The pooled mean therefore represents none of the latencies well and, at 1 Mbit/s, hides that the transportbased approaches are the fastest at low latency. The latencyspecific durations cross the datagram-based approaches at different points and are shown in Appendix C. Moreover, the means of the high-loss, high-latency TCP configurations are biased downward, as these configurations produced the highest share of failed handshakes, 62 of Classic McEliece’s 76, which are excluded from the mean. In contrast to the actual congestion events of the datagram-based approaches, the rate-limiting by congestion control is purely loss-driven and, therefore, independent of the actual bandwidth. The amount of transmitted packets also shows the congestion. Figure 9 shows the ratio of the packets actually sent by the initiator divided by the minimum number of packets for that approach, without loss and without congestion. So it shows how the environment changes the packet count, not fixed overhead, like FEC overhead or static padding for transport frames (cf. Section V-A). With Classic McEliece and 1 Mbit/s, all datagram-based approaches retransmit at least two times, even without loss, making them start at factor three already. As soon as the link is broad enough to avoid congestion, their structure reflects the one of the duration; hence, a slower approach is also less efficient. This also resembles the efficiency of the other two KEMs. So, without congestion and across KEMs, basic ADDKE’s primitive logic copes the worst with difficult conditions. Notify-ACK mostly follows second; a faster link even weakens its efficiency as its 17

ADDKE notify-ACK

status-ACK FEC

TCP TCP-c

QUIKE QUIKE-c

Composite TCP

packets sent / loss-free minimum

mceliece8192128, 1 Mbit/s 4

P1 KEM codepoints

TCP Stack

TCP

QUIC

QUIKE

2

P2 Large payloads

ADDKE

FEC

RaptorQ

notify-ACK

0

P3 Intermediate exchange

mceliece8192128, 10 Mbit/s 4

status-ACK

FIGURE 10. The dependencies of the different approaches. ADDKE is both an approach and a prerequisite for others. Yellow approaches are datagram-based, blue ones transport-based. External dependencies are shown in red, with a dashed arrow marking kernel-based ones.

2 0

0

0.1

0.5

2

packet loss [%]

5

10

FIGURE 9. Packets the initiator sends for Classic McEliece, each approach relative to itself on an uncongested loss-free path. Appendix B shows the same information for ML-KEM and FrodoKEM.

more cautious notify mechanism is then too slow to reduce the amount of sent packets. FEC’s redundancy absorbs loss until a predictable threshold, dependent on its configuration; and status-ACK’s aggressive mechanism and queue-pruning are most successful at preventing redundant retransmissions. While the transport approaches for McEliece slow down significantly under heavy loss, their efficiency remains almost unchanged. This observation is stable across bandwidths and latencies. Congestion control prevents overloading a link but is sometimes too cautious after observing losses, costing RTTs but preventing redundant transmissions. Also this observation is in line with the other KEMs (cf. Appendix B), where increases in duration are also caused by the initiator waiting for acknowledgments, never redundant retransmissions. VI. DISCUSSION

In this section, we build on the results of Section V, put them into perspective and then provide answers to RQ4. To do so, we first lay out how the approaches depend on each other and what implementing them costs. Then, we regard the state of Classic McEliece integration. Further, we consider the situation for the other KEMs and what it means for research, standardization, and especially implementation. Finally, we outline important trajectories for future work. The results in Section V-B show that for each KEM’s size regime, the approaches significantly differ in performance and resilience. However, the main factor remains the KEM size itself. Thus, analyzing the risk and determining which KEM size should be supported is the first step. Afterwards, the path of standardization and implementation needs to be decided, optimized for exactly this choice of KEMs.

18

Composite QUIKE

A. APPROACH STRUCTURE AND IMPLEMENTATION COST

Figure 10 shows the dependencies between the approaches. Every approach requires P1 and P2, yet P2 is only necessary for Classic McEliece-sized keys. P3 is the foundation for ADDKE which, in turn, is a prerequisite for every non-composite approach. This is especially important as ADDKE and P3 together are, considering lines of code, the biggest change with 2545 or 3122 lines considering all prerequisites, with most located within existing modules. The second largest change is composite QUIKE with 1700 (alone) or 2277 (including P1/2) lines, and the largest share put into separate modules. TCP is smaller but its changes are again more intertwined with existing software. Every non-composite approach then has a smaller footprint on its own but that is on top of ADDKE. Those numbers give an intuition about the implementations’ intrusiveness but do not necessarily reflect their complexity. E.g., signing fragmented intermediate exchanges was an especially complex task without needing much code. They also do not consider conceptual challenges, like unfinished standardization, previous-key retention, or delegating confidentiality to a different protocol. Replacing existing parts with external dependencies, on the one hand, leads to large and complex changes but, on the other hand, might make the final design simpler overall. Further, the external dependencies, like the whole QUIC stack, can introduce large pieces of software with their own security flaws, potentially degrading the overall security. Hence, integration requires thorough evaluation. TCP is less critical as the kernel provides it already. B. CLASSIC MCELIECE

While Classic McEliece is currently not considered as a widespread solution for ephemeral KEMs (cf. Section II-B), it still demonstrates the maturity of an approach, should KEM sizes overall increase into that size regime. Our results shown in Section V-B make clear that, as soon as the network conditions worsen, every approach either took over a minute for one handshake on average, or congested the network, practically denying service to any other device using that link. We consider none of these operationally acceptable. Hence, right now such large KEMs are only suitable for specific VOLUME X, X

use cases where the network conditions are stable, e.g., on a dedicated, high-performance layer two network [57]. Apart from that, further research needs to find ways to, either, prevent the congestion for the datagram-based approaches, or soften the effect of the transport-based approaches’ slow start and congestion control, both without introducing new caveats. C. TWO PATHS FOR ML-KEM AND FRODOKEM

For the other two KEMs there are two fundamental paths for implementations to follow: Established Path. This represents the compatible option. It builds on the already standardized ADDKE, allows stepwise optimization, and upholds backwards compatibility but pays in capability and a more patchwork design. New Transport. This delegates reliability, congestion control, and, with QUIKE, framing and packet protection. Its best variant, composite QUIKE, is always at least as fast as any datagram-based approach, but it introduces new dependencies and currently lacks standardization. Taking the established path adds heavy machinery that is usually part of transport protocols. However, it builds on an already standardized base, reusing the same foundation of classic IKEv2 and reducing friction by, e.g., allowing backwards compatibility, keeping testing infrastructure, firewall rule sets, etc. Further, it allows step-wise adoption: For ML-KEM, ADDKE’s performance might still be deemed acceptable. We show that further optimizations significantly improve performance under more challenging network conditions. We deem this helpful for ML-KEM and mandatory for FrodoKEMsized keys. The optimizations include: Status-ACK. This approach adds an acknowledgment mechanism based on status messages. The implementation does not add significant hurdles to ADDKE and the results show a strong performance increase compared to ADDKE under worsening networking conditions. Additionally, its explicit receipt bitmap allows pruning retransmit queues, making retransmits more efficient and adding less redundant traffic. It is still in the early standardization phase and its security considerations address neither the mandatory previous-key retention nor the retransmission limit (cf. Section V-A). The former means a responder still accepts acknowledgments protected only by the classical IKE_SA_INIT keys after the first PQC key exchange, the latter lets a malicious peer delay the initiator’s give-up. Notify-ACK. This approach falls into the same class as statusACK but is generally slower and less efficient, and it shares both gaps. Additionally, its notifies carry no message counter, so an on-path attacker can replay them, each time making the initiator resend request fragments, which IKEv2 initiators otherwise only do on timeout. Also, there is an open issue with nonce reuse, breaking confidentiality and authenticity for that SA. In conclusion, we see the status-ACK proposal as overall the better alternative for this kind of optimization approach. VOLUME X, X

FEC. Instead of optimizing retransmission, FEC tries to prevent it in the first place. It does not provide the same benefit as status-ACK for small KEMs but mostly fares better for FrodoKEM. It has the simplest mechanic of all approaches (not considering preconditions) and fewer protocol interactions but an additional dependency. For a software project willing to accept the additional dependency, this is a relatively cheap optimization for ADDKE with medium-sized KEMs. An implementation choosing continuity over maximum performance chooses this datagram-based path. It first adds ADDKE and then, if necessary, optimizes it with a finalized version of status-ACK or FEC (for FrodoKEM or similar KEMs). Further, both mechanisms are not mutually exclusive. So, even combining them is plausible with the aim to both reduce the chance of retransmissions and make them more efficient and effective where they are still necessary. The transport path is the alternative way of moving forward. It critically changes core design choices for IKEv2, instead of working around them. The result is an overall leaner design with clearer delegations and better performance but at the cost of continuity. The four variants split into composite or two-round and TCP or QUIKE. When choosing between them, our results give a clear picture regarding the first choice: Composite constitutes a significantly smaller change (cf. Section VI-A) and performs better. Choosing between (composite) TCP and QUIKE is less clear. In general, QUIKE resembles the more extreme variant. It changes the protocol more fundamentally, delegates more to the new transport, introduces a new external dependency, and, due to its novelty, lacks standardization. That shows in the change size: its implementation is larger, albeit more localized to its module which is the interface between IKEv2 and QUIC, while TCP is smaller but more distributed throughout the codebase. Additionally, QUIC’s retry token and its cap on what a peer may send to an unvalidated address represent the most advanced version of pre-authenticated DoS protection. Our implementation includes a bug fix of the introduced QUIC stack, highlighting the maturity risk of such a dependency. However, the clear separation between QUIC and IKEv2 theoretically allows to put both implementations into separate processes, where the QUIC process only ever sees its own domain-separated keying material, not the other keys used for authentication and protecting the application data. Hence, such an implementation could limit the potential damage by a vulnerable QUIC stack. In summary, there are two main pathways: Step-by-step working around design decisions aimed towards small, classical DH shares but keeping continuity regarding implementations, test setups, firewall rule sets, and backwards compatibility with existing setups; or, radically changing those design decisions to match the current context but causing disruption. TCP, thereby, resembles the less radical of the two variants. Nevertheless, we deem the advantages of the novel QUIKE worth the little increase in disruption, compared to TCP. Implementers, however, need clear specifications, 19

which to date leaves ADDKE as the only viable option, despite its weaker performance. So the IETF must either decide between them or standardize both pathways, allowing the implementations their own choice. VII. THREATS TO VALIDITY

In this section, we discuss potential threats to the validity of our study and how we mitigated them. Its structure adheres to the categories of Ampatzoglou et al. [95]: study selection validity, data validity, and research validity. Our systematic proposal search described in Section III-B focuses only on IETF drafts present in the IETF corpus’ snapshot. We could miss pure academic work. Also the snowballing only included RFCs and drafts, even excluding IETF documents with deviating draft citation tags. Yet, we only found two IETF documents excluded by the snowballing and they were already in the screened set. Also a manually checked sample of the referenced academic literature did not yield any new proposals but foundational work and analyses. We only had a single screener which we mitigated by applying criteria fixed before screening and publishing the complete decision record. The data validity depends on our implementations of the current Internet-Draft states and their tuning. Errors there could limit specific drafts. We set timers and windows to values trying to optimize each mechanism while keeping operational feasibility (e.g., a 500 ms timer for acknowledgment for a 400 ms RTT). Our test harness uses netem with random, uncorrelated loss. The random loss has less statistical variance which makes the results more stable and comparable but real loss often occurs in bursts [71]. Also we record netem’s packet counter but not its byte counter. Hence, different packet sizes or padding fluctuations could distort the efficiency results. In response, we only compared each arm against its normalized best case, mitigating the effect of differing packet sizes. Different padding might still affect the results. Further, we focused on key agreement and, hence, used PSK authentication, isolating the key exchange effect. It makes our results a lower bound for deployments whose signatures and certificate chains bear additional load. Both peers also run our own implementation, barring us from cross-checking the implementation validity against a different one. At the same time, the shared prerequisites increase the comparability of different approaches as their implementation affects all equally. Finally, disruptions to the test environment necessitated restarting configurations. We always applied the same configuration and manually verified that important parameters like bandwidth and base latency did not vary across restarts. Our research compares our own proposals with current alternatives. To reduce that bias, we decided on metrics and settings early and systematically, before taking any measurements. VIII. CONCLUSION

The IETF discusses different approaches to integrating PQC KEMs into IKEv2 but they lack a comparison on one implementation under identical conditions. We systematically 20

screened the IETF document corpus identifying all currently discussed approaches (RQ1), proposed three novel ones, namely one FEC-based, QUIKE, and QUIKE-composite (RQ2), implemented all of them on top of the same codebase, and evaluated all of them in one test environment emulating various network conditions and KEMs (RQ3), leading to 1296 different configurations and 126 500 handshakes. The exact result data, our implementations, and the IETF screening artifacts are all published inside our replication package [93]. Our results show that the dominant factor for the performance is the KEM size and the transmission approach needs to be adjusted to it. For Classic McEliece-sized KEMs, no proposal managed handshakes under challenging network conditions sufficiently well. For ML-KEM and FrodoKEM, changing the transport and then using composite KEMs is more reliable and faster, as well as leaner to implement, with our proposal QUIKE-composite the fastest. With datagrambased transport, the existing ADDKE RFC [3] requires the largest and most intrusive code change and struggles with more challenging network environments but can be extended with our FEC-mechanism or IKEv2-level acknowledgments. For those, two concurrent active drafts exist, with status-ACK [5] working better than notify-ACK [73]. We identified gaps for both of them regarding the necessity to retain superseded IKE SA keys and their unspecified retransmission limit which, like replayable notify-ACKs, opens DoS vectors. In the future, standardization and implementers will need to choose between keeping continuity and compatibility on the one hand, and adopting simpler, better-performing solutions on the other hand (RQ4). Future work comprises considering the approaches’ impact on authentication. Our tests used PSK authentication. Realworld deployments use public keys and certificate chains whose migration to PQC constitutes its own research problem, also sparking discussions about implicit KEM-based authentication (cf. Section II-E) or Extensible Authentication Protocol (EAP). Investigating those interactions with the approaches evaluated in this work gives a more holistic view on IKEv2’s PQC migration. In terms of standardization, we plan on discussing found gaps of the acknowledgment drafts in the respective working group. Further, we intend to propose FEC and QUIKE-composite approaches at the IETF. During implementation, we fixed a bug in the QUIC library we build on and intend to upstream this fix. Beyond that, combining our FEC approach with the status-ACK draft and measuring it against our data would show how well the two optimizations compound. Analyzing how different loss patterns affect the individual approaches is a further open question. For QUIKE, implementing the separation of QUIC and IKEv2 into distinct processes and formally verifying how far that containment limits an attacker able to manipulate the QUIC implementation are two further steps. Finally, enabling Classic McEliece-sized keys with acceptable performance and without congestion remains an important research direction.

VOLUME X, X

duration [s], log scale KE CK CK ADD otify-A tatus-A n s

FEC

mceliece8192128, 10 Mbit/s, 200 ms, 5% loss 64 32 16 8 4

TCP TCP-c QUIKE UIKE-c Q

FIGURE 11. ML-KEM over a 100 Mbit/s link at 50 ms one-way delay, at 2% and 5% packet loss.

duration [s], log scale

64 32 16 8 4

mlkem1024, 100 Mbit/s, 50 ms, 5% loss duration [s], log scale

duration [s], log scale

32 16 8 4 2 1 0.5 0.25

mceliece8192128, 10 Mbit/s, 200 ms, 2% loss

mlkem1024, 100 Mbit/s, 50 ms, 2% loss

KE CK CK ADD otify-A tatus-A n s

ADDKE notify-ACK

frodokem1344, 1 Mbit/s, 200 ms, 5% loss

32 16 8 4 2 1

KE CK CK ADD otify-A tatus-A n s

FEC

TCP TCP-c QUIKE UIKE-c Q

FIGURE 12. FrodoKEM over a 1 Mbit/s link at 200 ms one-way delay and 5% packet loss.

A. COMPLETION-TIME DISTRIBUTIONS

Figure 6 shows one FrodoKEM configuration. Figures 11–13 extend it to the other KEMs, further loss levels, and different network speeds, showing the deductions’ general applicability. B. TRANSMISSION OVERHEAD OF THE SMALLER KEMS

Figure 9 shows the efficiency of Classic McEliece, where the approaches’ overhead differs most. ML-KEM and FrodoKEM VOLUME X, X

TCP TCP-c QUIKE UIKE-c Q

status-ACK FEC

TCP TCP-c

QUIKE QUIKE-c

mlkem1024 3 2 1 0

frodokem1344 3 2 1 0

0

0.1

APPENDIX. MEASUREMENT RESULTS

This appendix shows the adjacent data to the figures in Section V-B, allowing the reader to reproduce the perconfiguration distributions.

FEC

FIGURE 13. Classic McEliece over a 10 Mbit/s link at 200 ms one-way delay, at 2% and 5% packet loss.

packets sent / loss-free minimum

duration [s], log scale

32 16 8 4 2 1 0.5 0.25

0.5

2

packet loss [%]

5

10

FIGURE 14. Packets the initiator sends over a 10 Mbit/s link for ML-KEM and FrodoKEM, each approach relative to itself on an uncongested loss-free path (cf. Figure 9).

reproduce the same ordering but at smaller magnitudes as shown in Figure 14. C. THE COMPLETE GRID

Figure 15 gives every measured configuration. Per approach there is one bar per one-way delay, loss levels behind one another, each showing its own excess over the next lower loss level. The mirrored area below zero depicts the failure rate. 21

0%

Loss

0.1%

0.5%

50 ms

100 ms

Latency

2%

5%

10%

200 ms

y-axis: mean of connection duration [s] | negative y-axis: failure rate

5

mlkem1024, 1 Mbit/s

10 Mbit/s

100 Mbit/s

frodokem1344, 1 Mbit/s

10 Mbit/s

100 Mbit/s

mceliece8192128, 1 Mbit/s

10 Mbit/s

100 Mbit/s

4 3 2 1 0 10% 20 15 10 5 0 10% 100 80 60 40 20 0 10%

KE-ACK-ACKFECTCPCP-Uc IKIEKE-c DKE-ACK-ACKFECTCPCP-Uc IKIEKE-c DKE-ACK-ACKFECTCPCP-Uc IKIEKE-c D T Q U AD tify tus T Q U AD tify tus T Q U ADotifytatus Q Q Q a a o o t t n s n s n s

FIGURE 15. Mean handshake duration over the complete grid. Rows are the KEMs, each with its own vertical axis shared across the row, and columns are the bandwidths.

22

VOLUME X, X

ACKNOWLEDGMENT

The authors used Anthropic’s Claude with the models Fable5, Opus4.8, Opus5, and Opus5.5 during the preparation of this article. It assisted in writing the PoC implementation, revising the manuscript for internal consistency and grammar, and writing the scripts for the analysis, systematic search, and plotting of the result data. The authors verified all analyses against the recorded measurements, reviewed and edited every generated passage, and take full responsibility for the content of this publication. REFERENCES

[1] C. Cremers, A. Dax, and N. Medinger, ‘‘Keeping Up with the KEMs: Stronger Security Notions for KEMs and Automated Analysis of KEM-based Protocols,’’ in Proceedings of the 2024 on ACM SIGSAC Conference on Computer and Communications Security, ser. CCS ’24. New York, NY, USA: Association for Computing Machinery, 2024, pp. 1046–1060. [2] C. Kaufman, P. Hoffman, Y. Nir, P. Eronen, and T. Kivinen, ‘‘Internet Key Exchange Protocol Version 2 (IKEv2),’’ RFC 7296, Oct. 2014. [3] C. Tjhai, M. Tomlinson, G. Bartlett, S. Fluhrer, D. van Geest, O. Garcia-Morchon, and V. Smyslov, ‘‘Multiple Key Exchanges in the Internet Key Exchange Protocol Version 2 (IKEv2),’’ RFC 9370, May 2023. [4] D. Herzinger, S.-L. Gazdag, and D. Loebenberger, ‘‘RealWorld Quantum-Resistant IPsec,’’ in 2021 14th International Conference on Security of Information and Networks (SIN), vol. 1, 2021, pp. 1–8. [5] V. Smyslov, ‘‘Using IKE Fragmentation for Large Messages,’’ Internet Engineering Task Force, Internet-Draft draft-smyslov-ipsecme-ikev2-fragm-large-msg-01, Feb. 2026, work in Progress. [6] J. Iyengar and M. Thomson, ‘‘QUIC: A UDP-Based Multiplexed and Secure Transport,’’ RFC 9000, May 2021. [7] S. Kent, ‘‘IP Encapsulating Security Payload (ESP),’’ RFC 4303, Dec. 2005. [8] V. Smyslov, ‘‘Internet Key Exchange Protocol Version 2 (IKEv2) Message Fragmentation,’’ RFC 7383, Nov. 2014. [9] J. Mogul and S. Deering, ‘‘Path MTU Discovery,’’ RFC 1191, Nov. 1990. [10] P. W. Shor, ‘‘Polynomial-Time Algorithms for Prime Factorization and Discrete Logarithms on a Quantum Computer,’’ SIAM Journal on Computing, vol. 26, no. 5, pp. 1484–1509, 1997. [11] D. Bernstein and T. Lange, ‘‘Post-quantum cryptography,’’ Nature, vol. 549, no. 7671, pp. 188–194, 2017. [12] National Institute of Standards and Technology, ‘‘Submission Requirements and Evaluation Criteria for the Post-Quantum Cryptography Standardization Process,’’ National Institute of Standards and Technology, Tech. Rep., Dec. 2016. [Online]. Available: https://csrc.nist.gov/CSRC/media/Projects/Post-Quant VOLUME X, X

um-Cryptography/documents/call-for-proposals-final -dec-2016.pdf [13] Federal Office for Information Security (BSI), ‘‘Kryptographische Verfahren: Empfehlungen und Schlüssellängen,’’ Federal Office for Information Security (BSI), Bonn, DE, Technical Guideline BSI TR-02102-1, February 2024. [14] ——, ‘‘Migration zu Post-Quanten-Kryptografie,’’ Federal Office for Information Security (BSI), Bonn, DE, Technical Guideline, August 2020. [Online]. Available: https://www.bsi.bund.de/SharedDocs/Downloads/DE/ BSI/Krypto/Post-Quanten-Kryptografie.pdf?__blob= publicationFile&v=1 [15] M. Barbosa, D. Connolly, J. D. Duarte, A. Kaiser, P. Schwabe, K. Varner, and B. Westerbaan, ‘‘X-Wing: The Hybrid KEM You’ve Been Looking For,’’ IACR Communications in Cryptology, vol. 1, no. 1, 2024. [16] S. A. Weis, ‘‘Improving GIJS Key Recovery for Classic McEliece,’’ Cryptology ePrint Archive, Paper 2026/1984, 2026. [Online]. Available: https://eprint.iacr. org/2026/1984 [17] A. Ghoshal, Y. Ishai, A. Jain, and N. Sun, ‘‘Quasipolynomial Cryptanalysis of the McEliece Cryptosystem (or: PIR Meets McEliece),’’ Cryptology ePrint Archive, Paper 2026/1630, 2026. [Online]. Available: https://eprint.iacr.org/2026/1630 [18] Federal Office for Information Security (BSI), ‘‘Notes on recent developments concerning Classic McEliece,’’ Federal Office for Information Security (BSI), Bonn, DE, Tech. Rep., Sep. 2026. [Online]. Available: https://www.bsi.bund.de/SharedDocs/Downloads/EN/ BSI/Crypto/Notes_Classic_McEliece.pdf [19] I. Reed and G. Solomon, ‘‘Polynomial Codes Over Certain Finite Fields,’’ Journal of the Society for Industrial and Applied Mathematics, vol. 8, no. 2, pp. 300–304, 1960. [20] S. Roman, Coding and Information Theory. Springer Science & Business Media, jun 4 1992. [21] F. MacWilliams and N. Sloane, The Theory of Errorcorrecting Codes. Elsevier, 1977. [22] R. Gallager, ‘‘Low-density parity-check codes,’’ IRE Transactions on Information Theory, vol. 8, no. 1, pp. 21–28, 1962. [23] S. Borwankar and D. Shah, ‘‘Low Density Parity Check Code (LDPC Codes) Overview,’’ arXiv:2009.08645, Sep. 2020. [Online]. Available: https://arxiv.org/abs/20 09.08645 [24] J. Hamkins, ‘‘Optimal Codes for the Burst Erasure Channel,’’ NASA Tech Briefs, no. NPO-46903, Sep. 2010, nPO-46903. Accessed: 2026-04-27. [Online]. Available: https://ntrs.nasa.gov/api/citations/20100033 570/downloads/20100033570.pdf [25] R. G. Maunder, ‘‘A Vision for 5G Channel Coding,’’ Project Report, October 2016. [Online]. Available: https://eprints.soton.ac.uk/401809/ 23

[26] C. Berrou, A. Glavieux, and P. Thitimajshima, ‘‘Near Shannon limit error-correcting coding and decoding: Turbo-codes. 1,’’ in Proceedings of ICC ’93 - IEEE International Conference on Communications, vol. 2, 1993, pp. 1064–1070. [27] S. Benedetto and G. Montorsi, ‘‘Role of recursive convolutional codes in turbocodes,’’ Electronics Letters, vol. 31, no. 11, pp. 858–859, May 1995. [28] C. Shannon, ‘‘A mathematical theory of communication,’’ The Bell System Technical Journal, vol. 27, no. 3, pp. 379–423, 1948. [29] M. Rowshan, M. Qiu, Y. Xie, X. Gu, and J. Yuan, ‘‘Channel Coding Toward 6G: Technical Overview and Outlook,’’ IEEE Open Journal of the Communications Society, vol. 5, pp. 2585–2685, 2024. [30] M. Luby, M. Mitzenmacher, A. Shokrollahi, D. Spielman, and V. Stemann, ‘‘Practical loss-resilient codes,’’ in Proceedings of the Twenty-Ninth Annual ACM Symposium on Theory of Computing, ser. STOC ’97. New York, NY, USA: Association for Computing Machinery, 1997, pp. 150–159. [31] J. Byers, M. Luby, M. Mitzenmacher, and A. Rege, ‘‘A digital fountain approach to reliable distribution of bulk data,’’ SIGCOMM Comput. Commun. Rev., vol. 28, no. 4, pp. 56–67, Oct. 1998. [32] M. Luby, ‘‘LT Codes,’’ in Proceedings of the 43rd Symposium on Foundations of Computer Science, ser. FOCS ’02. USA: IEEE Computer Society, 2002, p. 271. [33] M. Luby, A. Shokrollahi, M. Watson, and T. Stockhammer, ‘‘Raptor Forward Error Correction Scheme for Object Delivery,’’ RFC 5053, Oct. 2007. [34] M. Luby, A. Shokrollahi, M. Watson, T. Stockhammer, and L. Minder, ‘‘RaptorQ Forward Error Correction Scheme for Object Delivery,’’ RFC 6330, Aug. 2011. [35] Qualcomm, ‘‘RaptorQ™ Technical Overview,’’ 2010. [Online]. Available: https://www.qualcomm.com/conte nt/dam/qcomm-martech/dm-assets/documents/Raptor Q_Technical_Overview.pdf [36] J. Iyengar and I. Swett, ‘‘QUIC Loss Detection and Congestion Control,’’ RFC 9002, May 2021. [37] M. Thomson and S. Turner, ‘‘Using TLS to Secure QUIC,’’ RFC 9001, May 2021. [38] C. Näther, D. Herzinger, S.-L. Gazdag, J.-P. Steghöfer, S. Daum, and D. Loebenberger, ‘‘Migrating Software Systems Toward Post-Quantum Cryptography-A Systematic Literature Review,’’ IEEE Access, vol. 12, pp. 132 107–132 126, 2024. [39] C. Näther, D. Herzinger, J.-P. Steghöfer, S.-L. Gazdag, E. Hirsch, and D. Loebenberger, ‘‘Toward a Common Understanding of Cryptographic Agility: A Systematic Review,’’ IEEE Access, vol. 14, pp. 133 743–133 763, 2026. [40] E. Rescorla, ‘‘The Transport Layer Security (TLS) Protocol Version 1.3,’’ RFC 9846, Jul. 2026. 24

[41] D. Sikeridis, P. Kampanakis, and M. Devetsikiotis, ‘‘PostQuantum Authentication in TLS 1.3: A Performance Study,’’ in Proceedings of the Network and Distributed System Security Symposium (NDSS). Internet Society, 01 2020. [42] C. Paquin, D. Stebila, and G. Tamvada, ‘‘Benchmarking Post-quantum Cryptography in TLS,’’ in Post-Quantum Cryptography (PQCrypto 2020), ser. Lecture Notes in Computer Science, vol. 12100. Springer, 04 2020, pp. 72–91. [43] J. Sowa, B. Hoang, A. Yeluru, S. Qie, A. Nikolich, R. Iyer, and P. Cao, ‘‘Post-Quantum Cryptography (PQC) Network Instrument: Measuring PQC Adoption Rates and Identifying Migration Pathways,’’ in 2024 IEEE International Conference on Quantum Computing and Engineering (QCE). IEEE, 2024, pp. 1835–1846. [44] J. Donenfeld, ‘‘WireGuard: Next Generation Kernel Network Tunnel,’’ in Proceedings of the Network and Distributed System Security Symposium (NDSS). Internet Society, 01 2017. [45] A. Hülsing, K.-C. Ning, P. Schwabe, F. Weber, and P. Zimmermann, ‘‘Post-quantum wireguard,’’ in 2021 IEEE Symposium on Security and Privacy (SP). IEEE, 2021, pp. 304–321. [46] T. Perrin, ‘‘The Noise Protocol Framework,’’ https://no iseprotocol.org/noise.pdf, 2018, revision 34. [47] Y. Angel, B. Dowling, A. Hülsing, P. Schwabe, and F. Weber, ‘‘Post Quantum Noise,’’ in Proceedings of the 2022 ACM SIGSAC Conference on Computer and Communications Security (CCS). Association for Computing Machinery, 2022, pp. 97–109. [48] Rosenpass e.V. (2026) Rosenpass. Rosenpass e.V. [Online]. Available: https://rosenpass.eu/ [49] P. Schwabe, D. Stebila, and T. Wiggers, ‘‘Post-Quantum TLS Without Handshake Signatures,’’ in Proceedings of the 2020 ACM SIGSAC Conference on Computer and Communications Security, ser. CCS ’20. New York, NY, USA: Association for Computing Machinery, 2020, pp. 1461–1480. [50] S. Fluhrer, P. Kampanakis, D. McGrew, and V. Smyslov, ‘‘Mixing Preshared Keys in the Internet Key Exchange Protocol Version 2 (IKEv2) for Post-quantum Security,’’ RFC 8784, Jun. 2020. [51] D. Harkins and D. Carrel, ‘‘The Internet Key Exchange (IKE),’’ RFC 2409, Nov. 1998. [52] C. Tjhai, T. Heider, and V. Smyslov, ‘‘Beyond 64KB Limit of IKEv2 Payloads,’’ Internet Engineering Task Force, Internet-Draft draft-tjhai-ikev2-beyond-64k-limit03, Jul. 2022, work in Progress. [53] T. Reddy, V. Smyslov, and S. Fluhrer, ‘‘Signature Authentication in the Internet Key Exchange Version 2 (IKEv2) using PQC,’’ Internet Engineering Task Force, InternetDraft draft-ietf-ipsecme-ikev2-pqc-auth-12, Aug. 2026, work in Progress. [54] G. WANG and V. Smyslov, ‘‘KEM-based Authentication for IKEv2 with Post-quantum Security,’’ Internet EngiVOLUME X, X

neering Task Force, Internet-Draft draft-wang-ipsecmekem-auth-ikev2-04, Jul. 2026, work in Progress. [55] B. Dowling, T. B. Hansen, and K. Paterson, ‘‘Many a Mickle Makes a Muckle: A Framework for Provably Quantum-Secure Hybrid Key Exchange,’’ Cryptology ePrint Archive, Paper 2020/099, 2020. [56] S. Bruckner, S. Ramacher, and C. Striecks, ‘‘Muckle+: End-to-End Hybrid Authenticated Key Exchanges,’’ in Post-Quantum Cryptography, T. Johansson and D. SmithTone, Eds. Cham: Springer Nature Switzerland, 2023, pp. 601–633. [57] S.-L. Gazdag, S. Grundner-Culemann, T. Heider, D. Herzinger, F. Schärtl, J. Y. Cho, T. Guggemos, and D. Loebenberger, ‘‘Quantum-Resistant MACsec and IPsec for Virtual Private Networks,’’ in Security Standardisation Research - 8th International Conference, SSR 2023, Lyon, France, April 22-23, 2023, Proceedings, ser. Lecture Notes in Computer Science, F. Günther and J. Hesse, Eds., vol. 13895. Springer, 2023, pp. 1–21. [Online]. Available: https://doi.org/10.1007/978-3-031 -30731-7_1 [58] S. Bae, Y. Chang, H. Park, M. Kim, and Y. Shin, ‘‘A Performance Evaluation of IPsec with Post-Quantum Cryptography,’’ in Information Security and Cryptology – ICISC 2022, ser. Lecture Notes in Computer Science, vol. 13849. Springer, 2023, pp. 249–266. [59] S.-L. Gazdag, S. Grundner-Culemann, T. Guggemos, T. Heider, and D. Loebenberger, ‘‘A Formal Analysis of IKEv2’s Post-Quantum Extension,’’ in Proceedings of the 37th Annual Computer Security Applications Conference (ACSAC). Association for Computing Machinery, 2021, pp. 91–105. [60] P. Udugahapattuwa, C. De Alwis, E. Zeydan, U. Wijewardhana, and M. Liyanage, ‘‘A Post-Quantum Cryptographic Framework for High-Level Security Protocols in 6G,’’ in 2026 Joint European Conference on Networks and Communications & 6G Summit (EuCNC/6G Summit), 2026, pp. 1077–1084. [61] A. Bahaa-Eldin, M. El-Kharashi, and B. Abdullah, ‘‘Hybrid Post-Quantum IKEv2 on Embedded Automotive Platforms: Design, Implementation, and Evaluation,’’ Electronics, vol. 15, no. 15, 2026. [62] A. Mutlugun, Y. Hanna, and K. Akkaya, ‘‘Performance Evaluation of Quantum-Resistant IKEv2 Protocol for Satellite Networking Environments,’’ in 2024 IEEE Virtual Conference on Communications (VCC), 2024, pp. 1–7. [63] E. Lear, ‘‘Report from the IAB Workshop on Internet Technology Adoption and Transition (ITAT),’’ RFC 7305, Jul. 2014. [64] M. Welzl, J. Ott, C. Perkins, S. Islam, and D. Kutscher, ‘‘How not to IETF: Lessons Learned From Failed Standardization Attempts,’’ in 2023 IEEE International Conference on Pervasive Computing and Communications Workshops and other Affiliated Events (PerCom Workshops), 2023, pp. 427–432. VOLUME X, X

[65] M. Page, J. McKenzie, P. Bossuyt, I. Boutron, T. Hoffmann, C. Mulrow, L. Shamseer, J. Tetzlaff, E. Akl, S. Brennan, R. Chou, J. Glanville, J. Grimshaw, A. Hróbjartsson, M. Lalu, T. Li, E. Loder, E. Mayo-Wilson, S. McDonald, L. McGuinness, L. Stewart, J. Thomas, A. Tricco, V. Welch, P. Whiting, and D. Moher, ‘‘The PRISMA 2020 statement: an updated guideline for reporting systematic reviews,’’ Systematic Reviews, vol. 10, no. 1, p. 89, Mar. 2021. [66] National Institute of Standards and Technology, ‘‘Module-Lattice-Based Key-Encapsulation Mechanism Standard,’’ U.S. Department of Commerce, Tech. Rep. FIPS 203, 2024. [67] E. Alkim, J. W. Bos, L. Ducas, L. Glabush, P. Longa, I. Mironov, M. Naehrig, V. Nikolaenko, C. Peikert, A. Raghunathan, D. Stebila, and F. Virdia, ‘‘FrodoKEM: Learning With Errors Key Encapsulation,’’ https://frod okem.org/files/FrodoKEM-ISO-20230314.pdf, 2023, specification, 14 March 2023. Standardized as ISO/IEC 18033-2:2006/Amd 2. [68] M. R. Albrecht, D. J. Bernstein, T. Chou et al., ‘‘Classic McEliece: Conservative Code-Based Cryptography,’’ ht tps://classic.mceliece.org/, 2022, round-4 submission to the NIST post-quantum cryptography standardization process, 23 October 2022. [69] X. Zhou and P. Van Mieghem, ‘‘Reordering of IP Packets in Internet,’’ in Passive and Active Network Measurement (PAM 2004), ser. Lecture Notes in Computer Science, vol. 3015. Springer, 2004, pp. 237–246. [70] S. Hemminger, ‘‘Network Emulation with NetEm,’’ in Linux Conf Au, Canberra, AU, 2005. [71] M. Yajnik, S. Moon, J. Kurose, and D. Towsley, ‘‘Measurement and modelling of the temporal dependence in packet loss,’’ in IEEE INFOCOM ’99. IEEE, 1999, pp. 345–352. [72] V. Smyslov and T. Reddy, ‘‘Separate Transports for IKE and ESP,’’ Internet Engineering Task Force, InternetDraft draft-ietf-ipsecme-ikev2-reliable-transport-07, Aug. 2026, work in Progress. [73] A. Antony, S. Klassert, and T. Brunner, ‘‘IKEv2 Fragment Acknowledgment Extension,’’ Internet Engineering Task Force, Internet-Draft draft-antony-ipsecmeikev2-fragment-acknowledgment-03, Jan. 2026, work in Progress. [74] T. Reddy and V. Smyslov, ‘‘PQ/T Hybrid Composite Key Exchange and Reliable Transport for IKEv2,’’ Internet Engineering Task Force, Internet-Draft draft-reddyipsecme-ikev2-hybrid-reliable-01, Jul. 2026, work in Progress. [75] Y. Nir, ‘‘A Larger Internet Key Exchange version 2 (IKEv2) Payload,’’ Internet Engineering Task Force, Internet-Draft draft-nir-ipsecme-big-payload-07, Mar. 2026, work in Progress. [76] V. Smyslov, ‘‘Extended IKEv2 Payload Format,’’ Internet Engineering Task Force, Internet-Draft draft-smyslovipsecme-ikev2-extended-pld-01, Mar. 2023, work in 25

Progress. [77] ——, ‘‘Compact Format of IKEv2 Payloads,’’ Internet Engineering Task Force, Internet-Draft draft-smyslovipsecme-ikev2-compact-10, Sep. 2021, work in Progress. [78] P. Kampanakis, ‘‘Post-quantum Key Exchange with ML-KEM in the Internet Key Exchange Protocol Version 2 (IKEv2),’’ Internet Engineering Task Force, Internet-Draft draft-ietf-ipsecme-ikev2-mlkem-09, Jul. 2026, work in Progress. [79] G. Wang, L. Bruckert, V. Smyslov, and M. Chen, ‘‘Postquantum Key Exchange in IKEv2 with FrodoKEM,’’ Internet Engineering Task Force, Internet-Draft draft-ietfipsecme-hybrid-kem-ikev2-frodo-03, Aug. 2026, work in Progress. [80] V. Smyslov and Y. Nir, ‘‘Using Classic McEliece in the Internet Key Exchange Protocol Version 2 (IKEv2),’’ Internet Engineering Task Force, Internet-Draft draftsmyslov-ipsecme-ikev2-mceliece-02, Apr. 2026, work in Progress. [81] Y. Fukagawa, H. Kosuge, M. Saito, S. Fluhrer, and A. Nagai, ‘‘Post-quantum Hybrid Key Exchange with NTRU in the Internet Key Exchange Protocol Version 2 (IKEv2),’’ Internet Engineering Task Force, InternetDraft draft-skyline-ipsecme-ntru-ikev2-00, Jul. 2025, work in Progress. [82] V. Smyslov, ‘‘Intermediate Exchange in the Internet Key Exchange Protocol Version 2 (IKEv2),’’ RFC 9242, May 2022. [83] T. Pauly and V. Smyslov, ‘‘TCP Encapsulation of Internet Key Exchange Protocol (IKE) and IPsec Packets,’’ RFC 9329, Nov. 2022, obsoletes RFC 8229. [84] O. Honda, H. Ohsaki, M. Imase, M. Ishizuka, and J. Murayama, ‘‘Understanding TCP over TCP: effects of TCP tunneling on end-to-end throughput and latency,’’ Proceedings of SPIE, vol. 6011, 2005. [85] X. Lei, ‘‘The Comparison of RS Codes, LDPC Codes, And Turbo Codes,’’ Highlights in Science, Engineering and Technology, vol. 81, pp. 496–504, 01 2024. [86] H. Cui, F. Kschischang, M. Karlsson, and E. Agrell, ‘‘Channel Estimation and LDPC Decoding for Bursty Phase Noise,’’ 2026. [Online]. Available: https://arxiv.or g/abs/2604.07004 [87] J. Kang, W. Stark, and A. Hero, ‘‘Turbo Codes for Fading and Burst Channels,’’ 02 1999. [Online]. Available: https://web.eecs.umich.edu/~stark/1998F.pdf [88] M. Sanchez, K. Shanmugan, L. De Haro, and M. Calvo, ‘‘Burst error correction capabilities of turbo codes in mobile environments,’’ in First International Conference on 3G Mobile Communication Technologies, 2000, pp. 176–180. [89] X.-G. Xia, ‘‘Understanding turbo codes: A signal processing study,’’ Journal of Information and Intelligence, vol. 2, no. 1, pp. 1–13, 1 2024. [Online]. Available: http://dx.doi.org/10.1016/j.jiixd.2023.10.003 [90] QUALCOMM Incorporated, ‘‘QUALCOMM Incorporated’s Statement about IPR related to RFC 6330,’’ IETF 26

IPR Disclosure #2554, Mar. 2015, accessed: 2026-10-07. [Online]. Available: https://datatracker.ietf.org/ipr/2554/ [91] P. Eronen, ‘‘IKEv2 Mobility and Multihoming Protocol (MOBIKE),’’ RFC 4555, Jun. 2006. [92] J. Chu, N. Dukkipati, Y. Cheng, and M. Mathis, ‘‘Increasing TCP’s Initial Window,’’ RFC 6928, Apr. 2013. [93] D. Herzinger, ‘‘Replication Package for "Embedding Large PQC KEMs in IKEv2",’’ IEEE Dataport, 2026. [Online]. Available: https://dx.doi.org/10.21227/mygk-9 s17 [94] M. Mathis, J. Semke, J. Mahdavi, and T. Ott, ‘‘The Macroscopic Behavior of the TCP Congestion Avoidance Algorithm,’’ SIGCOMM Comput. Commun. Rev., vol. 27, no. 3, pp. 67–82, 1997. [95] A. Ampatzoglou, S. Bibi, P. Avgeriou, and A. Chatzigeorgiou, ‘‘Guidelines for Managing Threats to Validity of Secondary Studies in Software Engineering,’’ in Contemporary Empirical Methods in Software Engineering, M. Felderer and G. H. Travassos, Eds. Cham: Springer International Publishing, 2020, pp. 415–441.

DANIEL HERZINGER holds a Master of Science in Computer Science. He started working on postquantum cryptography (PQC) and its adoption into real-world scenarios during his Master’s thesis in 2020, together with the German IT security company genua, where he started his IT security journey in 2015. After finishing his studies, he first dove into supporting customers with securing their IT and OT infrastructures at genua’s consulting department for two years. He then indulged in his passion for PQC by joining the research group in 2023, focusing on the transition of complex systems and infrastructures to quantum resistance.

MARCO THOMAS holds a Master of Science in IT Security. He joined the German IT security company genua GmbH in 2019 as a student and finished his studies in 2026 with his Master’s thesis about real-world usability of post-quantum cryptography (PQC) in virtual private network (VPN) software. Throughout his studies, he focused on understanding deeply technical computer science topics, such as networking and kernel development. After finishing his studies, he joined the development department of genua, which is in charge of developing VPN technologies using the IKEv2 protocol. There, he works on integrating post-quantum cryptography into these products.

VOLUME X, X

TOBIAS HANDIRK is a researcher for PostQuantum Cryptography at the German IT security company genua GmbH. He joined the company in 2025, after completing a PhD in Computer Science with summa cum laude, which he obtained in 2024 at the Bergische Universität Wuppertal. In his PhD research he worked on the provable security of realworld cryptographic protocols, with a particular focus on key exchange protocols. Prior to that, he finished a Master of Science in Computer Science at the University of Paderborn with a specialization in the area ‘‘Networks and Communications’’.

STEFAN-LUKAS GAZDAG holds a Master of Science in Computer Science. He has focused on post-quantum cryptography (PQC) since 2013, overcoming obstacles in practical use. At the German IT security company genua’s research group he works with his team on publicly funded PQC research projects and other collaborations, enabling the transition to quantum-safe networks. He was, e.g., involved in the publication of the first explicit PQC RFC, RFC 8391, describing the signature scheme XMSS, recommended, e.g., by US NIST, NSA and German BSI.

DANIEL LOEBENBERGER received his doctorate in cryptography from the University of Bonn in 2012, where he conducted research and taught until the end of 2015. From 2016 to 2019, he worked as an IT security expert with a focus on cryptography at genua GmbH, a subsidiary of the Bundesdruckerei GmbH, the German Federal Printing Office, on various topics of professional high-security components. Daniel Loebenberger was appointed Professor of Cybersecurity at OTH Amberg-Weiden University of Applied Sciences in January 2019 and has also headed the Secure Infrastructure department at Fraunhofer AISEC’s Weiden site since then. His group focuses on applied post-quantum cryptography and quantum-safe infrastructures. Since 2026, he has also been an Honorary Visiting Professor at Nanyang Technological University, Singapore.

MARIAN MARGRAF is a professor of information security at Freie Universität Berlin and head of department at the Fraunhofer Institute AISEC. His research group focuses on usable privacy and security, cryptography—particularly post-quantum cryptography—and electronic identities. He has more than 20 years of experience in the field of information security. He began his career from 2003 to 2008 as a cryptologist at the Federal Office for Information Security, where he helped develop the cryptographic protocols for electronic passports and ID cards. In 2008, he moved to the Federal Ministry of the Interior, where he developed information security strategies.

VOLUME X, X

27

Related documents

• Embedding Large PQC KEMs in IKEv2#1447723
• Standard Public Key Cryptography (PKC) Test Keys#502774
• Benchmarking Post-Quantum Key Encapsulation in S3-Compatible Object Storage under Client Concurrency#1356793
• Benchmarking Post-Quantum Key Encapsulation in S3-Compatible Object Storage under Client Concurrency#1348775
• P6R's Secure Shell Public Key Subsystem#209063