[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: IKE v2 Requirements and backwards compatability
Aside from whatever method is ultimately decided upon for automagic
detection of a remote peer's IKE version number, would it be too much
to ask for a knob in IKEv2 implementations that allow operators/users
to manually configure the remote peer as being IKEv1 or IKEv2?
(Presumably, the default would be automagic detection and a user would
manually configure a remote IKE version number if they knew what they
were doing).
Could this be added to the requirements for the next IKE successor?
-shane
On Thu, Dec 20, 2001 at 02:10:05PM +0200, Tero Kivinen wrote:
> pkoning@equallogic.com (Paul Koning) writes:
> > In order to deal with IKEv1 vs. IKEv2 "without undue delay" as I
> > suggested should be the requirement, you need a timely way to
> > recognize a V1-only implementation. If the "invalid version number"
> > message were mandatory, this could be done (modulo the issue of lack
> > of authentication).
>
> In some cases there is no way to know if the other end talks IKE at
> all without timeouts.
>
> > It sounds like we're stuck with timeout as the mechanism for detecting
> > V1-only implementations. Yuck. If that's right, then there is no
> > reason to stick with the old port number.
>
> I don't think we are stuck with timeouts in common case. There are
> implementations out there that WILL send the notification. This means
> that if you start IKEv2 negotiation with them they will send
> notification back and you can immediately fall back to IKEv1. If the
> other end is one of those which does not send the notification then
> you have to wait until the timeout expires, but I think more IKEv1
> implementations will start sending those notifications when IKEv2
> starts get used, even if they do not support any other
> notifications, just to get rid of those timeouts.
>
> I.e if you notice that when I use vendor A products it immediately
> notices IKEv2 is not understood and falls back to IKEv1 without
> timeout, and for vendor B products you have to wait until timeout
> expires I think most of the users will consider the vendor A product
> better, thus vendor B will fix its code to send notifications.
>
> Also current installed base is mostly VPNs and there you can
> preconfigure that the other end only supports IKEv1 to get rid of
> timeout. For oppurtunistic encryption case etc where you don't know
> anything about the other end you might want to put that kind of
> information to the TXT record containing the public key itself...
> --
> kivinen@ssh.fi
> SSH Communications Security http://www.ssh.fi/
> SSH IPSEC Toolkit http://www.ssh.fi/ipsec/
>
Follow-Ups:
References: