Please add this draft to the list of mechanisms:
https://datatracker.ietf.org/doc/draft-wang-ipsecme-kem-auth-ikev2/ <9b1a50c6-6006-415a-951a-02e92a37caf9> -- 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] <margin-top: 0px; margin-bottom: 0px;> 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 <margin-top: 0px; margin-bottom: 0px;>). 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 <margin-top: 0px; margin-bottom: 0px;>), 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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ IPsec mailing list -- [email protected] To unsubscribe send an email to [email protected]
