ML-DSA Certificates on Cisco IPsec: What Changes in IKEv2?

FirstPassLab — Wed, 09 Sep 2026 00:00:00 -0600

ML-DSA certificates change Cisco IKEv2 by replacing pre-shared-key authentication with post-quantum digital signatures while ML-KEM continues to handle key establishment. The operational tradeoff is size: Cisco’s hardware lab found that certificate-bearing IKE_AUTH exchanges became several times larger than its RSA baseline, making RFC 7383 fragmentation, PKI hygiene, interoperability testing, and reconnect-capacity testing essential. This is a promising lab design, not a reason to assume every peer or platform combination is ready.

Key Takeaway: Treat ML-DSA authentication as a control-plane migration: prove certificate handling and fragmented IKE negotiation under failure and scale before changing production VPN peers.

FirstPassLab is an independent practice and lab provider and is not affiliated with or endorsed by Cisco.

What changes when Cisco IKEv2 uses ML-DSA certificates?

ML-DSA changes peer authentication, not the role of every cryptographic component in the tunnel. According to Cisco Blogs (2026), the tested IOS XE design used mldsa-sig for local and remote authentication, retained ML-KEM-768 for post-quantum key establishment, and retained classical cryptography elsewhere in the negotiated suite. That division matters: ML-KEM protects how the peers establish shared key material, while ML-DSA lets each peer verify the other’s certificate-backed identity. The result is not a single “PQC switch.” It is a composed IKEv2 design with separate algorithms, certificate objects, configuration dependencies, and failure modes. For a practicing engineer, the useful mental model is two adjacent control-plane jobs: establish keys, then authenticate identities. Validate each job independently before judging the complete tunnel.

Cisco’s reported detailed SA output showed Auth sign: MLDSA, Auth verify: MLDSA, and PQC Key Exchange: ML-KEM-768. According to Cisco Blogs (2026), that output came from three Cisco C8235-G2 routers running IOS XE 26.2, with the middle router acting as a transit observation point. It demonstrates the tested implementation; it does not establish support on other releases or interoperability with another vendor.

IKEv2 function	Mechanism in Cisco’s test	What the engineer verifies
Peer authentication	ML-DSA certificate signatures	Trustpoint, certificate chain, EKUs, local and remote authentication
Key establishment	ML-KEM-768 alongside the configured classical exchange	Negotiated SA output and downgrade or fallback behavior
Large-message handling	RFC 7383 IKEv2 fragmentation	Fragment negotiation, path behavior, retransmissions, and logs
Data plane	Existing ESP transform after negotiation	Traffic flow, counters, MTU behavior, and rekey stability

This separation also keeps study work precise. Review crypto agility as an operating practice before treating an algorithm choice as the whole migration. For broader lab context, the CCIE Security track page and Security lab environment show where VPN and PKI exercises fit into a practical study plan.

Why are ML-DSA certificates so large in IKE_AUTH?

ML-DSA makes IKE_AUTH large because the exchange must carry certificate and signature material whose encoded objects are substantially larger than Cisco’s classical comparison. According to Cisco Blogs (2026), its ML-DSA-65 identity used a 1,974-byte public key and a 5,647-byte DER certificate, compared with a 294-byte public key and a 920-byte certificate for RSA-2048. The same source measured a complete ML-DSA-65 handshake at 24,401 bytes, with 20,752 bytes concentrated in IKE_AUTH. Those figures belong to Cisco’s stated topology, certificates, software, and capture method. Use them to understand the direction and likely pressure points, not as a universal bandwidth calculator for every PKI profile or VPN platform.

According to Cisco Blogs (2026), the lab comparison produced the following capture results:

Authentication	`IKE_AUTH` frames	`IKE_AUTH` bytes	Complete handshake
RSA-2048	3	3,462	7,111 bytes
ML-DSA-44	12	15,384	19,033 bytes
ML-DSA-65	16	20,752	24,401 bytes
ML-DSA-87	20	27,848	31,497 bytes

The table points to a specific control-plane cost. According to Cisco Blogs (2026), the variable growth appeared in IKE_AUTH, where the certificate and signature travel, while the post-negotiation ESP data plane did not inherit that per-packet expansion. That distinction should shape testing: normal throughput alone will not expose a negotiation bottleneck.

Why is RFC 7383 fragmentation operationally essential?

RFC 7383 fragmentation is essential because it splits an oversized encrypted IKEv2 message at the IKE layer instead of relying on IP fragmentation across an uncertain path. According to RFC 7383 (2014), large IKE messages commonly arise when certificate chains are exchanged, and IP fragments can be blocked or mishandled by network devices. Cisco’s test makes that standards problem concrete: according to Cisco Blogs (2026), ML-DSA-65 produced 16 IKE_AUTH frames and ML-DSA-87 produced 20. The IOS XE warning explicitly told the operator to enable IKEv2 fragmentation when ML-DSA authentication was configured. The practical requirement is therefore broader than typing a knob: confirm both peers negotiate the capability, capture the exchange, inspect retransmissions, and test the actual underlay path.

A focused verification sequence is:

Confirm the peer software and platform explicitly support the intended ML-DSA and ML-KEM combination.
Import a controlled certificate bundle through the documented PKI workflow and remove the transferred bundle after import.
Inspect the certificate algorithm, subject identity, chain, and extended key usages on the router.
Enable IKEv2 fragmentation on both ends using the vendor-supported configuration for that release.
Capture a clean negotiation at a transit point and distinguish IKE_SA_INIT, IKE_INTERMEDIATE, and IKE_AUTH traffic.
Force rekeys and simultaneous reconnects while watching CPU, queueing, retransmissions, and SA completion.
Record the exact platform, image, certificate profile, parameter set, and path MTU with the results.

Do not copy a sample bundle password or disable revocation checks as a production default. Cisco’s lab disabled CRL checking because its private lab certificates had no CRL distribution point; a production PKI needs a deliberate revocation design. The related FlexVPN versus DMVPN framework guide is useful when deciding where IKEv2 policy and authentication changes sit in a wider VPN architecture.

How should engineers build and import the ML-DSA identity?

Engineers should treat ML-DSA identity creation as a PKI lifecycle, not merely a router command sequence. According to Cisco Blogs (2026), the tested path created the root and router identities on a workstation with OpenSSL 3.5 or later, packaged each private key, certificate, and issuing chain into a password-protected PKCS#12 bundle, imported the bundle into an IOS XE trustpoint, and deleted the transferred file immediately afterward. The lab also required both Server Authentication and Client Authentication extended key usages because an IKEv2 peer can act as initiator or responder. Those implementation details are valuable, but the stronger lesson is operational: define issuance, protected transport, identity matching, renewal, revocation, backup, and destruction before deploying the first identity.

NIST FIPS 204 standardizes ML-DSA itself, while RFC 9881 defines the algorithm identifiers used for ML-DSA public keys and signatures in X.509 certificates. Those standards provide interoperable building blocks; they do not automatically validate your CA profile, IOS XE release, trustpoint behavior, or IKEv2 peer policy.

Before import, inspect the bundle and certificate outside the router. After import, verify the displayed public-key algorithm, signature algorithm, issuer, subject, subject alternative name, validity, chain, and EKUs. Then test initiation in both directions. A one-sided success can conceal an identity-policy or EKU problem. If you need a broader identity-control lab alongside VPN work, the Cisco ISE lab preparation guide offers a separate path for practicing policy and certificate-dependent access controls.

Is ML-DSA over IKEv2 interoperable today?

ML-DSA over IKEv2 should be treated as implementation-specific until the exact peer combination is proven. According to NIST (2024), FIPS 204 standardizes the ML-DSA signature scheme, and according to the RFC Editor (2026), RFC 9881 standardizes ML-DSA identifiers for X.509 certificates. The IKEv2-specific document cited by Cisco has a different status: according to the IETF Datatracker (2026), draft-sfluhrer-ipsecme-ikev2-mldsa is an expired individual Internet-Draft, not an RFC. That mixed maturity means standards support exists at the algorithm and certificate layers while the IKEv2 authentication binding remains less settled. Do not infer cross-vendor compatibility from a same-vendor hardware demonstration.

Build an interoperability matrix with the exact peer platform, software image, ML-DSA parameter set, certificate encoding, identity type, fragmentation support, and failure result. Include asymmetric tests: initiate from each side, renew one certificate, reject an untrusted issuer, present the wrong SAN, and remove ML-DSA support from one peer. The failure behavior matters as much as the successful SA because migration usually creates mixed states.

This is where crypto agility testing becomes concrete. Inventory the dependency chain from CA tooling to router parser to IKEv2 negotiation rather than labeling the tunnel “quantum safe” based on one negotiated field.

What is the industry impact for VPN operations?

The industry impact is a shift from algorithm selection toward control-plane capacity and PKI operations. Cisco’s measurements show why: according to Cisco Blogs (2026), ML-DSA-65 generated a 24,401-byte complete handshake in the stated lab, versus 7,111 bytes for RSA-2048, and the author located the added cost in negotiation rather than every ESP packet. A stable site-to-site tunnel and a concentrator recovering many peers after an outage are therefore different engineering cases. The first emphasizes correctness and rekey reliability; the second adds burst CPU, packet-processing, certificate validation, retransmission, logging, and queue pressure. Capacity planning should reproduce the recovery event instead of extrapolating from steady-state encrypted throughput.

For a lab, test one clean tunnel first, then add concurrency and controlled faults. Measure negotiation completion time, failed SAs, retransmits, CPU, memory, and recovery order with the same certificate chain and fragmentation settings you intend to assess. Avoid turning Cisco’s lab figures into a vendor-neutral sizing ratio. They are evidence of the mechanism and of a possible bottleneck, not a substitute for your own platform measurements.

This topic also belongs in a broader security study sequence. The CCIE Security overview provides the track context, while the zero-trust implementation guide shows how identity, policy, and evidence-based validation connect beyond the VPN edge.

Which ML-DSA parameter set should a Cisco lab test first?

ML-DSA-65 is a reasonable first lab target only because Cisco’s author judged it the practical balance in this specific implementation, not because one parameter set fits every policy. According to Cisco Blogs (2026), moving from ML-DSA-44 to ML-DSA-65 increased IKE_AUTH bytes from 15,384 to 20,752 in the captured lab, while ML-DSA-87 increased them to 27,848. According to NIST FIPS 204 (2024), the parameter sets correspond to different security categories and object sizes. Your selection should begin with an external security requirement, then pass platform-support, interoperability, certificate-profile, fragmentation, and scale tests. If no policy requires a particular set, document why the tested choice is appropriate rather than presenting Cisco’s preference as a universal default.

Keep the evaluation reproducible. Save sanitized configurations, certificate profiles, packet captures, command outputs, and test conditions. Repeat the run after software changes because crypto support and protocol bindings are still evolving. The goal is not to memorize the largest handshake; it is to understand where the extra bytes appear and how the VPN system behaves when many negotiations collide.

Frequently Asked Questions

Does ML-DSA replace ML-KEM in Cisco IKEv2?

No. ML-DSA authenticates the peers with digital signatures, while ML-KEM establishes quantum-resistant key material. Cisco’s tested design uses both for different parts of the IKEv2 exchange.

Why does ML-DSA require IKEv2 fragmentation?

ML-DSA public keys, certificates, and signatures are much larger than the classical alternatives in Cisco’s comparison. RFC 7383 fragmentation lets IKEv2 split the oversized encrypted message before IP fragmentation becomes the fallback.

Is ML-DSA authentication in IKEv2 an interoperable standard?

ML-DSA is standardized by NIST FIPS 204, and RFC 9881 defines its X.509 algorithm identifiers. The cited IKEv2-specific proposal is an expired individual Internet-Draft, so engineers should test each vendor and software combination rather than assume interoperability.

Which ML-DSA parameter set should a Cisco lab test first?

Cisco’s author selected ML-DSA-65 as the practical balance in this specific lab. That is a lab conclusion, not a universal sizing rule; test the parameter set required by your policy against your own tunnel scale and failure scenarios.

To practice the surrounding VPN, PKI, and security workflows, view the CCIE Security · Practice package and its current price.

ML-DSA on FirstPassLab

ML-DSA Certificates on Cisco IPsec: What Changes in IKEv2?

What changes when Cisco IKEv2 uses ML-DSA certificates?

Why are ML-DSA certificates so large in IKE_AUTH?

Why is RFC 7383 fragmentation operationally essential?

How should engineers build and import the ML-DSA identity?

Is ML-DSA over IKEv2 interoperable today?

What is the industry impact for VPN operations?

Which ML-DSA parameter set should a Cisco lab test first?

Frequently Asked Questions

Does ML-DSA replace ML-KEM in Cisco IKEv2?

Why does ML-DSA require IKEv2 fragmentation?

Is ML-DSA authentication in IKEv2 an interoperable standard?

Which ML-DSA parameter set should a Cisco lab test first?