{"slug": "post-quantum-key-exchange-on-cisco-routers-ipsec-series-part-9", "title": "Post-Quantum Key Exchange on Cisco Routers – IPsec Series, Part 9", "summary": "Cisco Systems Inc. has added ML-DSA signatures for IKEv2 in IOS XE 26.2, enabling quantum-safe site-to-site IPsec tunnels on the Cisco 8000 Series Secure Router (C8235-G2). The update, verified on hardware, supports ML-KEM-768 hybrid key exchange, RFC 8784 PPK, ML-DSA-44/65/87 signatures, IKEv2 fragmentation for PQC payloads, and ML-DSA certificates via external CA + PKCS#12 import, making the platform quantum-safe end to end.", "body_md": "Over the first 8 parts of this series we built quantum-safe VPN tunnels on your laptop, using containers. That’s how you learn protocols: in a clean environment where everything is under your control.\n\nBut running a VPN in a container is not the usual setup in production. At some point the question changes from “does the protocol work?” to “does the *platform* work?”. This is where we go find out.\n\n## The hardware\n\nThe platform I’ve used for this exercise is part of the **Cisco 8000 Series Secure Router**, specifically the C8235-G2. Three of them, wired back to back, running **IOS XE 26.2** with the “advantage” license (which unlocks all crypto features).\n\nWhy 26.2? Because 26.1 gave you post-quantum *key exchange* (ML-KEM) and left authentication classical. **26.2 adds ML-DSA signatures for IKEv2**, so a site-to-site tunnel can now be quantum-safe end to end. Both pillars in one box.\n\n## The lab\n\n3 routers, 2 VLANs, 1 hub-and-spoke topology that stays the same for everything that follows:\n\n```\n    ┌──────────────┐          ┌──────────────┐          ┌──────────────┐\n    │      R1      │          │      R2      │          │      R3      │\n    │   (Spoke-1)  │          │ (Hub/Transit)│          │   (Spoke-2)  │\n    │              │          │              │          │              │\n    │  Vlan12      │          │  Vlan12      │          │              │\n    │  10.0.12.1   │          │  10.0.12.2   │          │              │\n    │              │  VLAN 12 │              │          │              │\n    │      Tw0/0/0 ├──────────┤ Tw0/0/0      │          │              │\n    │              │  2.5 Gb  │              │          │              │\n    │              │          │  Vlan23      │          │  Vlan23      │\n    │              │          │  10.0.23.1   │          │  10.0.23.2   │\n    │              │          │              │  VLAN 23 │              │\n    │              │          │      Tw0/0/1 ├──────────┤ Tw0/0/0      │\n    │              │          │              │  2.5 Gb  │              │\n    └──────────────┘          └──────────────┘          └──────────────┘\n```\n\nR2 sits in the middle as a Layer 3 transit router. The IPsec tunnel runs end to end between R1 and R3, traversing R2 as an intermediate hop to emulate a real WAN where crypto endpoints are not directly connected.\n\nLater, when we test phased migration, R2 becomes a VPN hub terminating tunnels to both spokes. Same 3 boxes, different role for the one in the middle.\n\n## IOS XE 26.2 support\n\nHere’s the honest status, verified on hardware:\n\n| Feature | Status on 26.2 |\n|---|---|\n| ML-KEM-768 hybrid key exchange | Working |\n| RFC 8784 PPK | Working |\n| ML-DSA-44 / 65 / 87 signatures | Working |\n| IKEv2 fragmentation for PQC payloads | Working |\n| ML-DSA certificates via external CA + PKCS#12 import | Working |\n\nThe container labs were clean: you installed a package, wrote a config, and things worked. On IOS XE the *concepts* are identical (same RFCs, same algorithms, same threat model)\n\nThe format for this post, and the next two, is different from the container posts. You won’t be typing along (unless you have some 8000 Secure Routers lying around), but you’ll see every command and every piece of `show`\n\noutput exactly as it came off the router. The goal isn’t to hand you a recipe; it’s to show you what post-quantum IPsec looks like in production, so you know exactly what to expect when your own migration starts.\n\n## Start classical\n\nFirst, the tunnel between R1 and R3. R2 just forwards packets between them (Layer 3 transit), emulating a real WAN where the crypto endpoints aren’t directly connected.\n\nHere’s the IKEv2 config on R1:\n\n```\ncrypto ikev2 proposal CLASSICAL-PROPOSAL\n encryption aes-cbc-256\n integrity sha512\n group 20\n\ncrypto ikev2 policy CLASSICAL-POLICY\n proposal CLASSICAL-PROPOSAL\n\ncrypto ikev2 keyring CLASSICAL-KEYRING\n peer R3\n  address 10.0.23.2\n  pre-shared-key C1sco12345psk\n\ncrypto ikev2 profile CLASSICAL-PROFILE\n match identity remote address 10.0.23.2 255.255.255.255\n authentication remote pre-share\n authentication local pre-share\n keyring local CLASSICAL-KEYRING\n\ncrypto ipsec transform-set CLASSICAL-TS esp-gcm 256\n mode tunnel\n\ncrypto ipsec profile CLASSICAL-IPSEC\n set transform-set CLASSICAL-TS\n set ikev2-profile CLASSICAL-PROFILE\n\ninterface Tunnel0\n ip address 192.168.100.1 255.255.255.0\n tunnel source Vlan12\n tunnel destination 10.0.23.2\n tunnel mode ipsec ipv4\n tunnel protection ipsec profile CLASSICAL-IPSEC\n```\n\nR3 mirrors it (peer address 10.0.12.1, tunnel IP 192.168.100.2).\n\nA quick note on `group 20`\n\n. That’s ECDH-384, the NIST P-384 curve. In the container labs, strongSwan used X25519 (Curve25519). Both are elliptic-curve Diffie-Hellman doing the same job: two peers agree on a shared secret without sending it over the wire. From a PQC perspective they’re equally “classical” and equally vulnerable to Shor’s algorithm. IOS XE uses group 20 because it’s natively supported and gives a higher security margin. The PQC story doesn’t change.\n\nVerify the tunnel is up:\n\n```\nR1# show crypto ikev2 sa\nTunnel-id Local                 Remote                fvrf/ivrf            Status\n1         10.0.12.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: PSK, Auth verify: PSK\n      Life/Active Time: 86400/8 sec\n\nR1# ping 192.168.100.2\n!!!!!\nSuccess rate is 100 percent (5/5), round-trip min/avg/max = 1/1/4 ms\n```\n\n`DH Grp:20, Auth sign: PSK, Auth verify: PSK`\n\n. Classical key exchange, classical authentication. This is the baseline.\n\nOne thing worth making explicit: the pre-shared-key in the keyring is for **authentication only**. It proves R1 is really talking to R3, not an attacker. The actual tunnel encryption key comes from the DH exchange (group 20). Swap PSK for certificates and the tunnel encryption doesn’t change at all. Part 10 does exactly that swap.\n\n## Add a PPK\n\nSame approach as Part 5, just with Cisco CLI. A Postquantum Preshared Key (PPK) gets mixed into the IKE key derivation. The PPK never travels on the wire, so even if a future quantum computer breaks the DH exchange from a recording, it still can’t derive the session keys without the secret it never saw.\n\nThe config goes inside the existing keyring on **both R1 and R3**:\n\n```\ncrypto ikev2 keyring CLASSICAL-KEYRING\n peer R3\n  ppk manual id PPK-R1R3 key hex 48656C6C6F506F737451756172746E756D required\n\ncrypto ikev2 profile CLASSICAL-PROFILE\n keyring ppk CLASSICAL-KEYRING\n```\n\n`required`\n\nmeans the tunnel won’t come up without PPK. Both sides need the same ID and key.\n\nClear the SA and let it renegotiate:\n\n```\nR1# clear crypto ikev2 sa\nR1# ping 192.168.100.2\n!!!!!\n```\n\nCheck the result:\n\n```\nR1# show crypto ikev2 sa detailed | include Quantum\n      Quantum-safe Encryption using Manual PPK\n\nR1# show crypto ikev2 stats | include Quantum\nSessions with Quantum Resistance: 1        Manual: 1        Dynamic: 0\n```\n\nThat’s it. Same classical DH exchange underneath, but the derived keys now also depend on a secret that was never transmitted.\n\nThe operational catch is the same too: every peer pair needs the same secret provisioned and rotated out of band. That’s the classic key-distribution headache that public-key crypto was invented to avoid, which is exactly why PPK is a transitional step.\n\n## Remove the PPK\n\nPPK proved the concept: you can protect the key derivation against quantum attacks without changing the underlying DH exchange. But once the platform supports ML-KEM natively, you don’t need the out-of-band key anymore. Let’s remove PPK before moving on.\n\nOn **both R1 and R3**:\n\n```\ncrypto ikev2 profile CLASSICAL-PROFILE\n no keyring ppk CLASSICAL-KEYRING\n\ncrypto ikev2 keyring CLASSICAL-KEYRING\n peer R3\n  no ppk manual id PPK-R1R3\n```\n\nClear the SA:\n\n```\nR1# clear crypto ikev2 sa\nR1# ping 192.168.100.2\n!!!!!\n```\n\nBack to the baseline: classical DH, classical PSK, no quantum protection. Now we add the real thing.\n\n## Native ML-KEM hybrid\n\nStarting with 26.1, IOS XE natively supports ML-KEM for IPsec tunnels. Two lines on **both R1 and R3**:\n\n```\ncrypto ikev2 fragmentation mtu 1400\n\ncrypto ikev2 proposal CLASSICAL-PROPOSAL\n pqc mlkem768 optional\n```\n\nThat’s it. `pqc mlkem768 optional`\n\nadds ML-KEM to the proposal (`optional`\n\nmeans: use it if the peer supports it, fall back to classical if it doesn’t). The `fragmentation`\n\ncommand is needed because ML-KEM adds about 1.5 KB to the IKE exchange, same problem we measured in Part 3, same solution: IKEv2 fragmentation splits the oversized messages into pieces that fit in a single UDP datagram.\n\nClear the SA:\n\n```\nR1# clear crypto ikev2 sa\nR1# ping 192.168.100.2\n....!\n```\n\nFirst few pings may time out while the larger handshake completes.\n\nNow look at the tunnel:\n\n```\nR1# show crypto ikev2 sa detailed\nTunnel-id Local                 Remote                fvrf/ivrf            Status\n1         10.0.12.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: PSK, Auth verify: PSK\n      PQC Key Exchange: ML-KEM-768\n      Life/Active Time: 86400/9 sec\n      ...\n      IETF Std Fragmentation  enabled.\n      Quantum-safe Encryption using PQC: ML-KEM-768\n      IETF Std Fragmentation MTU in use: 1372 bytes.\n```\n\nThere it is: ** PQC Key Exchange: ML-KEM-768** right there in the\n\n`show`\n\noutput. The key exchange is quantum-safe, and the tunnel negotiated it without any pre-shared secrets or out-of-band key distribution.## Phased migration\n\nThis is the real-world scenario. You have a Cisco network with multiple sites. You can’t upgrade everything at once. So you start with the hub, then upgrade spokes one by one.\n\nThe topology changes here. In the exercises above, the tunnel ran R1-to-R3 directly (R2 just forwarded). Now R2 becomes a VPN hub: it terminates two separate tunnels, one to each spoke. New keyrings, new profiles on all three routers.\n\nThe key difference is in the **proposals**. The hub (R2) and the already-upgraded spoke (R1) include `pqc mlkem768 optional`\n\n. The legacy spoke (R3) does not.\n\n**R2 (hub) proposal:**\n\n```\ncrypto ikev2 proposal HUB-PROPOSAL\n pqc mlkem768 optional\n encryption aes-cbc-256\n integrity sha512\n group 20\n```\n\n**R1 (upgraded spoke):**\n\n```\ncrypto ikev2 proposal PQC-PROPOSAL\n pqc mlkem768 optional\n encryption aes-cbc-256\n integrity sha512\n group 20\n```\n\n**R3 (legacy spoke), no PQC yet:**\n\n```\ncrypto ikev2 proposal SPOKE-PROPOSAL\n encryption aes-cbc-256\n integrity sha512\n group 20\n```\n\nNow check the hub’s two tunnels:\n\n```\nR2# show crypto ikev2 sa\nTunnel-id Local                 Remote                fvrf/ivrf            Status\n1         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: PSK, Auth verify: PSK\n      PQC Key Exchange: ML-KEM-768\n      Life/Active Time: 86400/19 sec\n\nTunnel-id Local                 Remote                fvrf/ivrf            Status\n2         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: PSK, Auth verify: PSK\n      Life/Active Time: 86400/18 sec\n```\n\nOne hub, two tunnels. The R2-R1 tunnel shows **ML-KEM-768** (both support it). The R2-R3 tunnel stays classical (R3 doesn’t have `pqc`\n\nin its proposal, so it falls back to plain DH group 20). That’s `optional`\n\ndoing its job: no breakage, graceful fallback.\n\nNow upgrade R3:\n\n```\nR3(config)# crypto ikev2 proposal SPOKE-PROPOSAL\nR3(config-ikev2-proposal)# pqc mlkem768 optional\n\nR2# clear crypto ikev2 sa\n```\n\nAfter renegotiation:\n\n```\nR2# show crypto ikev2 sa\nTunnel-id Local                 Remote                fvrf/ivrf            Status\n1         10.0.12.2/500         10.0.12.1/500         none/none            READY\n      ...\n      PQC Key Exchange: ML-KEM-768\n\nTunnel-id Local                 Remote                fvrf/ivrf            Status\n2         10.0.23.1/500         10.0.23.2/500         none/none            READY\n      ...\n      PQC Key Exchange: ML-KEM-768\n```\n\nBoth tunnels quantum-safe. Cool!\n\nThat’s the migration strategy: upgrade the hub first with `optional`\n\n, then roll out to spokes at your own pace. Once everything is upgraded, change `optional`\n\nto `required`\n\nto enforce PQC everywhere and reject classical-only peers.\n\n## Where we stand\n\nKey exchange is done. The two approaches we covered (PPK and ML-KEM) are alternatives, not layers you stack. PPK is an option when the platform doesn’t support ML-KEM yet; once it does, ML-KEM is the cleaner path because it doesn’t require distributing secrets out of band.\n\nBut authentication is still a pre-shared key. At scale, managing per-tunnel PSKs doesn’t work, and an RSA or ECDSA certificate is forgeable by a future quantum computer. The missing half of the picture is ML-DSA certificates, and that’s where IOS XE gets really interesting. Part 10 walks through the PKI story: how we build the CA externally, import the certificates, and what ML-DSA costs on the wire.\n\nSee you there!\n\n### Leave a Comment [Cancel reply](/developer/post-quantum-key-exchange-on-cisco-routers-ipsec-series-part-9#respond)\n\nYou must be [logged in](https://blogs.cisco.com/wp-author/?redirect_to=https%3A%2F%2Fblogs.cisco.com%2Fdeveloper%2Fpost-quantum-key-exchange-on-cisco-routers-ipsec-series-part-9) to post a comment.", "url": "https://wpnews.pro/news/post-quantum-key-exchange-on-cisco-routers-ipsec-series-part-9", "canonical_source": "https://blogs.cisco.com/developer/post-quantum-key-exchange-on-cisco-routers-ipsec-series-part-9", "published_at": "2026-09-01 20:49:30+00:00", "updated_at": "2026-09-01 20:55:18.697938+00:00", "lang": "en", "topics": ["ai-safety"], "entities": ["Cisco Systems Inc.", "Cisco 8000 Series Secure Router", "C8235-G2", "IOS XE 26.2", "ML-KEM-768", "ML-DSA", "RFC 8784"], "alternates": {"html": "https://wpnews.pro/news/post-quantum-key-exchange-on-cisco-routers-ipsec-series-part-9", "markdown": "https://wpnews.pro/news/post-quantum-key-exchange-on-cisco-routers-ipsec-series-part-9.md", "text": "https://wpnews.pro/news/post-quantum-key-exchange-on-cisco-routers-ipsec-series-part-9.txt", "jsonld": "https://wpnews.pro/news/post-quantum-key-exchange-on-cisco-routers-ipsec-series-part-9.jsonld"}}