Hi Nick, Paul, Uri, all, I took a first pass at the starter matrix I mentioned and attached it as Markdown.
It is deliberately lightweight: not an interop claim, and not a standards-status statement. The goal is just to give implementers a common row format for recording what was actually tested, against which peer, and with what evidence. I also split KEM-based authentication into its own bucket after Uri’s note, rather than folding it into RFC 9370 or PQC signature authentication. The seed rows are only placeholders based on the public discussion so far. They should be replaced or corrected by the actual implementers if the group wants to use this around IETF 126 / hackathon coordination. 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/IKEv2 PQC Interop Starter Matrix Date: 2026-06-23 Context: follow-up to the IPsec/PQC discussion on whether a low-friction interop artifact is useful for IETF 126 hackathon and vendor/open-source testing. Uri Blumenthal asked to add `draft-wang-ipsecme-kem-auth-ikev2` to the mechanism list. ## Mechanism buckets | Bucket | Mechanism/document | Why it belongs in the matrix | First evidence to collect | | --- | --- | --- | --- | | PSK mixing | RFC 8784 PPK | Existing post-quantum preshared-key style mitigation | Negotiated PPK use, failure reason when PPK is required but unavailable | | PSK mixing with intermediate exchange | RFC 9867 PPK with `IKE_INTERMEDIATE` | Relevant to larger PQC payload paths and intermediate exchange behavior | Transcript summary, fragmentation/retransmission behavior, negotiated transforms | | Multiple key exchange | RFC 9370 multiple key exchange | Core hybrid key-establishment path for IKEv2 | ADDKE transform set, selected KEMs, rekey/CREATE_CHILD_SA behavior | | PQC authentication by signatures | `draft-ietf-ipsecme-ikev2-pqc-auth` | PQ signature authentication path distinct from KEM auth | ML-DSA/signature algorithm used, certificate or raw-key path, failure diagnostics | | PQC authentication by KEM | `draft-wang-ipsecme-kem-auth-ikev2` | Uri's requested addition; distinct KEM-based authentication mechanism | KEM-auth exchange path, public-key binding, certificate protection path, downgrade/error behavior | | Multi-authentication | `draft-wang-ipsecme-multi-auth-ikev2-pq` | Related design surface for combining authentication methods | Negotiated auth methods, interaction with RFC 9593 announcements, strict failure behavior | | Transport robustness | reliable IKEv2 transport drafts | Important for large PQC payloads, retransmission, and failure recovery | TCP/UDP behavior, fallback, NAT traversal, logging | | Downgrade prevention | IPsecME downgrade-prevention work | Cross-cutting security property for hybrid/PQC negotiation | Downgrade detection path, authenticated failure, logs and peer diagnostics | | Deployment profile | CNSA 2.0/IPsec profile work | Operational profile target for real deployments | Parameter set, compliance profile, implementation versions | ## Result columns for an interop table Recommended minimal columns: - implementation and version; - peer implementation and version; - deployment shape: site-to-site, remote access, point-to-point, lab-only; - mechanism bucket and exact draft/RFC revision; - algorithm set actually exercised; - path conditions: fragmentation, retransmission, NAT traversal, rekey/CREATE_CHILD_SA; - success/failure result; - evidence type: packet trace summary, negotiated transforms, implementation logs, failure code; - disclosure level: public, redacted vendor-private, or chair-only if needed. ## Starter table This table is intentionally small. It is not a claim of interoperability; it is a place to collect candidate rows and then replace intent with observed evidence. | Status | Implementation / party | Peer | Deployment shape | Mechanism bucket | Algorithm set | Path conditions | Evidence to attach | Disclosure level | | --- | --- | --- | --- | --- | --- | --- | --- | --- | | Candidate | Microsoft implementation | TBD | IPsec / IPsec-based VPN | RFC 9370, PQC auth, reliable transport, downgrade prevention as applicable | TBD | TBD | negotiated transforms, logs, failure diagnostics | TBD | | Candidate | NCP VPN client/server | TBD | Client/server VPN | RFC 9370, RFC 4739, PQ KEM/signature algorithms available through OpenSSL | NIST PQ KEM/signature algorithms, exact sets TBD | Q3 prototype; topology TBD | implementation version, peer version, negotiated transforms | Public summary or redacted | | Candidate | libreswan / strongSwan / elvis-plus community testing | Microsoft/NCP/other vendors | Hackathon or bilateral lab test | Mechanism-specific | TBD | fragmentation, NAT traversal, rekey, failure behavior | transcript summary and implementation logs | Public summary where possible | | Candidate | Post-Quantum client via NIST NCCoE context | Microsoft or other consortium participant | Remote-access VPN | Non-PPK PQC deployment; exact mechanism TBD | TBD | TBD | NCCoE-compatible test notes if available | Consortium/public boundary TBD | ## Row-filling discipline Each row should identify exactly one mechanism bucket or one clearly named profile combination. If a test exercises both key establishment and authentication changes, split it into separate rows unless the point of the test is the interaction between them. Useful evidence is modest but specific: - negotiated IKE transforms and relevant notify payloads; - implementation and peer version; - whether fragmentation, retransmission, NAT traversal, and rekey were exercised; - pass/fail result and the first diagnosable failure reason; - whether packet captures, logs, or only a public summary can be shared. Avoid using the table as a standards-status claim. It should show what was tested, not imply that a mechanism is complete, recommended, or interoperable in general. ## Immediate reply position Reply narrowly: accept Uri's correction, add the KEM-auth draft as a separate authentication bucket, and avoid implying that one interop matrix can validate all mechanisms at once. The useful first deliverable is a starter table that lets implementers add rows without exposing sensitive deployment details.
_______________________________________________ IPsec mailing list -- [email protected] To unsubscribe send an email to [email protected]
