IKEv1 deprecated: post-quantum VPN options for OT sites

IKEv1 is the first version of the Internet Key Exchange protocol, used to set up IPsec VPN tunnels. The IETF has formally deprecated it, and it cannot negotiate post-quantum key exchange. A post-quantum VPN uses a key exchange that stays secure against future quantum computers, usually hybrid ML-KEM plus classical Diffie-Hellman, and that is only standardised for IKEv2. For OT operators, this means every remaining IKEv1 tunnel between substations, pumping stations or plants has to be migrated.

This article explains why IKEv1 has no route to quantum safety, how to find the IKEv1 tunnels still running, what it costs to keep weak Diffie-Hellman groups until 2030, and how to migrate a peer that sits at a remote, unmanned site.

Can IKEv1 VPNs be made quantum safe?

No. IKEv1 is frozen. The standards that add post-quantum key exchange to IPsec are written for IKEv2 only, and no equivalent will ever be written for IKEv1.

RFC 9395 makes this explicit. It records that IKEv1 and the IPsec DOI were obsoleted by IKEv2 [RFC4306] in December 2005, and that no new modifications or new algorithms have been accepted for IKEv1 for at least a decade. The working group also asked IANA to close the IKEv1 registries, so there is no codepoint where an ML-KEM transform for IKEv1 could go. Paul Wouters, who edited the deprecation work, put the consequence plainly: “Systems running IKEv1 should be upgraded and reconfigured to run IKEv2.”

One nuance comes up in OT discussions. IKEv1 mixes a pre-shared key into its key derivation, and the deprecation text acknowledges that IKEv1 and its way of using Preshared Keys (PSKs) protects against certain quantum attacks. That protection depends entirely on a long, random, secret PSK, and it does not hold in aggressive mode (see below). The IKEv2 replacement is the post-quantum preshared key mechanism: RFC 8784 (2020) introduces this “Post-quantum Preshared Key” extension to augment IKEv2 with entropy from a pre-shared secret. That still means IKEv2.

Why do hybrid ML-KEM site-to-site VPNs require IKEv2?

Hybrid ML-KEM depends on protocol machinery that exists only in IKEv2: the IKE_INTERMEDIATE exchange, the generalised key exchange registry and the multiple key exchange framework of RFC 9370.

RFC 7296 defines IKEv2 itself. RFC 9370 builds on it and describes how to extend the Internet Key Exchange Protocol Version 2 (IKEv2) to allow multiple key exchanges to take place while computing a shared secret during a Security Association (SA) setup. In practice, the additional key exchanges are performed using IKE_INTERMEDIATE messages that follow the IKE_SA_INIT exchange. RFC 9370 also renamed the Diffie-Hellman group registry so it can hold KEMs, which generalize key exchange algorithms that can be used in IKEv2.

The IETF IPSECME draft for ML-KEM then plugs into this framework. It specifies how to use ML-KEM by itself or as an additional key exchange in IKEv2 along with a traditional key exchange. Because both secrets feed the session keys, an attacker must break all key exchanges to defeat the security.

The fragmentation row matters for OT links. ML-KEM public keys and ciphertexts are much larger than an ECDH share, and NIST SP 800-77 Rev. 1 warns that oversized IKE packets get fragmented and too often, those fragments will be dropped by a firewall. Performance is less of a concern: the draft authors Panos Kampanakis and Gerardo Ravago state that ML-KEM-512, ML-KEM-768 and ML-KEM-1024 key exchanges will not have noticeable performance impact on IKEv2/IPsec tunnels that stay up for long periods.

How do you find remaining IKEv1 and aggressive mode tunnels between OT sites?

Combine passive observation of UDP 500 and 4500 traffic with a configuration export from every VPN endpoint, then reconcile the two lists. Neither source is complete on its own.

Passive identification on the wire

Every ISAKMP header carries a version field and an exchange type, both sent in the clear. Major version 1 means IKEv1, and major version 2 means IKEv2. Within IKEv1, exchange type 2 is main mode (identity protection) and exchange type 4 is aggressive mode. A span port or network tap at each site’s WAN edge, filtered to UDP 500 and 4500, is enough to build an inventory without sending a single packet toward OT equipment. This matters where controllers or legacy appliances react badly to active probing.

Long rekey intervals mean you need a long capture window. A tunnel configured with an 8 or 24 hour phase 1 lifetime may not renegotiate during a short capture, so plan to observe for several days, or trigger a controlled rekey during a maintenance window.

Configuration and peer review

• Export the crypto configuration from head-end concentrators. Hub sites often accept IKEv1 as a fallback even when most spokes use IKEv2, and that fallback is itself an exposure.
• Look for aggressive mode tied to dynamic-IP peers such as cellular routers at remote sites. NIST notes that aggressive mode can be used with pre-shared secret key authentication for hosts without fixed IP addresses, which is exactly why it persists in OT.
• Record the DH group, PSK or certificate authentication, and the owner for each tunnel. Third-party maintenance tunnels from integrators are frequently undocumented.

Aggressive mode deserves top priority. NIST warned in the original SP 800-77 that “with the increased speed of aggressive mode comes decreased security”, because the parties do not have an opportunity to negotiate the Diffie-Hellman parameters and the negotiations are also susceptible to pre-shared key cracking. NIST SP 800-77 Rev. 1 now lists IKEv2 as recommended and IKEv1 and Aggressive Mode under legacy.

What are the risks of keeping legacy Diffie-Hellman groups on site-to-site VPNs until 2030?

The risk has two parts. Weak groups are exposed to classical attacks today, and any recorded traffic stays exposed to future quantum decryption, whichever classical group protected it.

The dates that matter come from NIST IR 8547:

The NIST IR 8547 tables list DH and MQV together with RSA and ECDSA under these deadlines. The practical problem for critical infrastructure is that 2030 is a regulatory date, not a security date. Data in transit today, such as SCADA historian replication, engineering workstation sessions and protection relay settings, can be recorded now and decrypted once a capable quantum computer exists. Network diagrams, control logic and credentials often stay valid for ten years or longer. Groups 1, 2 and 5 (768, 1024 and 1536-bit MODP) are already below NIST’s 112-bit floor. Group 14 and the ECP groups will meet that floor until 2030, but they offer no protection against harvest-now, decrypt-later collection.

Ranking therefore matters. Start with tunnels that carry long-lived engineering data, then move to tunnels that carry only short-lived telemetry. Do not rank by bandwidth or site size.

How do you migrate an IKEv1 tunnel to IKEv2 when the remote peer is an old appliance at an unmanned site?

First establish whether the appliance can run IKEv2 at all. Then pick one of three paths: an in-place reconfiguration with a rollback timer, replacing the appliance, or an overlay that protects the legacy tunnel until replacement.

Step 1: verify capability before anyone drives out

Check the firmware release notes for IKEv2, RFC 7383 fragmentation and RFC 9370 support. Many appliances from the 2010s support IKEv2 but not multiple key exchanges, so they can leave IKEv1 behind but cannot reach hybrid ML-KEM. Reproduce the exact firmware on a lab unit and run the new IKEv2 proposal against your head-end before touching production.

Step 2: build the new tunnel next to the old one

Configure a parallel IKEv2 tunnel at the head-end with distinct traffic selectors or a separate routed interface, and leave the IKEv1 tunnel up. Move traffic by changing routes rather than by deleting the old configuration. If the device supports it, schedule an automatic configuration revert, so a failed cutover restores the IKEv1 tunnel without a site visit. Make sure an independent out-of-band path, such as a separate cellular management link, exists before the change window.

Step 3: when the appliance cannot do IKEv2

An overlay works because it does not depend on the old appliance’s IKE implementation. The QPN gateway from Quantum Network is one example of this pattern. It is placed at each end of the connection and encrypts at Layer 3 using a hybrid key agreement (classical plus ML-KEM, FIPS 203) that renews every two minutes. It co-exists with existing firewalls and routers and is integrated by adding or adapting a few routes, which suits sites where nobody is on hand to re-cable equipment. It protects data in transit only, so it does not replace the appliance upgrade on your roadmap.

What should an IKEv1 retirement plan for OT include?

A workable plan links an inventory, a priority order and a target configuration to dates that fall before NIST’s 2030 deprecation point.

NIST’s post-quantum project summarises the starting point: organizations must identify where vulnerable algorithms are used and plan to replace or update them. For site-to-site VPNs in OT, that means five things. Keep a reconciled tunnel inventory showing IKE version, mode and DH group. Rank tunnels by how long the data they carry stays sensitive. Set a target profile of IKEv2 with a classical group plus ML-KEM through RFC 9370, with RFC 7383 fragmentation enabled. Write a per-site cutover method that includes rollback and out-of-band access. Set a fixed date to disable IKEv1 at every head-end. Sites that cannot reach that profile on existing hardware need either a replacement date or an interim overlay, written down and owned by a named person.