[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: NAT Traversal



At 1:46 PM -0800 3/4/02, Chinna N.R. Pellacuru wrote:
>On Mon, 4 Mar 2002, Srinivasa Addepalli wrote:
>>    I am not sure whether you can restrict the responder to choose
>>    its own SPI. Lot of implementations take advantage of SPI
>>    for faster lookups. This is possible if the IPSEC implementation
>>    is given chance to choose its own SPI without any limitation.
>>    There are some implementations which use all bits of SPI value
>>    for different functionalities within the device.
>
>We only place a restriction on half of the SPI for this reason only. We
>want the other half to be unresticted for implemenations to still have
>some flexibility with picking a SPI for whatever fancy scheme they have.
>
>You should also honor what RFC 2401 says "SAD is indexed by a destination
>IP address, IPsec protocol type, and SPI.
>
>          o SPI: the 32-bit value used to distinguish among different
>            SAs terminating at the same destination and using the same
>            IPsec protocol.
>            [REQUIRED for all implementations]
>
>We will be reducing this un-restricted SPI space from 32 bits to 16 bits,
>because the other 16 bits are generated based on the SPI that the peer has
>picked.
>
>     chinna

Chinna,

Just a few notes re this discussion:

	- the revised ESP/AH documents emphasize that an IPsec 
implementation need not use the protocol type for SPI 
differentiation. so, if one starts assuming this is true, it will be 
yet another conflict with the IPsec specs

	- similarly, an IPsec implementation does not need to use the 
dest IP address as part of the SPI lookup, unless that address is for 
a multicast group.

	- do I understand correctly that you are suggesting a change 
to the specs to reduce the effective SPI space by a factor of 65K? 
is everyone comfortable with this?

Steve