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

Re: Proposed text changes to ESPbis and AHbis for multicast support


Russ,

The SMuG group a couple of years did consider putting some structure/meaning into the SPI, but the idea was not followed through due to the (perceived) difficulty of moving the idea through the IPsec WG.

cheers,

thomas
------

At 1/2/2003||01:55 PM, Russ Housley wrote:
Thomas:

I have a follow up question to your first ESP recommendation.

---------------------------------------------------------------------
ESPbis-change#1: SPI allocation and SA lookup

Section 2.1 (Security Parameters Index) specifies exactly how the
SPI should be dealt with:

      For multicast SAs, the SPI (and optionally the protocol ID) in
      combination with the destination address is used to select an SA.
      This is because multicast SAs are defined by a multicast
      controller, not by each IPsec receiver. (See the Security
      Architecture document for more details) [ESPbis].

We propose this section to be replaced with the following wording:

      For broadcast, multicast, and anycast SAs, the SPI and protocol
      ID (ESP) in combination with the destination address is used to
      select an SA. In some cases, other parameters (such as a source
      address) MAY be used by a receiver to further identify the
      correct SA. This is because multicast SAs may be defined by more
      than one multicast group controller.
---------------------------------------------------------------------

Would it help if the SPI indicated whether the associated security association was unicastor multicast (which includes broadcast and anycast)? If there were an indication in the SPI itself, then the implementation would know if the unicast or multicast rules should be applied.

If this is of value, the most significant bit could be used to indicate the security association type.

Russ