[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: IKE v2 Requirements and backwards compatability

On Thu, 20 Dec 2001, Shane Amante wrote:

> 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?
> 

Again, this is not something that belongs in a protocol spec. That's
an implementation detail. Good programmers will probably do something
like the above, but let's not clutter a protocol spec with
implementation details (unless they are internal error handling hints,
but please no UI stuff).

jan


> -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/
> > 
> 

 --
Jan Vilhuber                                            vilhuber@cisco.com
Cisco Systems, San Jose                                     (408) 527-0847
References: