[Swan-dev] how pluto handling AUTH error notifications

Paul Wouters paul at nohats.ca
Tue Mar 20 15:48:04 UTC 2018

On Tue, 20 Mar 2018, Andrew Cagney wrote:

> Now, for pluto as the initiator:
> First, when it's behaviour's been changed from sitting there
> re-transmitting the AUTH request (which is doomed), to recognizing the
> fatal error and deleting the IKE SA.   I suspect pluto "needs to treat
> the information with caution" and, instead, after a timeout restart
> the entire connection process?

yes, but the regular process should already work for that, as it is
driven by the state timer event.

> Second, for things like an AUTH NO_PROPOSAL_CHOSEN its, again been
> changed from sitting there re-transmitting the AUTH request, to,
> per-above, just deleting the IKE SA.  This is clearly wrong, I'm
> pretty sure it should, minimally, be sending a delete informational to
> so that the remote's IKE SA isn't left dangling - like for when the
> initiator rejects the responder's auth.

If the AUTH fails on the responder, it should send back an encrypted
AUTHENTICATION_FAILED and delete the half-open IKE SA.

If the AUTH fails on the initiator, since the responder has already
setup an authenticated IKE SA, the initiator must send an INFORMATIONAL
to delete the IKE SA, move into STATE_IKESA_DEL state, wait a short
time to receive the INFORMATIONAL reply (or retransmit the request)
and then self-delete (without sending more notify messages)

I believe we actually immediately delete the IKE SA, so when the reply
comes back we log an INVALID_SPI error.


More information about the Swan-dev mailing list