Matt,
In respect to a Notify ERROR TYPES & the IKE_AUTH response with IDr,
[CERT+] & AUTH payload inclusion, NO_PROPOSAL_CHOSEN,
SINGLE_PAIR_REQUIRED, TS_UNACCEPTABLE and NO_ADDITIONAL_SAS are Notify
ERROR TYPES that would generally still include the IDr, [CERT+] & AUTH
payload in the response.
In respect to the INVALID_SYNTAX & the IKE_AUTH Response, it's really
up to the implementation to decide what to do next in respect to
receiving a malformed IKE_AUTH Request. One option is suggested by Tero
- sending an IKE_AUTH Response with an INVALID_SYNTAX and no other
payloads. Another option is to simply drop the malformed IKE_AUTH
Request and not even send a reply. The point is, there's not much you
can really do when a device sends you a malformed request/response
message - it's not like it's gonna figure out what's wrong and fix it.
Whichever option that you go with, you'll have to eventually locally
delete the unauthenticated IKE_SA - I would not continue operating as if
the IKE_SA is authenticated by initializing a INFORMATIONAL Request with
Delete Payloads. RFC 4306 does not define what to do in such cases, and
essentially leaves it up to implementations to decide on how to handle
it - in other words, there isn't a specified way to handle every oddball
case out there.
- Jeff Sun
Matthew Cini Sarreo wrote:
Hello all,
As IKEv2bis-02 defines in Appendix C, the proper way to notify a
requester that there was an error in creating a Child SA using the
IKE_AUTH exchange is:
error in Child SA <-- IDr, [CERT+],
creation AUTH,
N(error),
[V+]
A point came up about this in a previous thread today (IKE_AUTH
without TSi, TSr), where an initator would send IKE_AUTH without TSi,
TSr. It seemed that a general agreement was to send an INVALID_SYNTAX
message without the IDr and AUTH payloads. As it was put:
>INVALID_SYNTAX is fatal error meaning that other end didn't follow the
>protocol specification, and the IKE SA is going to be removed anyways,
>and there is not really point of putting AUTH payload there (it can be
> there, but there is no need).
> If the other end is not following protocol specification (i.e. is
> non-complient), there is not really point of trying to be nice. This
> is something that cannot be seen by normal customers ever, it should
> only be seen by the implementors when they are testing against broken
> implementations.
>So better just send error message back as it is easiest for your
> implementation (i.e. if it is easy to include AUTH etc to the error
> message, then do so, if not, then leave them out).
The above seems reasonable to me.
What would be the reasoning for adding IDr, [CERT+], AUTH in this
scenario? Would it be possible/acceptable to some better text covering
INVALID_SYNTAX? Maybe it would specify that when INVALID_SYNTAX would
be sent, no other payloads are needed, and what would happen to the
SA. Would the SA be interrupted (removed from memory instantly without
any confirmation by the party sending the notification), an
Informational exchange to delete the SA be initiated or would the
party sending INVALID_SYNTAX allow the other endpoint to take some
action when receiving this error (maybe the initiator would give up
and start an Informational Exchange to delete the SA)?
Regards,
Matt
------------------------------------------------------------------------
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
