MUST provide a means of mapping traffic to these functions, even
   though they are not, per se, IPsec processing.)  The way in which the
   SPD operates is different for inbound vs. outbound traffic and it
   also may differ for host vs.  security gateway, BITS, and BITW
   implementations.  Sections 5.1 and 5.2 describe the use of the SPD
   for outbound and inbound processing, respectively.

   Because a security policy may require that more than one SA be
   applied to a specified set of traffic, in a specific order, the
   policy entry in the SPD must preserve these ordering requirements,
   when present.  Thus, it must be possible for an IPsec implementation
   to determine that an outbound or inbound packet must be processed
   thorough a sequence of SAs.  Conceptually, for outbound processing,
   one might imagine links (to the SAD) from an SPD entry for which
   there are active SAs, and each entry would consist of either a single
   SA or an ordered list of SAs that comprise an SA bundle.  When a
   packet is matched against an SPD entry and there is an existing SA or
   SA bundle that can be used to carry the traffic, the processing of
   the packet is controlled by the SA or SA bundle entry on the list.
   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.

   The SPD is used to control the flow of ALL traffic through an IPsec
   system, including security and key management traffic (e.g., ISAKMP)
   from/to entities behind a security gateway.  This means that ISAKMP
   traffic must be explicitly accounted for in the SPD, else it will be
   discarded.  Note that a security gateway could prohibit traversal of
   encrypted packets in various ways, e.g., having a DISCARD entry in
   the SPD for ESP packets or providing proxy key exchange.  In the
   latter case, the traffic would be internally routed to the key
   management module in the security gateway.

4.4.2  Selectors

   An SA (or SA bundle) may be fine-grained or coarse-grained, depending
   on the selectors used to define the set of traffic for the SA.  For
   example, all traffic between two hosts may be carried via a single
   SA, and afforded a uniform set of security services.  Alternatively,
   traffic between a pair of hosts might be spread over multiple SAs,
   depending on the applications being used (as defined by the Next
   Protocol and Port fields), with different security services offered
   by different SAs.  Similarly, all traffic between a pair of security
   gateways could be carried on a single SA, or one SA could be assigned
   for each communicating host pair.  The following selector parameters
   MUST be supported for SA management to facilitate control of SA
   granularity.  Note that in the case of receipt of a packet with an
   ESP header, e.g., at an encapsulating security gateway or BITW




 
RFC 2401              Security Architecture for IP         November 1998


   implementation, the transport layer protocol, source/destination
   ports, and Name (if present) may be "OPAQUE", i.e., inaccessible
   because of encryption or fragmentation.  Note also that both Source
   and Destination addresses should either be IPv4 or IPv6.

      - Destination IP Address (IPv4 or IPv6): this may be a single IP
        address (unicast, anycast, broadcast (IPv4 only), or multicast
        group), a range of addresses (high and low values (inclusive),
        address + mask, or a wildcard address.  The last three are used
        to support more than one destination system sharing the same SA
        (e.g., behind a security gateway). 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.
        Once the packet has been processed according to the tunnel SA
        and has come out of the tunnel, its selectors are "looked up" in
        the Inbound SPD.  The Inbound SPD has a selector called
        destination address.  This IP destination address is the one in
        the inner (encapsulated) IP header.  In the case of a
        transport'd packet, there will be only one IP header and this
        ambiguity does not exist.  [REQUIRED for all implementations]

      - Source IP Address(es) (IPv4 or IPv6): this may be a single IP
        address (unicast, anycast, broadcast (IPv4 only), or multicast
        group), range of addresses (high and low values inclusive),
        address + mask, or a wildcard address.  The last three are used
        to support more than one source system sharing the same SA
        (e.g., behind a security gateway or in a multihomed host).
        [REQUIRED for all implementations]

      - Name: There are 2 cases (Note that these name forms are
        supported in the IPsec DOI.)
                1. User ID
                    a. a fully qualified user name string (DNS), e.g.,
                       mozart@foo.bar.com
                    b. X.500 distinguished name, e.g., C = US, SP = MA,
                       O = GTE Internetworking, CN = Stephen T. Kent.
                2. System name (host, security gateway, etc.)
                    a. a fully qualified DNS name, e.g., foo.bar.com