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

Reply via email to