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

[Haitham Cruickshank <H.Cruickshank@eim.surrey.ac.uk>]

Hi Everybody,

I have attended the ipsec meeting at the ieft 54 meeting and Steve Kent has
presented some interworking problems with IP multicast.  Is it possible to
start a discussion on how to solve such problems.

I can see two major multicast problems:

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.

2. Anti-relay procedures for multiple senders:  Steve has pointed (quite
rightly) the problem that anti-replay procedures (receivers keeping track of
sequence numbers and sequence number windows) works OK for unicast or single
source multicast.  The potential problem is having unbounded number of senders,
where the ipsec receivers (especially hardware implementations) have to track
of sequence numbers and sequence number windows for each individual senders.
In my personal opinion, the anti-replay should be switched off for multi
senders.  Of course, this will weaken the security system against DOS attacks.

Can ipsec and msec people express opinion on how to solve these issues.
Thanks.

Haitham

Stephen Kent wrote:

> 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

--
Dr. Haitham S. Cruickshank

Senior Research Fellow in Communications
Centre for Communication Systems Research (CCSR)
School of Electronics, Computing and Mathematics
University of Surrey
Guildford, Surrey GU2 7XH, UK

Tel: +44 1483 686007 (indirect 689844)
Fax: +44 1483 686011
e-mail: H.Cruickshank@surrey.ac.uk
http://www.ee.surrey.ac.uk/Personal/H.Cruickshank/