up:: In the Protocols MOC

IPsec

IPsec is the protocol suite that secures traffic at the IP layer, the cryptography running underneath most VPNs, site-to-site tunnels, and protected machine-to-machine links. Every tunnel it builds does three jobs: it authenticates the peer gateway on the other end, it negotiates fresh secret keys with that peer, and it encrypts and integrity-protects the packets that flow afterward. The quantum problem with IPsec is narrow and specific. The bulk encryption of the traffic is durable, but the key exchange inside IKE (Internet Key Exchange) rests on classical Diffie-Hellman math that a large quantum computer can solve, so recorded tunnel traffic is exposed to decryption later. The fix is to keep IPsec and swap that key-exchange step for a quantum-safe one.

The short version:

• IPsec is a framework, not one algorithm. It splits into a control plane (IKE, which sets up keys and identity) and a data plane (ESP, which encrypts the packets), and each faces the quantum threat differently.
• The IKE key exchange (classical Diffie-Hellman or ECDH) is the urgent piece. It’s the harvest-now-decrypt-later exposure, because a recorded tunnel can be decrypted once a quantum computer arrives.
• Peer authentication (RSA or ECDSA signatures) is the slower track. Forging it needs a quantum computer live during the handshake, so there’s nothing to harvest, which buys more time.
• The ESP data encryption (AES-256 in an authenticated mode) survives the transition and stays in place with a large key.
• The path to quantum-safe is hybrid key exchange, and RFC 9370 lets IKEv2 run classical (EC)DH plus one or more additional ML-KEM exchanges in the same negotiation, so the tunnel is safe if any one layer holds.

Picture a private armored tunnel dug between two company campuses under a public city. Before packages move, the two gatehouses check each other’s seals so each knows it’s really talking to the other campus (authentication). Then they run a coded back-and-forth over an open channel to agree on a shared combination lock that only the two of them know (key exchange). After that, everything moving through the tunnel travels under that lock (encryption). Quantum computing threatens the coded exchange that sets the combination and the seals on the gatehouse doors. The armored tunnel itself is fine. You don’t fill in the tunnel. You upgrade how the combination gets agreed on and how the seals get signed.

What is IPsec?

IPsec (Internet Protocol Security) is a suite of protocols that secures IP traffic directly at the network layer, so two hosts, two networks, or two sites can communicate privately and with integrity across untrusted infrastructure. Because it works at the IP layer rather than inside an application, one IPsec tunnel can protect every protocol riding on top of it at once, which is why it’s the backbone of VPNs, datacenter interconnects, branch connectivity, and partner links.

Like TLS, IPsec is a framework rather than a single primitive, and it’s built from a few components:

1. ESP (Encapsulating Security Payload) carries the actual protection of the traffic. Per RFC 4303, ESP provides confidentiality, data-origin authentication, connectionless integrity, and an anti-replay service, and in practice it’s the component nearly every modern deployment uses.
2. AH (Authentication Header) provides integrity and data-origin authentication for a packet but no encryption, per RFC 4302. It’s uncommon in enterprise deployments because ESP covers the same integrity ground and adds confidentiality.
3. IKE (Internet Key Exchange), version 2 is the control-plane protocol. Per RFC 7296, IKEv2 authenticates the two peers, negotiates the cryptographic parameters, and establishes the keying material for the tunnel. This is where the public-key cryptography lives.
4. Security Associations (SAs) are the negotiated agreements that hold the chosen algorithms, keys, lifetimes, and traffic selectors for a protected flow.

IPsec runs in two modes. Transport mode protects the payload of the original IP packet and is used host-to-host. Tunnel mode wraps the entire original packet inside a new one and is the mode behind gateway-to-gateway VPNs and site-to-site links.

The takeaway is the same as for any protocol framework: “is IPsec quantum-safe?” has no single answer, because the honest answer depends on which mechanism is doing each job in a given tunnel.

Sources: C. Kaufman, P. Hoffman, Y. Nir, P. Eronen, T. Kivinen, “Internet Key Exchange Protocol Version 2 (IKEv2),” RFC 7296, October 2014 (Internet Standard, STD 79), datatracker.ietf.org.

Source: S. Kent, “IP Encapsulating Security Payload (ESP),” RFC 4303, December 2005, datatracker.ietf.org.

Source: S. Kent, “IP Authentication Header,” RFC 4302, December 2005, datatracker.ietf.org.

Where does cryptography live in IPsec?

Cryptography in IPsec lives in two planes, and only one of them holds the quantum-vulnerable math. Getting the split straight is what tells you where the exposure sits.

The control plane is IKE. This is where the two gateways negotiate and set up the tunnel, and it’s where the public-key cryptography runs. In IKEv2 the setup happens across a small set of exchanges defined in RFC 7296:

1. IKE_SA_INIT negotiates the cryptographic algorithms, exchanges nonces, and performs the Diffie-Hellman key exchange that produces the first shared secret. This is the piece a quantum computer targets.
2. IKE_AUTH authenticates the earlier messages, exchanges identities and certificates, and sets up the first Child SA. The peer authentication here uses signatures (RSA or ECDSA) or pre-shared keys.
3. CREATE_CHILD_SA creates additional Child SAs and rekeys existing ones.
4. INFORMATIONAL carries control messages, errors, and deletion.

The data plane is ESP. Once IKE has established the keys, ESP encrypts and integrity-protects the actual packets flowing through the tunnel, using the symmetric traffic keys IKE derived. No public-key math runs here.

So the crypto that quantum computing threatens is concentrated in the control plane: the key exchange in IKE_SA_INIT and the peer-authentication signatures in IKE_AUTH. The ESP data plane rides on symmetric keys, which are durable. This mirrors the TLS split between a public-key handshake and a symmetric record layer, and the lesson carries over cleanly.

Source: C. Kaufman, et al., “Internet Key Exchange Protocol Version 2 (IKEv2),” RFC 7296, §1.2 (The Initial Exchanges), October 2014, datatracker.ietf.org.

Which parts of IPsec are quantum-vulnerable?

Two of the three cryptographic roles in IPsec are quantum-vulnerable, and they run on different clocks. This is the single most important distinction, because it’s what decides what moves first.

IKE key establishment is the urgent piece. IKEv2’s Diffie-Hellman exchange in IKE_SA_INIT, whether classical finite-field Diffie-Hellman or ECDH, produces the shared secret that seeds every tunnel key. Both rest on the discrete-logarithm problem, which Shor’s algorithm solves on a large enough quantum computer.

The reason this is time-critical is timing itself. An adversary can record a tunnel’s encrypted traffic and its key-exchange messages today, store them, and derive the shared secret years later when a capable quantum computer exists. That’s harvest-now-decrypt-later, and it makes any IPsec traffic that must stay confidential for a long time exposed right now, well before the quantum computer boots.

Peer authentication is the slower track. IKE_AUTH proves each gateway’s identity with a signature, typically RSA or ECDSA, and those signatures are also breakable by Shor’s algorithm. Forging one, though, requires a quantum computer live at the moment the tunnel is being set up, because a signature only matters during authentication. There’s nothing to harvest and no deferred payoff, which makes this a Non-HNDL trust problem rather than a confidentiality one. It still has to be fixed, on a longer runway.

ESP data protection survives. The AES-256 encryption of the traffic isn’t broken by Shor’s algorithm. Its only quantum concern is Grover’s algorithm, which shaves the effective margin of a brute-force search but is answered by using a large key. AES-256 keeps a comfortable margin, so the data plane is a strengthen-in-place item rather than a replacement.

IPsec role	Where it runs	The algorithm today	Quantum threat	Exposure class	Urgency
Key establishment	IKE_SA_INIT (control plane)	DH / ECDH	Broken by Shor’s	HNDL, harvestable today	Highest, migrate first
Peer authentication	IKE_AUTH (control plane)	RSA / ECDSA signatures	Broken by Shor’s	Non-HNDL, needs a live CRQC	Slower track
Traffic encryption	ESP (data plane)	AES-256 authenticated mode	Weakened by Grover’s	Retain and strengthen	Keep AES-256, no swap

The upshot is that IPsec’s most important post-quantum business risk is deferred confidentiality loss from quantum-vulnerable key establishment, and it’s a quantum-vulnerable surface hiding in infrastructure that many teams rarely audit at the cryptographic level.

Source: P. W. Shor, “Polynomial-Time Algorithms for Prime Factorization and Discrete Logarithms on a Quantum Computer,” SIAM J. Comput. 26(5), 1997, arxiv.org.

How does IPsec go post-quantum?

IPsec goes quantum-safe in two moves, and the order follows the two clocks above: fix the harvestable key exchange first, fix the authentication signatures later.

Move one, hybrid key exchange through multiple key exchanges. Standard IKEv2 negotiates exactly one Diffie-Hellman group. RFC 9370, published May 2023 as a Proposed Standard, extends IKEv2 so a Security Association can perform several key exchanges and mix all of their results into one shared secret. It defines seven additional key-exchange slots, ADDKE1 through ADDKE7 (transform types 6 through 12), on top of the original one. A deployment negotiates the classical (EC)DH group as the first exchange and adds a post-quantum exchange in one of the ADDKE slots, and the final key depends on both.

The tunnel stays secure as long as any single component holds, so if ML-KEM later shows a weakness the classical exchange still defends against a classical attacker, and if a quantum computer arrives the ML-KEM exchange still defends against it. That’s the hybrid pattern, the defining move of the whole transition, and it’s the same logic that drives TLS 1.3 Hybrid Key Exchange.

The ML-KEM binding. The specific post-quantum algorithm for IKEv2 is ML-KEM, NIST’s standardized lattice-based key-encapsulation mechanism (FIPS 203, August 2024). The IETF draft draft-ietf-ipsecme-ikev2-mlkem registers ML-KEM-512, ML-KEM-768, and ML-KEM-1024 as key-exchange methods that plug into RFC 9370’s additional-exchange slots, and it reached the RFC Editor queue in 2026. So a fully post-quantum IKEv2 tunnel runs, for example, ECDH plus ML-KEM-768 together and derives its keys from the combination.

The large-payload plumbing. ML-KEM public keys and ciphertexts are far bigger than a classical elliptic-curve value, and IKEv2’s message fragmentation can’t operate during the very first exchange. RFC 9242 solves this with the IKE_INTERMEDIATE exchange (published May 2022, Proposed Standard), a new exchange inserted between IKE_SA_INIT and IKE_AUTH that can carry large data using IKE fragmentation. RFC 9370’s additional key exchanges are carried in IKE_INTERMEDIATE during initial setup, and in IKE_FOLLOWUP_KE for Child SA rekeys, which is what lets a kilobyte-scale ML-KEM value travel without triggering IP-layer fragmentation problems.

Move two, post-quantum authentication. The IKE_AUTH signatures transition later, toward NIST’s standardized signature schemes, ML-DSA as the general-purpose choice and SLH-DSA where a conservative hash-based signature is preferred. This is harder to roll out because it touches the certificate and identity ecosystem behind the gateways, so it moves on a longer timeline. During the overlap, composite certificates and parallel trust chains let peers present both a classical and a post-quantum signature.

ML-KEM parameter set	Public key size	Ciphertext size	Typical fit
ML-KEM-512	800 bytes	768 bytes	Constrained or latency-sensitive links
ML-KEM-768	1,184 bytes	1,088 bytes	General-purpose default
ML-KEM-1024	1,568 bytes	1,568 bytes	Highest assurance, CNSA 2.0 level for national-security systems

Sources: CJ. Tjhai, M. Tomlinson, G. Bartlett, S. Fluhrer, D. Van Geest, O. Garcia-Morchon, V. Smyslov, “Multiple Key Exchanges in the Internet Key Exchange Protocol Version 2 (IKEv2),” RFC 9370, May 2023, datatracker.ietf.org.

Source: V. Smyslov, “Intermediate Exchange in the Internet Key Exchange Protocol Version 2 (IKEv2),” RFC 9242, May 2022, datatracker.ietf.org.

Source: NIST, “Module-Lattice-Based Key-Encapsulation Mechanism Standard,” FIPS 203, August 2024, csrc.nist.gov.

Source: P. Kampanakis, G. Ravago, V. Smyslov, et al., “Post-quantum Key Exchange with ML-KEM in the Internet Key Exchange Protocol Version 2 (IKEv2),” draft-ietf-ipsecme-ikev2-mlkem, RFC Editor queue 2026, datatracker.ietf.org.

What does migrating IPsec actually look like?

Migrating IPsec is a rollout tracked tunnel by tunnel, governed by one rule: a tunnel is only as quantum-safe as the weaker of its two gateways. Both endpoints have to support the same post-quantum key-exchange transforms for a session to negotiate them, and IPsec endpoints are heavily concentrated in appliances and managed services, so the migration is really about getting new transforms supported across a population of gateways that are often controlled by someone other than the data owner.

The reality has a few defining features:

1. The weakest-endpoint rule. If one gateway offers ML-KEM and the peer on the far end doesn’t, the negotiation falls back to a classical group and the HNDL exposure stays open for that tunnel. Coverage across both ends is what closes the exposure, so a partner tunnel or a legacy branch gateway that hasn’t moved reopens the door for everything behind it.
2. Firmware sets the pace. IPsec is terminated on VPN concentrators, firewalls, SD-WAN and SASE appliances, and cloud networking gateways. Support for RFC 9370 multiple key exchanges and the ML-KEM transforms arrives when the vendor ships firmware that implements them, so much of the timeline is set by vendor roadmaps rather than internal effort. These are vendor surfaces, and appliance refresh cycles are measured in years.
3. Both sides of every tunnel move together. Unlike a browser reaching a public server, an IPsec tunnel usually joins two organizations or two internal sites that each own their gateway. Upgrading a partner-facing tunnel is a coordinated change on both ends, which turns a technical upgrade into a scheduling-and-contracts problem across organizations.
4. Visibility is harder than it looks. The presence of a VPN tells you nothing about which Diffie-Hellman group, authentication method, or transform a given tunnel actually negotiated. Configuration documents describe intended policy, and the negotiated reality can differ. Seeing the true cryptographic posture takes configuration-level and negotiated-parameter inspection, which is the evidence a CBOM is built to capture.

Underneath all of it, this is a crypto-agility problem. Gateways that can negotiate new key-exchange groups and retire old ones without breaking a tunnel migrate smoothly, and gateways hard-wired to one Diffie-Hellman group have to be replaced before they can move at all.

What are the interop and deployment traps?

The traps in post-quantum IPsec cluster around the size of ML-KEM values and the age of the gear in the path. Three come up repeatedly:

1. Oversized initial messages. A classical elliptic-curve key value is tens of bytes. An ML-KEM public key or ciphertext runs from roughly 800 bytes to over 1,500 bytes (see the parameter table above), which can push IKE messages past a single UDP datagram. That’s exactly why RFC 9242’s IKE_INTERMEDIATE exchange exists, and a deployment that tries to carry post-quantum key exchange without IKE_INTERMEDIATE and IKE fragmentation runs straight into IP-layer fragmentation, dropped packets, and stalled tunnels.
2. Constrained and high-latency links raise the parameter-versus-latency tension. On satellite and other bandwidth- or latency-constrained links, the extra round trip and larger payloads of the post-quantum exchange become a real cost, and MTU limits before IKE fragmentation is active can cap the achievable parameter size. Research on quantum-safe IKEv2 for satellite communications shows latency-optimal configurations gravitating to ML-KEM-512 or ML-KEM-768 to stay MTU-safe, which collides with the CNSA 2.0 requirement of ML-KEM-1024 for national-security systems. Constrained environments have to trade parameter strength against link budget in a way ordinary datacenter links never notice.
3. Middleboxes and legacy appliances in the path. Firewalls, NAT devices, and older concentrators written before large IKE payloads were common can mishandle fragmented or intermediate exchanges. Both endpoints supporting the new transforms still leaves a gap if a device between them silently drops the larger messages, so rollouts have to test the whole network path end to end, including every hop between the two gateways.

How urgent is the IPsec migration?

IPsec key exchange is one of the more time-sensitive items in the transition, and Mosca’s theorem is the clean way to see it. Mosca frames the decision as three numbers: X, how long the tunnel-protected data must stay confidential; Y, how long the migration takes; and Z, how long until a capable quantum computer exists. When X plus Y is greater than Z, the data is already exposed. IPsec often protects long-lived, high-value infrastructure traffic, datacenter interconnects, partner data exchange, administrative channels, and its migration Y is long because it depends on vendor firmware and cross-organization coordination. For anything that must stay secret for a decade, the harvestable window is open now, which is why IPsec key exchange belongs in the early phase of a transition rather than a later cleanup.

The authentication side is genuinely less urgent, because it’s a live-trust problem with nothing to harvest, so the honest prioritization is key exchange first and signatures on a longer runway.

Common misconceptions

• “We run a VPN, so we’re covered.” A working VPN tells you a tunnel exists, and it says nothing about which key-exchange group or authentication method it negotiated. A tunnel using classical ECDH is fully functional and fully harvestable at the same time.
• “Quantum computers break IPsec.” The protocol suite holds. The vulnerable parts are the IKE key exchange and the peer-authentication signatures, and the fix swaps those mechanisms while keeping IPsec, ESP, and the tunnel architecture. The ESP encryption of the traffic is fine.
• “The authentication problem is the one to fix first.” It’s the reverse. Peer-authentication signatures need a quantum computer live during setup, so there’s nothing to harvest. The IKE key exchange is harvestable today, which makes it the piece to migrate first.
• “ESP with AES needs replacing too.” It needs a large key, not a new algorithm. AES-256 keeps a comfortable margin against Grover’s algorithm, so the data plane is a strengthen-in-place item.
• “Turning on ML-KEM is a config flag and we’re done.” The flag is the easy part. A tunnel only goes hybrid when both gateways support the transforms, so the real work is coverage across every appliance, managed service, and partner endpoint in the path.
• “IPsec and TLS are the same migration.” They share the hybrid-key-exchange logic, and the operational shape differs. TLS termination is often a single side you control, where an IPsec tunnel usually joins two independently owned gateways that must upgrade in lockstep.

Questions people ask

What actually changes in IPsec for post-quantum? The IKE key exchange changes first. Under RFC 9370, IKEv2 runs the classical (EC)DH group plus an additional ML-KEM key exchange and mixes both into the shared secret. Peer-authentication signatures change later, toward ML-DSA or SLH-DSA. The ESP encryption of the traffic stays the same with AES-256.

Do I have to replace IPsec or my VPN? Usually not. IPsec is modernized in place by upgrading the key-establishment and authentication mechanisms inside IKE, most of which arrives through gateway and appliance firmware updates rather than a protocol swap. The tunnel architecture, ESP, and the traffic encryption carry forward.

What’s hybrid key exchange in IPsec, in one line? Running a classical and a post-quantum key exchange in the same IKEv2 negotiation and combining both into the tunnel keys, so the tunnel stays secure as long as either one holds. RFC 9370 is the standard that makes IKEv2 do it, with up to seven additional exchanges alongside the original.

Is post-quantum IPsec ready to deploy today? The framework is standardized. RFC 9370 (multiple key exchanges) and RFC 9242 (the IKE_INTERMEDIATE exchange for large payloads) are published standards-track RFCs, and the ML-KEM-for-IKEv2 binding reached the RFC Editor queue in 2026. Availability in practice tracks whether your specific gateway vendor has shipped firmware that implements them.

What breaks in production when I turn on post-quantum key exchange? The most common failure comes from message size. ML-KEM values are large enough to exceed a single datagram, and a deployment that carries them without the IKE_INTERMEDIATE exchange and IKE fragmentation runs into IP-layer fragmentation and dropped tunnels. Older middleboxes in the path can also mishandle the larger exchanges, so testing the full path matters.

Which ML-KEM parameter set should a tunnel use? ML-KEM-768 is the sensible general-purpose default. National-security systems under CNSA 2.0 are directed to ML-KEM-1024. Constrained and high-latency links, such as satellite, sometimes settle on ML-KEM-512 or ML-KEM-768 to stay within MTU limits, which trades some parameter strength for link budget.

Does IPsec key exchange need a quantum computer to break? For confidentiality, the exposure is deferred: an attacker records the tunnel now and decrypts it once a quantum computer exists, which is the harvest-now-decrypt-later problem. That deferred exposure is what makes the classical IKE key exchange urgent even though no quantum computer exists yet.

Why does IPsec deserve early attention next to TLS? IPsec frequently protects long-lived, high-value infrastructure traffic, and its key exchange is harvestable today, so under Mosca’s theorem the data with a long confidentiality lifetime is already exposed. Its migration also runs slower than most application-layer changes because it depends on vendor firmware and coordination across two tunnel owners, so starting early is what keeps the timeline honest.

---

Everything here is the map, given freely. When your team needs its own IPsec estate found, its harvestable tunnels prioritized, and a hybrid rollout sequenced across every gateway, appliance, and partner endpoint, defensible to your board and your auditor, that’s the work I do, and there’s an alignment briefing for it.

Last verified 2026-07-09 · Maintained by Addie LaMarr, LaMarr Labs.