RE: NAT Traversal

[Paul Koning <pkoning@equallogic.com>]

>>>>> "Chinna" == Chinna N R Pellacuru <pcn@cisco.com> writes:

 Chinna> 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.
 >> 
 >> 

 Chinna> We based our design on what the RFC 2401 says:

 Chinna> " o SPI: the 32-bit value used to distinguish among different
 Chinna> SAs terminating at the same destination and using the same
 Chinna> IPsec protocol.  [REQUIRED for all implementations] "

 Chinna> So, RFC 2401 is wrong?

No.  But you missed something.

RFC 2401 gives the receiving end of an SA full authority over the SPI
value.  It requires that the SPI values must be unique for a given
protocol and remote destination.  That's the minimum required for
demuxing to work.

But it does NOT require that SPI values be reused among SAs that have
different protocol or destination!

If you had a wide CAM, or fast hash lookup of wide keys, you can reuse
SPI values and lookup on the {address,SPI,protocol} triple.  

However, you're also allowed to select SPI values that are unique
among all SAs no matter what destination or protocol they belong to.
You might do that because you can efficiently look up with small keys,
but not with keys > 32 bits.  Or you might like the direct indexing
scheme I mentioned.

All these are permitted by RFC 2401.

The problem with your proposal is that a subset of the permitted
implementations (and, I suspect, a large subset) would become limited
to 64k SAs total, across all destinations.  That is not reasonable.

   paul