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

Re: Re[2]: Granularity of authentication in swIPe

On Jun 24, 17:20, Phil Karn wrote:

 >Also, I think that the SAID structure must support IP broadcast and IP 
 >multicast. For this reason, I want a larger SAID (say, 32 bits for 
 >compatabiltiy with the IEEE 802.10 Secure Data Exchange and Key Management 
 >Protocol).  Management of broadcast and multicast keys within the Internet 
 >will require a large pool of SAIDs.
 
% As I think Perry already said, SAIDs logically include the IP
% addresses.  They're just like TCP sockets - each connection is
% uniquely identified by the concatentation of the IP addresses and port
% numbers, which means you need many fewer port numbers than you
% otherwise would if everything was identified solely by port number.
 
I need to be able to use IPSP on my MLS workstations (e.g. Sun).  I
also have other systems which need to have many concurrent
connections.  32 bits is a practical minimum.  The TCP ports and IP
addresses are already accounted for when I say this.

% As an aside I just don't see any easy way to support multicast in IPSP
% that doesn't require a public key operation for each packet. Much of
% the utility of IPSP comes from setting up a session key using a fairly
% expensive key exchange protocol that is run only once for some fairly
% large number of packets. But I don't see any easy way to do this for
% multicast.
% 
% I can see putting in hooks for multicast, but it's hard to see how
% they could be really useful given the current costs of even a public
% RSA operation.

If you mean that it is hard to do scalable multicast key management
using any published key mgmt protocol, then I agree.  There are some
promising developments recently (e.g. the work by Reiter) but it
remains very much an area for research.

However, I can do manual key distribution and/or reuse existing
published key mgmt techniques for small multicast groups.  I plan to
do this.  Also, one can use hardware to make various algorithms
execute more quickly.  While we need to take software implementation
considerations into account, we must also recall that there will also
be hardware implementations and should avoid undue constraints on
them.  IMHO, IPSP must not preclude support for multicasting since
multicasting is a fundamental service in the community.

I hope we're agreeing here, but am not sure.

Ran
atkinson@itd.nrl.navy.mil