Re: NAT Traversal

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

" For inbound processing, each entry in the SAD is indexed by a
destination IP address, IPsec protocol type, and SPI."

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

I only see REQUIRED all over this. I don't see a "*may*" anywhere here.
Wondering if there are multiple versions of RFC 2401, and we are looking
at different versions?

In any case, I think you bring up another point. Probably you in your
implementation (probably being an "endpoint" IPsec implementation), will
only deal with a maximum of a couple of IPsec SAs at any time. I can
understand why someone with such a narrow point of view, obviously feels
that indexing the SAD by destination address, protocol and SPI for just a
couple of IPsec SAs, is such a performance hog and also so obviously feels
that they are unnecessarily complicating the SAD data structures.

You should atleast try and visualize how an implementation that is
claiming to support hunderds of thousands of IPsec peers simultaneously,
should implement their SAD. There are various reasons for having more
structure to the SAD (I can't beleive that we are discussing this
implementation stuff on a WG maillist!). You want to classify your SAD
entires on Destination address, and Protocol because we need to consult
the SAD for other purposes, than just finding an SA. For example we would
want to know if we have any IPsec SAs to a peer with a particular
Destination IP address, in order to decide whether to send an Initial
Contact. Walking through your entire hash table which is indexed only on
the SPI, and looking at each IPsec SA, and looking at the peer address is
one way to do it. But, that is not an efficient way to do it, even if you
have a reasonable number of IPsec SAs in your SAD. On top of that we
maintain multiple SADs per box. Probably one per interface and one per VPN
routing/forwarding instances (VRF). So it becomes pretty inefficient
pretty quick if you don't have more structure in your SAD. So, we endup
with different kinds of indexing for different purposes. If we are doing
something pretty often, in order to optimise just that query to the SAD,
we might endup with another parellel indexing scheme for the SAD.

Good for you, you probably don't have to deal with all this complicated
stuff. Unfortunately, we have to. So, please try to understand our
position too.

    thanks,
    chinna

On Wed, 6 Mar 2002, Bill Sommerfeld wrote:

> > I agree to your above assertion, and I also want to state that RFC 2401
> > REQUIRES all IPsec implementations to search the SA on {dest IP, IPsec
> > Protocol, SPI}, and also pretty strongly recommends all IPsec
> > implementations to index their SAD by Destination Address, Protocol and
> > SPI.
>
> This is not my interpretation of 2401.  2401 says that the receiver
> picks the SPI.  A consequence of this is that:
>
>  - the IPsec protocol value *may* be used as part of the lookup but
>    there is no requirement that it be used.
>
>  - in the case of unicast traffic, an implementation could assign SPIs
>    in such a way that it need not use the destination address to look up the
>    SA (however, it might examine the destination address in subsequent
>    policy checks).
>
> 					- Bill
>

chinna narasimha reddy pellacuru
s/w engineer