Re: new version of ESP ID

[Stephen Kent <kent@bbn.com>]

At 9:59 AM -0700 7/9/02, Bill Fenner wrote:
>  >First, section 2.2 deprecates sharing an SA among multiple senders to a
>>multicast group and in effect mandates single-sender multicast for ESP
>>groups.  The same is true for AH.  I'm aware of only one protocol, the VRRP
>>specification, that is affected by this change.  VRRP uses AH or ESP but
>>allows multi-source multicast groups.  We should notify the VRRP WG of this
>>potential change.
>
>I brought this up at the WG meeting in Minneapolis.  Several protocols
>that send multicasts on a LAN use this model (VRRP, OSPFv3, PIM,
>IGMP come to mind).
>
>I'd like to see two possible modes for use with multicast:
>- anti-replay sequence number per sender, with a shared SA.
>- including the source address when demultiplexing to permit SSM semantics.
>
>I know that at least the first is completely opposite of the direction
>that the group has been going.  However, especially with 64-bit anti-replay
>sequence numbers, it permits protocols to use a standard, existing protocol
>even when using static shared SAs.  Yes, a static shared SA buys you much
>less protection than dynamically negotiated ones, but does that mean that it
>should be ruled out?
>
>   Bill

If we include the source address for multicast, to accommodate SSM, 
does that mean I don't have to pay attention to the destination for 
any multicast protocol. That would be a sort of equal tradeoff, 
moving from requiring that an SA be defined by source and SPI instead 
of destination and SPI, for multicast. But I don't want to make life 
more complex by requiring support for all three.

The replay window per sender is more problematic. It breaks the 
simple model of one replay window per SA, and that could have very 
serious implications for hardware devices that choose to keep this 
data on chip. With a one-to-one correspondence between SAs and replay 
windows, it's easy to understand how to allocate space. But an 
unbounded number of senders on one SA, each with a separate replay 
window, is not attractive. If we use the source address plus SPI to 
define a multicast SA, then each sender gets its own SA and replay 
window, by definition.

I don't want to see two modes for multicast. In general, we're trying 
to simplify IPsec requirements as we go along, and this would add 
complexity.


Steve