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? 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]
