Re: new version of ESP ID

[Andrea Colegrove <acc@columbia.sparta.com>]

Stephen Kent wrote:

>
> 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.)
>

Could the opaque value be used and decoded only by multicast aware versions?  Or
is general name flexible enough?

Are there plans to expand the SPD facility to support more generic policy, as
well?  It appears that while RFC 2401 designates IKE as the default security
management mechanism, allowing others, as a "MAY", multiple management mechanisms
may be needed for different uses. (e.g., IKEv2 for gateways, JFK for small mobile
devices, gdoi for single source multicast groups, KMI for government, etc.)  These
mechanisms may also have different policy needs.  For example, GDOI might want to
check that it has received out-of-band, a group policy token that is valid before
proceeding to key distribution.  It would probably be important to show that the
correct management mechanism is selected according to policy and that the security
operating assumptions for each is met.

>
> 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

My thought was that if a lack of coordination did exist and if a collision did
occur (two BIG ifs), then separate keys would cause decryption errors.  A
management channel could then rekey, including the SPI.

--- Andrea