[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