Post-quantum IPsec hub and spoke scaling: what changes?

Post-quantum IPsec hub and spoke scaling is the engineering work of running hybrid IKEv2 key exchange (classical Diffie-Hellman plus ML-KEM) on a central VPN concentrator that terminates hundreds of branch, substation or plant tunnels, so that larger handshakes, extra round trips and synchronized rekeys don’t overload the hub or delay recovery after an outage.

For operators of OT and critical infrastructure, the hub is a single point where every remote site’s confidentiality and availability come together. This article explains where the real load comes from, which parts of the standards add latency, and how to migrate spokes without a disruptive cutover.

Why does hub and spoke topology change the post-quantum scaling problem?

A hub carries many IKE negotiations at once, so small per-tunnel costs add up and synchronized events matter more than steady-state throughput. Post-quantum key exchange changes message sizes and exchange counts far more than it changes CPU cost.

The standards path for hybrid IPsec runs through three documents. RFC 7296 defines IKEv2 itself. RFC 9242 defines a new exchange called “Intermediate Exchange” or “IKE_INTERMEDIATE”, and one or more of these exchanges may take place right after the IKE_SA_INIT exchange and prior to the IKE_AUTH exchange. RFC 9370 builds on that: it utilizes the IKE_INTERMEDIATE exchange to perform multiple key exchanges when an IKE SA is being established, and introduces a new exchange, IKE_FOLLOWUP_KE, for the same purpose when the IKE SA is being rekeyed or is creating additional Child SAs. The post-quantum algorithm most deployments negotiate is ML-KEM from FIPS 203, which specifies three parameter sets: in order of increasing security strength and decreasing performance, ML-KEM-512, ML-KEM-768 and ML-KEM-1024.

The security argument for the hybrid model is simple: the shared key is formed by combining secrets such that an attacker must break all key exchanges to defeat the security. The IETF authors of RFC 9370 put the design goal plainly: the method “allows integration of PQC in IKEv2, while maintaining backward compatibility”.

How much extra CPU load do ML-KEM handshakes put on a central VPN hub?

Very little in raw computation. ML-KEM operations cost tens of thousands of CPU cycles, roughly the same as elliptic-curve Diffie-Hellman. A hub’s CPU budget goes mostly on authentication, packet handling and state management.

Here’s a worked example. In IKEv2 the initiator generates the ML-KEM key pair and the responder encapsulates. A hub acting as responder therefore pays mainly the encapsulation cost: about 36,000 cycles, or around 12 microseconds on one 3 GHz core. Even 500 spokes reconnecting at once add only a few core-milliseconds of ML-KEM work. The authors of a 2025 NIST workshop submission summed it up: “ML-KEM is so fast that reusing private keys to save a few CPU cycles is not justifiable.”

The real extra cost comes from bytes and state. Each hybrid negotiation carries kilobytes more data, holds a half-open SA for one extra exchange, and needs one more round of encryption, integrity checking and possibly IKE fragment reassembly. On constrained ARM-based spokes the picture is different: on the Raspberry Pi 4, classical X25519 key generation throughput keeps a clear performance advantage over ML-KEM variants. Old RTU-class gateways at remote sites may therefore notice the change more than the hub does.

Does IKE_INTERMEDIATE add round trips that slow tunnel setup after a hub reboots?

Yes. Each additional key exchange adds exactly one round trip. A hybrid tunnel with one ML-KEM exchange needs three exchanges instead of two before traffic flows.

RFC 9370 assumes that each key exchange method requires one round trip and consumes exactly one IKE_INTERMEDIATE exchange. The reason for this design is fragmentation: the additional key exchanges are performed using IKE_INTERMEDIATE messages that follow IKE_SA_INIT, so that the standard IKE fragmentation mechanisms (which cannot be used in IKE_SA_INIT) are available for the potentially large Key Exchange payloads.

Packet captures confirm where the size goes. In one 2026 lab study, the IKE_SA_INIT pair stayed small (298 and 371 bytes) because it carried only X25519 public values, while the first IKE_INTERMEDIATE exchange carrying ML-KEM-768 grew to 1,295 and 1,199 bytes, close to the Ethernet MTU. Researchers have also warned that this fragmentation avoidance strategy introduces significant performance penalties in high-latency environments, where each additional round-trip incurs the full network delay.

After a hub reboot, one extra round trip per tunnel is rarely the main problem on its own. It becomes one when combined with queueing: if the hub accepts negotiations more slowly than spokes retry them, every extra exchange lengthens the window in which retransmissions pile up.

How do you avoid rekey storms when many post-quantum tunnels renegotiate at the same time?

Break the synchronization. Randomize lifetimes, let spokes initiate with randomized backoff, and limit how many negotiations the hub admits at once, so a reboot or line restoration doesn’t turn into hundreds of simultaneous handshakes.

Where synchronization comes from

Tunnels that came up together after a hub reboot share the same lifetime timers. Without jitter they rekey together for as long as the hub stays up. Rekeys also carry the post-quantum cost: for Child SAs, RFC 9370 runs the additional exchanges through IKE_FOLLOWUP_KE. Collisions are handled by an existing rule: in the case of simultaneous rekeying, if two identical new IKE SAs (or two pairs of Child SAs) are created, one of them should be deleted. That keeps things correct, but it wastes the work done on the duplicate.

Controls that work in practice

• Lifetime randomization: configure a rekey margin with a random fuzz of 10 to 30 percent on both IKE SA and Child SA lifetimes, so the cohort spreads out within one or two lifetimes.
• Single initiator role: let spokes initiate and rekey, and keep the hub as responder. This halves collision chances and puts the key generation cost on the spokes.
• Randomized reconnect backoff: have spokes wait a random 0 to 60 seconds after dead peer detection fires, instead of retrying at once.
• Admission control on the hub: cap half-open IKE SAs and use the RFC 7296 COOKIE mechanism under load, so excess initiators retry later instead of exhausting state.
• Priority tiers: stagger timers so that control-centre links and protection-signalling sites rekey in a separate window from low-priority telemetry spokes.

Short key lifetimes make this discipline essential rather than optional. Quantum Network’s Quantum Gateway, for example, renews both its classical and its ML-KEM handshake every two minutes. At that cadence, any design that treats handshakes as rare events breaks down quickly.

How many simultaneous post-quantum IKEv2 negotiations can a VPN concentrator handle?

No vendor-neutral published figure exists. The answer depends on the platform, the authentication method and the configured half-open limits, so measure it on your own hardware with a realistic reconnect test.

Use the cycle figures above as a lower bound, not a capacity rating. The ML-KEM part of a negotiation is small. Certificate signature verification, IKE_AUTH processing, fragment reassembly and per-SA memory usually set the ceiling. A meaningful test looks like this:

1. Emulate your real spoke count plus 25 percent growth, with production certificate chains and the ML-KEM-768 transform.
2. Add realistic latency per spoke group (fibre, LTE, satellite) so half-open SAs stay open as long as they would in the field.
3. Run a cold-start test: all spokes initiate within 10 seconds. Record the time until the last tunnel is up, the peak half-open count and the CPU usage per core.
4. Repeat with 1 to 2 percent packet loss to see how retransmissions change the curve.
5. Set the production half-open limit below the point where completion time starts to grow faster than linearly.

The useful number to report internally is “full recovery time after a hub reboot”, not “negotiations per second”. That number maps directly onto how long your remote sites go without protected connectivity.

Should you migrate spokes to hybrid key exchange in phases or all at once?

In phases, for almost every hub and spoke network. RFC 9370 negotiation lets a hub accept hybrid and classical proposals side by side during the transition, so you can move spokes in waves and enforce hybrid-only later.

The initiator’s IKE_SA_INIT SA payload includes the extra key exchange policy it requires, and the responder follows the usual IKEv2 negotiation rules, selecting a single transform of each type. A hub configured to offer ML-KEM as optional can therefore serve upgraded and legacy spokes during the same window.

A practical order: start with sites whose data has the longest confidentiality life, then sites on high-latency links (to validate the MTU and round-trip assumptions), and finally the bulk of the estate. Set a firm date for switching the hub to hybrid-only, because a permanent optional mode leaves a downgrade path open.

How should OT and critical infrastructure operators plan the timeline?

Treat hub capacity and recovery time as part of your post-quantum plan from the start, because national timelines now put high-risk systems in scope this decade.

• NIST IR 8547 proposes that 112-bit security strength algorithms be deprecated after 2030 and disallowed after 2035 (NIST, 2025).
• Experts estimate quantum computers will have enough computing power to break many of the most commonly used forms of cryptography between 2030 and 2040 (NCSC-NL and AIVD, March 2024).

The Dutch NCSC and AIVD advise that “organizations should act now and prepare to make the switch to quantum-secure cryptography.” For zone-and-conduit architectures designed against IEC 62443-3-3, the hub sits on conduits whose confidentiality and availability requirements are assessed together. Capacity tests for rekey storms and reboot recovery belong in the same risk assessment as the choice of algorithm, as does the decision on where encryption ends relative to the firewalls that still need to inspect OT traffic.