[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