Hi Uri, all, Agreed, thanks. I would add `draft-wang-ipsecme-kem-auth-ikev2` as a separate KEM-based authentication bucket in the matrix, distinct from RFC 9370 multiple key exchange and from the signature-authentication path.
My updated mechanism buckets would be: - RFC 8784 PPK; - RFC 9867 PPK with `IKE_INTERMEDIATE`; - RFC 9370 multiple key exchange; - PQC signature authentication; - KEM-based authentication, including `draft-wang-ipsecme-kem-auth-ikev2`; - reliable IKEv2 transport; - downgrade-prevention behavior; - relevant deployment profiles such as CNSA 2.0. For interop evidence, I would keep the first table lightweight: implementation/version, peer/version, deployment shape, mechanism, algorithm set, path conditions, and observed result/logs. That lets people contribute useful rows even if they cannot publish full packet captures or product-specific configuration. Best, Songbo On Tue, 23 Jun 2026 02:27:19 +0000, "Blumenthal, Uri - 0553 - MITLL" <[email protected]> wrote: > Please add this draft to the list of mechanisms: > > https://datatracker.ietf.org/doc/draft-wang-ipsecme-kem-auth-ikev2/ > > -- > > V/R, > > Uri Blumenthal > > There are two ways to design a system. One is to make it so simple there are > obviously no deficiencies. > > The other is to make it so complex there are no obvious deficiencies. > > - C. A. R. Hoare > > I was a shepherd to fools > > Causelessly bold or afraid. > > They would not abide by my rules. > > Yet they escaped. For I stayed. > > R. Kipling “Epitaphs of the War. Convoy Escort” > > From: Songbo Bu <[email protected]> > Date: Monday, June 22, 2026 at 21:23 > To: [email protected] <[email protected]>; [email protected] <[email protected]> > Cc: [email protected] <[email protected]>; [email protected] <[email protected]> > Subject: [EXT] [Pqc] Re: [IPsec] Re: [EXTERNAL] PQC integration in > IPsec/IKEv2 - implementation experience and interop > > This Message Is From an External Sender > > This message came from outside the Laboratory. > > 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 “bake offs” 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’t > 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 _______________________________________________ IPsec mailing list -- [email protected] To unsubscribe send an email to [email protected]
