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

Re: Simplifying IKE

On Thu, 9 Aug 2001, Henry Spencer wrote:

> On Thu, 9 Aug 2001, Jan Vilhuber wrote:
> > It's either a single protocol with lots of options and knobs to tune
> > behaviour, or multiple fairly fixed and well-defined protocols that are
> > suited for different tasks... There's no 'one-size fits all' keying protocol.
> 
> That may be true, but it is not a self-evident fact.

Hm.. I think it is. The fact that both main mode and aggressive mode exist,
is proof that there's (at least) two camps that needed to be satisfied in
IKE. One camp wants more security and versatility (negotiation, if you can
call it that), and another camp wants more speed and is willing to sacrifice
identity protection and negotiation.

The existence of KINK is another proof. There's obviously people that need
extremely fast and light-weight keying, which KINK (again arguably) provides
(for certain scenarios).

Personally, I consider that incontrovertible evidence, if not proof.


> And often it
> suffices for a protocol to be "one size fits almost all". 
> 
That doesn't really contradict what I said, of course. If you can get a good
fit for 90%, then you still need a separate protocol for the other 10% (if
they have a strong enough case, which I would argue they have and point at
the KINK WG again). I believe (and again KINK is evidence) that there ISN'T a
fit for 90%. More like 60/40.

All this back and forth in this WG is yet another piece of evidence that
there's no one-size-fits all (or even almost all). Some want AH, others want
to get rid of it. Some want main mode, other want aggressive mode. Ad
nauseum...

I'm not advocating we do them in parallel. Let's define some requirements
that simplifies as much as possible, agree on what can be left out to acheive
that, and send people that don't agree off to write their own requirements
(can't the WG chairs appoint sub-committee's to explore and recommend? Maybe
we should do that).

I think it's actually crucial we spell out what the camps are and what they
need. We currently (I claim) have NO good requirements to go off and revise
IKE, since we don't really know what we're optimizing it for. Do we want
maximum security? Or fast setup? Unless someone shows me an exchange that
combines both, I'm going to continue to claim that those two are mutually
exclusive (I'd be happy to be proven wrong). As long as that dichotomy exists
(amongst others), we'll need two protocols (or one that can do both...
whoops... we already did that once).

Or maybe we just point over to KINK and say "there's your fast setup" and
deal only with the one that does maximum security? Fine by me. But we need to
spell it out, so we can all start working in the same direction...

jan
 --
Jan Vilhuber                                            vilhuber@cisco.com
Cisco Systems, San Jose                                     (408) 527-0847
Follow-Ups: References: