[Swan-dev] how pluto handling AUTH error notifications
Andrew Cagney
andrew.cagney at gmail.com
Tue Mar 20 14:15:17 UTC 2018
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
More information about the Swan-dev
mailing list