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

RE: Choosing between IKEv2 and JFK




I think it's different problem.  in case of SSL, 3.0 can support all 2.0
features but the users just choose not to upgrade.  However, if IKEv2 cannot
support widely-used features in v1, then users are forced to use IKEv1 (even
IKEv2 has other great features).  They won't be able to upgrade without
changing their current practice, which is the most difficult part for a new
protocol to get acceptance.

Michael Shieh

-----Original Message-----
From: Khaja E. Ahmed
To: Tero Kivinen; Ran Canetti; ekr@rtfm.com; ipsec@lists.tislabs.com
Sent: 3/18/02 10:49 AM
Subject: RE: Choosing between IKEv2 and JFK

> > Anyway, when deciding between the two protocols for the next
> generation of
> > IKE, it may be good to keep in mind that IKEv1 will most
> probably be around
> > for a while (if not for good), living side-by-side with the
> next generation.
>
> How long the IKEv1 will live depends quite a lot of the replacement
> protocol. If the replacement protocol is going to be somewhat similar
> and offers same functionality than IKEv1 then I think IKEv1 will die
> much sooner, i.e after both ends have been updated to the next
> generation protocol they will use that and the IKEv1 functionality can
> be disabled. Later it will propably be optional "old" compatibility
> option that is disabled by default and finally removed from the
> products.
>
> If the replacement protocol does not offer things that IKEv1 currently
> offers and which people actually use, then IKEv1 will stay forever (or
> at least as long as those features are used). This means that instead
> of having one small protocol we have one small protocol plus IKEv1 and
> we must keep the IKEv1 there much longer, because we do not offer same
> functionality with the newer protocol.


I am not sure that this holds true in all cases and more importantly I
am
not sure how we would ensure that the outcome would be as you predict.
It
would be pain to support both IKEv1 and IKEv2 in a product both from a
product development perspective and from produce deployment and
administration perspective.  I bring this up because I find myself
regularly
forced to deal with deficient protocol immortality.  Six years after
arrival
of SSL 3.0, which does everything that 2.0 did and does it better SSL
2.0 is
still around, we are still trying to support it because it is enabled by
default in most products, many OEMs want it just because they are not
sure
if someone may want it.  Worse yet, at least one site (Schwab.com)
*requires* that you connect to it with SSL 2.0 and does *not* work if
SSL
2.0 support is disabled in a browser.

Clearly, this WG can not prohibit using deprecated/obsolete protocols
and
modes but can we do something to facilitate or hasten the demise of
'replaced' protocols?

Khaja