RE: NAT Traversal

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

On Tue, 5 Mar 2002, Paul Koning wrote:

> >>>>> "Chinna" == Chinna N R Pellacuru <pcn@cisco.com> writes:
>
>  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!

"[REQUIRED for all implementations]"

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

"[REQUIRED for all implementations]"

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

"[REQUIRED for all implementations]"

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

"[REQUIRED for all implementations]"

When is RFC 2401 being updated? I do NOT think it is fair to point to IDs
and implementations do NOT follow the RFC to say that our proposal will
have a potential problem.

    chinna