<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, 24 May 2021 at 18:47, Paul Wouters <<a href="mailto:paul@nohats.ca">paul@nohats.ca</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On May 24, 2021, at 14:20, Andrew Cagney <<a href="mailto:andrew.cagney@gmail.com" target="_blank">andrew.cagney@gmail.com</a>> wrote:<br>
> <br>
> <br>
> - responder sends back an AUTH rejection (doesn't really matter what, just not a child rejection)<br>
> - rejection is passed to CHILD SA (see switch above)<br>
> - child SA returns FAIL and is deleted<br>
>  time passes<br>
> - ike IKE SA gets a timer event and that triggers a retry<br>
<br>
It didn’t use to do that? An IKE_AUTH failure on the IKE SA unrecoverable. It just result in STF_FATAL and a (delayed) start of the next keyingtry.<br></blockquote><div><br></div><div>I've a test that, immediately after the IKE AUTH is rejected, checks for and expects to see no partial CHILD SAs (confirming that the larval child was deleted).</div><div><br></div><div>If, instead, the IKE family is deleted it immediately re-initiates as REVIVE_CONS kicks in  This leads to a test failure because a larval child sa appears in the look output.</div><div><br></div><div>Hence my working assumption.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> Now, if the code is changed so that the IKE SA initiator is in control, the rejection goes to the IKE SA, and it is the IKE SA that gets deleted.  This triggers an immediate retry.<br>
<br>
That seems correct.<br></blockquote><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> Should it?  I tend to suspect it shouldn't (back off) and the current behaviour was somewhat intentional.  If that's the case then what configuration knob should control it?<br>
<br>
Keyingtries had a back off mechanism that should remain to prevent retry storms on mismatching IKE SA configurations. I don’t think a knob is needed.</blockquote><div><br></div><div>Yea, I'll need to guide the IKE SA in that direction.   For the moment I've a hack that hopefully lets me kick this issue down the road just far enough to get initiator IKE_AUTH as IKE merged.</div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <br></blockquote></div></div>