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

Re: Choosing between IKEv2 and JFK



This really just brings up the point that if we focus on the requirements,
ensure that it aligns to what the user community wants and the WG agrees to
them, then, I suspect the march towards IKEv2 will be focused and done
effectively in a short period of time. Maybe during this IETF, we can get
some general agreement to the requirements, so we can focus on fulfilling
them.

My 2 cents (I hope of the common variety)
Scott
----- Original Message -----
From: "Tero Kivinen" <kivinen@ssh.fi>
To: "Ran Canetti" <canetti@watson.ibm.com>; <ekr@rtfm.com>;
<ipsec@lists.tislabs.com>
Sent: Saturday, March 16, 2002 5:28 PM
Subject: Re: Choosing between IKEv2 and JFK


> canetti@watson.ibm.com (Ran Canetti) writes:
> > 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.
>
> > Thus, it may be beneficial to have a next generation protocol that best
> > matches the scenarios that IKEv1 doesnt.
>
> I disagree. I think we want to phase IKEv1 out as soon as possible,
> meaning that we do want to have protocol that is implementation
> preserving, and that will can act as a replacement of the IKEv1 from
> the day one (i.e there is no reason to run IKEv1 if both ends support
> new version).
>
> > Here it seems to me that JFK provides a good complement to IKEv1: If
> > you want algorithm negotiation, two-phase structure, pre-shared key
> > mode (and are willing to pay the price) then use IKEv1.
>
> Meaning that quite a lot of people keep running IKEv1, and if this
> seems to be acceptable for you, then why are we doing anything at all?
>
> > If you want a leaner protocol and your particular
> > application does not require these funtions then use JFK.
> --
> kivinen@ssh.fi
> SSH Communications Security                  http://www.ssh.fi/
> SSH IPSEC Toolkit                            http://www.ssh.fi/ipsec/