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]
