Tech-invite3GPPspaceIETFspace
96959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 4301

Security Architecture for the Internet Protocol

Pages: 101
Proposed Standard
Errata
Obsoletes:  2401
Updates:  3168
Updated by:  60407619
Part 2 of 4 – Pages 18 to 50
First   Prev   Next

Top   ToC   RFC4301 - Page 18   prevText

4.4. Major IPsec Databases

Many of the details associated with processing IP traffic in an IPsec implementation are largely a local matter, not subject to standardization. However, some external aspects of the processing must be standardized to ensure interoperability and to provide a minimum management capability that is essential for productive use of IPsec. This section describes a general model for processing IP traffic relative to IPsec functionality, in support of these interoperability and functionality goals. The model described below is nominal; implementations need not match details of this model as presented, but the external behavior of implementations MUST correspond to the externally observable characteristics of this model in order to be compliant. There are three nominal databases in this model: the Security Policy Database (SPD), the Security Association Database (SAD), and the Peer Authorization Database (PAD). The first specifies the policies that determine the disposition of all IP traffic inbound or outbound from a host or security gateway (Section 4.4.1). The second database contains parameters that are associated with each established (keyed) SA (Section 4.4.2). The third database, the PAD, provides a link between an SA management protocol (such as IKE) and the SPD (Section 4.4.3). Multiple Separate IPsec Contexts If an IPsec implementation acts as a security gateway for multiple subscribers, it MAY implement multiple separate IPsec contexts. Each context MAY have and MAY use completely independent identities, policies, key management SAs, and/or IPsec SAs. This is for the most part a local implementation matter. However, a means for associating inbound (SA) proposals with local contexts is required. To this end, if supported by the key management protocol in use, context identifiers MAY be conveyed from initiator to responder in the signaling messages, with the result that IPsec SAs are created with a binding to a particular context. For example, a security gateway that provides VPN service to multiple customers will be able to associate each customer's traffic with the correct VPN. Forwarding vs Security Decisions The IPsec model described here embodies a clear separation between forwarding (routing) and security decisions, to accommodate a wide range of contexts where IPsec may be employed. Forwarding may be trivial, in the case where there are only two interfaces, or it may be complex, e.g., if the context in which IPsec is implemented
Top   ToC   RFC4301 - Page 19
      employs a sophisticated forwarding function.  IPsec assumes only
      that outbound and inbound traffic that has passed through IPsec
      processing is forwarded in a fashion consistent with the context
      in which IPsec is implemented.  Support for nested SAs is
      optional; if required, it requires coordination between forwarding
      tables and SPD entries to cause a packet to traverse the IPsec
      boundary more than once.

   "Local" vs "Remote"

      In this document, with respect to IP addresses and ports, the
      terms "Local" and "Remote" are used for policy rules.  "Local"
      refers to the entity being protected by an IPsec implementation,
      i.e., the "source" address/port of outbound packets or the
      "destination" address/port of inbound packets. "Remote" refers to
      a peer entity or peer entities.  The terms "source" and
      "destination" are used for packet header fields.

   "Non-initial" vs "Initial" Fragments

      Throughout this document, the phrase "non-initial fragments" is
      used to mean fragments that do not contain all of the selector
      values that may be needed for access control (e.g., they might not
      contain Next Layer Protocol, source and destination ports, ICMP
      message type/code, Mobility Header type).  And the phrase "initial
      fragment" is used to mean a fragment that contains all the
      selector values needed for access control.  However, it should be
      noted that for IPv6, which fragment contains the Next Layer
      Protocol and ports (or ICMP message type/code or Mobility Header
      type [Mobip]) will depend on the kind and number of extension
      headers present.  The "initial fragment" might not be the first
      fragment, in this context.

4.4.1. The Security Policy Database (SPD)

An SA is a management construct used to enforce security policy for traffic crossing the IPsec boundary. 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 specifies minimum management functionality that must be provided, to allow a user or system administrator to control whether and how IPsec is applied to traffic transmitted or received by a host or transiting a security gateway. The SPD, or relevant caches, must be consulted during the processing of all traffic (inbound and outbound), including traffic not protected by IPsec, that traverses the IPsec boundary. This includes IPsec management traffic such as IKE. An IPsec
Top   ToC   RFC4301 - Page 20
   implementation MUST have at least one SPD, and it MAY support
   multiple SPDs, if appropriate for the context in which the IPsec
   implementation operates.  There is no requirement to maintain SPDs on
   a per-interface basis, as was specified in RFC 2401 [RFC2401].
   However, if an implementation supports multiple SPDs, then it MUST
   include an explicit SPD selection function that is invoked to select
   the appropriate SPD for outbound traffic processing.  The inputs to
   this function are the outbound packet and any local metadata (e.g.,
   the interface via which the packet arrived) required to effect the
   SPD selection function.  The output of the function is an SPD
   identifier (SPD-ID).

   The SPD is an ordered database, consistent with the use of Access
   Control Lists (ACLs) or packet filters in firewalls, routers, etc.
   The ordering requirement arises because entries often will overlap
   due to the presence of (non-trivial) ranges as values for selectors.
   Thus, a user or administrator MUST be able to order the entries to
   express a desired access control policy.  There is no way to impose a
   general, canonical order on SPD entries, because of the allowed use
   of wildcards for selector values and because the different types of
   selectors are not hierarchically related.

   Processing Choices:  DISCARD, BYPASS, PROTECT

      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 PROTECT using IPsec.  The
      first choice refers to traffic that is not allowed to traverse the
      IPsec boundary (in the specified direction).  The second choice
      refers to traffic that is allowed to cross the IPsec boundary
      without IPsec protection.  The third choice refers to traffic that
      is afforded IPsec protection, and for such traffic the SPD must
      specify the security protocols to be employed, their mode,
      security service options, and the cryptographic algorithms to be
      used.

   SPD-S, SPD-I, SPD-O

      An SPD is logically divided into three pieces.  The SPD-S (secure
      traffic) contains entries for all traffic subject to IPsec
      protection.  SPD-O (outbound) contains entries for all outbound
      traffic that is to be bypassed or discarded.  SPD-I (inbound) is
      applied to inbound traffic that will be bypassed or discarded.
      All three of these can be decorrelated (with the exception noted
      above for native host implementations) to facilitate caching.  If
Top   ToC   RFC4301 - Page 21
      an IPsec implementation supports only one SPD, then the SPD
      consists of all three parts.  If multiple SPDs are supported, some
      of them may be partial, e.g., some SPDs might contain only SPD-I
      entries, to control inbound bypassed traffic on a per-interface
      basis.  The split allows SPD-I to be consulted without having to
      consult SPD-S, for such traffic.  Since the SPD-I is just a part
      of the SPD, if a packet that is looked up in the SPD-I cannot be
      matched to an entry there, then the packet MUST be discarded.
      Note that for outbound traffic, if a match is not found in SPD-S,
      then SPD-O must be checked to see if the traffic should be
      bypassed.  Similarly, if SPD-O is checked first and no match is
      found, then SPD-S must be checked.  In an ordered,
      non-decorrelated SPD, the entries for the SPD-S, SPD-I, and SPD-O
      are interleaved.  So there is one lookup in the SPD.

   SPD Entries

      Each SPD entry specifies packet disposition as BYPASS, DISCARD, or
      PROTECT.  The entry is keyed by a list of one or more selectors.
      The SPD contains an ordered list of these entries.  The required
      selector types are defined in Section 4.4.1.1. These selectors are
      used to define the granularity of the SAs that are created in
      response to an outbound packet or in response to a proposal from a
      peer.  The detailed structure of an SPD entry is described in
      Section 4.4.1.2. Every SPD SHOULD have a nominal, final entry that
      matches anything that is otherwise unmatched, and discards it.

      The SPD MUST permit a user or administrator to specify policy
      entries as follows:

       - SPD-I: For inbound traffic that is to be bypassed or discarded,
         the entry consists of the values of the selectors that apply to
         the traffic to be bypassed or discarded.

       - SPD-O: For outbound traffic that is to be bypassed or
         discarded, the entry consists of the values of the selectors
         that apply to the traffic to be bypassed or discarded.

       - SPD-S: For traffic that is to be protected using IPsec, the
         entry consists of the values of the selectors that apply to the
         traffic to be protected via AH or ESP, controls on how to
         create SAs based on these selectors, and the parameters needed
         to effect this protection (e.g., algorithms, modes, etc.). Note
         that an SPD-S entry also contains information such as "populate
         from packet" (PFP) flag (see paragraphs below on "How To Derive
         the Values for an SAD entry") and bits indicating whether the
Top   ToC   RFC4301 - Page 22
         SA lookup makes use of the local and remote IP addresses in
         addition to the SPI (see AH [Ken05b] or ESP [Ken05a]
         specifications).

   Representing Directionality in an SPD Entry

      For traffic protected by IPsec, the Local and Remote address and
      ports in an SPD entry are swapped to represent directionality,
      consistent with IKE conventions.  In general, the protocols that
      IPsec deals with have the property of requiring symmetric SAs with
      flipped Local/Remote IP addresses.  However, for ICMP, there is
      often no such bi-directional authorization requirement.
      Nonetheless, for the sake of uniformity and simplicity, SPD
      entries for ICMP are specified in the same way as for other
      protocols.  Note also that for ICMP, Mobility Header, and
      non-initial fragments, there are no port fields in these packets.
      ICMP has message type and code and Mobility Header has mobility
      header type.  Thus, SPD entries have provisions for expressing
      access controls appropriate for these protocols, in lieu of the
      normal port field controls.  For bypassed or discarded traffic,
      separate inbound and outbound entries are supported, e.g., to
      permit unidirectional flows if required.

   OPAQUE and ANY

      For each selector in an SPD entry, in addition to the literal
      values that define a match, there are two special values: ANY and
      OPAQUE.  ANY is a wildcard that matches any value in the
      corresponding field of the packet, or that matches packets where
      that field is not present or is obscured.  OPAQUE indicates that
      the corresponding selector field is not available for examination
      because it may not be present in a fragment, it does not exist for
      the given Next Layer Protocol, or prior application of IPsec may
      have encrypted the value.  The ANY value encompasses the OPAQUE
      value.  Thus, OPAQUE need be used only when it is necessary to
      distinguish between the case of any allowed value for a field, vs.
      the absence or unavailability (e.g., due to encryption) of the
      field.

   How to Derive the Values for an SAD Entry

      For each selector in an SPD entry, the entry specifies how to
      derive the corresponding values for a new SA Database (SAD, see
      Section 4.4.2) entry from those in the SPD and the packet.  The
      goal is to allow an SAD entry and an SPD cache entry to be created
      based on specific selector values from the packet, or from the
      matching SPD entry.  For outbound traffic, there are SPD-S cache
      entries and SPD-O cache entries.  For inbound traffic not
Top   ToC   RFC4301 - Page 23
      protected by IPsec, there are SPD-I cache entries and there is the
      SAD, which represents the cache for inbound IPsec-protected
      traffic (see Section 4.4.2).  If IPsec processing is specified for
      an entry, a "populate from packet" (PFP) flag may be asserted for
      one or more of the selectors in the SPD entry (Local IP address;
      Remote IP address; Next Layer Protocol; and, depending on Next
      Layer Protocol, Local port and Remote port, or ICMP type/code, or
      Mobility Header type).  If asserted for a given selector X, the
      flag indicates that the SA to be created should take its value for
      X from the value in the packet.  Otherwise, the SA should take its
      value(s) for X from the value(s) in the SPD entry.  Note: In the
      non-PFP case, the selector values negotiated by the SA management
      protocol (e.g., IKEv2) may be a subset of those in the SPD entry,
      depending on the SPD policy of the peer.  Also, whether a single
      flag is used for, e.g., source port, ICMP type/code, and Mobility
      Header (MH) type, or a separate flag is used for each, is a local
      matter.

      The following example illustrates the use of the PFP flag in the
      context of a security gateway or a BITS/BITW implementation.
      Consider an SPD entry where the allowed value for Remote address
      is a range of IPv4 addresses: 192.0.2.1 to 192.0.2.10.  Suppose an
      outbound packet arrives with a destination address of 192.0.2.3,
      and there is no extant SA to carry this packet.  The value used
      for the SA created to transmit this packet could be either of the
      two values shown below, depending on what the SPD entry for this
      selector says is the source of the selector value:

          PFP flag value  example of new
          for the Remote  SAD dest. address
          addr. selector  selector value
          --------------- ------------
          a. PFP TRUE     192.0.2.3 (one host)
          b. PFP FALSE    192.0.2.1 to 192.0.2.10 (range of hosts)

      Note that if the SPD entry above had a value of ANY for the Remote
      address, then the SAD selector value would have to be ANY for case
      (b), but would still be as illustrated for case (a).  Thus, the
      PFP flag can be used to prohibit sharing of an SA, even among
      packets that match the same SPD entry.

   Management Interface

      For every IPsec implementation, there MUST be a management
      interface that allows a user or system administrator to manage the
      SPD.  The interface must allow the user (or administrator) to
      specify the security processing to be applied to every packet that
      traverses the IPsec boundary. (In a native host IPsec
Top   ToC   RFC4301 - Page 24
      implementation making use of a socket interface, the SPD may not
      need to be consulted on a per-packet basis, as noted at the end of
      Section 4.4.1.1 and in Section 5.)  The management interface for
      the SPD MUST allow creation of entries consistent with the
      selectors defined in Section 4.4.1.1, and MUST support (total)
      ordering of these entries, as seen via this interface.  The SPD
      entries' selectors are analogous to the ACL or packet filters
      commonly found in a stateless firewall or packet filtering router
      and which are currently managed this way.

      In host systems, applications MAY be allowed to create SPD
      entries.  (The means of signaling such requests to the IPsec
      implementation are outside the scope of this standard.)  However,
      the system administrator MUST be able to specify whether or not a
      user or application can override (default) system policies.  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.

   Decorrelation

      The processing model described in this document assumes the
      ability to decorrelate overlapping SPD entries to permit caching,
      which enables more efficient processing of outbound traffic in
      security gateways and BITS/BITW implementations.  Decorrelation
      [CoSa04] is only a means of improving performance and simplifying
      the processing description.  This RFC does not require a compliant
      implementation to make use of decorrelation.  For example, native
      host implementations typically make use of caching implicitly
      because they bind SAs to socket interfaces, and thus there is no
      requirement to be able to decorrelate SPD entries in these
      implementations.

      Note:  Unless otherwise qualified, the use of "SPD" refers to the
      body of policy information in both ordered or decorrelated
      (unordered) state.  Appendix B provides an algorithm that can be
      used to decorrelate SPD entries, but any algorithm that produces
      equivalent output may be used.  Note that when an SPD entry is
      decorrelated all the resulting entries MUST be linked together, so
      that all members of the group derived from an individual, SPD
      entry (prior to decorrelation) can all be placed into caches and
      into the SAD at the same time.  For example, suppose one starts
      with an entry A (from an ordered SPD) that when decorrelated,
      yields entries A1, A2, and A3.  When a packet comes along that
      matches, say A2, and triggers the creation of an SA, the SA
      management protocol (e.g., IKEv2) negotiates A.  And all 3
Top   ToC   RFC4301 - Page 25
      decorrelated entries, A1, A2, and A3, are placed in the
      appropriate SPD-S cache and linked to the SA.  The intent is that
      use of a decorrelated SPD ought not to create more SAs than would
      have resulted from use of a not-decorrelated SPD.

      If a decorrelated SPD is employed, there are three options for
      what an initiator sends to a peer via an SA management protocol
      (e.g., IKE).  By sending the complete set of linked, decorrelated
      entries that were selected from the SPD, a peer is given the best
      possible information to enable selection of the appropriate SPD
      entry at its end, especially if the peer has also decorrelated its
      SPD.  However, if a large number of decorrelated entries are
      linked, this may create large packets for SA negotiation, and
      hence fragmentation problems for the SA management protocol.

      Alternatively, the original entry from the (correlated) SPD may be
      retained and passed to the SA management protocol.  Passing the
      correlated SPD entry keeps the use of a decorrelated SPD a local
      matter, not visible to peers, and avoids possible fragmentation
      concerns, although it provides less precise information to a
      responder for matching against the responder's SPD.

      An intermediate approach is to send a subset of the complete set
      of linked, decorrelated SPD entries.  This approach can avoid the
      fragmentation problems cited above yet provide better information
      than the original, correlated entry.  The major shortcoming of
      this approach is that it may cause additional SAs to be created
      later, since only a subset of the linked, decorrelated entries are
      sent to a peer.  Implementers are free to employ any of the
      approaches cited above.

      A responder uses the traffic selector proposals it receives via an
      SA management protocol to select an appropriate entry in its SPD.
      The intent of the matching is to select an SPD entry and create an
      SA that most closely matches the intent of the initiator, so that
      traffic traversing the resulting SA will be accepted at both ends.
      If the responder employs a decorrelated SPD, it SHOULD use the
      decorrelated SPD entries for matching, as this will generally
      result in creation of SAs that are more likely to match the intent
      of both peers.  If the responder has a correlated SPD, then it
      SHOULD match the proposals against the correlated entries.  For
      IKEv2, use of a decorrelated SPD offers the best opportunity for a
      responder to generate a "narrowed" response.

      In all cases, when a decorrelated SPD is available, the
      decorrelated entries are used to populate the SPD-S cache.  If the
      SPD is not decorrelated, caching is not allowed and an ordered
Top   ToC   RFC4301 - Page 26
      search of SPD MUST be performed to verify that inbound traffic
      arriving on an SA is consistent with the access control policy
      expressed in the SPD.

   Handling Changes to the SPD While the System Is Running

      If a change is made to the SPD while the system is running, a
      check SHOULD be made of the effect of this change on extant SAs.
      An implementation SHOULD check the impact of an SPD change on
      extant SAs and SHOULD provide a user/administrator with a
      mechanism for configuring what actions to take, e.g., delete an
      affected SA, allow an affected SA to continue unchanged, etc.

4.4.1.1. Selectors
An SA 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 Layer Protocol and related fields, e.g., ports), 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 by all IPsec implementations to facilitate control of SA granularity. Note that both Local and Remote addresses should either be IPv4 or IPv6, but not a mix of address types. Also, note that the Local/Remote port selectors (and ICMP message type and code, and Mobility Header type) may be labeled as OPAQUE to accommodate situations where these fields are inaccessible due to packet fragmentation. - Remote IP Address(es) (IPv4 or IPv6): This is a list of ranges of IP addresses (unicast, broadcast (IPv4 only)). This structure allows expression of a single IP address (via a trivial range), or a list of addresses (each a trivial range), or a range of addresses (low and high values, inclusive), as well as the most generic form of a list of ranges. Address ranges are used to support more than one remote system sharing the same SA, e.g., behind a security gateway. - Local IP Address(es) (IPv4 or IPv6): This is a list of ranges of IP addresses (unicast, broadcast (IPv4 only)). This structure allows expression of a single IP address (via a trivial range), or a list of addresses (each a trivial range), or a range of addresses (low and high values, inclusive), as well as the most generic form of a list of ranges. Address ranges are used to
Top   ToC   RFC4301 - Page 27
        support more than one source system sharing the same SA, e.g.,
        behind a security gateway.  Local refers to the address(es)
        being protected by this implementation (or policy entry).

        Note: The SPD does not include support for multicast address
        entries.  To support multicast SAs, an implementation should
        make use of a Group SPD (GSPD) as defined in [RFC3740].  GSPD
        entries require a different structure, i.e., one cannot use the
        symmetric relationship associated with local and remote address
        values for unicast SAs in a multicast context.  Specifically,
        outbound traffic directed to a multicast address on an SA would
        not be received on a companion, inbound SA with the multicast
        address as the source.

      - Next Layer Protocol: Obtained from the IPv4 "Protocol" or the
        IPv6 "Next Header" fields.  This is an individual protocol
        number, ANY, or for IPv6 only, OPAQUE.  The Next Layer Protocol
        is whatever comes after any IP extension headers that are
        present.  To simplify locating the Next Layer Protocol, there
        SHOULD be a mechanism for configuring which IPv6 extension
        headers to skip.  The default configuration for which protocols
        to skip SHOULD include the following protocols: 0 (Hop-by-hop
        options), 43 (Routing Header), 44 (Fragmentation Header), and 60
        (Destination Options).  Note: The default list does NOT include
        51 (AH) or 50 (ESP).  From a selector lookup point of view,
        IPsec treats AH and ESP as Next Layer Protocols.

        Several additional selectors depend on the Next Layer Protocol
        value:

         * If the Next Layer Protocol uses two ports (as do TCP, UDP,
           SCTP, and others), then there are selectors for Local and
           Remote Ports.  Each of these selectors has a list of ranges
           of values.  Note that the Local and Remote ports may not be
           available in the case of receipt of a fragmented packet or if
           the port fields have been protected by IPsec (encrypted);
           thus, a value of OPAQUE also MUST be supported.  Note: In a
           non-initial fragment, port values will not be available.  If
           a port selector specifies a value other than ANY or OPAQUE,
           it cannot match packets that are non-initial fragments.  If
           the SA requires a port value other than ANY or OPAQUE, an
           arriving fragment without ports MUST be discarded. (See
           Section 7, "Handling Fragments".)

         * If the Next Layer Protocol is a Mobility Header, then there
           is a selector for IPv6 Mobility Header message type (MH type)
           [Mobip].  This is an 8-bit value that identifies a particular
           mobility message.  Note that the MH type may not be available
Top   ToC   RFC4301 - Page 28
           in the case of receipt of a fragmented packet. (See Section
           7, "Handling Fragments".) For IKE, the IPv6 Mobility Header
           message type (MH type) is placed in the most significant
           eight bits of the 16-bit local "port" selector.

         * If the Next Layer Protocol value is ICMP, then there is a
           16-bit selector for the ICMP message type and code.  The
           message type is a single 8-bit value, which defines the type
           of an ICMP message, or ANY.  The ICMP code is a single 8-bit
           value that defines a specific subtype for an ICMP message.
           For IKE, the message type is placed in the most significant 8
           bits of the 16-bit selector and the code is placed in the
           least significant 8 bits.  This 16-bit selector can contain a
           single type and a range of codes, a single type and ANY code,
           and ANY type and ANY code.  Given a policy entry with a range
           of Types (T-start to T-end) and a range of Codes (C-start to
           C-end), and an ICMP packet with Type t and Code c, an
           implementation MUST test for a match using

               (T-start*256) + C-start <= (t*256) + c <= (T-end*256) +
               C-end

           Note that the ICMP message type and code may not be available
           in the case of receipt of a fragmented packet. (See Section
           7, "Handling Fragments".)

      - Name:  This is not a selector like the others above.  It is not
        acquired from a packet.  A name may be used as a symbolic
        identifier for an IPsec Local or Remote address.  Named SPD
        entries are used in two ways:

         1. A named SPD entry is used by a responder (not an initiator)
            in support of access control when an IP address would not be
            appropriate for the Remote IP address selector, e.g., for
            "road warriors".  The name used to match this field is
            communicated during the IKE negotiation in the ID payload.
            In this context, the initiator's Source IP address (inner IP
            header in tunnel mode) is bound to the Remote IP address in
            the SAD entry created by the IKE negotiation.  This address
            overrides the Remote IP address value in the SPD, when the
            SPD entry is selected in this fashion.  All IPsec
            implementations MUST support this use of names.

         2. A named SPD entry may be used by an initiator to identify a
            user for whom an IPsec SA will be created (or for whom
            traffic may be bypassed).  The initiator's IP source address
            (from inner IP header in tunnel mode) is used to replace the
            following if and when they are created:
Top   ToC   RFC4301 - Page 29
                    - local address in the SPD cache entry
                    - local address in the outbound SAD entry
                    - remote address in the inbound SAD entry

            Support for this use is optional for multi-user, native host
            implementations and not applicable to other implementations.
            Note that this name is used only locally; it is not
            communicated by the key management protocol.  Also, name
            forms other than those used for case 1 above (responder) are
            applicable in the initiator context (see below).

         An SPD entry can contain both a name (or a list of names) and
         also values for the Local or Remote IP address.

         For case 1, responder, the identifiers employed in named SPD
         entries are one of the following four types:

                 a. a fully qualified user name string (email), e.g.,
                    mozart@foo.example.com
                    (this corresponds to ID_RFC822_ADDR in IKEv2)

                 b. a fully qualified DNS name, e.g.,
                    foo.example.com
                    (this corresponds to ID_FQDN in IKEv2)

                 c. X.500 distinguished name, e.g., [WaKiHo97],
                    CN = Stephen T. Kent, O = BBN Technologies,
                    SP = MA, C = US
                    (this corresponds to ID_DER_ASN1_DN in IKEv2, after
                    decoding)

                 d. a byte string
                    (this corresponds to Key_ID in IKEv2)

         For case 2, initiator, the identifiers employed in named SPD
         entries are of type byte string.  They are likely to be Unix
         UIDs, Windows security IDs, or something similar, but could
         also be a user name or account name.  In all cases, this
         identifier is only of local concern and is not transmitted.

   The IPsec implementation context determines how selectors are used.
   For example, a native host implementation typically makes use of a
   socket interface.  When a new connection is established, the SPD can
   be consulted and an SA bound to the socket.  Thus, traffic sent via
   that socket need not result in additional lookups to the SPD (SPD-O
   and SPD-S) cache.  In contrast, a BITS, BITW, or security gateway
   implementation needs to look at each packet and perform an
   SPD-O/SPD-S cache lookup based on the selectors.
Top   ToC   RFC4301 - Page 30
4.4.1.2. Structure of an SPD Entry
This section contains a prose description of an SPD entry. Also, Appendix C provides an example of an ASN.1 definition of an SPD entry. This text describes the SPD in a fashion that is intended to map directly into IKE payloads to ensure that the policy required by SPD entries can be negotiated through IKE. Unfortunately, the semantics of the version of IKEv2 published concurrently with this document [Kau05] do not align precisely with those defined for the SPD. Specifically, IKEv2 does not enable negotiation of a single SA that binds multiple pairs of local and remote addresses and ports to a single SA. Instead, when multiple local and remote addresses and ports are negotiated for an SA, IKEv2 treats these not as pairs, but as (unordered) sets of local and remote values that can be arbitrarily paired. Until IKE provides a facility that conveys the semantics that are expressed in the SPD via selector sets (as described below), users MUST NOT include multiple selector sets in a single SPD entry unless the access control intent aligns with the IKE "mix and match" semantics. An implementation MAY warn users, to alert them to this problem if users create SPD entries with multiple selector sets, the syntax of which indicates possible conflicts with current IKE semantics. The management GUI can offer the user other forms of data entry and display, e.g., the option of using address prefixes as well as ranges, and symbolic names for protocols, ports, etc. (Do not confuse the use of symbolic names in a management interface with the SPD selector "Name".) Note that Remote/Local apply only to IP addresses and ports, not to ICMP message type/code or Mobility Header type. Also, if the reserved, symbolic selector value OPAQUE or ANY is employed for a given selector type, only that value may appear in the list for that selector, and it must appear only once in the list for that selector. Note that ANY and OPAQUE are local syntax conventions -- IKEv2 negotiates these values via the ranges indicated below: ANY: start = 0 end = <max> OPAQUE: start = <max> end = 0 An SPD is an ordered list of entries each of which contains the following fields. o Name -- a list of IDs. This quasi-selector is optional. The forms that MUST be supported are described above in Section 4.4.1.1 under "Name".
Top   ToC   RFC4301 - Page 31
           o PFP flags -- one per traffic selector.  A given flag, e.g.,
             for Next Layer Protocol, applies to the relevant selector
             across all "selector sets" (see below) contained in an SPD
             entry.  When creating an SA, each flag specifies for the
             corresponding traffic selector whether to instantiate the
             selector from the corresponding field in the packet that
             triggered the creation of the SA or from the value(s) in
             the corresponding SPD entry (see Section 4.4.1, "How to
             Derive the Values for an SAD Entry").  Whether a single
             flag is used for, e.g., source port, ICMP type/code, and
             MH type, or a separate flag is used for each, is a local
             matter.  There are PFP flags for:
                - Local Address
                - Remote Address
                - Next Layer Protocol
                - Local Port, or ICMP message type/code or Mobility
                  Header type (depending on the next layer protocol)
                - Remote Port, or ICMP message type/code or Mobility
                  Header type (depending on the next layer protocol)

           o One to N selector sets that correspond to the "condition"
             for applying a particular IPsec action.  Each selector set
             contains:
                - Local Address
                - Remote Address
                - Next Layer Protocol
                - Local Port, or ICMP message type/code or Mobility
                  Header type (depending on the next layer protocol)
                - Remote Port, or ICMP message type/code or Mobility
                  Header type (depending on the next layer protocol)

             Note: The "next protocol" selector is an individual value
             (unlike the local and remote IP addresses) in a selector
             set entry.  This is consistent with how IKEv2 negotiates
             the Traffic Selector (TS) values for an SA.  It also makes
             sense because one may need to associate different port
             fields with different protocols.  It is possible to
             associate multiple protocols (and ports) with a single SA
             by specifying multiple selector sets for that SA.

           o Processing info -- which action is required -- PROTECT,
             BYPASS, or DISCARD.  There is just one action that goes
             with all the selector sets, not a separate action for each
             set.  If the required processing is PROTECT, the entry
             contains the following information.
                - IPsec mode -- tunnel or transport
Top   ToC   RFC4301 - Page 32
                - (if tunnel mode) local tunnel address -- For a
                  non-mobile host, if there is just one interface, this
                  is straightforward; if there are multiple
                  interfaces, this must be statically configured.  For a
                  mobile host, the specification of the local address
                  is handled externally to IPsec.
                - (if tunnel mode) remote tunnel address -- There is no
                  standard way to determine this.  See 4.5.3, "Locating
                  a Security Gateway".
                - Extended Sequence Number -- Is this SA using extended
                  sequence numbers?
                - stateful fragment checking -- Is this SA using
                  stateful fragment checking?  (See Section 7 for more
                  details.)
                - Bypass DF bit (T/F) -- applicable to tunnel mode SAs
                - Bypass DSCP (T/F) or map to unprotected DSCP values
                  (array) if needed to restrict bypass of DSCP values --
                  applicable to tunnel mode SAs
                - IPsec protocol -- AH or ESP
                - algorithms -- which ones to use for AH, which ones to
                  use for ESP, which ones to use for combined mode,
                  ordered by decreasing priority

   It is a local matter as to what information is kept with regard to
   handling extant SAs when the SPD is changed.

4.4.1.3. More Regarding Fields Associated with Next Layer Protocols
Additional selectors are often associated with fields in the Next Layer Protocol header. A particular Next Layer Protocol can have zero, one, or two selectors. There may be situations where there aren't both local and remote selectors for the fields that are dependent on the Next Layer Protocol. The IPv6 Mobility Header has only a Mobility Header message type. AH and ESP have no further selector fields. A system may be willing to send an ICMP message type and code that it does not want to receive. In the descriptions below, "port" is used to mean a field that is dependent on the Next Layer Protocol. A. If a Next Layer Protocol has no "port" selectors, then the Local and Remote "port" selectors are set to OPAQUE in the relevant SPD entry, e.g., Local's next layer protocol = AH "port" selector = OPAQUE
Top   ToC   RFC4301 - Page 33
           Remote's
             next layer protocol = AH
             "port" selector     = OPAQUE

        B. Even if a Next Layer Protocol has only one selector, e.g.,
           Mobility Header type, then the Local and Remote "port"
           selectors are used to indicate whether a system is
           willing to send and/or receive traffic with the specified
          "port" values. For example, if Mobility Headers of a
           specified type are allowed to be sent and received via an
           SA, then the relevant SPD entry would be set as follows:

           Local's
             next layer protocol = Mobility Header
             "port" selector     = Mobility Header message type

           Remote's
             next layer protocol = Mobility Header
             "port" selector     = Mobility Header message type

           If Mobility Headers of a specified type are allowed to be
           sent but NOT received via an SA, then the relevant SPD
           entry would be set as follows:

           Local's
             next layer protocol = Mobility Header
             "port" selector     = Mobility Header message type

           Remote's
             next layer protocol = Mobility Header
             "port" selector     = OPAQUE

           If Mobility Headers of a specified type are allowed to be
           received but NOT sent via an SA, then the relevant SPD
           entry would be set as follows:

           Local's
             next layer protocol = Mobility Header
             "port" selector     = OPAQUE

           Remote's
             next layer protocol = Mobility Header
             "port" selector     = Mobility Header message type

        C. If a system is willing to send traffic with a particular
           "port" value but NOT receive traffic with that kind of
           port value, the system's traffic selectors are set as
           follows in the relevant SPD entry:
Top   ToC   RFC4301 - Page 34
           Local's
             next layer protocol = ICMP
             "port" selector     = <specific ICMP type & code>

           Remote's
             next layer protocol = ICMP
             "port" selector     = OPAQUE

        D. To indicate that a system is willing to receive traffic
           with a particular "port" value but NOT send that kind of
           traffic, the system's traffic selectors are set as follows
           in the relevant SPD entry:

           Local's
             next layer protocol = ICMP
             "port" selector     = OPAQUE

           Remote's
             next layer protocol = ICMP
             "port" selector     = <specific ICMP type & code>

           For example, if a security gateway is willing to allow
           systems behind it to send ICMP traceroutes, but is not
           willing to let outside systems run ICMP traceroutes to
           systems behind it, then the security gateway's traffic
           selectors are set as follows in the relevant SPD entry:

           Local's
             next layer protocol = 1 (ICMPv4)
             "port" selector     = 30 (traceroute)

           Remote's
             next layer protocol = 1 (ICMPv4)
             "port" selector     = OPAQUE

4.4.2. Security Association Database (SAD)

In each IPsec implementation, there is a nominal Security Association Database (SAD), in which each entry defines the parameters associated with one SA. Each SA has an entry in the SAD. For outbound processing, each SAD entry is pointed to by entries in the SPD-S part of the SPD cache. For inbound processing, for unicast SAs, the SPI is used either alone to look up an SA or in conjunction with the IPsec protocol type. If an IPsec implementation supports multicast, the SPI plus destination address, or SPI plus destination and source addresses are used to look up the SA. (See Section 4.1 for details on the algorithm that MUST be used for mapping inbound IPsec datagrams to SAs.) The following parameters are associated with each entry in
Top   ToC   RFC4301 - Page 35
   the SAD.  They should all be present except where otherwise noted,
   e.g., AH Authentication algorithm.  This description does not purport
   to be a MIB, only a specification of the minimal data items required
   to support an SA in an IPsec implementation.

   For each of the selectors defined in Section 4.4.1.1, the entry for
   an inbound SA in the SAD MUST be initially populated with the value
   or values negotiated at the time the SA was created. (See the
   paragraph in Section 4.4.1 under "Handling Changes to the SPD while
   the System is Running" for guidance on the effect of SPD changes on
   extant SAs.) For a receiver, these values are used to check that the
   header fields of an inbound packet (after IPsec processing) match the
   selector values negotiated for the SA.  Thus, the SAD acts as a cache
   for checking the selectors of inbound traffic arriving on SAs.  For
   the receiver, this is part of verifying that a packet arriving on an
   SA is consistent with the policy for the SA. (See Section 6 for rules
   for ICMP messages.)  These fields can have the form of specific
   values, ranges, ANY, or OPAQUE, as described in Section 4.4.1.1,
   "Selectors".  Note also that there are a couple of situations in
   which the SAD can have entries for SAs that do not have corresponding
   entries in the SPD.  Since this document does not mandate that the
   SAD be selectively cleared when the SPD is changed, SAD entries can
   remain when the SPD entries that created them are changed or deleted.
   Also, if a manually keyed SA is created, there could be an SAD entry
   for this SA that does not correspond to any SPD entry.

   Note: The SAD can support multicast SAs, if manually configured.  An
   outbound multicast SA has the same structure as a unicast SA.  The
   source address is that of the sender, and the destination address is
   the multicast group address.  An inbound, multicast SA must be
   configured with the source addresses of each peer authorized to
   transmit to the multicast SA in question.  The SPI value for a
   multicast SA is provided by a multicast group controller, not by the
   receiver, as for a unicast SA.  Because an SAD entry may be required
   to accommodate multiple, individual IP source addresses that were
   part of an SPD entry (for unicast SAs), the required facility for
   inbound, multicast SAs is a feature already present in an IPsec
   implementation.  However, because the SPD has no provisions for
   accommodating multicast entries, this document does not specify an
   automated way to create an SAD entry for a multicast, inbound SA.
   Only manually configured SAD entries can be created to accommodate
   inbound, multicast traffic.

   Implementation Guidance: This document does not specify how an SPD-S
   entry refers to the corresponding SAD entry, as this is an
   implementation-specific detail.  However, some implementations (based
   on experience from RFC 2401) are known to have problems in this
   regard.  In particular, simply storing the (remote tunnel header IP
Top   ToC   RFC4301 - Page 36
   address, remote SPI) pair in the SPD cache is not sufficient, since
   the pair does not always uniquely identify a single SAD entry.  For
   instance, two hosts behind the same NAT could choose the same SPI
   value.  The situation also may arise if a host is assigned an IP
   address (e.g., via DHCP) previously used by some other host, and the
   SAs associated with the old host have not yet been deleted via dead
   peer detection mechanisms.  This may lead to packets being sent over
   the wrong SA or, if key management ensures the pair is unique,
   denying the creation of otherwise valid SAs.  Thus, implementors
   should implement links between the SPD cache and the SAD in a way
   that does not engender such problems.

4.4.2.1. Data Items in the SAD
The following data items MUST be in the SAD: o Security Parameter Index (SPI): a 32-bit value selected by the receiving end of an SA to uniquely identify the SA. In an SAD entry for an outbound SA, the SPI is used to construct the packet's AH or ESP header. In an SAD entry for an inbound SA, the SPI is used to map traffic to the appropriate SA (see text on unicast/multicast in Section 4.1). o Sequence Number Counter: a 64-bit counter used to generate the Sequence Number field in AH or ESP headers. 64-bit sequence numbers are the default, but 32-bit sequence numbers are also supported if negotiated. o Sequence Counter Overflow: a flag indicating whether overflow of the sequence number counter should generate an auditable event and prevent transmission of additional packets on the SA, or whether rollover is permitted. The audit log entry for this event SHOULD include the SPI value, current date/time, Local Address, Remote Address, and the selectors from the relevant SAD entry. o Anti-Replay Window: a 64-bit counter and a bit-map (or equivalent) used to determine whether an inbound AH or ESP packet is a replay. Note: If anti-replay has been disabled by the receiver for an SA, e.g., in the case of a manually keyed SA, then the Anti-Replay Window is ignored for the SA in question. 64-bit sequence numbers are the default, but this counter size accommodates 32-bit sequence numbers as well. o AH Authentication algorithm, key, etc. This is required only if AH is supported.
Top   ToC   RFC4301 - Page 37
    o ESP Encryption algorithm, key, mode, IV, etc.  If a combined mode
      algorithm is used, these fields will not be applicable.

    o ESP integrity algorithm, keys, etc.  If the integrity service is
      not selected, these fields will not be applicable.  If a combined
      mode algorithm is used, these fields will not be applicable.

    o ESP combined mode algorithms, key(s), etc.  This data is used when
      a combined mode (encryption and integrity) algorithm is used with
      ESP.  If a combined mode algorithm is not used, these fields are
      not applicable.

    o Lifetime of this SA: a time interval after which an SA must be
      replaced with a new SA (and new SPI) or terminated, plus an
      indication of which of these actions should occur.  This may be
      expressed as a time or byte count, or a simultaneous use of both
      with the first lifetime to expire taking precedence.  A compliant
      implementation MUST support both types of lifetimes, and MUST
      support a simultaneous use of both.  If time is employed, and if
      IKE employs X.509 certificates for SA establishment, the SA
      lifetime must be constrained by the validity intervals of the
      certificates, and the NextIssueDate of the Certificate Revocation
      Lists (CRLs) used in the IKE exchange for the SA.  Both initiator
      and responder are responsible for constraining the SA lifetime in
      this fashion.  Note: The details of how to handle the refreshing
      of keys when SAs expire is a local matter.  However, one
      reasonable approach is:

     (a) If byte count is used, then the implementation SHOULD count the
         number of bytes to which the IPsec cryptographic algorithm is
         applied.  For ESP, this is the encryption algorithm (including
         Null encryption) and for AH, this is the authentication
         algorithm.  This includes pad bytes, etc.  Note that
         implementations MUST be able to handle having the counters at
         the ends of an SA get out of synch, e.g., because of packet
         loss or because the implementations at each end of the SA
         aren't doing things the same way.

     (b) There SHOULD be two kinds of lifetime -- a soft lifetime that
         warns the implementation to initiate action such as setting up
         a replacement SA, and a hard lifetime when the current SA ends
         and is destroyed.

     (c) If the entire packet does not get delivered during the SA's
         lifetime, the packet SHOULD be discarded.

    o IPsec protocol mode: tunnel or transport.  Indicates which mode of
      AH or ESP is applied to traffic on this SA.
Top   ToC   RFC4301 - Page 38
    o Stateful fragment checking flag.  Indicates whether or not
      stateful fragment checking applies to this SA.

    o Bypass DF bit (T/F) -- applicable to tunnel mode SAs where both
      inner and outer headers are IPv4.

    o DSCP values -- the set of DSCP values allowed for packets carried
      over this SA.  If no values are specified, no DSCP-specific
      filtering is applied.  If one or more values are specified, these
      are used to select one SA among several that match the traffic
      selectors for an outbound packet.  Note that these values are NOT
      checked against inbound traffic arriving on the SA.

    o Bypass DSCP (T/F) or map to unprotected DSCP values (array) if
      needed to restrict bypass of DSCP values -- applicable to tunnel
      mode SAs.  This feature maps DSCP values from an inner header to
      values in an outer header, e.g., to address covert channel
      signaling concerns.

    o Path MTU: any observed path MTU and aging variables.

    o Tunnel header IP source and destination address -- both addresses
      must be either IPv4 or IPv6 addresses.  The version implies the
      type of IP header to be used.  Only used when the IPsec protocol
      mode is tunnel.

4.4.2.2. Relationship between SPD, PFP flag, packet, and SAD
For each selector, the following tables show the relationship between the value in the SPD, the PFP flag, the value in the triggering packet, and the resulting value in the SAD. Note that the administrative interface for IPsec can use various syntactic options to make it easier for the administrator to enter rules. For example, although a list of ranges is what IKEv2 sends, it might be clearer and less error prone for the user to enter a single IP address or IP address prefix.
Top   ToC   RFC4301 - Page 39
                                        Value in
                                        Triggering   Resulting SAD
         Selector  SPD Entry        PFP Packet       Entry
         --------  ---------------- --- ------------ --------------
         loc addr  list of ranges    0  IP addr "S"  list of ranges
                   ANY               0  IP addr "S"  ANY
                   list of ranges    1  IP addr "S"  "S"
                   ANY               1  IP addr "S"  "S"

         rem addr  list of ranges    0  IP addr "D"  list of ranges
                   ANY               0  IP addr "D"  ANY
                   list of ranges    1  IP addr "D"  "D"
                   ANY               1  IP addr "D"  "D"

         protocol  list of prot's*   0  prot. "P"    list of prot's*
                   ANY**             0  prot. "P"    ANY
                   OPAQUE****        0  prot. "P"    OPAQUE

                   list of prot's*   0  not avail.   discard packet
                   ANY**             0  not avail.   ANY
                   OPAQUE****        0  not avail.   OPAQUE

                   list of prot's*   1  prot. "P"    "P"
                   ANY**             1  prot. "P"    "P"
                   OPAQUE****        1  prot. "P"    ***

                   list of prot's*   1  not avail.   discard packet
                   ANY**             1  not avail.   discard packet
                   OPAQUE****        1  not avail.   ***
Top   ToC   RFC4301 - Page 40
      If the protocol is one that has two ports, then there will be
      selectors for both Local and Remote ports.

                                        Value in
                                        Triggering   Resulting SAD
         Selector  SPD Entry        PFP Packet       Entry
         --------  ---------------- --- ------------ --------------
         loc port  list of ranges    0  src port "s" list of ranges
                   ANY               0  src port "s" ANY
                   OPAQUE            0  src port "s" OPAQUE

                   list of ranges    0  not avail.   discard packet
                   ANY               0  not avail.   ANY
                   OPAQUE            0  not avail.   OPAQUE

                   list of ranges    1  src port "s" "s"
                   ANY               1  src port "s" "s"
                   OPAQUE            1  src port "s" ***

                   list of ranges    1  not avail.   discard packet
                   ANY               1  not avail.   discard packet
                   OPAQUE            1  not avail.   ***


         rem port  list of ranges    0  dst port "d" list of ranges
                   ANY               0  dst port "d" ANY
                   OPAQUE            0  dst port "d" OPAQUE

                   list of ranges    0  not avail.   discard packet
                   ANY               0  not avail.   ANY
                   OPAQUE            0  not avail.   OPAQUE

                   list of ranges    1  dst port "d" "d"
                   ANY               1  dst port "d" "d"
                   OPAQUE            1  dst port "d" ***

                   list of ranges    1  not avail.   discard packet
                   ANY               1  not avail.   discard packet
                   OPAQUE            1  not avail.   ***
Top   ToC   RFC4301 - Page 41
      If the protocol is mobility header, then there will be a selector
      for mh type.

                                        Value in
                                        Triggering   Resulting SAD
         Selector  SPD Entry        PFP Packet       Entry
         --------  ---------------- --- ------------ --------------
         mh type   list of ranges    0  mh type "T"  list of ranges
                   ANY               0  mh type "T"  ANY
                   OPAQUE            0  mh type "T"  OPAQUE

                   list of ranges    0  not avail.   discard packet
                   ANY               0  not avail.   ANY
                   OPAQUE            0  not avail.   OPAQUE

                   list of ranges    1  mh type "T"  "T"
                   ANY               1  mh type "T"  "T"
                   OPAQUE            1  mh type "T"  ***

                   list of ranges    1  not avail.   discard packet
                   ANY               1  not avail.   discard packet
                   OPAQUE            1  not avail.   ***
Top   ToC   RFC4301 - Page 42
      If the protocol is ICMP, then there will be a 16-bit selector for
      ICMP type and ICMP code.  Note that the type and code are bound to
      each other, i.e., the codes apply to the particular type.  This
      16-bit selector can contain a single type and a range of codes, a
      single type and ANY code, and ANY type and ANY code.

                                         Value in
                                         Triggering   Resulting SAD
         Selector   SPD Entry        PFP Packet       Entry
         ---------  ---------------- --- ------------ --------------
         ICMP type  a single type &   0  type "t" &   single type &
         and code    range of codes        code "c"    range of codes
                    a single type &   0  type "t" &   single type &
                     ANY code              code "c"    ANY code
                    ANY type & ANY    0  type "t" &   ANY type &
                     code                  code "c"    ANY code
                    OPAQUE            0  type "t" &   OPAQUE
                                           code "c"

                    a single type &   0  not avail.   discard packet
                     range of codes
                    a single type &   0  not avail.   discard packet
                     ANY code
                    ANY type &        0  not avail.   ANY type &
                     ANY code                          ANY code
                    OPAQUE            0  not avail.   OPAQUE

                    a single type &   1  type "t" &   "t" and "c"
                     range of codes        code "c"
                    a single type &   1  type "t" &   "t" and "c"
                     ANY code              code "c"
                    ANY type &        1  type "t" &   "t" and "c"
                     ANY code              code "c"
                    OPAQUE            1  type "t" &   ***
                                           code "c"

                    a single type &   1  not avail.   discard packet
                     range of codes
                    a single type &   1  not avail.   discard packet
                     ANY code
                    ANY type &        1  not avail.   discard packet
                     ANY code
                    OPAQUE            1  not avail.   ***
Top   ToC   RFC4301 - Page 43
      If the name selector is used:

                                         Value in
                                         Triggering   Resulting SAD
         Selector   SPD Entry        PFP Packet       Entry
         ---------  ---------------- --- ------------ --------------
         name       list of user or  N/A     N/A           N/A
                    system names

            * "List of protocols" is the information, not the way
              that the SPD or SAD or IKEv2 have to represent this
              information.
           ** 0 (zero) is used by IKE to indicate ANY for
              protocol.
          *** Use of PFP=1 with an OPAQUE value is an error and
              SHOULD be prohibited by an IPsec implementation.
         **** The protocol field cannot be OPAQUE in IPv4.  This
              table entry applies only to IPv6.

4.4.3. Peer Authorization Database (PAD)

The Peer Authorization Database (PAD) provides the link between the SPD and a security association management protocol such as IKE. It embodies several critical functions: o identifies the peers or groups of peers that are authorized to communicate with this IPsec entity o specifies the protocol and method used to authenticate each peer o provides the authentication data for each peer o constrains the types and values of IDs that can be asserted by a peer with regard to child SA creation, to ensure that the peer does not assert identities for lookup in the SPD that it is not authorized to represent, when child SAs are created o peer gateway location info, e.g., IP address(es) or DNS names, MAY be included for peers that are known to be "behind" a security gateway The PAD provides these functions for an IKE peer when the peer acts as either the initiator or the responder. To perform these functions, the PAD contains an entry for each peer or group of peers with which the IPsec entity will communicate. An entry names an individual peer (a user, end system or security gateway) or specifies a group of peers (using ID matching rules defined below). The entry specifies the authentication protocol (e.g., IKEv1, IKEv2, KINK) method used (e.g., certificates or pre- shared secrets) and the authentication data (e.g., the pre-shared
Top   ToC   RFC4301 - Page 44
   secret or the trust anchor relative to which the peer's certificate
   will be validated).  For certificate-based authentication, the entry
   also may provide information to assist in verifying the revocation
   status of the peer, e.g., a pointer to a CRL repository or the name
   of an Online Certificate Status Protocol (OCSP) server associated
   with the peer or with the trust anchor associated with the peer.

   Each entry also specifies whether the IKE ID payload will be used as
   a symbolic name for SPD lookup, or whether the remote IP address
   provided in traffic selector payloads will be used for SPD lookups
   when child SAs are created.

   Note that the PAD information MAY be used to support creation of more
   than one tunnel mode SA at a time between two peers, e.g., two
   tunnels to protect the same addresses/hosts, but with different
   tunnel endpoints.

4.4.3.1. PAD Entry IDs and Matching Rules
The PAD is an ordered database, where the order is defined by an administrator (or a user in the case of a single-user end system). Usually, the same administrator will be responsible for both the PAD and SPD, since the two databases must be coordinated. The ordering requirement for the PAD arises for the same reason as for the SPD, i.e., because use of "star name" entries allows for overlaps in the set of IKE IDs that could match a specific entry. Six types of IDs are supported for entries in the PAD, consistent with the symbolic name types and IP addresses used to identify SPD entries. The ID for each entry acts as the index for the PAD, i.e., it is the value used to select an entry. All of these ID types can be used to match IKE ID payload types. The six types are: o DNS name (specific or partial) o Distinguished Name (complete or sub-tree constrained) o RFC 822 email address (complete or partially qualified) o IPv4 address (range) o IPv6 address (range) o Key ID (exact match only) The first three name types can accommodate sub-tree matching as well as exact matches. A DNS name may be fully qualified and thus match exactly one name, e.g., foo.example.com. Alternatively, the name may encompass a group of peers by being partially specified, e.g., the string ".example.com" could be used to match any DNS name ending in these two domain name components.
Top   ToC   RFC4301 - Page 45
   Similarly, a Distinguished Name may specify a complete Distinguished
   Name to match exactly one entry, e.g., CN = Stephen, O = BBN
   Technologies, SP = MA, C = US.  Alternatively, an entry may encompass
   a group of peers by specifying a sub-tree, e.g., an entry of the form
   "C = US, SP = MA" might be used to match all DNs that contain these
   two attributes as the top two Relative Distinguished Names (RDNs).

   For an RFC 822 e-mail addresses, the same options exist.  A complete
   address such as foo@example.com matches one entity, but a sub-tree
   name such as "@example.com" could be used to match all the entities
   with names ending in those two domain names to the right of the @.

   The specific syntax used by an implementation to accommodate sub-tree
   matching for distinguished names, domain names or RFC 822 e-mail
   addresses is a local matter.  But, at a minimum, sub-tree matching of
   the sort described above MUST be supported. (Substring matching
   within a DN, DNS name, or RFC 822 address MAY be supported, but is
   not required.)

   For IPv4 and IPv6 addresses, the same address range syntax used for
   SPD entries MUST be supported.  This allows specification of an
   individual address (via a trivial range), an address prefix (by
   choosing a range that adheres to Classless Inter-Domain Routing
   (CIDR)-style prefixes), or an arbitrary address range.

   The Key ID field is defined as an OCTET string in IKE.  For this name
   type, only exact-match syntax MUST be supported (since there is no
   explicit structure for this ID type).  Additional matching functions
   MAY be supported for this ID type.

4.4.3.2. IKE Peer Authentication Data
Once an entry is located based on an ordered search of the PAD based on ID field matching, it is necessary to verify the asserted identity, i.e., to authenticate the asserted ID. For each PAD entry, there is an indication of the type of authentication to be performed. This document requires support for two required authentication data types: - X.509 certificate - pre-shared secret For authentication based on an X.509 certificate, the PAD entry contains a trust anchor via which the end entity (EE) certificate for the peer must be verifiable, either directly or via a certificate path. See RFC 3280 for the definition of a trust anchor. An entry used with certificate-based authentication MAY include additional data to facilitate certificate revocation status, e.g., a list of
Top   ToC   RFC4301 - Page 46
   appropriate OCSP responders or CRL repositories, and associated
   authentication data.  For authentication based on a pre-shared
   secret, the PAD contains the pre-shared secret to be used by IKE.

   This document does not require that the IKE ID asserted by a peer be
   syntactically related to a specific field in an end entity
   certificate that is employed to authenticate the identity of that
   peer.  However, it often will be appropriate to impose such a
   requirement, e.g., when a single entry represents a set of peers each
   of whom may have a distinct SPD entry.  Thus, implementations MUST
   provide a means for an administrator to require a match between an
   asserted IKE ID and the subject name or subject alt name in a
   certificate.  The former is applicable to IKE IDs expressed as
   distinguished names; the latter is appropriate for DNS names, RFC 822
   e-mail addresses, and IP addresses.  Since KEY ID is intended for
   identifying a peer authenticated via a pre-shared secret, there is no
   requirement to match this ID type to a certificate field.

   See IKEv1 [HarCar98] and IKEv2 [Kau05] for details of how IKE
   performs peer authentication using certificates or pre-shared
   secrets.

   This document does not mandate support for any other authentication
   methods, although such methods MAY be employed.

4.4.3.3. Child SA Authorization Data
Once an IKE peer is authenticated, child SAs may be created. Each PAD entry contains data to constrain the set of IDs that can be asserted by an IKE peer, for matching against the SPD. Each PAD entry indicates whether the IKE ID is to be used as a symbolic name for SPD matching, or whether an IP address asserted in a traffic selector payload is to be used. If the entry indicates that the IKE ID is to be used, then the PAD entry ID field defines the authorized set of IDs. If the entry indicates that child SAs traffic selectors are to be used, then an additional data element is required, in the form of IPv4 and/or IPv6 address ranges. (A peer may be authorized for both address types, so there MUST be provision for both a v4 and a v6 address range.)
4.4.3.4. How the PAD Is Used
During the initial IKE exchange, the initiator and responder each assert their identity via the IKE ID payload and send an AUTH payload to verify the asserted identity. One or more CERT payloads may be transmitted to facilitate the verification of each asserted identity.
Top   ToC   RFC4301 - Page 47
   When an IKE entity receives an IKE ID payload, it uses the asserted
   ID to locate an entry in the PAD, using the matching rules described
   above.  The PAD entry specifies the authentication method to be
   employed for the identified peer.  This ensures that the right method
   is used for each peer and that different methods can be used for
   different peers.  The entry also specifies the authentication data
   that will be used to verify the asserted identity.  This data is
   employed in conjunction with the specified method to authenticate the
   peer, before any CHILD SAs are created.

   Child SAs are created based on the exchange of traffic selector
   payloads, either at the end of the initial IKE exchange or in
   subsequent CREATE_CHILD_SA exchanges.  The PAD entry for the (now
   authenticated) IKE peer is used to constrain creation of child SAs;
   specifically, the PAD entry specifies how the SPD is searched using a
   traffic selector proposal from a peer.  There are two choices: either
   the IKE ID asserted by the peer is used to find an SPD entry via its
   symbolic name, or peer IP addresses asserted in traffic selector
   payloads are used for SPD lookups based on the remote IP address
   field portion of an SPD entry.  It is necessary to impose these
   constraints on creation of child SAs to prevent an authenticated peer
   from spoofing IDs associated with other, legitimate peers.

   Note that because the PAD is checked before searching for an SPD
   entry, this safeguard protects an initiator against spoofing attacks.
   For example, assume that IKE A receives an outbound packet destined
   for IP address X, a host served by a security gateway.  RFC 2401
   [RFC2401] and this document do not specify how A determines the
   address of the IKE peer serving X.  However, any peer contacted by A
   as the presumed representative for X must be registered in the PAD in
   order to allow the IKE exchange to be authenticated.  Moreover, when
   the authenticated peer asserts that it represents X in its traffic
   selector exchange, the PAD will be consulted to determine if the peer
   in question is authorized to represent X.  Thus, the PAD provides a
   binding of address ranges (or name sub-spaces) to peers, to counter
   such attacks.

4.5. SA and Key Management

All IPsec implementations MUST support both manual and automated SA and cryptographic key management. The IPsec protocols, AH and ESP, are largely independent of the associated SA management techniques, although the techniques involved do affect some of the security services offered by the protocols. For example, the optional anti-replay service available for AH and ESP requires automated SA management. Moreover, the granularity of key distribution employed with IPsec determines the granularity of authentication provided. In general, data origin authentication in AH and ESP is limited by the
Top   ToC   RFC4301 - Page 48
   extent to which secrets used with the integrity algorithm (or with a
   key management protocol that creates such secrets) are shared among
   multiple possible sources.

   The following text describes the minimum requirements for both types
   of SA management.

4.5.1. Manual Techniques

The simplest form of management is manual management, in which a person manually configures each system with keying material and SA management data relevant to secure communication with other systems. Manual techniques are practical in small, static environments but they do not scale well. For example, a company could create a virtual private network (VPN) using IPsec in security gateways at several sites. If the number of sites is small, and since all the sites come under the purview of a single administrative domain, this might be a feasible context for manual management techniques. In this case, the security gateway might selectively protect traffic to and from other sites within the organization using a manually configured key, while not protecting traffic for other destinations. It also might be appropriate when only selected communications need to be secured. A similar argument might apply to use of IPsec entirely within an organization for a small number of hosts and/or gateways. Manual management techniques often employ statically configured, symmetric keys, though other options also exist.

4.5.2. Automated SA and Key Management

Widespread deployment and use of IPsec requires an Internet-standard, scalable, automated, SA management protocol. Such support is required to facilitate use of the anti-replay features of AH and ESP, and to accommodate on-demand creation of SAs, e.g., for user- and session-oriented keying. (Note that the notion of "rekeying" an SA actually implies creation of a new SA with a new SPI, a process that generally implies use of an automated SA/key management protocol.) The default automated key management protocol selected for use with IPsec is IKEv2 [Kau05]. This document assumes the availability of certain functions from the key management protocol that are not supported by IKEv1. Other automated SA management protocols MAY be employed. When an automated SA/key management protocol is employed, the output from this protocol is used to generate multiple keys for a single SA. This also occurs because distinct keys are used for each of the two
Top   ToC   RFC4301 - Page 49
   SAs created by IKE.  If both integrity and confidentiality are
   employed, then a minimum of four keys are required.  Additionally,
   some cryptographic algorithms may require multiple keys, e.g., 3DES.

   The Key Management System may provide a separate string of bits for
   each key or it may generate one string of bits from which all keys
   are extracted.  If a single string of bits is provided, care needs to
   be taken to ensure that the parts of the system that map the string
   of bits to the required keys do so in the same fashion at both ends
   of the SA.  To ensure that the IPsec implementations at each end of
   the SA use the same bits for the same keys, and irrespective of which
   part of the system divides the string of bits into individual keys,
   the encryption keys MUST be taken from the first (left-most,
   high-order) bits and the integrity keys MUST be taken from the
   remaining bits.  The number of bits for each key is defined in the
   relevant cryptographic algorithm specification RFC.  In the case of
   multiple encryption keys or multiple integrity keys, the
   specification for the cryptographic algorithm must specify the order
   in which they are to be selected from a single string of bits
   provided to the cryptographic algorithm.

4.5.3. Locating a Security Gateway

This section discusses issues relating to how a host learns about the existence of relevant security gateways and, once a host has contacted these security gateways, how it knows that these are the correct security gateways. The details of where the required information is stored is a local matter, but the Peer Authorization Database (PAD) described in Section 4.4 is the most likely candidate. (Note: S* indicates a system that is running IPsec, e.g., SH1 and SG2 below.) Consider a situation in which a remote host (SH1) is using the Internet to gain access to a server or other machine (H2) and there is a security gateway (SG2), e.g., a firewall, through which H1's traffic must pass. An example of this situation would be a mobile host crossing the Internet to his home organization's firewall (SG2). This situation raises several issues: 1. How does SH1 know/learn about the existence of the security gateway SG2? 2. How does it authenticate SG2, and once it has authenticated SG2, how does it confirm that SG2 has been authorized to represent H2? 3. How does SG2 authenticate SH1 and verify that SH1 is authorized to contact H2?
Top   ToC   RFC4301 - Page 50
   4. How does SH1 know/learn about any additional gateways that provide
      alternate paths to H2?

   To address these problems, an IPsec-supporting host or security
   gateway MUST have an administrative interface that allows the
   user/administrator to configure the address of one or more security
   gateways for ranges of destination addresses that require its use.
   This includes the ability to configure information for locating and
   authenticating one or more security gateways and verifying the
   authorization of these gateways to represent the destination host.
   (The authorization function is implied in the PAD.) This document
   does not address the issue of how to automate the
   discovery/verification of security gateways.

4.6. SAs and Multicast

The receiver-orientation of the SA implies that, in the case of unicast traffic, the destination system will select the SPI value. By having the destination select the SPI value, there is no potential for manually configured SAs to conflict with automatically configured (e.g., via a key management protocol) SAs or for SAs from multiple sources to conflict with each other. For multicast traffic, there are multiple destination systems associated with a single SA. So some system or person will need to coordinate among all multicast groups to select an SPI or SPIs on behalf of each multicast group and then communicate the group's IPsec information to all of the legitimate members of that multicast group via mechanisms not defined here. Multiple senders to a multicast group SHOULD use a single Security Association (and hence SPI) for all traffic to that group when a symmetric key encryption or integrity algorithm is employed. In such circumstances, the receiver knows only that the message came from a system possessing the key for that multicast group. In such circumstances, a receiver generally will not be able to authenticate which system sent the multicast traffic. Specifications for other, more general multicast approaches are deferred to the IETF Multicast Security Working Group.


(page 50 continued on part 3)

Next Section