RE: NAT Traversal

["Chinna N.R. Pellacuru" <pcn@cisco.com>]

On Mon, 4 Mar 2002, Stephen Kent wrote:

> 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

Curious what are the reasons for removing this restriction, and what are
the cons of still reqiring that this restriction apply.

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

Here also, curious why that it is not required anymore to have dest IP
address as part of SPI lookup.

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

I am suggesting that the original concept of IPsec SA being identified by
a tuple: destination IP, protocol, SPI be required, and within the SPI add
new semantics for picking a SPI on the phase2 responder.

    thanks,
    chinna