First lets quote some random bits of the RFC: https://tools.ietf.org/html/rfc7296#section-3.10 3.10. Notify Payload
Types in the range 0 - 16383 are intended for reporting errors. An implementation receiving a Notify payload with one of these types that it does not recognize in a response MUST assume that the corresponding request has failed entirely. https://tools.ietf.org/html/rfc7296#section-2.21 2.21. Error Handling AUTHENTICATION_FAILED .... Although the IKE_AUTH messages are encrypted and integrity protected, if the peer receiving this notification has not authenticated the other end yet, that peer needs to treat the information with caution. ... If authentication has succeeded in the IKE_AUTH exchange, the IKE SA is established; however, establishing the Child SA or requesting configuration information may still fail. This failure does not automatically cause the IKE SA to be deleted. 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? 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. Andrew _______________________________________________ Swan-dev mailing list [email protected] https://lists.libreswan.org/mailman/listinfo/swan-dev
