[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



Sorry if any confusion resulted from my choice of words. I also intended to
address the way an SA is identified. Probably "selector" was not the
appropriate term in that case.

 Lies.





Mark Baugher <mbaugher@cisco.com> on 02/07/2002 17:16:04

To:   Markku Savela <msa@burp.tkv.asdf.org>
cc:   Annelies VAN MOFFAERT/BE/ALCATEL@ALCATEL, ipsec@lists.tislabs.com
Subject:  identifying IPsec SAs (was Re: IPsec AH and ESP I-Ds; source
      address as possible SA selector for multicast SA?


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>.  The
issue is whether we support multi-sender multicast groups:  If we allow
multiple senders to a multicast destination address, then a 4-tuple is
needed <SPI, source address, destination, address, IPsec
protocol>.  Otherwise, we lose replay protection.  It's worse if the IPsec
implementation does not correctly handle the case of multiple senders and
attempts IPsec replay protection on two or more different sequence number
spaces.

Mark