On 20 March 2018 at 11:48, Paul Wouters <[email protected]> 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) Right. 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 isn't critical). 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. > > Paul _______________________________________________ Swan-dev mailing list [email protected] https://lists.libreswan.org/mailman/listinfo/swan-dev
