[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: