Hi Valery, Andrew , and all, Thanks for the further clarification.
Valery’s point regarding the unreliability of IP addresses in NAT environments during IKE_SA_INIT is absolutely unassailable. We cannot make any justified decision before identities are aligned. 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? If this means even the kernel-level approach must wait until the IKE_AUTH exchange validates the identities and instantiates the routing states, and if my understanding is correct, since both approaches must wait until the identities and SPIs are clarified, why force the OS kernel to intervene at all? 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. Regards, Wang Xi -----Original Message----- From: Valery Smyslov <[email protected]> Sent: Tuesday, September 1, 2026 11:26 PM To: 'Wang Xi' <[email protected]>; 'Andrew Cagney' <[email protected]>; 'Michael Richardson' <[email protected]> Cc: 'IPsec WG' <[email protected]> Subject: [IPsec] Re: fail Child SA with TEMPORARY_FAILURE response during IKE_AUTH Hi, > Hi Andrew, Michael, and all, > > Thanks for the profound insights into the simultaneous initiation > issue, especially regarding the massive overhead of PQC signatures. > > While Andrew's suggestion of manipulating the packet flow via kernel > policy updates works efficiently in Linux/Libreswan ecosystems, I am inclined > to keep the network stack and the IKE daemon cleanly decoupled. > Relying too heavily on OS-specific kernel state machines might reduce > protocol portability. > > Instead of silently delaying/ignoring packets (which, as Andrew > correctly pointed out, triggers exponential retransmissions and > timeouts on the peer) or forcing the kernel to intervene, why don't we > introduce an Explicit Fast Refusal mechanism at the application layer? > > The proposal: > Once the IKE_SA_INIT exchange completes, both ends immediately compute > the Nonce tie-breaker. The party that determines its SA will be the > "loser" doesn't need to silently endure the heavy PQC IKE_AUTH exchange just > to delete it later. > > Instead, upon receiving the next message (whether it's > IKE_INTERMEDIATE or IKE_AUTH) from the "winner", the losing party > immediately replies with a specific Notify Payload—for example, > TEMPORARY_FAILURE or a new status like COLLISION_ABORT, and then safely tears > down its local half-open state. > > This achieves several goals: > No Kernel Messing: It solves the issue purely within the IKE > user-space daemon, leaving the Linux kernel protocol stack clean. > No Deadlocks/Timeouts: The winning peer receives an explicit signal, > so it won't trigger retransmissions or waste hardware resources verifying a > doomed SA. > DoS Mitigation: It acts as a fast-fail path, freeing up cryptographic > accelerator resources immediately. > > Thoughts? Generally, you don't know who is your peer until you receive peers' identity. Thus, you cannot make a justified decision whether these two IKE_SA_INIT relate or not until IKE_AUTH starts. You may sometimes rely on IP addresses, but with NATs this is unreliable. Regards, Valery. > Regards, > Wang Xi > > -----Original Message----- > From: Andrew Cagney <[email protected]> > Sent: Monday, August 31, 2026 10:22 AM > To: Michael Richardson <[email protected]> > Cc: IPsec WG <[email protected]> > Subject: [IPsec] Re: fail Child SA with TEMPORARY_FAILURE response > during IKE_AUTH > > On Wed, 26 Aug 2026 at 12:50, Michael Richardson <[email protected]> > wrote: > > > > > > Andrew Cagney <[email protected]> wrote: > > >> Andrew Cagney <[email protected]> wrote: > > >> > Trust hasn't yet been established; and when it has it's too late. > > For instance: > > >> > > >> > initial initial exchanges happen > > >> > A still has no IKE SA it fully trusts and a Child SA that isn't > > established > > >> > A initiates IKE_AUTH w/ Child SA to B > > >> > A responds to IKE_AUTH w/ seemingly same Child SA from B > > >> > > >> The worst pathology, particularly given big-expensive multi-packet > > >> quantum-safe authentications, is that both ends start IKE_INIT, > > >> and then go into IKE_INTERMEDIATE. > > >> > > >> A is responding to B's init, but hasn't finished (might not even > > know it's > > >> B), and then A sees that it needs to talk to B, and *it* starts. > > >> I think that this is what you are talking about, and I think a lot > > of detail > > >> is buried in the "initial initial exchanges happen" point above. > > > > > I'm trying to keep things focused on an IKE_AUTH exchange, where trust > > > and the Child SA cross. A variant would be childless IKE SAs where > > > both ends immediately initiate a CREATE_CHILD_SA (I've seen this in > > > the field with a second SA). > > > > Yes, but we can do better! > > > > > With an overlap such as: > > > > > A initiates IKE_SA_INIT to B > > > A responds to IKE_SA_INIT from B > > > A responds to IKE_AUTH from B > > > > (1) A->B IKE_SA_INIT > > (1) B->A respond to SA_INIT > > > > (2) B->A IKE_SA_INIT > > (2) A->B respond (**) > > > > [##] > > (1) A->B IKE_INTERMEDIATE > > 2..3..4.. > > > > (2) B->A IKE_INTERMEDIATE > > 2..3.. > > > > (1) A->B IKE_AUTH > > (1) B->A responds > > could be many packets to get quantum-safe signature! > > > > (2) B->A IKE_AUTH > > (2) A->B responds > > could be many packets to get quantum-safe signature! > > [!!] > > > > > > >> That TEMPORARY_FAILURE is called out in 2.8.2, and I suspect that > > there is a > > >> higher probability of this happening when the exchange is longer. > > > > > Yea, that's why I'm putting it out there. > > > > > Unfortunately, it's surrounded by words making it clear it is only for > > > use when a rekey crosses. And the value used to break the tie is > > > comming from a not-yet-trusted IKE_SA_INIT exchange. > > > > Exactly, in order to pick a clear winner, we need to know who we are > > talking to, which means finishing the IKE_AUTH. Then we > > consistently pick the winner, and the initiator of the loser kills it. > > > > So I'm suggesting that at the (**) the nonces from both (1) and (2) > > are visible, and one can know which will be the winner. > > I'm suggesting that *A*, if it sees that it's SA would be the loser, > > would then, rather than immediately doing [##], would instead insert a > > backoff delay of a few seconds. Since A is initiator, it can go as slow as > > it likes, and at [!!], A can see that it has a valid SA (2), and just stop. > > I don't *think* A has to do any cleanup here. > > A, as initiator, can't be too slow - the peer will time it out. > Similarly, A can't tie it being slow to the peer's next request. It > may never happen and DOSing with all 0s or Fs would be fun. > > So I think, while this nudges the exchange in the right direction it > still needs a way to, when processing that first child, to signal a backoff > using NONCEs as the tie-breaker. > > > I can't recall if A would be allowed to send a delete for (1), using SA (2). > > Unfortunately, no. > > > > Hmm, perhaps the way out is to let both ends establish, but then the > > > end with the lowest trusted nonce, initiate a delete. Probably going > > > hand-in-hand with kernel policy updates to move, instead of remove, > > > rules. > > > > That's what RFC7296 already says, it just takes a lot of work to > > establish both IKE SAs, and if the child SA is created, then it > > sucks up hardware (as you point), and can also wind up having two > > unidirectional IPsec SAs, if the delete process is not speedy. (I > > think that might be a hard-to-replicate bug) > > We have the technology (with a mechanism to mess with packet flow it becomes > straight forward). > > _______________________________________________ > IPsec mailing list -- [email protected] > To unsubscribe send an email to [email protected] > > > *** 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] _______________________________________________ IPsec mailing list -- [email protected] To unsubscribe send an email to [email protected] *** 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]
