RE: NAT Traversal

[Paul Koning <pkoning@equallogic.com>]

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

 Chinna> When a responder receives a bunch of Phase2 proposals in
 Chinna> Quick mode, it'll pick one proposal, and for that proposal it
 Chinna> generates the SPI(s) which are a hash of the initiator's
 Chinna> SPI(s). In general, IKE will have to request SPIs from the
 Chinna> IPsec implementation because SPI is an IPsec parameter.

I'm not sure what you mean by "...are a hash of the initator's
SPI(s)".  In the existing IPsec/IKE the algorithm for choosing SPI
values is unconstrained.  You can certainly use a hash, but you don't
have to.  The implementation I once worked on did not use a hash at
all.

 Chinna> We only propose to change the semantics of the SPI, IE., now
 Chinna> incoming and outgoing SPIs of an IPsec protocol (ESP or AH)
 Chinna> can be paired. One of them will be the hash of the
 Chinna> other. Actually only half of one of them is a hash of the
 Chinna> other. The other half is still left free, to allow some
 Chinna> flexibility for implementations who want to do fancy things
 Chinna> with SPI generation.

That only works if you want IPsec gateways to be limited to 64k SA
pairs.  Also, if the SPI has 16 bits generated by hashing, you're
likely to have duplicates in that field once you have more than 256 SA
pairs (birthday rule).  That seems like it would be a problem for NAT
processing that relies on these hash fields being effective
discriminators. 

I don't think this approach is workable...

      paul