[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
SKIP in IPSEC: is it really simple?
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