SKIP in IPSEC: is it really simple?

[[e-mail]]

Ref:  Your note of Wed, 11 Sep 1996 17:42:53 -0700 (PDT) (attached)

 >
 > What is misleading to say is that SKIP has as high an overhead at startup
 > as an Oakley exchange, when the overhead in practice is considerably less.
 > It is also misleading to say that one can't have PFS in SKIP without
 > throwing out all of SKIP's advantages; this isn't true.

I haven't said or implied that. Any real advantages of SKIP can be
added into the ISAKMP/Oakley framework (in particular, I was personally
all for a convergence of all these protocols which is technically
feasible, but unfortunately failed).

 >
 > This may well be a matter of religion, and not technical merit.
 > Some will choose to start with a simple protocol, and build upon that.
 > Others advocate designing a large, heavyweight protocol which offers
 > every conceivable feature (except statelessness, that is) from the start.

The point is not to start with a heavyweight protocol that gives you
every conceivable feature (and even statelessness if you want) but
to start with a set of required features (eg PFS and anonymity as
WG requirements, and secure/fresh handshakes as my *personal*
requirement :) and have the right framework to build more features into
it in the future.

 >
 > > ISAKMP/Oakley, on the other hand, has several security advantages
 > > over SKIP
 >
 > Having to stop and renegotiate a session to change the traffic key is not
 > an advantage.

You do not have to stop to renegotiate a key, For example we have continouous
encrypted/authenticated video running with key refreshments in between.

 >
 > It is also incorrect to say that SKIP forces the Internet to standardize
 > on a single g and p; this is once again an administrative issue.  Our
 > implementation currently supports as many local (g, p, i) identities as

Notice the word *local*: I meant a solution that scales to the whole
Internet where not only *local parties* can communicate and inter-operate.

 > the administrator cares to configure.  It must, in order to support
 > simultaneous interoperability with products deployed to the different
 > rings of the US export law hell (2048 US, 1024 Swiss banks, 512 non-US).
 >
 >
 > In any event, it's clear that there hasn't been, and won't be, consensus
 > to back one KMP exclusively.  Continuing to delay further is pointless.
 > Let's have all existing KMPs proceed within the WG with the same status
 > as soon as possible.
 >
My personal vote here is against co-existence. That will postpone global
success (inter-operability) even more. There will be time to tune the
one chosen protocol later with experience. But there should be one basis
for all.

Hugo