> I'd like to pick up on this thread
>
https://mailarchive.ietf.org/arch/browse/ipsec/?gbt=1&index=_a7dgrxWgS_hqhUQaHBNlIoJbbAThis link just gets me the august 2026 date index view... So I don't have the entire context... guessing. 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) > - 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. -- 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 **
signature.asc
Description: PGP signature
_______________________________________________ IPsec mailing list -- [email protected] To unsubscribe send an email to [email protected]
