must be mappable to the externally observable characteristics of this
   model.

   There are two nominal databases in this model: the Security Policy
   Database and the Security Association Database.  The former specifies
   the policies that determine the disposition of all IP traffic inbound
   or outbound from a host, security gateway, or BITS or BITW IPsec
   implementation.  The latter database contains parameters that are
   associated with each (active) security association.  This section
   also defines the concept of a Selector, a set of IP and upper layer
   protocol field values that is used by the Security Policy Database to
   map traffic to a policy, i.e., an SA (or SA bundle).

   Each interface for which IPsec is enabled requires nominally separate
   inbound vs. outbound databases (SAD and SPD), because of the
   directionality of many of the fields that are used as selectors.
   Typically there is just one such interface, for a host or security
   gateway (SG).  Note that an SG would always have at least 2
   interfaces, but the "internal" one to the corporate net, usually
   would not have IPsec enabled and so only one pair of SADs and one
   pair of SPDs would be needed.  On the other hand, if a host had
   multiple interfaces or an SG had multiple external interfaces, it
   might be necessary to have separate SAD and SPD pairs for each
   interface.






 
RFC 2401              Security Architecture for IP         November 1998


4.4.1 The Security Policy Database (SPD)

   Ultimately, a security association is a management construct used to
   enforce a security policy in the IPsec environment.  Thus an
   essential element of SA processing is an underlying Security Policy
   Database (SPD) that specifies what services are to be offered to IP
   datagrams and in what fashion.  The form of the database and its
   interface are outside the scope of this specification.  However, this
   section does specify certain minimum management functionality that
   must be provided, to allow a user or system administrator to control
   how IPsec is applied to traffic transmitted or received by a host or
   transiting a security gateway.

   The SPD must be consulted during the processing of all traffic
   (INBOUND and OUTBOUND), including non-IPsec traffic.  In order to
   support this, the SPD requires distinct entries for inbound and
   outbound traffic.  One can think of this as separate SPDs (inbound
   vs.  outbound).  In addition, a nominally separate SPD must be
   provided for each IPsec-enabled interface.

   An SPD must discriminate among traffic that is afforded IPsec
   protection and traffic that is allowed to bypass IPsec.  This applies
   to the IPsec protection to be applied by a sender and to the IPsec
   protection that must be present at the receiver.  For any outbound or
   inbound datagram, three processing choices are possible: discard,
   bypass IPsec, or apply IPsec.  The first choice refers to traffic
   that is not allowed to exit the host, traverse the security gateway,
   or be delivered to an application at all.  The second choice refers
   to traffic that is allowed to pass without additional IPsec
   protection.  The third choice refers to traffic that is afforded
   IPsec protection, and for such traffic the SPD must specify the
   security services to be provided, protocols to be employed,
   algorithms to be used, etc.

   For every IPsec implementation, there MUST be an administrative
   interface that allows a user or system administrator to manage the
   SPD.  Specifically, every inbound or outbound packet is subject to
   processing by IPsec and the SPD must specify what action will be
   taken in each case.  Thus the administrative interface must allow the
   user (or system administrator) to specify the security processing to
   be applied to any packet entering or exiting the system, on a packet
   by packet basis.  (In a host IPsec implementation making use of a
   socket interface, the SPD may not need to be consulted on a per
   packet basis, but the effect is still the same.)  The management
   interface for the SPD MUST allow creation of entries consistent with
   the selectors defined in Section 4.4.2, and MUST support (total)
   ordering of these entries.  It is expected that through the use of
   wildcards in various selector fields, and because all packets on a




 
RFC 2401              Security Architecture for IP         November 1998


   single UDP or TCP connection will tend to match a single SPD entry,
   this requirement will not impose an unreasonably detailed level of
   SPD specification.  The selectors are analogous to what are found in
   a stateless firewall or filtering router and which are currently
   manageable this way.

   In host systems, applications MAY be allowed to select what security
   processing is to be applied to the traffic they generate and consume.
   (Means of signalling such requests to the IPsec implementation are
   outside the scope of this standard.)  However, the system