[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: NAT Traversal



On Tue, 5 Mar 2002, Stephen Kent wrote:
>
> 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.
>
>

We based our design on what the RFC 2401 says:

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

So, RFC 2401 is wrong? The suggestion is that we reduce the SAID space by
4 bytes of IP address, and a bit for protocol (because we currently have
only two IPsec protocols, AH and ESP). Effectively reducing the SAID space
by 33 bits.

This is being suggested only for performance-based reasons. I don't think
the performance benefits are significant enough for us to change RFC 2401.
TCAMs can handle large selectors. Selector size is not the most important
problem that TCAMs are dealing with now. I think the resoning that TCAMs
cannot handle large selector sizes is dated. We are only talking about
adding 4 bytes of destination IP address, and a byte for protocol into the
selector for the TCAM. That is just 5 bytes. The TCAMs are alredy having
to deal with the increase in IP address from 4 bytes to 16 bytes, and
there can be multiple of these IP addresses in the selector (for IPsec
atleast 2). I think it is just a myth that the biggest problem with TCAMs
is the selector size.

Even in software, I don't think that there is any significant performance
benefit. I think it's more of a burden (regardless of hardware or
software) to make absolutely sure that the SPI we use is unique on the
box, if we are going to require it to be unique. The SPIs are sent with
each proposal, and we only endup using one of the proposals. We need to
keep track of what SPIs were allocated to these proposals that are being
negotiated. We can NOT just look at the SADB and pick a SPI that is not in
the SADB. And, there needs to be some garbage collection to be done to
scavange all the SPIs we burn up when we propose a bunch of proposals. The
SPI space can get pretty fragmented once rekeys happen, and it just
becomes a nightmare to have to pick a SPI that we are absolutely sure that
it is unique.

It is much more easier to not have to change RFC 2401 and reduce the
existing SAID space.

    chinna