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

Re: Please save the pre-shared key mode

Dan Harkins writes:
 >   The draft which calls itself IKEv2 _is_ a working group draft.

   Oh. I don't mean this in a disparaging way, but how
   did that happen? Do I read too much into the draft-ietf-ipsec-xxx?

   In any case, my real point is that he shouldn't be
   reading anything into the name since that's a
   function of the requirements.

	    Mike

 > 
 >   Dan.
 > 
 > On Fri, 07 Dec 2001 08:54:47 PST you wrote
 > > 
 > > The fundamental mistake you're making here is
 > > giving special status to the name of *a*
 > > non-working group draft which calls itself IKEv2.
 > > It's not decided whether the working group will
 > > take IKEv2 as the basis of SOI, nor is it clear
 > > that the WG will call it "IKEv2" even if it did.
 > > 
 > > Again, what is important at this point is setting
 > > the requirements to evaluate all of the candidate
 > > protocols. The requirements currently do not say
 > > that SOI will be everything that IKEv1 is and
 > > more.  If you want the requirements to
 > > specifically say this, I think you need to get WG
 > > consensus for that, which I doubt there currently
 > > is.
 > > 
 > > 		Mike
 > > 
 > > 
 > > Paul Koning writes:
 > >  > >>>>> "Michael" == Michael Thomas <mat@cisco.com> writes:
 > >  > 
 > >  >  Michael> Paul Koning writes:
 > >  >  >> >>>>> "Wang," == Wang, Cliff <CWang@smartpipes.com> writes:
 > >  >  >> 
 > >  >  >> Wang,> Very simple reasons, IKEv1 is going to be replaced by IKEv2
 > >  >  >> in Wang,> the future and KINK has yet to be standardized and it is
 > >  >  >> not Wang,> going to replace IKE. On the other hand, adding PSK
 > >  >  >> support in Wang,> IKEv2 is not an overkill, but provides much more
 > >  >  >> flexibilities Wang,> and more choices for service providers.
 > >  >  >> 
 > >  >  >> Agreed.
 > >  >  >> 
 > >  >  >> It makes no sense to call a protocol XYZv2 if you're removing from
 > >  >  >> it one of the very widely used features of XYZv1.
 > >  >  >> 
 > >  >  >> If you want a protocol without preshared keys, feel free, but then
 > >  >  >> don't call it IKE and don't expect people to give up IKEv1.
 > >  >   
 > >  >  Michael> The name of protocol is irrelevant at this point.
 > >  > 
 > >  > I don't agree.
 > >  > 
 > >  > Its name *is* relevant if it is a name that says "this is the second
 > >  > version of a previously defined protocol, intended to supersede the
 > >  > first version".  And that is the name currently given to the draft.
 > >  > 
 > >  > So... is the intent that this protocol is supposed to be viewed as a
 > >  > replacement for the protocol defined in RFC 2408/2409?  Or is it
 > >  > supposed to be considered a new, unrelated, protocol?
 > >  > 
 > >  > If the latter, then the requirements set is open.  But if the former,
 > >  > then the new protocol MUST include among its requirements all the
 > >  > features of the earlier protocol that are important.  It is clear from
 > >  > looking at customer installations that pre-shared key is a critical
 > >  > feature of IKE.
 > >  > 
 > >  > Another point: if the problem with IKEv1 is that it has too many
 > >  > options -- which is a fair point -- how does it help matters to define
 > >  > yet another protocol that products will have to implement IN ADDITION
 > >  > to the already existing complex protocol?  Why bother?  If the goal is
 > >  > to improve matters for implementers and customers, the goal should be
 > >  > to create a new protocol which is indeed a viable replacement for the
 > >  > previous protocol, fully entitled to the name "IKE V2" because it
 > >  > incorporates the capabilities for which there is a proven need while
 > >  > cleaning up in other areas.
 > >  > 
 > >  > So what are we doing?  Creating more protocols that increase
 > >  > everyone's burden, or making things simpler?
 > >  > 
 > >  > 	   paul
 > >  >
Follow-Ups: References: