Tero Kivinen writes:
> 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.
They will work when an unrecognized notify type is received but they
may not work as well as if they had received a recognized notify
type such as NO_PROPOSAL_CHOSEN.
>
> There is no reason to send old error notifications.
A recognized (old) notify type like NO_PROPOSAL_CHOSEN may be used as a
hint
to do something special like try again later, a notion the RFC 4718
authors
exploited because they didn't have the luxury of introducing new notify
types.
So, sending a new notify type to a peer that does not recognize it could
be viewed as preventing the peer from making the most informed decision.
>
> > 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.
I think there is a point to supporting the old notifies. If you have a
deployed implementation then you have to consider patching it to at least
recognize the new notification types. If you have an undeployed
implementation in development you still might have to interoperate with
unpatched peers. On the other hand, if ikev2bis increments the minor
version number then you may code the ikev2bis implementation to not send
the new notify types to down-level peers rather than patching already
deployed implementations.
I also think that calling the new error notifications "backwards
compatible"
is misleading. If you send a new notification to a peer that does not
recognize it then the behavior may be different, possibly worse, than if
you had sent an old, recognized notification.
> 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.
The quoted RFC 4718 text suggested using a "non-fatal" notify type.
However, a new notify type if it is unrecognized by the peer constitutes
a fatal notify type. The recipient will probably not process
NO_PROPOSAL_CHOSEN and an unrecognized error-type notify the same way.
>
> > 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".
Certainly an RFC 4306 compliant implementation would fail a "request"
entirely if it got an unknown error notification in the response.
However, an RFC 4306 compliant implementation might also retry the request
later with a different message ID after receiving NO_PROPOSAL_CHOSEN
whereas
it almost certainly would not do such a thing after receiving an unknown
error notification.
>
> 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
I think this thread has been heading in the direction that
it is not necessary to increment the minor version based on the
incorrect assertion that old implementations will work just as
well when they receive the new notify types as they did before.
Old implementations will continue to work but they may not work
*as well* when the new notify types are introduced unless the old
implementations are patched. Some old implementations may even
work worse if they receive the new notifications rather than those
originally suggested in RFC 4718 section 5.11.10.
I think there is a tangible benefit to be gained from incrementing
the minor version number. Specifically, to enable an implementation
to avoid sending the new notify types to a peer that won't recognize
them. I understand the potential risk of incrementing the minor version
but I think we ought to weigh that against the potential benefits.
Keith Welter
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
