[Swan-dev] delay when initiator gets their IKE AUTH request rejected

Andrew Cagney andrew.cagney at gmail.com
Mon May 24 23:26:58 UTC 2021


On Mon, 24 May 2021 at 18:47, Paul Wouters <paul at nohats.ca> wrote:

> On May 24, 2021, at 14:20, Andrew Cagney <andrew.cagney at gmail.com> wrote:
> >
> > 
> > - responder sends back an AUTH rejection (doesn't really matter what,
> just not a child rejection)
> > - rejection is passed to CHILD SA (see switch above)
> > - child SA returns FAIL and is deleted
> >  time passes
> > - ike IKE SA gets a timer event and that triggers a retry
>
> 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.
>

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).

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.

Hence my working assumption.


> > 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.
>
> That seems correct.
>



>
> > 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?
>
> 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.


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.




>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.libreswan.org/pipermail/swan-dev/attachments/20210524/4ce2c354/attachment.html>


More information about the Swan-dev mailing list