RFC 6071
IP Security (IPsec) and Internet Key Exchange (IKE) Document Roadmap
Internet Engineering Task Force (IETF) S. Frankel Request for Comments: 6071 NIST Obsoletes: 2411 S. Krishnan Category: Informational Ericsson ISSN: 2070-1721 February 2011 IP Security (IPsec) and Internet Key Exchange (IKE) Document RoadmapAbstract
Over the past few years, the number of RFCs that define and use IPsec and Internet Key Exchange (IKE) has greatly proliferated. This is complicated by the fact that these RFCs originate from numerous IETF working groups: the original IPsec WG, its various spin-offs, and other WGs that use IPsec and/or IKE to protect their protocols' traffic. This document is a snapshot of IPsec- and IKE-related RFCs. It includes a brief description of each RFC, along with background information explaining the motivation and context of IPsec's outgrowths and extensions. It obsoletes RFC 2411, the previous "IP Security Document Roadmap." The obsoleted IPsec roadmap (RFC 2411) briefly described the interrelationship of the various classes of base IPsec documents. The major focus of RFC 2411 was to specify the recommended contents of documents specifying additional encryption and authentication algorithms. Status of This Memo This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6071.
Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.Table of Contents
1. Introduction ....................................................4 2. IPsec/IKE Background Information ................................5 2.1. Interrelationship of IPsec/IKE Documents ...................5 2.2. Versions of IPsec ..........................................6 2.2.1. Differences between "Old" IPsec (IPsec-v2) and "New" IPsec (IPsec-v3) ..............................6 2.3. Versions of IKE ............................................7 2.3.1. Differences between IKEv1 and IKEv2 .................8 2.4. IPsec and IKE IANA Registries ..............................9 3. IPsec Documents .................................................9 3.1. Base Documents .............................................9 3.1.1. "Old" IPsec (IPsec-v2) ..............................9 3.1.2. "New" IPsec (IPsec-v3) .............................11 3.2. Additions to IPsec ........................................11 3.3. General Considerations ....................................14 4. IKE Documents ..................................................15 4.1. Base Documents ............................................15 4.1.1. IKEv1 ..............................................15 4.1.2. IKEv2 ..............................................16
4.2. Additions and Extensions ..................................17
4.2.1. Peer Authentication Methods ........................17
4.2.2. Certificate Contents and Management (PKI4IPsec) ....18
4.2.3. Dead Peer Detection ................................19
4.2.4. Remote Access ......................................19
5. Cryptographic Algorithms and Suites ............................21
5.1. Algorithm Requirements ....................................22
5.2. Encryption Algorithms .....................................23
5.3. Integrity-Protection (Authentication) Algorithms ..........27
5.4. Combined Mode Algorithms ..................................30
5.5. Pseudo-Random Functions (PRFs) ............................33
5.6. Cryptographic Suites ......................................34
5.7. Diffie-Hellman Algorithms .................................35
6. IPsec/IKE for Multicast ........................................36
7. Outgrowths of IPsec/IKE ........................................38
7.1. IPsec Policy ..............................................38
7.2. IPsec MIBs ................................................39
7.3. IPComp (Compression) ......................................39
7.4. Better-Than-Nothing Security (BTNS) .......................39
7.5. Kerberized Internet Negotiation of Keys (KINK) ............40
7.6. IPsec Secure Remote Access (IPSRA) ........................41
7.7. IPsec Keying Information Resource Record (IPSECKEY) .......42
8. Other Protocols That Use IPsec/IKE .............................42
8.1. Mobile IP (MIPv4 and MIPv6) ...............................42
8.2. Open Shortest Path First (OSPF) ...........................44
8.3. Host Identity Protocol (HIP) ..............................45
8.4. Stream Control Transmission Protocol (SCTP) ...............46
8.5. Robust Header Compression (ROHC) ..........................46
8.6. Border Gateway Protocol (BGP) .............................47
8.7. IPsec Benchmarking ........................................47
8.8. Network Address Translators (NAT) .........................48
8.9. Session Initiation Protocol (SIP) .........................48
8.10. Explicit Packet Sensitivity Labels .......................49
9. Other Protocols That Adapt IKE for Non-IPsec Functionality .....49
9.1. Extensible Authentication Protocol (EAP) ..................49
9.2. Fibre Channel .............................................49
9.3. Wireless Security .........................................50
10. Acknowledgements ..............................................50
11. Security Considerations .......................................50
12. References ....................................................50
12.1. Informative References ...................................50
Appendix A. Summary of Algorithm Requirement Levels ..............61
1. Introduction
IPsec (Internet Protocol Security) is a suite of protocols that provides security to Internet communications at the IP layer. The most common current use of IPsec is to provide a Virtual Private Network (VPN), either between two locations (gateway-to-gateway) or between a remote user and an enterprise network (host-to-gateway); it can also provide end-to-end, or host-to-host, security. IPsec is also used by other Internet protocols (e.g., Mobile IP version 6 (MIPv6)) to protect some or all of their traffic. IKE (Internet Key Exchange) is the key negotiation and management protocol that is most commonly used to provide dynamically negotiated and updated keying material for IPsec. IPsec and IKE can be used in conjunction with both IPv4 and IPv6. In addition to the base documents for IPsec and IKE, there are numerous RFCs that reference, extend, and in some cases alter the core specifications. This document obsoletes [RFC2411]. It attempts to list and briefly describe those RFCs, providing context and rationale where indicated. The title of each RFC is followed by a letter that indicates its category in the RFC series [RFC2026], as follows: o S: Standards Track (Proposed Standard, Draft Standard, or Standard) o E: Experimental o B: Best Current Practice o I: Informational For each RFC, the publication date is also given. This document also categorizes the requirements level of each cryptographic algorithm for use with IKEv1, IKEv2, IPsec-v2, and IPsec-v3. These requirements are summarized in Appendix A. These levels are current as of February 2011; subsequent RFCs may result in altered requirement levels. This document does not define requirement levels; it simply restates those found in the IKE and IPsec RFCs. If there is a conflict between this document and any other RFC, then the other RFC takes precedence. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
2. IPsec/IKE Background Information
2.1. Interrelationship of IPsec/IKE Documents
The main documents describing the set of IPsec protocols are divided into seven groups. This is illustrated in Figure 1. There is a main Architecture document that broadly covers the general concepts, security requirements, definitions, and mechanisms defining IPsec technology. There are an Encapsulating Security Payload (ESP) Protocol document and an Authentication Header (AH) Protocol document that cover the packet format and general issues regarding the respective protocols. The "Encryption Algorithm" document set, shown on the left, is the set of documents describing how various encryption algorithms are used for ESP. The "Combined Algorithm" document set, shown in the middle, is the set of documents describing how various combined mode algorithms are used to provide both encryption and integrity protection for ESP. The "Integ-Protection Algorithm" document set, shown on the right, is the set of documents describing how various integrity-protection algorithms are used for both ESP and AH. The "IKE" documents, shown at the bottom, are the documents describing the IETF Standards-Track key management schemes.
+--------------+ | Architecture | +--------------+ v v +<-<-<-<-<-<-<-<-+ +->->->->->->->->+ v v +----------+ +----------+ | ESP | | AH | | Protocol | | Protocol | +----------+ +----------+ v v v v v +->->->->->->->->+->->->->->->->->+ v v v v v v v v v v v v v v v +------------+ +-----------+ +----------------+ v v | +------------+ | +------------+ | +----------------+ v v | | Encryption | | | Combined | | |Integ-Protection| v v +-| Algorithm | +-| Algorithm | +-| Algorithm | v v +------------+ +------------+ +----------------+ v v v v v v v v v v v +>->->->-+->->->->->->->->->--<-<-<-<-<-<-<-<-<-+-<-<-<-<-+ ^ ^ +------------+ | IKE | | Protocol | +------------+ Figure 1. IPsec/IKE Document Interrelationships2.2. Versions of IPsec
Two versions of IPsec can currently be found in implementations. The "new" IPsec (referred to as IPsec-v3 in this document; see Section 3.1.1 for the RFC descriptions) obsoleted the "old" IPsec (referred to as IPsec-v2 in this document; see Section 3.1.2 for the RFC descriptions); however, IPsec-v2 is still commonly found in operational use. In this document, when the unqualified term IPsec is used, it pertains to both versions of IPsec. An earlier version of IPsec (defined in RFCs 1825-1829), obsoleted by IPsec-v2, is not covered in this document.2.2.1. Differences between "Old" IPsec (IPsec-v2) and "New" IPsec (IPsec-v3)
IPsec-v3 incorporates "lessons learned" from implementation and operational experience with IPsec-v2 and its predecessor, IPsec-v1.
Knowledge was gained about the barriers to IPsec deployment, the scenarios in which IPsec is most effective, and the requirements that needed to be added to IPsec to facilitate its use with other protocols. In addition, the documentation for IPsec-v3 clarifies and expands details that were underspecified or ambiguous in IPsec-v2. Changes to the architecture document [RFC4301] include: o More detailed descriptions of IPsec processing, both unicast and multicast, and the interactions among the various IPsec databases o In IPsec-v2, an SA (Security Association) is uniquely identified by a combination of the SPI (Security Parameters Index), protocol (ESP or AH) and the destination address. In IPsec-v3, a unicast SA is uniquely identified by the SPI and, optionally, by the protocol; a multicast SA is identified by a combination of the SPI and the destination address and, optionally, the source address. o More flexible SPD (Security Policy Database) selectors, including ranges of values and ICMP message types as selectors o Decorrelated (order-independent) SAD (Security Association Database) replaced the former ordered SAD o Extended sequence numbers (ESNs) were added o Mandatory algorithms defined in standalone document o AH [RFC4302] is mandatory to implement (MUST) in IPsec-v2, optional (MAY) in IPsec-v3 Changes to ESP [RFC4303] include: o Combined mode algorithms were added, necessitating changes to packet format and processing o NULL authentication, mandatory (MUST) in ESP-v2, is optional (MAY) in ESP-v32.3. Versions of IKE
Two versions of IKE can currently be found in implementations. The "new" IKE (generally referred to as IKEv2) obsoleted the "old" IKE (generally referred to as IKEv1); however, IKEv1 is still commonly found in operational use. In this document, when the unqualified term IKE is used, it pertains to both versions of IKE.
2.3.1. Differences between IKEv1 and IKEv2
As with IPsec-v3, IKEv2 incorporates "lessons learned" from implementation and operational experience with IKEv1. Knowledge was gained about the barriers to IKE deployment, the scenarios in which IKE is most effective, and the requirements that needed to be added to IKE to facilitate its use with other protocols as well as in general-purpose use. The documentation for IKEv2 replaces multiple, at times contradictory, documents with a single document; it also clarifies and expands details that were underspecified or ambiguous in IKEv1. Once an IKE negotiation is successfully completed, the peers have established two pairs of one-way (inbound and outbound) SAs. Since IKE always negotiates pairs of SAs, the term "SA" is generally used to refer to a pair of SAs (e.g., an "IKE SA" or an "IPsec SA" is in reality a pair of one-way SAs). The first SA, the IKE SA, is used to protect IKE traffic. The second SA provides IPsec protection to data traffic between the peers and/or other devices for which the peers are authorized to negotiate. It is called the IPsec SA in IKEv1 and, in the IKEv2 RFCs, it is referred to variously as a CHILD_SA, a child SA, and an IPsec SA. This document uses the term "IPsec SA". To further complicate the terminology, since IKEv1 consists of two sequential negotiations, called phases, the IKE SA is also referred to as a Phase 1 SA and the IPsec SA is referred to as a Phase 2 SA. Changes to IKE include: o Replaced multiple alternate exchange types with a single, shorter exchange o Streamlined negotiation format to avoid combinatorial bloat for multiple proposals o Protect responder from committing significant resources to the exchange until the initiator's existence and identity are confirmed o Reliable exchanges: every request expects a response o Protection of IKE messages based on ESP, rather than a method unique to IKE o Add traffic selectors: distinct from peer IDs and more flexible o Support of EAP-based authentication methods and asymmetric authentication (i.e., initiator and responder can use different authentication methods)
2.4. IPsec and IKE IANA Registries
Numerous IANA registries contain values that are used in IPsec, IKE, and related protocols. They include: o IKE Attributes (http://www.iana.org/assignments/ipsec-registry): values used during IKEv1 Phase 1 exchanges, defined in [RFC2409]. o "Magic Numbers" for Internet Security Association and Key Management Protocol (ISAKMP) (http://www.iana.org/assignments/isakmp-registry): values used during IKEv1 Phase 2 exchanges, defined in [RFC2407], [RFC2408], and numerous other cryptographic algorithm RFCs. o IKEv2 Parameters (http://www.iana.org/assignments/ikev2-parameters): values used in IKEv2 exchanges, defined in [RFC5996] and numerous other cryptographic algorithm RFCs. o Cryptographic Suites for IKEv1, IKEv2, and IPsec (http://www.iana.org/assignments/crypto-suites): names of cryptographic suites in [RFC4308] and [RFC4869].3. IPsec Documents
3.1. Base Documents
IPsec protections are provided by two special headers: the Encapsulating Security Payload (ESP) Header and the Authentication Header (AH). In IPv4, these headers take the form of protocol headers; in IPv6, they are classified as extension headers. There are three base IPsec documents: one that describes the IP security architecture, and one for each of the IPsec headers.3.1.1. "Old" IPsec (IPsec-v2)
3.1.1.1. RFC 2401, Security Architecture for the Internet Protocol (S, November 1998)
[RFC2401] specifies the mechanisms, procedures, and components required to provide security services at the IP layer. It also describes their interrelationship and the general processing required to inject IPsec protections into the network architecture.
The components include:
- SA (Security Association): a one-way (inbound or outbound)
agreement between two communicating peers that specifies the
IPsec protections to be provided to their communications. This
includes the specific security protections, cryptographic
algorithms, and secret keys to be applied, as well as the
specific types of traffic to be protected.
- SPI (Security Parameters Index): a value that, together with the
destination address and security protocol (AH or ESP), uniquely
identifies a single SA.
- SAD (Security Association Database): each peer's SA repository.
The RFC describes how this database functions (SA lookup, etc.)
and the types of information it must contain to facilitate SA
processing; it does not dictate the format or layout of the
database. SAs can be established in either transport mode or
tunnel mode (see below).
- SPD (Security Policy Database): an ordered database that
expresses the security protections to be afforded to different
types and classes of traffic. The three general classes of
traffic are traffic to be discarded, traffic that is allowed
without IPsec protection, and traffic that requires IPsec
protection.
RFC 2401 describes general inbound and outbound IPsec processing; it
also includes details on several special cases: packet fragments,
ICMP messages, and multicast traffic.
3.1.1.2. RFC 2402, IP Authentication Header (S, November 1998)
[RFC2402] defines the Authentication Header (AH), which provides
integrity protection; it also provides data-origin authentication,
access control, and, optionally, replay protection. A transport mode
AH SA, used to protect peer-to-peer communications, protects upper-
layer data, as well as those portions of the IP header that do not
vary unpredictably during packet delivery. A tunnel mode AH SA can
be used to protect gateway-to-gateway or host-to-gateway traffic; it
can optionally be used for host-to-host traffic. This class of AH SA
protects the inner (original) header and upper-layer data, as well as
those portions of the outer (tunnel) header that do not vary
unpredictably during packet delivery. Because portions of the IP
header are not included in the AH calculations, AH processing is more
complex than ESP processing. AH also does not work in the presence
of Network Address Translation (NAT). Unlike IPsec-v3, IPsec-v2
classifies AH as mandatory to implement.
3.1.1.3. RFC 2406, IP Encapsulating Security Payload (ESP) (S, November 1998)
[RFC2406] defines the IP Encapsulating Security Payload (ESP), which provides confidentiality (encryption) and/or integrity protection; it also provides data-origin authentication, access control, and, optionally, replay and/or traffic analysis protection. A transport mode ESP SA protects the upper-layer data, but not the IP header. A tunnel mode ESP SA protects the upper-layer data and the inner header, but not the outer header.3.1.2. "New" IPsec (IPsec-v3)
3.1.2.1. RFC 4301, Security Architecture for the Internet Protocol (S, December 2005)
[RFC4301] obsoletes [RFC2401], and it includes a more complete and detailed processing model. The most notable changes are detailed above in Section 2.2.1. IPsec-v3 processing incorporates an additional database: - PAD (Peer Authorization Database): contains information necessary to conduct peer authentication, providing a link between IPsec and the key management protocol (e.g., IKE)3.1.2.2. RFC 4302, IP Authentication Header (S, December 2005)
[RFC4302] obsoletes [RFC2402]. Unlike IPsec-v2, IPsec-v3 classifies AH as optional.3.1.2.3. RFC 4303, IP Encapsulating Security Payload (ESP) (S, December 2005)
[RFC4303] obsoletes [RFC2406]. The most notable changes are detailed above in Section 2.2.1.3.2. Additions to IPsec
Once the IKEv1 and IPsec-v2 RFCs were finalized, several additions were defined in separate documents: negotiation of NAT traversal, extended sequence numbers, UDP encapsulation of ESP packets, opportunistic encryption, and IPsec-related ICMP messages. Additional uses of IPsec transport mode were also described: protection of manually configured IPv6-in-IPv4 tunnels and protection of IP-in-IP tunnels. These documents describe atypical uses of IPsec transport mode, but do not define any new IPsec features.
Once the original IPsec Working Group concluded, additional IPsec- related issues were handled by the IPsecME (IPsec Maintenance and Extensions) Working Group. One such problem is the capability of middleboxes to distinguish unencrypted ESP packets (ESP-NULL) from encrypted ones in a fast and accurate manner. Two solutions are described: a new protocol that requires changes to IKEv2 and IPsec-v3 and a heuristic method that imposes no new requirements. Another issue that was addressed is the problem of using IKE and IPsec in a high-availability environment.3.2.1. RFC 3947, Negotiation of NAT-Traversal in the IKE (S, January 2005)
[RFC3947] defines an optional extension to IKEv1. It enables IKEv1 to detect whether there are any NATs between the negotiating peers and whether both peers support NAT traversal. It also describes how IKEv1 can be used to negotiate the use of UDP encapsulation of ESP packets for the IPsec SA. For IKEv2, this capability is described in [RFC5996].3.2.2. RFC 3948, UDP Encapsulation of IPsec ESP Packets (S, January 2005)
[RFC3948] is an optional extension for IPsec-v2 and IPsec-v3. It defines how to encapsulate ESP packets in UDP packets to enable the traversal of NATs that discard packets with protocols other than UDP or TCP. This makes it possible for ESP packets to pass through the NAT device without requiring any change to the NAT device itself. The use of this solution is negotiated by IKE, as described in [RFC3947] for IKEv1 and [RFC5996] for IKEv2.3.2.3. RFC 4304, Extended Sequence Number (ESN) Addendum to IPsec Domain of Interpretation (DOI) for Internet Security Association and Key Management Protocol (ISAKMP) (S, December 2005)
The use of ESNs allows IPsec to use 64-bit sequence numbers for replay protection, but to send only 32 bits of the sequence number in the packet, enabling shorter packets and avoiding a redesign of the packet format. The larger sequence numbers allow an existing IPsec SA to be used for larger volumes of data. [RFC4304] describes an optional extension to IKEv1 that enables IKEv1 to negotiate the use of ESNs for IPsec SAs. For IKEv2, this capability is described in [RFC5996].
3.2.4. RFC 4322, Opportunistic Encryption using the Internet Key Exchange (IKE) (I, December 2005)
Opportunistic encryption allows a pair of end systems to use encryption without any specific pre-arrangements. [RFC4322] specifies a mechanism that uses DNS to distribute the public keys of each system involved and uses DNS Security (DNSSEC) to secure the mechanism against active attackers. It specifies the changes that are needed in existing IPsec and IKE implementations. The majority of the changes are needed in the IKE implementation and these changes relate to the handling of key acquisition requests, the lookup of public keys and TXT records, and the interactions with firewalls and other security facilities that may be co-resident on the same gateway.3.2.5. RFC 4891, Using IPsec to Secure IPv6-in-IPv4 Tunnels (I, May 2007)
[RFC4891] describes how to use IKE and transport-mode IPsec to provide security protection to manually configured IPv6-in-IPv4 tunnels. This document uses standard IKE and IPsec, without any new extensions. It does not apply to tunnels that are initiated in an automated manner (e.g., 6to4 tunnels [RFC3056]).3.2.6. RFC 3884, Use of IPsec Transport Mode for Dynamic Routing (I, September 2004)
[RFC3884] describes the use of transport-mode IPsec to secure IP-in- IP tunnels, which constitute the links of a multi-hop, distributed virtual network (VN). This allows the traffic to be dynamically routed via the VN's trusted routers, rather than routing all traffic through a statically routed IPsec tunnel. This RFC has not been widely adopted.3.2.7. RFC 5840, Wrapped Encapsulating Security Payload (ESP) for Traffic Visibility (S, April 2010)
ESP, as defined in [RFC4303], does not allow a network device to easily determine whether protected traffic that is passing through the device is encrypted or only integrity protected (referred to as ESP-NULL packets). [RFC5840] extends ESPv3 to provide explicit notification of integrity-protected packets, and extends IKEv2 to negotiate this capability between the IPsec peers.
3.2.8. RFC 5879, Heuristics for Detecting ESP-NULL packets (I, May 2010)
[RFC5879] offers an alternative approach to differentiating between ESP-encrypted and ESP-NULL packets through packet inspection. This method does not require any change to IKE or ESP; it can be used with ESP-v2 or ESP-v3.3.3. General Considerations
3.3.1. RFC 3715, IPsec-Network Address Translation (NAT) Compatibility Requirements (I, March 2004)
[RFC3715] "describes known incompatibilities between NAT and IPsec, and describes the requirements for addressing them". This is a critical issue, since IPsec is frequently used to provide VPN access to the corporate network for telecommuters, and NATs are widely deployed in home gateways, hotels, and other access networks typically used for remote access.3.3.2. RFC 5406, Guidelines for Specifying the Use of IPsec Version 2 (B, February 2009)
[RFC5406] offers guidance to protocol designers on how to ascertain whether IPsec is the appropriate security mechanism to provide an interoperable security solution for the protocol. If this is not the case, it advises against attempting to define a new security protocol; rather, it suggests using another standards-based security protocol. The details in this document apply only to IPsec-v2.3.3.3. RFC 2521, ICMP Security Failures Messages (E, March 1999)
[RFC2521] specifies an ICMP message for indicating failures related to the use of IPsec protocols (AH and ESP). The specified ICMP message defines several codes for handling common failure modes for IPsec. The failures that are signaled by this message include invalid or expired SPIs, failure of authenticity or integrity checks on datagrams, decryption and decompression errors, etc. These messages can be used to trigger automated session-key management or to signal to an operator the need to manually reconfigure the SAs. This RFC has not been widely adopted. Furthermore, [RFC4301] discusses the pros and cons of relying on unprotected ICMP messages.3.3.4. RFC 6027, IPsec Cluster Problem Statement (I, October 2010)
[RFC6027] describes the problems of using IKE and IPsec in a high availability environment, in which one or both of the peers are clusters of gateways. It details the numerous types of stateful
information shared by IKE and IPsec peers that would have to be available to other members of the cluster in order to provide high- availability, load sharing, and/or failover capabilities.
(page 15 continued on part 2)
