Re: AHbis WG LC: need for source address based selectors

[Stephen Kent <kent@bbn.com>]

At 10:47 AM +0300 6/16/03, Pekka Nikander wrote:
>One more comment to the AHbis WG LC:
>
>AHbis currently states the following:
>
>>2.4  Security Parameters Index (SPI)
>>
>>The SPI is an arbitrary 32-bit value that is used by a receiver to 
>>identify the SA to which an incoming packet is bound. For a unicast 
>>SA, the SPI can be used by itself to specify an SA, or it may be 
>>used
>>in conjunction with the IPsec protocol type (in this case AH). 
>>Since, for unicast SAs, the SPI value is generated by the receiver, 
>>whether the value is sufficient to identify an SA by itself, or 
>>whether it must be used in conjunction with the IPsec protocol 
>>value is a local matter.  The SPI field is mandatory and this 
>>mechanism for
>>mapping inbound traffic to unicast SAs described above MUST be 
>>supported by all AH implementations.
>
>However, in the SEND WG we are using AH with public key crypto,
>with a fixed SPI.  There the key used depends on the sender of
>the message, not the receiver.  Hence, for our purposes neither
>the SPI alone nor SPI + protocol are enough.  We need also the ability
>to select the SA based on SPI + source address, even for unicast.
>
>
>>If an IPsec implementation supports multicast, then it MUST support 
>>multicast SAs using the following algorithm for mapping inbound 
>>IPsec
>>datagrams to SAs. ...  Each entry in the Security Association
>>Database (SAD) [KA98a] must indicate whether the SA lookup makes use
>>of the source and destination IP addresses, in addition to the SPI.
>>... (There is no current requirement to support SA mapping based on
>>the source address but not the destination address, thus one of the
>>possible four values is not meaningful.) ....
>
>Since we are using PK crypto, we also need the possibility for
>selecting the SA based solely on the source address.  In fact,
>for our fixed SPI, the destination address does not have any role,
>not even whether the destination address is unicast or multicast.
>
>I don't know how to handle this so late in the process.  I would
>like to see the text to be sufficiently revised to allow source
>address based SA selection, so that we could use it directly in SEND.
>However, I have no idea how the IPSEC WG would feel about that.
>
>--Pekka Nikander
>   SEND WG co-chair

It sounds like SEND would like to use the AH format, but has a 
processing model that is not aligned with the way IPsec uses SAs in 
general.  We had extensive discussion in this WG about demuxing for 
inbound IPsec traffic after the MSEC folks expressed concern about 
the current process last fall. The demuxing spec has been very stable 
for several YEARS; we tweaked it very slightly for MSEC, after 
considerable debate and analysis, to accommodate SSM.  Your proposed 
change represents yet another bit of complexity for an IPsec 
implementation and I question whether the WG ought to agree to such a 
change at this late date.

Steve