tech-invite   World Map     

3GPP     Specs     Glossaries     Architecture     IMS     UICC       IETF     RFCs     Groups     SIP     ABNFs       Search

RFC 4301

 Errata 
Proposed STD
Pages: 101
Top     in Index     Prev     Next
in Group Index     Prev in Group     Next in Group     Group: IPSEC

Security Architecture for the Internet Protocol

Part 1 of 4, p. 1 to 17
None       Next RFC Part

Obsoletes:    2401
Updates:    3168
Updated by:    6040    7619


Top       ToC       Page 1 
Network Working Group                                            S. Kent
Request for Comments: 4301                                        K. Seo
Obsoletes: 2401                                         BBN Technologies
Category: Standards Track                                  December 2005


            Security Architecture for the Internet Protocol

Status of This Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   This document describes an updated version of the "Security
   Architecture for IP", which is designed to provide security services
   for traffic at the IP layer.  This document obsoletes RFC 2401
   (November 1998).

Dedication

   This document is dedicated to the memory of Charlie Lynn, a long-time
   senior colleague at BBN, who made very significant contributions to
   the IPsec documents.

Top       Page 2 
Table of Contents

   1. Introduction ....................................................4
      1.1. Summary of Contents of Document ............................4
      1.2. Audience ...................................................4
      1.3. Related Documents ..........................................5
   2. Design Objectives ...............................................5
      2.1. Goals/Objectives/Requirements/Problem Description ..........5
      2.2. Caveats and Assumptions ....................................6
   3. System Overview .................................................7
      3.1. What IPsec Does ............................................7
      3.2. How IPsec Works ............................................9
      3.3. Where IPsec Can Be Implemented ............................10
   4. Security Associations ..........................................11
      4.1. Definition and Scope ......................................12
      4.2. SA Functionality ..........................................16
      4.3. Combining SAs .............................................17
      4.4. Major IPsec Databases .....................................18
           4.4.1. The Security Policy Database (SPD) .................19
                  4.4.1.1. Selectors .................................26
                  4.4.1.2. Structure of an SPD Entry .................30
                  4.4.1.3. More Regarding Fields Associated
                           with Next Layer Protocols .................32
           4.4.2. Security Association Database (SAD) ................34
                  4.4.2.1. Data Items in the SAD .....................36
                  4.4.2.2. Relationship between SPD, PFP
                           flag, packet, and SAD .....................38
           4.4.3. Peer Authorization Database (PAD) ..................43
                  4.4.3.1. PAD Entry IDs and Matching Rules ..........44
                  4.4.3.2. IKE Peer Authentication Data ..............45
                  4.4.3.3. Child SA Authorization Data ...............46
                  4.4.3.4. How the PAD Is Used .......................46
      4.5. SA and Key Management .....................................47
           4.5.1. Manual Techniques ..................................48
           4.5.2. Automated SA and Key Management ....................48
           4.5.3. Locating a Security Gateway ........................49
      4.6. SAs and Multicast .........................................50
   5. IP Traffic Processing ..........................................50
      5.1. Outbound IP Traffic Processing
           (protected-to-unprotected) ................................52
           5.1.1. Handling an Outbound Packet That Must Be
                  Discarded ..........................................54
           5.1.2. Header Construction for Tunnel Mode ................55
                  5.1.2.1. IPv4: Header Construction for
                           Tunnel Mode ...............................57
                  5.1.2.2. IPv6: Header Construction for
                           Tunnel Mode ...............................59
      5.2. Processing Inbound IP Traffic (unprotected-to-protected) ..59

Top      ToC       Page 3 
   6. ICMP Processing ................................................63
      6.1. Processing ICMP Error Messages Directed to an
           IPsec Implementation ......................................63
           6.1.1. ICMP Error Messages Received on the
                  Unprotected Side of the Boundary ...................63
           6.1.2. ICMP Error Messages Received on the
                  Protected Side of the Boundary .....................64
      6.2. Processing Protected, Transit ICMP Error Messages .........64
   7. Handling Fragments (on the protected side of the IPsec
      boundary) ......................................................66
      7.1. Tunnel Mode SAs that Carry Initial and Non-Initial
           Fragments .................................................67
      7.2. Separate Tunnel Mode SAs for Non-Initial Fragments ........67
      7.3. Stateful Fragment Checking ................................68
      7.4. BYPASS/DISCARD Traffic ....................................69
   8. Path MTU/DF Processing .........................................69
      8.1. DF Bit ....................................................69
      8.2. Path MTU (PMTU) Discovery .................................70
           8.2.1. Propagation of PMTU ................................70
           8.2.2. PMTU Aging .........................................71
   9. Auditing .......................................................71
   10. Conformance Requirements ......................................71
   11. Security Considerations .......................................72
   12. IANA Considerations ...........................................72
   13. Differences from RFC 2401 .....................................72
   14. Acknowledgements ..............................................75
   Appendix A: Glossary ..............................................76
   Appendix B: Decorrelation .........................................79
      B.1. Decorrelation Algorithm ...................................79
   Appendix C: ASN.1 for an SPD Entry ................................82
   Appendix D: Fragment Handling Rationale ...........................88
      D.1. Transport Mode and Fragments ..............................88
      D.2. Tunnel Mode and Fragments .................................89
      D.3. The Problem of Non-Initial Fragments ......................90
      D.4. BYPASS/DISCARD Traffic ....................................93
      D.5. Just say no to ports? .....................................94
      D.6. Other Suggested Solutions..................................94
      D.7. Consistency................................................95
      D.8. Conclusions................................................95
   Appendix E: Example of Supporting Nested SAs via SPD and
               Forwarding Table Entries...............................96
   References.........................................................98
      Normative References............................................98
      Informative References..........................................99

Top      ToC       Page 4 
1.  Introduction

1.1.  Summary of Contents of Document

   This document specifies the base architecture for IPsec-compliant
   systems.  It describes how to provide a set of security services for
   traffic at the IP layer, in both the IPv4 [Pos81a] and IPv6 [DH98]
   environments.  This document describes the requirements for systems
   that implement IPsec, the fundamental elements of such systems, and
   how the elements fit together and fit into the IP environment.  It
   also describes the security services offered by the IPsec protocols,
   and how these services can be employed in the IP environment.  This
   document does not address all aspects of the IPsec architecture.
   Other documents address additional architectural details in
   specialized environments, e.g., use of IPsec in Network Address
   Translation (NAT) environments and more comprehensive support for IP
   multicast.  The fundamental components of the IPsec security
   architecture are discussed in terms of their underlying, required
   functionality.  Additional RFCs (see Section 1.3 for pointers to
   other documents) define the protocols in (a), (c), and (d).

        a. Security Protocols -- Authentication Header (AH) and
           Encapsulating Security Payload (ESP)
        b. Security Associations -- what they are and how they work,
           how they are managed, associated processing
        c. Key Management -- manual and automated (The Internet Key
           Exchange (IKE))
        d. Cryptographic algorithms for authentication and encryption

   This document is not a Security Architecture for the Internet; it
   addresses security only at the IP layer, provided through the use of
   a combination of cryptographic and protocol security mechanisms.

   The spelling "IPsec" is preferred and used throughout this and all
   related IPsec standards.  All other capitalizations of IPsec (e.g.,
   IPSEC, IPSec, ipsec) are deprecated.  However, any capitalization of
   the sequence of letters "IPsec" should be understood to refer to the
   IPsec protocols.

   The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
   SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
   document, are to be interpreted as described in RFC 2119 [Bra97].

1.2.  Audience

   The target audience for this document is primarily individuals who
   implement this IP security technology or who architect systems that
   will use this technology.  Technically adept users of this technology

Top      ToC       Page 5 
   (end users or system administrators) also are part of the target
   audience.  A glossary is provided in Appendix A to help fill in gaps
   in background/vocabulary.  This document assumes that the reader is
   familiar with the Internet Protocol (IP), related networking
   technology, and general information system security terms and
   concepts.

1.3.  Related Documents

   As mentioned above, other documents provide detailed definitions of
   some of the components of IPsec and of their interrelationship.  They
   include RFCs on the following topics:

        a. security protocols -- RFCs describing the Authentication
           Header (AH) [Ken05b] and Encapsulating Security Payload
           (ESP) [Ken05a] protocols.
        b. cryptographic algorithms for integrity and encryption -- one
           RFC that defines the mandatory, default algorithms for use
           with AH and ESP [Eas05], a similar RFC that defines the
           mandatory algorithms for use with IKEv2 [Sch05] plus a
           separate RFC for each cryptographic algorithm.
        c. automatic key management -- RFCs on "The Internet Key
           Exchange (IKEv2) Protocol" [Kau05] and "Cryptographic
           Algorithms for Use in the Internet Key Exchange Version 2
           (IKEv2)" [Sch05].

2.  Design Objectives

2.1.  Goals/Objectives/Requirements/Problem Description

   IPsec is designed to provide interoperable, high quality,
   cryptographically-based security for IPv4 and IPv6.  The set of
   security services offered includes access control, connectionless
   integrity, data origin authentication, detection and rejection of
   replays (a form of partial sequence integrity), confidentiality (via
   encryption), and limited traffic flow confidentiality.  These
   services are provided at the IP layer, offering protection in a
   standard fashion for all protocols that may be carried over IP
   (including IP itself).

   IPsec includes a specification for minimal firewall functionality,
   since that is an essential aspect of access control at the IP layer.
   Implementations are free to provide more sophisticated firewall
   mechanisms, and to implement the IPsec-mandated functionality using
   those more sophisticated mechanisms. (Note that interoperability may
   suffer if additional firewall constraints on traffic flows are
   imposed by an IPsec implementation but cannot be negotiated based on
   the traffic selector features defined in this document and negotiated

Top      ToC       Page 6 
   via IKEv2.)  The IPsec firewall function makes use of the
   cryptographically-enforced authentication and integrity provided for
   all IPsec traffic to offer better access control than could be
   obtained through use of a firewall (one not privy to IPsec internal
   parameters) plus separate cryptographic protection.

   Most of the security services are provided through use of two traffic
   security protocols, the Authentication Header (AH) and the
   Encapsulating Security Payload (ESP), and through the use of
   cryptographic key management procedures and protocols.  The set of
   IPsec protocols employed in a context, and the ways in which they are
   employed, will be determined by the users/administrators in that
   context.  It is the goal of the IPsec architecture to ensure that
   compliant implementations include the services and management
   interfaces needed to meet the security requirements of a broad user
   population.

   When IPsec is correctly implemented and deployed, it ought not
   adversely affect users, hosts, and other Internet components that do
   not employ IPsec for traffic protection.  IPsec security protocols
   (AH and ESP, and to a lesser extent, IKE) are designed to be
   cryptographic algorithm independent.  This modularity permits
   selection of different sets of cryptographic algorithms as
   appropriate, without affecting the other parts of the implementation.
   For example, different user communities may select different sets of
   cryptographic algorithms (creating cryptographically-enforced
   cliques) if required.

   To facilitate interoperability in the global Internet, a set of
   default cryptographic algorithms for use with AH and ESP is specified
   in [Eas05] and a set of mandatory-to-implement algorithms for IKEv2
   is specified in [Sch05].  [Eas05] and [Sch05] will be periodically
   updated to keep pace with computational and cryptologic advances.  By
   specifying these algorithms in documents that are separate from the
   AH, ESP, and IKEv2 specifications, these algorithms can be updated or
   replaced without affecting the standardization progress of the rest
   of the IPsec document suite.  The use of these cryptographic
   algorithms, in conjunction with IPsec traffic protection and key
   management protocols, is intended to permit system and application
   developers to deploy high quality, Internet-layer, cryptographic
   security technology.

2.2.  Caveats and Assumptions

   The suite of IPsec protocols and associated default cryptographic
   algorithms are designed to provide high quality security for Internet
   traffic.  However, the security offered by use of these protocols
   ultimately depends on the quality of their implementation, which is

Top      ToC       Page 7 
   outside the scope of this set of standards.  Moreover, the security
   of a computer system or network is a function of many factors,
   including personnel, physical, procedural, compromising emanations,
   and computer security practices.  Thus, IPsec is only one part of an
   overall system security architecture.

   Finally, the security afforded by the use of IPsec is critically
   dependent on many aspects of the operating environment in which the
   IPsec implementation executes.  For example, defects in OS security,
   poor quality of random number sources, sloppy system management
   protocols and practices, etc., can all degrade the security provided
   by IPsec.  As above, none of these environmental attributes are
   within the scope of this or other IPsec standards.

3.  System Overview

   This section provides a high level description of how IPsec works,
   the components of the system, and how they fit together to provide
   the security services noted above.  The goal of this description is
   to enable the reader to "picture" the overall process/system, see how
   it fits into the IP environment, and to provide context for later
   sections of this document, which describe each of the components in
   more detail.

   An IPsec implementation operates in a host, as a security gateway
   (SG), or as an independent device, affording protection to IP
   traffic. (A security gateway is an intermediate system implementing
   IPsec, e.g., a firewall or router that has been IPsec-enabled.) More
   detail on these classes of implementations is provided later, in
   Section 3.3. The protection offered by IPsec is based on requirements
   defined by a Security Policy Database (SPD) established and
   maintained by a user or system administrator, or by an application
   operating within constraints established by either of the above.  In
   general, packets are selected for one of three processing actions
   based on IP and next layer header information ("Selectors", Section
   4.4.1.1) matched against entries in the SPD.  Each packet is either
   PROTECTed using IPsec security services, DISCARDed, or allowed to
   BYPASS IPsec protection, based on the applicable SPD policies
   identified by the Selectors.

3.1.  What IPsec Does

   IPsec creates a boundary between unprotected and protected
   interfaces, for a host or a network (see Figure 1 below).  Traffic
   traversing the boundary is subject to the access controls specified
   by the user or administrator responsible for the IPsec configuration.
   These controls indicate whether packets cross the boundary unimpeded,
   are afforded security services via AH or ESP, or are discarded.

Top      ToC       Page 8 
   IPsec security services are offered at the IP layer through selection
   of appropriate security protocols, cryptographic algorithms, and
   cryptographic keys.  IPsec can be used to protect one or more "paths"
   (a) between a pair of hosts, (b) between a pair of security gateways,
   or (c) between a security gateway and a host.  A compliant host
   implementation MUST support (a) and (c) and a compliant security
   gateway must support all three of these forms of connectivity, since
   under certain circumstances a security gateway acts as a host.

                        Unprotected
                         ^       ^
                         |       |
           +-------------|-------|-------+
           | +-------+   |       |       |
           | |Discard|<--|       V       |
           | +-------+   |B  +--------+  |
         ................|y..| AH/ESP |..... IPsec Boundary
           |   +---+     |p  +--------+  |
           |   |IKE|<----|a      ^       |
           |   +---+     |s      |       |
           | +-------+   |s      |       |
           | |Discard|<--|       |       |
           | +-------+   |       |       |
           +-------------|-------|-------+
                         |       |
                         V       V
                         Protected

            Figure 1.  Top Level IPsec Processing Model

   In this diagram, "unprotected" refers to an interface that might also
   be described as "black" or "ciphertext".  Here, "protected" refers to
   an interface that might also be described as "red" or "plaintext".
   The protected interface noted above may be internal, e.g., in a host
   implementation of IPsec, the protected interface may link to a socket
   layer interface presented by the OS.  In this document, the term
   "inbound" refers to traffic entering an IPsec implementation via the
   unprotected interface or emitted by the implementation on the
   unprotected side of the boundary and directed towards the protected
   interface.  The term "outbound" refers to traffic entering the
   implementation via the protected interface, or emitted by the
   implementation on the protected side of the boundary and directed
   toward the unprotected interface.  An IPsec implementation may
   support more than one interface on either or both sides of the
   boundary.

Top      ToC       Page 9 
   Note the facilities for discarding traffic on either side of the
   IPsec boundary, the BYPASS facility that allows traffic to transit
   the boundary without cryptographic protection, and the reference to
   IKE as a protected-side key and security management function.

   IPsec optionally supports negotiation of IP compression [SMPT01],
   motivated in part by the observation that when encryption is employed
   within IPsec, it prevents effective compression by lower protocol
   layers.

3.2.  How IPsec Works

   IPsec uses two protocols to provide traffic security services --
   Authentication Header (AH) and Encapsulating Security Payload (ESP).
   Both protocols are described in detail in their respective RFCs
   [Ken05b, Ken05a].  IPsec implementations MUST support ESP and MAY
   support AH. (Support for AH has been downgraded to MAY because
   experience has shown that there are very few contexts in which ESP
   cannot provide the requisite security services.  Note that ESP can be
   used to provide only integrity, without confidentiality, making it
   comparable to AH in most contexts.)

    o The IP Authentication Header (AH) [Ken05b] offers integrity and
      data origin authentication, with optional (at the discretion of
      the receiver) anti-replay features.

    o The Encapsulating Security Payload (ESP) protocol [Ken05a] offers
      the same set of services, and also offers confidentiality.  Use of
      ESP to provide confidentiality without integrity is NOT
      RECOMMENDED.  When ESP is used with confidentiality enabled, there
      are provisions for limited traffic flow confidentiality, i.e.,
      provisions for concealing packet length, and for facilitating
      efficient generation and discard of dummy packets.  This
      capability is likely to be effective primarily in virtual private
      network (VPN) and overlay network contexts.

    o Both AH and ESP offer access control, enforced through the
      distribution of cryptographic keys and the management of traffic
      flows as dictated by the Security Policy Database (SPD, Section
      4.4.1).

   These protocols may be applied individually or in combination with
   each other to provide IPv4 and IPv6 security services.  However, most
   security requirements can be met through the use of ESP by itself.
   Each protocol supports two modes of use: transport mode and tunnel
   mode.  In transport mode, AH and ESP provide protection primarily for

Top      ToC       Page 10 
   next layer protocols; in tunnel mode, AH and ESP are applied to
   tunneled IP packets.  The differences between the two modes are
   discussed in Section 4.1.

   IPsec allows the user (or system administrator) to control the
   granularity at which a security service is offered.  For example, one
   can create a single encrypted tunnel to carry all the traffic between
   two security gateways, or a separate encrypted tunnel can be created
   for each TCP connection between each pair of hosts communicating
   across these gateways.  IPsec, through the SPD management paradigm,
   incorporates facilities for specifying:

    o which security protocol (AH or ESP) to employ, the mode (transport
      or tunnel), security service options, what cryptographic
      algorithms to use, and in what combinations to use the specified
      protocols and services, and

    o the granularity at which protection should be applied.

   Because most of the security services provided by IPsec require the
   use of cryptographic keys, IPsec relies on a separate set of
   mechanisms for putting these keys in place.  This document requires
   support for both manual and automated distribution of keys.  It
   specifies a specific public-key based approach (IKEv2 [Kau05]) for
   automated key management, but other automated key distribution
   techniques MAY be used.

   Note: This document mandates support for several features for which
   support is available in IKEv2 but not in IKEv1, e.g., negotiation of
   an SA representing ranges of local and remote ports or negotiation of
   multiple SAs with the same selectors.  Therefore, this document
   assumes use of IKEv2 or a key and security association management
   system with comparable features.

3.3.  Where IPsec Can Be Implemented

   There are many ways in which IPsec may be implemented in a host, or
   in conjunction with a router or firewall to create a security
   gateway, or as an independent security device.

   a. IPsec may be integrated into the native IP stack.  This requires
      access to the IP source code and is applicable to both hosts and
      security gateways, although native host implementations benefit
      the most from this strategy, as explained later (Section 4.4.1,
      paragraph 6; Section 4.4.1.1, last paragraph).

Top      ToC       Page 11 
   b. In a "bump-in-the-stack" (BITS) implementation, IPsec is
      implemented "underneath" an existing implementation of an IP
      protocol stack, between the native IP and the local network
      drivers.  Source code access for the IP stack is not required in
      this context, making this implementation approach appropriate for
      use with legacy systems.  This approach, when it is adopted, is
      usually employed in hosts.

   c. The use of a dedicated, inline security protocol processor is a
      common design feature of systems used by the military, and of some
      commercial systems as well.  It is sometimes referred to as a
      "bump-in-the-wire" (BITW) implementation.  Such implementations
      may be designed to serve either a host or a gateway.  Usually, the
      BITW device is itself IP addressable.  When supporting a single
      host, it may be quite analogous to a BITS implementation, but in
      supporting a router or firewall, it must operate like a security
      gateway.

   This document often talks in terms of use of IPsec by a host or a
   security gateway, without regard to whether the implementation is
   native, BITS, or BITW.  When the distinctions among these
   implementation options are significant, the document makes reference
   to specific implementation approaches.

   A host implementation of IPsec may appear in devices that might not
   be viewed as "hosts".  For example, a router might employ IPsec to
   protect routing protocols (e.g., BGP) and management functions (e.g.,
   Telnet), without affecting subscriber traffic traversing the router.
   A security gateway might employ separate IPsec implementations to
   protect its management traffic and subscriber traffic.  The
   architecture described in this document is very flexible.  For
   example, a computer with a full-featured, compliant, native OS IPsec
   implementation should be capable of being configured to protect
   resident (host) applications and to provide security gateway
   protection for traffic traversing the computer.  Such configuration
   would make use of the forwarding tables and the SPD selection
   function described in Sections 5.1 and 5.2.

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 AH and ESP.  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 SAs.  All implementations of AH or ESP MUST support
   the concept of an SA as described below.  The remainder of this

Top      ToC       Page 12 
   section describes various aspects of SA management, defining required
   characteristics for SA policy management and SA management
   techniques.

4.1.  Definition and Scope

   An 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
   are applied to a traffic stream, then two SAs must be created and
   coordinated to effect protection through iterated application of the
   security protocols.  To secure typical, bi-directional communication
   between two IPsec-enabled systems, a pair of SAs (one in each
   direction) is required.  IKE explicitly creates SA pairs in
   recognition of this common usage requirement.

   For an SA used to carry unicast traffic, the Security Parameters
   Index (SPI) by itself suffices to specify an SA.  (For information on
   the SPI, see Appendix A and the AH and ESP specifications [Ken05b,
   Ken05a].)  However, as a local matter, an implementation may choose
   to use the SPI in conjunction with the IPsec protocol type (AH or
   ESP) for SA identification.  If an IPsec implementation supports
   multicast, then it MUST support multicast SAs using the algorithm
   below for mapping inbound IPsec datagrams to SAs.  Implementations
   that support only unicast traffic need not implement this de-
   multiplexing algorithm.

   In many secure multicast architectures, e.g., [RFC3740], a central
   Group Controller/Key Server unilaterally assigns the Group Security
   Association's (GSA's) SPI.  This SPI assignment is not negotiated or
   coordinated with the key management (e.g., IKE) subsystems that
   reside in the individual end systems that constitute the group.
   Consequently, it is possible that a GSA and a unicast SA can
   simultaneously use the same SPI.  A multicast-capable IPsec
   implementation MUST correctly de-multiplex inbound traffic even in
   the context of SPI collisions.

   Each entry in the SA Database (SAD) (Section 4.4.2) must indicate
   whether the SA lookup makes use of the destination IP address, or the
   destination and source IP addresses, in addition to the SPI.  For
   multicast SAs, the protocol field is not employed for SA lookups.
   For each inbound, IPsec-protected packet, an implementation must
   conduct its search of the SAD such that it finds the entry that
   matches the "longest" SA identifier.  In this context, if two or more
   SAD entries match based on the SPI value, then the entry that also
   matches based on destination address, or destination and source
   address (as indicated in the SAD entry) is the "longest" match.  This
   implies a logical ordering of the SAD search as follows:

Top      ToC       Page 13 
      1. Search the SAD for a match on the combination of SPI,
         destination address, and source address.  If an SAD entry
         matches, then process the inbound packet with that
         matching SAD entry.  Otherwise, proceed to step 2.

      2. Search the SAD for a match on both SPI and destination address.
         If the SAD entry matches, then process the inbound packet
         with that matching SAD entry.  Otherwise, proceed to step 3.

      3. Search the SAD for a match on only SPI if the receiver has
         chosen to maintain a single SPI space for AH and ESP, and on
         both SPI and protocol, otherwise.  If an SAD entry matches,
         then process the inbound packet with that matching SAD entry.
         Otherwise, discard the packet and log an auditable event.

   In practice, an implementation may choose any method (or none at all)
   to accelerate this search, although its externally visible behavior
   MUST be functionally equivalent to having searched the SAD in the
   above order.  For example, a software-based implementation could
   index into a hash table by the SPI.  The SAD entries in each hash
   table bucket's linked list could be kept sorted to have those SAD
   entries with the longest SA identifiers first in that linked list.
   Those SAD entries having the shortest SA identifiers could be sorted
   so that they are the last entries in the linked list.  A
   hardware-based implementation may be able to effect the longest match
   search intrinsically, using commonly available Ternary
   Content-Addressable Memory (TCAM) features.

   The indication of whether source and destination address matching is
   required to map inbound IPsec traffic to SAs MUST be set either as a
   side effect of manual SA configuration or via negotiation using an SA
   management protocol, e.g., IKE or Group Domain of Interpretation
   (GDOI) [RFC3547].  Typically, Source-Specific Multicast (SSM) [HC03]
   groups use a 3-tuple SA identifier composed of an SPI, a destination
   multicast address, and source address.  An Any-Source Multicast group
   SA requires only an SPI and a destination multicast address as an
   identifier.

   If different classes of traffic (distinguished by Differentiated
   Services Code Point (DSCP) bits [NiBlBaBL98], [Gro02]) are sent on
   the same SA, and if the receiver is employing the optional
   anti-replay feature available in both AH and ESP, this could result
   in inappropriate discarding of lower priority packets due to the
   windowing mechanism used by this feature.  Therefore, a sender SHOULD
   put traffic of different classes, but with the same selector values,
   on different SAs to support Quality of Service (QoS) appropriately.
   To permit this, the IPsec implementation MUST permit establishment
   and maintenance of multiple SAs between a given sender and receiver,

Top      ToC       Page 14 
   with the same selectors.  Distribution of traffic among these
   parallel SAs to support QoS is locally determined by the sender and
   is not negotiated by IKE.  The receiver MUST process the packets from
   the different SAs without prejudice.  These requirements apply to
   both transport and tunnel mode SAs.  In the case of tunnel mode SAs,
   the DSCP values in question appear in the inner IP header.  In
   transport mode, the DSCP value might change en route, but this should
   not cause problems with respect to IPsec processing since the value
   is not employed for SA selection and MUST NOT be checked as part of
   SA/packet validation.  However, if significant re-ordering of packets
   occurs in an SA, e.g., as a result of changes to DSCP values en
   route, this may trigger packet discarding by a receiver due to
   application of the anti-replay mechanism.

   DISCUSSION: Although the DSCP [NiBlBaBL98, Gro02] and Explicit
   Congestion Notification (ECN) [RaFlBl01] fields are not "selectors",
   as that term in used in this architecture, the sender will need a
   mechanism to direct packets with a given (set of) DSCP values to the
   appropriate SA.  This mechanism might be termed a "classifier".

   As noted above, two types of SAs are defined: transport mode and
   tunnel mode.  IKE creates pairs of SAs, so for simplicity, we choose
   to require that both SAs in a pair be of the same mode, transport or
   tunnel.

   A transport mode SA is an SA typically employed between a pair of
   hosts to provide end-to-end security services.  When security is
   desired between two intermediate systems along a path (vs. end-to-end
   use of IPsec), transport mode MAY be used between security gateways
   or between a security gateway and a host.  In the case where
   transport mode is used between security gateways or between a
   security gateway and a host, transport mode may be used to support
   in-IP tunneling (e.g., IP-in-IP [Per96] or Generic Routing
   Encapsulation (GRE) tunneling [FaLiHaMeTr00] or dynamic routing
   [ToEgWa04]) over transport mode SAs.  To clarify, the use of
   transport mode by an intermediate system (e.g., a security gateway)
   is permitted only when applied to packets whose source address (for
   outbound packets) or destination address (for inbound packets) is an
   address belonging to the intermediate system itself.  The access
   control functions that are an important part of IPsec are
   significantly limited in this context, as they cannot be applied to
   the end-to-end headers of the packets that traverse a transport mode
   SA used in this fashion.  Thus, this way of using transport mode
   should be evaluated carefully before being employed in a specific
   context.

Top      ToC       Page 15 
   In IPv4, a transport mode security protocol header appears
   immediately after the IP header and any options, and before any next
   layer protocols (e.g., TCP or UDP).  In IPv6, the security protocol
   header appears after the base IP header and selected extension
   headers, but may appear before or after destination options; it MUST
   appear before next layer protocols (e.g., TCP, UDP, Stream Control
   Transmission Protocol (SCTP)).  In the case of ESP, a transport mode
   SA provides security services only for these next 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 preceding it, 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 [Ken05b].

   A tunnel mode SA is essentially an SA applied to an IP tunnel, with
   the access controls applied to the headers of the traffic inside the
   tunnel.  Two hosts MAY establish a tunnel mode SA between themselves.
   Aside from the two exceptions below, 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 typically a
   tunnel mode SA, as is an SA between a host and a security gateway.
   The two exceptions are as follows.

    o Where traffic is destined for a security gateway, e.g., Simple
      Network Management Protocol (SNMP) commands, the security gateway
      is acting as a host and transport mode is allowed.  In this case,
      the SA terminates at a host (management) function within a
      security gateway and thus merits different treatment.

    o As noted above, security gateways MAY support a transport mode SA
      to provide security for IP traffic between two intermediate
      systems along a path, e.g., between a host and a security gateway
      or between two security gateways.

   Several concerns motivate the use of tunnel mode for an SA involving
   a security gateway.  For example, if there are multiple paths (e.g.,
   via different security gateways) to the same destination behind a
   security gateway, it is important that an IPsec packet be sent to the
   security gateway with which the SA was negotiated.  Similarly, a
   packet that might be fragmented en route must have all the fragments
   delivered to the same IPsec instance for reassembly prior to
   cryptographic processing.  Also, when a fragment is processed by
   IPsec and transmitted, then fragmented en route, it is critical that
   there be inner and outer headers to retain the fragmentation state
   data for the pre- and post-IPsec packet formats.  Hence there are
   several reasons for employing tunnel mode when either end of an SA is

Top      ToC       Page 16 
   a security gateway. (Use of an IP-in-IP tunnel in conjunction with
   transport mode can also address these fragmentation issues.  However,
   this configuration limits the ability of IPsec to enforce access
   control policies on traffic.)

   Note: AH and ESP cannot be applied using transport mode to IPv4
   packets that are fragments.  Only tunnel mode can be employed in such
   cases.  For IPv6, it would be feasible to carry a plaintext fragment
   on a transport mode SA; however, for simplicity, this restriction
   also applies to IPv6 packets.  See Section 7 for more details on
   handling plaintext fragments on the protected side of the IPsec
   barrier.

   For a tunnel mode SA, there is an "outer" IP header that specifies
   the IPsec processing source and destination, plus an "inner" IP
   header that specifies the (apparently) ultimate source and
   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 next layer
   protocols).  If ESP is employed, the protection is afforded only to
   the tunneled packet, not to the outer header.

   In summary,

   a) A host implementation of IPsec MUST support both transport and
      tunnel mode.  This is true for native, BITS, and BITW
      implementations for hosts.

   b) A security gateway MUST support tunnel mode and MAY support
      transport 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, or to provide security between two
      intermediate systems along a path.

4.2.  SA 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 the
   election of optional services within the protocol.

   For example, both AH and ESP offer integrity and authentication
   services, but the coverage differs for each protocol and differs for
   transport vs. tunnel mode.  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 IP or extension
   headers that may change in a fashion not predictable by the sender.

Top      ToC       Page 17 
   However, the same security may be achieved in some contexts by
   applying ESP to a tunnel carrying a packet.

   The granularity of access control provided is determined by the
   choice of the selectors that define each SA.  Moreover, the
   authentication means employed by IPsec peers, e.g., during creation
   of an IKE (vs. child) SA also affects the granularity of the access
   control afforded.

   If confidentiality 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 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 that are carrying traffic from
   many subscribers.

   Note: A compliant implementation MUST NOT allow instantiation of an
   ESP SA that employs both NULL encryption and no integrity algorithm.
   An attempt to negotiate such an SA is an auditable event by both
   initiator and responder.  The audit log entry for this event SHOULD
   include the current date/time, local IKE IP address, and remote IKE
   IP address.  The initiator SHOULD record the relevant SPD entry.

4.3.  Combining SAs

   This document does not require support for nested security
   associations or for what RFC 2401 [RFC2401] called "SA bundles".
   These features still can be effected by appropriate configuration of
   both the SPD and the local forwarding functions (for inbound and
   outbound traffic), but this capability is outside of the IPsec module
   and thus the scope of this specification.  As a result, management of
   nested/bundled SAs is potentially more complex and less assured than
   under the model implied by RFC 2401 [RFC2401].  An implementation
   that provides support for nested SAs SHOULD provide a management
   interface that enables a user or administrator to express the nesting
   requirement, and then create the appropriate SPD entries and
   forwarding table entries to effect the requisite processing. (See
   Appendix E for an example of how to configure nested SAs.)


Next RFC Part