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

Re: (IPng) out-of-band key management is like virtual circuits




In message <9502242049.AA04270@snark.imsi.com>  you wrote:

Good points about context for measuring "overhead" elided

> 
> Are we talking about encrypting every packet? We know thats
> expensive. I don't think that has anything to do with Ran's
> architecture -- if you are encrypting all your data, it costs a huge
> amount. And yes, I've got code that does that sort of thing right now,
> and it is bloody expensive. Its unavoidable, however. The solution is
> to use fast ciphers or hardware cipher implementations. Just switching
> from DES to RC4 gives you a huge boost.
> 

I'd like to stop us from beating ourselves too hard about the "costs of
encryption." While in the context of communications protocol execution
"costs" encryption is expensive, but in the context of applications using
these services we're (crypto) not really a problem.  At the September ARPA
Principal Investigators meeting, Van Jacobson pretty eloquently put this when
he compared the "costs" of encryption with the "costs" of running a
multi-media multicasting system. If encryption consumes 10% (real high) of
the available processor, that's minor when compared to the 60, 70, or even
80% of the processor needed to support VAT at 30 fps.

Yes, security should be "cheap", but there is value provided by the use of
security so lets not worry too much about it.

> However, this has nothing to do with performance hits from key
> management. To my knowledge, as it stands you are probably using
> manual keying.
> 
> > If Danny's idea can or may give us a performance gain then why not
> > permit it as an option.
> 
> If someone thinkgs rubbing chicken entrails on our chests will give us
> a performance gain, shall we specify that in an RFC as well?
> 

I think that we should, and since Danvers is real close to the 91st day of
1995, I think that an ID or RFC on poultry enchanced security protocols would
be quite appropriate.

> I fail to understand what sort of performance gain we are to expect
> here. We aren't even being given a model of the sort of traffic we are
> discussing. If we are talking about a Telnet session Danny's notion
> can't give us any observable performance gain. If we are talking about
> a random hit at a DNS server it might give us a gain -- but DNS is not
> being protected with this mechanism. Were we talking about some sort
> of file service arrangement it certainly wouldn't give us a gain.
> 
> Could someone PLEASE tell me how gaining a few milliseconds in startup
> of relationships between hosts that last hours is going to be
> worthwhile? Remember, of course, that we are talking of "worst case"
> situations -- average case you aren't going to gain anything.
> 

Well we wouldn't want to get the relationship off on the wrong foot, we all
know how costly that can be in the long run. And we wouldn't wan to waste
those precious milliseconds when we can replace them with "IVs" which have
bloated to 2, or 3 times their normal length. (And need to be handled as
exceptions in the code, I expect).

> Perry

carl.


References: