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]
