Hello Matt, I do not have implementation results to report, but from a deployment and interoperability perspective I think it would be useful to separate the discussion into a few test dimensions.
The CNSA 2.0 IPsec profile is a useful reference point, but it is a profile and not a complete interop plan. For implementation alignment, I would suggest tracking at least the following items explicitly: - which transition mechanism is being tested, for example PPK-based deployment, additional key exchange / IKE_INTERMEDIATE behavior, or a profile-specific combination of mechanisms; - whether the test is site-to-site or remote-access VPN, since certificate handling, authentication policy, and path behavior can differ materially; - IKE message size behavior, including fragmentation, retransmission behavior, and whether reliable IKE transport is being considered for larger exchanges; - downgrade and fallback policy when one peer supports only classical algorithms or only part of the PQC profile; - rekey and CREATE_CHILD_SA behavior, not only the initial IKE_SA_INIT and IKE_AUTH path; - logging and diagnostics for negotiation failure, because several failure cases can otherwise look like generic tunnel-establishment problems; - certificate-chain and authentication-payload size, especially if ML-DSA certificates or CNSA-aligned PKI profiles are in scope. For interop, it may help to publish a small matrix that separates required profile conformance from optional transition mechanisms. That would let implementers state, for example, whether they support a specific CNSA profile mode, PPK, additional key exchange, reliable transport, or only a subset of those items. I would be interested in helping review an interoperability checklist or test matrix if one is assembled on-list. That kind of artifact would also make it easier for implementers who are not ready to expose code or product details to contribute useful compatibility information. Best regards, Songbo Bu On Fri, 15 May 2026 19:06:12 +0000, Matt Ige [email protected] wrote: Hi, I’m reaching out to understand how others are approaching the integration of post-quantum cryptography (PQC) into their IPsec/IKEv2 implementations. We are currently looking at the CNSA 2.0 IPsec profile draft as a reference: https://datatracker.ietf.org/doc/draft-guthrie-cnsa2-ipsec-profile I have a couple of specific questions: 1. Beyond what is outlined in this draft, are there additional requirements, design considerations, or extensions that implementations are incorporating in practice? 2. Are there organizations actively implementing PQC for IPsec that would be interested in interoperability testing or collaboration? We are actively working on our implementation and are particularly interested in ensuring alignment with emerging standards and ecosystem compatibility. I appreciate any insights or pointers. Thanks, Matt
_______________________________________________ IPsec mailing list -- [email protected] To unsubscribe send an email to [email protected]
