| Main Archive Page > Month Archives > ipsec archives |
Re: [IPsec] [IKEv2] Error in Child SA creation
From: J. Sun <jsun2501_at_nospam>Date: Wed Apr 22 2009 - 20:34:57 GMT
To: Matthew Cini Sarreo <mcins1@gmail.com>
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