Hi Matt, I agree with Jeff. Sending INVALID_SYNTAX notify with no payload and immediately delete IKEv2 SA will be good idea in case of malformed IKE_AUTH request. As SA is still unauthenticated, sending DELETE notify will cause another problems.
Thanks, Raj On Thu, Apr 23, 2009 at 2:04 AM, J. Sun <jsun2...@gmail.com> wrote: > 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 >
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
