[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: (IPng) Re: out-of-band key management is like virtual circuits
Ashar Aziz says:
> > From perry@imsi.com Fri Feb 24 15:15 PST 1995
> > Under those circumstances, SKIP would display absolutely identical
> > properties if it was to perform well. You would end up having to cache
> > lots of keys in the kernel -- unless you were going to do server
> > lookups on each, with several packet exchanges, which would obviate
> > all claims of performance advantages.
>
> As I just explained in an earlier message to Carl, SKIP caching is quite
> different from caching stateful connections. It is very session-less,
Ashar;
A session is a lump of data sitting in memory. It isn't a bunch of
phone linemen with trucks. Our connections are "virtual"; they are
just state. From what I can tell, SKIP forces you to cache a bunch of
data, and other proposals do, too. As soon as you start having to keep
track of data, you aren't stateless and thats all that
counts. "Sessions" are a red herring. The question is state, and you
have it just like all the other proposals. You can't avoid it.
One reason people have to want to be stateless is that things like DNS
get huge amounts of traffic from lots of sources -- but you would have
just as bad a problem securing DNS traffic as anyone else, because
you'd have to do lots of database lookups for your keys just like
everyone else. IPSP isn't suitable for such applications -- only
things like the Eastlake-Kaufman DNS proposal, which produce very low
server overhead by pre-signing lots of data, will work for such
applications.
> and with the right implementation, one can almost completely hide the
> overhead of expensive public-key operations; this cannot be achieved
> by caching traditional secure sessions.
Why not? So far as I can tell you are just labeling your data
differently -- you are also involving state, you are just calling it
something else.
> > Now, as for firewalls with large numbers of clients, I have actually
> > built and operated such firewalls. They all operate with application
> > level relays which are far heavier weight, statewise, than security
> > associations could ever be. These firewalls function just fine.
>
> We have several firewalls in-house as well. However, these firewalls
> with application-layer relays have never been used to establish
> entire virtual enterprises over a public net like the Internet.
What is a "virtual enterprise", and why should we expect it to be any
harder to establish than anything else? Anyway, the point was simply
that existing systems that employ state are capable of handling fairly
heavy loads -- loads similar, if not higher than, the ones we would
expect to have to hit in machines dealing with the sort of state that
SKIP or other protocols would induce in them. And yes, Ashar, you are
not proposing a stateless protocol no matter what you would say.
> > > Normally, one can simply blow away half-open connections when
> > > the side that has crashed detects them. This is not so trivial for a
> > > security session because this has to be done securely, otherwise
> > > denial-of-service attacks would be trivial. (Not to say that this can't
> > > be solved, but this at least presents another complication).
> >
> > I don't see why its a problem at all. The TCP connections to the dead
> > machine will vanish on their own. The security associations will
> > eventually time out and go away. New connections from the rebooted
> > machine will form new security associations.
>
> Yes, but we are not talking about a security protocol just for TCP.
Thats completely irrelevant. You just put an inactivity timer on your
SA structures and they clean themselves up. Bit deal.
> We are talking about a security protocol for IP, and TCP is not the
> only thing that runs over IP. In particular, secure sessions running
> underneath session-less protocols (e.g. UDP based apps) will not time out
> and vanish.
Yes they will. If you have no traffic for long enough a period, you
can time out your state, and if new traffic arises, you can
re-establish it.
> (As it so happens, the encrypted video demo using Sun's ShowMe
> application that I gave at the San Jose IETF is one such application.)
ShowMe is a very heavyweight application -- you get data packets from
it on a constant basis. I would expect, then, that the half-open state
problem would not be a problem -- a two minute inactivity timer on
your state would easily handle the problem. That was your original
point, remember?
In any case, I assume that you have to build such stuff into the cache
of state that you have to have built into your SKIP implementation,
because unless you are caching keys that you expect to be using soon,
you will hit insanely bad performance problems -- like having to do an
X.500 query to the X.500 database you are depending on to store your
X.509 certificates on every packet for which you haven't already
cached the keys.
Perry
References: