On Mon, 24 Aug 2026 at 10:48, Michael Richardson <[email protected]> wrote: > > > > I'd like to pick up on this thread > > > https://mailarchive.ietf.org/arch/browse/ipsec/?gbt=1&index=_a7dgrxWgS_hqhUQaHBNlIoJbbA > > This link just gets me the august 2026 date index view... > So I don't have the entire context... guessing.
Weird. The post was: [IPsec] collison during initial exchange - RFC 5996 "Prashant Batra (prbatra)" <[email protected]> Fri, 16 December 2011 12:06 UTCShow heade https://mailarchive.ietf.org/arch/msg/ipsec/8caMSeq9hswgDMk3Wz0hGbGXu_Y/ maybe that works. > Andrew Cagney <[email protected]> wrote: > > - while statistically rare, it is not random; rather it is highly > > predictable - after any power fail or phy restore, when things are > > expected to come up ASAP > > My work on RFC8994 caused me to debug such situations in very much > *deterministic ways*... yes... not at all random. And "wire" ("WAN") latency > was > very low since it was v6-LL / v6-LL communcation. > > I wound up putting a sleep in *before* asking my IKE to initiate, > based upon the low bits of the IPv6-LL. This meant that one side would > always initiate first, so one wasn't wasting time doing two IKE Parent SAs. > (Yes, I did find bugs in the pick-IKEv2-to-kill too) Anything to break the symmetry. > > - in a world where 3 or more exchanges are required to authenticate > > the IKE SA; I think there's value in not throwing that effort away > > > My suggestion is for the responder, during IKE_AUTH, to complete > > authentication of the IKE SA but then reject the Child SA with > > TEMPORARY_FAILURE - i.e., back off for a moment. > > The initiator can then, after some jitter, and assuming the Child SA > > hasn't established, initiate a CREATE_CHILD_SA for the failed Child SA > > using the still established IKE SA. > > I guess that one end does not yet have the right policy loaded yet, so it > would otherwise refuse? I didn't have this problem, but I don't see why I > couldn't run into it as well. 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 At this point A has an IKE SA it trusts (initiated by the peer). Does it go with that or hold its breath and hope its own request comes back. Symmetry means the peer is going to do the same thing, hence a cross. One of the original recommendations for handling this was to just leave the two SAs. Not sure that's the best when they're fighting over dedicated h/w. > -- > Michael Richardson <[email protected]> . o O ( IPv6 IøT consulting ) > Sandelman Software Works Inc, Ottawa and Worldwide > > ** My working hours and your working hours may be different. ** > ** Please do not feel obligated to reply outside your normal working hours ** > > > > _______________________________________________ IPsec mailing list -- [email protected] To unsubscribe send an email to [email protected]
