[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Simplifying IKE
On thing that might help to show that there really is
a division in the problem space is that VPN's generally
compete with the time it takes a modem to train --
ie, they are replacing dial and its expectations which
has a lot of head room for fat. It's hard to imagine
how you coujld make a VPN startup worse than that.
On the other hand, we have transport like uses
which have the expectation that anything you add
beyond SYN/SYN-ACK/ACK is unwanted overhead (or
less). Many thing are already piling on with
just-one-more-exchangeitus, and security (along
with signaled QoS) deliver us pretty quickly to
hell by way of handbasket.
So, I really don't have a very good opinion on
how to make the engineering tradeoffs, but it
seems as long as there is transport mode IPsec,
this sort of debate is going to go on.
[and to the fans of killing transport, do tell
what the viable alternative is to IPsec, and
please don't say TLS since it doesn't work with
UDP]
Mike
Jan Vilhuber writes:
> 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
>
References: