[Pqc] [IPsec] PQC integration in IPsec/IKEv2 - implementat ion experience and interop

--===============8380476329810123649==
Content-Type: multipart/alternative; boundary="000000000000b6fdf306528876be"

--000000000000b6fdf306528876be
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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 diffe=
r
   materially;
   - IKE message size behavior, including fragmentation, retransmission
   behavior, and whether reliable IKE transport is being considered for lar=
ger
   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 probl=
ems;
   - 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=C3=A2=E2=82=AC=E2=84=A2m reaching out to understand how others are approa=
ching 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

--000000000000b6fdf306528876be
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><p>Hello Matt,</p>
<p>I do not have implementation results to report, but from a deployment an=
d interoperability perspective I think it would be useful to separate the d=
iscussion into a few test dimensions.</p>
<p>The CNSA 2.0 IPsec profile is a useful reference point, but it is a prof=
ile and not a complete interop plan. For implementation alignment, I would =
suggest tracking at least the following items explicitly:</p>
<ul>
<li>which transition mechanism is being tested, for example PPK-based deplo=
yment, additional key exchange / IKE_INTERMEDIATE behavior, or a profile-sp=
ecific combination of mechanisms;</li>
<li>whether the test is site-to-site or remote-access VPN, since certificat=
e handling, authentication policy, and path behavior can differ materially;=
</li>
<li>IKE message size behavior, including fragmentation, retransmission beha=
vior, and whether reliable IKE transport is being considered for larger exc=
hanges;</li>
<li>downgrade and fallback policy when one peer supports only classical alg=
orithms or only part of the PQC profile;</li>
<li>rekey and CREATE_CHILD_SA behavior, not only the initial IKE_SA_INIT an=
d IKE_AUTH path;</li>
<li>logging and diagnostics for negotiation failure, because several failur=
e cases can otherwise look like generic tunnel-establishment problems;</li>
<li>certificate-chain and authentication-payload size, especially if ML-DSA=
 certificates or CNSA-aligned PKI profiles are in scope.</li>
</ul>
<p>For interop, it may help to publish a small matrix that separates requir=
ed profile conformance from optional transition mechanisms. That would let =
implementers state, for example, whether they support a specific CNSA profi=
le mode, PPK, additional key exchange, reliable transport, or only a subset=
 of those items.</p>
<p>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.</p>
<p>Best regards,</p>
<p>Songbo Bu</p>
<p>On Fri, 15 May 2026 19:06:12 +0000, Matt Ige <a href=3D"mailto:Matthew.I=
[email protected]" target=3D"_blank">Matthew.Ige=3D40micr=
[email protected]</a> wrote:</p>
<blockquote>
<p>Hi,</p>
<p>I=C3=A2=E2=82=AC=E2=84=A2m reaching out to understand how others are app=
roaching the integration of post-quantum cryptography (PQC) into their IPse=
c/IKEv2 implementations.</p>
<p>We are currently looking at the CNSA 2.0 IPsec profile draft as a refere=
nce: <a href=3D"https://datatracker.ietf.org/doc/draft-guthrie-cnsa2-ipsec-=
profile" target=3D"_blank">https://datatracker.ietf.org/doc/draft-guthrie-c=
nsa2-ipsec-profile</a></p>
<p>I have a couple of specific questions:</p>
<ol>
<li>
<p>Beyond what is outlined in this draft, are there additional requirements=
, design considerations, or extensions that implementations are incorporati=
ng in practice?</p>
</li>
<li>
<p>Are there organizations actively implementing PQC for IPsec that would b=
e interested in interoperability testing or collaboration?</p>
</li>
</ol>
<p>We are actively working on our implementation and are particularly inter=
ested in ensuring alignment with emerging standards and ecosystem compatibi=
lity. I appreciate any insights or pointers.</p>
<p>Thanks,</p>
<p>Matt</p>
</blockquote>
</div>

--000000000000b6fdf306528876be--


--===============8380476329810123649==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Disposition: inline

LS0gClBxYyBtYWlsaW5nIGxpc3QgLS0gcHFjQGlldGYub3JnClRvIHVuc3Vic2NyaWJlIHNlbmQg
YW4gZW1haWwgdG8gcHFjLWxlYXZlQGlldGYub3JnCg==

--===============8380476329810123649==--