[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Simplifying IKE
On Thu, 9 Aug 2001, Michael Thomas wrote:
> Ari Huttunen writes:
> > Thus my preference would be to have a four packet phase 1 (base mode) and
> > a four packet quick mode.
>
> Gad. Doesn't anybody care about link up times??? There
> a lots of things which are quite sensitive
> (user experiencewise) to startup delay.
One should point out that main-mode and quick-mode together comprise 6+3
messages (== 9. Make that 10, if you use the commit-bit). You'd actually save
a message (two actually, if you compare apples to apples) by doing base-mode
(4) and a 4 message quick mode. You'd also gain (arguably) some stability in
the protocol.
Of course a 2 message exchange would be even better. No arguments there. Am I
correct in assuming that people agree there's a 2 message exchange by using
some counter mechanism (proposed by Andrew K, I believe), but only if there's
no PFS (and why is that? Can someone explain? All relevant payloads seem to
be in QM1 and QM2 even with PFS)?
Also, we should start to realize that trying to create a single keying
protocol that solves ALL problems is not worthwhile (we've done this in IKE
and it's caused major confusion). If you want shorter setup times, there
should be a different keying protocol for that (say KINK, or something else
we would have to design, if people don't want to use kerberos).
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.
Or rather, there is: it's called IKE.
jan
P.S. I can live with Dan's 3 message exchange IFF it's so well defined that
there's nothing left to the imagination of coders (nothing optional, all
assumptions spelled out including pseudo-code that says in which order to do
things; yes, one could assume we're all adults and don't need such excessive
hand-holding, but the past has shown that's not true at all; the pseudo code
approach is used in the kerberos rfc's, and no one seems to mind overly)...
> Just
> this amount of signaling would be enough to
> dissuade anybody from casually using IKE for,
> oh say, transport mode, and would be pretty
> sucky for everything else too. As Jari points
> out, there are plenty of link layers that
> punish you for these kinds of excesses.
>
> Also: it needs to be said that the when
> security flies in the face usability, it is
> well documented which one is jettisoned...
>
> Mike
>
--
Jan Vilhuber vilhuber@cisco.com
Cisco Systems, San Jose (408) 527-0847
Follow-Ups:
References: