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]
