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

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

At 1:55 PM -0500 1/2/03, 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

Russ,

The receiver needs an easy way to tell what fields to examine, and it needs to do so very early in the demuxing process. Otherwise this could become a rate-limiting part of processing. Your suggestion may be a good one, so long as we agree that we will not need to provide more ways of distinguishing which demuxing rules to use, else we would need to reserve even more of the SPI space for further subdividing.