GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc4301

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.

Kent & Seo Standards Track [Page 1] RFC 4301 Security Architecture for IP December 2005

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

Kent & Seo Standards Track [Page 2] RFC 4301 Security Architecture for IP December 2005

 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

Kent & Seo Standards Track [Page 3] RFC 4301 Security Architecture for IP December 2005

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

Kent & Seo Standards Track [Page 4] RFC 4301 Security Architecture for IP December 2005

 (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

Kent & Seo Standards Track [Page 5] RFC 4301 Security Architecture for IP December 2005

 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

Kent & Seo Standards Track [Page 6] RFC 4301 Security Architecture for IP December 2005

 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.

Kent & Seo Standards Track [Page 7] RFC 4301 Security Architecture for IP December 2005

 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.

Kent & Seo Standards Track [Page 8] RFC 4301 Security Architecture for IP December 2005

 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

Kent & Seo Standards Track [Page 9] RFC 4301 Security Architecture for IP December 2005

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

Kent & Seo Standards Track [Page 10] RFC 4301 Security Architecture for IP December 2005

 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

Kent & Seo Standards Track [Page 11] RFC 4301 Security Architecture for IP December 2005

 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:

Kent & Seo Standards Track [Page 12] RFC 4301 Security Architecture for IP December 2005

    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,

Kent & Seo Standards Track [Page 13] RFC 4301 Security Architecture for IP December 2005

 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.

Kent & Seo Standards Track [Page 14] RFC 4301 Security Architecture for IP December 2005

 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

Kent & Seo Standards Track [Page 15] RFC 4301 Security Architecture for IP December 2005

 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.

Kent & Seo Standards Track [Page 16] RFC 4301 Security Architecture for IP December 2005

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

Kent & Seo Standards Track [Page 17] RFC 4301 Security Architecture for IP December 2005

4.4. Major IPsec Databases

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

Kent & Seo Standards Track [Page 18] RFC 4301 Security Architecture for IP December 2005

    employs a sophisticated forwarding function.  IPsec assumes only
    that outbound and inbound traffic that has passed through IPsec
    processing is forwarded in a fashion consistent with the context
    in which IPsec is implemented.  Support for nested SAs is
    optional; if required, it requires coordination between forwarding
    tables and SPD entries to cause a packet to traverse the IPsec
    boundary more than once.
 "Local" vs "Remote"
    In this document, with respect to IP addresses and ports, the
    terms "Local" and "Remote" are used for policy rules.  "Local"
    refers to the entity being protected by an IPsec implementation,
    i.e., the "source" address/port of outbound packets or the
    "destination" address/port of inbound packets. "Remote" refers to
    a peer entity or peer entities.  The terms "source" and
    "destination" are used for packet header fields.
 "Non-initial" vs "Initial" Fragments
    Throughout this document, the phrase "non-initial fragments" is
    used to mean fragments that do not contain all of the selector
    values that may be needed for access control (e.g., they might not
    contain Next Layer Protocol, source and destination ports, ICMP
    message type/code, Mobility Header type).  And the phrase "initial
    fragment" is used to mean a fragment that contains all the
    selector values needed for access control.  However, it should be
    noted that for IPv6, which fragment contains the Next Layer
    Protocol and ports (or ICMP message type/code or Mobility Header
    type [Mobip]) will depend on the kind and number of extension
    headers present.  The "initial fragment" might not be the first
    fragment, in this context.

4.4.1. The Security Policy Database (SPD)

 An SA is a management construct used to enforce security policy for
 traffic crossing the IPsec boundary.  Thus, an essential element of
 SA processing is an underlying Security Policy Database (SPD) that
 specifies what services are to be offered to IP datagrams and in what
 fashion.  The form of the database and its interface are outside the
 scope of this specification.  However, this section specifies minimum
 management functionality that must be provided, to allow a user or
 system administrator to control whether and how IPsec is applied to
 traffic transmitted or received by a host or transiting a security
 gateway.  The SPD, or relevant caches, must be consulted during the
 processing of all traffic (inbound and outbound), including traffic
 not protected by IPsec, that traverses the IPsec boundary.  This
 includes IPsec management traffic such as IKE.  An IPsec

Kent & Seo Standards Track [Page 19] RFC 4301 Security Architecture for IP December 2005

 implementation MUST have at least one SPD, and it MAY support
 multiple SPDs, if appropriate for the context in which the IPsec
 implementation operates.  There is no requirement to maintain SPDs on
 a per-interface basis, as was specified in RFC 2401 [RFC2401].
 However, if an implementation supports multiple SPDs, then it MUST
 include an explicit SPD selection function that is invoked to select
 the appropriate SPD for outbound traffic processing.  The inputs to
 this function are the outbound packet and any local metadata (e.g.,
 the interface via which the packet arrived) required to effect the
 SPD selection function.  The output of the function is an SPD
 identifier (SPD-ID).
 The SPD is an ordered database, consistent with the use of Access
 Control Lists (ACLs) or packet filters in firewalls, routers, etc.
 The ordering requirement arises because entries often will overlap
 due to the presence of (non-trivial) ranges as values for selectors.
 Thus, a user or administrator MUST be able to order the entries to
 express a desired access control policy.  There is no way to impose a
 general, canonical order on SPD entries, because of the allowed use
 of wildcards for selector values and because the different types of
 selectors are not hierarchically related.
 Processing Choices:  DISCARD, BYPASS, PROTECT
    An SPD must discriminate among traffic that is afforded IPsec
    protection and traffic that is allowed to bypass IPsec.  This
    applies to the IPsec protection to be applied by a sender and to
    the IPsec protection that must be present at the receiver.  For
    any outbound or inbound datagram, three processing choices are
    possible: DISCARD, BYPASS IPsec, or PROTECT using IPsec.  The
    first choice refers to traffic that is not allowed to traverse the
    IPsec boundary (in the specified direction).  The second choice
    refers to traffic that is allowed to cross the IPsec boundary
    without IPsec protection.  The third choice refers to traffic that
    is afforded IPsec protection, and for such traffic the SPD must
    specify the security protocols to be employed, their mode,
    security service options, and the cryptographic algorithms to be
    used.
 SPD-S, SPD-I, SPD-O
    An SPD is logically divided into three pieces.  The SPD-S (secure
    traffic) contains entries for all traffic subject to IPsec
    protection.  SPD-O (outbound) contains entries for all outbound
    traffic that is to be bypassed or discarded.  SPD-I (inbound) is
    applied to inbound traffic that will be bypassed or discarded.
    All three of these can be decorrelated (with the exception noted
    above for native host implementations) to facilitate caching.  If

Kent & Seo Standards Track [Page 20] RFC 4301 Security Architecture for IP December 2005

    an IPsec implementation supports only one SPD, then the SPD
    consists of all three parts.  If multiple SPDs are supported, some
    of them may be partial, e.g., some SPDs might contain only SPD-I
    entries, to control inbound bypassed traffic on a per-interface
    basis.  The split allows SPD-I to be consulted without having to
    consult SPD-S, for such traffic.  Since the SPD-I is just a part
    of the SPD, if a packet that is looked up in the SPD-I cannot be
    matched to an entry there, then the packet MUST be discarded.
    Note that for outbound traffic, if a match is not found in SPD-S,
    then SPD-O must be checked to see if the traffic should be
    bypassed.  Similarly, if SPD-O is checked first and no match is
    found, then SPD-S must be checked.  In an ordered,
    non-decorrelated SPD, the entries for the SPD-S, SPD-I, and SPD-O
    are interleaved.  So there is one lookup in the SPD.
 SPD Entries
    Each SPD entry specifies packet disposition as BYPASS, DISCARD, or
    PROTECT.  The entry is keyed by a list of one or more selectors.
    The SPD contains an ordered list of these entries.  The required
    selector types are defined in Section 4.4.1.1. These selectors are
    used to define the granularity of the SAs that are created in
    response to an outbound packet or in response to a proposal from a
    peer.  The detailed structure of an SPD entry is described in
    Section 4.4.1.2. Every SPD SHOULD have a nominal, final entry that
    matches anything that is otherwise unmatched, and discards it.
    The SPD MUST permit a user or administrator to specify policy
    entries as follows:
  1. SPD-I: For inbound traffic that is to be bypassed or discarded,

the entry consists of the values of the selectors that apply to

       the traffic to be bypassed or discarded.
  1. SPD-O: For outbound traffic that is to be bypassed or

discarded, the entry consists of the values of the selectors

       that apply to the traffic to be bypassed or discarded.
  1. SPD-S: For traffic that is to be protected using IPsec, the

entry consists of the values of the selectors that apply to the

       traffic to be protected via AH or ESP, controls on how to
       create SAs based on these selectors, and the parameters needed
       to effect this protection (e.g., algorithms, modes, etc.). Note
       that an SPD-S entry also contains information such as "populate
       from packet" (PFP) flag (see paragraphs below on "How To Derive
       the Values for an SAD entry") and bits indicating whether the

Kent & Seo Standards Track [Page 21] RFC 4301 Security Architecture for IP December 2005

       SA lookup makes use of the local and remote IP addresses in
       addition to the SPI (see AH [Ken05b] or ESP [Ken05a]
       specifications).
 Representing Directionality in an SPD Entry
    For traffic protected by IPsec, the Local and Remote address and
    ports in an SPD entry are swapped to represent directionality,
    consistent with IKE conventions.  In general, the protocols that
    IPsec deals with have the property of requiring symmetric SAs with
    flipped Local/Remote IP addresses.  However, for ICMP, there is
    often no such bi-directional authorization requirement.
    Nonetheless, for the sake of uniformity and simplicity, SPD
    entries for ICMP are specified in the same way as for other
    protocols.  Note also that for ICMP, Mobility Header, and
    non-initial fragments, there are no port fields in these packets.
    ICMP has message type and code and Mobility Header has mobility
    header type.  Thus, SPD entries have provisions for expressing
    access controls appropriate for these protocols, in lieu of the
    normal port field controls.  For bypassed or discarded traffic,
    separate inbound and outbound entries are supported, e.g., to
    permit unidirectional flows if required.
 OPAQUE and ANY
    For each selector in an SPD entry, in addition to the literal
    values that define a match, there are two special values: ANY and
    OPAQUE.  ANY is a wildcard that matches any value in the
    corresponding field of the packet, or that matches packets where
    that field is not present or is obscured.  OPAQUE indicates that
    the corresponding selector field is not available for examination
    because it may not be present in a fragment, it does not exist for
    the given Next Layer Protocol, or prior application of IPsec may
    have encrypted the value.  The ANY value encompasses the OPAQUE
    value.  Thus, OPAQUE need be used only when it is necessary to
    distinguish between the case of any allowed value for a field, vs.
    the absence or unavailability (e.g., due to encryption) of the
    field.
 How to Derive the Values for an SAD Entry
    For each selector in an SPD entry, the entry specifies how to
    derive the corresponding values for a new SA Database (SAD, see
    Section 4.4.2) entry from those in the SPD and the packet.  The
    goal is to allow an SAD entry and an SPD cache entry to be created
    based on specific selector values from the packet, or from the
    matching SPD entry.  For outbound traffic, there are SPD-S cache
    entries and SPD-O cache entries.  For inbound traffic not

Kent & Seo Standards Track [Page 22] RFC 4301 Security Architecture for IP December 2005

    protected by IPsec, there are SPD-I cache entries and there is the
    SAD, which represents the cache for inbound IPsec-protected
    traffic (see Section 4.4.2).  If IPsec processing is specified for
    an entry, a "populate from packet" (PFP) flag may be asserted for
    one or more of the selectors in the SPD entry (Local IP address;
    Remote IP address; Next Layer Protocol; and, depending on Next
    Layer Protocol, Local port and Remote port, or ICMP type/code, or
    Mobility Header type).  If asserted for a given selector X, the
    flag indicates that the SA to be created should take its value for
    X from the value in the packet.  Otherwise, the SA should take its
    value(s) for X from the value(s) in the SPD entry.  Note: In the
    non-PFP case, the selector values negotiated by the SA management
    protocol (e.g., IKEv2) may be a subset of those in the SPD entry,
    depending on the SPD policy of the peer.  Also, whether a single
    flag is used for, e.g., source port, ICMP type/code, and Mobility
    Header (MH) type, or a separate flag is used for each, is a local
    matter.
    The following example illustrates the use of the PFP flag in the
    context of a security gateway or a BITS/BITW implementation.
    Consider an SPD entry where the allowed value for Remote address
    is a range of IPv4 addresses: 192.0.2.1 to 192.0.2.10.  Suppose an
    outbound packet arrives with a destination address of 192.0.2.3,
    and there is no extant SA to carry this packet.  The value used
    for the SA created to transmit this packet could be either of the
    two values shown below, depending on what the SPD entry for this
    selector says is the source of the selector value:
        PFP flag value  example of new
        for the Remote  SAD dest. address
        addr. selector  selector value
        --------------- ------------
        a. PFP TRUE     192.0.2.3 (one host)
        b. PFP FALSE    192.0.2.1 to 192.0.2.10 (range of hosts)
    Note that if the SPD entry above had a value of ANY for the Remote
    address, then the SAD selector value would have to be ANY for case
    (b), but would still be as illustrated for case (a).  Thus, the
    PFP flag can be used to prohibit sharing of an SA, even among
    packets that match the same SPD entry.
 Management Interface
    For every IPsec implementation, there MUST be a management
    interface that allows a user or system administrator to manage the
    SPD.  The interface must allow the user (or administrator) to
    specify the security processing to be applied to every packet that
    traverses the IPsec boundary. (In a native host IPsec

Kent & Seo Standards Track [Page 23] RFC 4301 Security Architecture for IP December 2005

    implementation making use of a socket interface, the SPD may not
    need to be consulted on a per-packet basis, as noted at the end of
    Section 4.4.1.1 and in Section 5.)  The management interface for
    the SPD MUST allow creation of entries consistent with the
    selectors defined in Section 4.4.1.1, and MUST support (total)
    ordering of these entries, as seen via this interface.  The SPD
    entries' selectors are analogous to the ACL or packet filters
    commonly found in a stateless firewall or packet filtering router
    and which are currently managed this way.
    In host systems, applications MAY be allowed to create SPD
    entries.  (The means of signaling such requests to the IPsec
    implementation are outside the scope of this standard.)  However,
    the system administrator MUST be able to specify whether or not a
    user or application can override (default) system policies.  The
    form of the management interface is not specified by this document
    and may differ for hosts vs. security gateways, and within hosts
    the interface may differ for socket-based vs. BITS
    implementations.  However, this document does specify a standard
    set of SPD elements that all IPsec implementations MUST support.
 Decorrelation
    The processing model described in this document assumes the
    ability to decorrelate overlapping SPD entries to permit caching,
    which enables more efficient processing of outbound traffic in
    security gateways and BITS/BITW implementations.  Decorrelation
    [CoSa04] is only a means of improving performance and simplifying
    the processing description.  This RFC does not require a compliant
    implementation to make use of decorrelation.  For example, native
    host implementations typically make use of caching implicitly
    because they bind SAs to socket interfaces, and thus there is no
    requirement to be able to decorrelate SPD entries in these
    implementations.
    Note:  Unless otherwise qualified, the use of "SPD" refers to the
    body of policy information in both ordered or decorrelated
    (unordered) state.  Appendix B provides an algorithm that can be
    used to decorrelate SPD entries, but any algorithm that produces
    equivalent output may be used.  Note that when an SPD entry is
    decorrelated all the resulting entries MUST be linked together, so
    that all members of the group derived from an individual, SPD
    entry (prior to decorrelation) can all be placed into caches and
    into the SAD at the same time.  For example, suppose one starts
    with an entry A (from an ordered SPD) that when decorrelated,
    yields entries A1, A2, and A3.  When a packet comes along that
    matches, say A2, and triggers the creation of an SA, the SA
    management protocol (e.g., IKEv2) negotiates A.  And all 3

Kent & Seo Standards Track [Page 24] RFC 4301 Security Architecture for IP December 2005

    decorrelated entries, A1, A2, and A3, are placed in the
    appropriate SPD-S cache and linked to the SA.  The intent is that
    use of a decorrelated SPD ought not to create more SAs than would
    have resulted from use of a not-decorrelated SPD.
    If a decorrelated SPD is employed, there are three options for
    what an initiator sends to a peer via an SA management protocol
    (e.g., IKE).  By sending the complete set of linked, decorrelated
    entries that were selected from the SPD, a peer is given the best
    possible information to enable selection of the appropriate SPD
    entry at its end, especially if the peer has also decorrelated its
    SPD.  However, if a large number of decorrelated entries are
    linked, this may create large packets for SA negotiation, and
    hence fragmentation problems for the SA management protocol.
    Alternatively, the original entry from the (correlated) SPD may be
    retained and passed to the SA management protocol.  Passing the
    correlated SPD entry keeps the use of a decorrelated SPD a local
    matter, not visible to peers, and avoids possible fragmentation
    concerns, although it provides less precise information to a
    responder for matching against the responder's SPD.
    An intermediate approach is to send a subset of the complete set
    of linked, decorrelated SPD entries.  This approach can avoid the
    fragmentation problems cited above yet provide better information
    than the original, correlated entry.  The major shortcoming of
    this approach is that it may cause additional SAs to be created
    later, since only a subset of the linked, decorrelated entries are
    sent to a peer.  Implementers are free to employ any of the
    approaches cited above.
    A responder uses the traffic selector proposals it receives via an
    SA management protocol to select an appropriate entry in its SPD.
    The intent of the matching is to select an SPD entry and create an
    SA that most closely matches the intent of the initiator, so that
    traffic traversing the resulting SA will be accepted at both ends.
    If the responder employs a decorrelated SPD, it SHOULD use the
    decorrelated SPD entries for matching, as this will generally
    result in creation of SAs that are more likely to match the intent
    of both peers.  If the responder has a correlated SPD, then it
    SHOULD match the proposals against the correlated entries.  For
    IKEv2, use of a decorrelated SPD offers the best opportunity for a
    responder to generate a "narrowed" response.
    In all cases, when a decorrelated SPD is available, the
    decorrelated entries are used to populate the SPD-S cache.  If the
    SPD is not decorrelated, caching is not allowed and an ordered

Kent & Seo Standards Track [Page 25] RFC 4301 Security Architecture for IP December 2005

    search of SPD MUST be performed to verify that inbound traffic
    arriving on an SA is consistent with the access control policy
    expressed in the SPD.
 Handling Changes to the SPD While the System Is Running
    If a change is made to the SPD while the system is running, a
    check SHOULD be made of the effect of this change on extant SAs.
    An implementation SHOULD check the impact of an SPD change on
    extant SAs and SHOULD provide a user/administrator with a
    mechanism for configuring what actions to take, e.g., delete an
    affected SA, allow an affected SA to continue unchanged, etc.

4.4.1.1. Selectors

 An SA may be fine-grained or coarse-grained, depending on the
 selectors used to define the set of traffic for the SA.  For example,
 all traffic between two hosts may be carried via a single SA, and
 afforded a uniform set of security services.  Alternatively, traffic
 between a pair of hosts might be spread over multiple SAs, depending
 on the applications being used (as defined by the Next Layer Protocol
 and related fields, e.g., ports), with different security services
 offered by different SAs.  Similarly, all traffic between a pair of
 security gateways could be carried on a single SA, or one SA could be
 assigned for each communicating host pair.  The following selector
 parameters MUST be supported by all IPsec implementations to
 facilitate control of SA granularity.  Note that both Local and
 Remote addresses should either be IPv4 or IPv6, but not a mix of
 address types.  Also, note that the Local/Remote port selectors (and
 ICMP message type and code, and Mobility Header type) may be labeled
 as OPAQUE to accommodate situations where these fields are
 inaccessible due to packet fragmentation.
  1. Remote IP Address(es) (IPv4 or IPv6): This is a list of ranges

of IP addresses (unicast, broadcast (IPv4 only)). This

      structure allows expression of a single IP address (via a
      trivial range), or a list of addresses (each a trivial range),
      or a range of addresses (low and high values, inclusive), as
      well as the most generic form of a list of ranges.  Address
      ranges are used to support more than one remote system sharing
      the same SA, e.g., behind a security gateway.
  1. Local IP Address(es) (IPv4 or IPv6): This is a list of ranges of

IP addresses (unicast, broadcast (IPv4 only)). This structure

      allows expression of a single IP address (via a trivial range),
      or a list of addresses (each a trivial range), or a range of
      addresses (low and high values, inclusive), as well as the most
      generic form of a list of ranges.  Address ranges are used to

Kent & Seo Standards Track [Page 26] RFC 4301 Security Architecture for IP December 2005

      support more than one source system sharing the same SA, e.g.,
      behind a security gateway.  Local refers to the address(es)
      being protected by this implementation (or policy entry).
      Note: The SPD does not include support for multicast address
      entries.  To support multicast SAs, an implementation should
      make use of a Group SPD (GSPD) as defined in [RFC3740].  GSPD
      entries require a different structure, i.e., one cannot use the
      symmetric relationship associated with local and remote address
      values for unicast SAs in a multicast context.  Specifically,
      outbound traffic directed to a multicast address on an SA would
      not be received on a companion, inbound SA with the multicast
      address as the source.
  1. Next Layer Protocol: Obtained from the IPv4 "Protocol" or the

IPv6 "Next Header" fields. This is an individual protocol

      number, ANY, or for IPv6 only, OPAQUE.  The Next Layer Protocol
      is whatever comes after any IP extension headers that are
      present.  To simplify locating the Next Layer Protocol, there
      SHOULD be a mechanism for configuring which IPv6 extension
      headers to skip.  The default configuration for which protocols
      to skip SHOULD include the following protocols: 0 (Hop-by-hop
      options), 43 (Routing Header), 44 (Fragmentation Header), and 60
      (Destination Options).  Note: The default list does NOT include
      51 (AH) or 50 (ESP).  From a selector lookup point of view,
      IPsec treats AH and ESP as Next Layer Protocols.
      Several additional selectors depend on the Next Layer Protocol
      value:
  • If the Next Layer Protocol uses two ports (as do TCP, UDP,

SCTP, and others), then there are selectors for Local and

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

is a selector for IPv6 Mobility Header message type (MH type)

         [Mobip].  This is an 8-bit value that identifies a particular
         mobility message.  Note that the MH type may not be available

Kent & Seo Standards Track [Page 27] RFC 4301 Security Architecture for IP December 2005

         in the case of receipt of a fragmented packet. (See Section
         7, "Handling Fragments".) For IKE, the IPv6 Mobility Header
         message type (MH type) is placed in the most significant
         eight bits of the 16-bit local "port" selector.
  • If the Next Layer Protocol value is ICMP, then there is a

16-bit selector for the ICMP message type and code. The

         message type is a single 8-bit value, which defines the type
         of an ICMP message, or ANY.  The ICMP code is a single 8-bit
         value that defines a specific subtype for an ICMP message.
         For IKE, the message type is placed in the most significant 8
         bits of the 16-bit selector and the code is placed in the
         least significant 8 bits.  This 16-bit selector can contain a
         single type and a range of codes, a single type and ANY code,
         and ANY type and ANY code.  Given a policy entry with a range
         of Types (T-start to T-end) and a range of Codes (C-start to
         C-end), and an ICMP packet with Type t and Code c, an
         implementation MUST test for a match using
             (T-start*256) + C-start <= (t*256) + c <= (T-end*256) +
             C-end
         Note that the ICMP message type and code may not be available
         in the case of receipt of a fragmented packet. (See Section
         7, "Handling Fragments".)
  1. Name: This is not a selector like the others above. It is not

acquired from a packet. A name may be used as a symbolic

      identifier for an IPsec Local or Remote address.  Named SPD
      entries are used in two ways:
       1. A named SPD entry is used by a responder (not an initiator)
          in support of access control when an IP address would not be
          appropriate for the Remote IP address selector, e.g., for
          "road warriors".  The name used to match this field is
          communicated during the IKE negotiation in the ID payload.
          In this context, the initiator's Source IP address (inner IP
          header in tunnel mode) is bound to the Remote IP address in
          the SAD entry created by the IKE negotiation.  This address
          overrides the Remote IP address value in the SPD, when the
          SPD entry is selected in this fashion.  All IPsec
          implementations MUST support this use of names.
       2. A named SPD entry may be used by an initiator to identify a
          user for whom an IPsec SA will be created (or for whom
          traffic may be bypassed).  The initiator's IP source address
          (from inner IP header in tunnel mode) is used to replace the
          following if and when they are created:

Kent & Seo Standards Track [Page 28] RFC 4301 Security Architecture for IP December 2005

  1. local address in the SPD cache entry
  2. local address in the outbound SAD entry
  3. remote address in the inbound SAD entry
          Support for this use is optional for multi-user, native host
          implementations and not applicable to other implementations.
          Note that this name is used only locally; it is not
          communicated by the key management protocol.  Also, name
          forms other than those used for case 1 above (responder) are
          applicable in the initiator context (see below).
       An SPD entry can contain both a name (or a list of names) and
       also values for the Local or Remote IP address.
       For case 1, responder, the identifiers employed in named SPD
       entries are one of the following four types:
               a. a fully qualified user name string (email), e.g.,
                  mozart@foo.example.com
                  (this corresponds to ID_RFC822_ADDR in IKEv2)
               b. a fully qualified DNS name, e.g.,
                  foo.example.com
                  (this corresponds to ID_FQDN in IKEv2)
               c. X.500 distinguished name, e.g., [WaKiHo97],
                  CN = Stephen T. Kent, O = BBN Technologies,
                  SP = MA, C = US
                  (this corresponds to ID_DER_ASN1_DN in IKEv2, after
                  decoding)
               d. a byte string
                  (this corresponds to Key_ID in IKEv2)
       For case 2, initiator, the identifiers employed in named SPD
       entries are of type byte string.  They are likely to be Unix
       UIDs, Windows security IDs, or something similar, but could
       also be a user name or account name.  In all cases, this
       identifier is only of local concern and is not transmitted.
 The IPsec implementation context determines how selectors are used.
 For example, a native host implementation typically makes use of a
 socket interface.  When a new connection is established, the SPD can
 be consulted and an SA bound to the socket.  Thus, traffic sent via
 that socket need not result in additional lookups to the SPD (SPD-O
 and SPD-S) cache.  In contrast, a BITS, BITW, or security gateway
 implementation needs to look at each packet and perform an
 SPD-O/SPD-S cache lookup based on the selectors.

Kent & Seo Standards Track [Page 29] RFC 4301 Security Architecture for IP December 2005

4.4.1.2. Structure of an SPD Entry

 This section contains a prose description of an SPD entry.  Also,
 Appendix C provides an example of an ASN.1 definition of an SPD
 entry.
 This text describes the SPD in a fashion that is intended to map
 directly into IKE payloads to ensure that the policy required by SPD
 entries can be negotiated through IKE.  Unfortunately, the semantics
 of the version of IKEv2 published concurrently with this document
 [Kau05] do not align precisely with those defined for the SPD.
 Specifically, IKEv2 does not enable negotiation of a single SA that
 binds multiple pairs of local and remote addresses and ports to a
 single SA.  Instead, when multiple local and remote addresses and
 ports are negotiated for an SA, IKEv2 treats these not as pairs, but
 as (unordered) sets of local and remote values that can be
 arbitrarily paired.  Until IKE provides a facility that conveys the
 semantics that are expressed in the SPD via selector sets (as
 described below), users MUST NOT include multiple selector sets in a
 single SPD entry unless the access control intent aligns with the IKE
 "mix and match" semantics.  An implementation MAY warn users, to
 alert them to this problem if users create SPD entries with multiple
 selector sets, the syntax of which indicates possible conflicts with
 current IKE semantics.
 The management GUI can offer the user other forms of data entry and
 display, e.g., the option of using address prefixes as well as
 ranges, and symbolic names for protocols, ports, etc. (Do not confuse
 the use of symbolic names in a management interface with the SPD
 selector "Name".) Note that Remote/Local apply only to IP addresses
 and ports, not to ICMP message type/code or Mobility Header type.
 Also, if the reserved, symbolic selector value OPAQUE or ANY is
 employed for a given selector type, only that value may appear in the
 list for that selector, and it must appear only once in the list for
 that selector.  Note that ANY and OPAQUE are local syntax conventions
 -- IKEv2 negotiates these values via the ranges indicated below:
        ANY:     start = 0        end = <max>
        OPAQUE:  start = <max>    end = 0
 An SPD is an ordered list of entries each of which contains the
 following fields.
         o Name -- a list of IDs.  This quasi-selector is optional.
           The forms that MUST be supported are described above in
           Section 4.4.1.1 under "Name".

Kent & Seo Standards Track [Page 30] RFC 4301 Security Architecture for IP December 2005

         o PFP flags -- one per traffic selector.  A given flag, e.g.,
           for Next Layer Protocol, applies to the relevant selector
           across all "selector sets" (see below) contained in an SPD
           entry.  When creating an SA, each flag specifies for the
           corresponding traffic selector whether to instantiate the
           selector from the corresponding field in the packet that
           triggered the creation of the SA or from the value(s) in
           the corresponding SPD entry (see Section 4.4.1, "How to
           Derive the Values for an SAD Entry").  Whether a single
           flag is used for, e.g., source port, ICMP type/code, and
           MH type, or a separate flag is used for each, is a local
           matter.  There are PFP flags for:
              - Local Address
              - Remote Address
              - Next Layer Protocol
              - Local Port, or ICMP message type/code or Mobility
                Header type (depending on the next layer protocol)
              - Remote Port, or ICMP message type/code or Mobility
                Header type (depending on the next layer protocol)
         o One to N selector sets that correspond to the "condition"
           for applying a particular IPsec action.  Each selector set
           contains:
              - Local Address
              - Remote Address
              - Next Layer Protocol
              - Local Port, or ICMP message type/code or Mobility
                Header type (depending on the next layer protocol)
              - Remote Port, or ICMP message type/code or Mobility
                Header type (depending on the next layer protocol)
           Note: The "next protocol" selector is an individual value
           (unlike the local and remote IP addresses) in a selector
           set entry.  This is consistent with how IKEv2 negotiates
           the Traffic Selector (TS) values for an SA.  It also makes
           sense because one may need to associate different port
           fields with different protocols.  It is possible to
           associate multiple protocols (and ports) with a single SA
           by specifying multiple selector sets for that SA.
         o Processing info -- which action is required -- PROTECT,
           BYPASS, or DISCARD.  There is just one action that goes
           with all the selector sets, not a separate action for each
           set.  If the required processing is PROTECT, the entry
           contains the following information.
              - IPsec mode -- tunnel or transport

Kent & Seo Standards Track [Page 31] RFC 4301 Security Architecture for IP December 2005

  1. (if tunnel mode) local tunnel address – For a

non-mobile host, if there is just one interface, this

                is straightforward; if there are multiple
                interfaces, this must be statically configured.  For a
                mobile host, the specification of the local address
                is handled externally to IPsec.
              - (if tunnel mode) remote tunnel address -- There is no
                standard way to determine this.  See 4.5.3, "Locating
                a Security Gateway".
              - Extended Sequence Number -- Is this SA using extended
                sequence numbers?
              - stateful fragment checking -- Is this SA using
                stateful fragment checking?  (See Section 7 for more
                details.)
              - Bypass DF bit (T/F) -- applicable to tunnel mode SAs
              - Bypass DSCP (T/F) or map to unprotected DSCP values
                (array) if needed to restrict bypass of DSCP values --
                applicable to tunnel mode SAs
              - IPsec protocol -- AH or ESP
              - algorithms -- which ones to use for AH, which ones to
                use for ESP, which ones to use for combined mode,
                ordered by decreasing priority
 It is a local matter as to what information is kept with regard to
 handling extant SAs when the SPD is changed.

4.4.1.3. More Regarding Fields Associated with Next Layer Protocols

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

Kent & Seo Standards Track [Page 32] RFC 4301 Security Architecture for IP December 2005

         Remote's
           next layer protocol = AH
           "port" selector     = OPAQUE
      B. Even if a Next Layer Protocol has only one selector, e.g.,
         Mobility Header type, then the Local and Remote "port"
         selectors are used to indicate whether a system is
         willing to send and/or receive traffic with the specified
        "port" values. For example, if Mobility Headers of a
         specified type are allowed to be sent and received via an
         SA, then the relevant SPD entry would be set as follows:
         Local's
           next layer protocol = Mobility Header
           "port" selector     = Mobility Header message type
         Remote's
           next layer protocol = Mobility Header
           "port" selector     = Mobility Header message type
         If Mobility Headers of a specified type are allowed to be
         sent but NOT received via an SA, then the relevant SPD
         entry would be set as follows:
         Local's
           next layer protocol = Mobility Header
           "port" selector     = Mobility Header message type
         Remote's
           next layer protocol = Mobility Header
           "port" selector     = OPAQUE
         If Mobility Headers of a specified type are allowed to be
         received but NOT sent via an SA, then the relevant SPD
         entry would be set as follows:
         Local's
           next layer protocol = Mobility Header
           "port" selector     = OPAQUE
         Remote's
           next layer protocol = Mobility Header
           "port" selector     = Mobility Header message type
      C. If a system is willing to send traffic with a particular
         "port" value but NOT receive traffic with that kind of
         port value, the system's traffic selectors are set as
         follows in the relevant SPD entry:

Kent & Seo Standards Track [Page 33] RFC 4301 Security Architecture for IP December 2005

         Local's
           next layer protocol = ICMP
           "port" selector     = <specific ICMP type & code>
         Remote's
           next layer protocol = ICMP
           "port" selector     = OPAQUE
      D. To indicate that a system is willing to receive traffic
         with a particular "port" value but NOT send that kind of
         traffic, the system's traffic selectors are set as follows
         in the relevant SPD entry:
         Local's
           next layer protocol = ICMP
           "port" selector     = OPAQUE
         Remote's
           next layer protocol = ICMP
           "port" selector     = <specific ICMP type & code>
         For example, if a security gateway is willing to allow
         systems behind it to send ICMP traceroutes, but is not
         willing to let outside systems run ICMP traceroutes to
         systems behind it, then the security gateway's traffic
         selectors are set as follows in the relevant SPD entry:
         Local's
           next layer protocol = 1 (ICMPv4)
           "port" selector     = 30 (traceroute)
         Remote's
           next layer protocol = 1 (ICMPv4)
           "port" selector     = OPAQUE

4.4.2. Security Association Database (SAD)

 In each IPsec implementation, there is a nominal Security Association
 Database (SAD), in which each entry defines the parameters associated
 with one SA.  Each SA has an entry in the SAD.  For outbound
 processing, each SAD entry is pointed to by entries in the SPD-S part
 of the SPD cache.  For inbound processing, for unicast SAs, the SPI
 is used either alone to look up an SA or in conjunction with the
 IPsec protocol type.  If an IPsec implementation supports multicast,
 the SPI plus destination address, or SPI plus destination and source
 addresses are used to look up the SA. (See Section 4.1 for details on
 the algorithm that MUST be used for mapping inbound IPsec datagrams
 to SAs.) The following parameters are associated with each entry in

Kent & Seo Standards Track [Page 34] RFC 4301 Security Architecture for IP December 2005

 the SAD.  They should all be present except where otherwise noted,
 e.g., AH Authentication algorithm.  This description does not purport
 to be a MIB, only a specification of the minimal data items required
 to support an SA in an IPsec implementation.
 For each of the selectors defined in Section 4.4.1.1, the entry for
 an inbound SA in the SAD MUST be initially populated with the value
 or values negotiated at the time the SA was created. (See the
 paragraph in Section 4.4.1 under "Handling Changes to the SPD while
 the System is Running" for guidance on the effect of SPD changes on
 extant SAs.) For a receiver, these values are used to check that the
 header fields of an inbound packet (after IPsec processing) match the
 selector values negotiated for the SA.  Thus, the SAD acts as a cache
 for checking the selectors of inbound traffic arriving on SAs.  For
 the receiver, this is part of verifying that a packet arriving on an
 SA is consistent with the policy for the SA. (See Section 6 for rules
 for ICMP messages.)  These fields can have the form of specific
 values, ranges, ANY, or OPAQUE, as described in Section 4.4.1.1,
 "Selectors".  Note also that there are a couple of situations in
 which the SAD can have entries for SAs that do not have corresponding
 entries in the SPD.  Since this document does not mandate that the
 SAD be selectively cleared when the SPD is changed, SAD entries can
 remain when the SPD entries that created them are changed or deleted.
 Also, if a manually keyed SA is created, there could be an SAD entry
 for this SA that does not correspond to any SPD entry.
 Note: The SAD can support multicast SAs, if manually configured.  An
 outbound multicast SA has the same structure as a unicast SA.  The
 source address is that of the sender, and the destination address is
 the multicast group address.  An inbound, multicast SA must be
 configured with the source addresses of each peer authorized to
 transmit to the multicast SA in question.  The SPI value for a
 multicast SA is provided by a multicast group controller, not by the
 receiver, as for a unicast SA.  Because an SAD entry may be required
 to accommodate multiple, individual IP source addresses that were
 part of an SPD entry (for unicast SAs), the required facility for
 inbound, multicast SAs is a feature already present in an IPsec
 implementation.  However, because the SPD has no provisions for
 accommodating multicast entries, this document does not specify an
 automated way to create an SAD entry for a multicast, inbound SA.
 Only manually configured SAD entries can be created to accommodate
 inbound, multicast traffic.
 Implementation Guidance: This document does not specify how an SPD-S
 entry refers to the corresponding SAD entry, as this is an
 implementation-specific detail.  However, some implementations (based
 on experience from RFC 2401) are known to have problems in this
 regard.  In particular, simply storing the (remote tunnel header IP

Kent & Seo Standards Track [Page 35] RFC 4301 Security Architecture for IP December 2005

 address, remote SPI) pair in the SPD cache is not sufficient, since
 the pair does not always uniquely identify a single SAD entry.  For
 instance, two hosts behind the same NAT could choose the same SPI
 value.  The situation also may arise if a host is assigned an IP
 address (e.g., via DHCP) previously used by some other host, and the
 SAs associated with the old host have not yet been deleted via dead
 peer detection mechanisms.  This may lead to packets being sent over
 the wrong SA or, if key management ensures the pair is unique,
 denying the creation of otherwise valid SAs.  Thus, implementors
 should implement links between the SPD cache and the SAD in a way
 that does not engender such problems.

4.4.2.1. Data Items in the SAD

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

Kent & Seo Standards Track [Page 36] RFC 4301 Security Architecture for IP December 2005

  o ESP Encryption algorithm, key, mode, IV, etc.  If a combined mode
    algorithm is used, these fields will not be applicable.
  o ESP integrity algorithm, keys, etc.  If the integrity service is
    not selected, these fields will not be applicable.  If a combined
    mode algorithm is used, these fields will not be applicable.
  o ESP combined mode algorithms, key(s), etc.  This data is used when
    a combined mode (encryption and integrity) algorithm is used with
    ESP.  If a combined mode algorithm is not used, these fields are
    not applicable.
  o Lifetime of this SA: a time interval after which an SA must be
    replaced with a new SA (and new SPI) or terminated, plus an
    indication of which of these actions should occur.  This may be
    expressed as a time or byte count, or a simultaneous use of both
    with the first lifetime to expire taking precedence.  A compliant
    implementation MUST support both types of lifetimes, and MUST
    support a simultaneous use of both.  If time is employed, and if
    IKE employs X.509 certificates for SA establishment, the SA
    lifetime must be constrained by the validity intervals of the
    certificates, and the NextIssueDate of the Certificate Revocation
    Lists (CRLs) used in the IKE exchange for the SA.  Both initiator
    and responder are responsible for constraining the SA lifetime in
    this fashion.  Note: The details of how to handle the refreshing
    of keys when SAs expire is a local matter.  However, one
    reasonable approach is:
   (a) If byte count is used, then the implementation SHOULD count the
       number of bytes to which the IPsec cryptographic algorithm is
       applied.  For ESP, this is the encryption algorithm (including
       Null encryption) and for AH, this is the authentication
       algorithm.  This includes pad bytes, etc.  Note that
       implementations MUST be able to handle having the counters at
       the ends of an SA get out of synch, e.g., because of packet
       loss or because the implementations at each end of the SA
       aren't doing things the same way.
   (b) There SHOULD be two kinds of lifetime -- a soft lifetime that
       warns the implementation to initiate action such as setting up
       a replacement SA, and a hard lifetime when the current SA ends
       and is destroyed.
   (c) If the entire packet does not get delivered during the SA's
       lifetime, the packet SHOULD be discarded.
  o IPsec protocol mode: tunnel or transport.  Indicates which mode of
    AH or ESP is applied to traffic on this SA.

Kent & Seo Standards Track [Page 37] RFC 4301 Security Architecture for IP December 2005

  o Stateful fragment checking flag.  Indicates whether or not
    stateful fragment checking applies to this SA.
  o Bypass DF bit (T/F) -- applicable to tunnel mode SAs where both
    inner and outer headers are IPv4.
  o DSCP values -- the set of DSCP values allowed for packets carried
    over this SA.  If no values are specified, no DSCP-specific
    filtering is applied.  If one or more values are specified, these
    are used to select one SA among several that match the traffic
    selectors for an outbound packet.  Note that these values are NOT
    checked against inbound traffic arriving on the SA.
  o Bypass DSCP (T/F) or map to unprotected DSCP values (array) if
    needed to restrict bypass of DSCP values -- applicable to tunnel
    mode SAs.  This feature maps DSCP values from an inner header to
    values in an outer header, e.g., to address covert channel
    signaling concerns.
  o Path MTU: any observed path MTU and aging variables.
  o Tunnel header IP source and destination address -- both addresses
    must be either IPv4 or IPv6 addresses.  The version implies the
    type of IP header to be used.  Only used when the IPsec protocol
    mode is tunnel.

4.4.2.2. Relationship between SPD, PFP flag, packet, and SAD

    For each selector, the following tables show the relationship
    between the value in the SPD, the PFP flag, the value in the
    triggering packet, and the resulting value in the SAD.  Note that
    the administrative interface for IPsec can use various syntactic
    options to make it easier for the administrator to enter rules.
    For example, although a list of ranges is what IKEv2 sends, it
    might be clearer and less error prone for the user to enter a
    single IP address or IP address prefix.

Kent & Seo Standards Track [Page 38] RFC 4301 Security Architecture for IP December 2005

                                      Value in
                                      Triggering   Resulting SAD
       Selector  SPD Entry        PFP Packet       Entry
       --------  ---------------- --- ------------ --------------
       loc addr  list of ranges    0  IP addr "S"  list of ranges
                 ANY               0  IP addr "S"  ANY
                 list of ranges    1  IP addr "S"  "S"
                 ANY               1  IP addr "S"  "S"
       rem addr  list of ranges    0  IP addr "D"  list of ranges
                 ANY               0  IP addr "D"  ANY
                 list of ranges    1  IP addr "D"  "D"
                 ANY               1  IP addr "D"  "D"
       protocol  list of prot's*   0  prot. "P"    list of prot's*
                 ANY**             0  prot. "P"    ANY
                 OPAQUE****        0  prot. "P"    OPAQUE
                 list of prot's*   0  not avail.   discard packet
                 ANY**             0  not avail.   ANY
                 OPAQUE****        0  not avail.   OPAQUE
                 list of prot's*   1  prot. "P"    "P"
                 ANY**             1  prot. "P"    "P"
                 OPAQUE****        1  prot. "P"    ***
                 list of prot's*   1  not avail.   discard packet
                 ANY**             1  not avail.   discard packet
                 OPAQUE****        1  not avail.   ***

Kent & Seo Standards Track [Page 39] RFC 4301 Security Architecture for IP December 2005

    If the protocol is one that has two ports, then there will be
    selectors for both Local and Remote ports.
                                      Value in
                                      Triggering   Resulting SAD
       Selector  SPD Entry        PFP Packet       Entry
       --------  ---------------- --- ------------ --------------
       loc port  list of ranges    0  src port "s" list of ranges
                 ANY               0  src port "s" ANY
                 OPAQUE            0  src port "s" OPAQUE
                 list of ranges    0  not avail.   discard packet
                 ANY               0  not avail.   ANY
                 OPAQUE            0  not avail.   OPAQUE
                 list of ranges    1  src port "s" "s"
                 ANY               1  src port "s" "s"
                 OPAQUE            1  src port "s" ***
                 list of ranges    1  not avail.   discard packet
                 ANY               1  not avail.   discard packet
                 OPAQUE            1  not avail.   ***
       rem port  list of ranges    0  dst port "d" list of ranges
                 ANY               0  dst port "d" ANY
                 OPAQUE            0  dst port "d" OPAQUE
                 list of ranges    0  not avail.   discard packet
                 ANY               0  not avail.   ANY
                 OPAQUE            0  not avail.   OPAQUE
                 list of ranges    1  dst port "d" "d"
                 ANY               1  dst port "d" "d"
                 OPAQUE            1  dst port "d" ***
                 list of ranges    1  not avail.   discard packet
                 ANY               1  not avail.   discard packet
                 OPAQUE            1  not avail.   ***

Kent & Seo Standards Track [Page 40] RFC 4301 Security Architecture for IP December 2005

    If the protocol is mobility header, then there will be a selector
    for mh type.
                                      Value in
                                      Triggering   Resulting SAD
       Selector  SPD Entry        PFP Packet       Entry
       --------  ---------------- --- ------------ --------------
       mh type   list of ranges    0  mh type "T"  list of ranges
                 ANY               0  mh type "T"  ANY
                 OPAQUE            0  mh type "T"  OPAQUE
                 list of ranges    0  not avail.   discard packet
                 ANY               0  not avail.   ANY
                 OPAQUE            0  not avail.   OPAQUE
                 list of ranges    1  mh type "T"  "T"
                 ANY               1  mh type "T"  "T"
                 OPAQUE            1  mh type "T"  ***
                 list of ranges    1  not avail.   discard packet
                 ANY               1  not avail.   discard packet
                 OPAQUE            1  not avail.   ***

Kent & Seo Standards Track [Page 41] RFC 4301 Security Architecture for IP December 2005

    If the protocol is ICMP, then there will be a 16-bit selector for
    ICMP type and ICMP code.  Note that the type and code are bound to
    each other, i.e., the codes apply to the particular type.  This
    16-bit selector can contain a single type and a range of codes, a
    single type and ANY code, and ANY type and ANY code.
                                       Value in
                                       Triggering   Resulting SAD
       Selector   SPD Entry        PFP Packet       Entry
       ---------  ---------------- --- ------------ --------------
       ICMP type  a single type &   0  type "t" &   single type &
       and code    range of codes        code "c"    range of codes
                  a single type &   0  type "t" &   single type &
                   ANY code              code "c"    ANY code
                  ANY type & ANY    0  type "t" &   ANY type &
                   code                  code "c"    ANY code
                  OPAQUE            0  type "t" &   OPAQUE
                                         code "c"
                  a single type &   0  not avail.   discard packet
                   range of codes
                  a single type &   0  not avail.   discard packet
                   ANY code
                  ANY type &        0  not avail.   ANY type &
                   ANY code                          ANY code
                  OPAQUE            0  not avail.   OPAQUE
                  a single type &   1  type "t" &   "t" and "c"
                   range of codes        code "c"
                  a single type &   1  type "t" &   "t" and "c"
                   ANY code              code "c"
                  ANY type &        1  type "t" &   "t" and "c"
                   ANY code              code "c"
                  OPAQUE            1  type "t" &   ***
                                         code "c"
                  a single type &   1  not avail.   discard packet
                   range of codes
                  a single type &   1  not avail.   discard packet
                   ANY code
                  ANY type &        1  not avail.   discard packet
                   ANY code
                  OPAQUE            1  not avail.   ***

Kent & Seo Standards Track [Page 42] RFC 4301 Security Architecture for IP December 2005

    If the name selector is used:
                                       Value in
                                       Triggering   Resulting SAD
       Selector   SPD Entry        PFP Packet       Entry
       ---------  ---------------- --- ------------ --------------
       name       list of user or  N/A     N/A           N/A
                  system names
  • "List of protocols" is the information, not the way

that the SPD or SAD or IKEv2 have to represent this

            information.
         ** 0 (zero) is used by IKE to indicate ANY for
            protocol.
        *** Use of PFP=1 with an OPAQUE value is an error and
            SHOULD be prohibited by an IPsec implementation.
       **** The protocol field cannot be OPAQUE in IPv4.  This
            table entry applies only to IPv6.

4.4.3. Peer Authorization Database (PAD)

 The Peer Authorization Database (PAD) provides the link between the
 SPD and a security association management protocol such as IKE.  It
 embodies several critical functions:
      o identifies the peers or groups of peers that are authorized
        to communicate with this IPsec entity
      o specifies the protocol and method used to authenticate each
        peer
      o provides the authentication data for each peer
      o constrains the types and values of IDs that can be asserted
        by a peer with regard to child SA creation, to ensure that the
        peer does not assert identities for lookup in the SPD that it
        is not authorized to represent, when child SAs are created
      o peer gateway location info, e.g., IP address(es) or DNS names,
        MAY be included for peers that are known to be "behind" a
        security gateway
 The PAD provides these functions for an IKE peer when the peer acts
 as either the initiator or the responder.
 To perform these functions, the PAD contains an entry for each peer
 or group of peers with which the IPsec entity will communicate.  An
 entry names an individual peer (a user, end system or security
 gateway) or specifies a group of peers (using ID matching rules
 defined below).  The entry specifies the authentication protocol
 (e.g., IKEv1, IKEv2, KINK) method used (e.g., certificates or pre-
 shared secrets) and the authentication data (e.g., the pre-shared

Kent & Seo Standards Track [Page 43] RFC 4301 Security Architecture for IP December 2005

 secret or the trust anchor relative to which the peer's certificate
 will be validated).  For certificate-based authentication, the entry
 also may provide information to assist in verifying the revocation
 status of the peer, e.g., a pointer to a CRL repository or the name
 of an Online Certificate Status Protocol (OCSP) server associated
 with the peer or with the trust anchor associated with the peer.
 Each entry also specifies whether the IKE ID payload will be used as
 a symbolic name for SPD lookup, or whether the remote IP address
 provided in traffic selector payloads will be used for SPD lookups
 when child SAs are created.
 Note that the PAD information MAY be used to support creation of more
 than one tunnel mode SA at a time between two peers, e.g., two
 tunnels to protect the same addresses/hosts, but with different
 tunnel endpoints.

4.4.3.1. PAD Entry IDs and Matching Rules

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

Kent & Seo Standards Track [Page 44] RFC 4301 Security Architecture for IP December 2005

 Similarly, a Distinguished Name may specify a complete Distinguished
 Name to match exactly one entry, e.g., CN = Stephen, O = BBN
 Technologies, SP = MA, C = US.  Alternatively, an entry may encompass
 a group of peers by specifying a sub-tree, e.g., an entry of the form
 "C = US, SP = MA" might be used to match all DNs that contain these
 two attributes as the top two Relative Distinguished Names (RDNs).
 For an RFC 822 e-mail addresses, the same options exist.  A complete
 address such as foo@example.com matches one entity, but a sub-tree
 name such as "@example.com" could be used to match all the entities
 with names ending in those two domain names to the right of the @.
 The specific syntax used by an implementation to accommodate sub-tree
 matching for distinguished names, domain names or RFC 822 e-mail
 addresses is a local matter.  But, at a minimum, sub-tree matching of
 the sort described above MUST be supported. (Substring matching
 within a DN, DNS name, or RFC 822 address MAY be supported, but is
 not required.)
 For IPv4 and IPv6 addresses, the same address range syntax used for
 SPD entries MUST be supported.  This allows specification of an
 individual address (via a trivial range), an address prefix (by
 choosing a range that adheres to Classless Inter-Domain Routing
 (CIDR)-style prefixes), or an arbitrary address range.
 The Key ID field is defined as an OCTET string in IKE.  For this name
 type, only exact-match syntax MUST be supported (since there is no
 explicit structure for this ID type).  Additional matching functions
 MAY be supported for this ID type.

4.4.3.2. IKE Peer Authentication Data

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

Kent & Seo Standards Track [Page 45] RFC 4301 Security Architecture for IP December 2005

 appropriate OCSP responders or CRL repositories, and associated
 authentication data.  For authentication based on a pre-shared
 secret, the PAD contains the pre-shared secret to be used by IKE.
 This document does not require that the IKE ID asserted by a peer be
 syntactically related to a specific field in an end entity
 certificate that is employed to authenticate the identity of that
 peer.  However, it often will be appropriate to impose such a
 requirement, e.g., when a single entry represents a set of peers each
 of whom may have a distinct SPD entry.  Thus, implementations MUST
 provide a means for an administrator to require a match between an
 asserted IKE ID and the subject name or subject alt name in a
 certificate.  The former is applicable to IKE IDs expressed as
 distinguished names; the latter is appropriate for DNS names, RFC 822
 e-mail addresses, and IP addresses.  Since KEY ID is intended for
 identifying a peer authenticated via a pre-shared secret, there is no
 requirement to match this ID type to a certificate field.
 See IKEv1 [HarCar98] and IKEv2 [Kau05] for details of how IKE
 performs peer authentication using certificates or pre-shared
 secrets.
 This document does not mandate support for any other authentication
 methods, although such methods MAY be employed.

4.4.3.3. Child SA Authorization Data

 Once an IKE peer is authenticated, child SAs may be created.  Each
 PAD entry contains data to constrain the set of IDs that can be
 asserted by an IKE peer, for matching against the SPD.  Each PAD
 entry indicates whether the IKE ID is to be used as a symbolic name
 for SPD matching, or whether an IP address asserted in a traffic
 selector payload is to be used.
 If the entry indicates that the IKE ID is to be used, then the PAD
 entry ID field defines the authorized set of IDs.  If the entry
 indicates that child SAs traffic selectors are to be used, then an
 additional data element is required, in the form of IPv4 and/or IPv6
 address ranges. (A peer may be authorized for both address types, so
 there MUST be provision for both a v4 and a v6 address range.)

4.4.3.4. How the PAD Is Used

 During the initial IKE exchange, the initiator and responder each
 assert their identity via the IKE ID payload and send an AUTH payload
 to verify the asserted identity.  One or more CERT payloads may be
 transmitted to facilitate the verification of each asserted identity.

Kent & Seo Standards Track [Page 46] RFC 4301 Security Architecture for IP December 2005

 When an IKE entity receives an IKE ID payload, it uses the asserted
 ID to locate an entry in the PAD, using the matching rules described
 above.  The PAD entry specifies the authentication method to be
 employed for the identified peer.  This ensures that the right method
 is used for each peer and that different methods can be used for
 different peers.  The entry also specifies the authentication data
 that will be used to verify the asserted identity.  This data is
 employed in conjunction with the specified method to authenticate the
 peer, before any CHILD SAs are created.
 Child SAs are created based on the exchange of traffic selector
 payloads, either at the end of the initial IKE exchange or in
 subsequent CREATE_CHILD_SA exchanges.  The PAD entry for the (now
 authenticated) IKE peer is used to constrain creation of child SAs;
 specifically, the PAD entry specifies how the SPD is searched using a
 traffic selector proposal from a peer.  There are two choices: either
 the IKE ID asserted by the peer is used to find an SPD entry via its
 symbolic name, or peer IP addresses asserted in traffic selector
 payloads are used for SPD lookups based on the remote IP address
 field portion of an SPD entry.  It is necessary to impose these
 constraints on creation of child SAs to prevent an authenticated peer
 from spoofing IDs associated with other, legitimate peers.
 Note that because the PAD is checked before searching for an SPD
 entry, this safeguard protects an initiator against spoofing attacks.
 For example, assume that IKE A receives an outbound packet destined
 for IP address X, a host served by a security gateway.  RFC 2401
 [RFC2401] and this document do not specify how A determines the
 address of the IKE peer serving X.  However, any peer contacted by A
 as the presumed representative for X must be registered in the PAD in
 order to allow the IKE exchange to be authenticated.  Moreover, when
 the authenticated peer asserts that it represents X in its traffic
 selector exchange, the PAD will be consulted to determine if the peer
 in question is authorized to represent X.  Thus, the PAD provides a
 binding of address ranges (or name sub-spaces) to peers, to counter
 such attacks.

4.5. SA and Key Management

 All IPsec implementations MUST support both manual and automated SA
 and cryptographic key management.  The IPsec protocols, AH and ESP,
 are largely independent of the associated SA management techniques,
 although the techniques involved do affect some of the security
 services offered by the protocols.  For example, the optional
 anti-replay service available for AH and ESP requires automated SA
 management.  Moreover, the granularity of key distribution employed
 with IPsec determines the granularity of authentication provided.  In
 general, data origin authentication in AH and ESP is limited by the

Kent & Seo Standards Track [Page 47] RFC 4301 Security Architecture for IP December 2005

 extent to which secrets used with the integrity algorithm (or with a
 key management protocol that creates such secrets) are shared among
 multiple possible sources.
 The following text describes the minimum requirements for both types
 of SA management.

4.5.1. Manual Techniques

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

4.5.2. Automated SA and Key Management

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

Kent & Seo Standards Track [Page 48] RFC 4301 Security Architecture for IP December 2005

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

4.5.3. Locating a Security Gateway

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

Kent & Seo Standards Track [Page 49] RFC 4301 Security Architecture for IP December 2005

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

4.6. SAs and Multicast

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

5. IP Traffic Processing

 As mentioned in Section 4.4.1, "The Security Policy Database (SPD)",
 the SPD (or associated caches) MUST be consulted during the
 processing of all traffic that crosses the IPsec protection boundary,
 including IPsec management traffic.  If no policy is found in the SPD
 that matches a packet (for either inbound or outbound traffic), the
 packet MUST be discarded.  To simplify processing, and to allow for
 very fast SA lookups (for SG/BITS/BITW), this document introduces the

Kent & Seo Standards Track [Page 50] RFC 4301 Security Architecture for IP December 2005

 notion of an SPD cache for all outbound traffic (SPD-O plus SPD-S),
 and a cache for inbound, non-IPsec-protected traffic (SPD-I).  (As
 mentioned earlier, the SAD acts as a cache for checking the selectors
 of inbound IPsec-protected traffic arriving on SAs.) There is
 nominally one cache per SPD.  For the purposes of this specification,
 it is assumed that each cached entry will map to exactly one SA.
 Note, however, exceptions arise when one uses multiple SAs to carry
 traffic of different priorities (e.g., as indicated by distinct DSCP
 values) but the same selectors.  Note also, that there are a couple
 of situations in which the SAD can have entries for SAs that do not
 have corresponding entries in the SPD.  Since this document does not
 mandate that the SAD be selectively cleared when the SPD is changed,
 SAD entries can remain when the SPD entries that created them are
 changed or deleted.  Also, if a manually keyed SA is created, there
 could be an SAD entry for this SA that does not correspond to any SPD
 entry.
 Since SPD entries may overlap, one cannot safely cache these entries
 in general.  Simple caching might result in a match against a cache
 entry, whereas an ordered search of the SPD would have resulted in a
 match against a different entry.  But, if the SPD entries are first
 decorrelated, then the resulting entries can safely be cached.  Each
 cached entry will indicate that matching traffic should be bypassed
 or discarded, appropriately. (Note: The original SPD entry might
 result in multiple SAs, e.g., because of PFP.) Unless otherwise
 noted, all references below to the "SPD" or "SPD cache" or "cache"
 are to a decorrelated SPD (SPD-I, SPD-O, SPD-S) or the SPD cache
 containing entries from the decorrelated SPD.
 Note: In a host IPsec implementation based on sockets, the SPD will
 be consulted whenever a new socket is created to determine what, if
 any, IPsec processing will be applied to the traffic that will flow
 on that socket.  This provides an implicit caching mechanism, and the
 portions of the preceding discussion that address caching can be
 ignored in such implementations.
 Note: It is assumed that one starts with a correlated SPD because
 that is how users and administrators are accustomed to managing these
 sorts of access control lists or firewall filter rules.  Then the
 decorrelation algorithm is applied to build a list of cache-able SPD
 entries.  The decorrelation is invisible at the management interface.
 For inbound IPsec traffic, the SAD entry selected by the SPI serves
 as the cache for the selectors to be matched against arriving IPsec
 packets, after AH or ESP processing has been performed.

Kent & Seo Standards Track [Page 51] RFC 4301 Security Architecture for IP December 2005

5.1. Outbound IP Traffic Processing (protected-to-unprotected)

 First consider the path for traffic entering the implementation via a
 protected interface and exiting via an unprotected interface.
                        Unprotected Interface
                                 ^
                                 |
          (nested SAs)      +----------+
         -------------------|Forwarding|<-----+
         |                  +----------+      |
         |                        ^           |
         |                        | BYPASS    |
         V                     +-----+        |
     +-------+                 | SPD |     +--------+
  ...| SPD-I |.................|Cache|.....|PROCESS |...IPsec
     |  (*)  |                 | (*) |---->|(AH/ESP)|   boundary
     +-------+                 +-----+     +--------+
         |        +-------+     /  ^
         |        |DISCARD| <--/   |
         |        +-------+        |
         |                         |
         |                 +-------------+
         |---------------->|SPD Selection|
                           +-------------+
                                  ^
                                  |     +------+
                                  |  -->| ICMP |
                                  | /   +------+
                                  |/
                                  |
                                  |
                          Protected Interface
       Figure 2.  Processing Model for Outbound Traffic
                  (*) = The SPD caches are shown here.  If there
                        is a cache miss, then the SPD is checked.
                        There is no requirement that an
                        implementation buffer the packet if
                        there is a cache miss.

Kent & Seo Standards Track [Page 52] RFC 4301 Security Architecture for IP December 2005

 IPsec MUST perform the following steps when processing outbound
 packets:
 1.  When a packet arrives from the subscriber (protected) interface,
     invoke the SPD selection function to obtain the SPD-ID needed to
     choose the appropriate SPD. (If the implementation uses only one
     SPD, this step is a no-op.)
 2.  Match the packet headers against the cache for the SPD specified
     by the SPD-ID from step 1.  Note that this cache contains entries
     from SPD-O and SPD-S.
 3a. If there is a match, then process the packet as specified by the
     matching cache entry, i.e., BYPASS, DISCARD, or PROTECT using AH
     or ESP.  If IPsec processing is applied, there is a link from the
     SPD cache entry to the relevant SAD entry (specifying the mode,
     cryptographic algorithms, keys, SPI, PMTU, etc.).  IPsec
     processing is as previously defined, for tunnel or transport
     modes and for AH or ESP, as specified in their respective RFCs
     [Ken05b, Ken05a].  Note that the SA PMTU value, plus the value of
     the stateful fragment checking flag (and the DF bit in the IP
     header of the outbound packet) determine whether the packet can
     (must) be fragmented prior to or after IPsec processing, or if it
     must be discarded and an ICMP PMTU message is sent.
 3b. If no match is found in the cache, search the SPD (SPD-S and
     SPD-O parts) specified by SPD-ID.  If the SPD entry calls for
     BYPASS or DISCARD, create one or more new outbound SPD cache
     entries and if BYPASS, create one or more new inbound SPD cache
     entries. (More than one cache entry may be created since a
     decorrelated SPD entry may be linked to other such entries that
     were created as a side effect of the decorrelation process.) If
     the SPD entry calls for PROTECT, i.e., creation of an SA, the key
     management mechanism (e.g., IKEv2) is invoked to create the SA.
     If SA creation succeeds, a new outbound (SPD-S) cache entry is
     created, along with outbound and inbound SAD entries, otherwise
     the packet is discarded. (A packet that triggers an SPD lookup
     MAY be discarded by the implementation, or it MAY be processed
     against the newly created cache entry, if one is created.)  Since
     SAs are created in pairs, an SAD entry for the corresponding
     inbound SA also is created, and it contains the selector values
     derived from the SPD entry (and packet, if any PFP flags were
     "true") used to create the inbound SA, for use in checking
     inbound traffic delivered via the SA.
 4.  The packet is passed to the outbound forwarding function
     (operating outside of the IPsec implementation), to select the
     interface to which the packet will be directed.  This function

Kent & Seo Standards Track [Page 53] RFC 4301 Security Architecture for IP December 2005

     may cause the packet to be passed back across the IPsec boundary,
     for additional IPsec processing, e.g., in support of nested SAs.
     If so, there MUST be an entry in SPD-I database that permits
     inbound bypassing of the packet, otherwise the packet will be
     discarded.  If necessary, i.e., if there is more than one SPD-I,
     the traffic being looped back MAY be tagged as coming from this
     internal interface.  This would allow the use of a different
     SPD-I for "real" external traffic vs. looped traffic, if needed.
 Note: With the exception of IPv4 and IPv6 transport mode, an SG,
 BITS, or BITW implementation MAY fragment packets before applying
 IPsec. (This applies only to IPv4.  For IPv6 packets, only the
 originator is allowed to fragment them.) The device SHOULD have a
 configuration setting to disable this.  The resulting fragments are
 evaluated against the SPD in the normal manner.  Thus, fragments not
 containing port numbers (or ICMP message type and code, or Mobility
 Header type) will only match rules having port (or ICMP message type
 and code, or MH type) selectors of OPAQUE or ANY. (See Section 7 for
 more details.)
 Note: With regard to determining and enforcing the PMTU of an SA, the
 IPsec system MUST follow the steps described in Section 8.2.

5.1.1. Handling an Outbound Packet That Must Be Discarded

 If an IPsec system receives an outbound packet that it finds it must
 discard, it SHOULD be capable of generating and sending an ICMP
 message to indicate to the sender of the outbound packet that the
 packet was discarded.  The type and code of the ICMP message will
 depend on the reason for discarding the packet, as specified below.
 The reason SHOULD be recorded in the audit log.  The audit log entry
 for this event SHOULD include the reason, current date/time, and the
 selector values from the packet.
 a.  The selectors of the packet matched an SPD entry requiring the
     packet to be discarded.
         IPv4 Type = 3 (destination unreachable) Code = 13
              (Communication Administratively Prohibited)
         IPv6 Type = 1 (destination unreachable) Code = 1
              (Communication with destination administratively
              prohibited)
 b1. The IPsec system successfully reached the remote peer but was
     unable to negotiate the SA required by the SPD entry matching the
     packet because, for example, the remote peer is administratively
     prohibited from communicating with the initiator, the initiating

Kent & Seo Standards Track [Page 54] RFC 4301 Security Architecture for IP December 2005

     peer was unable to authenticate itself to the remote peer, the
     remote peer was unable to authenticate itself to the initiating
     peer, or the SPD at the remote peer did not have a suitable
     entry.
         IPv4 Type = 3 (destination unreachable) Code = 13
              (Communication Administratively Prohibited)
         IPv6 Type = 1 (destination unreachable) Code = 1
              (Communication with destination administratively
              prohibited)
 b2. The IPsec system was unable to set up the SA required by the SPD
     entry matching the packet because the IPsec peer at the other end
     of the exchange could not be contacted.
         IPv4 Type = 3 (destination unreachable) Code = 1 (host
              unreachable)
         IPv6 Type = 1 (destination unreachable) Code = 3 (address
              unreachable)
 Note that an attacker behind a security gateway could send packets
 with a spoofed source address, W.X.Y.Z, to an IPsec entity causing it
 to send ICMP messages to W.X.Y.Z.  This creates an opportunity for a
 denial of service (DoS) attack among hosts behind a security gateway.
 To address this, a security gateway SHOULD include a management
 control to allow an administrator to configure an IPsec
 implementation to send or not send the ICMP messages under these
 circumstances, and if this facility is selected, to rate limit the
 transmission of such ICMP responses.

5.1.2. Header Construction for Tunnel Mode

 This section describes the handling of the inner and outer IP
 headers, extension headers, and options for AH and ESP tunnels, with
 regard to outbound traffic processing.  This includes how to
 construct the encapsulating (outer) IP header, how to process fields
 in the inner IP header, and what other actions should be taken for
 outbound, tunnel mode traffic.  The general processing described here
 is modeled after RFC 2003, "IP Encapsulation within IP" [Per96]:
  o The outer IP header Source Address and Destination Address
    identify the "endpoints" of the tunnel (the encapsulator and
    decapsulator).  The inner IP header Source Address and Destination
    Addresses identify the original sender and recipient of the
    datagram (from the perspective of this tunnel), respectively.

Kent & Seo Standards Track [Page 55] RFC 4301 Security Architecture for IP December 2005

    (See footnote 3 after the table in 5.1.2.1 for more details on the
    encapsulating source IP address.)
  o The inner IP header is not changed except as noted below for TTL
    (or Hop Limit) and the DS/ECN Fields.  The inner IP header
    otherwise remains unchanged during its delivery to the tunnel exit
    point.
  o No change to IP options or extension headers in the inner header
    occurs during delivery of the encapsulated datagram through the
    tunnel.
 Note: IPsec tunnel mode is different from IP-in-IP tunneling (RFC
 2003 [Per96]) in several ways:
  o IPsec offers certain controls to a security administrator to
    manage covert channels (which would not normally be a concern for
    tunneling) and to ensure that the receiver examines the right
    portions of the received packet with respect to application of
    access controls.  An IPsec implementation MAY be configurable with
    regard to how it processes the outer DS field for tunnel mode for
    transmitted packets.  For outbound traffic, one configuration
    setting for the outer DS field will operate as described in the
    following sections on IPv4 and IPv6 header processing for IPsec
    tunnels.  Another will allow the outer DS field to be mapped to a
    fixed value, which MAY be configured on a per-SA basis. (The value
    might really be fixed for all traffic outbound from a device, but
    per-SA granularity allows that as well.) This configuration option
    allows a local administrator to decide whether the covert channel
    provided by copying these bits outweighs the benefits of copying.
  o IPsec describes how to handle ECN or DS and provides the ability
    to control propagation of changes in these fields between
    unprotected and protected domains.  In general, propagation from a
    protected to an unprotected domain is a covert channel and thus
    controls are provided to manage the bandwidth of this channel.
    Propagation of ECN values in the other direction are controlled so
    that only legitimate ECN changes (indicating occurrence of
    congestion between the tunnel endpoints) are propagated.  By
    default, DS propagation from an unprotected domain to a protected
    domain is not permitted.  However, if the sender and receiver do
    not share the same DS code space, and the receiver has no way of
    learning how to map between the two spaces, then it may be
    appropriate to deviate from the default.  Specifically, an IPsec
    implementation MAY be configurable in terms of how it processes
    the outer DS field for tunnel mode for received packets.  It may
    be configured to either discard the outer DS value (the default)
    OR to overwrite the inner DS field with the outer DS field.  If

Kent & Seo Standards Track [Page 56] RFC 4301 Security Architecture for IP December 2005

    offered, the discard vs. overwrite behavior MAY be configured on a
    per-SA basis.  This configuration option allows a local
    administrator to decide whether the vulnerabilities created by
    copying these bits outweigh the benefits of copying.  See
    [RFC2983] for further information on when each of these behaviors
    may be useful, and also for the possible need for diffserv traffic
    conditioning prior or subsequent to IPsec processing (including
    tunnel decapsulation).
  o IPsec allows the IP version of the encapsulating header to be
    different from that of the inner header.
 The tables in the following sub-sections show the handling for the
 different header/option fields ("constructed" means that the value in
 the outer field is constructed independently of the value in the
 inner).

5.1.2.1. IPv4: Header Construction for Tunnel Mode

                       <-- How Outer Hdr Relates to Inner Hdr -->
                       Outer Hdr at                 Inner Hdr at
  IPv4                 Encapsulator                 Decapsulator
    Header fields:     --------------------         ------------
      version          4 (1)                        no change
      header length    constructed                  no change
      DS Field         copied from inner hdr (5)    no change
      ECN Field        copied from inner hdr        constructed (6)
      total length     constructed                  no change
      ID               constructed                  no change
      flags (DF,MF)    constructed, DF (4)          no change
      fragment offset  constructed                  no change
      TTL              constructed (2)              decrement (2)
      protocol         AH, ESP                      no change
      checksum         constructed                  constructed (2)(6)
      src address      constructed (3)              no change
      dest address     constructed (3)              no change
    Options            never copied                 no change
  Notes:
    (1) The IP version in the encapsulating header can be different
        from the value in the inner header.
    (2) The TTL in the inner header is decremented by the encapsulator
        prior to forwarding and by the decapsulator if it forwards the
        packet.  (The IPv4 checksum changes when the TTL changes.)

Kent & Seo Standards Track [Page 57] RFC 4301 Security Architecture for IP December 2005

        Note: Decrementing the TTL value is a normal part of
        forwarding a packet.  Thus, a packet originating from the same
        node as the encapsulator does not have its TTL decremented,
        since the sending node is originating the packet rather than
        forwarding it.  This applies to BITS and native IPsec
        implementations in hosts and routers.  However, the IPsec
        processing model includes an external forwarding capability.
        TTL processing can be used to prevent looping of packets,
        e.g., due to configuration errors, within the context of this
        processing model.
    (3) Local and Remote addresses depend on the SA, which is used to
        determine the Remote address, which in turn determines which
        Local address (net interface) is used to forward the packet.
        Note: For multicast traffic, the destination address, or
        source and destination addresses, may be required for
        demuxing.  In that case, it is important to ensure consistency
        over the lifetime of the SA by ensuring that the source
        address that appears in the encapsulating tunnel header is the
        same as the one that was negotiated during the SA
        establishment process.  There is an exception to this general
        rule, i.e., a mobile IPsec implementation will update its
        source address as it moves.
    (4) Configuration determines whether to copy from the inner header
        (IPv4 only), clear, or set the DF.
    (5) If the packet will immediately enter a domain for which the
        DSCP value in the outer header is not appropriate, that value
        MUST be mapped to an appropriate value for the domain
        [NiBlBaBL98].  See RFC 2475 [BBCDWW98] for further
        information.
    (6) If the ECN field in the inner header is set to ECT(0) or
        ECT(1), where ECT is ECN-Capable Transport (ECT), and if the
        ECN field in the outer header is set to Congestion Experienced
        (CE), then set the ECN field in the inner header to CE;
        otherwise, make no change to the ECN field in the inner
        header.  (The IPv4 checksum changes when the ECN changes.)
 Note: IPsec does not copy the options from the inner header into the
 outer header, nor does IPsec construct the options in the outer
 header.  However, post-IPsec code MAY insert/construct options for
 the outer header.

Kent & Seo Standards Track [Page 58] RFC 4301 Security Architecture for IP December 2005

5.1.2.2. IPv6: Header Construction for Tunnel Mode

                       <-- How Outer Hdr  Relates Inner Hdr --->
                       Outer Hdr at                 Inner Hdr at
  IPv6                 Encapsulator                 Decapsulator
    Header fields:     --------------------         ------------
      version          6 (1)                        no change
      DS Field         copied from inner hdr (5)    no change (9)
      ECN Field        copied from inner hdr        constructed (6)
      flow label       copied or configured (8)     no change
      payload length   constructed                  no change
      next header      AH,ESP,routing hdr           no change
      hop limit        constructed (2)              decrement (2)
      src address      constructed (3)              no change
      dest address     constructed (3)              no change
    Extension headers  never copied (7)             no change
  Notes:
    (1) - (6) See Section 5.1.2.1.
    (7) IPsec does not copy the extension headers from the inner
        packet into outer headers, nor does IPsec construct extension
        headers in the outer header.  However, post-IPsec code MAY
        insert/construct extension headers for the outer header.
    (8) See [RaCoCaDe04].  Copying is acceptable only for end systems,
        not SGs.  If an SG copied flow labels from the inner header to
        the outer header, collisions might result.
    (9) An implementation MAY choose to provide a facility to pass the
        DS value from the outer header to the inner header, on a per-
        SA basis, for received tunnel mode packets.  The motivation
        for providing this feature is to accommodate situations in
        which the DS code space at the receiver is different from that
        of the sender and the receiver has no way of knowing how to
        translate from the sender's space.  There is a danger in
        copying this value from the outer header to the inner header,
        since it enables an attacker to modify the outer DSCP value in
        a fashion that may adversely affect other traffic at the
        receiver.  Hence the default behavior for IPsec
        implementations is NOT to permit such copying.

5.2. Processing Inbound IP Traffic (unprotected-to-protected)

 Inbound processing is somewhat different from outbound processing,
 because of the use of SPIs to map IPsec-protected traffic to SAs.
 The inbound SPD cache (SPD-I) is applied only to bypassed or

Kent & Seo Standards Track [Page 59] RFC 4301 Security Architecture for IP December 2005

 discarded traffic.  If an arriving packet appears to be an IPsec
 fragment from an unprotected interface, reassembly is performed prior
 to IPsec processing.  The intent for any SPD cache is that a packet
 that fails to match any entry is then referred to the corresponding
 SPD.  Every SPD SHOULD have a nominal, final entry that catches
 anything that is otherwise unmatched, and discards it.  This ensures
 that non-IPsec-protected traffic that arrives and does not match any
 SPD-I entry will be discarded.
                    Unprotected Interface
                              |
                              V
                           +-----+   IPsec protected
       ------------------->|Demux|-------------------+
       |                   +-----+                   |
       |                      |                      |
       |            Not IPsec |                      |
       |                      |                      |
       |                      V                      |
       |     +-------+    +---------+                |
       |     |DISCARD|<---|SPD-I (*)|                |
       |     +-------+    +---------+                |
       |                   |                         |
       |                   |-----+                   |
       |                   |     |                   |
       |                   |     V                   |
       |                   |  +------+               |
       |                   |  | ICMP |               |
       |                   |  +------+               |
       |                   |                         V
    +---------+            |                   +-----------+
....|SPD-O (*)|............|...................|PROCESS(**)|...IPsec
    +---------+            |                   | (AH/ESP)  | Boundary
       ^                   |                   +-----------+
       |                   |       +---+             |
       |            BYPASS |   +-->|IKE|             |
       |                   |   |   +---+             |
       |                   V   |                     V
       |               +----------+          +---------+   +----+
       |--------<------|Forwarding|<---------|SAD Check|-->|ICMP|
         nested SAs    +----------+          | (***)   |   +----+
                             |               +---------+
                             V
                     Protected Interface
          Figure 3.  Processing Model for Inbound Traffic

Kent & Seo Standards Track [Page 60] RFC 4301 Security Architecture for IP December 2005

                     (*) = The caches are shown here.  If there is
                           a cache miss, then the SPD is checked.
                           There is no requirement that an
                           implementation buffer the packet if
                           there is a cache miss.
                    (**) = This processing includes using the
                           packet's SPI, etc., to look up the SA
                           in the SAD, which forms a cache of the
                           SPD for inbound packets (except for
                           cases noted in Sections 4.4.2 and 5).
                           See step 3a below.
                   (***) = This SAD check refers to step 4 below.
 Prior to performing AH or ESP processing, any IP fragments that
 arrive via the unprotected interface are reassembled (by IP).  Each
 inbound IP datagram to which IPsec processing will be applied is
 identified by the appearance of the AH or ESP values in the IP Next
 Protocol field (or of AH or ESP as a next layer protocol in the IPv6
 context).
 IPsec MUST perform the following steps:
 1.  When a packet arrives, it may be tagged with the ID of the
     interface (physical or virtual) via which it arrived, if
     necessary, to support multiple SPDs and associated SPD-I caches.
     (The interface ID is mapped to a corresponding SPD-ID.)
 2.  The packet is examined and demuxed into one of two categories:
     - If the packet appears to be IPsec protected and it is addressed
       to this device, an attempt is made to map it to an active SA
       via the SAD.  Note that the device may have multiple IP
       addresses that may be used in the SAD lookup, e.g., in the case
       of protocols such as SCTP.
     - Traffic not addressed to this device, or addressed to this
       device and not AH or ESP, is directed to SPD-I lookup. (This
       implies that IKE traffic MUST have an explicit BYPASS entry in
       the SPD.) If multiple SPDs are employed, the tag assigned to
       the packet in step 1 is used to select the appropriate SPD-I
       (and cache) to search.  SPD-I lookup determines whether the
       action is DISCARD or BYPASS.
 3a. If the packet is addressed to the IPsec device and AH or ESP is
     specified as the protocol, the packet is looked up in the SAD.
     For unicast traffic, use only the SPI (or SPI plus protocol).
     For multicast traffic, use the SPI plus the destination or SPI
     plus destination and source addresses, as specified in Section
     4.1. In either case (unicast or multicast), if there is no match,
     discard the traffic.  This is an auditable event.  The audit log

Kent & Seo Standards Track [Page 61] RFC 4301 Security Architecture for IP December 2005

     entry for this event SHOULD include the current date/time, SPI,
     source and destination of the packet, IPsec protocol, and any
     other selector values of the packet that are available.  If the
     packet is found in the SAD, process it accordingly (see step 4).
 3b. If the packet is not addressed to the device or is addressed to
     this device and is not AH or ESP, look up the packet header in
     the (appropriate) SPD-I cache.  If there is a match and the
     packet is to be discarded or bypassed, do so.  If there is no
     cache match, look up the packet in the corresponding SPD-I and
     create a cache entry as appropriate. (No SAs are created in
     response to receipt of a packet that requires IPsec protection;
     only BYPASS or DISCARD cache entries can be created this way.) If
     there is no match, discard the traffic.  This is an auditable
     event.  The audit log entry for this event SHOULD include the
     current date/time, SPI if available, IPsec protocol if available,
     source and destination of the packet, and any other selector
     values of the packet that are available.
 3c. Processing of ICMP messages is assumed to take place on the
     unprotected side of the IPsec boundary.  Unprotected ICMP
     messages are examined and local policy is applied to determine
     whether to accept or reject these messages and, if accepted, what
     action to take as a result.  For example, if an ICMP unreachable
     message is received, the implementation must decide whether to
     act on it, reject it, or act on it with constraints. (See Section
     6.)
 4.  Apply AH or ESP processing as specified, using the SAD entry
     selected in step 3a above.  Then match the packet against the
     inbound selectors identified by the SAD entry to verify that the
     received packet is appropriate for the SA via which it was
     received.
 5.  If an IPsec system receives an inbound packet on an SA and the
     packet's header fields are not consistent with the selectors for
     the SA, it MUST discard the packet.  This is an auditable event.
     The audit log entry for this event SHOULD include the current
     date/time, SPI, IPsec protocol(s), source and destination of the
     packet, any other selector values of the packet that are
     available, and the selector values from the relevant SAD entry.
     The system SHOULD also be capable of generating and sending an
     IKE notification of INVALID_SELECTORS to the sender (IPsec peer),
     indicating that the received packet was discarded because of
     failure to pass selector checks.

Kent & Seo Standards Track [Page 62] RFC 4301 Security Architecture for IP December 2005

 To minimize the impact of a DoS attack, or a mis-configured peer, the
 IPsec system SHOULD include a management control to allow an
 administrator to configure the IPsec implementation to send or not
 send this IKE notification, and if this facility is selected, to rate
 limit the transmission of such notifications.
 After traffic is bypassed or processed through IPsec, it is handed to
 the inbound forwarding function for disposition.  This function may
 cause the packet to be sent (outbound) across the IPsec boundary for
 additional inbound IPsec processing, e.g., in support of nested SAs.
 If so, then as with ALL outbound traffic that is to be bypassed, the
 packet MUST be matched against an SPD-O entry.  Ultimately, the
 packet should be forwarded to the destination host or process for
 disposition.

6. ICMP Processing

 This section describes IPsec handling of ICMP traffic.  There are two
 categories of ICMP traffic: error messages (e.g., type = destination
 unreachable) and non-error messages (e.g., type = echo).  This
 section applies exclusively to error messages.  Disposition of
 non-error, ICMP messages (that are not addressed to the IPsec
 implementation itself) MUST be explicitly accounted for using SPD
 entries.
 The discussion in this section applies to ICMPv6 as well as to
 ICMPv4.  Also, a mechanism SHOULD be provided to allow an
 administrator to cause ICMP error messages (selected, all, or none)
 to be logged as an aid to problem diagnosis.

6.1. Processing ICMP Error Messages Directed to an IPsec Implementation

6.1.1. ICMP Error Messages Received on the Unprotected Side of the

      Boundary
 Figure 3 in Section 5.2 shows a distinct ICMP processing module on
 the unprotected side of the IPsec boundary, for processing ICMP
 messages (error or otherwise) that are addressed to the IPsec device
 and that are not protected via AH or ESP.  An ICMP message of this
 sort is unauthenticated, and its processing may result in denial or
 degradation of service.  This suggests that, in general, it would be
 desirable to ignore such messages.  However, many ICMP messages will
 be received by hosts or security gateways from unauthenticated
 sources, e.g., routers in the public Internet.  Ignoring these ICMP
 messages can degrade service, e.g., because of a failure to process
 PMTU message and redirection messages.  Thus, there is also a
 motivation for accepting and acting upon unauthenticated ICMP
 messages.

Kent & Seo Standards Track [Page 63] RFC 4301 Security Architecture for IP December 2005

 To accommodate both ends of this spectrum, a compliant IPsec
 implementation MUST permit a local administrator to configure an
 IPsec implementation to accept or reject unauthenticated ICMP
 traffic.  This control MUST be at the granularity of ICMP type and
 MAY be at the granularity of ICMP type and code.  Additionally, an
 implementation SHOULD incorporate mechanisms and parameters for
 dealing with such traffic.  For example, there could be the ability
 to establish a minimum PMTU for traffic (on a per destination basis),
 to prevent receipt of an unauthenticated ICMP from setting the PMTU
 to a trivial size.
 If an ICMP PMTU message passes the checks above and the system is
 configured to accept it, then there are two possibilities.  If the
 implementation applies fragmentation on the ciphertext side of the
 boundary, then the accepted PMTU information is passed to the
 forwarding module (outside of the IPsec implementation), which uses
 it to manage outbound packet fragmentation.  If the implementation is
 configured to effect plaintext side fragmentation, then the PMTU
 information is passed to the plaintext side and processed as
 described in Section 8.2.

6.1.2. ICMP Error Messages Received on the Protected Side of the

      Boundary
 These ICMP messages are not authenticated, but they do come from
 sources on the protected side of the IPsec boundary.  Thus, these
 messages generally are viewed as more "trustworthy" than their
 counterparts arriving from sources on the unprotected side of the
 boundary.  The major security concern here is that a compromised host
 or router might emit erroneous ICMP error messages that could degrade
 service for other devices "behind" the security gateway, or that
 could even result in violations of confidentiality.  For example, if
 a bogus ICMP redirect were consumed by a security gateway, it could
 cause the forwarding table on the protected side of the boundary to
 be modified so as to deliver traffic to an inappropriate destination
 "behind" the gateway.  Thus, implementers MUST provide controls to
 allow local administrators to constrain the processing of ICMP error
 messages received on the protected side of the boundary, and directed
 to the IPsec implementation.  These controls are of the same type as
 those employed on the unprotected side, described above in Section
 6.1.1.

6.2. Processing Protected, Transit ICMP Error Messages

 When an ICMP error message is transmitted via an SA to a device
 "behind" an IPsec implementation, both the payload and the header of
 the ICMP message require checking from an access control perspective.
 If one of these messages is forwarded to a host behind a security

Kent & Seo Standards Track [Page 64] RFC 4301 Security Architecture for IP December 2005

 gateway, the receiving host IP implementation will make decisions
 based on the payload, i.e., the header of the packet that purportedly
 triggered the error response.  Thus, an IPsec implementation MUST be
 configurable to check that this payload header information is
 consistent with the SA via which it arrives. (This means that the
 payload header, with source and destination address and port fields
 reversed, matches the traffic selectors for the SA.) If this sort of
 check is not performed, then, for example, anyone with whom the
 receiving IPsec system (A) has an active SA could send an ICMP
 Destination Unreachable message that refers to any host/net with
 which A is currently communicating, and thus effect a highly
 efficient DoS attack regarding communication with other peers of A.
 Normal IPsec receiver processing of traffic is not sufficient to
 protect against such attacks.  However, not all contexts may require
 such checks, so it is also necessary to allow a local administrator
 to configure an implementation to NOT perform such checks.
 To accommodate both policies, the following convention is adopted.
 If an administrator wants to allow ICMP error messages to be carried
 by an SA without inspection of the payload, then configure an SPD
 entry that explicitly allows for carriage of such traffic.  If an
 administrator wants IPsec to check the payload of ICMP error messages
 for consistency, then do not create any SPD entries that accommodate
 carriage of such traffic based on the ICMP packet header.  This
 convention motivates the following processing description.
 IPsec senders and receivers MUST support the following processing for
 ICMP error messages that are sent and received via SAs.
 If an SA exists that accommodates an outbound ICMP error message,
 then the message is mapped to the SA and only the IP and ICMP headers
 are checked upon receipt, just as would be the case for other
 traffic.  If no SA exists that matches the traffic selectors
 associated with an ICMP error message, then the SPD is searched to
 determine if such an SA can be created.  If so, the SA is created and
 the ICMP error message is transmitted via that SA.  Upon receipt,
 this message is subject to the usual traffic selector checks at the
 receiver.  This processing is exactly what would happen for traffic
 in general, and thus does not represent any special processing for
 ICMP error messages.
 If no SA exists that would carry the outbound ICMP message in
 question, and if no SPD entry would allow carriage of this outbound
 ICMP error message, then an IPsec implementation MUST map the message
 to the SA that would carry the return traffic associated with the
 packet that triggered the ICMP error message.  This requires an IPsec
 implementation to detect outbound ICMP error messages that map to no
 extant SA or SPD entry, and treat them specially with regard to SA

Kent & Seo Standards Track [Page 65] RFC 4301 Security Architecture for IP December 2005

 creation and lookup.  The implementation extracts the header for the
 packet that triggered the error (from the ICMP message payload),
 reverses the source and destination IP address fields, extracts the
 protocol field, and reverses the port fields (if accessible).  It
 then uses this extracted information to locate an appropriate, active
 outbound SA, and transmits the error message via this SA.  If no such
 SA exists, no SA will be created, and this is an auditable event.
 If an IPsec implementation receives an inbound ICMP error message on
 an SA, and the IP and ICMP headers of the message do not match the
 traffic selectors for the SA, the receiver MUST process the received
 message in a special fashion.  Specifically, the receiver must
 extract the header of the triggering packet from the ICMP payload,
 and reverse fields as described above to determine if the packet is
 consistent with the selectors for the SA via which the ICMP error
 message was received.  If the packet fails this check, the IPsec
 implementation MUST NOT forwarded the ICMP message to the
 destination.  This is an auditable event.

7. Handling Fragments (on the protected side of the IPsec boundary)

 Earlier sections of this document describe mechanisms for (a)
 fragmenting an outbound packet after IPsec processing has been
 applied and reassembling it at the receiver before IPsec processing
 and (b) handling inbound fragments received from the unprotected side
 of the IPsec boundary.  This section describes how an implementation
 should handle the processing of outbound plaintext fragments on the
 protected side of the IPsec boundary. (See Appendix D, "Fragment
 Handling Rationale".) In particular, it addresses:
      o mapping an outbound non-initial fragment to the right SA
        (or finding the right SPD entry)
      o verifying that a received non-initial fragment is
        authorized for the SA via which it was received
      o mapping outbound and inbound non-initial fragments to the
        right SPD-O/SPD-I entry or the relevant cache entry, for
        BYPASS/DISCARD traffic
 Note: In Section 4.1, transport mode SAs have been defined to not
 carry fragments (IPv4 or IPv6).  Note also that in Section 4.4.1, two
 special values, ANY and OPAQUE, were defined for selectors and that
 ANY includes OPAQUE.  The term "non-trivial" is used to mean that the
 selector has a value other than OPAQUE or ANY.
 Note: The term "non-initial fragment" is used here to indicate a
 fragment that does not contain all the selector values that may be
 needed for access control.  As observed in Section 4.4.1, depending
 on the Next Layer Protocol, in addition to Ports, the ICMP message

Kent & Seo Standards Track [Page 66] RFC 4301 Security Architecture for IP December 2005

 type/code or Mobility Header type could be missing from non-initial
 fragments.  Also, for IPv6, even the first fragment might NOT contain
 the Next Layer Protocol or Ports (or ICMP message type/code, or
 Mobility Header type) depending on the kind and number of extension
 headers present.  If a non-initial fragment contains the Port (or
 ICMP type and code or Mobility Header type) but not the Next Layer
 Protocol, then unless there is an SPD entry for the relevant
 Local/Remote addresses with ANY for Next Layer Protocol and Port (or
 ICMP type and code or Mobility Header type), the fragment would not
 contain all the selector information needed for access control.
 To address the above issues, three approaches have been defined:
     o Tunnel mode SAs that carry initial and non-initial fragments
       (See Section 7.1.)
     o Separate tunnel mode SAs for non-initial fragments (See
       Section 7.2.)
     o Stateful fragment checking (See Section 7.3.)

7.1. Tunnel Mode SAs that Carry Initial and Non-Initial Fragments

 All implementations MUST support tunnel mode SAs that are configured
 to pass traffic without regard to port field (or ICMP type/code or
 Mobility Header type) values.  If the SA will carry traffic for
 specified protocols, the selector set for the SA MUST specify the
 port fields (or ICMP type/code or Mobility Header type) as ANY.  An
 SA defined in this fashion will carry all traffic including initial
 and non-initial fragments for the indicated Local/Remote addresses
 and specified Next Layer protocol(s).  If the SA will carry traffic
 without regard to a specific protocol value (i.e., ANY is specified
 as the (Next Layer) protocol selector value), then the port field
 values are undefined and MUST be set to ANY as well. (As noted in
 4.4.1, ANY includes OPAQUE as well as all specific values.)

7.2. Separate Tunnel Mode SAs for Non-Initial Fragments

 An implementation MAY support tunnel mode SAs that will carry only
 non-initial fragments, separate from non-fragmented packets and
 initial fragments.  The OPAQUE value will be used to specify port (or
 ICMP type/code or Mobility Header type) field selectors for an SA to
 carry such fragments.  Receivers MUST perform a minimum offset check
 on IPv4 (non-initial) fragments to protect against overlapping
 fragment attacks when SAs of this type are employed.  Because such
 checks cannot be performed on IPv6 non-initial fragments, users and
 administrators are advised that carriage of such fragments may be
 dangerous, and implementers may choose to NOT support such SAs for
 IPv6 traffic.  Also, an SA of this sort will carry all non-initial
 fragments that match a specified Local/Remote address pair and

Kent & Seo Standards Track [Page 67] RFC 4301 Security Architecture for IP December 2005

 protocol value, i.e., the fragments carried on this SA belong to
 packets that if not fragmented, might have gone on separate SAs of
 differing security.  Therefore, users and administrators are advised
 to protect such traffic using ESP (with integrity) and the
 "strongest" integrity and encryption algorithms in use between both
 peers.  (Determination of the "strongest" algorithms requires
 imposing an ordering of the available algorithms, a local
 determination at the discretion of the initiator of the SA.)
 Specific port (or ICMP type/code or Mobility Header type) selector
 values will be used to define SAs to carry initial fragments and
 non-fragmented packets.  This approach can be used if a user or
 administrator wants to create one or more tunnel mode SAs between the
 same Local/Remote addresses that discriminate based on port (or ICMP
 type/code or Mobility Header type) fields.  These SAs MUST have
 non-trivial protocol selector values, otherwise approach #1 above
 MUST be used.
 Note: In general, for the approach described in this section, one
 needs only a single SA between two implementations to carry all
 non-initial fragments.  However, if one chooses to have multiple SAs
 between the two implementations for QoS differentiation, then one
 might also want multiple SAs to carry fragments-without-ports, one
 for each supported QoS class.  Since support for QoS via distinct SAs
 is a local matter, not mandated by this document, the choice to have
 multiple SAs to carry non-initial fragments should also be local.

7.3. Stateful Fragment Checking

 An implementation MAY support some form of stateful fragment checking
 for a tunnel mode SA with non-trivial port (or ICMP type/code or MH
 type) field values (not ANY or OPAQUE).  Implementations that will
 transmit non-initial fragments on a tunnel mode SA that makes use of
 non-trivial port (or ICMP type/code or MH type) selectors MUST notify
 a peer via the IKE NOTIFY NON_FIRST_FRAGMENTS_ALSO payload.
 The peer MUST reject this proposal if it will not accept non-initial
 fragments in this context.  If an implementation does not
 successfully negotiate transmission of non-initial fragments for such
 an SA, it MUST NOT send such fragments over the SA.  This standard
 does not specify how peers will deal with such fragments, e.g., via
 reassembly or other means, at either sender or receiver.  However, a
 receiver MUST discard non-initial fragments that arrive on an SA with
 non-trivial port (or ICMP type/code or MH type) selector values
 unless this feature has been negotiated.  Also, the receiver MUST
 discard non-initial fragments that do not comply with the security
 policy applied to the overall packet.  Discarding such packets is an
 auditable event.  Note that in network configurations where fragments

Kent & Seo Standards Track [Page 68] RFC 4301 Security Architecture for IP December 2005

 of a packet might be sent or received via different security gateways
 or BITW implementations, stateful strategies for tracking fragments
 may fail.

7.4. BYPASS/DISCARD Traffic

 All implementations MUST support DISCARDing of fragments using the
 normal SPD packet classification mechanisms.  All implementations
 MUST support stateful fragment checking to accommodate BYPASS traffic
 for which a non-trivial port range is specified.  The concern is that
 BYPASS of a cleartext, non-initial fragment arriving at an IPsec
 implementation could undermine the security afforded IPsec-protected
 traffic directed to the same destination.  For example, consider an
 IPsec implementation configured with an SPD entry that calls for
 IPsec protection of traffic between a specific source/destination
 address pair, and for a specific protocol and destination port, e.g.,
 TCP traffic on port 23 (Telnet).  Assume that the implementation also
 allows BYPASS of traffic from the same source/destination address
 pair and protocol, but for a different destination port, e.g., port
 119 (NNTP).  An attacker could send a non-initial fragment (with a
 forged source address) that, if bypassed, could overlap with
 IPsec-protected traffic from the same source and thus violate the
 integrity of the IPsec-protected traffic.  Requiring stateful
 fragment checking for BYPASS entries with non-trivial port ranges
 prevents attacks of this sort.  As noted above, in network
 configurations where fragments of a packet might be sent or received
 via different security gateways or BITW implementations, stateful
 strategies for tracking fragments may fail.

8. Path MTU/DF Processing

 The application of AH or ESP to an outbound packet increases the size
 of a packet and thus may cause a packet to exceed the PMTU for the SA
 via which the packet will travel.  An IPsec implementation also may
 receive an unprotected ICMP PMTU message and, if it chooses to act
 upon the message, the result will affect outbound traffic processing.
 This section describes the processing required of an IPsec
 implementation to deal with these two PMTU issues.

8.1. DF Bit

 All IPsec implementations MUST support the option of copying the DF
 bit from an outbound packet to the tunnel mode header that it emits,
 when traffic is carried via a tunnel mode SA.  This means that it
 MUST be possible to configure the implementation's treatment of the
 DF bit (set, clear, copy from inner header) for each SA.  This
 applies to SAs where both inner and outer headers are IPv4.

Kent & Seo Standards Track [Page 69] RFC 4301 Security Architecture for IP December 2005

8.2. Path MTU (PMTU) Discovery

 This section discusses IPsec handling for unprotected Path MTU
 Discovery messages.  ICMP PMTU is used here to refer to an ICMP
 message for:
         IPv4 (RFC 792 [Pos81b]):
                 - Type = 3 (Destination Unreachable)
                 - Code = 4 (Fragmentation needed and DF set)
                 - Next-Hop MTU in the low-order 16 bits of the
                   second word of the ICMP header (labeled "unused"
                   in RFC 792), with high-order 16 bits set to zero)
         IPv6 (RFC 2463 [CD98]):
                 - Type = 2 (Packet Too Big)
                 - Code = 0 (Fragmentation needed)
                 - Next-Hop MTU in the 32-bit MTU field of the ICMP6
                   message

8.2.1. Propagation of PMTU

 When an IPsec implementation receives an unauthenticated PMTU
 message, and it is configured to process (vs. ignore) such messages,
 it maps the message to the SA to which it corresponds.  This mapping
 is effected by extracting the header information from the payload of
 the PMTU message and applying the procedure described in Section 5.2.
 The PMTU determined by this message is used to update the SAD PMTU
 field, taking into account the size of the AH or ESP header that will
 be applied, any crypto synchronization data, and the overhead imposed
 by an additional IP header, in the case of a tunnel mode SA.
 In a native host implementation, it is possible to maintain PMTU data
 at the same granularity as for unprotected communication, so there is
 no loss of functionality.  Signaling of the PMTU information is
 internal to the host.  For all other IPsec implementation options,
 the PMTU data must be propagated via a synthesized ICMP PMTU.  In
 these cases, the IPsec implementation SHOULD wait for outbound
 traffic to be mapped to the SAD entry.  When such traffic arrives, if
 the traffic would exceed the updated PMTU value the traffic MUST be
 handled as follows:
     Case 1: Original (cleartext) packet is IPv4 and has the DF
             bit set.  The implementation SHOULD discard the packet
             and send a PMTU ICMP message.

Kent & Seo Standards Track [Page 70] RFC 4301 Security Architecture for IP December 2005

     Case 2: Original (cleartext) packet is IPv4 and has the DF
             bit clear.  The implementation SHOULD fragment (before or
             after encryption per its configuration) and then forward
             the fragments.  It SHOULD NOT send a PMTU ICMP message.
     Case 3: Original (cleartext) packet is IPv6.  The implementation
             SHOULD discard the packet and send a PMTU ICMP message.

8.2.2. PMTU Aging

 In all IPsec implementations, the PMTU associated with an SA MUST be
 "aged" and some mechanism is required to update the PMTU in a timely
 manner, especially for discovering if the PMTU is smaller than
 required by current network conditions.  A given PMTU has to remain
 in place long enough for a packet to get from the source of the SA to
 the peer, and to propagate an ICMP error message if the current PMTU
 is too big.
 Implementations SHOULD use the approach described in the Path MTU
 Discovery document (RFC 1191 [MD90], Section 6.3), which suggests
 periodically resetting the PMTU to the first-hop data-link MTU and
 then letting the normal PMTU Discovery processes update the PMTU as
 necessary.  The period SHOULD be configurable.

9. Auditing

 IPsec implementations are not required to support auditing.  For the
 most part, the granularity of auditing is a local matter.  However,
 several auditable events are identified in this document, and for
 each of these events a minimum set of information that SHOULD be
 included in an audit log is defined.  Additional information also MAY
 be included in the audit log for each of these events, and additional
 events, not explicitly called out in this specification, also MAY
 result in audit log entries.  There is no requirement for the
 receiver to transmit any message to the purported transmitter in
 response to the detection of an auditable event, because of the
 potential to induce denial of service via such action.

10. Conformance Requirements

 All IPv4 IPsec implementations MUST comply with all requirements of
 this document.  All IPv6 implementations MUST comply with all
 requirements of this document.

Kent & Seo Standards Track [Page 71] RFC 4301 Security Architecture for IP December 2005

11. Security Considerations

 The focus of this document is security; hence security considerations
 permeate this specification.
 IPsec imposes stringent constraints on bypass of IP header data in
 both directions, across the IPsec barrier, especially when tunnel
 mode SAs are employed.  Some constraints are absolute, while others
 are subject to local administrative controls, often on a per-SA
 basis.  For outbound traffic, these constraints are designed to limit
 covert channel bandwidth.  For inbound traffic, the constraints are
 designed to prevent an adversary who has the ability to tamper with
 one data stream (on the unprotected side of the IPsec barrier) from
 adversely affecting other data streams (on the protected side of the
 barrier).  The discussion in Section 5 dealing with processing DSCP
 values for tunnel mode SAs illustrates this concern.
 If an IPsec implementation is configured to pass ICMP error messages
 over SAs based on the ICMP header values, without checking the header
 information from the ICMP message payload, serious vulnerabilities
 may arise.  Consider a scenario in which several sites (A, B, and C)
 are connected to one another via ESP-protected tunnels: A-B, A-C, and
 B-C.  Also assume that the traffic selectors for each tunnel specify
 ANY for protocol and port fields and IP source/destination address
 ranges that encompass the address range for the systems behind the
 security gateways serving each site.  This would allow a host at site
 B to send an ICMP Destination Unreachable message to any host at site
 A, that declares all hosts on the net at site C to be unreachable.
 This is a very efficient DoS attack that could have been prevented if
 the ICMP error messages were subjected to the checks that IPsec
 provides, if the SPD is suitably configured, as described in Section
 6.2.

12. IANA Considerations

 The IANA has assigned the value (3) for the asn1-modules registry and
 has assigned the object identifier 1.3.6.1.5.8.3.1 for the SPD
 module.  See Appendix C, "ASN.1 for an SPD Entry".

13. Differences from RFC 2401

 This architecture document differs substantially from RFC 2401
 [RFC2401] in detail and in organization, but the fundamental notions
 are unchanged.
 o The processing model has been revised to address new IPsec
   scenarios, improve performance, and simplify implementation.  This
   includes a separation between forwarding (routing) and SPD

Kent & Seo Standards Track [Page 72] RFC 4301 Security Architecture for IP December 2005

   selection, several SPD changes, and the addition of an outbound SPD
   cache and an inbound SPD cache for bypassed or discarded traffic.
   There is also a new database, the Peer Authorization Database
   (PAD).  This provides a link between an SA management protocol
   (such as IKE) and the SPD.
 o There is no longer a requirement to support nested SAs or "SA
   bundles".  Instead this functionality can be achieved through SPD
   and forwarding table configuration.  An example of a configuration
   has been added in Appendix E.
 o SPD entries were redefined to provide more flexibility.  Each SPD
   entry now consists of 1 to N sets of selectors, where each selector
   set contains one protocol and a "list of ranges" can now be
   specified for the Local IP address, Remote IP address, and whatever
   fields (if any) are associated with the Next Layer Protocol (Local
   Port, Remote Port, ICMP message type and code, and Mobility Header
   type).  An individual value for a selector is represented via a
   trivial range and ANY is represented via a range than spans all
   values for the selector.  An example of an ASN.1 description is
   included in Appendix C.
 o TOS (IPv4) and Traffic Class (IPv6) have been replaced by DSCP and
   ECN.  The tunnel section has been updated to explain how to handle
   DSCP and ECN bits.
 o For tunnel mode SAs, an SG, BITS, or BITW implementation is now
   allowed to fragment packets before applying IPsec.  This applies
   only to IPv4.  For IPv6 packets, only the originator is allowed to
   fragment them.
 o When security is desired between two intermediate systems along a
   path or between an intermediate system and an end system, transport
   mode may now be used between security gateways and between a
   security gateway and a host.
 o This document clarifies that for all traffic that crosses the IPsec
   boundary, including IPsec management traffic, the SPD or associated
   caches must be consulted.
 o This document defines how to handle the situation of a security
   gateway with multiple subscribers requiring separate IPsec
   contexts.
 o A definition of reserved SPIs has been added.

Kent & Seo Standards Track [Page 73] RFC 4301 Security Architecture for IP December 2005

 o Text has been added explaining why ALL IP packets must be checked
   -- IPsec includes minimal firewall functionality to support access
   control at the IP layer.
 o The tunnel section has been updated to clarify how to handle the IP
   options field and IPv6 extension headers when constructing the
   outer header.
 o SA mapping for inbound traffic has been updated to be consistent
   with the changes made in AH and ESP for support of unicast and
   multicast SAs.
 o Guidance has been added regarding how to handle the covert channel
   created in tunnel mode by copying the DSCP value to outer header.
 o Support for AH in both IPv4 and IPv6 is no longer required.
 o PMTU handling has been updated.  The appendix on
   PMTU/DF/Fragmentation has been deleted.
 o Three approaches have been added for handling plaintext fragments
   on the protected side of the IPsec boundary.  Appendix D documents
   the rationale behind them.
 o Added revised text describing how to derive selector values for SAs
   (from the SPD entry or from the packet, etc.)
 o Added a new table describing the relationship between selector
   values in an SPD entry, the PFP flag, and resulting selector values
   in the corresponding SAD entry.
 o Added Appendix B to describe decorrelation.
 o Added text describing how to handle an outbound packet that must be
   discarded.
 o Added text describing how to handle a DISCARDED inbound packet,
   i.e., one that does not match the SA upon which it arrived.
 o IPv6 mobility header has been added as a possible Next Layer
   Protocol.  IPv6 Mobility Header message type has been added as a
   selector.
 o ICMP message type and code have been added as selectors.
 o The selector "data sensitivity level" has been removed to simplify
   things.

Kent & Seo Standards Track [Page 74] RFC 4301 Security Architecture for IP December 2005

 o Updated text describing handling ICMP error messages.  The appendix
   on "Categorization of ICMP Messages" has been deleted.
 o The text for the selector name has been updated and clarified.
 o The "Next Layer Protocol" has been further explained and a default
   list of protocols to skip when looking for the Next Layer Protocol
   has been added.
 o The text has been amended to say that this document assumes use of
   IKEv2 or an SA management protocol with comparable features.
 o Text has been added clarifying the algorithm for mapping inbound
   IPsec datagrams to SAs in the presence of multicast SAs.
 o The appendix "Sequence Space Window Code Example" has been removed.
 o With respect to IP addresses and ports, the terms "Local" and
   "Remote" are used for policy rules (replacing source and
   destination).  "Local" refers to the entity being protected by an
   IPsec implementation, i.e., the "source" address/port of outbound
   packets or the "destination" address/port of inbound packets.
   "Remote" refers to a peer entity or peer entities.  The terms
   "source" and "destination" are still used for packet header fields.

14. Acknowledgements

 The authors would like to acknowledge the contributions of Ran
 Atkinson, who played a critical role in initial IPsec activities, and
 who authored the first series of IPsec standards: RFCs 1825-1827; and
 Charlie Lynn, who made significant contributions to the second series
 of IPsec standards (RFCs 2401, 2402, and 2406) and to the current
 versions, especially with regard to IPv6 issues.  The authors also
 would like to thank the members of the IPsec and MSEC working groups
 who have contributed to the development of this protocol
 specification.

Kent & Seo Standards Track [Page 75] RFC 4301 Security Architecture for IP December 2005

Appendix A: Glossary

 This section provides definitions for several key terms that are
 employed in this document.  Other documents provide additional
 definitions and background information relevant to this technology,
 e.g., [Shi00], [VK83], and [HA94].  Included in this glossary are
 generic security service and security mechanism terms, plus
 IPsec-specific terms.
 Access Control
    A security service that prevents unauthorized use of a resource,
    including the prevention of use of a resource in an unauthorized
    manner.  In the IPsec context, the resource to which access is
    being controlled is often:
             o for a host, computing cycles or data
             o for a security gateway, a network behind the gateway
               or bandwidth on that network.
 Anti-replay
    See "Integrity" below.
 Authentication
    Used informally to refer to the combination of two nominally
    distinct security services, data origin authentication and
    connectionless integrity.  See the definitions below for each of
    these services.
 Availability
    When viewed as a security service, addresses the security concerns
    engendered by attacks against networks that deny or degrade
    service.  For example, in the IPsec context, the use of
    anti-replay mechanisms in AH and ESP support availability.
 Confidentiality
    The security service that protects data from unauthorized
    disclosure.  The primary confidentiality concern in most instances
    is unauthorized disclosure of application-level data, but
    disclosure of the external characteristics of communication also
    can be a concern in some circumstances.  Traffic flow
    confidentiality is the service that addresses this latter concern
    by concealing source and destination addresses, message length, or
    frequency of communication.  In the IPsec context, using ESP in
    tunnel mode, especially at a security gateway, can provide some
    level of traffic flow confidentiality. (See also "Traffic
    Analysis" below.)

Kent & Seo Standards Track [Page 76] RFC 4301 Security Architecture for IP December 2005

 Data Origin Authentication
    A security service that verifies the identity of the claimed
    source of data.  This service is usually bundled with
    connectionless integrity service.
 Encryption
    A security mechanism used to transform data from an intelligible
    form (plaintext) into an unintelligible form (ciphertext), to
    provide confidentiality.  The inverse transformation process is
    designated "decryption".  Often the term "encryption" is used to
    generically refer to both processes.
 Integrity
    A security service that ensures that modifications to data are
    detectable.  Integrity comes in various flavors to match
    application requirements.  IPsec supports two forms of integrity:
    connectionless and a form of partial sequence integrity.
    Connectionless integrity is a service that detects modification of
    an individual IP datagram, without regard to the ordering of the
    datagram in a stream of traffic.  The form of partial sequence
    integrity offered in IPsec is referred to as anti-replay
    integrity, and it detects arrival of duplicate IP datagrams
    (within a constrained window).  This is in contrast to
    connection-oriented integrity, which imposes more stringent
    sequencing requirements on traffic, e.g., to be able to detect
    lost or re-ordered messages.  Although authentication and
    integrity services often are cited separately, in practice they
    are intimately connected and almost always offered in tandem.
 Protected vs. Unprotected
    "Protected" refers to the systems or interfaces that are inside
    the IPsec protection boundary, and "unprotected" refers to the
    systems or interfaces that are outside the IPsec protection
    boundary.  IPsec provides a boundary through which traffic passes.
    There is an asymmetry to this barrier, which is reflected in the
    processing model.  Outbound data, if not discarded or bypassed, is
    protected via the application of AH or ESP and the addition of the
    corresponding headers.  Inbound data, if not discarded or
    bypassed, is processed via the removal of AH or ESP headers.  In
    this document, inbound traffic enters an IPsec implementation from
    the "unprotected" interface.  Outbound traffic enters the
    implementation via the "protected" interface, or is internally
    generated 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.  The protected interface may be

Kent & Seo Standards Track [Page 77] RFC 4301 Security Architecture for IP December 2005

    internal, e.g., in a host implementation of IPsec.  The protected
    interface may link to a socket layer interface presented by the
    OS.
 Security Association (SA)
    A simplex (uni-directional) logical connection, created for
    security purposes.  All traffic traversing an SA is provided the
    same security processing.  In IPsec, an SA is an Internet-layer
    abstraction implemented through the use of AH or ESP.  State data
    associated with an SA is represented in the SA Database (SAD).
 Security Gateway
    An intermediate system that acts as the communications interface
    between two networks.  The set of hosts (and networks) on the
    external side of the security gateway is termed unprotected (they
    are generally at least less protected than those "behind" the SG),
    while the networks and hosts on the internal side are viewed as
    protected.  The internal subnets and hosts served by a security
    gateway are presumed to be trusted by virtue of sharing a common,
    local, security administration.  In the IPsec context, a security
    gateway is a point at which AH and/or ESP is implemented in order
    to serve a set of internal hosts, providing security services for
    these hosts when they communicate with external hosts also
    employing IPsec (either directly or via another security gateway).
 Security Parameters Index (SPI)
    An arbitrary 32-bit value that is used by a receiver to identify
    the SA to which an incoming packet should be bound.  For a unicast
    SA, the SPI can be used by itself to specify an SA, or it may be
    used in conjunction with the IPsec protocol type.  Additional IP
    address information is used to identify multicast SAs.  The SPI is
    carried in AH and ESP protocols to enable the receiving system to
    select the SA under which a received packet will be processed.  An
    SPI has only local significance, as defined by the creator of the
    SA (usually the receiver of the packet carrying the SPI); thus an
    SPI is generally viewed as an opaque bit string.  However, the
    creator of an SA may choose to interpret the bits in an SPI to
    facilitate local processing.
 Traffic Analysis
    The analysis of network traffic flow for the purpose of deducing
    information that is useful to an adversary.  Examples of such
    information are frequency of transmission, the identities of the
    conversing parties, sizes of packets, and flow identifiers
    [Sch94].

Kent & Seo Standards Track [Page 78] RFC 4301 Security Architecture for IP December 2005

Appendix B: Decorrelation

 This appendix is based on work done for caching of policies in the IP
 Security Policy Working Group by Luis Sanchez, Matt Condell, and John
 Zao.
 Two SPD entries are correlated if there is a non-null intersection
 between the values of corresponding selectors in each entry.  Caching
 correlated SPD entries can lead to incorrect policy enforcement.  A
 solution to this problem, which still allows for caching, is to
 remove the ambiguities by decorrelating the entries.  That is, the
 SPD entries must be rewritten so that for every pair of entries there
 exists a selector for which there is a null intersection between the
 values in both of the entries.  Once the entries are decorrelated,
 there is no longer any ordering requirement on them, since only one
 entry will match any lookup.  The next section describes
 decorrelation in more detail and presents an algorithm that may be
 used to implement decorrelation.

B.1. Decorrelation Algorithm

 The basic decorrelation algorithm takes each entry in a correlated
 SPD and divides it into a set of entries using a tree structure.
 The nodes of the tree are the selectors that may overlap between the
 policies.  At each node, the algorithm creates a branch for each of
 the values of the selector.  It also creates one branch for the
 complement of the union of all selector values.  Policies are then
 formed by traversing the tree from the root to each leaf.  The
 policies at the leaves are compared to the set of already
 decorrelated policy rules.  Each policy at a leaf is either
 completely overridden by a policy in the already decorrelated set and
 is discarded or is decorrelated with all the policies in the
 decorrelated set and is added to it.
 The basic algorithm does not guarantee an optimal set of decorrelated
 entries.  That is, the entries may be broken up into smaller sets
 than is necessary, though they will still provide all the necessary
 policy information.  Some extensions to the basic algorithm are
 described later to improve this and improve the performance of the
 algorithm.
         C   A set of ordered, correlated entries (a correlated SPD).
         Ci  The ith entry in C.
         U   The set of decorrelated entries being built from C.
         Ui  The ith entry in U.
         Sik The kth selection for policy Ci.
         Ai  The action for policy Ci.

Kent & Seo Standards Track [Page 79] RFC 4301 Security Architecture for IP December 2005

 A policy (SPD entry) P may be expressed as a sequence of selector
 values and an action (BYPASS, DISCARD, or PROTECT):
         Ci = Si1 x Si2 x ... x Sik -> Ai
 1) Put C1 in set U as U1
 For each policy Cj (j > 1) in C
 2) If Cj is decorrelated with every entry in U, then add it to U.
 3) If Cj is correlated with one or more entries in U, create a tree
 rooted at the policy Cj that partitions Cj into a set of decorrelated
 entries.  The algorithm starts with a root node where no selectors
 have yet been chosen.
   A) Choose a selector in Cj, Sjn, that has not yet been chosen when
      traversing the tree from the root to this node.  If there are no
      selectors not yet used, continue to the next unfinished branch
      until all branches have been completed.  When the tree is
      completed, go to step D.
      T is the set of entries in U that are correlated with the entry
      at this node.
      The entry at this node is the entry formed by the selector
      values of each of the branches between the root and this node.
      Any selector values that are not yet represented by branches
      assume the corresponding selector value in Cj, since the values
      in Cj represent the maximum value for each selector.
   B) Add a branch to the tree for each value of the selector Sjn that
      appears in any of the entries in T.  (If the value is a superset
      of the value of Sjn in Cj, then use the value in Cj, since that
      value represents the universal set.)  Also add a branch for the
      complement of the union of all the values of the selector Sjn
      in T.  When taking the complement, remember that the universal
      set is the value of Sjn in Cj.  A branch need not be created
      for the null set.
   C) Repeat A and B until the tree is completed.
   D) The entry to each leaf now represents an entry that is a subset
      of Cj.  The entries at the leaves completely partition Cj in
      such a way that each entry is either completely overridden by
      an entry in U, or is decorrelated with the entries in U.
      Add all the decorrelated entries at the leaves of the tree to U.

Kent & Seo Standards Track [Page 80] RFC 4301 Security Architecture for IP December 2005

 4) Get next Cj and go to 2.
 5) When all entries in C have been processed, then U will contain an
 decorrelated version of C.
 There are several optimizations that can be made to this algorithm.
 A few of them are presented here.
 It is possible to optimize, or at least improve, the amount of
 branching that occurs by carefully choosing the order of the
 selectors used for the next branch.  For example, if a selector Sjn
 can be chosen so that all the values for that selector in T are equal
 to or a superset of the value of Sjn in Cj, then only a single branch
 needs to be created (since the complement will be null).
 Branches of the tree do not have to proceed with the entire
 decorrelation algorithm.  For example, if a node represents an entry
 that is decorrelated with all the entries in U, then there is no
 reason to continue decorrelating that branch.  Also, if a branch is
 completely overridden by an entry in U, then there is no reason to
 continue decorrelating the branch.
 An additional optimization is to check to see if a branch is
 overridden by one of the CORRELATED entries in set C that has already
 been decorrelated.  That is, if the branch is part of decorrelating
 Cj, then check to see if it was overridden by an entry Cm, m < j.
 This is a valid check, since all the entries Cm are already expressed
 in U.
 Along with checking if an entry is already decorrelated in step 2,
 check if Cj is overridden by any entry in U.  If it is, skip it since
 it is not relevant.  An entry x is overridden by another entry y if
 every selector in x is equal to or a subset of the corresponding
 selector in entry y.

Kent & Seo Standards Track [Page 81] RFC 4301 Security Architecture for IP December 2005

Appendix C: ASN.1 for an SPD Entry

 This appendix is included as an additional way to describe SPD
 entries, as defined in Section 4.4.1.  It uses ASN.1 syntax that has
 been successfully compiled.  This syntax is merely illustrative and
 need not be employed in an implementation to achieve compliance.  The
 SPD description in Section 4.4.1 is normative.
 SPDModule
  {iso(1) org (3) dod (6) internet (1) security (5) mechanisms (5)
   ipsec (8) asn1-modules (3) spd-module (1) }
     DEFINITIONS IMPLICIT TAGS ::=
     BEGIN
     IMPORTS
         RDNSequence FROM PKIX1Explicit88
           { iso(1) identified-organization(3)
             dod(6) internet(1) security(5) mechanisms(5) pkix(7)
             id-mod(0) id-pkix1-explicit(18) } ;
  1. - An SPD is a list of policies in decreasing order of preference

SPD ::= SEQUENCE OF SPDEntry

     SPDEntry ::= CHOICE {
         iPsecEntry       IPsecEntry,               -- PROTECT traffic
         bypassOrDiscard  [0] BypassOrDiscardEntry } -- DISCARD/BYPASS
     IPsecEntry ::= SEQUENCE {       -- Each entry consists of
         name        NameSets OPTIONAL,
         pFPs        PacketFlags,    -- Populate from packet flags
                            -- Applies to ALL of the corresponding
                            -- traffic selectors in the SelectorLists
         condition   SelectorLists,  -- Policy "condition"
         processing  Processing      -- Policy "action"
         }
     BypassOrDiscardEntry ::= SEQUENCE {
         bypass      BOOLEAN,        -- TRUE BYPASS, FALSE DISCARD
         condition   InOutBound }
     InOutBound ::= CHOICE {
         outbound    [0] SelectorLists,
         inbound     [1] SelectorLists,
         bothways    [2] BothWays }

Kent & Seo Standards Track [Page 82] RFC 4301 Security Architecture for IP December 2005

     BothWays ::= SEQUENCE {
         inbound     SelectorLists,
         outbound    SelectorLists }
     NameSets ::= SEQUENCE {
         passed      SET OF Names-R,  -- Matched to IKE ID by
                                      -- responder
         local       SET OF Names-I } -- Used internally by IKE
                                      -- initiator
     Names-R ::= CHOICE {                   -- IKEv2 IDs
         dName       RDNSequence,           -- ID_DER_ASN1_DN
         fqdn        FQDN,                  -- ID_FQDN
         rfc822      [0] RFC822Name,        -- ID_RFC822_ADDR
         keyID       OCTET STRING }         -- KEY_ID
     Names-I ::= OCTET STRING       -- Used internally by IKE
                                    -- initiator
     FQDN ::= IA5String
     RFC822Name ::= IA5String
     PacketFlags ::= BIT STRING {
                 -- if set, take selector value from packet
                 -- establishing SA
                 -- else use value in SPD entry
         localAddr  (0),
         remoteAddr (1),
         protocol   (2),
         localPort  (3),
         remotePort (4)  }
     SelectorLists ::= SET OF SelectorList
     SelectorList ::= SEQUENCE {
         localAddr   AddrList,
         remoteAddr  AddrList,
         protocol    ProtocolChoice }
     Processing ::= SEQUENCE {
         extSeqNum   BOOLEAN, -- TRUE 64 bit counter, FALSE 32 bit
         seqOverflow BOOLEAN, -- TRUE rekey, FALSE terminate & audit
         fragCheck   BOOLEAN, -- TRUE stateful fragment checking,
                              -- FALSE no stateful fragment checking
         lifetime    SALifetime,
         spi         ManualSPI,
         algorithms  ProcessingAlgs,

Kent & Seo Standards Track [Page 83] RFC 4301 Security Architecture for IP December 2005

         tunnel      TunnelOptions OPTIONAL } -- if absent, use
                                              -- transport mode
     SALifetime ::= SEQUENCE {
         seconds   [0] INTEGER OPTIONAL,
         bytes     [1] INTEGER OPTIONAL }
     ManualSPI ::= SEQUENCE {
         spi     INTEGER,
         keys    KeyIDs }
     KeyIDs ::= SEQUENCE OF OCTET STRING
     ProcessingAlgs ::= CHOICE {
         ah          [0] IntegrityAlgs,  -- AH
         esp         [1] ESPAlgs}        -- ESP
     ESPAlgs ::= CHOICE {
         integrity       [0] IntegrityAlgs,       -- integrity only
         confidentiality [1] ConfidentialityAlgs, -- confidentiality
                                                  -- only
         both            [2] IntegrityConfidentialityAlgs,
         combined        [3] CombinedModeAlgs }
     IntegrityConfidentialityAlgs ::= SEQUENCE {
         integrity       IntegrityAlgs,
         confidentiality ConfidentialityAlgs }
  1. - Integrity Algorithms, ordered by decreasing preference

IntegrityAlgs ::= SEQUENCE OF IntegrityAlg

  1. - Confidentiality Algorithms, ordered by decreasing preference

ConfidentialityAlgs ::= SEQUENCE OF ConfidentialityAlg

  1. - Integrity Algorithms

IntegrityAlg ::= SEQUENCE {

         algorithm   IntegrityAlgType,
         parameters  ANY -- DEFINED BY algorithm -- OPTIONAL }
     IntegrityAlgType ::= INTEGER {
         none              (0),
         auth-HMAC-MD5-96  (1),
         auth-HMAC-SHA1-96 (2),
         auth-DES-MAC      (3),
         auth-KPDK-MD5     (4),
         auth-AES-XCBC-96  (5)
     --  tbd (6..65535)
         }

Kent & Seo Standards Track [Page 84] RFC 4301 Security Architecture for IP December 2005

  1. - Confidentiality Algorithms

ConfidentialityAlg ::= SEQUENCE {

         algorithm   ConfidentialityAlgType,
         parameters  ANY -- DEFINED BY algorithm -- OPTIONAL }
     ConfidentialityAlgType ::= INTEGER {
         encr-DES-IV64   (1),
         encr-DES        (2),
         encr-3DES       (3),
         encr-RC5        (4),
         encr-IDEA       (5),
         encr-CAST       (6),
         encr-BLOWFISH   (7),
         encr-3IDEA      (8),
         encr-DES-IV32   (9),
         encr-RC4       (10),
         encr-NULL      (11),
         encr-AES-CBC   (12),
         encr-AES-CTR   (13)
     --  tbd (14..65535)
         }
     CombinedModeAlgs ::= SEQUENCE OF CombinedModeAlg
     CombinedModeAlg ::= SEQUENCE {
         algorithm   CombinedModeType,
         parameters  ANY -- DEFINED BY algorithm} -- defined outside
                                  -- of this document for AES modes.
     CombinedModeType ::= INTEGER {
         comb-AES-CCM    (1),
         comb-AES-GCM    (2)
     --  tbd (3..65535)
         }
     TunnelOptions ::= SEQUENCE {
         dscp        DSCP,
         ecn         BOOLEAN,    -- TRUE Copy CE to inner header
         df          DF,
         addresses   TunnelAddresses }
     TunnelAddresses ::= CHOICE {
         ipv4        IPv4Pair,
         ipv6        [0] IPv6Pair }
     IPv4Pair ::= SEQUENCE {
         local       OCTET STRING (SIZE(4)),
         remote      OCTET STRING (SIZE(4)) }

Kent & Seo Standards Track [Page 85] RFC 4301 Security Architecture for IP December 2005

     IPv6Pair ::= SEQUENCE {
         local       OCTET STRING (SIZE(16)),
         remote      OCTET STRING (SIZE(16)) }
     DSCP ::= SEQUENCE {
         copy      BOOLEAN, -- TRUE copy from inner header
                            -- FALSE do not copy
         mapping   OCTET STRING OPTIONAL} -- points to table
                                          -- if no copy
     DF ::= INTEGER {
         clear   (0),
         set     (1),
         copy    (2) }
     ProtocolChoice::= CHOICE {
         anyProt  AnyProtocol,              -- for ANY protocol
         noNext   [0] NoNextLayerProtocol,  -- has no next layer
                                            -- items
         oneNext  [1] OneNextLayerProtocol, -- has one next layer
                                            -- item
         twoNext  [2] TwoNextLayerProtocol, -- has two next layer
                                            -- items
         fragment FragmentNoNext }          -- has no next layer
                                            -- info
     AnyProtocol ::= SEQUENCE {
         id          INTEGER (0),    -- ANY protocol
         nextLayer   AnyNextLayers }
     AnyNextLayers ::= SEQUENCE {      -- with either
         first       AnyNextLayer,     -- ANY next layer selector
         second      AnyNextLayer }    -- ANY next layer selector
     NoNextLayerProtocol ::= INTEGER (2..254)
     FragmentNoNext ::= INTEGER (44)   -- Fragment identifier
     OneNextLayerProtocol ::= SEQUENCE {
         id          INTEGER (1..254),   -- ICMP, MH, ICMPv6
         nextLayer   NextLayerChoice }   -- ICMP Type*256+Code
                                         -- MH   Type*256
     TwoNextLayerProtocol ::= SEQUENCE {
         id          INTEGER (2..254),   -- Protocol
         local       NextLayerChoice,    -- Local and
         remote      NextLayerChoice }   -- Remote ports

Kent & Seo Standards Track [Page 86] RFC 4301 Security Architecture for IP December 2005

     NextLayerChoice ::= CHOICE {
         any         AnyNextLayer,
         opaque      [0] OpaqueNextLayer,
         range       [1] NextLayerRange }
  1. - Representation of ANY in next layer field

AnyNextLayer ::= SEQUENCE {

         start       INTEGER (0),
         end         INTEGER (65535) }
  1. - Representation of OPAQUE in next layer field.
  2. - Matches IKE convention

OpaqueNextLayer ::= SEQUENCE {

         start       INTEGER (65535),
         end         INTEGER (0) }
  1. - Range for a next layer field

NextLayerRange ::= SEQUENCE {

         start       INTEGER (0..65535),
         end         INTEGER (0..65535) }
  1. - List of IP addresses

AddrList ::= SEQUENCE {

         v4List      IPv4List OPTIONAL,
         v6List      [0] IPv6List OPTIONAL }
  1. - IPv4 address representations

IPv4List ::= SEQUENCE OF IPv4Range

     IPv4Range ::= SEQUENCE {    -- close, but not quite right ...
         ipv4Start   OCTET STRING (SIZE (4)),
         ipv4End     OCTET STRING (SIZE (4)) }
  1. - IPv6 address representations

IPv6List ::= SEQUENCE OF IPv6Range

     IPv6Range ::= SEQUENCE {    -- close, but not quite right ...
         ipv6Start   OCTET STRING (SIZE (16)),
         ipv6End     OCTET STRING (SIZE (16)) }
     END

Kent & Seo Standards Track [Page 87] RFC 4301 Security Architecture for IP December 2005

Appendix D: Fragment Handling Rationale

 There are three issues that must be resolved regarding processing of
 (plaintext) fragments in IPsec:
  1. mapping a non-initial, outbound fragment to the right SA

(or finding the right SPD entry)

  1. verifying that a received, non-initial fragment is authorized

for the SA via which it is received

  1. mapping outbound and inbound non-initial fragments to the

right SPD/cache entry, for BYPASS/DISCARD traffic

 The first and third issues arise because we need a deterministic
 algorithm for mapping traffic to SAs (and SPD/cache entries).  All
 three issues are important because we want to make sure that
 non-initial fragments that cross the IPsec boundary do not cause the
 access control policies in place at the receiver (or transmitter) to
 be violated.

D.1. Transport Mode and Fragments

 First, we note that transport mode SAs have been defined to not carry
 fragments.  This is a carryover from RFC 2401, where transport mode
 SAs always terminated at endpoints.  This is a fundamental
 requirement because, in the worst case, an IPv4 fragment to which
 IPsec was applied might then be fragmented (as a ciphertext packet),
 en route to the destination.  IP fragment reassembly procedures at
 the IPsec receiver would not be able to distinguish between pre-IPsec
 fragments and fragments created after IPsec processing.
 For IPv6, only the sender is allowed to fragment a packet.  As for
 IPv4, an IPsec implementation is allowed to fragment tunnel mode
 packets after IPsec processing, because it is the sender relative to
 the (outer) tunnel header.  However, unlike IPv4, it would be
 feasible to carry a plaintext fragment on a transport mode SA,
 because the fragment header in IPv6 would appear after the AH or ESP
 header, and thus would not cause confusion at the receiver with
 respect to reassembly.  Specifically, the receiver would not attempt
 reassembly for the fragment until after IPsec processing.  To keep
 things simple, this specification prohibits carriage of fragments on
 transport mode SAs for IPv6 traffic.
 When only end systems used transport mode SAs, the prohibition on
 carriage of fragments was not a problem, since we assumed that the
 end system could be configured to not offer a fragment to IPsec.  For
 a native host implementation, this seems reasonable, and, as someone
 already noted, RFC 2401 warned that a BITS implementation might have
 to reassemble fragments before performing an SA lookup.  (It would

Kent & Seo Standards Track [Page 88] RFC 4301 Security Architecture for IP December 2005

 then apply AH or ESP and could re-fragment the packet after IPsec
 processing.) Because a BITS implementation is assumed to be able to
 have access to all traffic emanating from its host, even if the host
 has multiple interfaces, this was deemed a reasonable mandate.
 In this specification, it is acceptable to use transport mode in
 cases where the IPsec implementation is not the ultimate destination,
 e.g., between two SGs.  In principle, this creates a new opportunity
 for outbound, plaintext fragments to be mapped to a transport mode SA
 for IPsec processing.  However, in these new contexts in which a
 transport mode SA is now approved for use, it seems likely that we
 can continue to prohibit transmission of fragments, as seen by IPsec,
 i.e., packets that have an "outer header" with a non-zero fragment
 offset field.  For example, in an IP overlay network, packets being
 sent over transport mode SAs are IP-in-IP tunneled and thus have the
 necessary inner header to accommodate fragmentation prior to IPsec
 processing.  When carried via a transport mode SA, IPsec would not
 examine the inner IP header for such traffic, and thus would not
 consider the packet to be a fragment.

D.2. Tunnel Mode and Fragments

 For tunnel mode SAs, it has always been the case that outbound
 fragments might arrive for processing at an IPsec implementation.
 The need to accommodate fragmented outbound packets can pose a
 problem because a non-initial fragment generally will not contain the
 port fields associated with a next layer protocol such as TCP, UDP,
 or SCTP.  Thus, depending on the SPD configuration for a given IPsec
 implementation, plaintext fragments might or might not pose a
 problem.
 For example, if the SPD requires that all traffic between two address
 ranges is offered IPsec protection (no BYPASS or DISCARD SPD entries
 apply to this address range), then it should be easy to carry
 non-initial fragments on the SA defined for this address range, since
 the SPD entry implies an intent to carry ALL traffic between the
 address ranges.  But, if there are multiple SPD entries that could
 match a fragment, and if these entries reference different subsets of
 port fields (vs. ANY), then it is not possible to map an outbound
 non-initial fragment to the right entry, unambiguously. (If we choose
 to allow carriage of fragments on transport mode SAs for IPv6, the
 problems arises in that context as well.)
 This problem largely, though not exclusively, motivated the
 definition of OPAQUE as a selector value for port fields in RFC 2401.
 The other motivation for OPAQUE is the observation that port fields
 might not be accessible due to the prior application of IPsec.  For
 example, if a host applied IPsec to its traffic and that traffic

Kent & Seo Standards Track [Page 89] RFC 4301 Security Architecture for IP December 2005

 arrived at an SG, these fields would be encrypted.  The algorithm
 specified for locating the "next layer protocol" described in RFC
 2401 also motivated use of OPAQUE to accommodate an encrypted next
 layer protocol field in such circumstances.  Nonetheless, the primary
 use of the OPAQUE value was to match traffic selector fields in
 packets that did not contain port fields (non-initial fragments), or
 packets in which the port fields were already encrypted (as a result
 of nested application of IPsec).  RFC 2401 was ambiguous in
 discussing the use of OPAQUE vs. ANY, suggesting in some places that
 ANY might be an alternative to OPAQUE.
 We gain additional access control capability by defining both ANY and
 OPAQUE values.  OPAQUE can be defined to match only fields that are
 not accessible.  We could define ANY as the complement of OPAQUE,
 i.e., it would match all values but only for accessible port fields.
 We have therefore simplified the procedure employed to locate the
 next layer protocol in this document, so that we treat ESP and AH as
 next layer protocols.  As a result, the notion of an encrypted next
 layer protocol field has vanished, and there is also no need to worry
 about encrypted port fields either.  And accordingly, OPAQUE will be
 applicable only to non-initial fragments.
 Since we have adopted the definitions above for ANY and OPAQUE, we
 need to clarify how these values work when the specified protocol
 does not have port fields, and when ANY is used for the protocol
 selector.  Accordingly, if a specific protocol value is used as a
 selector, and if that protocol has no port fields, then the port
 field selectors are to be ignored and ANY MUST be specified as the
 value for the port fields. (In this context, ICMP TYPE and CODE
 values are lumped together as a single port field (for IKEv2
 negotiation), as is the IPv6 Mobility Header TYPE value.) If the
 protocol selector is ANY, then this should be treated as equivalent
 to specifying a protocol for which no port fields are defined, and
 thus the port selectors should be ignored, and MUST be set to ANY.

D.3. The Problem of Non-Initial Fragments

 For an SG implementation, it is obvious that fragments might arrive
 from end systems behind the SG.  A BITW implementation also may
 encounter fragments from a host or gateway behind it. (As noted
 earlier, native host implementations and BITS implementations
 probably can avoid the problems described below.) In the worst case,
 fragments from a packet might arrive at distinct BITW or SG
 instantiations and thus preclude reassembly as a solution option.
 Hence, in RFC 2401 we adopted a general requirement that fragments
 must be accommodated in tunnel mode for all implementations. However,

Kent & Seo Standards Track [Page 90] RFC 4301 Security Architecture for IP December 2005

 RFC 2401 did not provide a perfect solution.  The use of OPAQUE as a
 selector value for port fields (a SHOULD in RFC 2401) allowed an SA
 to carry non-initial fragments.
 Using the features defined in RFC 2401, if one defined an SA between
 two IPsec (SG or BITW) implementations using the OPAQUE value for
 both port fields, then all non-initial fragments matching the
 source/destination (S/D) address and protocol values for the SA would
 be mapped to that SA.  Initial fragments would NOT map to this SA, if
 we adopt a strict definition of OPAQUE.  However, RFC 2401 did not
 provide detailed guidance on this and thus it may not have been
 apparent that use of this feature would essentially create a
 "non-initial fragment only" SA.
 In the course of discussing the "fragment-only" SA approach, it was
 noted that some subtle problems, problems not considered in RFC 2401,
 would have to be avoided.  For example, an SA of this sort must be
 configured to offer the "highest quality" security services for any
 traffic between the indicated S/D addresses (for the specified
 protocol).  This is necessary to ensure that any traffic captured by
 the fragment-only SA is not offered degraded security relative to
 what it would have been offered if the packet were not fragmented.  A
 possible problem here is that we may not be able to identify the
 "highest quality" security services defined for use between two IPsec
 implementation, since the choice of security protocols, options, and
 algorithms is a lattice, not a totally ordered set. (We might safely
 say that BYPASS < AH < ESP w/integrity, but it gets complicated if we
 have multiple ESP encryption or integrity algorithm options.) So, one
 has to impose a total ordering on these security parameters to make
 this work, but this can be done locally.
 However, this conservative strategy has a possible performance
 downside.  If most traffic traversing an IPsec implementation for a
 given S/D address pair (and specified protocol) is bypassed, then a
 fragment-only SA for that address pair might cause a dramatic
 increase in the volume of traffic afforded crypto processing.  If the
 crypto implementation cannot support high traffic rates, this could
 cause problems. (An IPsec implementation that is capable of line rate
 or near line rate crypto performance would not be adversely affected
 by this SA configuration approach.  Nonetheless, the performance
 impact is a potential concern, specific to implementation
 capabilities.)
 Another concern is that non-initial fragments sent over a dedicated
 SA might be used to effect overlapping reassembly attacks, when
 combined with an apparently acceptable initial fragment. (This sort
 of attack assumes creation of bogus fragments and is not a side
 effect of normal fragmentation.) This concern is easily addressed in

Kent & Seo Standards Track [Page 91] RFC 4301 Security Architecture for IP December 2005

 IPv4, by checking the fragment offset value to ensure that no
 non-initial fragments have a small enough offset to overlap port
 fields that should be contained in the initial fragment.  Recall that
 the IPv4 MTU minimum is 576 bytes, and the max IP header length is 60
 bytes, so any ports should be present in the initial fragment.  If we
 require all non-initial fragments to have an offset of, say, 128 or
 greater, just to be on the safe side, this should prevent successful
 attacks of this sort.  If the intent is only to protect against this
 sort of reassembly attack, this check need be implemented only by a
 receiver.
 IPv6 also has a fragment offset, carried in the fragmentation
 extension header.  However, IPv6 extension headers are variable in
 length and there is no analogous max header length value that we can
 use to check non-initial fragments, to reject ones that might be used
 for an attack of the sort noted above.  A receiver would need to
 maintain state analogous to reassembly state, to provide equivalent
 protection.  So, only for IPv4 is it feasible to impose a fragment
 offset check that would reject attacks designed to circumvent port
 field checks by IPsec (or firewalls) when passing non-initial
 fragments.
 Another possible concern is that in some topologies and SPD
 configurations this approach might result in an access control
 surprise.  The notion is that if we create an SA to carry ALL
 (non-initial) fragments, then that SA would carry some traffic that
 might otherwise arrive as plaintext via a separate path, e.g., a path
 monitored by a proxy firewall.  But, this concern arises only if the
 other path allows initial fragments to traverse it without requiring
 reassembly, presumably a bad idea for a proxy firewall.  Nonetheless,
 this does represent a potential problem in some topologies and under
 certain assumptions with respect to SPD and (other) firewall rule
 sets, and administrators need to be warned of this possibility.
 A less serious concern is that non-initial fragments sent over a
 non-initial fragment-only SA might represent a DoS opportunity, in
 that they could be sent when no valid, initial fragment will ever
 arrive.  This might be used to attack hosts behind an SG or BITW
 device.  However, the incremental risk posed by this sort of attack,
 which can be mounted only by hosts behind an SG or BITW device, seems
 small.
 If we interpret the ANY selector value as encompassing OPAQUE, then a
 single SA with ANY values for both port fields would be able to
 accommodate all traffic matching the S/D address and protocol traffic
 selectors, an alternative to using the OPAQUE value.  But, using ANY

Kent & Seo Standards Track [Page 92] RFC 4301 Security Architecture for IP December 2005

 here precludes multiple, distinct SAs between the same IPsec
 implementations for the same address pairs and protocol.  So, it is
 not an exactly equivalent alternative.
 Fundamentally, fragment handling problems arise only when more than
 one SA is defined with the same S/D address and protocol selector
 values, but with different port field selector values.

D.4. BYPASS/DISCARD Traffic

 We also have to address the non-initial fragment processing issue for
 BYPASS/DISCARD entries, independent of SA processing.  This is
 largely a local matter for two reasons:
         1) We have no means for coordinating SPD entries for such
            traffic between IPsec implementations since IKE is not
            invoked.
         2) Many of these entries refer to traffic that is NOT
            directed to or received from a location that is using
            IPsec.  So there is no peer IPsec implementation with
            which to coordinate via any means.
 However, this document should provide guidance here, consistent with
 our goal of offering a well-defined, access control function for all
 traffic, relative to the IPsec boundary.  To that end, this document
 says that implementations MUST support fragment reassembly for
 BYPASS/DISCARD traffic when port fields are specified.  An
 implementation also MUST permit a user or administrator to accept
 such traffic or reject such traffic using the SPD conventions
 described in Section 4.4.1.  The concern is that BYPASS of a
 cleartext, non-initial fragment arriving at an IPsec implementation
 could undermine the security afforded IPsec-protected traffic
 directed to the same destination.  For example, consider an IPsec
 implementation configured with an SPD entry that calls for
 IPsec-protection of traffic between a specific source/destination
 address pair, and for a specific protocol and destination port, e.g.,
 TCP traffic on port 23 (Telnet).  Assume that the implementation also
 allows BYPASS of traffic from the same source/destination address
 pair and protocol, but for a different destination port, e.g., port
 119 (NNTP).  An attacker could send a non-initial fragment (with a
 forged source address) that, if bypassed, could overlap with
 IPsec-protected traffic from the same source and thus violate the
 integrity of the IPsec-protected traffic.  Requiring stateful
 fragment checking for BYPASS entries with non-trivial port ranges
 prevents attacks of this sort.

Kent & Seo Standards Track [Page 93] RFC 4301 Security Architecture for IP December 2005

D.5. Just say no to ports?

 It has been suggested that we could avoid the problems described
 above by not allowing port field selectors to be used in tunnel mode.
 But the discussion above shows this to be an unnecessarily stringent
 approach, i.e., since no problems arise for the native OS and BITS
 implementations.  Moreover, some WG members have described scenarios
 where use of tunnel mode SAs with (non-trivial) port field selectors
 is appropriate.  So the challenge is defining a strategy that can
 deal with this problem in BITW and SG contexts.  Also note that
 BYPASS/DISCARD entries in the SPD that make use of ports pose the
 same problems, irrespective of tunnel vs. transport mode notions.
 Some folks have suggested that a firewall behind an SG or BITW should
 be left to enforce port-level access controls and the effects of
 fragmentation.  However, this seems to be an incongruous suggestion
 in that elsewhere in IPsec (e.g., in IKE payloads) we are concerned
 about firewalls that always discard fragments.  If many firewalls
 don't pass fragments in general, why should we expect them to deal
 with fragments in this case? So, this analysis rejects the suggestion
 of disallowing use of port field selectors with tunnel mode SAs.

D.6. Other Suggested Solutions

 One suggestion is to reassemble fragments at the sending IPsec
 implementation, and thus avoid the problem entirely.  This approach
 is invisible to a receiver and thus could be adopted as a purely
 local implementation option.
 A more sophisticated version of this suggestion calls for
 establishing and maintaining minimal state from each initial fragment
 encountered, to allow non-initial fragments to be matched to the
 right SAs or SPD/cache entries.  This implies an extension to the
 current processing model (and the old one).  The IPsec implementation
 would intercept all fragments; capture Source/Destination IP
 addresses, protocol, packet ID, and port fields from initial
 fragments; and then use this data to map non-initial fragments to SAs
 that require port fields.  If this approach is employed, the receiver
 needs to employ an equivalent scheme, as it too must verify that
 received fragments are consistent with SA selector values.  A
 non-initial fragment that arrives prior to an initial fragment could
 be cached or discarded, awaiting arrival of the corresponding initial
 fragment.
 A downside of both approaches noted above is that they will not
 always work.  When a BITW device or SG is configured in a topology
 that might allow some fragments for a packet to be processed at
 different SGs or BITW devices, then there is no guarantee that all

Kent & Seo Standards Track [Page 94] RFC 4301 Security Architecture for IP December 2005

 fragments will ever arrive at the same IPsec device.  This approach
 also raises possible processing problems.  If the sender caches
 non-initial fragments until the corresponding initial fragment
 arrives, buffering problems might arise, especially at high speeds.
 If the non-initial fragments are discarded rather than cached, there
 is no guarantee that traffic will ever pass, e.g., retransmission
 will result in different packet IDs that cannot be matched with prior
 transmissions.  In any case, housekeeping procedures will be needed
 to decide when to delete the fragment state data, adding some
 complexity to the system.  Nonetheless, this is a viable solution in
 some topologies, and these are likely to be common topologies.
 The Working Group rejected an earlier version of the convention of
 creating an SA to carry only non-initial fragments, something that
 was supported implicitly under the RFC 2401 model via use of OPAQUE
 port fields, but never clearly articulated in RFC 2401.  The
 (rejected) text called for each non-initial fragment to be treated as
 protocol 44 (the IPv6 fragment header protocol ID) by the sender and
 receiver.  This approach has the potential to make IPv4 and IPv6
 fragment handling more uniform, but it does not fundamentally change
 the problem, nor does it address the issue of fragment handling for
 BYPASS/DISCARD traffic.  Given the fragment overlap attack problem
 that IPv6 poses, it does not seem that it is worth the effort to
 adopt this strategy.

D.7. Consistency

 Earlier, the WG agreed to allow an IPsec BITS, BITW, or SG to perform
 fragmentation prior to IPsec processing.  If this fragmentation is
 performed after SA lookup at the sender, there is no "mapping to the
 right SA" problem.  But, the receiver still needs to be able to
 verify that the non-initial fragments are consistent with the SA via
 which they are received.  Since the initial fragment might be lost en
 route, the receiver encounters all of the potential problems noted
 above.  Thus, if we are to be consistent in our decisions, we need to
 say how a receiver will deal with the non-initial fragments that
 arrive.

D.8. Conclusions

 There is no simple, uniform way to handle fragments in all contexts.
 Different approaches work better in different contexts.  Thus, this
 document offers 3 choices -- one MUST and two MAYs.  At some point in
 the future, if the community gains experience with the two MAYs, they
 may become SHOULDs or MUSTs or other approaches may be proposed.

Kent & Seo Standards Track [Page 95] RFC 4301 Security Architecture for IP December 2005

Appendix E: Example of Supporting Nested SAs via SPD and Forwarding

          Table Entries
 This appendix provides an example of how to configure the SPD and
 forwarding tables to support a nested pair of SAs, consistent with
 the new processing model.  For simplicity, this example assumes just
 one SPD-I.
 The goal in this example is to support a transport mode SA from A to
 C, carried over a tunnel mode SA from A to B.  For example, A might
 be a laptop connected to the public Internet, B might be a firewall
 that protects a corporate network, and C might be a server on the
 corporate network that demands end-to-end authentication of A's
 traffic.
       +---+     +---+  +---+
       | A |=====| B |  | C |
       |   |------------|   |
       |   |=====|   |  |   |
       +---+     +---+  +---+
 A's SPD contains entries of the form:
                      Next Layer
    Rule Local Remote Protocol   Action
    ---- ----- ------ ---------- -----------------------
     1     C     A     ESP       BYPASS
     2     A     C     ICMP,ESP  PROTECT(ESP,tunnel,integr+conf)
     3     A     C     ANY       PROTECT(ESP,transport,integr-only)
     4     A     B     ICMP,IKE  BYPASS
 A's unprotected-side forwarding table is set so that outbound packets
 destined for C are looped back to the protected side.  A's
 protected-side forwarding table is set so that inbound ESP packets
 are looped back to the unprotected side.  A's forwarding tables
 contain entries of the form:
    Unprotected-side forwarding table
      Rule Local Remote Protocol Action
      ---- ----- ------ -------- ---------------------------
       1     A     C       ANY   loop back to protected side
       2     A     B       ANY   forward to B

Kent & Seo Standards Track [Page 96] RFC 4301 Security Architecture for IP December 2005

    Protected-side forwarding table
      Rule Local Remote Protocol Action
      ---- ----- ------ -------- -----------------------------
       1     A     C       ESP   loop back to unprotected side
 An outbound TCP packet from A to C would match SPD rule 3 and have
 transport mode ESP applied to it.  The unprotected-side forwarding
 table would then loop back the packet.  The packet is compared
 against SPD-I (see Figure 2), matches SPD rule 1, and so it is
 BYPASSed.  The packet is treated as an outbound packet and compared
 against the SPD for a third time.  This time it matches SPD rule 2,
 so ESP is applied in tunnel mode.  This time the forwarding table
 doesn't loop back the packet, because the outer destination address
 is B, so the packet goes out onto the wire.
 An inbound TCP packet from C to A is wrapped in two ESP headers; the
 outer header (ESP in tunnel mode) shows B as the source, whereas the
 inner header (ESP transport mode) shows C as the source.  Upon
 arrival at A, the packet would be mapped to an SA based on the SPI,
 have the outer header removed, and be decrypted and
 integrity-checked.  Then it would be matched against the SAD
 selectors for this SA, which would specify C as the source and A as
 the destination, derived from SPD rule 2.  The protected-side
 forwarding function would then send it back to the unprotected side
 based on the addresses and the next layer protocol (ESP), indicative
 of nesting.  It is compared against SPD-O (see Figure 3) and found to
 match SPD rule 1, so it is BYPASSed.  The packet is mapped to an SA
 based on the SPI, integrity-checked, and compared against the SAD
 selectors derived from SPD rule 3.  The forwarding function then
 passes it up to the next layer, because it isn't an ESP packet.

Kent & Seo Standards Track [Page 97] RFC 4301 Security Architecture for IP December 2005

References

Normative References

 [BBCDWW98]     Blake, S., Black, D., Carlson, M., Davies, E., Wang,
                Z., and W. Weiss, "An Architecture for Differentiated
                Service", RFC 2475, December 1998.
 [Bra97]        Bradner, S., "Key words for use in RFCs to Indicate
                Requirement Level", BCP 14, RFC 2119, March 1997.
 [CD98]         Conta, A. and S. Deering, "Internet Control Message
                Protocol (ICMPv6) for the Internet Protocol Version 6
                (IPv6) Specification", RFC 2463, December 1998.
 [DH98]         Deering, S., and R. Hinden, "Internet Protocol,
                Version 6 (IPv6) Specification", RFC 2460, December
                1998.
 [Eas05]        3rd Eastlake, D., "Cryptographic Algorithm
                Implementation Requirements For Encapsulating Security
                Payload (ESP) and Authentication Header (AH)", RFC
                4305, December 2005.
 [HarCar98]     Harkins, D. and D. Carrel, "The Internet Key Exchange
                (IKE)", RFC 2409, November 1998.
 [Kau05]        Kaufman, C., Ed., "The Internet Key Exchange (IKEv2)
                Protocol", RFC 4306, December 2005.
 [Ken05a]       Kent, S., "IP Encapsulating Security Payload (ESP)",
                RFC 4303, December 2005.
 [Ken05b]       Kent, S., "IP Authentication Header", RFC 4302,
                December 2005.
 [MD90]         Mogul, J. and S. Deering, "Path MTU discovery", RFC
                1191, November 1990.
 [Mobip]        Johnson, D., Perkins, C., and J. Arkko, "Mobility
                Support in IPv6", RFC 3775, June 2004.
 [Pos81a]       Postel, J., "Internet Protocol", STD 5, RFC 791,
                September 1981.
 [Pos81b]       Postel, J., "Internet Control Message Protocol", RFC
                792, September 1981.

Kent & Seo Standards Track [Page 98] RFC 4301 Security Architecture for IP December 2005

 [Sch05]        Schiller, J., "Cryptographic Algorithms for use in the
                Internet Key Exchange Version 2 (IKEv2)", RFC 4307,
                December 2005.
 [WaKiHo97]     Wahl, M., Kille, S., and T. Howes, "Lightweight
                Directory Access Protocol (v3): UTF-8 String
                Representation of Distinguished Names", RFC 2253,
                December 1997.

Informative References

 [CoSa04]       Condell, M., and L. Sanchez, "On the Deterministic
                Enforcement of Un-ordered Security Policies", BBN
                Technical Memo 1346, March 2004.
 [FaLiHaMeTr00] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
                Traina, "Generic Routing Encapsulation (GRE)", RFC
                2784, March 2000.
 [Gro02]        Grossman, D., "New Terminology and Clarifications for
                Diffserv", RFC 3260, April 2002.
 [HC03]         Holbrook, H. and B. Cain, "Source Specific Multicast
                for IP", Work in Progress, November 3, 2002.
 [HA94]         Haller, N. and R. Atkinson, "On Internet
                Authentication", RFC 1704, October 1994.
 [NiBlBaBL98]   Nichols, K., Blake, S., Baker, F., and D. Black,
                "Definition of the Differentiated Services Field (DS
                Field) in the IPv4 and IPv6 Headers", RFC 2474,
                December 1998.
 [Per96]        Perkins, C., "IP Encapsulation within IP", RFC 2003,
                October 1996.
 [RaFlBl01]     Ramakrishnan, K., Floyd, S., and D. Black, "The
                Addition of Explicit Congestion Notification (ECN) to
                IP", RFC 3168, September 2001.
 [RFC2401]      Kent, S. and R. Atkinson, "Security Architecture for
                the Internet Protocol", RFC 2401, November 1998.
 [RFC2983]      Black, D., "Differentiated Services and Tunnels", RFC
                2983, October 2000.
 [RFC3547]      Baugher, M., Weis, B., Hardjono, T., and H. Harney,
                "The Group Domain of Interpretation", RFC 3547, July
                2003.

Kent & Seo Standards Track [Page 99] RFC 4301 Security Architecture for IP December 2005

 [RFC3740]      Hardjono, T. and B.  Weis, "The Multicast Group
                Security Architecture", RFC 3740, March 2004.
 [RaCoCaDe04]   Rajahalme, J., Conta, A., Carpenter, B., and S.
                Deering, "IPv6 Flow Label Specification", RFC 3697,
                March 2004.
 [Sch94]        Schneier, B.,  Applied Cryptography, Section 8.6, John
                Wiley & Sons, New York, NY, 1994.
 [Shi00]        Shirey, R., "Internet Security Glossary", RFC 2828,
                May 2000.
 [SMPT01]       Shacham, A., Monsour, B., Pereira, R., and M. Thomas,
                "IP Payload Compression Protocol (IPComp)", RFC 3173,
                September 2001.
 [ToEgWa04]     Touch, J., Eggert, L., and Y. Wang, "Use of IPsec
                Transport Mode for Dynamic Routing", RFC 3884,
                September 2004.
 [VK83]         V.L. Voydock & S.T. Kent, "Security Mechanisms in
                High-level Networks", ACM Computing Surveys, Vol. 15,
                No. 2, June 1983.

Authors' Addresses

 Stephen Kent
 BBN Technologies
 10 Moulton Street
 Cambridge, MA  02138
 USA
 Phone: +1 (617) 873-3988
 EMail: kent@bbn.com
 Karen Seo
 BBN Technologies
 10 Moulton Street
 Cambridge, MA  02138
 USA
 Phone: +1 (617) 873-3152
 EMail: kseo@bbn.com

Kent & Seo Standards Track [Page 100] RFC 4301 Security Architecture for IP December 2005

Full Copyright Statement

 Copyright (C) The Internet Society (2005).
 This document is subject to the rights, licenses and restrictions
 contained in BCP 78, and except as set forth therein, the authors
 retain all their rights.
 This document and the information contained herein are provided on an
 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

 The IETF takes no position regarding the validity or scope of any
 Intellectual Property Rights or other rights that might be claimed to
 pertain to the implementation or use of the technology described in
 this document or the extent to which any license under such rights
 might or might not be available; nor does it represent that it has
 made any independent effort to identify any such rights.  Information
 on the procedures with respect to rights in RFC documents can be
 found in BCP 78 and BCP 79.
 Copies of IPR disclosures made to the IETF Secretariat and any
 assurances of licenses to be made available, or the result of an
 attempt made to obtain a general license or permission for the use of
 such proprietary rights by implementers or users of this
 specification can be obtained from the IETF on-line IPR repository at
 http://www.ietf.org/ipr.
 The IETF invites any interested party to bring to its attention any
 copyrights, patents or patent applications, or other proprietary
 rights that may cover technology that may be required to implement
 this standard.  Please address the information to the IETF at ietf-
 ipr@ietf.org.

Acknowledgement

 Funding for the RFC Editor function is currently provided by the
 Internet Society.

Kent & Seo Standards Track [Page 101]

/data/webs/external/dokuwiki/data/pages/rfc/rfc4301.txt · Last modified: 2005/12/19 23:45 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki