Hi Lun, Thanks for posting this. I think the draft is useful because it turns a real configuration/interoperability failure into something the WG can reason about.
One point that might make the mechanism easier to review: I would separate the "find a valid RFC 9370 outcome" case from the "compatibility fallback" case. My read is: - First, the responder should try a holistic selection over the ADDKE transform types and prefer a valid, non-duplicated set when one exists. - Only if no such set exists, local compatibility policy could decide whether to accept a weaker outcome, such as duplicate use of the same KEM or an implicit NONE. - That fallback should be gated by an explicit local minimum-security policy, so the responder never silently turns a multi-KEM intent into something below its configured floor. This framing may also make Section 6 easier to turn into an interop matrix: initiator proposal, responder capability, strict RFC 9370 outcome, extended-policy outcome, and the security threshold that allowed or rejected it. If useful, I can help sketch that matrix or a short responder-processing checklist for the Vienna discussion. Best, Songbo Bu On Tue, 9 Jun 2026 07:04:15 +0000, "lilun (F)" <[email protected]> wrote: > Dear all, > > I've posted a new individual draft to address some robust negotiation issues > found during multi-KEM migration in IKEv2. > > Title: Consideration of Robust Multi-KEM Negotiation within IKEv2 > URL: > https://datatracker.ietf.org/doc/draft-li-ipsecme-extensions-for-robust-negotiation/ > > The draft discusses scenarios where initiators send redundant or overlapping > KEM algorithm lists across different ADDKE transform types (RFC 9370) based > on our PoC best practice. To prevent interoperability fragmentation and > unexpected negotiation failures on the wire, this document introduces > deterministic extended selection logic for responders (such as duplicate > selection). > > Please review the document and feel free to share your thoughts on the > mailing list. > > I would also like to be considered having chance to request a presentation > slot at the upcoming Vienna meeting to introduce this I-D to the group. > > Regards, > > Lun Li > > > -----Original message----- > > From: [email protected] <[email protected]> > > Sent: June 5, 2026, 16:30 > > To: lilun (F) <[email protected]> > > Subject: New Version Notification for> > > draft-li-ipsecme-extensions-for-robust-negotiation-00.txt > > > > A new version of Internet-Draft > > draft-li-ipsecme-extensions-for-robust-negotiation-00.txt has been > > successfully submitted by Lun Li and posted to the > > IETF repository. > > > > Name: draft-li-ipsecme-extensions-for-robust-negotiation > > Revision: 00 > > Title: Consideration of Robust Multi-KEM Negotiation within IKEv2 > > Date: 2026-06-03 > > Group: Individual Submission > > Pages: 11 > > URL: > > https://www.ietf.org/archive/id/draft-li-ipsecme-extensions-for-robust-negot > > iation-00.txt > > Status: > > https://datatracker.ietf.org/doc/draft-li-ipsecme-extensions-for-robust-negoti > > ation/ > > HTMLized: > > https://datatracker.ietf.org/doc/html/draft-li-ipsecme-extensions-for-robust- > > negotiation > > > > > > Abstract: > > > > RFC 9370 specifies a framework for multiple additional key exchanges > > (ADDKE) in the Internet Key Exchange Protocol Version 2 (IKEv2) to > > support post-quantum cryptography migration. Under this framework, > > an initiator can propose multiple ADDKE transform types. In > > deployment scenarios, initiators may send proposals that contain > > redundant or overlapping lists of Key Encapsulation Mechanism (KEM) > > algorithms across different ADDKE transform types. This contribution > > discusses the implications of these proposals and specifies extended > > procedures for handling proposed transforms, which may improve > > negotiation robustness and interoperability by allowing the responder > > to select a valid set of algorithms without altering the security > > properties defined in RFC 9370. > > > > > > > > The IETF Secretariat > > > > > -----Original message----- > > From: Lilun (F) <[email protected]> > > Sent: April 30, 2026 15:25 > > To: Valery Smyslov <[email protected]>; [email protected] > > Subject: [IPsec] Re: Triggering discussion on RFC 9370 ADDKE algorithm > > selection and potential issues.> > > Hi Valery, > > > > Thanks for the explain. I think generally the ADDKE algorithm selection is > > an > > interesting topic and worth to re-visit. > > I am about to prepare an individual draft to further illustrate this topic > > for > > the reference. > > > > Regards, > > Lun > > > > > -----Original message----- > > > From: Valery Smyslov <[email protected]> > > > Sent: April 29, 2026 20:52 > > > To: lilun (F) <[email protected]>; Wang Guilin > > > <[email protected]>; [email protected] > > > Subject: RE: [IPsec] Re: Triggering discussion on RFC 9370 ADDKE > > algorithm > > > selection and potential issues> > > > Hi Lun, > > > > > > The intended use of multiple ADDKE transforms was that each of these > > > transforms would contain > > > KE methods based on different mathematical properties. For example, the > > > initiator can put all lattice-based KEMs > > > to ADDKE1, all code-based KEMs to ADDKE2 etc. (we have plenty of spare > > > transforms for the future). > > > > > > It is a little point for the initiator to populate all ADDKE transforms > > > with the > > same > > > set of algorithms - just a waste of message space > > > in IKE_SA_INIT, where it is often limited. It is the responder who can > > > have a > > > policy allowing *any* supported > > > KEM in *any* ADDKE, since this policy is not transferred on the wire and > > does not > > > eat space. > > > In this case, the responder does not care the order of KEMs, but should > > make > > > sure that > > > a needed set of KEMs is proposed. > > > > > > But this is just a good way of using RFC 9370, the specification does not > > prohibit > > > other scenarios. > > > The only restriction is a prohibition of multiple use of the same KE > > > method, > > since > > > it makes no sense > > > from security PoV and is a waste of resources. > > > > > > Regards, > > > Valery. > > > > > > > > > > Hi Guilin, > > > > > > > > I agree with your assessment of the current RFC 9370 text. redundant > > > proposals don't provide additional security. > > > > > > > > I think the motivation for bringing this to the WG is the gap between > > > > the > > > specification and best practice reflecting, > > > > particularly in large-scale deployments. > > > > > > > > In practice, IKEv2 configurations are often managed by developers who > > might > > > perhaps populate ADDKE slots with > > > > the same algorithm list. Currently, this redundancy causes a hard > > negotiation > > > failure. I hope to raise is whether we > > > > should allow the responder to be more resilient. If a secure connection > > can still > > > be established. > > > > > > > > Furthermore, different implementations may have handled these edge > > cases in > > > different ways to consider > > > > robustness. However, this could potentially lead to interoperability > > > > issues. > > it is > > > not to encourage redundant configs > > > > in specification level, but to explore if the protocol can be more > > > > resilient > > during > > > PQC migration. > > > > > > > > Regards, > > > > > > > > Lun > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: Wang Guilin <[email protected]> > > > > Sent: 24 Apr 2026 17:56 > > > > To: lilun (F) <[email protected]>; [email protected]; Tobias Brunner > > > <[email protected]> > > > > Cc: [email protected]; Wang Guilin <[email protected]> > > > > Subject: RE: [IPsec] Re: Triggering discussion on RFC 9370 ADDKE > > algorithm > > > selection and potential issues > > > > As I understand, your case "ADDKE1 [A, B], ADDKE2 [A, B], ADDKE3 [A, > > B]" is > > > not allowed mainly because, from > > > > the security view point, such proposal does not enhance security while > > > increases the complexity for both side (to > > > > run the same algorithm twice or more). > > > > > > > > For such a proposal, as requiring to select select one algorithm in each > > ADDKE, > > > the responder has to select > > > > something like "ADDKE1 [A], ADDKE2 [B], ADDKE3 [A]". However, such > > an > > > answer is not allowed according to > > > > 2.2.1 in RFC 9370. So, a failure will happen. > > > > > > > > 2.2.1 > > > > "The responder performs the negotiation using the standard IKEv2 > > procedure > > > described in Section 3.3 of > > > > [RFC7296]. However, for the ADDKE Transform Types, the > > responder's > > > choice MUST NOT contain duplicated > > > > algorithms (those with an identical Transform ID and attributes), except > > for the > > > Transform ID of NONE." > > > > > > > > So, to prepare aproposal, the initiator may need to do as follows: > > > > > > > > - If the initiator wants the responder to select either A or B, the > > > > proposal > > should > > > be: "ADDKE1 [A, B]". > > > > - If the initiator wants the responder to select A and B, the proposal > > should be: > > > "ADDKE1 [A], ADDKE2 [B] ". > > > > - If the initiator wants the responder to select A OR (A and B), the > > proposal > > > should be: "ADDKE1 [A], ADDKE2 [B, > > > > None]". > > > > - If the initiator wants the responder to select None OR A OR B OR (A > > > > and > > B), > > > the proposal should be: "ADDKE1 > > > > [A, None], ADDKE2 [B, None]". > > > > - ... > > > > > > > > Guilin > > > > > > > > -----Original Message----- > > > > From: lilun (F) <[email protected]> > > > > Sent: Friday, 24 April 2026 4:12 pm > > > > To: [email protected]; Tobias Brunner <[email protected]> > > > > Cc: [email protected] > > > > Subject: [IPsec] Re: Triggering discussion on RFC 9370 ADDKE algorithm > > > selection and potential issues > > > > > > > > Hi Thanks Tobias, and all work group, > > > > > > > > Thank you for the reply. I think strongSwan already does an excellent > > > > job > > > implementing RFC 9370, and your > > > > example illustrates the cases we are encountering. > > > > > > > > Actually but, my main point is whether we could explore a potential > > > specification draft/update/extension to handle > > > > these redundant scenarios more gracefully. Reviewing some of our failed > > test > > > cases, I am wondering if we could > > > > relax or clarify the restrictions. > > > > > > > > In practice, many developers might configure ADDKEs by simply filling > > them > > > with the exact same list of supported > > > > algorithms. For example, an initiator might send: > > > > ADDKE1 [A, B], ADDKE2 [A, B], ADDKE3 [A, B] Currently, this redundant > > > configuration leads to negotiation failure. > > > > It would be much more robust if the responder could tolerate the > > redundancy > > > and intelligently select algorithms— > > > > for example, selecting A for ADDKE1, B for ADDKE2, and another A for > > > ADDKE3—thus still resulting in a > > > > successful hybrid exchange. > > > > > > > > If there is interest in exploring this in the Work Group for algorithm > > selection > > > issues and more, I would be very > > > > happy to request a presentation slot at IETF 126 to elaborate above > > content > > > and some deep thinking. > > > > > > > > Best regards, > > > > > > > > Lun Li > > > > > > > > -----Original Message----- > > > > From: Tobias Brunner <[email protected]> > > > > Sent: April 16, 2026 18:54 > > > > To: lilun (F) <[email protected]>; [email protected] > > > > Cc: [email protected]; [email protected] > > > > Subject: Re: [IPsec] Triggering discussion on RFC 9370 ADDKE algorithm > > > selection and potential issues On > > > > 16.04.26 12:18, lilun (F) wrote: > > > > > Hi Everyone, > > > > > > > > > > Following our earlier research in the PQUIP WG regarding PQC > > migration > > > > > in telecom systems, our team have recently been implementing IKEv2 > > > > > migration based on RFC 9370. During this process, we encountered > > some > > > > > negotiation failures related to ADDKEs that I would like to bring to > > > > > the WG's attention for discussion. > > > > > > > > > > During our PoC testing, we observed that IKE configuration errors— > > > > > specifically, configuring the same algorithm redundantly in ADDKE > > > > > payloads during IKE negotiation—frequently lead to negotiation > > > > > failures. > > > > > > > > > > According to RFC 9370, Section 2.2.1 (which also references RFC 7296, > > > > > Section 2.7), the implementation shall be strictly limited: > > > > > > > > > > /"the responder MUST select one of the algorithms proposed using this > > > > > type... the responder's choice MUST NOT contain duplicated algorithms > > > > > (those with an identical Transform ID and attributes), except for the > > > > > Transform ID of NONE."/ > > > > > > > > The important part there is "responder's choice". It's perfectly fine to > > > configure as well as send the same > > > > algorithms in ADDKEs as initiator. > > > > The responder just has to make sure its proposal selection process does > > > result in a unique algorithm for each > > > > ADDKE (except for NONE). > > > > > > > > > Based on feedback from our testing, some errors may be occurred > > > > > frequently in the configuration, and they were negotiation failed. > > > > > After troubleshooting, We found that the error was due to the same > > > > > algorithm being configured in ADDKEs during IKE in a redundance. For > > > > > example, placing ML-KEM-768 in multiple ADDKEs > > > > > > > > > > I would like to start a discussion on whether these strict in 2.2.1 > > > > > limitations for ADDKEs could have consideration for future releases > > > > > (for instance, in PQC-specific profiles like ML-KEM). Considering the > > > > > real- world possibility of configuration redundancies. > > > > > > > > > > Interestingly, also as part of our research verification, we found > > > > > that some open-source implementations (e.g., strongSwan) handle > > ADDKE > > > > > differently. Instead of strict responder selection, the algorithm > > > > > negotiation is often simplified to finding the intersection of > > > > > multiple ADDKEs between peers. > > > > > > > > Yes, we have simplified the process a bit in so far that we only check > > individual > > > ADDKEs (sequentially) and avoid > > > > duplicates overall. So we currently can't handle situations like > > ADDKE1[A, B], > > > ADDKE2[B, C] with a local config of > > > > ADDKE1[B, A], ADDKE2[B, A]. We'd select ADDKE1[B] (preferring the > > local > > > config and order by default) but that > > > > prevents selecting it for ADDKE2, so no valid proposal results. However, > > > ADDKE1[A], ADDKE2[B] would > > > > technically be acceptable by both peers (in this particular example > > disabling > > > prefer_configured_proposals would > > > > make it work). > > > > > > > > Regards, > > > > Tobias > > > > _______________________________________________ > > > > IPsec mailing list -- [email protected] > > > > To unsubscribe send an email to [email protected] > > > > _______________________________________________ > > > > IPsec mailing list -- [email protected] > > > > To unsubscribe send an email to [email protected] > > > > _______________________________________________ > > IPsec mailing list -- [email protected] > > To unsubscribe send an email to [email protected] > _______________________________________________ > IPsec mailing list -- [email protected] > To unsubscribe send an email to [email protected] _______________________________________________ IPsec mailing list -- [email protected] To unsubscribe send an email to [email protected]
