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

Paul Wouters paul at nohats.ca
Mon May 24 22:46:57 UTC 2021


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.

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

Paul


More information about the Swan-dev mailing list