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

Re: Please save the pre-shared key mode

  The draft which calls itself IKEv2 _is_ a working group draft.

  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: