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

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/