Hi Songbo,
I agree, there are many aspects to this. I see a few categories here, all of
which would be relevant to interop discussions:
1.
Test deployments (ex: site-to-site VPN)
2.
PQC-related mechanisms (ex: multiple key exchange via RFC 9370)
3.
PQC-related mechanism details (ex: within RFC 9370, multiple key exchange for
IKE SA rekey)
4.
PQC algorithm sets (ex: ML-KEM-1024 key exchange method)
5.
Network topologies (ex: initiator behind a NAT)
A single matrix capturing all combinations of these aspects might be hard to
represent. To simplify, I've listified the categories I think are most relevant
for initial discussions and left out the rest on purpose to start. I'm certain
it is incomplete, but it can easily be edited and expanded. CNSA 2.0 profile
applicability can also be layered on top.
1. Test Deployment
* Site-to-site VPN
* Point-to-site VPN
* Point-to-point IPsec
2. Ipsec mode
* Tunnel mode
* Transport mode
3. PQC-related mechanism
* Mixing Preshared Keys (RFC 8784)
* Mixing Preshared Keys using Intermediate (RFC 9867)
* Multiple Key Exchange (RFC 9370)
*
Signature Authentication using PQC (draft-ietf-ipsecme-ikev2-pqc-auth)
* Reliable IKEv2 Transport (draft-ietf-ipsecme-ikev2-reliable-transport)
* Downgrade Prevention (draft-ietf-ipsecme-ikev2-downgrade-prevention)
4. PQC algorithm set
* ML-KEM-512
* ML-KEM-768
* ML-KEM-1024
* ML-DSA-44
* ML-DSA-65
* ML-DSA-87
Also, I see in the past there have been PQC-related interop events (ex:
https://github.com/IETF-Hackathon/pqc-certificates). Is there any appetite for
an interop event for PQC in IPsec/IKEv2 amongst the community? I realize the
nature of many IPsec/IKEv2 products might not be suitable for a robust and
efficient interop framework (ex: https://github.com/quic-interop), so maybe
that makes such an event less practical.
-Nick
________________________________
From: Blue Dog <[email protected]>
Sent: Saturday, May 23, 2026 9:11 PM
To: [email protected] <[email protected]>; [email protected] <[email protected]>
Subject: [EXTERNAL] [Pqc] [IPsec] PQC integration in IPsec/IKEv2 -
implementation experience and interop
You don't often get email from [email protected]. Learn why this is
important<https://aka.ms/LearnAboutSenderIdentification>
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]<mailto:[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]
