view Side-By-Side changes
Internet Draft K. Seodraft-ietf-ipsec-rfc2401bis-01.txtdraft-ietf-ipsec-rfc2401bis-02.txt BBN Technologies Obsoletes: RFC 2401 January 2004 Expires July 2004 Security Architecture for the Internet Protocol Status of this Memo 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 6 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 a "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 (2004). All Rights Reserved. Kent & Seo [Page 1] Internet Draft Security Architecture for IP January 2004 Table of Contents 1. Introduction.........................................................3 1.1 Summary of Contents of Document.................................3 1.2 Audience........................................................3 1.3 Related Documents...............................................4 2. Design Objectives....................................................4 2.1 Goals/Objectives/Requirements/Problem Description...............4 2.2 Caveats and Assumptions.........................................5 3. System Overview .....................................................6 3.1 What IPsec Does.................................................6 3.2 How IPsec Works.................................................8 3.3 Where IPsec May Be Implemented..................................9 4. Security Associations...............................................10 4.1 Definition and Scope...........................................10 4.2 Security Association Functionality.............................13 4.3 Combining Security Associations................................14 4.4 Major IPsec Databases..........................................14 4.4.1 The Security Policy Database (SPD)........................15 4.4.2 Selectors.................................................19 4.4.3 Security Association Database (SAD).......................22 4.5 SA and Key Management..........................................24 4.5.1 Manual Techniques.........................................25 4.5.2 Automated SA and Key Management...........................25 4.5.3 Locating a Security Gateway...............................26 4.6 Security Associations and Multicast............................27 5. IP Traffic Processing...............................................27 5.1 Outbound IP Traffic Processing (protected-to-unprotected)......28 5.1.1 Handling an Outbound Packet That Must Be Dropped..........30 5.1.2 Header Construction for Tunnel Mode.......................31 5.1.2.1 IPv4 -- Header Construction for Tunnel Mode..........33 5.1.2.2 IPv6 -- Header Construction for Tunnel Mode..........34 5.2 Processing Inbound IP Traffic (unprotected-to-protected).......35 6. ICMP Processing (to be filled in when IPsec issue #91 is resolved)..38 7. Auditing............................................................38 8. Conformance Requirements............................................38 9. Security Considerations.............................................38 10. Differences from RFC 2401..........................................38 Acknowledgements.......................................................38 Appendix A -- Glossary.................................................40 Appendix B -- Decorrelation............................................43 Appendix C -- Categorization of ICMP messages [May be deleted].........46 References.............................................................49 Author Information.....................................................51 Notices................................................................52 Kent & Seo [Page 2] Internet Draft Security Architecture for IP January 2004 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 and IPv6 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 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 3] Internet Draft Security Architecture for IP January 2004 audience. A glossary is provided as an appendix 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) [Ken04b] and Encapsulating Security Payload (ESP) [Ken04a] protocols. b. cryptographic algorithms for integrity and encryption -- one RFC that defines the mandatory, default algorithms for use with AH and ESP [Eas03], a similar RFC that defines the mandatory algorithms for use with IKEv2 [Sch03] plus a separate RFC for each cryptographic algorithm. c. automatic key management -- RFCs on "The Internet Key Exchange (IKEv2) Protocol" [Kau03] and "Cryptographic Algorithms for use in the Internet Key Exchange Version 2" [Sch03] 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 for all protocols that may be carried over IP in a standard fashion (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 IKEv2.) The IPsec firewall function makes use of the Kent & Seo [Page 4] Internet Draft Security Architecture for IP January 2004 cryptographically-enforced authentication and integrity provided for all IPsec traffic to offer better access control than could be obtained through use of an independent firewall (one not privy to IPsec internal parameters). 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. A set of default cryptographic algorithms for use with AH and ESP is specified [Eas03] to facilitate interoperability in the global Internet. 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 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 Kent & Seo [Page 5] Internet Draft Security Architecture for IP January 2004 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.2) matched against entries in the database (SPD). Each packet is either afforded 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 cryptographic keys. IPsec can be used to protect one or more "paths" between a pair of hosts, between a pair of security gateways, or between a security gateway and a host. Compliant implementations MUST support all three forms of connectivity noted here. Kent & Seo [Page 6] Internet Draft Security Architecture for IP January 2004 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. 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. IPsec optionally supports negotiation of IP compression [SMPT98], motivated in part by the observation that when encryption is employed within IPsec, it prevents effective compression by lower protocol layers. Kent & Seo [Page 7] Internet Draft Security Architecture for IP January 2004 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 [KA98a, KA98b]. 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) [Ken04b] offers integrity and data origin authentication, with optional (at the discretion of the receiver) anti-replay features. o The Encapsulating Security Payload (ESP) protocol [Ken04a] offers the same set of services, and also offers confidentially. Use of ESP in a confidentiality-only mode is discouraged. When ESP is used with confidentiality enabled, there are provisions for limited traffic flow confidentiality, i.e., provisions for concealing packet length, and to facilitate 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). These protocols may be applied individually or in combination with each other to provide security services in IPv4 and IPv6. 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. IPsec allows the user (or system administrator) to control the granularity at which a security service is offered. For example, one can create a single encrypted tunnel to carry all the traffic between two security gateways or a separate encrypted tunnel can be created for each TCP connection between each pair of hosts communicating across these gateways. IPsec, through the SPD management paradigm, incorporates facilities for specifying: o which security services to use and in what combinations Kent & Seo [Page 8] Internet Draft Security Architecture for IP January 2004 o the granularity at which protection should be applied o the cryptographic algorithms used to effect cryptographic-based security Because most of the security services provided by IPsec require the use of cryptographic keys, IPsec relies on a separate set of mechanisms for putting these keys in place. This document requires support for both manual and automated distribution of keys. It specifies a specific public-key based approach (IKEv2 [KAU04]) for automated key management, but other automated key distribution techniques MAY be used. Note: This document mandates support for several features for which support is available in IKEv2 but not in IKEv1, e.g., negotiation of an SA representing ranges of source and destination ports or negotiation of multiple SAs with the same selectors. Therefore this document assumes use of IKEv2 or a key and security association management system with comparable features. 3.3 Where IPsec Can Be Implemented There are many ways in which IPsec may be implemented in a host, or in conjunction with a router or firewall to create a security gateway, or as an independent security device. a. IPsec may be integrated into the native IP stack. This requires access to the IP source code and is applicable to both hosts and security gateways, although native host implementations benefit the most from this strategy, as explained later (Section 4.4.1, paragraph 4; Section 4.4.2, 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 an dedicated, inline security protocol processor is a common design feature of systems used by the military, and of some commercial systems as well. It is sometimes referred to as a "bump-in-the-wire" (BITW) implementation. Such implementations may be designed to serve either a host or a gateway. Usually the BITW device is itself IP addressable. When supporting a single host, it may be quite analogous to a BITS implementation, but in supporting a router or firewall, it must operate like a security gateway. Kent & Seo [Page 9] Internet Draft Security Architecture for IP January 2004 This document often talks in terms of host or security gateway use of IPsec, 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. 4. Security Associations This section defines Security Association management requirements for all IPv6 implementations and for those IPv4 implementations that implement AH, ESP, or both. The concept of a "Security Association" (SA) is fundamental to IPsec. Both AH and ESP make use of SAs and a major function of IKE is the establishment and maintenance of Security Associations. All implementations of AH or ESP MUST support the concept of a Security Association as described below. The remainder of this section describes various aspects of Security Association management, defining required characteristics for SA policy management, traffic processing, and SA management techniques. 4.1 Definition and Scope A Security Association (SA) is a simplex "connection" that affords security services to the traffic carried by it. Security services are afforded to an SA by the use of AH, or ESP, but not both. If both AH and ESP protection 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 Security Associations (one in each direction) are required. IKE explicitly creates SA pairs in recognition of this common usage requirement. For an SA used to carry unicast (or anycast) traffic, the SPI (Security Parameters Index - see Appendix A and AH [Ken04b] and ESP [Ken04a] 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 described in AH and ESP for mapping inbound IPsec protected datagrams to SAs. (Implementations that support only unicast traffic need not implement that demultiplexing algorithm.) Note: If different classes of traffic (distinguished by DSCP bits [NiBlBaBL98], [Gro02]) are sent on the same SA, this could result in inappropriate discarding of lower priority packets due to the windowing mechanism used by receivers to reject replays. Therefore a sender SHOULD put traffic of different classes, but with the same Kent & Seo [Page 10] Internet Draft Security Architecture for IP January 2004 selector values, on different SAs to appropriately support QoS. 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. DISCUSSION: While the DSCP [NiBlBaBL98, Gro02] and 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 a security association typically employed between a pair of hosts to provide end-to-end security services. When link (vs. end-to-end) security is desired between two intermediate systems along a path, transport mode MAY be used between security gateways or between a security gateway and a host. In the latter case, transport mode may be used to support IP-in-IP [Per96] or GRE tunneling [FaLiHaMeTr00] over transport mode SAs. 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. 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 [Ken04b]. A tunnel mode SA is essentially an SA applied to an IP tunnel, with Kent & Seo [Page 11] Internet Draft Security Architecture for IP January 2004 the access controls applied to the headers of the traffic inside the tunnel. In general, 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. Note that for the case where traffic is destined for a security gateway, e.g., SNMP commands, the security gateway is acting as a host and transport mode is allowed. In this case, the SA terminates at a host (management) function within a security gateway and thus merits different treatment. Also, as noted above, security gateways MAY support a transport mode SA to provide link security for IP traffic. Two hosts MAY establish a tunnel mode SA between themselves. 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 security gateways, 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. 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. 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 a tunnel mode SA, there is an "outer" IP header that specifies the IPsec processing source and destination, plus an "inner" IP header that specifies the (apparently) ultimate source and destination for the packet. The security protocol header appears after the outer IP header, and before the inner IP header. If AH is employed in tunnel mode, portions of the outer IP header are afforded protection (as above), as well as all of the tunneled IP packet (i.e., all of the inner IP header is protected, as well as next layer protocols). If ESP is employed, the protection is afforded only to the tunneled packet, not to the outer header. In summary, a) A host implementation of IPsec MUST support both transport and tunnel mode. This is true for native, BITS, and BITW implementations for hosts. b) A security gateway MUST support tunnel mode and MAY support transport mode. If it supports transport mode, that should be used only when the security gateway is acting as a host, e.g., for Kent & Seo [Page 12] Internet Draft Security Architecture for IP January 2004 network management, or to provide link security. 4.2 Security Association Functionality The set of security services offered by an SA depends on the security protocol selected, the SA mode, the endpoints of the SA, and on the election of optional services within the protocol. For example, 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 the mutable (non- predictable) parts of the IP or extension headers. 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 security association. 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 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. Kent & Seo [Page 13] Internet Draft Security Architecture for IP January 2004 4.3 Combining Security Associations 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 function 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. 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 deemed compliant. There are two nominal databases in this model: the Security Policy Database and the Security Association Database. The first specifies the policies that determine the disposition of all IP traffic inbound or outbound from a host or security gateway. The second database contains parameters that are associated with each established (keyed) security association. A third database, the Peer Authorization Database (PAD) is also required. The PAD provides a link between an SA management protocol like IKE and the SPD. The PAD indicates the range of identities that a peer is authorized to represent when (child) SAs are negotiated with the peer. The identities may be a list of IP address ranges or symbolic names. The fundamental requirement associated with the PAD is that the traffic selectors passed by the SA management protocol for comparison against the SPD MUST be verified as authorized relative to the authenticated peer of the SA management protocol. (See also Section 4.5.3, which levies requirements on the PAD in Kent & Seo [Page 14] Internet Draft Security Architecture for IP January 2004 support of locating security gateways.) The PAD also specifies how to authenticate each peer, e.g., via shared secret or use of a certificate. If a shared secret is used, the secret is stored here. If a certificate is used, the trust anchor for the certificate is part of the PAD. Because the PAD might be incorporated into the SA management protocol implementation, it is not discussed extensively in this document. If an IPsec implementation acts as a security gateway for multiple subscribers, it MAY implement multiple separate IPsec contexts. Each context MAY have and 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. 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 there are multiple protected or unprotected interfaces or 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. 4.4.1 The Security Policy Database (SPD) A security association 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 non-IPsec traffic, that traverses the IPsec Kent & Seo [Page 15] Internet Draft Security Architecture for IP January 2004 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 ID. Each SPD entry is either implicitly or explicitly directional. For traffic protected by IPsec, the source and destination address and ports are swapped to represent directionality, consistent with IKE conventions. For bypassed or discarded traffic, separate inbound and outbound entries are supported, e.g., to permit unidirectional flows if required. 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. 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. (Native host implementations have an implicit form of caching available, due to the use of, for example, socket interfaces for applications, and thus there is no requirement to be able to decorrelate SPD entries in these implementations.) Decorrelation is a means of improving performance and simplifying the processing description; it is not a requirement for a compliant implementation. 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 grouped 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. The intent is that use of a decorrelated SPD ought not create more SAs than would have resulted from use of a not-decorrelated SPD. Kent & Seo [Page 16] Internet Draft Security Architecture for IP January 2004 An SPD must discriminate among traffic that is afforded IPsec protection and traffic that is allowed to bypass IPsec. This applies to the IPsec protection to be applied by a sender and to the IPsec protection that must be present at the receiver. For any outbound or inbound datagram, three processing choices are possible: discard, bypass IPsec, or apply IPsec. The first choice refers to traffic that is not allowed to traverse the IPsec boundary (in the specified direction). The second choice refers to traffic that is allowed to pass without additional IPsec protection. The third choice refers to traffic that is afforded IPsec protection, and for such traffic the SPD must specify the security protocols to be employed, their mode, security service options, and the cryptographic algorithms to be used. An SPD is logically divided into three pieces, all of which should be decorrelated (with the exception noted above for native host implementations) to facilitate caching. 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. 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, the same rule applies here, i.e., 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. 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.2, 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 Kent & Seo [Page 17] Internet Draft Security Architecture for IP January 2004 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. Each SPD entry specifies packet disposition as BYPASS, DISCARD, or IPsec. 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.2. 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 SPD MUST permit a user or administrator to specify policy entries as follows: - SPD-I: For inbound traffic that is to be bypassed or discarded, the entry consists of the values of the selectors that apply to the traffic to be bypassed or discarded. - SPD-O: For outbound traffic that is to be bypassed or discarded, the entry consists of the values of the selectors that apply to the traffic to be bypassed or discarded. - SPD-S: For traffic that is to be protected using IPsec, the entry consists of the values of the selectors that apply to the traffic that the initiator will send or receive and the values that apply to the traffic that the responder will receive or send. - The selector types are defined in Section 4.2.2 below. 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. The former value is a wildcard that matches any value in the corresponding field of the packet, whereas the latter value indicates that the corresponding selector field is not examined, e.g., because it may be obscured by encryption already applied to the packet or may not be present in a fragment. For each selector in an SPD entry, the policy entry specifies how to derive the corresponding values for a new Security Association Database (SAD, see Section 4.4.3) entry from those in the SPD and the packet. 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. If IPsec processing is specified for an entry, a "populate from packet" (PFP) flag may be asserted for one or more of the selector types in the SPD entry. If present, the flag applies to all selectors of the indicated type in the outbound element of the pair. (PFP does not apply to inbound traffic.) Kent & Seo [Page 18] Internet Draft Security Architecture for IP January 2004 Note that this text describes the representation in the SPD that maps into IKE payloads, i.e., one should not create SPD entries that cannot be mapped into what IKE can negotiate. 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".) If the reserved, symbolic selector value OPAQUE or ANY is employed for a given selector type, only it may appear in the list for that type, and it must appear only once in the list for that type. Note that "ANY" is a local syntax convention - IKE handles this concept via ranges. 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 destination address is a range of IPv4 addresses: 192.168.2.1 to 192.168.2.10. Suppose an outbound packet arrives with a destination address of 192.168.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: source for the example of new value to be SAD destination address used in the SA selector value --------------- ------------ a. PFP TRUE 192.168.2.3 (one host) b. PFP FALSE 192.168.2.1 to 192.168.2.10 (range of hosts) Note that if the SPD entry had a value of ANY for the destination 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. 4.4.2 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 Protocol and Port fields), with different security services offered by different SAs. Similarly, all traffic between a pair of security gateways could be carried on a single SA, or one SA could be assigned for each Kent & Seo [Page 19] Internet Draft Security Architecture for IP January 2004 communicating host pair. The following selector parameters MUST be supported by all IPsec implementations to facilitate control of SA granularity. Note that both Source and Destination addresses should either be IPv4 or IPv6, but not a mix of address types. Also, note that the source/destination port selectors may be labeled as "OPAQUE" to accommodate situations where these fields are inaccessible because of prior encryption or due to packet fragmentation. - Destination IP Address (IPv4 or IPv6): this is a list of ranges of IP addresses (unicast, anycast, broadcast (IPv4 only), or multicast group). This structure allows expression of a single IP address (via a trivial range), or a list of addresses (each a trivial ranges), or a range of addresses (high and low values, inclusive), as well as the most generic form of a list of ranges. Address ranges are used to support more than one destination system sharing the same SA, e.g., behind a security gateway. - Source IP Address(es) (IPv4 or IPv6): this is a list of ranges of IP addresses (unicast, anycast, broadcast (IPv4 only), or multicast group). This structure allows expression of a single IP address (via a trivial range), or a list of addresses (each a trivial ranges), or a range of addresses (high and low 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. - Next Layer Protocol: Obtained from the IPv4 "Protocol" or the IPv6 "Next Header" fields. This is an individual protocol number, or ANY. The Next Layer Protocol is whatever comes after any IP extension headers that are present. To simplify locating the Next Layer Protocol in the IPv6 context, there SHOULD be a mechanism for configuring which IP extension headers to skip, e.g., Destination Options, Routing Header, Fragmentation Header, Mobility Header, Hop-by-hop options, etc. Several additional selectors depend on the Next Layer Protocol value: * If the Next Layer Protocol uses ports (e.g., TCP, UDP, SCTP, ...), then there are selectors for Source and Destination Ports: Each of these selectors is a list of ranges of values. Note that the source and destination ports may not be available in the case of receipt of a fragmented packet, thus a value of "OPAQUE" also MUST be supported. Note: In a non-initial fragment, port values will not be available. If the SA requires a non-OPAQUE port value, an arriving fragment MUST be discarded. Kent & Seo [Page 20] Internet Draft Security Architecture for IP January 2004 * 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. * If the Next Layer Protocol value is ICMP then there are selectors 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 single 8-bit value that defines a specific subtype for an ICMP message. This selector can be a single value, or ANY. - Name: A name is used as a symbolic identifier for an IPsec source or destination address. Thus an SPD entry that has a non- null Name selector MUST set either the source or destination IP address selector to NULL in the corresponding, directional SPD entry. a. an RFC 822 address, e.g., mozart@foo.example.com b. X.500 distinguished name c. a fully qualified DNS name, e.g., foo.example.com Use of this selector is different from all the other selectors described above. Names do not appear in packets, so it is not possible to match a packet against an SPD entry based on a Name selector. Name selectors are used to trigger creation of SPD cache (SPD-S and SPD-O) (and SAD) entries, which are then populated with specific IP source or destination addresses provided by the SA management protocol. For a native host implementation, a Name may be used in an SPD entry to provide finer granularity access control that would be otherwise be available on multi-user systems. In this case, the entry may be consulted when SA creation is initiated by the host, or when the host is a responder. The Name refers to an entity at the host in question, and the implementation relies on its integration into the host OS to ensure appropriate linking to the named entity's process. The other use for the Name selector occurs when any IPsec implementation (native host, BITW, BITS, or security gateway) is contacted by a peer whose address cannot be known a priori, e.g., a road warrior. In this context, the Name is used in lieu of the IP address of the peer, who must be an initiator of the SA creation. [This selector description may change based on discussion of some name/identity issues that haven't yet been posted to the list.] 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 Kent & Seo [Page 21] Internet Draft Security Architecture for IP January 2004 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/SPD-S cache lookup based on the selectors. 4.4.3 Security Association Database (SAD) In each IPsec implementation there is a nominal Security Association Database, in which each entry defines the parameters associated with one SA. Each SA has an entry in the SAD. For outbound processing, entries are pointed to by entries in the SPD-S part of the SPD cache. For inbound processing, each entry in the SAD is indexed by an SPI (from the AH or ESP protocol header), plus source and/or destination address for multicast SAs, as noted earlier. 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.2, the entry for an inbound SA in the SAD MUST contain the value or values negotiated at the time the SA was created. For a receiver, these values are used to check that the header fields of an inbound packet match the selector values negotiated for the SA. For the receiver, this is part of verifying that a packet arriving on an SA is consistent with the policy for the SA. (See Section 6 for rules for ICMP messages.) These fields can have the form of specific values, ranges, ANY, or "OPAQUE" as described in section 4.4.2, "Selectors." 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 or 32-bit value 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 Kent & Seo [Page 22] Internet Draft Security Architecture for IP January 2004 rollover is permitted. The audit log entry for this event SHOULD include the SPI value, current date/time, Source Address, Destination 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. o AH Authentication algorithm, key, etc. This is required only if AH is supported. o ESP Encryption algorithm, key, mode, IV, etc. o ESP integrity algorithm, keys, etc. If the integrity service is not selected, these fields will be null. o ESP combined mode algorithms, key(s), etc. This data is used when a combined mode (encryption and integrity) algorithm is used with ESP. o Lifetime of this Security Association: a time interval after which an SA must be replaced with a new SA (and new SPI) or terminated, plus an indication of which of these actions should occur. This may be expressed as a time or byte count, or a simultaneous use of both 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 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 SHOULD be able to handle having the counters at the ends of an SA get out of synch, e.g., because of packet Kent & Seo [Page 23] Internet Draft Security Architecture for IP January 2004 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 Path MTU: any observed path MTU and aging variables. See Section 6.1.2.4 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. The following table summarizes the kinds of entries that one needs to be able to express in the SPD and SAD. It also shows how they relate to the fields in data traffic being subjected to IPsec screening. [Table to be added in a future draft.] 4.5 SA and Key Management IPsec mandates support for both manual and automated SA and cryptographic key management. The IPsec protocols, AH and ESP, are largely independent of the associated SA management techniques, although the techniques involved do affect some of the security services offered by the protocols. For example, the optional anti- replay 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. The following text describes the minimum requirements for both types of SA management. Kent & Seo [Page 24] Internet Draft Security Architecture for IP January 2004 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 security association management data relevant to secure communication with other systems. Manual techniques are practical in small, static environments but they do not scale well. For example, a company could create a Virtual Private Network (VPN) using IPsec in security gateways at several sites. If the number of sites is small, and since all the sites come under the purview of a single administrative domain, this might be a feasible context for manual management techniques. In this case, the security gateway might selectively protect traffic to and from other sites within the organization using a manually configured key, while not protecting traffic for other destinations. It also might be appropriate when only selected communications need to be secured. A similar argument might apply to use of IPsec entirely within an organization for a small number of hosts and/or gateways. Manual management techniques often employ statically configured, symmetric keys, though other options also exist. 4.5.2 Automated SA and Key Management Widespread deployment and use of IPsec requires an Internet-standard, scalable, automated, SA management protocol. Such support is required to facilitate use of the anti-replay features of AH and ESP, and to accommodate on-demand creation of SAs, e.g., for user- and session- oriented keying. (Note that the notion of "rekeying" an SA actually implies creation of a new SA with a new SPI, a process that generally implies use of an automated SA/key management protocol.) The default automated key management protocol selected for use with IPsec is IKEv2 [Kau04]. 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 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 Kent & Seo [Page 25] Internet Draft Security Architecture for IP January 2004 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. Consider a situation in which a remote host (H1) is using the Internet to gain access to a server or other machine (H2) and there is a security gateway (SG2), e.g., a firewall, through which H1's traffic must pass. An example of this situation would be a mobile host (road warrior) crossing the Internet to his home organization's firewall (SG2). This situation raises several issues: 1. How does H1 know/learn about the existence of the security gateway SG2? 2. How does it authenticate SG2, and once it has authenticated SG2, how does it confirm that SG2 has been authorized to represent H2? 3. How does SG2 authenticate H1 and verify that H1 is authorized to contact H2? 4. How does H1 know/learn about any additional gateways that provide alternate paths to H2? To address these problems, a host or security gateway MUST have an administrative interface that allows the user/administrator to configure the address of one or more security gateways for ranges of destination addresses that require its use. This includes the ability to configure information for locating and authenticating one or more security gateways and verifying the authorization of these gateways to represent the destination host. (The authorization Kent & Seo [Page 26] Internet Draft Security Architecture for IP January 2004 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 Security Associations and Multicast The receiver-orientation of the Security Association 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 Security Associations to conflict with automatically configured (e.g., via a key management protocol) Security Associations or for Security Associations from multiple sources to conflict with each other. For multicast traffic, there are multiple destination systems 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 Security Parameter Index) 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's 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 be consulted during the processing of all traffic that crosses the IPsec 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 traffic (SPD-I). There is nominally one cache per SPD. 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 Kent & Seo [Page 27] Internet Draft Security Architecture for IP January 2004 match against a different entry. But, if the SPD entries are first decorrelated, then the resulting entries can safely be cached, and each cached entry will map to an SA (or multiple SAs if "populate from packet" (PFP) is specified), or indicate that matching traffic should be bypassed or discarded, appropriately. 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 allow caching of 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 28] Internet Draft Security Architecture for IP January 2004 Unprotected Interface ^ | +----------+ ...................|Forwarding|<-----+ : +----------+ | : ^ | : | Bypass | : +-----+ | +-------+ +-------+ | SPD | +--------+ | SPD-I | |Discard|<---|Cache|---->| AH/ESP | +-------+ +-------+ +-----+ +--------+ : ^ : | : +-------------+ :................>|SPD Selection| +-------------+ ^ | Protected Interface Figure 2. Processing Model for Outbound Traffic IPsec MUST perform the following steps when processing outbound packets: 1. when a packet arrives from the subscriber (protected) interface, invoke the SPD lookup function to select the appropriate SPD. (If the implementation uses only one SPD, this step is a no-op.) 2. Match the packet headers against the cache for the SPD specified by the SPD-ID from step 1. Note that this cache contains entries from SPD-O and SPD-S. 3a. If there is a match, then process the packet as specified by the matching cache entry, i.e., bypass, discard, or apply AH or ESP in the specified mode. If IPsec processing is applied, there is a link from the SPD cache entry to the relevant SAD entry (specifying the cryptographic algorithms, keys, SPI, etc.). IPsec processing is as previously defined, for tunnel or transport modes and for AH or ESP, as specified in their respective RFCs [Ken04b and Ken04a]. 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 new outbound and inbound SPD cache entries. If the Kent & Seo [Page 29] Internet Draft Security Architecture for IP January 2004 SPD entry calls for creation of an SA, the key management mechanism (e.g., IKEv2) is invoked to create the SA. If SA creation succeeds, a new outbound (SPD-S) cache entry is created, along with an SAD entry, 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 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 bypass of the packet. 5.1.1 Handling an Outbound Packet That Must Be Dropped If an IPsec system receives an outbound packet which it finds it must drop, it SHOULD be capable of generating and sending an ICMP message to indicate to the sender of the outbound packet that the packet was dropped. The type and code of the ICMP message will depend on the reason for dropping 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 of the packet. a. the selectors of the packet matched an SPD entry requiring the packet to be dropped --> 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 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 is administratively prohibited from communicating with the initiator and rejects the negotiation. IPv4 Type = 3 (destination unreachable) Code = 13 (Communication Administratively Prohibited) Kent & Seo [Page 30] Internet Draft Security Architecture for IP January 2004 IPv6 Type = 1 (destination unreachable) Code = 1 (Communication with destination administratively prohibited) b2. the IPsec system was unable to set up the SA required by the SPD entry matching the packet because the IPsec peer at the other end of the exchange could not be contacted. IPv4 Type = 3 (destination unreachable) Code = 1 (host unreachable) IPv6 Type = 1 (destination unreachable) Code = 3 (address unreachable) Note that an attacker behind a security gateway could send packets with a spoofed source address, W.X.Y.Z, to an IPsec entity causing it to send ICMP messages to W.X.Y.Z. This creates an opportunity for a 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 ECN Field. 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 Kent & Seo [Page 31] Internet Draft Security Architecture for IP January 2004 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: 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 DSCP field for tunnel mode for transmitted packets. For outbound traffic, one configuration setting for DSCP will operate as described in the following sections on IPv4 and IPv6 header processing for IPsec tunnels. Another will allow the DSCPfield 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 DSCP. 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 32] Internet Draft Security Architecture for IP January 2004 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 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. src and dest addresses depend on the SA, which is used to determine the dest address which in turn determines which src address (net interface) is used to forward the packet. Note: The source address that appears in the encapsulating tunnel header MUST be the one that was negotiated during the SA establishment process. In principle, the encapsulating IP source address can be any of the encapsulator's interface addresses or even an address different from any of the encapsulator's IP addresses, (e.g., if it's acting as a NAT box) so long as the address is reachable through the encapsulator Kent & Seo [Page 33] Internet Draft Security Architecture for IP January 2004 from the environment into which the packet is sent. 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] 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 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 ECN Field copied from inner hdr constructed (6) flow label copied or configured 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 no change Note: IPsec does not copy the extension headers from the inner header into the outer header, nor does IPsec construct extension headers in the outer header. However, post-IPsec code MAY insert/construct extension headers for the outer header. Kent & Seo [Page 34] Internet Draft Security Architecture for IP January 2004 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 the IPsec processing. The intent for any SPD cache is that a packet that fails to match any entry is then referred to the corresponding SPD. Every SPD SHOULD have a nominal, final entry that catches anything that is otherwise unmatched, and discards it. This ensures that non-IPsec protected traffic that arrives and does not match any SPD-I entry will be discarded. Unprotected Interface | V +-----+ IPsec protected ...................>|Demux|-------------------+ : +-----+ | : | | : | Not IPsec | : |-----------+ | : V | | : +-------+ V V +-----+ +-------+ |Bypass/| +------+ +------+ |SPD-O| |Discard|<---|Discard| | ICMP | |AH/ESP| +-----+ +-------+ +-------+ +------+ +------+ ^ | | : | +---+ | : Bypass | +-->|IKE| | : | | +---+ | : V | V : +----------+ +---------+ :...............|Forwarding|<------------|SAD Check| +----------+ +---------+ | V Protected Interface Figure 3. Inbound Traffic Processing Model 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 an extension header in the IPv6 Kent & Seo [Page 35] Internet Draft Security Architecture for IP January 2004 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 with different SPD-I entries. 2. The packet is examined and demuxed into one of three 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. - Traffic not addressed to this device is directed to BYPASS/DISCARD lookup. 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. - ICMP traffic directed to this device is directed to "unprotected" ICMP processing (see Section 6). 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 identified by the SPD-ID from step 1. For unicast traffic, use only the SPI. For multicast traffic, use the SPI plus the source and/or destination addresses, as specified in the SAD. 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, look up the packet header in the (appropriate) SPD-I cache. If there is a match and the packet is to be discarded or bypassed, do so. If there is no cache match, look up the packet in the corresponding SPD-I and create a cache entry as appropriate. (No SAs are created in response to receipt of a packet that requires IPsec protection; only bypass or discard 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. Unprotected ICMP processing 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 Kent & Seo [Page 36] Internet Draft Security Architecture for IP January 2004 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 2a 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. 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 drop 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 to the sender (IPsec peer), indicating that the received packet was dropped because of failure to pass selector checks. NOTIFY MESSAGES - ERROR TYPES Value ----------------------------- ----- INVALID_SELECTORS iana-tbd MAY be sent in an IKE INFORMATIONAL Exchange when a node receives an ESP or AH packet whose selectors do not match those of the SA on which it was delivered (and which caused the packet to be dropped). The Notification Data contains the start of the offending packet (as in ICMP messages) and the SPI field of the notification is set to match the SPI of the IPsec SA. 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 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 37] Internet Draft Security Architecture for IP January 2004 6. ICMP Processing [This section will be filled in when IPsec issue # 91 is resolved. The following text needs to be inserted somewhere, possibly this section.] NOTE: With the exception of IPv4 transport mode, an SG, BITS, or BITW implementation MAY fragment packets before applying IPsec. The device SHOULD have a configuration setting to disable this. The resulting fragments are evaluated against the SPD in the normal manner. Thus, fragments not containing port numbers may only match rules having port selectors of OPAQUE or "ANY". 7. Auditing Not all systems that implement IPsec will implement 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. 8. Conformance Requirements All IPv4 systems that claim to implement IPsec MUST comply with all requirements of this document. All IPv6 systems that claim to implement IPsec MUST comply with all requirements of this document. 9. Security Considerations The focus of this document is security; hence security considerations permeate this specification. 10. Differences from RFC 2401 [Will be updated when things have settled down.] This architecture document differs substantially from RFC 2401 in detail and in organization, but the fundamental notions are unchanged. Kent & Seo [Page 38] Internet Draft Security Architecture for IP January 2004 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. Also a contributor who wishes to remain nameless, deserves special thanks for providing extensive help in the editing of this specification. 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 39] Internet Draft Security Architecture for IP January 2004 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 Kent & Seo [Page 40] Internet Draft Security Architecture for IP January 2004 identity of the claimed source of data. This service is usually 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 barrier 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 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. 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. Kent & Seo [Page 41] Internet Draft Security Architecture for IP January 2004 Security Association (SA) A simplex (uni-directional) logical connection, created for security purposes. All traffic traversing an SA is provided the same security processing. In IPsec, an SA is an internet layer abstraction implemented through the use of AH or ESP. State data associated with an SA is represented in the Security Association 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 at generally at least less protected than those "behind the SG), while the networks and hosts and 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 combination of a destination address, a security protocol, and an SPI uniquely identifies a security association (SA, see above) in the context of unicast or anycast traffic. 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 42] Internet Draft Security Architecture for IP January 2004 Appendix B - Decorrelation This section is based on work done 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. Those of the resulting entries that are decorrelated with the decorrelated set of entries are then added to that decorrelated set. 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. A policy (SPD entry) P may be expressed as a sequence of selector values and an action (Bypass, Discard, or apply IPsec): Pi = 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. Kent & Seo [Page 43] Internet Draft Security Architecture for IP January 2004 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, Scjn, 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 Scjn that appears in any of the entries in T. (If the value is a superset of the value of Scjn 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 Scjn in T. When taking the complement, remember that the universal set is the value of Scjn 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. 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 Kent & Seo [Page 44] Internet Draft Security Architecture for IP January 2004 selectors used for the next branch. For example, if a selector Scjn can be chosen so that all the values for that selector in T are equal to or a superset of the value of Scjn 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 45] Internet Draft Security Architecture for IP January 2004 Appendix C -- Categorization of ICMP messages [May be deleted] The tables below characterize ICMP messages as being either host generated, router generated, both, unassigned/unknown. The first set of messages are for IPv4. The second set of messages are for IPv6. IPv4 Type Name/Codes Reference ======================================================================== HOST GENERATED: 3 Destination Unreachable 2 Protocol Unreachable [RFC792] 3 Port Unreachable [RFC792] 8 Source Host Isolated [RFC792] 14 Host Precedence Violation [RFC1812] 10 Router Selection [RFC1256] Type Name/Codes Reference ======================================================================== ROUTER GENERATED: 3 Destination Unreachable 0 Net Unreachable [RFC792] 4 Fragmentation Needed, Don't Fragment was Set [RFC792] 5 Source Route Failed [RFC792] 6 Destination Network Unknown [RFC792] 7 Destination Host Unknown [RFC792] 9 Comm. w/Dest. Net. is Administratively Prohibited [RFC792] 11 Destination Network Unreachable for Type of Service[RFC792] 5 Redirect 0 Redirect Datagram for the Network (or subnet) [RFC792] 2 Redirect Datagram for the Type of Service & Network[RFC792] 9 Router Advertisement [RFC1256] 18 Address Mask Reply [RFC950] Kent & Seo [Page 46] Internet Draft Security Architecture for IP January 2004 IPv4 Type Name/Codes Reference ======================================================================== BOTH ROUTER AND HOST GENERATED: 0 Echo Reply [RFC792] 3 Destination Unreachable 1 Host Unreachable [RFC792] 10 Comm. w/Dest. Host is Administratively Prohibited [RFC792] 12 Destination Host Unreachable for Type of Service [RFC792] 13 Communication Administratively Prohibited [RFC1812] 15 Precedence cutoff in effect [RFC1812] 4 Source Quench [RFC792] 5 Redirect 1 Redirect Datagram for the Host [RFC792] 3 Redirect Datagram for the Type of Service and Host [RFC792] 6 Alternate Host Address [JBP] 8 Echo [RFC792] 11 Time Exceeded [RFC792] 12 Parameter Problem [RFC792,RFC1108] 13 Timestamp [RFC792] 14 Timestamp Reply [RFC792] 15 Information Request [RFC792] 16 Information Reply [RFC792] 17 Address Mask Request [RFC950] 30 Traceroute [RFC1393] 31 Datagram Conversion Error [RFC1475] 32 Mobile Host Redirect [Johnson] 39 SKIP [Markson] 40 Photuris [Simpson] Type Name/Codes Reference ======================================================================== UNASSIGNED TYPE OR UNKNOWN GENERATOR: 1 Unassigned [JBP] 2 Unassigned [JBP] 7 Unassigned [JBP] 19 Reserved (for Security) [Solo] 20-29 Reserved (for Robustness Experiment) [ZSu] 33 IPv6 Where-Are-You [Simpson] 34 IPv6 I-Am-Here [Simpson] 35 Mobile Registration Request [Simpson] 36 Mobile Registration Reply [Simpson] 37 Domain Name Request [Simpson] 38 Domain Name Reply [Simpson] 41-255 Reserved [JBP] Kent & Seo [Page 47] Internet Draft Security Architecture for IP January 2004 IPv6 Type Name/Codes Reference ======================================================================== HOST GENERATED: 1 Destination Unreachable [RFC 1885] 4 Port Unreachable Type Name/Codes Reference ======================================================================== ROUTER GENERATED: 1 Destination Unreachable [RFC1885] 0 No Route to Destination 1 Comm. w/Destination is Administratively Prohibited 2 Not a Neighbor 3 Address Unreachable 2 Packet Too Big [RFC1885] 0 3 Time Exceeded [RFC1885] 0 Hop Limit Exceeded in Transit 1 Fragment reassembly time exceeded Type Name/Codes Reference ======================================================================== BOTH ROUTER AND HOST GENERATED: 4 Parameter Problem [RFC1885] 0 Erroneous Header Field Encountered 1 Unrecognized Next Header Type Encountered 2 Unrecognized IPv6 Option Encountered Kent & Seo [Page 48] Internet Draft Security Architecture for IP January 2004 References [Will be updated after the text settles down] Normative [Bra97] Bradner, S., "Key words for use in RFCs to Indicate Requirement Level", BCP 14, RFC 2119, March 1997. [DH98] Deering, S., and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [Eas03] Eastlake, D., "Cryptographic Algorithm Implementation Requirements For ESP And AH", draft-ietf-ipsec-esp-ah- algorithms-00.txt, December 2003. [HC03] Holbrook, H., and Cain, B., "Source Specific Multicast for IP", Internet Draft, draft-ietf-ssm-arch-01.txt, November 3, 2002. [Kau03] Kaufman, C., "The Internet Key Exchange (IKEv2) Protocol", draft-ietf- ipsec-ikev2-11.txt, October 2003 [Ken04a] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC ???, ???? 2004. [Ken04b] Kent, S., "IP Authentication Header", RFC ???, ??? 2004. [Mobip] Johnson, D., Perkins, C., Arkko, J., "Mobility Support in IPv6", Internet Draft, draft-ietf-mobileip-ipv6-24.txt, June 2003 [Pos81] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981 [Sch03] Schiller, J., "Cryptographic Algorithms for use in the Internet Key Exchange Version 2", draft-ietf-ipsec- ikev2-algorithms-04.txt, September 2003 Informative [BL73] Bell, D.E. & LaPadula, L.J., "Secure Computer Systems: Mathematical Foundations and Model", Technical Report M74-244, The MITRE Corporation, Bedford, MA, May 1973. [DoD85] US National Computer Security Center, "Department of Defense Trusted Computer System Evaluation Criteria", DoD 5200.28-STD, US Department of Defense, Ft. Meade, MD., December 1985. Kent & Seo [Page 49] Internet Draft Security Architecture for IP January 2004 [DoD87] US National Computer Security Center, "Trusted Network Interpretation of the Trusted Computer System Evaluation Criteria", NCSC-TG-005, Version 1, US Department of Defense, Ft. Meade, MD., 31 July 1987. [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. [HA94] Haller, N., and Atkinson, R., "On Internet Authentication", RFC 1704, October 1994 [ISO] ISO/IEC JTC1/SC6, Network Layer Security Protocol, ISO-IEC DIS 11577, International Standards Organisation, Geneva, Switzerland, 29 November 1992. [IB93] Ioannidis, J. and Blaze, M., "Architecture and Implementation of Network-layer Security Under Unix", Proceedings of USENIX Security Symposium, Santa Clara, CA, October 1993. [IBK93] Ioannidis, J., Blaze, M., and Karn, P., "swIPe: Network- Layer Security for IP", presentation at the Spring 1993 IETF Meeting, Columbus, Ohio [Ken91] Kent, S., "US DoD Security Options for the Internet Protocol", RFC 1108, November 1991. [MSST97] Maughan, D., Schertler, M., Schneider, M., and J. Turner, "Internet Security Association and Key Management Protocol (ISAKMP)", RFC 2408, November 1998. [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. [Orm97] Orman, H., "The OAKLEY Key Determination Protocol", RFC 2412, November 1998. [Per96] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1996. [Pip98] Piper, D., "The Internet IP Security Domain of Interpretation for ISAKMP", RFC 2407, November 1998. Kent & Seo [Page 50] Internet Draft Security Architecture for IP January 2004 [RaFlBL01]Ramakrishnan, K., Floyd, S., Black, D., "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001. [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. [SDNS] SDNS Secure Data Network System, Security Protocol 3, SP3, Document SDN.301, Revision 1.5, 15 May 1989, published in NIST Publication NIST-IR-90-4250, February 1990. [SMPT98] Shacham, A., Monsour, R., Pereira, R., and M. Thomas, "IP Payload Compression Protocol (IPComp)", RFC 2393, August 1998. [VK83] V.L. Voydock & S.T. Kent, "Security Mechanisms in High- level Networks", ACM Computing Surveys, Vol. 15, No. 2, June 1983. 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 51] Internet Draft Security Architecture for IP January 2004 Notices The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards- related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Copyright (C) The Internet Society (2004). All Rights Reserved. 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 implementation 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. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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 Kent & Seo [Page 52] Internet Draft Security Architecture for IP January 2004 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Expires July 2004 Kent & Seo [Page 53] ----