Re: Son of IKE: A proposal for moving forward

[Michael Thomas <mat@cisco.com>]

Uri Blumenthal writes:
 > On Thursday 13 June 2002 09:14, Stuart Jacobs wrote:
 > > If this group restricts their focus primarily on the VPN scenarios
 > > below then they are ignoring a major role that IPsec is expected to
 > > fill by large enterprises.
 > 
 > Stu, the point is not to LIMIT the protocol to VPN scenarios! The
 > point is that VPN scenarios MUST BE INCLUDED/SUPPORTED, 
 > mentioned because (as I understood) some argued that it's unnecessary.
 > 
 > As I understood Michael, he doesn't want the overhead involved
 > with VPN functionality support. But in my view (and in view of some 
 > other WG members) - cutting it out will reduce the protocol to unusable.

Uri,

I'm not sure that that's what I meant, but I can
see how it would be construed that way. As I said,
I'm rather schizophrenic about this issue. We
really, really need to enable strong auth on the
next gen of IP widgets -- ie, things that aren't
going to have 80GB disks and 512MB of ram to
fritter away.

Ted's right that Moore's law eventually solves
this, but that's a rather facile arguement if it
solves it *too late*. That is, if the next gen of
widgets either do without strong auth altogether,
or find something like WEP which is "easier" to
implement at the cost of near complete insecurity,
we're not doing the user base any favors.

Frankly, I don't think that we're really at the
point where we can handwave things away with
Moore's law: there's a whole new generation of
cheap wireless widgets on the horizon and they
have a hard time swallowing IKE as it's currently
defined. Nor do they seem to need a lot of what
IKE has to offer: cell phones seem to work pretty
OK with simple SIM based authentication. That is,
their needs seem simplier than your average road
warrior.

This is why I wonder if there are two problem
spaces. You've taken this to mean my suggesting
that the split should VPN/not-VPN, but that's
just one way to carve the problem space up.
Another might be to differentiate via remote
access, or some other split. A third way to deal
with this is to potentially legitimize "profiles"
where we have a very slim inner protocol which can
and should be implemented by *everything* where
you have additional functionality layered on 
through, say, different standard's track RFC's,
or whatever.

The bottom line is that I'm much more interested
that this issue is considered seriously than any
particular way to solve it. When I floated the
JFK/IKEv2 split, it was mainly because I can see
how to make JFK a very light weight -- but still
useful -- means of establishing transport and
tunnel mode SA's. I like IPsec, generally, because
it opens a lot of options. It would be really nice
to have a base level keying mechanism which would
be shameful not to implement. I think that's
within reach right now, even if the kitchen sink
is not.

		Mike