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

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


bound@zk3.dec.com says:
> Look folks lets slow down here and go back to basic protocol of 1993
> #101.  You can gain performance in networks in various manners.  Like
> reducing memory copies, avoiding fine granular timers, and piggybacking
> data and even packets.  The in-band approach can possibly increase
> performance becuase of the latter strictly from a pure packet throughput
> and avoidance of signing the key out-of-band data which is going to cost
> extra.

Jim;

1) Over the life of a typical Telnet session or AFS file sharing
   session or whatever, the few extra milliseconds involved in a user
   level packet exchange won't be noticed. Note that needing a packet
   exchange is worst case. I don't think it will occur normally.
2) Typical ICMP and other "system" applications will not be using user
   level keying and average case will have their security associations
   in place at the time of a packet transmission -- in other words,
   they will almost always be "in cache" as it were.

> The other basic is why cannot we have it as an option.  How many of you
> have tested Rans architecture in your code?  The Digital team has.  And
> it will be very costly to your end systems.

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.

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 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.

> In addition its completely in line with my input to Ran on the issue of
> Key Mgmt and the Security architecture and how a particular MUST is
> worded.  In fact this is a good LAST CALL I don't like this argument to
> the IESG if necessary.

I don't believe a last call has been issued. Could you explain what it
is that you are speaking of?

Perry
Follow-Ups: References: