Re: new version of ESP ID

[Stephen Kent <kent@bbn.com>]

At 1:11 PM -0400 7/2/02, Andrea Colegrove wrote:
>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?

Symbolic names in the SPD for S/D IP address selectors are mapped 
into specific addresses when an SA is established, so I don't know 
what you have in mind here. "Opaque" applies to port fields, but not 
IP addresses.  (The text in 2401 is not clear enough about this, just 
as it needs to improve re the discussion of how symbolic names are 
used.)

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

IKEv2 and JFK are competing replacements for IKE v1. I don't see the 
split you allude to above, i.e., I expect the WG to select one 
replacement, because the choice affects not only the local device, 
but also any device with which it communicates. So a I can't have one 
protocol for security gateways and another for small, mobile devices, 
if these devices ever want to communicate with a computer behind a 
security gateway, for example.

Nonetheless, your question is relevant. There is a distinction 
between what 2401 will mandate in terms of SPD capabilities, and what 
any key/SA management protocol provides. I think it is reasonable for 
IPsec to be able to use more than one key/SA management protocol, but 
the SPD should be uniform and the protocols should support what the 
SPD allows users to express. The concern I have re support of 
multicast is any imposition of new requirements on the "fast path" 
processing required of all IPsec implementations. As more of these 
move into hardware, to accommodate higher speeds, we cannot easily 
make changes on things such as SA demuxing without severely affecting 
this hardware.

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

I would like to continue with the assumption that the SPIs MUST be 
managed in a coordinated fashion for each, individual multicast 
group. A failure to coordinate will fail secure, which is the highest 
priority for IPsec, and hopefully the failure will allow affected 
subscribers to invoke management mecahnsisms to fix the problem.

Steve