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

From: [email-masked]
Date: Tue, 2 Jul 2002 18:09:11 +0200

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 <[email-masked]>@securemulticast.org on 02/07/2002
17:30:35

Sent by:  [email-masked]

To:   Stephen Kent <[email-masked]>
cc:   [email-masked], [email-masked]
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
[email-masked]
http://www.pairlist.net/mailman/listinfo/msec

_______________________________________________
msec mailing list
[email-masked]
http://www.pairlist.net/mailman/listinfo/msec

---

From: Ran Canetti <[email-masked]>
Date: Mon, 29 Jul 2002 14:26:18 -0400

Haitham,

Regarding the distributed controller issue. MSEC has set up for itself to first
address the single controller setting, with the ideas that:
1) the single controller setting is complex and relevant enough 
2) there can be many alternative ways to distribute the functionality of the
controller. In the most part, this can be done in a "transparent" way
as far as the group members are concerned. Furthermore, there seems to be 
less urgent need for standardization there.

I suggest to limit further discussion of this issue to the msec list,
no need to bother ipsec with this.

Ran

> From: Haitham Cruickshank <[email-masked]>
> 
> ...
> 
> 1. Scalability:  For very large groups (thousands of members) or very dynamic
> multicast groups (frequent join and leaves), having a single group controller
> might not scale well specially for re-keying problem (changing keys when
> members join or leave).  If this problems is true, then we need to have a
> distributed group controller/controllers and this brings new problems which has
> been discussed in some previous emails.
> 
> ...