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]
