Source address as possible SA selector for multicast SA?

[annelies.van_moffaert@alcatel.be]

Mark,

Thanks for your comments. As far as scalability is concerned. I agree that
one SA per sender doesn't scale well for groups with a very large number of
senders.  However would the alternative be not to use the anti-replay
mechanism? Or to use one SA for the whole group but within this SA a
seperate sequence number window per sender? The latter case keeps also
state per sender. So I guess it is not perfect from a scalability point of
view either and it doesn't solve a number of other issues that a seperate
SA per sender perhaps could solve.

In case the source address could (optionally) be used as SA selector this
could also be used to authenticate IGMP messages. Note that this would not
be restricted to multicast addresses in the SSM range only.
Since IGMP messages are exchanged only locally between hosts and routers on
the same subnet, it would be most logical and preferable, I think,that also
the SAs that protect these IGMP messages would be completely managed
locally. However there are IGMP messages that are sent to the group
addresses that have members on the subnet. In other words, apart from the
source of the multicast data, the IGMP routers are also `sources' of IP
packets sent to this address. Hence if the IGMP SAs are set up locally and
independently from the global owner then the same ambiguity problem as for
independent SSM sources can occur.

The latter problem is also discussed in the last update of the draft
draft-irtf-gsec-igmpv3-security-issues-02.txt
(only in version 2; this version will hopefully be soon available but I can
of course always send it to interested people.)

Kind regards,
 Annelies Van Moffaert





Mark Baugher <mbaugher@cisco.com> on 01/07/2002 19:35:03

To:   Annelies VAN MOFFAERT/BE/ALCATEL@ALCATEL
cc:   ipsec@lists.tislabs.com
Subject:  Re: IPsec AH and ESP I-Ds; source address as possible SA
      selector for multicast SA?


Annelies,
   Pardon my late response, I somehow misplaced this note.

At 05:10 PM 6/17/2002 +0200, annelies.van_moffaert@alcatel.be wrote:
>Dear all,
>
>Some time ago I posted a comment on the list regarding the new IPsec AH
and
>ESP I-Ds
>  draft-ietf-ipsec-rfc2402bis-00.txt and
>  draft-ietf-ipsec-esp-v3-02.txt
>
>In these drafts it is stated that for multicast the SPI in combination
with
>the destination IP address is used to select an SA. This can however lead
>to ambiguity problems for SSM SAs (SSM = Source Specific Multicast).
>
>A range of multicast IP addresses is reserved for SSM. In SSM a group is
>characterized by the pair (source IP address, destination IP address) and
>every source can freely choose a destination IP address from the SSM
range.
>This means that it is possible that two different sources use the same
>group address as IP destination address.
>If the group controllers of the 2 would happen to choose the same SPI
value
>then the common receivers cannot distinguish between the SAs for the 2
>different groups since they have the smae SPI and the same destination IP
>address.

Yes, I think this could be a problem.  A second potential problem that I
mentioned in my previous message is when more that one sender sends to a
single-source group.  IGMPv3 provides a mechanism to prune unauthorized
sources, but IGMPv2 might be used and the pruning may not occur because a
particular receiver did not issue the request.  In either case, the
sequence number spaces will differ between the sources and cause problems
at an unknowing reciever.


>I think a good solution would be to include also the source address in the
>SA selector for multicast SAs. This would also be very useful  to protect
>IGMP messages by means of IPsec AH.

I favor this approach but it is not consistent with RFC2401.  That's one
issue.  Another issue is whether we restrict SA's to be single-sender SAs
if we associate the source address with the SA.  In this case, the receiver
can maintain a separate replay vector for each source.  This approach won't
scale to very large groups but will work for "small" and "moderate" size
multi-sender groups.

Mark


>Steve Kent, author of the I-Ds, replied to me that it is up to the WG to
>discuss this, hence my email...
>
>So I have to questions for the group:
>Is the above mentioned problem already solved for the IPsec AH and ESP
>I-Ds? and
>Could the source IP address be included as SA selector?
>
>Kind regards,
>  Lies Van Moffaert.
>
>
>
>
>
>Stephen Kent <kent@bbn.com> on 03/05/2002 22:44:03
>
>
>
>  To:      Annelies VAN MOFFAERT/BE/ALCATEL@ALCATEL
>
>  cc:      ipsec@lists.tislabs.com
>
>
>
>  Subject:
>
>
>
>
>
>
>At 2:51 PM +0200 4/30/02, annelies.van_moffaert@alcatel.be wrote:
> >Hi Steven and all,
> >
> >I read the new IP Authentication Header I-D and I have a small question
or
> >remark about the multicast SAs. I saw that these are identified by the
> >destination IP address
> >and the SPI value and optionally, the protocol ID.
> >I'm not sure whether this rules out all possible ambiguity for SSM. For
>SSM
> >the IP destination address does not need to be unique (if I remember
> >correctly). A group session is in SSM identified by the pair (Source IP,
> >Destination IP) and it is possible that 2 different sources choose the
>same
> >SSM group address as Destination IP address. The group controller of
each
> >will pick independently an SPI number. It's of course very unlikely but
I
> >think that it is then strictly speaking possible to have the same (SPI,
> >Destination IP) pair for 2 different SSM sessions. In this case the
> >receiver cannot differentiate between two different SAs since they have
>the
> >same identification pair (Destion IP, SPI). Is this correct or did I
> >overlook something?
> >
> >Kind regards,
> >  Lies