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

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


Dan Nessett says:
> Out-of-band management assumes either that
> a synchronized security assocation already exists between the source and
> destination hosts or that when an IP packet is processed, the key management
> software is called to establish this context. Those familiar with X.25 will
> recognize this as a virtual circuit model of operation. In fact I think it
> is a fair characterization that out-of-band key management imposes a
> "security virtual circuit" model on IP security (both IPv4 and IPv6).
> 
> In-band key management, on the other hand, is philosophically similar to
> dynamic connection management, which is the technique employed by TCP.

Are you attempting to make an emotional argument here based on on the
assumption that people will have a knee jerk reaction against things
you label as being "X.25"ish? Unless that is your point, I cannot see
why mentioning "X.25" vs. "TCP" would be important.

You know, TCP connections require out of band mechanisms for
determining mappings between host names and addresses. They also
require out of band negotiation of IP routing and fixed preselection
of communications ports. Somehow, we survive with all of this.

> An important point that some may have overlooked is that the current
> draft of the IPv6 security Architecture I-D (I couldn't find an
> security architecture I-D for IPv4) encourages the use of
> user-to-user keying (by specifying that implementations MUST support
> user-to-user keying, but only MAY provide for host-to-host keying),
> rather than host-to-host keying. The implication is that everytime a
> new *user* communicates to a specific machine, the key management
> software will be required to establish a new security
> association. If out-of-band keying is used, this is going to mean,
> on average, very poor performance, since the key management protocol
> must use a separate communications stream to establish the keys for
> use before communications on the stream originating the key
> management activity can proceed.

Is this based on your implementation experience? Could you please post
some numbers describing how bad the performance is in practice? I was,
in fact, unaware of your implementation.

You know, horrors, virtually every time a TCP connection gets built on
our network a DNS query has to be made. Performance is obviously
impossibly low as a result of this.  I say we get rid of DNS and put
the queries in band somehow to increase performance.

(The existing implementation work indicates that that crypto
algorithms so dominate the costs of what we are doing that an extra
packet exchange at the start of a connection is almost an invisible
cost by comparison.)

I don't think that even Ashar, who wants the in-band stuff to support
SKIP, would argue that the out-of-bandness is per se a performance
problem, especially given that his stuff is still going to require
external communciation to look up keys and the like in databases.

Perry
Follow-Ups: References: