[Pqc] Re: [IPsec] Re: [EXTERNAL] PQC integration i n IPsec/IKEv2 - implementation experience and interop

--===============0432569114661338927==
Content-Type: multipart/alternative; boundary="000000000000540d5e0654e19882"

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

Hi Nick, Paul, all,

This thread is useful.

I agree with Paul that IPsec/IKEv2 interop probably does not need a
QUIC-style continuous public test harness to be useful.

A lower-friction artifact may be enough for the first pass: a public
interop checklist and results matrix that records exactly what was tested,
against which peer, and what evidence was observed.

For PQC-in-IKEv2 I would split the first matrix along a few axes:

   - implementation and version;
   - peer implementation and version;
   - deployment shape: site-to-site, remote access, or point-to-point;
   - mechanism: RFC 8784 PPK, RFC 9867 PPK with IKE_INTERMEDIATE, RFC 9370
   multiple key exchange, PQC authentication, reliable IKEv2 transport,
   downgrade prevention;
   - algorithm set: ML-KEM and ML-DSA parameter sets actually exercised;
   - path conditions: fragmentation, retransmission, NAT traversal,
   rekey/CREATE_CHILD_SA, and failure diagnostics;
   - result evidence: packet trace summary, logs, negotiated transforms,
   and failure reason where applicable.

That would let vendors and open-source implementations participate at
different disclosure levels while still producing useful compatibility data=
.

If there is interest, I can help turn this into a starter checklist or
markdown matrix for the IETF 126 hackathon discussion.

Best,
Songbo

On Mon, 22 Jun 2026 19:26:21 -0400 (EDT), Paul Wouters [email protected] wrote=
:

On Mon, 22 Jun 2026, Nick Grifka wrote:

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.

Traditionally these were held in the past (called =E2=80=9Cbake offs=E2=80=
=9D but then
IPR got into the way of that name). But since IKEv2/IPsec has strong
opensource releases (libreswan and strongswan), interop testing usually
happens against those implementations (and recently elvis-plus) and doesn=
=E2=80=99t
require much gathering. Although if you will be at IETF-126, there will
be *swan people and elvis-plus people who will gladly do some interop
testing with you - especially during the hackathon days (Sat+Sun)

Paul

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

<div dir=3D"ltr"><p>Hi Nick, Paul, all,</p>
<p>This thread is useful.</p>
<p>I agree with Paul that IPsec/IKEv2 interop probably does not need a QUIC=
-style continuous public test harness to be useful.</p>
<p>A lower-friction artifact may be enough for the first pass: a public int=
erop checklist and results matrix that records exactly what was tested, aga=
inst which peer, and what evidence was observed.</p>
<p>For PQC-in-IKEv2 I would split the first matrix along a few axes:</p>
<ul>
<li>implementation and version;</li>
<li>peer implementation and version;</li>
<li>deployment shape: site-to-site, remote access, or point-to-point;</li>
<li>mechanism: RFC 8784 PPK, RFC 9867 PPK with IKE_INTERMEDIATE, RFC 9370 m=
ultiple key exchange, PQC authentication, reliable IKEv2 transport, downgra=
de prevention;</li>
<li>algorithm set: ML-KEM and ML-DSA parameter sets actually exercised;</li=
>
<li>path conditions: fragmentation, retransmission, NAT traversal, rekey/CR=
EATE_CHILD_SA, and failure diagnostics;</li>
<li>result evidence: packet trace summary, logs, negotiated transforms, and=
 failure reason where applicable.</li>
</ul>
<p>That would let vendors and open-source implementations participate at di=
fferent disclosure levels while still producing useful compatibility data.<=
/p>
<p>If there is interest, I can help turn this into a starter checklist or m=
arkdown matrix for the IETF 126 hackathon discussion.</p>
<p>Best,<br>
Songbo</p></div>
<p>On Mon, 22 Jun 2026 19:26:21 -0400 (EDT), Paul Wouters <a href=3D"mailto=
:[email protected]" target=3D"_blank">[email protected]</a> wrote:</p>
<blockquote>
<p>On Mon, 22 Jun 2026, Nick Grifka wrote:</p>
<blockquote>
<p>Also, I see in the past there have been PQC-related interop events (ex: =
<a href=3D"https://github.com/IETF-Hackathon/pqc-certificates" target=3D"_b=
lank">https://github.com/IETF-Hackathon/pqc-certificates</a>). Is there any=
 appetite for an interop<br>
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<br>
framework (ex: <a href=3D"https://github.com/quic-interop" target=3D"_blank=
">https://github.com/quic-interop</a>), so maybe that makes such an event l=
ess practical.</p>
</blockquote>
<p>Traditionally these were held in the past (called =E2=80=9Cbake offs=E2=
=80=9D but then<br>
IPR got into the way of that name). But since IKEv2/IPsec has strong<br>
opensource releases (libreswan and strongswan), interop testing usually<br>
happens against those implementations (and recently elvis-plus) and doesn=
=E2=80=99t<br>
require much gathering. Although if you will be at IETF-126, there will<br>
be *swan people and elvis-plus people who will gladly do some interop<br>
testing with you - especially during the hackathon days (Sat+Sun)</p>
<p>Paul</p>
</blockquote>

--000000000000540d5e0654e19882--


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

LS0gClBxYyBtYWlsaW5nIGxpc3QgLS0gcHFjQGlldGYub3JnClRvIHVuc3Vic2NyaWJlIHNlbmQg
YW4gZW1haWwgdG8gcHFjLWxlYXZlQGlldGYub3JnCg==

--===============0432569114661338927==--