RE: NAT Traversal

["Chinna N.R. Pellacuru" <pcn@cisco.com>]

On Mon, 4 Mar 2002, Paul Koning wrote:

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

Yes, this is adding new semantics to the SPIs so that NAT can find out
which SPIs are a pair.

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

The actual working of this technique in NAT is much more complicated than
what you describe above. This will require for you to understand how NAT
works more. We have 16 bits in the responder's SPI for a hash of the
initiator's SPI and we have 16 bits that don't have any constraints. Let's
assume that the unspecified 16 bits are filled randomly.

When a NAT tries to translate the ESP traffic based on matching the SPI in
the above scheme, it maintains these SPIs in its translation table. When
there is some outgoing ESP traffic that NAT sees, which has a SPI that NAT
has never seen before, it will create an entry in its translation table,
which is incomplete. When there is some incoming ESP traffic with a SPI
that NAT hasn't seen before, it will try to match the incoming SPI to any
of the SPIs in the *incomplete* translations only within its translation
table. If there is a match, the translation is completed. If there is no
match the traffic is dropped.  In this context, a collision happens when
we are trying to find out which of the incomplete translations corresponds
to the incoming SPI. Once a translation is made, the new incoming SPIs
don't have to be matched with the already completed translations. So the
probability of a collision is very low, and also a collison can only
happen among the incomplete translations.

    chinna