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

RE: Please save the pre-shared key mode

 >>>>> "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: