RE: NAT Traversal

["Chinna N.R. Pellacuru" <[e-mail]>]

Hi Steve,

I somehow feel that placing additional restrictions on selecting an IPsec
SA is not very good just based on performance reasons. Why was a 32 bit
sequence selected the first time, and how did we endup trying to extend it
now.

If we look at how we ended up with only 4 bytes for the IP address instead
of a variable length IP address: there too, it could be performance and
other reasons that prompted people to go with a 4 byte IP address. I can
see people arguing that 4 bytes of IP address, yes, we will never have
enough nodes to use up all those addresses. We did endup using or
scrambling all our IP addresses, and now moving to IPv6 just becuase we
are running out out IPv4 addresses.

I think we should not place those restrictions just for performance
reasons.

    thanks,
    chinna

On Mon, 4 Mar 2002, Stephen Kent wrote:

> At 3:52 PM -0800 3/4/02, Chinna N.R. Pellacuru wrote:
> >Hi Steve,
> >
> >Is it possible that along with the sequence number, we also increase the
> >SPI space so that we can use some of the SPI space for NAT translation.
> >We could keep the original restrictions on how to pick an SA, or we need
> >to come up with elaborate schemes to effectively increase the SPI space,
> >like you are attempting to increase the sequence number.
>
> I see a problem here. We increased the sequence number size, but
> didn't transmit the extra (high order) 32 bits!  So, I can't see
> folks being fond of an increase in SPI size.  It is no accident that
> the current ESP header is a multiple of both 4 and 8 bytes, using the
> default integrity algorithm length, specifically to ensure IPv4 and
> v6 alignment for the payload. Adding 2 bytes for a bigger SPI would
> break that alignment.
>
> >How does the transition happen? If the new ESP ID is placing additional
> >restrictions that did not exist originally I think it is fair to ask the
> >new ID to accomidate NAT traversal by increasing the SPI space. It's like
> >shutting off all the doors for us.
>
> The extended sequence number is an option that is negotiated by IKE
> (or its successor), so it is backward compatible with existing
> implementations that do not support the extended sequence number
> facility.
>
> >
> >You bring up another good point about multicast. Frankly, I haven't
> >thought about it. I'll have to look at this and get back to you and the
> >list.
>
> OK.
>
> Steve
>

chinna narasimha reddy pellacuru
s/w engineer