Re: new version of ESP ID

[Stephen Kent <kent@bbn.com>]

At 12:19 PM -0400 7/2/02, Andrea Colegrove wrote:
>Mark and Steve,
>     I agree that if only one sender is authorized than that sender should be
>indicated in the SA as policy that must be adhered to.  This should not cause
>one to disallow multiple senders sharing an SA.  The policy rule must be
>flexible enough to allow an entity, a list, a rule, a wildcard, etc. to cover
>all multicast scenarios.  It would be a shame to break future advanced
>multicast uses.
>     I agree with Annalies that anti-replay is still a problem.  We all
>acknowledged that several years ago in smug.  We also discussed the SPI
>collision problem at that time.  The probability that two sender-specific SAs
>would be assigned the same SPI in the same destination (multicast) address
>space is rather slim.  Do you anticipate using different group keys 
>for each of
>those SAs?
>
>--- Andrea

Andrea,

The current facilities in 2401 do not mandate support for lists of IP 
addresses for an SA, although that is a feature we plan to put in 
2401bis. So, relative to current standards, there is no way to 
associate a list of authorized senders for a single SA.  You can 
specify a single address, a range of addresses, or allow any address, 
but not an enumerated list. (This was a feature in the ID that was 
deleted before we went to RFC, to match what IKE could negotiate.)

Every SA nominally has a different set of keys, and that's what IKE, 
IKE v2, and JFK provide. However one could imagine a key management 
protocol which created multiple SAs with a common key, e.g., for the 
purposes you cite here. However,
I would not expect Ipsec to treat such SAs specially, e.g., to know 
that the keys are common and thus to svae state space as a result.

In any case, we have always required that SPI assignment be 
coordinated for all parties using the same multicast address. This is 
essential for the reasons I cited in my recent, previous message. 
Thus I do not understand the notion of SPI collisions relative to a 
single multicast address, irrespective of whether there is one sender 
or multiple senders.

Steve