{"slug": "the-honest-migration-playbook-ipsec-series-part-11", "title": "The Honest Migration Playbook – IPsec Series, Part 11", "summary": "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.", "body_md": "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.\n\n**Authentication doesn’t work like that.**\n\nThis 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.\n\n## The starting point: RSA certificates\n\nParts 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.\n\nSo 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?\n\n## The asymmetry\n\nCheck the difference in available capabilities between key exchange and authentication:\n\n```\nR1(config-ikev2-proposal)# pqc mlkem768 ?\n  optional  Optionally negotiate PQ key exchange\n  required  Must negotiate PQ key exchange\n\nR1(config-ikev2-profile)# authentication local ?\n  dynamic    Dynamically set local authentication method for responder\n  eap        Extended Authentication Protocol\n  ecdsa-sig  ECDSA Signature\n  mldsa-sig  ML-DSA Signature\n  pre-share  Pre-Shared Key\n  rsa-sig    Rivest-Shamir-Adleman Signature\n```\n\nKey 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.\n\n## One hub, two signature algorithms\n\nSame 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.\n\n```\nR1  ==== Tunnel1, ML-DSA-65 ====  R2  ==== Tunnel2, RSA-2048 ====  R3\n```\n\nBoth tunnels keep `pqc mlkem768 optional`, so the key exchange is quantum-safe on both legs. Only the signatures differ.\n\nOn R2 (hub), one profile per spoke handles this:\n\n```\ncrypto ikev2 profile SPOKE-R1\n match identity remote address 10.0.12.1 255.255.255.255\n identity local address 10.0.12.2\n authentication local mldsa-sig\n authentication remote mldsa-sig\n pki trustpoint TP-MLDSA65\n\ncrypto ikev2 profile SPOKE-R3\n match identity remote address 10.0.23.2 255.255.255.255\n identity local address 10.0.23.1\n authentication local rsa-sig\n authentication remote rsa-sig\n pki trustpoint TP-RSA\n```\n\nHere’s the hub output in this mixed state:\n\n```\nR2# show crypto ikev2 sa\nTunnel-id Local                 Remote                fvrf/ivrf            Status\n2         10.0.12.2/500         10.0.12.1/500         none/none            READY\n      Encr: AES-CBC, keysize: 256, PRF: SHA512, Hash: SHA512, DH Grp:20, Auth sign: MLDSA, Auth verify: MLDSA\n      PQC Key Exchange: ML-KEM-768\n\nTunnel-id Local                 Remote                fvrf/ivrf            Status\n1         10.0.23.1/500         10.0.23.2/500         none/none            READY\n      Encr: AES-CBC, keysize: 256, PRF: SHA512, Hash: SHA512, DH Grp:20, Auth sign: RSA, Auth verify: RSA\n      PQC Key Exchange: ML-KEM-768\n```\n\nOne 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.\n\n## Can you cut over without an outage?\n\nThis is the question that matters operationally. And the answer is **no**. Here’s the experiment.\n\n`authentication remote` is *additive*. Configure two methods and both stay listed:\n\n```\nR2(config-ikev2-profile)# authentication remote mldsa-sig\n\nR2# show running-config | section crypto ikev2 profile SPOKE-R3\ncrypto ikev2 profile SPOKE-R3\n authentication remote rsa-sig\n authentication remote mldsa-sig\n authentication local rsa-sig\n pki trustpoint TP-RSA\n pki trustpoint TP-MLDSA65\n```\n\nSo 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.\n\nIt 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:\n\n```\nR3(config-ikev2-profile)# authentication local mldsa-sig\n\nR3# clear crypto ikev2 sa\nR3# ping 192.168.102.1\n.....\nSuccess rate is 0 percent (0/5)\n\nR3# show logging | include IKEv2\nIKEv2-ERROR:(SESSION ID = 71,SA ID = 1):: Auth exchange failed\n```\n\nBoth 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:\n\n```\nR2(config-ikev2-profile)# authentication local mldsa-sig\n\nR2# show crypto ikev2 sa | include Auth sign\n      Encr: ... DH Grp:20, Auth sign: MLDSA, Auth verify: MLDSA\n      Encr: ... DH Grp:20, Auth sign: MLDSA, Auth verify: MLDSA\n```\n\n## The planning table\n\n|  | Key exchange (ML-KEM) | Authentication (ML-DSA) | \n|---|---|---|\n| Negotiated per session | Yes, `optional` falls back | No, configured per profile | \n| Mixed-version peers | Fine, hub-first rollout works | Fine, but needs one profile per peer | \n| Cutting a peer over | No outage, just renegotiate | Brief outage, both ends together | \n| Rollout unit | The whole hub at once | One peer at a time | \n\nThe 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.\n\n## DFUQ?\n\nOnce the tunnel is fully quantum-safe, `show crypto session detail` reports the status in a compact way:\n\n```\nR1# show crypto session detail\nCode: C - IKE Configuration mode, D - Dead Peer Detection\nK - Keepalives, N - NAT-traversal, T - cTCP encapsulation\nX - IKE Extended Authentication, F - IKE Fragmentation\nR - IKE Auto Reconnect, U - IKE Dynamic Route Update\nS - SIP VPN, E - Stronger IKE Encryption Enforced\nQ - Quantum-safe Encryption\n\nInterface: Tunnel0\nProfile: MLDSA-PROFILE\nSession status: UP-ACTIVE\n  IKEv2 SA: local 10.0.12.1/500 remote 10.0.23.2/500 Active\n          Capabilities:DFUQ connid:2 lifetime:23:59:04\n```\n\nRead 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.\n\n`DFUQ`.\n\nYou 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.\n\n## Look how far we’ve come\n\nEleven parts. Two acts. One story.\n\nIn 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.\n\nYou started Part 1 with a question: is your VPN ready for the quantum era? You can answer it now.\n\nYou 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.\n\nFrom “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.\n\nThat’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.\n\n**Go quantum-proof your network!**", "url": "https://wpnews.pro/news/the-honest-migration-playbook-ipsec-series-part-11", "canonical_source": "https://blogs.cisco.com/developer/the-honest-migration-playbook-ipsec-series-part-11", "published_at": "2026-09-14 19:41:59+00:00", "updated_at": "2026-09-14 23:04:43.819650+00:00", "lang": "en", "topics": ["ai-safety", "ai-policy"], "entities": ["ML-KEM", "ML-DSA", "RSA-2048", "Cisco IOS-XE 26.2", "IPsec", "IKEv2", "PKCS#12", "ECDSA"], "alternates": {"html": "https://wpnews.pro/news/the-honest-migration-playbook-ipsec-series-part-11", "markdown": "https://wpnews.pro/news/the-honest-migration-playbook-ipsec-series-part-11.md", "text": "https://wpnews.pro/news/the-honest-migration-playbook-ipsec-series-part-11.txt", "jsonld": "https://wpnews.pro/news/the-honest-migration-playbook-ipsec-series-part-11.jsonld"}}