Tech-invite3GPPspaceIETF RFCsSIP
in Index   Prev   Next

RFC 2401

Security Architecture for the Internet Protocol

Pages: 66
Obsoletes:  1825
Obsoleted by:  4301
Updated by:  3168
Part 2 of 4 – Pages 8 to 29
First   Prev   Next

ToP   noToC   RFC2401 - Page 8   prevText
4. Security Associations

   This section defines Security Association management requirements for
   all IPv6 implementations and for those IPv4 implementations that
   implement AH, ESP, or both.  The concept of a "Security Association"
   (SA) is fundamental to IPsec.  Both AH and ESP make use of SAs and a
   major function of IKE is the establishment and maintenance of
   Security Associations.  All implementations of AH or ESP MUST support
   the concept of a Security Association as described below.  The
   remainder of this section describes various aspects of Security
   Association management, defining required characteristics for SA
   policy management, traffic processing, and SA management techniques.

4.1 Definition and Scope

   A Security Association (SA) is a simplex "connection" that affords
   security services to the traffic carried by it.  Security services
   are afforded to an SA by the use of AH, or ESP, but not both.  If
   both AH and ESP protection is applied to a traffic stream, then two
   (or more) SAs are created to afford protection to the traffic stream.
   To secure typical, bi-directional communication between two hosts, or
   between two security gateways, two Security Associations (one in each
   direction) are required.

   A security association is uniquely identified by a triple consisting
   of a Security Parameter Index (SPI), an IP Destination Address, and a
   security protocol (AH or ESP) identifier.  In principle, the
   Destination Address may be a unicast address, an IP broadcast
   address, or a multicast group address.  However, IPsec SA management
   mechanisms currently are defined only for unicast SAs.  Hence, in the
ToP   noToC   RFC2401 - Page 9
   discussions that follow, SAs will be described in the context of
   point-to-point communication, even though the concept is applicable
   in the point-to-multipoint case as well.

   As noted above, two types of SAs are defined: transport mode and
   tunnel mode.  A transport mode SA is a security association between
   two hosts.  In IPv4, a transport mode security protocol header
   appears immediately after the IP header and any options, and before
   any higher layer protocols (e.g., TCP or UDP).  In IPv6, the security
   protocol header appears after the base IP header and extensions, but
   may appear before or after destination options, and before higher
   layer protocols.  In the case of ESP, a transport mode SA provides
   security services only for these higher layer protocols, not for the
   IP header or any extension headers preceding the ESP header.  In the
   case of AH, the protection is also extended to selected portions of
   the IP header, selected portions of extension headers, and selected
   options (contained in the IPv4 header, IPv6 Hop-by-Hop extension
   header, or IPv6 Destination extension headers).  For more details on
   the coverage afforded by AH, see the AH specification [KA98a].

   A tunnel mode SA is essentially an SA applied to an IP tunnel.
   Whenever either end of a security association is a security gateway,
   the SA MUST be tunnel mode.  Thus an SA between two security gateways
   is always a tunnel mode SA, as is an SA between a host and a security
   gateway.  Note that for the case where traffic is destined for a
   security gateway, e.g., SNMP commands, the security gateway is acting
   as a host and transport mode is allowed.  But in that case, the
   security gateway is not acting as a gateway, i.e., not transiting
   traffic.  Two hosts MAY establish a tunnel mode SA between
   themselves.  The requirement for any (transit traffic) SA involving a
   security gateway to be a tunnel SA arises due to the need to avoid
   potential problems with regard to fragmentation and reassembly of
   IPsec packets, and in circumstances where multiple paths (e.g., via
   different security gateways) exist to the same destination behind the
   security gateways.

   For a tunnel mode SA, there is an "outer" IP header that specifies
   the IPsec processing destination, plus an "inner" IP header that
   specifies the (apparently) ultimate destination for the packet.  The
   security protocol header appears after the outer IP header, and
   before the inner IP header.  If AH is employed in tunnel mode,
   portions of the outer IP header are afforded protection (as above),
   as well as all of the tunneled IP packet (i.e., all of the inner IP
   header is protected, as well as higher layer protocols).  If ESP is
   employed, the protection is afforded only to the tunneled packet, not
   to the outer header.
ToP   noToC   RFC2401 - Page 10
   In summary,
           a) A host MUST support both transport and tunnel mode.
           b) A security gateway is required to support only tunnel
              mode.  If it supports transport mode, that should be used
              only when the security gateway is acting as a host, e.g.,
              for network management.

4.2 Security Association Functionality

   The set of security services offered by an SA depends on the security
   protocol selected, the SA mode, the endpoints of the SA, and on the
   election of optional services within the protocol.  For example, AH
   provides data origin authentication and connectionless integrity for
   IP datagrams (hereafter referred to as just "authentication").  The
   "precision" of the authentication service is a function of the
   granularity of the security association with which AH is employed, as
   discussed in Section 4.4.2, "Selectors".

   AH also offers an anti-replay (partial sequence integrity) service at
   the discretion of the receiver, to help counter denial of service
   attacks.  AH is an appropriate protocol to employ when
   confidentiality is not required (or is not permitted, e.g , due to
   government restrictions on use of encryption).  AH also provides
   authentication for selected portions of the IP header, which may be
   necessary in some contexts.  For example, if the integrity of an IPv4
   option or IPv6 extension header must be protected en route between
   sender and receiver, AH can provide this service (except for the
   non-predictable but mutable parts of the IP header.)

   ESP optionally provides confidentiality for traffic.  (The strength
   of the confidentiality service depends in part, on the encryption
   algorithm employed.)  ESP also may optionally provide authentication
   (as defined above).  If authentication is negotiated for an ESP SA,
   the receiver also may elect to enforce an anti-replay service with
   the same features as the AH anti-replay service.  The scope of the
   authentication offered by ESP is narrower than for AH, i.e., the IP
   header(s) "outside" the ESP header is(are) not protected.  If only
   the upper layer protocols need to be authenticated, then ESP
   authentication is an appropriate choice and is more space efficient
   than use of AH encapsulating ESP.  Note that although both
   confidentiality and authentication are optional, they cannot both be
   omitted. At least one of them MUST be selected.

   If confidentiality service is selected, then an ESP (tunnel mode) SA
   between two security gateways can offer partial traffic flow
   confidentiality.  The use of tunnel mode allows the inner IP headers
   to be encrypted, concealing the identities of the (ultimate) traffic
   source and destination.  Moreover, ESP payload padding also can be
ToP   noToC   RFC2401 - Page 11
   invoked to hide the size of the packets, further concealing the
   external characteristics of the traffic.  Similar traffic flow
   confidentiality services may be offered when a mobile user is
   assigned a dynamic IP address in a dialup context, and establishes a
   (tunnel mode) ESP SA to a corporate firewall (acting as a security
   gateway).  Note that fine granularity SAs generally are more
   vulnerable to traffic analysis than coarse granularity ones which are
   carrying traffic from many subscribers.

4.3 Combining Security Associations

   The IP datagrams transmitted over an individual SA are afforded
   protection by exactly one security protocol, either AH or ESP, but
   not both.  Sometimes a security policy may call for a combination of
   services for a particular traffic flow that is not achievable with a
   single SA.  In such instances it will be necessary to employ multiple
   SAs to implement the required security policy.  The term "security
   association bundle" or "SA bundle" is applied to a sequence of SAs
   through which traffic must be processed to satisfy a security policy.
   The order of the sequence is defined by the policy.  (Note that the
   SAs that comprise a bundle may terminate at different endpoints. For
   example, one SA may extend between a mobile host and a security
   gateway and a second, nested SA may extend to a host behind the

   Security associations may be combined into bundles in two ways:
   transport adjacency and iterated tunneling.

           o Transport adjacency refers to applying more than one
             security protocol to the same IP datagram, without invoking
             tunneling.  This approach to combining AH and ESP allows
             for only one level of combination; further nesting yields
             no added benefit (assuming use of adequately strong
             algorithms in each protocol) since the processing is
             performed at one IPsec instance at the (ultimate)

             Host 1 --- Security ---- Internet -- Security --- Host 2
              | |        Gwy 1                      Gwy 2        | |
              | |                                                | |
              | -----Security Association 1 (ESP transport)------- |
              |                                                    |
              -------Security Association 2 (AH transport)----------

           o Iterated tunneling refers to the application of multiple
             layers of security protocols effected through IP tunneling.
             This approach allows for multiple levels of nesting, since
             each tunnel can originate or terminate at a different IPsec
ToP   noToC   RFC2401 - Page 12
             site along the path.  No special treatment is expected for
             ISAKMP traffic at intermediate security gateways other than
             what can be specified through appropriate SPD entries (See
             Case 3 in Section 4.5)

             There are 3 basic cases of iterated tunneling -- support is
             required only for cases 2 and 3.:

             1. both endpoints for the SAs are the same -- The inner and
                outer tunnels could each be either AH or ESP, though it
                is unlikely that Host 1 would specify both to be the
                same, i.e., AH inside of AH or ESP inside of ESP.

                Host 1 --- Security ---- Internet -- Security --- Host 2
                 | |        Gwy 1                      Gwy 2        | |
                 | |                                                | |
                 | -------Security Association 1 (tunnel)---------- | |
                 |                                                    |
                 ---------Security Association 2 (tunnel)--------------

             2. one endpoint of the SAs is the same -- The inner and
                uter tunnels could each be either AH or ESP.

                Host 1 --- Security ---- Internet -- Security --- Host 2
                 | |        Gwy 1                      Gwy 2         |
                 | |                                     |           |
                 | ----Security Association 1 (tunnel)----           |
                 |                                                   |
                 ---------Security Association 2 (tunnel)-------------

             3. neither endpoint is the same -- The inner and outer
                tunnels could each be either AH or ESP.

                Host 1 --- Security ---- Internet -- Security --- Host 2
                 |          Gwy 1                      Gwy 2         |
                 |            |                          |           |
                 |            --Security Assoc 1 (tunnel)-           |
                 |                                                   |
                 -----------Security Association 2 (tunnel)-----------

   These two approaches also can be combined, e.g., an SA bundle could
   be constructed from one tunnel mode SA and one or two transport mode
   SAs, applied in sequence.  (See Section 4.5 "Basic Combinations of
   Security Associations.") Note that nested tunnels can also occur
   where neither the source nor the destination endpoints of any of the
   tunnels are the same.  In that case, there would be no host or
   security gateway with a bundle corresponding to the nested tunnels.
ToP   noToC   RFC2401 - Page 13
   For transport mode SAs, only one ordering of security protocols seems
   appropriate.  AH is applied to both the upper layer protocols and
   (parts of) the IP header.  Thus if AH is used in a transport mode, in
   conjunction with ESP, AH SHOULD appear as the first header after IP,
   prior to the appearance of ESP.  In that context, AH is applied to
   the ciphertext output of ESP.  In contrast, for tunnel mode SAs, one
   can imagine uses for various orderings of AH and ESP.  The required
   set of SA bundle types that MUST be supported by a compliant IPsec
   implementation is described in Section 4.5.

4.4 Security Association 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 security associations, in support of these
   interoperability and functionality goals.  The model described below
   is nominal; compliant implementations need not match details of this
   model as presented, but the external behavior of such implementations
   must be mappable to the externally observable characteristics of this

   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
ToP   noToC   RFC2401 - Page 14
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
ToP   noToC   RFC2401 - Page 15
   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
   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
           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
ToP   noToC   RFC2401 - Page 16
              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 ( to  And suppose that a packet is to be sent that has a
   source address of  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 (one host)
           b. SPD entry to (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
ToP   noToC   RFC2401 - Page 17
   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
ToP   noToC   RFC2401 - Page 18
   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.,
                    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.,
                    b. X.500 distinguished name
                    c. X.500 general name

        NOTE: One of the possible values of this selector is "OPAQUE".
ToP   noToC   RFC2401 - Page 19
        [REQUIRED for the following cases.  Note that support for name
        forms other than addresses is not required for manually keyed
                o User ID
                    - native host implementations
                    - BITW and BITS implementations acting as HOSTS
                      with only one user
                    - security gateway implementations for INBOUND
                o System names -- all implementations]

      - Data sensitivity level: (IPSO/CIPSO labels)
        [REQUIRED for all systems providing information flow security as
        per Section 8, OPTIONAL for all other systems.]

      - Transport Layer Protocol: Obtained from the IPv4 "Protocol" or
        the IPv6 "Next Header" fields.  This may be an individual
        protocol number.  These packet fields may not contain the
        Transport Protocol due to the presence of IP extension headers,
        e.g., a Routing Header, AH, ESP, Fragmentation Header,
        Destination Options, Hop-by-hop options, etc.  Note that the
        Transport Protocol may not be available in the case of receipt
        of a packet with an ESP header, thus a value of "OPAQUE" SHOULD
        be supported.
        [REQUIRED for all implementations]

        NOTE: To locate the transport protocol, a system has to chain
        through the packet headers checking the "Protocol" or "Next
        Header" field until it encounters either one it recognizes as a
        transport protocol, or until it reaches one that isn't on its
        list of extension headers, or until it encounters an ESP header
        that renders the transport protocol opaque.

      - Source and Destination (e.g., TCP/UDP) Ports: These may be
        individual UDP or TCP port values or a wildcard port.  (The use
        of the Next Protocol field and the Source and/or Destination
        Port fields (in conjunction with the Source and/or Destination
        Address fields), as an SA selector is sometimes referred to as
        "session-oriented keying.").  Note that the source and
        destination ports may not be available in the case of receipt of
        a packet with an ESP header, thus a value of "OPAQUE" SHOULD be

        The following table summarizes the relationship between the
        "Next Header" value in the packet and SPD and the derived Port
        Selector value for the SPD and SAD.
ToP   noToC   RFC2401 - Page 20
          Next Hdr        Transport Layer   Derived Port Selector Field
          in Packet       Protocol in SPD   Value in SPD and SAD
          --------        ---------------   ---------------------------
          ESP             ESP or ANY        ANY (i.e., don't look at it)
          -don't care-    ANY               ANY (i.e., don't look at it)
          specific value  specific value    NOT ANY (i.e., drop packet)
          specific value  specific value    actual port selector field
             not fragment

        If the packet has been fragmented, then the port information may
        not be available in the current fragment.  If so, discard the
        fragment.  An ICMP PMTU should be sent for the first fragment,
        which will have the port information.  [MAY be supported]

   The IPsec implementation context determines how selectors are used.
   For example, a host implementation integrated into the stack may make
   use of a socket interface.  When a new connection is established the
   SPD can be consulted and an SA (or SA bundle) bound to the socket.
   Thus traffic sent via that socket need not result in additional
   lookups to the SPD/SAD.  In contrast, a BITS, BITW, or security
   gateway implementation needs to look at each packet and perform an
   SPD/SAD lookup based on the selectors. The allowable values for the
   selector fields differ between the traffic flow, the security
   association, and the security policy.

   The following table summarizes the kinds of entries that one needs to
   be able to express in the SPD and SAD.  It shows how they relate to
   the fields in data traffic being subjected to IPsec screening.
   (Note: the "wild" or "wildcard" entry for src and dst addresses
   includes a mask, range, etc.)

 Field         Traffic Value       SAD Entry            SPD Entry
 --------      -------------   ----------------   --------------------
 src addr      single IP addr  single,range,wild  single,range,wildcard
 dst addr      single IP addr  single,range,wild  single,range,wildcard
 xpt protocol* xpt protocol    single,wildcard    single,wildcard
 src port*     single src port single,wildcard    single,wildcard
 dst port*     single dst port single,wildcard    single,wildcard
 user id*      single user id  single,wildcard    single,wildcard
 sec. labels   single value    single,wildcard    single,wildcard

       * The SAD and SPD entries for these fields could be "OPAQUE"
         because the traffic value is encrypted.

   NOTE: In principle, one could have selectors and/or selector values
   in the SPD which cannot be negotiated for an SA or SA bundle.
   Examples might include selector values used to select traffic for
ToP   noToC   RFC2401 - Page 21
   discarding or enumerated lists which cause a separate SA to be
   created for each item on the list.  For now, this is left for future
   versions of this document and the list of required selectors and
   selector values is the same for the SPD and the SAD.  However, it is
   acceptable to have an administrative interface that supports use of
   selector values which cannot be negotiated provided that it does not
   mislead the user into believing it is creating an SA with these
   selector values.  For example, the interface may allow the user to
   specify an enumerated list of values but would result in the creation
   of a separate policy and SA for each item on the list.  A vendor
   might support such an interface to make it easier for its customers
   to specify clear and concise policy specifications.

4.4.3 Security Association Database (SAD)

   In each IPsec implementation there is a nominal Security Association
   Database, in which each entry defines the parameters associated with
   one SA.  Each SA has an entry in the SAD.  For outbound processing,
   entries are pointed to by entries in the SPD.  Note that if an SPD
   entry does not currently point to an SA that is appropriate for the
   packet, the implementation creates an appropriate SA (or SA Bundle)
   and links the SPD entry to the SAD entry (see Section 5.1.1).  For
   inbound processing, each entry in the SAD is indexed by a destination
   IP address, IPsec protocol type, and SPI.  The following parameters
   are associated with each entry in the SAD.  This description does not
   purport to be a MIB, but only a specification of the minimal data
   items required to support an SA in an IPsec implementation.

   For inbound processing: The following packet fields are used to look
   up the SA in the SAD:

         o Outer Header's Destination IP address: the IPv4 or IPv6
           Destination address.
           [REQUIRED for all implementations]
         o IPsec Protocol: AH or ESP, used as an index for SA lookup
           in this database.  Specifies the IPsec protocol to be
           applied to the traffic on this SA.
           [REQUIRED for all implementations]
         o SPI: the 32-bit value used to distinguish among different
           SAs terminating at the same destination and using the same
           IPsec protocol.
           [REQUIRED for all implementations]

   For each of the selectors defined in Section 4.4.2, the SA entry in
   the SAD MUST contain the value or values which were negotiated at the
   time the SA was created.  For the sender, these values are used to
   decide whether a given SA is appropriate for use with an outbound
   packet.  This is part of checking to see if there is an existing SA
ToP   noToC   RFC2401 - Page 22
   that can be used.  For the receiver, these values are used to check
   that the selector values in an inbound packet match those for the SA
   (and thus indirectly those for the matching policy).  For the
   receiver, this is part of verifying that the SA was appropriate for
   this packet.  (See Section 6 for rules for ICMP messages.)  These
   fields can have the form of specific values, ranges, wildcards, or
   "OPAQUE" as described in section 4.4.2, "Selectors".  Note that for
   an ESP SA, the encryption algorithm or the authentication algorithm
   could be "NULL".  However they MUST not both be "NULL".

   The following SAD fields are used in doing IPsec processing:

         o Sequence Number Counter: a 32-bit value used to generate the
           Sequence Number field in AH or ESP headers.
           [REQUIRED for all implementations, but used only for outbound
         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
           [REQUIRED for all implementations, but used only for outbound
         o Anti-Replay Window: a 32-bit counter and a bit-map (or
           equivalent) used to determine whether an inbound AH or ESP
           packet is a replay.
           [REQUIRED for all implementations but used only for inbound
           traffic. NOTE: If anti-replay has been disabled by the
           receiver, e.g., in the case of a manually keyed SA, then the
           Anti-Replay Window is not used.]
         o AH Authentication algorithm, keys, etc.
           [REQUIRED for AH implementations]
         o ESP Encryption algorithm, keys, IV mode, IV, etc.
           [REQUIRED for ESP implementations]
         o ESP authentication algorithm, keys, etc. If the
           authentication service is not selected, this field will be
           [REQUIRED for ESP implementations]
         o Lifetime of this Security Association: 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, 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 CRLs used in the IKE exchange
ToP   noToC   RFC2401 - Page 23
           for the SA.  Both initiator and responder are responsible for
           constraining SA lifetime in this fashion.
           [REQUIRED for all implementations]

           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
                 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 SHOULD 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 which warns the implementation to initiate
                 action such as setting up a replacement SA and a
                 hard lifetime when the current SA ends.
             (c) If the entire packet does not get delivered during
                 the SAs lifetime, the packet SHOULD be discarded.

         o IPsec protocol mode: tunnel, transport or wildcard.
           Indicates which mode of AH or ESP is applied to traffic on
           this SA.  Note that if this field is "wildcard" at the
           sending end of the SA, then the application has to specify
           the mode to the IPsec implementation.  This use of wildcard
           allows the same SA to be used for either tunnel or transport
           mode traffic on a per packet basis, e.g., by different
           sockets.  The receiver does not need to know the mode in
           order to properly process the packet's IPsec headers.

           [REQUIRED as follows, unless implicitly defined by context:
                   - host implementations must support all modes
                   - gateway implementations must support tunnel mode]

           NOTE: The use of wildcard for the protocol mode of an inbound
           SA may add complexity to the situation in the receiver (host
           only).  Since the packets on such an SA could be delivered in
           either tunnel or transport mode, the security of an incoming
           packet could depend in part on which mode had been used to
           deliver it.  If, as a result, an application cared about the
           SA mode of a given packet, then the application would need a
           mechanism to obtain this mode information.
ToP   noToC   RFC2401 - Page 24
         o Path MTU: any observed path MTU and aging variables.  See
           [REQUIRED for all implementations but used only for outbound

4.5 Basic Combinations of Security Associations

   This section describes four examples of combinations of security
   associations that MUST be supported by compliant IPsec hosts or
   security gateways.  Additional combinations of AH and/or ESP in
   tunnel and/or transport modes MAY be supported at the discretion of
   the implementor.  Compliant implementations MUST be capable of
   generating these four combinations and on receipt, of processing
   them, but SHOULD be able to receive and process any combination.  The
   diagrams and text below describe the basic cases.  The legend for the
   diagrams is:

        ==== = one or more security associations (AH or ESP, transport
               or tunnel)
        ---- = connectivity (or if so labelled, administrative boundary)
        Hx   = host x
        SGx  = security gateway x
        X*   = X supports IPsec

   NOTE: The security associations below can be either AH or ESP.  The
   mode (tunnel vs transport) is determined by the nature of the
   endpoints.  For host-to-host SAs, the mode can be either transport or

   Case 1.  The case of providing end-to-end security between 2 hosts
        across the Internet (or an Intranet).

                 |                                  |
                H1* ------ (Inter/Intranet) ------ H2*

        Note that either transport or tunnel mode can be selected by the
        hosts.  So the headers in a packet between H1 and H2 could look
        like any of the following:

                  Transport                  Tunnel
             -----------------          ---------------------
             1. [IP1][AH][upper]        4. [IP2][AH][IP1][upper]
             2. [IP1][ESP][upper]       5. [IP2][ESP][IP1][upper]
             3. [IP1][AH][ESP][upper]
ToP   noToC   RFC2401 - Page 25
        Note that there is no requirement to support general nesting,
        but in transport mode, both AH and ESP can be applied to the
        packet.  In this event, the SA establishment procedure MUST
        ensure that first ESP, then AH are applied to the packet.

   Case 2.  This case illustrates simple virtual private networks

                       |                         |
  ---------------------|----                  ---|-----------------------
  |                    |   |                  |  |                      |
  |  H1 -- (Local --- SG1* |--- (Internet) ---| SG2* --- (Local --- H2  |
  |        Intranet)       |                  |          Intranet)      |
  --------------------------                  ---------------------------
      admin. boundary                               admin. boundary

        Only tunnel mode is required here.  So the headers in a packet
        between SG1 and SG2 could look like either of the following:

                4. [IP2][AH][IP1][upper]
                5. [IP2][ESP][IP1][upper]

   Case 3.  This case combines cases 1 and 2, adding end-to-end security
        between the sending and receiving hosts.  It imposes no new
        requirements on the hosts or security gateways, other than a
        requirement for a security gateway to be configurable to pass
        IPsec traffic (including ISAKMP traffic) for hosts behind it.

     |                                                             |
     |                 =========================                   |
     |                 |                       |                   |
  ---|-----------------|----                ---|-------------------|---
  |  |                 |   |                |  |                   |  |
  | H1* -- (Local --- SG1* |-- (Internet) --| SG2* --- (Local --- H2* |
  |        Intranet)       |                |          Intranet)      |
  --------------------------                ---------------------------
       admin. boundary                            admin. boundary

   Case 4.  This covers the situation where a remote host (H1) uses the
        Internet to reach an organization's firewall (SG2) and to then
        gain access to some server or other machine (H2).  The remote
        host could be a mobile host (H1) dialing up to a local PPP/ARA
        server (not shown) on the Internet and then crossing the
        Internet to the home organization's firewall (SG2), etc.  The
ToP   noToC   RFC2401 - Page 26
        details of support for this case, (how H1 locates SG2,
        authenticates it, and verifies its authorization to represent
        H2) are discussed in Section 4.6.3, "Locating a Security

        |                                                    |
        |==============================                      |
        ||                            |                      |
        ||                         ---|----------------------|---
        ||                         |  |                      |  |
        H1* ----- (Internet) ------| SG2* ---- (Local ----- H2* |
              ^                    |           Intranet)        |
              |                    ------------------------------
        could be dialup              admin. boundary (optional)
        to PPP/ARA server

        Only tunnel mode is required between H1 and SG2.  So the choices
        for the SA between H1 and SG2 would be one of the ones in case
        2.  The choices for the SA between H1 and H2 would be one of the
        ones in case 1.

        Note that in this case, the sender MUST apply the transport
        header before the tunnel header.  Therefore the management
        interface to the IPsec implementation MUST support configuration
        of the SPD and SAD to ensure this ordering of IPsec header

   As noted above, support for additional combinations of AH and ESP is
   optional.  Use of other, optional combinations may adversely affect

4.6 SA and Key Management

   IPsec mandates support for 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 services available for AH and ESP require automated SA
   management.  Moreover, the granularity of key distribution employed
   with IPsec determines the granularity of authentication provided.
   (See also a discussion of this issue in Section 4.7.)  In general,
   data origin authentication in AH and ESP is limited by the extent to
   which secrets used with the authentication algorithm (or with a key
   management protocol that creates such secrets) are shared among
   multiple possible sources.
ToP   noToC   RFC2401 - Page 27
   The following text describes the minimum requirements for both types
   of SA management.

4.6.1 Manual Techniques

   The simplest form of management is manual management, in which a
   person manually configures each system with keying material and
   security association 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 is likely to 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

4.6.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 IKE [MSST97, Orm97, HC98] under the IPsec domain of
   interpretation [Pip98].  Other automated SA management protocols MAY
   be employed.

   When an automated SA/key management protocol is employed, the output
   from this protocol may be used to generate multiple keys, e.g., for a
   single ESP SA.  This may arise because:

       o the encryption algorithm uses multiple keys (e.g., triple DES)
       o the authentication algorithm uses multiple keys
       o both encryption and authentication algorithms are employed
ToP   noToC   RFC2401 - Page 28
   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 of them
   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 key(s) MUST be taken from the first (left-most, high-
   order) bits and the authentication key(s) MUST be taken from the
   remaining bits.  The number of bits for each key is defined in the
   relevant algorithm specification RFC.  In the case of multiple
   encryption keys or multiple authentication keys, the specification
   for the algorithm must specify the order in which they are to be
   selected from a single string of bits provided to the algorithm.

4.6.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.

   Consider a situation in which a remote host (H1) 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 (Road Warrior) crossing the Internet to the home organization's
   firewall (SG2).  (See Case 4 in the section 4.5 Basic Combinations of
   Security Associations.) This situation raises several issues:

        1. How does H1 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 H1 and verify that H1 is authorized
           to contact H2?
        4. How does H1 know/learn about backup gateways which provide
           alternate paths to H2?

   To address these problems, a host or security gateway MUST have an
   administrative interface that allows the user/administrator to
   configure the address of a security gateway for any sets of
   destination addresses that require its use. This includes the ability
   to configure:
ToP   noToC   RFC2401 - Page 29
        o the requisite information for locating and authenticating the
          security gateway and verifying its authorization to represent
          the destination host.
        o the requisite information for locating and authenticating any
          backup gateways and verifying their authorization to represent
          the destination host.

   It is assumed that the SPD is also configured with policy information
   that covers any other IPsec requirements for the path to the security
   gateway and the destination host.

   This document does not address the issue of how to automate the
   discovery/verification of security gateways.

4.7 Security Associations and Multicast

   The receiver-orientation of the Security Association implies that, in
   the case of unicast traffic, the destination system will normally
   select the SPI value.  By having the destination select the SPI
   value, there is no potential for manually configured Security
   Associations to conflict with automatically configured (e.g., via a
   key management protocol) Security Associations or for Security
   Associations from multiple sources to conflict with each other.  For
   multicast traffic, there are multiple destination systems per
   multicast group.  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 Security Parameter Index) for all traffic to
   that group when a symmetric key encryption or authentication
   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 cases are deferred
   to later IPsec documents.

   At the time this specification was published, automated protocols for
   multicast key distribution were not considered adequately mature for
   standardization.  For multicast groups having relatively few members,
   manual key distribution or multiple use of existing unicast key
   distribution algorithms such as modified Diffie-Hellman appears
   feasible.  For very large groups, new scalable techniques will be
   needed.  An example of current work in this area is the Group Key
   Management Protocol (GKMP) [HM97].

(next page on part 3)

Next Section