Hi Andrew, Thanks for the insights. Glad to hear we are aligned on keeping this purely within the application layer
If we strictly wait for the response to arrive as per RFC 7296, the responder (the loser) is still forced to execute the heavy PQC signing just to generate that doomed response. This completely defeats the purpose of mitigating PQC overhead. To solve this without breaking the state machine or risking a spoofing DoS, I am NOT suggesting a standard DELETE payload. Instead, once the responder verifies the collision via local identity checks, it should reply with an encrypted, lightweight COLLISION_ABORT Notify Payload using the IKE_SA_INIT keys, and instantly tear down the state. To be precise, this mechanism does not eliminate 100% of the PQC overhead, as the initiator has already computed and sent its initial IKE_AUTH request. However, it completely saves the responder from running the heavy asymmetric PQC signing for the response. Since the reply comes from the responder, it perfectly honors the standard Request-Response flow, while successfully shielding the responder's CPU. Best regards, Wang Xi -----Original Message----- From: Andrew Cagney <[email protected]> Sent: Wednesday, September 2, 2026 12:18 PM To: Wang Xi <[email protected]> Cc: Valery Smyslov <[email protected]>; Wang Xi <[email protected]>; Michael Richardson <[email protected]>; IPsec WG <[email protected]> Subject: Re: [IPsec] Re: fail Child SA with TEMPORARY_FAILURE response during IKE_AUTH ALERT : This message originated outside of the Fortinet network. BE CAUTIOUS before clicking any link or opening an attachment. On Wed, 2 Sept 2026 at 14:04, Wang Xi <[email protected]> wrote: > Regarding Andrew’s suggestion of manipulating the packet flow at the kernel > level: correct me if I am wrong, but isn't this mechanism also strictly > dependent on the explicit generation of the Child SA SPIs? No one has suggested manipulating packets at the kernel level. (MIchael has suggested adding a delay when sending IKE packets as part of the IKE negotiation, and to use nonce to decide a "winner"; but that is very different). > I would suggest an Application-Layer Fast Refusal at that exact junction > instead: Once the IKE_AUTH exchange begins and the responder aligns the > peer’s identity (successfully detecting a genuine collision and generating > the corresponding SPIs), the losing party should immediately reply with a > fast-fail Notify Payload (e.g., COLLISION_ABORT) and tear down its local > half-open state instantly. Where COLLISION_ABORT is a new error notification. So would tear down the IKE SA. Remember, the original initiator, can't "respond", it needs to immediately initiate a new exchange after the IKE_AUTH response arrives. At that point it might as well initiate a delete. *** Please note that this message and any attachments may contain confidential and proprietary material and information and are intended only for the use of the intended recipient(s). If you are not the intended recipient, you are hereby notified that any review, use, disclosure, dissemination, distribution or copying of this message and any attachments is strictly prohibited. If you have received this email in error, please immediately notify the sender and destroy this e-mail and any attachments and all copies, whether electronic or printed. Please also note that any views, opinions, conclusions or commitments expressed in this message are those of the individual sender and do not necessarily reflect the views of Fortinet, Inc., its affiliates, and emails are not binding on Fortinet and only a writing manually signed by Fortinet's General Counsel can be a binding commitment of Fortinet to Fortinet's customers or partners. Thank you. *** _______________________________________________ IPsec mailing list -- [email protected] To unsubscribe send an email to [email protected]
