Well said - I agree with Tero. Scott -----Original Message----- From: Tero Kivinen Sent: Sat 3/16/2002 5:28 PM To: Ran Canetti; ekr@rtfm.com; ipsec@lists.tislabs.com Cc: 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/
<<winmail.dat>>