The Honest Migration Playbook – IPsec Series, Part 11

Migrating IPsec authentication from RSA-2048 certificates to ML-DSA across a multi-router network cannot be done without an outage, because authentication requires selecting a single signature method with no fallback, unlike ML-KEM key exchange which supports an optional negotiation mode. The finding comes from a hands-on migration experiment on Cisco IOS-XE 26.2 using three routers, where a hub (R2) ran two IKEv2 profiles simultaneously — ML-DSA-65 to spoke R1 and RSA-2048 to spoke R3 — both with ML-KEM-768 key exchange, a mixed state the author says can be maintained for months. The author notes that most production IPsec networks use RSA or ECDSA certificates from an internal CA rather than the pre-shared keys used in Parts 9 and 10, making the RSA-to-ML-DSA path the realistic migration baseline.

Part 9 migrated the key exchange across three routers, and it was smooth. The Hub router negotiates ML-KEM when it can and falls back when it can’t. You upgrade the hub, roll out to spokes at your own pace, zero outage. Authentication doesn’t work like that. This post is the operational reality: migrating ML-DSA authentication across a multi-router network, the experiments that show exactly where it breaks, and every gotcha we hit on 26.2. If you’re planning a PQC migration this is the post to read slowly. The starting point: RSA certificates Parts 9 and 10 used pre-shared keys for authentication. That kept things simple while we focused on key exchange and then on the ML-DSA certificate workflow. But most production IPsec networks don’t run PSK at scale. They use RSA or ECDSA certificates issued by an internal CA. So for this migration experiment, we start from a more realistic baseline: RSA-2048 certificates on all three routers , imported via PKCS 12 the same way we imported ML-DSA in Part 10. Same process, classical algorithm. The question is: how do you get from RSA to ML-DSA across a live network? The asymmetry Check the difference in available capabilities between key exchange and authentication: R1 config-ikev2-proposal pqc mlkem768 ? optional Optionally negotiate PQ key exchange required Must negotiate PQ key exchange R1 config-ikev2-profile authentication local ? dynamic Dynamically set local authentication method for responder eap Extended Authentication Protocol ecdsa-sig ECDSA Signature mldsa-sig ML-DSA Signature pre-share Pre-Shared Key rsa-sig Rivest-Shamir-Adleman Signature Key exchange offers optional . But for authentication you need to go with one method, no fallback. You pick mldsa-sig or rsa-sig or pre-share , period. That difference drives the entire migration strategy. One hub, two signature algorithms Same topology as Part 9’s phased migration. R2 is the hub with two tunnels. R1 is the already-migrated spoke ML-DSA certificates . R3 is still running classical RSA. R1 ==== Tunnel1, ML-DSA-65 ==== R2 ==== Tunnel2, RSA-2048 ==== R3 Both tunnels keep pqc mlkem768 optional , so the key exchange is quantum-safe on both legs. Only the signatures differ. On R2 hub , one profile per spoke handles this: crypto ikev2 profile SPOKE-R1 match identity remote address 10.0.12.1 255.255.255.255 identity local address 10.0.12.2 authentication local mldsa-sig authentication remote mldsa-sig pki trustpoint TP-MLDSA65 crypto ikev2 profile SPOKE-R3 match identity remote address 10.0.23.2 255.255.255.255 identity local address 10.0.23.1 authentication local rsa-sig authentication remote rsa-sig pki trustpoint TP-RSA Here’s the hub output in this mixed state: R2 show crypto ikev2 sa Tunnel-id Local Remote fvrf/ivrf Status 2 10.0.12.2/500 10.0.12.1/500 none/none READY Encr: AES-CBC, keysize: 256, PRF: SHA512, Hash: SHA512, DH Grp:20, Auth sign: MLDSA, Auth verify: MLDSA PQC Key Exchange: ML-KEM-768 Tunnel-id Local Remote fvrf/ivrf Status 1 10.0.23.1/500 10.0.23.2/500 none/none READY Encr: AES-CBC, keysize: 256, PRF: SHA512, Hash: SHA512, DH Grp:20, Auth sign: RSA, Auth verify: RSA PQC Key Exchange: ML-KEM-768 One hub, two tunnels, two different signature algorithms, both with ML-KEM-768. That’s a perfectly reasonable place to sit for months while you work through your network. Can you cut over without an outage? This is the question that matters operationally. And the answer is no . Here’s the experiment. authentication remote is additive . Configure two methods and both stay listed: R2 config-ikev2-profile authentication remote mldsa-sig R2 show running-config | section crypto ikev2 profile SPOKE-R3 crypto ikev2 profile SPOKE-R3 authentication remote rsa-sig authentication remote mldsa-sig authentication local rsa-sig pki trustpoint TP-RSA pki trustpoint TP-MLDSA65 So both ends can be told to accept either signature type, and the running tunnel stays up while you do it. Looks like the setup for a clean make-before-break: teach both ends to accept both, flip one side, flip the other. It doesn’t work like that. Flip only R3’s authentication local to mldsa-sig so R3 signs with ML-DSA while R2 still signs with RSA , and the tunnel dies: R3 config-ikev2-profile authentication local mldsa-sig R3 clear crypto ikev2 sa R3 ping 192.168.102.1 ..... Success rate is 0 percent 0/5 R3 show logging | include IKEv2 IKEv2-ERROR: SESSION ID = 71,SA ID = 1 :: Auth exchange failed Both peers listed both methods and it still failed. The two ends have to present the same signature type, so the authentication cutover is atomic per peer . Change authentication local on both ends together and the tunnel comes straight back: R2 config-ikev2-profile authentication local mldsa-sig R2 show crypto ikev2 sa | include Auth sign Encr: ... DH Grp:20, Auth sign: MLDSA, Auth verify: MLDSA Encr: ... DH Grp:20, Auth sign: MLDSA, Auth verify: MLDSA The planning table | | Key exchange ML-KEM | Authentication ML-DSA | |---|---|---| | Negotiated per session | Yes, optional falls back | No, configured per profile | | Mixed-version peers | Fine, hub-first rollout works | Fine, but needs one profile per peer | | Cutting a peer over | No outage, just renegotiate | Brief outage, both ends together | | Rollout unit | The whole hub at once | One peer at a time | The practical recipe: keep one IKEv2 profile per peer or per migration group on the hub. Stage the certificates everywhere first. Then flip peers in maintenance windows. Don’t expect the optional trick from Part 9 to save you here. And once every peer is migrated, drop the leftover authentication remote rsa-sig lines so a downgrade isn’t silently accepted. DFUQ? Once the tunnel is fully quantum-safe, show crypto session detail reports the status in a compact way: R1 show crypto session detail Code: C - IKE Configuration mode, D - Dead Peer Detection K - Keepalives, N - NAT-traversal, T - cTCP encapsulation X - IKE Extended Authentication, F - IKE Fragmentation R - IKE Auto Reconnect, U - IKE Dynamic Route Update S - SIP VPN, E - Stronger IKE Encryption Enforced Q - Quantum-safe Encryption Interface: Tunnel0 Profile: MLDSA-PROFILE Session status: UP-ACTIVE IKEv2 SA: local 10.0.12.1/500 remote 10.0.23.2/500 Active Capabilities:DFUQ connid:2 lifetime:23:59:04 Read the capability letters against the legend: D is Dead Peer Detection, F is IKE Fragmentation, U is IKE Dynamic Route Update, Q is Quantum-safe Encryption. DFUQ . You cannot make these things up… 🙂 DFUQ is what a healthy post-quantum tunnel looks like on IOS XE. Dead Peer Detection, Fragmentation, Dynamic Route Update, Quantum-safe Encryption. All green. That’s the finish line. Look how far we’ve come Eleven parts. Two acts. One story. In the container labs you built every moving part yourself: hybrid key exchange, the PPK alternative, the certificate size explosion, a live ML-DSA tunnel on your laptop. Then we took the same RFCs to three Cisco 8000 routers: ML-KEM with a phased rollout, ML-DSA certificates from an external CA, and the migration playbook that tells you where the platform is ready and where it still hurts. You started Part 1 with a question: is your VPN ready for the quantum era? You can answer it now. You know which pillar is urgent. Key exchange: harvest now, decrypt later, fix it with ML-KEM hybrid or PPK as a stopgap . You know which one has the sneakier deadline. Authentication: long-lived trust anchors, forged identities, fix it with ML-DSA. You know what those fixes cost on the wire ~24 KB per handshake for a fully quantum-safe tunnel on IOS XE, not per packet . And you know the migration isn’t symmetric: key exchange rolls out with “optional”, authentication cuts over atomically, one peer at a time, in a maintenance window. From “what even is post-quantum cryptography?” to watching both pillars negotiate on production hardware. The headlines about quantum computers breaking the internet? They stop being scary once you’ve seen a tunnel come up with your own eyes. That’s the series. Containers first, Cisco second, honest about the rough edges throughout. If you’re planning a migration, you now have a map. If you’re still exploring, you know exactly where to start. Go quantum-proof your network