Re: identifying IPsec SAs (was Re: IPsec AH and ESP I-Ds; source address as possible SA selector for multicast SA?

[Mark Baugher <mbaugher@cisco.com>]

Markku,
    I may be misunderstanding something about IPsec.  By my reading of RFC 
2401, the SA is uniquely identified by <SPI, destination address, IPsec 
protocol> and it is not possible to install another SA having the same 
triple but with a different source address based upon some SPD entry.

Mark
At 06:57 PM 7/2/2002 +0300, Markku Savela wrote:

> > From: Mark Baugher <mbaugher@cisco.com>
> > Cc: annelies.van_moffaert@alcatel.be, ipsec@lists.tislabs.com
> > Content-Type: text/plain; charset="us-ascii"; format=flowed
> >
> > At 11:25 PM 7/1/2002 +0300, Markku Savela wrote:
> > > > From: Mark Baugher <mbaugher@cisco.com>
> > >
> > > > >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.
> > >
> > >Nothing in RFC2401 prevents using source address as a selector.
> >
> > Annalies used the term "selector," I didn't.  I wasn't referring to the 
> SPD
> > and how packets are selected for IPsec processing but rather how an SA is
> > identified.  Section 4.1 of RFC 2401 says that an IPsec SA is uniquely
> > identified by the triple <SPI, destination address, IPsec protocol>.
>
>Yes, <SPI, destination, protocol>, but then SA is supposed to include
>additional parameters (as per RFC 2401) which are used to distinguish
>between different SA's. One of those parameters is the source address
>(other paramters are the ports and transport protocol).
>
>We could have multiple SA's with same destination (= multicast group),
>with different source address.
>
>The proposed IKEv2 TS payload almost gets it, but there may be some
>confusion about two "source addresses": (1) the source address of
>the IPSEC node and (2) the source address of the original packet.
>
>However, as IKEv2 may not be relevant here (for negotiating multicast
>SA's), this may not be an issue?