[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: reserving some SAIDs
Steve Bellovin write:
> I have a different model in mind for multicast. Unless public
> keys are used -- and they're too expensive for general bulk traffic
> -- everyone in a multicast group has to share the same key. The
> SAID is therefore redundant. I thus suggest using SAID 0 with
> multicast to denote the per-address key. Non-zero keys would be
> bound to the source/destination pair, and would be used with public
> key, for low-volume transmissions. (I envision its use with things
> like sd, where the sending rate is on the order of once per minute,
> and the packet contents may not even change.)
I'm not sure that this will work either. Assuming that one will desire to
rekey the multicast SA, what SAID (read keyid) will be used? My model here
is that for some period of time two keys will be valid. Everyone sends on
the new key and receives on either, the SAID telling you which. Assignment
of the multicast SAID would be made by the creator of the multicast key, and
its value relayed to multicast participants when the key is distributed.
Also, is there any desire to allow multiple classifications/services to use
the same low-level multi-cast address? Today, a single multicast address
carries serveral types of traffic, if each type is encrypted differently, or
has different access rules, a different key may be needed. For example, a
particular multicast address may carry both video and audio, the video
unencrypted, and the audio encrypted, how would SAIDs be established to
denote this. (I admit that it just occurred to me will there be a NULL key
for which an SAID may be assigned to denote bypass?) (Alternatively think of
video encrypted with RC4 and audio encrypted with DES.)
carl.
Follow-Ups:
References: