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

[annelies.van_moffaert@alcatel.be]

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.

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?

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

Kind regards, Lies.







Mark Baugher <mbaugher@cisco.com>@securemulticast.org on 02/07/2002
17:30:35

Sent by:  msec-admin@securemulticast.org


To:   Stephen Kent <kent@bbn.com>
cc:   ipsec@lists.tislabs.com, msec@securemulticast.org
Subject:  [MSEC] Re: new version of ESP ID


Steve,

At 05:07 PM 7/1/2002 -0400, Stephen Kent wrote:
<text deleted>


>>Finally, If we are going to restrict a multicast SA to single-source
>>multicast groups, then I don't understand how we can avoid identifying
>>associating that sender with the SA.  If a member of the single-source
>>multicast group who is not the authorized sender begins sending to that
>>group, there is no way to identify this problem, which will likely break
>>the anti-replay mechanism.
>
>  The SA for a single-sender, multicast SA should specify the address of
> the one, authorized sender and that would be checked by each receiver.

I'm okay with this.  It limits us strictly to single-sender multicast
groups.  Given the complexities of multicast security, that's probably the
best approach at least for the near term.  Shouldn't we document this
constraint in the ESP (and AH) I-Ds?  That is, the receiver SHALL check the
source address of a received packet to ensure that it is from the
authorized sender for the particular SA?


>This is separate from the fact that the IP source address is not (and
>never has been) used in selecting the SA for inbound traffic, i.e., it is
>the destination address and the SPI that are used for that demuxing.

Yes, and this is consistent with what RFC 2401 says:  "The concept is
applicable in the point-to-multipoint case as well."  We disallow having
multiple senders share an SA.  Annalies point was (if I understand her
correctly) that we cannot have multiple SAs for a particular multicast
destination address because the SPIs might collide.  The SPIs might collide
if different group controllers assign them independently.  Do you agree?

Mark


>Steve


_______________________________________________
msec mailing list
msec@securemulticast.org
http://www.pairlist.net/mailman/listinfo/msec