--- /dev/null
+Network Working Group S. Kent
+Internet Draft K. Seo
+draft-ietf-ipsec-rfc2401bis-06.txt BBN Technologies
+Obsoletes: RFC 2401 March 2005
+Expires September 2005
+
+
+
+
+
+
+
+ Security Architecture for the Internet Protocol
+
+
+
+ Dedicated to the memory of Charlie Lynn, a long time senior
+ colleague at BBN, who made very significant contributions to
+ the IPsec documents.
+
+
+
+Status of this Memo
+
+ By submitting this Internet-Draft, I certify that any applicable
+ patent or other IPR claims of which I am aware have been disclosed,
+ and any of which I become aware will be disclosed, in accordance with
+ RFC 3668.
+
+ This document is an Internet Draft and is subject to all provisions
+ of Section 10 of RFC2026. Internet-Drafts are working documents of
+ the Internet Engineering Task Force (IETF), its areas, and its
+ working groups. Note that other groups may also distribute working
+ documents as Internet-Drafts. Internet-Drafts are draft documents
+ valid for a maximum of six months and may be updated, replaced, or
+ obsoleted by other documents at any time. It is inappropriate to use
+ Internet-Drafts as reference material or to cite them other than as
+ "work in progress". The list of current Internet-Drafts can be
+ accessed at http://www.ietf.org/1id-abstracts.html. The list of
+ Internet-Draft Shadow Directories can be accessed at
+ http://www.ietf.org/shadow.html.
+
+ Copyright (C) The Internet Society (2005). All Rights Reserved.
+
+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).
+
+ Comments should be sent to Stephen Kent (kent@bbn.com). [RFC Editor:
+ Please remove this line prior to publication as an RFC.]
+
+
+
+Kent & Seo [Page 1]
+\f
+Internet Draft Security Architecture for IP March 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..........................................11
+ 4.2 SA Functionality..............................................16
+ 4.3 Combining SAs.................................................17
+ 4.4 Major IPsec Databases.........................................17
+ 4.4.1 The Security Policy Database (SPD).......................19
+ 4.4.1.1 Selectors...........................................25
+ 4.4.1.2 Structure of an SPD entry...........................29
+ 4.4.1.3 More re: Fields Associated with Next Layer
+ Protocols...........................................31
+ 4.4.2 Security Association Database (SAD)......................33
+ 4.4.2.1 Data Items in the SAD...............................34
+ 4.4.2.2 Relationship between SPD, PFP flag, packet, and SAD.36
+ 4.4.3 Peer Authorization Database (PAD)........................41
+ 4.4.3.1 PAD Entry IDs and Matching Rules....................42
+ 4.4.3.2 IKE Peer Authentication Data........................43
+ 4.4.3.3 Child SA Authorization Data.........................44
+ 4.4.3.4 How the PAD Is Used.................................44
+ 4.5 SA and Key Management.........................................45
+ 4.5.1 Manual Techniques........................................46
+ 4.5.2 Automated SA and Key Management..........................46
+ 4.5.3 Locating a Security Gateway..............................47
+ 4.6 SAs and Multicast.............................................48
+5. IP Traffic Processing..............................................48
+ 5.1 Outbound IP Traffic Processing (protected-to-unprotected).....49
+ 5.1.1 Handling an Outbound Packet That Must Be Discarded.......52
+ 5.1.2 Header Construction for Tunnel Mode......................53
+ 5.1.2.1 IPv4 -- Header Construction for Tunnel Mode.........55
+ 5.1.2.2 IPv6 -- Header Construction for Tunnel Mode.........56
+ 5.2 Processing Inbound IP Traffic (unprotected-to-protected)......57
+6. ICMP Processing ...................................................61
+ 6.1 Processing ICMP Error Messages Directed to an IPsec
+ Implementation.....................................61
+ 6.1.1 ICMP Error Messages Received on the Unprotected
+ Side of the Boundary...............................61
+ 6.1.2 ICMP Error Messages Received on the Protected
+ Side of the Boundary...............................62
+
+
+Kent & Seo [Page 2]
+\f
+Internet Draft Security Architecture for IP March 2005
+
+
+ 6.2 Processing Protected, Transit ICMP Error Messages.............62
+7. Handling Fragments (on the protected side of the IPsec boundary)...64
+ 7.1 Tunnel Mode SAs that Carry Initial and Non-Initial Fragments..65
+ 7.2 Separate Tunnel Mode SAs for Non-Initial Fragments............65
+ 7.3 Stateful Fragment Checking....................................66
+ 7.4 BYPASS/DISCARD traffic........................................66
+8. Path MTU/DF Processing.............................................67
+ 8.1 DF Bit........................................................67
+ 8.2 Path MTU (PMTU) Discovery.....................................67
+ 8.2.1 Propagation of PMTU......................................68
+ 8.2.2 PMTU Aging...............................................68
+9. Auditing...........................................................69
+10. Conformance Requirements..........................................69
+11. Security Considerations...........................................69
+12. IANA Considerations...............................................70
+13. Differences from RFC 2401.........................................70
+Acknowledgements......................................................73
+Appendix A -- Glossary................................................74
+Appendix B -- Decorrelation...........................................77
+Appendix C -- ASN.1 for an SPD Entry..................................80
+Appendix D -- Fragment Handling Rationale.............................86
+ D.1 Transport Mode and Fragments..................................86
+ D.2 Tunnel Mode and Fragments.....................................87
+ D.3 The Problem of Non-Initial Fragments..........................88
+ D.4 BYPASS/DISCARD traffic........................................91
+ D.5 Just say no to ports?.........................................91
+ D.6 Other Suggested Solutions.....................................92
+ D.7 Consistency...................................................93
+ D.8 Conclusions...................................................93
+Appendix E -- Example of Supporting Nested SAs via SPD and Forwarding
+ Table Entries.....................................94
+References............................................................96
+Author Information....................................................99
+Notices..............................................................100
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kent & Seo [Page 3]
+\f
+Internet Draft Security Architecture for IP March 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
+ (end users or system administrators) also are part of the target
+
+
+Kent & Seo [Page 4]
+\f
+Internet Draft Security Architecture for IP March 2005
+
+
+ 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 inter-relationship.
+ 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 IKE v2 [Sch05] plus a
+ separate RFC for each cryptographic algorithm.
+ c. automatic key management -- RFCs on "The Internet Key
+ Exchange (IKE v2) Protocol" [Kau05] and "Cryptographic
+ Algorithms for use in the Internet Key Exchange Version 2"
+ [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
+ via IKE v2.) The IPsec firewall function makes use of the
+
+
+Kent & Seo [Page 5]
+\f
+Internet Draft Security Architecture for IP March 2005
+
+
+ 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 & 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 IKE v2
+ 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 IKE v2 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 the their implementation, which
+ is outside the scope of this set of standards. Moreover, the
+ security of a computer system or network is a function of many
+
+
+Kent & Seo [Page 6]
+\f
+Internet Draft Security Architecture for IP March 2005
+
+
+ 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, 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 Security Policy Database (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. IPsec
+ security services are offered at the IP layer through selection of
+ appropriate security protocols, cryptographic algorithms, and
+
+
+Kent & Seo [Page 7]
+\f
+Internet Draft Security Architecture for IP March 2005
+
+
+ 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.
+
+ 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.
+
+
+Kent & Seo [Page 8]
+\f
+Internet Draft Security Architecture for IP March 2005
+
+
+ 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 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
+ 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
+
+
+Kent & Seo [Page 9]
+\f
+Internet Draft Security Architecture for IP March 2005
+
+
+ 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,
+
+ 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 (IKE v2 [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 IKE v2 but not in IKE v1, 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 IKE v2 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).
+
+ 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
+
+
+Kent & Seo [Page 10]
+\f
+Internet Draft Security Architecture for IP March 2005
+
+
+ "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
+ 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
+
+
+Kent & Seo [Page 11]
+\f
+Internet Draft Security Architecture for IP March 2005
+
+
+ direction) is required. IKE explicitly creates SA pairs in
+ recognition of this common usage requirement.
+
+ For an SA used to carry unicast traffic, the SPI (Security Parameters
+ Index - see Appendix A and AH [Ken05b] and ESP [Ken05a]
+ specifications) by itself suffices to specify an SA. 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 demultiplexing 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:
+
+
+ 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.
+
+
+Kent & Seo [Page 12]
+\f
+Internet Draft Security Architecture for IP March 2005
+
+
+ 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 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 CodePoint (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 QoS appropriately. To permit this, the
+ IPsec implementation MUST permit establishment and maintenance of
+ multiple SAs between a given sender and receiver, 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.
+
+
+
+Kent & Seo [Page 13]
+\f
+Internet Draft Security Architecture for IP March 2005
+
+
+ DISCUSSION: While 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 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.
+
+ 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, 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.
+
+
+Kent & Seo [Page 14]
+\f
+Internet Draft Security Architecture for IP March 2005
+
+
+ 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., 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 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
+
+
+Kent & Seo [Page 15]
+\f
+Internet Draft Security Architecture for IP March 2005
+
+
+ (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 on 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.
+ 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 effects 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
+
+
+Kent & Seo [Page 16]
+\f
+Internet Draft Security Architecture for IP March 2005
+
+
+ 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 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. 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.)
+
+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 Peer Authorization
+ Database (PAD) provides a link between an SA management protocol like
+ IKE and the SPD (Section 4.4.3).
+
+
+Kent & Seo [Page 17]
+\f
+Internet Draft Security Architecture for IP March 2005
+
+
+ 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
+ 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
+
+
+Kent & Seo [Page 18]
+\f
+Internet Draft Security Architecture for IP March 2005
+
+
+ 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) 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
+ 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. 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 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
+
+
+Kent & Seo [Page 19]
+\f
+Internet Draft Security Architecture for IP March 2005
+
+
+ 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 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 look up 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
+
+
+Kent & Seo [Page 20]
+\f
+Internet Draft Security Architecture for IP March 2005
+
+
+ entries as follows:
+
+ - SPD-I: For inbound traffic that is to be bypassed or discarded,
+ the entry consists of the values of the selectors that apply to
+ the traffic to be bypassed or discarded.
+
+ - SPD-O: For outbound traffic that is to be bypassed or
+ discarded, the entry consists of the values of the selectors
+ that apply to the traffic to be bypassed or discarded.
+
+ - SPD-S: For traffic that is to be protected using IPsec, the
+ entry consists of the values of the selectors that apply to the
+ traffic to be protected via AH or ESP, controls on how to
+ create SAs based on these selectors, and the parameters needed
+ to effect this protection (e.g., algorithms, modes, etc.). Note
+ that an SPD-S entry also contains information such as "populate
+ from packet" (PFP) flag (see paragraphs below on "How To Derive
+ the Values for an SAD entry") and bits indicating whether the
+ 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
+
+
+Kent & Seo [Page 21]
+\f
+Internet Draft Security Architecture for IP March 2005
+
+
+ because it may not be present in a fragment, does not exist for
+ the given Next Layer Protocol, or because 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
+ 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., IKE v2) 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 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:
+
+
+
+
+
+
+
+
+Kent & Seo [Page 22]
+\f
+Internet Draft Security Architecture for IP March 2005
+
+
+ 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
+ implementation making use of a socket interface, the SPD may not
+ need to be consulted on a per packet basis, as noted above.) 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
+
+
+Kent & Seo [Page 23]
+\f
+Internet Draft Security Architecture for IP March 2005
+
+
+ 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., IKE v2, negotiates A. And all 3
+ 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 info 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 and 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.
+
+
+
+Kent & Seo [Page 24]
+\f
+Internet Draft Security Architecture for IP March 2005
+
+
+ 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
+ IKE v2, 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
+ 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.
+
+
+
+Kent & Seo [Page 25]
+\f
+Internet Draft Security Architecture for IP March 2005
+
+
+ - Remote IP Address(es) (IPv4 or IPv6): this is a list of ranges
+ of IP addresses (unicast, broadcast (IPv4 only)). This structure
+ allows expression of a single IP address (via a trivial range),
+ or a list of addresses (each a trivial range), or a range of
+ addresses (low and high values, inclusive), as well as the most
+ generic form of a list of ranges. Address ranges are used to
+ support more than one remote system sharing the same SA, e.g.,
+ behind a security gateway.
+
+ - Local IP Address(es) (IPv4 or IPv6): this is a list of ranges of
+ IP addresses (unicast, broadcast (IPv4 only)). This structure
+ allows expression of a single IP address (via a trivial range),
+ or a list of addresses (each a trivial range), or a range of
+ addresses (low and high values, inclusive), as well as the most
+ generic form of a list of ranges. Address ranges are used to
+ 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 of the
+ symmetric relationship associated with local and remote address
+ values for unicast SAs in a multicast context. Specifically,
+ outbound traffic directed to a multicast address on an SA would
+ not be received on a companion, inbound SA with the multicast
+ address as the source.
+
+ - Next Layer Protocol: Obtained from the IPv4 "Protocol" or the
+ IPv6 "Next Header" fields. This is an individual protocol
+ number, ANY, or for IPv6 only, OPAQUE. The Next Layer Protocol
+ is whatever comes after any IP extension headers that are
+ present. To simplify locating the Next Layer Protocol, there
+ SHOULD be a mechanism for configuring which IPv6 extension
+ headers to skip. The default configuration for which protocols
+ to skip SHOULD include the following protocols: 0 (Hop-by-hop
+ options), 43 (Routing Header), 44 (Fragmentation Header), and 60
+ (Destination Options). Note: The default list does NOT include
+ 51 (AH), or 50 (ESP). From a selector lookup point of view,
+ IPsec treats AH and ESP as Next Layer Protocols.
+
+ Several additional selectors depend on the Next Layer Protocol
+ value:
+
+ * If the Next Layer Protocol uses two ports (e.g., TCP, UDP,
+ SCTP, ...), 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
+
+
+Kent & Seo [Page 26]
+\f
+Internet Draft Security Architecture for IP March 2005
+
+
+ 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
+ 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,
+ ANY type and ANY code. Given a policy entry with a range of
+ Types (T-start to T-end) and a range of Codes (C-start to
+ C-end), and an ICMP packet with Type t and Code c, an
+ implementation MUST test for a match using
+
+ (T-start*256) + C-start <= (t*256) + c <= (T-end*256) +
+ C-end
+
+ Note that the ICMP message type and code may not be available
+ in the case of receipt of a fragmented packet. (See Section 7
+ Handling Fragments.)
+
+ - Name: This is not a selector like the others above. It is not
+ acquired from a packet. A name may be used as a symbolic
+ identifier for an IPsec Local or Remote address. Named SPD
+ entries are used in two ways:
+
+ 1. A named SPD entry is used by a responder (not an initiator)
+ in support of access control when an IP address would not be
+ appropriate for the Remote IP address selector, e.g., for
+ "road warriors." The name used to match this field is
+
+
+Kent & Seo [Page 27]
+\f
+Internet Draft Security Architecture for IP March 2005
+
+
+ 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:
+
+ - local address in the SPD cache entry
+ - local address in the outbound SAD entry
+ - remote address in the inbound SAD entry
+
+ Support for this use is optional for multi-user, native host
+ implementations and not applicable to other implementations.
+ Note that this name is used only locally; it is not
+ communicated by the key management protocol. Also, name
+ forms other than those used for case 1 above (responder) are
+ applicable in the initiator context (see below).
+
+ An SPD entry can contain both a name (or a list of names) and
+ also values for the Local or Remote IP address.
+
+ For case 1, responder, the identifiers employed in named SPD
+ entries are one of the following four types:
+
+ a. a fully qualified user name string (email), e.g.,
+ mozart@foo.example.com
+ (this corresponds to ID_RFC822_ADDR in IKE v2)
+
+ b. a fully qualified DNS name, e.g.,
+ foo.example.com
+ (this corresponds to ID_FQDN in IKE v2)
+
+ 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 IKE v2, after
+ decoding)
+
+ d. a byte string
+
+
+Kent & Seo [Page 28]
+\f
+Internet Draft Security Architecture for IP March 2005
+
+
+ (this corresponds to Key_ID in IKE v2)
+
+ 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.
+
+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 IKE v2 published concurrently with this document
+ [Kau05] do not align precisely with those defined for the SPD.
+ Specifically, IKE v2 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, IKE v2 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
+
+
+Kent & Seo [Page 29]
+\f
+Internet Draft Security Architecture for IP March 2005
+
+
+ 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
+ -- IKE v2 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".
+
+ 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
+
+
+Kent & Seo [Page 30]
+\f
+Internet Draft Security Architecture for IP March 2005
+
+
+ set entry. This is consistent with how IKE v2 negotiates
+ the 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
+ - (if tunnel mode) local tunnel address -- For a
+ non-mobile host, if there is just one interface, this
+ is straightforward; and 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 re: 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
+
+
+Kent & Seo [Page 31]
+\f
+Internet Draft Security Architecture for IP March 2005
+
+
+ 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
+
+ Remote's
+ next layer protocol = AH
+ "port" selector = OPAQUE
+
+ B. If a Next Layer Protocol has only one selector, e.g.,
+ Mobility Header type, then that field is placed in the
+ Local "port" selector in the relevant SPD entry, and the
+ Remote "port" selector is set to OPAQUE in the relevant
+ SPD entry, e.g.,
+
+ Local's
+ next layer protocol = Mobility Header
+ "port" selector = Mobility Header message type
+
+ Remote's
+ next layer protocol = Mobility Header
+ "port" selector = OPAQUE
+
+ 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:
+
+ 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
+
+
+Kent & Seo [Page 32]
+\f
+Internet Draft Security Architecture for IP March 2005
+
+
+ "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 the SPI may be used 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 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 Section
+ 4.4.1, paragraph on 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
+
+
+Kent & Seo [Page 33]
+\f
+Internet Draft Security Architecture for IP March 2005
+
+
+ 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 2401bis 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.
+
+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
+
+
+Kent & Seo [Page 34]
+\f
+Internet Draft Security Architecture for IP March 2005
+
+
+ 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.
+
+ 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 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
+
+
+Kent & Seo [Page 35]
+\f
+Internet Draft Security Architecture for IP March 2005
+
+
+ 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 SAs
+ 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.
+
+ 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 IKE v2 sends, it
+
+
+Kent & Seo [Page 36]
+\f
+Internet Draft Security Architecture for IP March 2005
+
+
+ might be clearer and less error prone for the user to enter a
+ single IP address or IP address prefix.
+
+ 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 [Page 37]
+\f
+Internet Draft Security Architecture for IP March 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 [Page 38]
+\f
+Internet Draft Security Architecture for IP March 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 [Page 39]
+\f
+Internet Draft Security Architecture for IP March 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 [Page 40]
+\f
+Internet Draft Security Architecture for IP March 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 IKv2 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., IKE v1, IKE v2, KINK) method used (e.g., certificates or pre-
+ shared secrets) and the authentication data (e.g., the pre-shared
+ secret or the trust anchor relative to which the peer's certificate
+
+
+Kent & Seo [Page 41]
+\f
+Internet Draft Security Architecture for IP March 2005
+
+
+ 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 OSCP 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 RFC822 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.
+
+ Similarly, a Distinguished Name may specify a complete DN 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"
+
+
+Kent & Seo [Page 42]
+\f
+Internet Draft Security Architecture for IP March 2005
+
+
+ might be used to match all DNs that contain these two attributes as
+ the top two RDNs.
+
+ For an RFC822 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 RFC822 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 RFC822 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 CIDR-style prefixes), or an
+ arbitrary address range.
+
+ The Key ID field is defined as an OCTET string in IKE. For this name
+ type, only exact match syntax MUST be supported (since there is no
+ explicit structure for this ID type. Additional matching functions
+ MAY be supported for this ID type.
+
+4.4.3.2 IKE Peer Authentication Data
+
+ Once an entry is located based on an ordered search of the PAD based
+ on ID field matching, it is necessary to verify the asserted
+ identity, i.e., to authenticate the asserted ID. For each PAD entry
+ there is an indication of the type of authentication to be performed.
+ This document requires support for two required authentication data
+ types:
+
+ - X.509 certificate
+ - pre-shared secret
+
+ For authentication based on an X.509 certificate, the PAD entry
+ contains a trust anchor via which the end entity (EE) certificate for
+ the peer must be verifiable, either directly or via a certificate
+ path. See RFC 3280 for the definition of a trust anchor. An entry
+ used with certificate-based authentication MAY include additional
+ data to facilitate certificate revocation status, e.g., a list of
+ 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
+
+
+Kent & Seo [Page 43]
+\f
+Internet Draft Security Architecture for IP March 2005
+
+
+ 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, RFC822
+ e-mail addresses, and IP addresses. Since KEY ID is intended for
+ identifying a peer authenticated via a pre-shred secret, there is no
+ requirement to match this ID type to a certificate field.
+
+ See IKE v1 [HarCar98] and IKE v2 [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.
+
+ 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
+
+
+Kent & Seo [Page 44]
+\f
+Internet Draft Security Architecture for IP March 2005
+
+
+ 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 and
+ 2401bis 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
+ 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.
+
+
+
+Kent & Seo [Page 45]
+\f
+Internet Draft Security Architecture for IP March 2005
+
+
+ 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 IKE v2 [Kau05]. This document assumes the availability of
+ certain functions from the key management protocol which are not
+ supported by IKE v1. 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
+ 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
+
+
+Kent & Seo [Page 46]
+\f
+Internet Draft Security Architecture for IP March 2005
+
+
+ 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
+ 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?
+
+ 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
+
+
+Kent & Seo [Page 47]
+\f
+Internet Draft Security Architecture for IP March 2005
+
+
+ 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
+ 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
+
+
+Kent & Seo [Page 48]
+\f
+Internet Draft Security Architecture for IP March 2005
+
+
+ have corresponding entries in the SPD. Since 2401bis 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.
+
+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.
+
+
+
+
+
+
+
+
+
+
+
+
+Kent & Seo [Page 49]
+\f
+Internet Draft Security Architecture for IP March 2005
+
+
+ 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.
+
+
+ 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.
+
+
+Kent & Seo [Page 50]
+\f
+Internet Draft Security Architecture for IP March 2005
+
+
+ 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
+ and 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., IKE v2) 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 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
+
+
+Kent & Seo [Page 51]
+\f
+Internet Draft Security Architecture for IP March 2005
+
+
+ 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, e.g., because the remote peer is administratively
+ prohibited from communicating with the initiator, or the
+ initiating peer was unable to authenticate itself to the remote
+ peer, or the remote peer was unable to authenticate itself to the
+ initiating peer, or SPD at remote peer did not have a suitable
+ entry, etc.
+
+ IPv4 Type = 3 (destination unreachable) Code = 13
+ (Communication Administratively Prohibited)
+
+ IPv6 Type = 1 (destination unreachable) Code = 1
+ (Communication with destination administratively
+ prohibited)
+
+
+
+Kent & Seo [Page 52]
+\f
+Internet Draft Security Architecture for IP March 2005
+
+
+ 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
+ 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 with 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.
+ (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) in several ways:
+
+
+Kent & Seo [Page 53]
+\f
+Internet Draft Security Architecture for IP March 2005
+
+
+ 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 re: 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
+ 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 [RFC
+ 2983] 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).
+
+
+Kent & Seo [Page 54]
+\f
+Internet Draft Security Architecture for IP March 2005
+
+
+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
+ 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.)
+
+ 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.
+
+ 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.
+
+
+Kent & Seo [Page 55]
+\f
+Internet Draft Security Architecture for IP March 2005
+
+
+ 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 [RFC 2474]. See RFC 2475[BBCDWW98] for
+ further information.
+
+ 6. If the ECN field in the inner header is set to ECT(0) or
+ ECT(1) and the ECN field in the outer header is set to
+ 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.
+
+5.1.2.2 IPv6 -- Header Construction for Tunnel Mode
+
+ See previous section 5.1.2.1 for notes 1-6 indicated by (footnote
+ number).
+
+ <-- 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
+
+ 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
+
+
+Kent & Seo [Page 56]
+\f
+Internet Draft Security Architecture for IP March 2005
+
+
+ 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 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kent & Seo [Page 57]
+\f
+Internet Draft Security Architecture for IP March 2005
+
+
+
+ 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. Inbound Traffic Processing Model
+ (*) = 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.
+
+
+Kent & Seo [Page 58]
+\f
+Internet Draft Security Architecture for IP March 2005
+
+
+ (***) = 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 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
+
+
+Kent & Seo [Page 59]
+\f
+Internet Draft Security Architecture for IP March 2005
+
+
+ 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, and 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.
+
+ 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.
+
+
+
+Kent & Seo [Page 60]
+\f
+Internet Draft Security Architecture for IP March 2005
+
+
+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.
+
+ 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
+
+
+Kent & Seo [Page 61]
+\f
+Internet Draft Security Architecture for IP March 2005
+
+
+ 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
+ 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 dead message that refers to any host/net with which A is
+ currently communicating, and thus effect a highly efficient DoS
+ attack re: 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
+
+
+Kent & Seo [Page 62]
+\f
+Internet Draft Security Architecture for IP March 2005
+
+
+ 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
+ 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.
+
+
+
+Kent & Seo [Page 63]
+\f
+Internet Draft Security Architecture for IP March 2005
+
+
+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 for discussion
+ of 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
+ 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)
+
+
+
+
+Kent & Seo [Page 64]
+\f
+Internet Draft Security Architecture for IP March 2005
+
+
+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
+ 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
+
+
+Kent & Seo [Page 65]
+\f
+Internet Draft Security Architecture for IP March 2005
+
+
+ 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
+ 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
+
+
+Kent & Seo [Page 66]
+\f
+Internet Draft Security Architecture for IP March 2005
+
+
+ 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 choose to act
+ upon it, 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.
+
+8.2 Path MTU Discovery (PMTU)
+
+ 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
+
+
+
+
+
+
+Kent & Seo [Page 67]
+\f
+Internet Draft Security Architecture for IP March 2005
+
+
+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.
+
+ 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.
+
+
+Kent & Seo [Page 68]
+\f
+Internet Draft Security Architecture for IP March 2005
+
+
+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.
+
+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 dead 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
+
+
+Kent & Seo [Page 69]
+\f
+Internet Draft Security Architecture for IP March 2005
+
+
+ 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
+
+ Upon approval of this draft for publication as an RFC, this document
+ requests that IANA fill in the number (xx) for the asn1-modules
+ registry and assign the object identifier (yy) for the spd-module in
+ Appendix C "ASN.1 for an SPD Entry".
+
+13. Differences from RFC 2401
+
+ This architecture document differs substantially from RFC 2401 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
+ 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 like 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.
+
+
+Kent & Seo [Page 70]
+\f
+Internet Draft Security Architecture for IP March 2005
+
+
+ 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.
+
+ 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 re: 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.
+
+
+
+Kent & Seo [Page 71]
+\f
+Internet Draft Security Architecture for IP March 2005
+
+
+ o Added text describing how to handle an outbound packet which 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.
+
+ 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
+ IKE v2 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.
+
+
+
+
+
+
+
+
+
+
+
+Kent & Seo [Page 72]
+\f
+Internet Draft Security Architecture for IP March 2005
+
+
+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 [Page 73]
+\f
+Internet Draft Security Architecture for IP March 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, HA94]. Included in this glossary are generic
+security service and security mechanism terms, plus IPsec-specific
+terms.
+
+ Access Control
+ Access control is 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
+ This term is 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
+ 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
+ Confidentiality is 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.)
+
+ Data Origin Authentication
+ Data origin authentication is a security service that verifies the
+ identity of the claimed source of data. This service is usually
+
+
+Kent & Seo [Page 74]
+\f
+Internet Draft Security Architecture for IP March 2005
+
+
+ bundled with connectionless integrity service.
+
+ Encryption
+ Encryption is 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". Oftimes the
+ term "encryption" is used to generically refer to both processes.
+
+ Integrity
+ Integrity is 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
+ 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
+
+
+Kent & Seo [Page 75]
+\f
+Internet Draft Security Architecture for IP March 2005
+
+
+ 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
+ A security gateway is 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. (See
+ "Trusted Subnetwork" below.) 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).
+
+ SPI
+ Acronym for "Security Parameters Index" (SPI). The SPI is 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, flow identifiers, etc.
+ [Sch94]
+
+
+
+
+
+
+
+
+
+
+Kent & Seo [Page 76]
+\f
+Internet Draft Security Architecture for IP March 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, that 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 up 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
+
+ A policy (SPD entry) P may be expressed as a sequence of selector
+
+
+Kent & Seo [Page 77]
+\f
+Internet Draft Security Architecture for IP March 2005
+
+
+ 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.
+
+ 4) Get next Cj and go to 2.
+
+
+Kent & Seo [Page 78]
+\f
+Internet Draft Security Architecture for IP March 2005
+
+
+
+ 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 [Page 79]
+\f
+Internet Draft Security Architecture for IP March 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 which 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)
+ asn1-modules (xx) spd-module (yy) }
+
+ 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) } ;
+
+ -- 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 [Page 80]
+\f
+Internet Draft Security Architecture for IP March 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 { -- IKE v2 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,
+ tunnel TunnelOptions OPTIONAL } -- if absent, use
+
+
+Kent & Seo [Page 81]
+\f
+Internet Draft Security Architecture for IP March 2005
+
+
+ -- 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 }
+
+ -- Integrity Algorithms, ordered by decreasing preference
+ IntegrityAlgs ::= SEQUENCE OF IntegrityAlg
+
+ -- Confidentiality Algorithms, ordered by decreasing preference
+ ConfidentialityAlgs ::= SEQUENCE OF ConfidentialityAlg
+
+ -- 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)
+ }
+
+ -- Confidentiality Algorithms
+
+
+Kent & Seo [Page 82]
+\f
+Internet Draft Security Architecture for IP March 2005
+
+
+ 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)) }
+
+ IPv6Pair ::= SEQUENCE {
+
+
+Kent & Seo [Page 83]
+\f
+Internet Draft Security Architecture for IP March 2005
+
+
+ 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
+
+ NextLayerChoice ::= CHOICE {
+ any AnyNextLayer,
+
+
+Kent & Seo [Page 84]
+\f
+Internet Draft Security Architecture for IP March 2005
+
+
+ opaque [0] OpaqueNextLayer,
+ range [1] NextLayerRange }
+
+ -- Representation of ANY in next layer field
+ AnyNextLayer ::= SEQUENCE {
+ start INTEGER (0),
+ end INTEGER (65535) }
+
+ -- Representation of OPAQUE in next layer field.
+ -- Matches IKE convention
+ OpaqueNextLayer ::= SEQUENCE {
+ start INTEGER (65535),
+ end INTEGER (0) }
+
+ -- Range for a next layer field
+ NextLayerRange ::= SEQUENCE {
+ start INTEGER (0..65535),
+ end INTEGER (0..65535) }
+
+ -- List of IP addresses
+ AddrList ::= SEQUENCE {
+ v4List IPv4List OPTIONAL,
+ v6List [0] IPv6List OPTIONAL }
+
+ -- IPv4 address representations
+ IPv4List ::= SEQUENCE OF IPv4Range
+
+ IPv4Range ::= SEQUENCE { -- close, but not quite right ...
+ ipv4Start OCTET STRING (SIZE (4)),
+ ipv4End OCTET STRING (SIZE (4)) }
+
+ -- 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 [Page 85]
+\f
+Internet Draft Security Architecture for IP March 2005
+
+
+Appendix D -- Fragment Handling Rationale
+
+ There are three issues that must be resolved re processing of
+ (plaintext) fragments in IPsec:
+
+ - mapping a non-initial, outbound fragment to the right SA
+ (or finding the right SPD entry)
+ - verifying that a received, non-initial fragment is authorized
+ for the SA via which it is received
+ - 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 end points. 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 re 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
+ then apply AH or ESP and could re-fragment the packet after IPsec
+
+
+Kent & Seo [Page 86]
+\f
+Internet Draft Security Architecture for IP March 2005
+
+
+ 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
+ arrived at an SG, these fields would be encrypted. The algorithm
+ specified for locating the "next layer protocol" described in RFC
+
+
+Kent & Seo [Page 87]
+\f
+Internet Draft Security Architecture for IP March 2005
+
+
+ 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 IKE v2
+ 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,
+ 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
+
+
+Kent & Seo [Page 88]
+\f
+Internet Draft Security Architecture for IP March 2005
+
+
+ two IPsec (SG or BITW) implementations using the OPAQUE value for
+ both port fields, then all non-initial fragments matching the 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 down
+ side; 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
+ 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
+
+
+Kent & Seo [Page 89]
+\f
+Internet Draft Security Architecture for IP March 2005
+
+
+ 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 it is 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 re: 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
+ 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.
+
+
+
+
+Kent & Seo [Page 90]
+\f
+Internet Draft Security Architecture for IP March 2005
+
+
+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 Secion 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.
+
+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.
+
+
+Kent & Seo [Page 91]
+\f
+Internet Draft Security Architecture for IP March 2005
+
+
+ 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
+ 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
+
+
+Kent & Seo [Page 92]
+\f
+Internet Draft Security Architecture for IP March 2005
+
+
+ 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 [Page 93]
+\f
+Internet Draft Security Architecture for IP March 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 a firewall that protects
+ a corporate network, and C 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
+
+ Protected-side forwarding table
+
+ Rule Local Remote Protocol Action
+ ---- ----- ------ -------- -----------------------------
+ 1 A C ESP loop back to unprotected side
+
+
+
+Kent & Seo [Page 94]
+\f
+Internet Draft Security Architecture for IP March 2005
+
+
+ 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 [Page 95]
+\f
+Internet Draft Security Architecture for IP March 2005
+
+
+References
+
+
+Normative
+
+ [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] Eastlake, D., "Cryptographic Algorithm Implementation
+ Requirements For ESP And AH", ???, ???? 200?.
+
+ [RFC Editor: Please update reference [Eas05] "Cryptographic
+ Algorithm Implementation Requirements For ESP And AH"
+ (draft-ietf-ipsec-esp-ah-algorithms-02.txt) with the RFC
+ number and month and year when it is issued.]
+
+ [HarCar98]Harkins, D., and Carrel, D., "The Internet Key Exchange
+ (IKE)", RFC 2409, November 1998.
+
+ [Kau05] Kaufman, C., "The Internet Key Exchange (IKEv2) Protocol",
+ RFC ???, ???? 200?.
+
+ [RFC Editor: Please update the reference [Kau05] "The
+ Internet Key Exchange (IKEv2) Protocol"
+ (draft-ietf-ipsec-ikev2-17.txt) with the RFC number and
+ month and year when it is issued.]
+
+ [Ken05a] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC
+ ???, ???? 200?.
+
+ [RFC Editor: Please update the reference [Ken05a] "IP
+ Encapsulating Security Payload (ESP)"
+ (draft-ietf-ipsec-esp-v3-09.txt) with the RFC number and
+ month and year when it is issued.]
+
+ [Ken05b] Kent, S., "IP Authentication Header", RFC ???, ??? 200?.
+
+ [RFC Editor: Please update the reference [Ken05b] "IP
+
+
+Kent & Seo [Page 96]
+\f
+Internet Draft Security Architecture for IP March 2005
+
+
+ Authentication Header" (draft-ietf-ipsec-rfc2402bis-09.txt)
+ with the RFC number and month and year when it is issued.]
+
+ [MD90] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
+ November 1990.
+
+ [Pos81a] Postel, J., "Internet Protocol", STD 5, RFC 791, September
+ 1981
+
+ [Pos81b] Postel, J., "Internet Control Message Protocol", RFC 792,
+ September 1981
+
+ [Sch05] Schiller, J., "Cryptographic Algorithms for use in the
+ Internet Key Exchange Version 2", RFC ???, ???? 200?
+
+ [RFC Editor: Please update the reference [Sch05]
+ "Cryptographic Algorithms for use in the Internet Key
+ Exchange Version 2"
+ (draft-ietf-ipsec-ikev2-algorithms-05.txt) with the RFC
+ number and month and year when it is issued.]
+
+ [WaKiHo97]Wahl, M., Kille, S., Howes, T., "Lightweight Directory
+ Access Protocol (v3): UTF-8 String Representation of
+ Distinguished Names", RFC 2253, December 1997
+
+Informative
+
+ [CoSa04] Condell, M., and Sanchez, L. On the Deterministic
+ Enforcement of Un-ordered Security Policies", BBN Technical
+ Memo 1346, March 2004
+
+ [FaLiHaMeTr00]Farinacci, D., Li, T., Hanks, S., Meyer, D., Traina,
+ P., "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 Cain, B., "Source Specific Multicast for
+ IP", WWork in Progress, November 3, 2002.
+
+ [HA94] Haller, N., and Atkinson, R., "On Internet Authentication",
+ RFC 1704, October 1994
+
+ [Mobip] Johnson, D., Perkins, C., Arkko, J., "Mobility Support in
+ IPv6", RFC 3775, June 2004
+
+ [NiBlBaBL98]Nichols, K., Blake, S., Baker, F., Black, D., "Definition
+ of the Differentiated Services Field (DS Field) in the IPv4
+ and IPv6 Headers", RFC2474, December 1998.
+
+
+Kent & Seo [Page 97]
+\f
+Internet Draft Security Architecture for IP March 2005
+
+
+ [Per96] Perkins, C., "IP Encapsulation within IP", RFC 2003,
+ October 1996.
+
+ [RaFlBl01]Ramakrishnan, K., Floyd, S., Black, D., "The Addition of
+ Explicit Congestion Notification (ECN) to IP", RFC 3168,
+ September 2001.
+
+ [RFC3547] Baugher, M., Weis, B., Hardjono, T., Harney, H., "The Group
+ Domain of Interpretation", RFC 3547, July 2003.
+
+ [RFC3740] Hardjono, T., Weis, B., "The Multicast Group Security
+ Architecture", RFC 3740, March 2004.
+
+ [RaCoCaDe04]Rajahalme, J., Conta, A., Carpenter, B., Deering, S.,
+ "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., Wang, Y., 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kent & Seo [Page 98]
+\f
+Internet Draft Security Architecture for IP March 2005
+
+
+Author Information
+
+ 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 [Page 99]
+\f
+Internet Draft Security Architecture for IP March 2005
+
+
+Notices
+
+
+ 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.
+
+ 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 translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implmentation may be prepared, copied, published and
+ distributed, in whole or in part, without restriction of any kind,
+ provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English. The limited permissions granted above are perpetual and
+ will not be revoked by the Internet Society or its successors or
+ assigns.
+
+
+
+Kent & Seo [Page 100]
+\f
+Internet Draft Security Architecture for IP March 2005
+
+
+ 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.
+
+
+
+
+Expires September 2005
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kent & Seo [Page 101]
projects / thirdparty / strongswan.git / blobdiff