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

RE: Please save the pre-shared key mode


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: