administrator MUST be able to specify whether or not a user or
   application can override (default) system policies.  Note that
   application specified policies may satisfy system requirements, so
   that the system may not need to do additional IPsec processing beyond
   that needed to meet an application's requirements.  The form of the
   management interface is not specified by this document and may differ
   for hosts vs. security gateways, and within hosts the interface may
   differ for socket-based vs.  BITS implementations.  However, this
   document does specify a standard set of SPD elements that all IPsec
   implementations MUST support.

   The SPD contains an ordered list of policy entries.  Each policy
   entry is keyed by one or more selectors that define the set of IP
   traffic encompassed by this policy entry.  (The required selector
   types are defined in Section 4.4.2.)  These define the granularity of
   policies or SAs.  Each entry includes an indication of whether
   traffic matching this policy will be bypassed, discarded, or subject
   to IPsec processing.  If IPsec processing is to be applied, the entry
   includes an SA (or SA bundle) specification, listing the IPsec
   protocols, modes, and algorithms to be employed, including any
   nesting requirements.  For example, an entry may call for all
   matching traffic to be protected by ESP in transport mode using
   3DES-CBC with an explicit IV, nested inside of AH in tunnel mode
   using HMAC/SHA-1.  For each selector, the policy entry specifies how
   to derive the corresponding values for a new Security Association
   Database (SAD, see Section 4.4.3) entry from those in the SPD and the
   packet (Note that at present, ranges are only supported for IP
   addresses; but wildcarding can be expressed for all selectors):

           a. use the value in the packet itself -- This will limit use
              of the SA to those packets which have this packet's value
              for the selector even if the selector for the policy entry
              has a range of allowed values or a wildcard for this
              selector.
           b. use the value associated with the policy entry -- If this
              were to be just a single value, then there would be no
              difference between (b) and (a).  However, if the allowed
              values for the selector are a range (for IP addresses) or




 
RFC 2401              Security Architecture for IP         November 1998


              wildcard, then in the case of a range,(b) would enable use
              of the SA by any packet with a selector value within the
              range not just by packets with the selector value of the
              packet that triggered the creation of the SA.  In the case
              of a wildcard, (b) would allow use of the SA by packets
              with any value for this selector.

   For example, suppose there is an SPD entry where the allowed value
   for source address is any of a range of hosts (192.168.2.1 to
   192.168.2.10).  And suppose that a packet is to be sent that has a
   source address of 192.168.2.3.  The value to be used for the SA could
   be any of the sample values below depending on what the policy entry
   for this selector says is the source of the selector value:

           source for the  example of
           value to be     new SAD
           used in the SA  selector value
           --------------- ------------
           a. packet       192.168.2.3 (one host)
           b. SPD entry    192.168.2.1 to 192.168.2.10 (range of hosts)

   Note that if the SPD entry had an allowed value of wildcard for the
   source address, then the SAD selector value could be wildcard (any
   host).  Case (a) can be used to prohibit sharing, even among packets
   that match the same SPD entry.

   As described below in Section 4.4.3, selectors may include "wildcard"
   entries and hence the selectors for two entries may overlap.  (This
   is analogous to the overlap that arises with ACLs or filter entries
   in routers or packet filtering firewalls.)  Thus, to ensure
   consistent, predictable processing, SPD entries MUST be ordered and
   the SPD MUST always be searched in the same order, so that the first
   matching entry is consistently selected.  (This requirement is
   necessary as the effect of processing traffic against SPD entries
   must be deterministic, but there is no way to canonicalize SPD
   entries given the use of wildcards for some selectors.)  More detail
   on matching of packets against SPD entries is provided in Section 5.

   Note that if ESP is specified, either (but not both) authentication
   or encryption can be omitted.  So it MUST be possible to configure
   the SPD value for the authentication or encryption algorithms to be
   "NULL".  However, at least one of these services MUST be selected,
   i.e., it MUST NOT be possible to configure both of them as "NULL".

   The SPD can be used to map traffic to specific SAs or SA bundles.
   Thus it can function both as the reference database for security
   policy and as the map to existing SAs (or SA bundles).  (To
   accommodate the bypass and discard policies cited above, the SPD also




 
RFC 2401              Security Architecture for IP         November 1998