[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: SKIP in IPSEC: is it really simple?
> From ipsec-request@neptune.hq.tis.com Thu Sep 12 09:58:58 1996
> From: Rich Skrenta <skrenta@osmosys.incog.com>
> Message-Id: <199609120042.RAA17690@miraj.incog.com>
> Subject: Re: SKIP in IPSEC: is it really simple?
> To: ipsec@TIS.COM
> Date: Wed, 11 Sep 1996 17:42:53 -0700 (PDT)
> In-Reply-To: <199609111751.NAA734524@mailhub1.watson.ibm.com> from
> Content-Length: 3621
> Status: RO
...............................
>
> > Isn't this a highly misleading argument??
>
> 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.
If you run SKIP PFS extension, then the start up cost is about as high
as any other interactive KMP.
...............
> > 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.
Why stop ? Just negotiate a new key before the old key expires.
>
> 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
> 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).
I am sure your product can do that but I fail to see where such
flexibility is mentioned in the SKIP draft. You are actually
enhancing SKIP to address a practical concern. I think this is another
example of the complexity of the KMP issue. There are so many concenrs
and many requirements that it is hard to find a one-size-fit-all
solution.
Pau-Chen