RE: NAT Traversal

[Paul Koning <pkoning@equallogic.com>]

>>>>> "Stephen" == Stephen Kent <kent@bbn.com> writes:

 Stephen> ...

 >>> - do I understand correctly that you are suggesting a change to
 >>> the specs to reduce the effective SPI space by a factor of 65K?
 >>> is everyone comfortable with this?
 >>> 
 >>> Steve
 >>> 
 >>  I am suggesting that the original concept of IPsec SA being
 >> identified by a tuple: destination IP, protocol, SPI be required,
 >> and within the SPI add new semantics for picking a SPI on the
 >> phase2 responder.

 Stephen> The new ESP ID, published before the December IETF,
 Stephen> clarified the SPI demuxing description. We have received
 Stephen> feedback on the ID, and nobody has voiced any objections to
 Stephen> this revised SPI demuxing description.  There appear to be
 Stephen> no "cons" to the new wording. The "pros" are that IPsec
 Stephen> implementations need not spend cycles matching additional
 Stephen> fields in inbound IPsec headers that are not needed to demux
 Stephen> SAs, which potentially improves performance. 

Indeed.

And that's already allowed by the earlier specs, because of the fact
that the SPI is chosen by the receiver.  That's a classic good design
approach for fast demuxing.  For example, a receiver might choose the
SPI so the low order N bits (across *all* inbound SAs, not just the
SAs for a particular remote address) are unique and index a vector of
SA state pointers.  Clearly that's a permitted design, and it's a
design that is currently in use.  (Obviously, it then has to verify
that the address and protocol are correct, but that's a compare for
equality, not a search key operation.)

Right now that design works up to a very large number of SAs -- 32
bits is a reasonable size for this scheme.  On the other hand, if you
reduce the portion of the SPI that the receiver can control to 16
bits, this direct indexing approach becomes problematic for larger
implementations.

So in answer to your earlier question: no, reducing the effective SPI
space to 16 bits is not acceptable.

     paul