[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: NAT Traversal
At 4:38 PM -0800 3/4/02, Chinna N.R. Pellacuru wrote:
>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.
We're not "placing additional restrictions on SA selection." We
clarified what was technically required in the first place, but which
was not expressed clearly. We selected 32 bits for the SPI in much
the same way we selected 32 bits for IP v4 addresses: it was the
smallest multiple of 4 bytes that seemed reasonable. (BTW, I erred
in my comments re alignment yesterday, confusing ESP and AH. The ESP
header is exactly 8 bytes long, which is the smallest length that
satisfies the v4 and v6 payload alignment criteria. The integrity
check appears after the payload and thus is not relevant to payload
alignment. In AH, the total length of the protocol header affects
payload alignment, and there the magic number we have adopted, using
the default integrity algorithm, is 24 bytes.)
We did debate on the list whether to go with 16 bits, years ago, and
many folks felt that might not be enough in some contexts. You'd
have to review the archives from 6 or more years ago to reconstruct
the arguments. I'm not saying that we could not revisit the issue,
but I am noting that we did debate it once before.
>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.
Yes, as my comments above note, we went through an analogous
discussion for SPIs.
>
>I think we should not place those restrictions just for performance
>reasons.
>
> thanks,
> chinna
Again, I don't think the characterization you're citing is accurate.
I gave performance-based motivations for why a receiver would prefer
to use just the SPI for SA lookup in unicast contexts. SA lookup is
purely a receiver function, and the specs have ALWAYS made it clear
that the receiver has tremendous leeway in selecting SPI values to
facilitate lookup. Our clarifications in the most recent IDs merely
make clear how a receiver can take advantage of the flexibility that
has always been accorded to it. We're not changing the rules, as you
seem to suggest; we're explaining what a receiver can do within the
scope of the protocol design, and providing rationale that clarifies
when one needs to use more than the SPI to select the right SA.
Steve