Source-linked AI summary
Sentinel-Based Failover for QKD-Augmented IPsec Tunnels
Juan Carlos Hernandez-Hernandez, Francesco Vista, Haftay Gebreslasie Abreha, Intidhar Bedhief, Seid Koudia, Symeon Chatzinotas
TL;DR
Hybrid QKD/PQC IPsec must preserve tunnel availability when KME-based QKD delivery fails. The paper integrates X25519, ML-KEM, and ETSI GS QKD 014 keys through RFC 9370 with sentinel-based degradation, and evaluates the design on a 33 km metropolitan link. The full hybrid costs 103 ms versus 61 ms for the classical baseline, while failure experiments show uninterrupted protected traffic during complete KME outage.
Problem
QKD integration depends on KME key delivery, so a failed QKD leg could abort IKEv2 negotiation and reduce tunnel availability.
Method
An open-source strongSwan plugin combines X25519, ML-KEM, and ETSI GS QKD 014 keys through RFC 9370 and uses sentinels to coordinate graceful degradation.
Results
103 ms versus 61 ms: complete authentication for the full hybrid versus classical baseline; QKD retrieval adds about 7 ms, and protected traffic continues through complete KME outage.
Takeaways & Limitations
The sentinel protocol keeps the tunnel operational with available key-establishment components and restores the QKD share at a subsequent rekey.
Abstract
from arXiv · showhide
Quantum-safe IPsec through hybrid key establishment is practical, but creates a critical operational challenge: how to maintain tunnel availability when the QKD infrastructure becomes unavailable. In this paper, we present the design, implementation, and experimental evaluation of a quantum-safe key establishment mechanism for an IPsec tunnel that combines X25519, ML-KEM, and ETSI GS QKD 014 keys through the RFC 9370 multiple key exchange mechanism, and that degrades gracefully when the QKD key delivery fails. Our open-source StrongSwan plugin uses a sentinel-based coordination protocol, thereby permitting us to complete the handshake even if the QKD leg fails, instead of aborting, restoring the QKD share at the next rekey. On a testbed connected to a metropolitan QKD link over 33 km of deployed fiber, we evaluated five configurations, from a classical X25519 with RSA baseline to a hybrid one that adds ML-KEM-1024 and a QKD key. The full hybrid authentication costs 103 ms against 61 ms for the baseline, the QKD retrieval itself adds only about 7 ms. Failure injection experiments confirm that the tunnel survives a complete KME outage without any interruption of the protected traffic.
I. INTRODUCTION
Hybrid IPsec combines classical, post-quantum, and QKD-derived secrets, but QKD introduces an availability dependency when KMEs fail. This paper addresses graceful degradation through an open-source plugin and sentinel protocol, evaluated across five configurations.
- Classical public-key algorithms used by IKEv2 are vulnerable to cryptographically relevant quantum computers and harvest-now-decrypt-later attacks.
- RFC 9370 allows classical, PQC, and QKD key exchanges to feed one session key that remains secure while at least one component remains unbroken.
- QKD creates an operational dependency on reachable, sufficiently provisioned KMEs, so negotiation failure could reduce tunnel availability.
- The paper designs an open-source strongSwan plugin integrating ETSI GS QKD 014 retrieval with X25519 and ML-KEM through RFC 9370.
- The sentinel-based protocol keeps the tunnel up and re-keying during KME failures, while experiments cover five configurations up to X25519, ML-KEM-1024, and QKD over 33 km of deployed fiber.
II. BACKGROUND
IPsec uses IKEv2 to negotiate security associations and periodically renews keys for long-lived tunnels. Rekeying follows Make Before Break, installing the new association before deleting the old one.
- IKE SA INIT performs key exchange, IKE AUTH authenticates peers and creates the first Child SA, and CREATE CHILD SA exchanges renew keys periodically.
- Under Make Before Break, the new security association is installed before the old one is deleted.
- IPsec protects network traffic with ESP while IKEv2 negotiates the required security associations.
B. Multiple KEs in IKEv2
RFC 9242 and RFC 9370 extend IKEv2 to support large payloads and multiple key exchanges, enabling X25519, ML-KEM, and QKD secrets to contribute to one hybrid session key.
- RFC 9242 adds an IKE INTERMEDIATE exchange for large payloads, while RFC 9370 permits up to seven additional key exchanges.
- During rekeying, additional exchanges use IKE FOLLOWUP KE messages, and the session key mixes all negotiated secrets.
- ML-KEM provides a software-only PQC mechanism, while QKD applications retrieve matching symmetric keys through local KMEs using the ETSI GS QKD 014 REST interface.
III. RELATED WORK
Related work compared sequential and parallel hybrid QKD/PQC establishment, while this paper combines the same hybrid components in a metropolitan testbed. Its focus is graceful degradation when QKD delivery fails.
- Blanco-Romero et al. compared sequential RFC 9370-style and parallel hybrid QKD/PQC IKEv2 establishment using ETSI 004 and ETSI 014 APIs.
- The present system uses two IPsec peers, local KMEs, QKD devices, X25519, ML-KEM, and a QKD component within the LUQCIA infrastructure.
- The experiments use a deployed 33 km quantum channel connecting the two QKD systems.
B. The QKD Plugin
The plugin keeps tunnel establishment available by selecting the strongest currently available key components and retrying QKD at rekey.
- The design establishes the tunnel with the strongest available component set and upgrades it when QKD returns at the next rekey.This avoids restarting negotiation when the QKD branch fails.
- During the QKD exchange, peers use a sentinel value to signal failure and converge on completing the handshake without the QKD share.The sentinel is an all-zero identifier that cannot collide with a real UUID.
- A 2-second response limit determines when the KME is treated as unavailable.
V. EXPERIMENTAL SETUP
The evaluation compares five IKEv2 key-establishment configurations through repeated tunnel and rekey cycles, while separately testing wire behavior and KME failures.
- Five configurations range from classical X25519 with RSA to X25519 with ML-KEM-1024 and QKD.All configurations use RSA certificates and AES-256-GCM, isolating differences to key establishment.
- Measurements cover tunnel establishment, IKE SA REKEY, and CHILD SA REKEY in cold-start and steady-state conditions.Round-trip durations come from strongSwan initiator timestamps.
- The sentinel protocol makes both peers converge on using the QKD share or completing the exchange without it.
- Tcpdump captures verify protocol behavior on the wire, while charon logs support failure-injection experiments.KME outages are injected by making the service unreachable or exhausting its keys.
VI. EXPERIMENTAL RESULTS
The packet capture shows the hybrid handshake carrying classical, PQC, and QKD exchange material before ESP-protected traffic begins.
- 127-byte QKD-round datagrams carry key identifiers rather than the QKD key itself.The key identifier exchange avoids sending the symmetric key across the classical network.
- 1295- and 1199-byte ML-KEM-768 payloads nearly reach the Ethernet MTU during the first IKE INTERMEDIATE exchange.
- IKE AUTH is the only exchange requiring IKE-level fragmentation, with two datagrams per direction.
- ESP packets appear after the final response, indicating that protected traffic starts once the handshake completes.
B. Handshake and Rekey Cost
Hybrid key establishment increases authentication time mainly through PQC processing and exchange overhead, while QKD adds a comparatively small cost and child rekeys remain stable.
- 103 ms versus 61 ms: full hybrid authentication is 1.7 times the classical baseline.Standard deviations remain between 2.0 and 4.3 ms for authentication.
- 7 ms: adding the QKD round increases rekey cost by about 7 ms on the metropolitan link.This includes one extra round trip and two KME REST calls.
- 37 ms: ML-KEM-1024 rekeying costs this amount after ML-KEM-768 reaches 25 ms from a 5 ms classical baseline.The larger public key causes exchange fragmentation.
- About 5 ms: CHILD SA REKEY remains at this duration across all five configurations.It derives keys from previously established key sessions.
- 169 ms versus 125 ms: cold-start authentication is higher than steady-state authentication because initialization and first certificate validation add one-time overhead.
D. Failure Injection and Recovery
The tunnel completes rekeying during a KME failure by disabling only the QKD leg, then automatically restores the full hybrid exchange after KME recovery. Protected traffic remains uninterrupted throughout the degradation cycle.
- The full hybrid profile is established before the injected KME failure.
- The failed QKD retrieval sends a sentinel, allowing rekeying to continue with X25519 and ML-KEM-768 only.The responder skips its own KME call, and both daemons log SECURITY DEGRADED.
- The rekey completes normally, and ESP traffic is never interrupted during the KME outage.From the protected applications’ perspective, nothing happens.
- A restored KME enables the next rekey to fetch a fresh 32 byte key and reactivate the full hybrid exchange.Both daemons log SECURITY RESTORED.
- The sentinel decision occurs within the normal message flow, adding no extra exchange or failure-specific latency.
- The exposure window without the QKD share is bounded by the rekey interval.This lets the operator directly control how long the tunnel may remain without its QKD share.
VII. CONCLUSION
The paper presents and evaluates a quantum-safe IPsec key-establishment scheme combining X25519, ML-KEM, and QKD, with graceful degradation when QKD fails. On a 33 km metropolitan QKD testbed, the scheme preserves traffic during a complete KME outage while adding limited authentication and QKD-retrieval overhead.
- The scheme combines X25519, ML-KEM, and QKD keys in one IKEv2 negotiation and degrades gracefully when the QKD leg fails.
- 103 ms versus 61 ms: full hybrid key establishment raises complete authentication time on the 33 km testbed.
- About 7 ms: the QKD round’s identifier-based design contributes only a small retrieval cost.
- About 5 ms: frequent child rekeys remain at this level in every configuration.
- A complete KME outage leaves protected traffic uninterrupted, while the protocol maintains the post-quantum security floor and restores QKD automatically at the next rekey.