Re: [MSEC] Re: new version of ESP ID

[Stephen Kent <kent@bbn.com>]

At 6:09 PM +0200 7/2/02, annelies.van_moffaert@alcatel.be wrote:
>Mark and Steve,
>
>I am not sure I completely understand your arguments. I would think that
>there is a difference between saying that
>1. IPsec can only be used to protect SSM or single-source multicast groups
>and
>2. When using IPsec to protect multicast traffic one should use a seperate
>SA per sender.
>
>In the second case there can be more than 1 sender allowed to send to the
>same group. Both legitimate senders and receivers should then e.g.
>authenticate to a common key server and the key server could create for
>each sender a seperate SA. Additionally the key server would push the SAs
>to the group of receivers.

The second case would be consistent with the IPsec architecture. The 
common key server needs to assign the SPIs uniquely for the multicast 
group as well as provide keys to the group members. In this model, 
each SA has just one authorized sender and so anti-replay can be 
employed, and each receiver can use the SPD to constrain the source 
address appropriately. But, the granularity of the source 
authentication is still just the group, since each receiver also 
could send traffic claiming to be from the authorized sender.

>A concrete example could be hosts that all send IGMP messages to the group
>address to which all IGMP capable routers listen  or PIM routers that all
>send PIM messages to the PIM group address. It could also be a multicast
>data service with more than one legitimate source (all sources should then
>probably be under the control of a single key server).
>
>Do you have scenario 1 in mind or scenario 2 or again something else?
>
>
>A second question I have relates to the statement that "the receiver SHALL
>check the source address to ensure that it is from the authorized sender".
>Isn't this a weak check given that a source address can be spoofed by a
>receiver who wants to impersonate the sender?

It is effective for unicast SAs, but it is a less effective control 
for multicast SAs, in so far as any multicast group member has the 
requisite key material to spoof. However I do not envision changing 
this general requirement to special case multicast SAs. As noted 
earlier, if you don't feel that the check is really useful in the 
multicast context, you can set the source address to be * for these 
SAs.

>Mark explained correctly my concern related to colliding SPI values when
>independent group controllers manage SAs for the same destination address.
>Thanks! ;-) I think this problem could be solved by adding the source
>address to the triplet (SPI, protocol, dest IP addr).

What problem? We still require coordination for SPI management on a 
per multicast group address basis, so if you want to create multiple 
SAs for the multicast group, one per sender, why not use SPIs for 
this purpose. I am hesitant, to say the least, to impose a new, 
additional burden on all IPsec implementations to use sources 
addresses for demuxing, when the same effect can be achieved using 
the SPI.

Steve