David Wierbowski writes: > I think it is reasonable to expect that an IKEv2 bis implementation would > use an IF statement to control sending the new Notify types.
No they should just use new notifies, as all old complient implementations will work with those new error messages also. There is no reason to send old error notifications. > If the minor number was changed an implementation could check the > minor version and send the new notify types when the minor version > was 1 and send the notify types recommended in RFC 4718 if the minor > number was 0. There is no point of supporting old RFC4718 error notifications after you implement IKEv2bis as new error notifications are backward compatible with old ones. Also RFC4718 used text like "thus failing the request with something non-fatal such as NO_PROPOSAL_CHOSEN seems like a reasonable approach." which clearly indicates that other error notifications are also possible, thus whether other end sends NO_PROPOSAL_CHOSEN or CHILD_SA_NOT_FOUND error notification, as recipient will process them both in a same way, and expect that exchange failed. > That is what my implementation plans to do if the minor version > number is bumped. I do not think I will ever implement RFC4718 error notifications (we have not implemented it yet, and now when we have IKEv2bis almost ready, I do not think we ever will), thus for me it does not really matter, but I think it would be much easier to just change those error notifications you already have in the code to use CHILD_SA_NOT_FOUND and TEMPORARY_FAILURE instead of NO_ADDITIONAL_SAS and NO_PROPOSAL_CHOSEN without adding any extra logic based on the minor version number. > I'm not sure I agree with Tero that an implementation getting an unknown > TEMPORARY_FAILURE notify would always take the same action that it would if > it received NO_PROPOSAL_CHOSEN as suggested by RFC 4718. Then it is not complient to RFC4306, as RFC4306 clearly says that if you get uknown error notification then you "MUST assume that the corresponding request has failed entirely". RFC4718 does not (and cannot) modify the meaning of NO_PROPOSAL_CHOSEN error notification it just gives you examples what kind error notifications could be used in which case, but I do not think it gives you instructions what to do when you receive such error notifications. This was one of the things needed to be added to the IKEv2bis, and that was the reason we needed to have separate error notifications as we wanted to be sure that it is easy to decide what to do when you get error notification back (i.e. in addition to assuming that exchange failed). -- kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
