RE: NAT Traversal

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

On Tue, 5 Mar 2002, Paul Koning wrote:
> Judging by the tone of your note, I am probably wasting my time, but I
> will make one more attempt to explain this to you.

Same here. I'll also try and make one last attempt to try and convince you
that RFC2401 pretty strongly recomments that the IPsec SA be picked on
{dest IP, IPsec protocol, SPI}.

First of all, the performance argument is pretty moot.

Please clarify your position more:

And, are you saying that RFC 2401 is irrelevant to IPsec, because we are
fully and more clearly specifying in an update to the ESP RFC, how all
IPsec implementations should *implement* their internal SPI selection
logic, (which has only local significance). How about an RFC just to
specify how all IPsec implementations MUST *implement* their SPI
selection. That way there will be no need to update RFC 2401 just because
by "mistake" the *implementation* of SPI selection by all IPsec
implementations was not specified properly.

- Are there any IDs already trying to supercede RFC 2401?

- Are there any IDs trying to just specify how all IPsec implemenations
MUST *implemnt* their internal SPI selection.

- How can an ESP RFC supercede some behaviour in the Architecture RFC?

- Are there any IDs that are trying to "fix" this in AH too?

- People are already complaining about the number of redirections that are
needed becuase there are already too many RFCs that people have to read,
to get a basic understanding of IPsec. By having a new kind of dependency
where something is specified in one RFC (the Architecture RFC), and
"fixed" in another RFC (a new ESP RFC) which is actually superceding
another RFC (original ESP RFC), will just make people crazy.

According to RFC 2119:

"1. MUST   This word, or the terms "REQUIRED" or "SHALL", mean that the
   definition is an absolute requirement of the specification.
"

The excerpts from RFC 2401:

excerpt 1: Page 7, Section 4.1 Definition and Scope

"  A security association is uniquely identified by a triple consisting
   of a Security Parameter Index (SPI), an IP Destination Address, and a
   security protocol (AH or ESP) identifier.
"

excerpt 2: Page 16, Section 4.4.1 The Security Policy Database (SPD)
"
   For an inbound IPsec packet for which multiple IPsec SAs are to be
   applied, the lookup based on destination address, IPsec protocol, and
   SPI should identify a single SA.
"

excerpt 3: Page 17, same Section as above
"
Note that this selector is conceptually different from the "Destination IP
Address" field in the <Destination IP Address, IPsec Protocol, SPI> tuple
used to uniquely identify an SA. When a tunneled packet arrives at the
tunnel endpoint, its SPI/Destination address/Protocol are used to look up
the SA for this packet in the SAD.  This destination address comes from
the encapsulating IP header.
"

excerpt 4: Page 20, Section 4.4.3 Security Association Database (SAD)
"
   For
   inbound processing, each entry in the SAD is indexed by a destination
   IP address, IPsec protocol type, and SPI.  The following parameters
   are associated with each entry in the SAD.  This description does not
   purport to be a MIB, but only a specification of the minimal data
   items required to support an SA in an IPsec implementation.

   For inbound processing: The following packet fields are used to look
   up the SA in the SAD:

         o Outer Header's Destination IP address: the IPv4 or IPv6
           Destination address.
           [REQUIRED for all implementations]
         o IPsec Protocol: AH or ESP, used as an index for SA lookup
           in this database.  Specifies the IPsec protocol to be
           applied to the traffic on this SA.
           [REQUIRED for all implementations]
         o SPI: the 32-bit value used to distinguish among different
           SAs terminating at the same destination and using the same
           IPsec protocol.
           [REQUIRED for all implementations]

"

excerpt 5:
"
5.2.1 Selecting and Using an SA or SA Bundle

   Mapping the IP datagram to the appropriate SA is simplified because
   of the presence of the SPI in the AH or ESP header.  Note that the
   selector checks are made on the inner headers not the outer (tunnel)
   headers.  The steps followed are:

           1. Use the packet's destination address (outer IP header),
              IPsec protocol, and SPI to look up the SA in the SAD.  If
              the SA lookup fails, drop the packet and log/report the
              error.
"

excerpt 6:
"
    SPI
        Acronym for "Security Parameters Index".  The combination of a
        destination address, a security protocol, and an SPI uniquely
        identifies a security association (SA, see above).  The SPI is
        carried in AH and ESP protocols to enable the receiving system
        to select the SA under which a received packet will be
        processed.  An SPI has only local significance, as defined by
        the creator of the SA (usually the receiver of the packet
        carrying the SPI); thus an SPI is generally viewed as an opaque
        bit string.  However, the creator of an SA may choose to
        interpret the bits in an SPI to facilitate local processing.
"

excerpt 7: Page 54, B.3 Path MTU Discovery
"
   The destination security gateway and SPI uniquely define a security
   association which in turn defines a set of possible originating
   hosts.
"

excerpt 8: Page 55, section B.3.2 Calculation of PMTU
"Within a single host, multiple applications may share an SPI and nesting
of security associations may occur.  (See Section 4.5 Basic Combinations
of Security Associations for description of the combinations that MUST be
supported). "

    chinna