[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