Re: NAT Traversal

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

On Wed, 6 Mar 2002, Bill Sommerfeld wrote:

> Chinna,
>
> Please see also:
>
>    The receiver-orientation of the Security Association implies that, in
>    the case of unicast traffic, the destination system will normally
>    select the SPI value.  By having the destination select the SPI
>    value, there is no potential for manually configured Security
>    Associations to conflict with automatically configured (e.g., via a
>    key management protocol) Security Associations or for Security
>    Associations from multiple sources to conflict with each other.
>
> This means that *IN PRACTICE*, the "REQUIRED" verbiage you cite means
> very little.

"REQUIRED" in an RFC means nothing, but an obscure paragraph that is
trying to say something about multicast and manually configured SAs MUST
be followed *IN PRACTICE*.

The paragraph is trying to suggest an exception to the regular SA
selection process, in the case of a remote possibility that someone has
setup Manual IPsec SAs to protect Multicast traffic.

That is my understanding of the above paragraph.

>
> Moreover, the author of 2401 has stated in public on several occasions
> without objection that the "REQUIRED" bits will be weakened in a 2401
> followon.

Sorry for having missed these suggestions in the past. There's so much
going on in this WG, it's hard to keep track of what is happening anymore.

Even if the "REQUIRED" bits are weakened, I hope Steve is OK with not
mandating that IPsec implementations are "NOT REQUIRED" to find an SA
based on {dest IP, protocol, SPI}. I do not see why an RFC should say that
all IPsec implementations "MUST NOT" use {dest IP, protocol, SPI} to pick
and SA, because it is not very efficient if you have a small number of
IPsec SAs. I also don't see why and RFC should say, all IPsec
implementations "MUST" use only the SPI to pick an IPsec SA, because it is
much more efficient if you have a small number of IPsec SAs. I would like
to strongly object to any RFC that is trying to mandate what exact SPI
selection logic needs to be used by *ALL* IPsec implementations. Why
should the SAID space be delibirately reduced by 33 bits for no reason.

Not everybody has to implement every proposal that is being considered by
the IETF. Not everybody needs to implement our proposal. Our proposal is
not central to the basic working of IPsec. If someone wants to traverse
through NATs, they can implement a proposal that suits them. So, I don't
see why the general IPsec community should worry about us reducing the SPI
space by 16 bits.  If there is enough flexibility in the SA selection,
those who want to use our SPI matching technique, will choose to use {dest
IP, protocol, SPI} to pick their SAs.

As you said, this is totally internal implementation logic, and an
understanding between the parties that want to interoperate using our
particular proposal.

The whole IPsec community in general is not doing special stuff for
navigating through MPLS that someone else suggested.

    chinna