[Swan-dev] how pluto handling AUTH error notifications
andrew.cagney at gmail.com
Tue Mar 20 16:33:44 UTC 2018
On 20 March 2018 at 11:48, Paul Wouters <paul at nohats.ca> wrote:
> 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.
Ah, I'll try that - I suspect the state needs to hang around until
that event triggers.
The old code:
- kept transmitting AUTH packets (which got ignored)
- timed out, and then had another go
>> 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)
Here, the responder accepted the AUTH request but rejected the
attached CHILD SA request (hopefully it still replied with its own
AUTH credentials, I'm not sure, but if we're deleting the IKE SA it
I'll try tricking it into taking the failed auth path.
> 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