RE: NAT Traversal

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

On Mon, 4 Mar 2002, Chinna N.R. Pellacuru wrote:

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

And considering the fact that an IPsec SA is identified by the tuple:
Destination, Protocol and SPI, the probability of a collision is even
lower, and for all practical purposes zero.

    chinna