Re: SKIP in IPSEC: is it really simple?

[[e-mail]]

> From [e-mail] Thu Sep 12 09:58:58 1996
> From: Rich Skrenta <[e-mail]>
> Message-Id: <[e-mail]>
> Subject: Re: SKIP in IPSEC: is it really simple?
> To: [e-mail]
> Date: Wed, 11 Sep 1996 17:42:53 -0700 (PDT)
> In-Reply-To: <[e-mail]> 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