idnits 2.17.1 draft-ietf-ipsecme-roadmap-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC2411]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. -- The draft header indicates that this document obsoletes RFC2411, but the abstract doesn't seem to directly say this. It does mention RFC2411 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 2738 has weird spacing: '...ptional optio...' == Line 2742 has weird spacing: '...ptional optio...' == Line 2746 has weird spacing: '...ptional optio...' == Line 2750 has weird spacing: '...ptional undef...' == Line 2758 has weird spacing: '...ptional optio...' == (8 more instances...) -- The document date (August 13, 2010) is 4999 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 2401 (Obsoleted by RFC 4301) -- Obsolete informational reference (is this intentional?): RFC 2402 (Obsoleted by RFC 4302, RFC 4305) -- Obsolete informational reference (is this intentional?): RFC 2406 (Obsoleted by RFC 4303, RFC 4305) -- Obsolete informational reference (is this intentional?): RFC 2407 (Obsoleted by RFC 4306) -- Obsolete informational reference (is this intentional?): RFC 2408 (Obsoleted by RFC 4306) -- Obsolete informational reference (is this intentional?): RFC 2409 (Obsoleted by RFC 4306) -- Obsolete informational reference (is this intentional?): RFC 2411 (Obsoleted by RFC 6071) -- Obsolete informational reference (is this intentional?): RFC 3547 (Obsoleted by RFC 6407) -- Obsolete informational reference (is this intentional?): RFC 4305 (Obsoleted by RFC 4835) -- Obsolete informational reference (is this intentional?): RFC 4306 (Obsoleted by RFC 5996) -- Obsolete informational reference (is this intentional?): RFC 4307 (Obsoleted by RFC 8247) -- Obsolete informational reference (is this intentional?): RFC 4718 (Obsoleted by RFC 5996) -- Obsolete informational reference (is this intentional?): RFC 4753 (Obsoleted by RFC 5903) -- Obsolete informational reference (is this intentional?): RFC 4835 (Obsoleted by RFC 7321) -- Obsolete informational reference (is this intentional?): RFC 4869 (Obsoleted by RFC 6379) -- Obsolete informational reference (is this intentional?): RFC 5201 (Obsoleted by RFC 7401) -- Obsolete informational reference (is this intentional?): RFC 5202 (Obsoleted by RFC 7402) -- Obsolete informational reference (is this intentional?): RFC 5206 (Obsoleted by RFC 8046) -- Obsolete informational reference (is this intentional?): RFC 5268 (Obsoleted by RFC 5568) -- Obsolete informational reference (is this intentional?): RFC 5566 (Obsoleted by RFC 9012) Summary: 1 error (**), 0 flaws (~~), 7 warnings (==), 22 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Frankel 3 Internet Draft NIST 4 Obsoletes: 2411 (if approved) S. Krishnan 5 Intended Status: Informational Ericsson 6 Expires: February 2011 August 13, 2010 8 IP Security (IPsec) and Internet Key Exchange (IKE) Document Roadmap 9 11 Status of this Memo 13 Distribution of this memo is unlimited. 15 This Internet-Draft is submitted to IETF in full conformance with the 16 provisions of BCP 78 and BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as 21 Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/1id-abstracts.html. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on February 13, 2011. 36 Copyright and License Notice 38 Copyright (c) 2010 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Abstract 53 Over the past few years, the number of RFCs that define and use IPsec 54 and IKE has greatly proliferated. This is complicated by the fact 55 that these RFCs originate from numerous IETF working groups: the 56 original IPsec WG, its various spin-offs, and other WGs that use 57 IPsec and/or IKE to protect their protocols' traffic. 59 This document is a snapshot of IPsec- and IKE-related RFCs. It 60 includes a brief description of each RFC, along with background 61 information explaining the motivation and context of IPsec's 62 outgrowths and extensions. It obsoletes the previous IPsec Document 63 Roadmap [RFC2411]. 65 The obsoleted IPsec roadmap [RFC2411] briefly described the 66 interrelationship of the various classes of base IPsec documents. 67 The major focus of [RFC2411] was to specify the recommended contents 68 of documents specifying additional encryption and authentication 69 algorithms. 71 Table of Contents 73 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 4 74 2. IPsec/IKE Background Information . . . . . . . . . . . . . . . . 4 75 2.1. Interrelationship of IPsec/IKE Documents . . . . . . . . . 5 76 2.2. Versions of IPsec . . . . . . . . . . . . . . . . . . . . . 6 77 2.2.1. Differences between "old" IPsec (IPsec-v2) and 78 "new" IPsec (IPsec-v3) . . . . . . . . . . . . . . . . 6 79 2.3. Versions of IKE . . . . . . . . . . . . . . . . . . . . . . 7 80 2.3.1. Differences between IKEv1 and IKEv2 . . . . . . . . . . 8 81 2.4. IPsec and IKE IANA Registries . . . . . . . . . . . . . . . 9 82 3. IPsec Documents . . . . . . . . . . . . . . . . . . . . . . . . 9 83 3.1. Base Documents . . . . . . . . . . . . . . . . . . . . . . 9 84 3.1.1. "Old" IPsec (IPsec-v2) . . . . . . . . . . . . . . . . 9 85 3.1.2. "New" IPsec (IPsec-v3) . . . . . . . . . . . . . . . . 11 86 3.2. Additions to IPsec . . . . . . . . . . . . . . . . . . . . 11 87 3.3. General Considerations . . . . . . . . . . . . . . . . . . 13 88 4. IKE Documents . . . . . . . . . . . . . . . . . . . . . . . . . 14 89 4.1. Base Documents . . . . . . . . . . . . . . . . . . . . . . 14 90 4.1.1. IKEv1 . . . . . . . . . . . . . . . . . . . . . . . . . 14 91 4.1.2. IKEv2 . . . . . . . . . . . . . . . . . . . . . . . . . 16 92 4.2. Additions and Extensions . . . . . . . . . . . . . . . . . 17 93 4.2.1. Peer Authentication Methods . . . . . . . . . . . . . . 17 94 4.2.2. Certificate Contents and Management . . . . . . . . . . 18 95 4.2.3. Dead Peer Detection . . . . . . . . . . . . . . . . . . 19 96 4.2.4. Remote Access . . . . . . . . . . . . . . . . . . . . . 19 97 5. Cryptographic Algorithms and Suites . . . . . . . . . . . . . . 21 98 5.1. Algorithm Requirements . . . . . . . . . . . . . . . . . . 21 99 5.2. Encryption Algorithms . . . . . . . . . . . . . . . . . . . 22 100 5.3. Integrity-Protection (Authentication) Algorithms . . . . . 26 101 5.4. Combined Mode Algorithms . . . . . . . . . . . . . . . . . 29 102 5.5. Pseudo-Random Functions (PRFs) . . . . . . . . . . . . . . 32 103 5.6. Cryptographic Suites . . . . . . . . . . . . . . . . . . . 33 104 5.7. Diffie-Hellman Algorithms . . . . . . . . . . . . . . . . . 34 105 6. IPsec/IKE for Multicast . . . . . . . . . . . . . . . . . . . . 35 106 7. Outgrowths of IPsec/IKE . . . . . . . . . . . . . . . . . . . . 36 107 7.1. IPsec Policy . . . . . . . . . . . . . . . . . . . . . . . 37 108 7.2. IPsec MIBs . . . . . . . . . . . . . . . . . . . . . . . . 37 109 7.3. IPComp (Compression) . . . . . . . . . . . . . . . . . . . 37 110 7.5. Better-than-Nothing Security (BTNS) . . . . . . . . . . . . 38 111 7.6. Kerberized Internet Negotiation of Keys (KINK) . . . . . . 39 112 7.7. IPsec Secure Remote Access (IPSRA) . . . . . . . . . . . . 39 113 7.8. IPsec Keying Information Resource Record (IPSECKEY) . . . . 40 114 8. Other Protocols that use IPsec/IKE . . . . . . . . . . . . . . . 40 115 8.1. Mobile IP (MIPv4 and MIPv6) . . . . . . . . . . . . . . . . 40 116 8.2. Open Shortest Path First (OSPF) . . . . . . . . . . . . . . 43 117 8.3. Host Identity Protocol (HIP) . . . . . . . . . . . . . . . 43 118 8.4. Stream Control Transmission Protocol (SCTP) . . . . . . . . 44 119 8.5. Robust Header Compression (ROHC) . . . . . . . . . . . . . 44 120 8.6. Border Gateway Protocol (BGP) . . . . . . . . . . . . . . . 45 121 8.7. IPsec Benchmarking . . . . . . . . . . . . . . . . . . . . 46 122 8.8. Network Address Translators (NAT) . . . . . . . . . . . . . 46 123 8.9. Session Initiation Protocol (SIP) . . . . . . . . . . . . . 47 124 8.10. Explicit Packet Sensitivity Labels . . . . . . . . . . . . 47 125 9. Other Protocols that adapt IKE for non-IPsec 126 functionality . . . . . . . . . . . . . . . . . . . . . . . . . 47 127 9.1. Extensible Authentication Protocol (EAP) . . . . . . . . . 47 128 9.2. Fibre Channel . . . . . . . . . . . . . . . . . . . . . . . 47 129 9.3. Wireless Security . . . . . . . . . . . . . . . . . . . . . 48 130 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 48 131 11. Security Considerations . . . . . . . . . . . . . . . . . . . . 48 132 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 48 133 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 134 13.1. Normative References . . . . . . . . . . . . . . . . . . . 49 135 13.2. Informative References . . . . . . . . . . . . . . . . . . 49 136 Appendix A. Summary of Algorithm Requirement Levels . . . . . . . . 59 137 1. Introduction 139 IPsec (Internet Protocol Security) is a suite of protocols that 140 provides security to Internet communications at the IP layer. The 141 most common current use of IPsec is to provide a Virtual Private 142 Network (VPN), either between two locations (gateway-to-gateway) or 143 between a remote user and an enterprise network (host-to-gateway); it 144 can also provide end-to-end, or host-to-host, security. IPsec is 145 also used by other Internet protocols (e.g. MIPv6) to protect some or 146 all of their traffic. IKE (Internet Key Exchange) is the key 147 negotiation and management protocol that is most commonly used to 148 provide dynamically negotiated and updated keying material for IPsec. 149 IPsec and IKE can be used in conjunction with both IPv4 and IPv6. 151 In addition to the base documents for IPsec and IKE, there are 152 numerous RFCs that reference, extend, and in some cases alter the 153 core specifications. This document is an attempt to list and briefly 154 describe those RFCs, providing context and rationale where indicated. 155 The title of each RFC is followed by a letter that indicates its 156 category in the RFC series [RFC2026], as follows: 158 o S: Standards Track (Proposed Standard, Draft Standard, or 159 Standard) 161 o E: Experimental 163 o B: Best Current Practice 165 o I: Informational 167 For each RFC, the publication date is also given. 169 This document also categorizes the requirements level of each 170 cryptographic algorithm for use with IKEv1, IKEv2, IPsec-v2 and 171 IPsec-v3. These requirements are summarized in Appendix A. These 172 levels are current as of August 2010; subsequent RFCs may result in 173 altered requirement levels. 175 This document does not define requirement levels; it simply restates 176 those found in the IKE and IPsec RFCs. If there is a conflict 177 between this document and any other RFC, then the other RFC takes 178 precedence. 180 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 181 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 182 document are to be interpreted as described in [RFC2119]. 184 2. IPsec/IKE Background Information 185 2.1. Interrelationship of IPsec/IKE Documents 187 The main documents describing the set of IPsec protocols are divided 188 into seven groups. This is illustrated in Figure 1. There is a main 189 Architecture document which broadly covers the general concepts, 190 security requirements, definitions, and mechanisms defining IPsec 191 technology. 193 There are an ESP Protocol document and an AH Protocol document which 194 cover the packet format and general issues regarding the respective 195 protocols. The "Encryption Algorithm" document set, shown on the 196 left, is the set of documents describing how various encryption 197 algorithms are used for ESP. The "Combined Algorithm" document set, 198 shown in the middle, is the set of documents describing how various 199 combined mode algorithms are used to provide both encryption and 200 integrity-protection for ESP. The "Integ-Protection Algorithm" 201 document set, shown on the right, is the set of documents describing 202 how various integrity-protection algorithms are used for both ESP and 203 AH. 205 The "IKE Documents", shown at the bottom, are the documents 206 describing the IETF standards-track key management schemes. 208 +--------------+ 209 | Architecture | 210 +--------------+ 211 v v 212 +<-<-<-<-<-<-<-<-+ +->->->->->->->->+ 213 v v 214 +----------+ +----------+ 215 | ESP | | AH | 216 | Protocol | | Protocol | 217 +----------+ +----------+ 218 v v v v 219 v +->->->->->->->->+->->->->->->->->+ v v 220 v v v v v v 221 v v v v v v 222 v +------------+ +-----------+ +----------------+ v 223 v | +------------+ | +------------+ | +----------------+ v 224 v | | Encryption | | | Combined | | |Integ-Protection| v 225 v +-| Algorithm | +-| Algorithm | +-| Algorithm | v 226 v +------------+ +------------+ +----------------+ v 227 v v v v v 228 v v v v v 229 +>->->->-+->->->->->->->->->--<-<-<-<-<-<-<-<-<-+-<-<-<-<-+ 230 ^ 231 ^ 232 +------------+ 233 | IKE | 234 | Protocol | 235 +------------+ 237 Figure 1. IPsec/IKE Document Interrelationships 239 2.2. Versions of IPsec 241 Two versions of IPsec can currently be found in implementations. The 242 "new" IPsec (referred to as IPsec-v3 in this document; see Section 243 3.1.1 for the RFC descriptions) obsoleted the "old" IPsec (referred 244 to as IPsec-v2 in this document; see Section 3.1.2 for the RFC 245 descriptions); however, IPsec-v2 is still commonly found in 246 operational use. In this document, when the unqualified term IPsec 247 is used, it pertains to both versions of IPsec. An earlier version 248 of IPsec (defined in RFCs 1825-1829), obsoleted by IPsec-v2, is not 249 covered in this document. 251 2.2.1. Differences between "old" IPsec (IPsec-v2) and "new" IPsec 252 (IPsec-v3) 254 IPsec-v3 incorporates "lessons learned" from implementation and 255 operational experience with IPsec-v2 and its predecessor, IPsec-v1. 257 Knowledge was gained about the barriers to IPsec deployment, the 258 scenarios in which IPsec is most effective, and requirements that 259 needed to be added to IPsec to facilitate its use with other 260 protocols. In addition, the documentation for IPsec-v3 clarifies and 261 expands details that were underspecified or ambiguous in IPsec-v2. 263 Changes to the architecture document [RFC4301] include: 265 o More detailed descriptions of IPsec processing, both unicast and 266 multicast, and the interactions among the various IPsec 267 databases 269 o In IPsec-v2, an SA (Security Association) is uniquely identified 270 by a combination of the SPI (Security Parameters Index), 271 protocol (ESP or AH), and destination address. In IPsec-v3, a 272 unicast SA is uniquely identified by the SPI and, optionally, by 273 the protocol; a multicast SA is identified by a combination of 274 the SPI and the destination address and, optionally, the source 275 address. 277 o More flexible SPD (Security Policy Database) selectors, 278 including ranges of values and ICMP message types as selectors 280 o Decorrelated (order-independent) SAD (Security Association 281 Database) replaced the former ordered SAD 283 o Added extended sequence numbers (ESNs) 285 o Mandatory algorithms defined in standalone document 287 o AH [RFC4302] is mandatory-to-implement (MUST) in IPsec-v2, 288 optional (MAY) in IPsec-v3 290 Changes to ESP [RFC4303] include: 292 o Added combined mode algorithms, necessitating changes to packet 293 format and processing 295 o NULL authentication, mandatory (MUST) in ESP-v2, is optional 296 (MAY) in ESP-v3 298 2.3. Versions of IKE 300 Two versions of IKE can currently be found in implementations. The 301 "new" IKE (generally referred to as IKEv2) obsoleted the "old" IKE 302 (generally referred to as IKEv1); however, IKEv1 is still commonly 303 found in operational use. In this document, when the unqualified 304 term IKE is used, it pertains to both versions of IKE. 306 2.3.1. Differences between IKEv1 and IKEv2 308 As with IPsec-v3, IKEv2 incorporates "lessons learned" from 309 implementation and operational experience with IKEv1. Knowledge was 310 gained about the barriers to IKE deployment, the scenarios in which 311 IKE is most effective, and requirements that needed to be added to 312 IKE to facilitate its use with other protocols as well as in 313 general-purpose use. The documentation for IKEv2 replaces multiple, 314 at times contradictory documents, with a single document; it also 315 clarifies and expands details that were underspecified or ambiguous 316 in IKEv1. 318 Once an IKE negotiation is successfully completed, the peers have 319 established two pairs of one-way (inbound and outbound) SAs. Since 320 IKE always negotiates pairs of SAs, the term "SA" is generally used 321 to refer to a pair of SAs (e.g., an "IKE SA" or an "IPsec SA" is in 322 reality a pair of one-way SAs). The first SA, the IKE SA, is used to 323 protect IKE traffic. The second SA provides IPsec protection to data 324 traffic between the peers and/or other devices for which the peers 325 are authorized to negotiate. It is called the IPsec SA in IKEv1 and, 326 in the IKEv2 RFCs, it is referred to variously as a CHILD_SA, a child 327 SA, and an IPsec SA. This document uses the term "IPsec SA". To 328 further complicate the terminology, since IKEv1 consists of two 329 sequential negotiations, called phases, the IKE SA is also referred 330 to as a phase 1 SA and the IPsec SA is referred to as a phase 2 SA. 332 Changes to IKE include: 334 o Multiple alternate exchange types replaced by a single, shorter 335 exchange 337 o Streamlined negotiation format to avoid combinatorial bloat for 338 multiple proposals 340 o Protects responder from committing significant resources to the 341 exchange until the initiator's existence and identity are 342 confirmed 344 o Reliable exchanges: Every request expects a response 346 o Protection of IKE messages based on ESP, rather than a method 347 unique to IKE 349 o Add traffic selectors: distinct from peer IDs and more flexible 351 o Support of EAP-based authentication methods and asymmetric 352 authentication (i.e., initiator and responder can use different 353 authentication methods) 355 2.4. IPsec and IKE IANA Registries 357 Numerous IANA registries contain values that are used in IPsec, IKE 358 and related protocols. They include: 360 o IKE Attributes 361 (http://www.iana.org/assignments/ipsec-registry): values used 362 during IKEv1 Phase 1 exchanges, defined in [RFC2409] 364 o "Magic Numbers" for ISAKMP Protocol 365 (http://www.iana.org/assignments/isakmp-registry): values used 366 during IKEv1 Phase 2 exchanges, defined in [RFC2407], [RFC2408] 367 and numerous other cryptographic algorithm RFCs 369 o IKEv2 Parameters 370 (http://www.iana.org/assignments/ikev2-parameters): values used 371 in IKEv2 exchanges, defined in [RFC4306] and numerous other 372 cryptographic algorithm RFCs 374 o Cryptographic Suites for IKEv1, IKEv2, and IPsec 375 (http://www.iana.org/assignments/crypto-suites): names of 376 cryptographic suites in [RFC4308] and [RFC4869] 378 3. IPsec Documents 380 3.1. Base Documents 382 IPsec protections are provided by two special headers: the 383 Encapsulating Security Payload (ESP) Header and the Authentication 384 Header (AH). In IPv4, these headers take the form of protocol 385 headers; in IPv6, they are classified as extension headers. There are 386 3 base IPsec documents: one that describes the IP security 387 architecture, and one for each of the IPsec headers. 389 3.1.1. "Old" IPsec 391 3.1.1.1. RFC 2401, Security Architecture for the Internet Protocol (S, 392 Nov. 1998) 394 [RFC2401] specifies the mechanisms, procedures and components 395 required to provide security services at the IP layer. It also 396 describes their interrelationship, and the general processing 397 required to inject IPsec protections into the network architecture. 399 The components include: 401 - SA (Security Association): a one-way (inbound or outbound) 403 agreement between two communicating peers that specifies the IPsec 404 protections to be provided to their communications. This includes 405 the specific security protections, cryptographic algorithms, and 406 secret keys to be applied, as well as the specific types of traffic 407 to be protected. 409 - SPI (Security Parameters Index): a value that, together with 410 the Destination Address and security protocol (AH or ESP), uniquely 411 identifies a single SA 413 - SAD (Security Association Database): each peer's SA 414 repository. The RFC describes how this database functions (SA 415 lookup, etc.) and the types of information it must contain to 416 facilitate SA processing; it does not dictate the format or layout of 417 the database. SAs can be established in either transport mode or 418 tunnel mode (see below). 420 - SPD (Security Policy Database): an ordered database that 421 expresses the security protections to be afforded to different types 422 and classes of traffic. The 3 general classes of traffic are: 423 traffic to be discarded, traffic that is allowed without IPsec 424 protection, and traffic that requires IPsec protection. 426 The RFC describes general inbound and outbound IPsec processing; it 427 also includes details on several special cases: packet fragments, 428 ICMP messages, and multicast traffic. 430 3.1.1.2. RFC 2402, IP Authentication Header (S, Nov. 1998) 432 [RFC2402] defines the Authentication Header (AH), which provides 433 integrity protection; it also provides data origin authentication, 434 access control, and, optionally, replay protection. A transport mode 435 AH SA, used to protect peer-to-peer communications, protects 436 upper-layer data, as well as those portions of the IP header that do 437 not vary unpredictably during packet delivery. A tunnel mode AH SA 438 can be used to protect gateway-to-gateway or host-to-gateway traffic; 439 it can optionally be used for host-to-host traffic. This class of AH 440 SA protects the inner (original) header and upper-layer data, as well 441 as those portions of the outer (tunnel) header that do not vary 442 unpredictably during packet delivery. Because portions of the IP 443 header are not included in the AH calculations, AH processing is more 444 complex than ESP processing. AH also does not work in the presence 445 of Network Address Translation (NAT). Unlike IPsec-v3, IPsec-v2 446 classifies AH as mandatory-to-implement. 448 3.1.1.3. RFC 2406, IP Encapsulating Security Payload (ESP) (S, Nov. 449 1998) 451 [RFC2406] defines the IP Encapsulating Security Payload (ESP), which 452 provides confidentiality (encryption) and/or integrity protection; it 453 also provides data origin authentication, access control, and, 454 optionally, replay and/or traffic analysis protection. A transport 455 mode ESP SA protects the upper-layer data, but not the IP header. A 456 tunnel mode ESP SA protects the upper-layer data and the inner 457 header, but not the outer header. 459 3.1.2. "New" IPsec 461 3.1.2.1. RFC 4301, Security Architecture for the Internet Protocol (S, 462 Dec. 2005) 464 [RFC4301] obsoletes [RFC2401], including a more complete and detailed 465 processing model. The most notable changes are detailed above in 466 Section 2.2.1. IPsec-v3 processing incorporates an additional 467 database: 469 - PAD (Peer Authorization Database): contains information 470 necessary to conduct peer authentication, providing a link between 471 IPsec and the key management procotol (e.g. IKE) 473 3.1.2.2. RFC 4302, IP Authentication Header (S, Dec. 2005) 475 [RFC4302] obsoletes [RFC2402]. Unlike IPsec-v2, IPsec-v3 classifies 476 AH as optional. 478 3.1.2.3. RFC 4303, IP Encapsulating Security Payload (ESP) (S, Dec. 479 2005) 481 [RFC4303] obsoletes [RFC2406]. The most notable changes are detailed 482 above in Section 2.2.1. 484 3.2. Additions to IPsec 486 Once the IKEv1 and IPsec-v2 RFCs were finalized, several additions 487 were defined in separate documents: negotiation of NAT traversal, 488 extended sequence numbers, UDP encapsulation of ESP packets, 489 opportunistic encryption, and IPsec-related ICMP messages. 490 Additional uses of IPsec transport mode were also described: 491 protection of manually-configured IPv6-in-IPv4 tunnels and protection 492 of IP-in-IP tunnels. These documents describe atypical uses of IPsec 493 transport mode, but do not define any new IPsec features. 495 Once the original IPsec working group concluded, additional 496 IPsec-related issues were handled by the IPsecME (IPsec Maintenance 497 and Extensions) working group. One such problem is the capability of 498 middleboxes to distinguish unencrypted ESP packets (ESP-NULL) from 499 encrypted ones in a fast and accurate manner. Two solutions are 500 described: a new protocol that requires changes to IKEv2 and 501 IPsec-v3, and a heuristic method that imposes no new requirements. 502 Another issue that was addressed is the problems of using IKE and 503 IPsec in a high availability environment. 505 3.2.1. RFC 3947, Negotiation of NAT-Traversal in the IKE (S, Jan. 2005) 507 [RFC3947] defines an optional extension to IKEv1. It enables IKEv1 508 to detect whether there are any NATs between the negotiating peers, 509 and whether both peers support NAT traversal. It also describes how 510 IKEv1 can be used to negotiate the use of UDP encapsulation of ESP 511 packets for the IPsec SA. For IKEv2, this capability is described in 512 [RFC4306]. 514 3.2.2. RFC 3948, UDP Encapsulation of IPsec ESP Packets (S, Jan. 2005) 516 [RFC3948] is an optional extension for IPsec-v2 and IPsec-v3. It 517 defines how to encapsulate ESP packets in UDP packets to enable the 518 traversal of NATs that discard packets with protocols other than UDP 519 or TCP. This makes it possible for ESP packets to pass through the 520 NAT device without requiring any change to the NAT device itself. 521 The use of this solution is negotiated by IKE, as described in 522 [RFC3947] for IKEv1 and [RFC4306] for IKEv2. 524 3.2.3. RFC 4304, Extended Sequence Number (ESN) Addendum to IPsec 525 Domain of Interpretation (DOI) for Internet Security Association and 526 Key Management Protocol (ISAKMP) (S, Dec. 2005) 528 The use of ESNs allows IPsec to use 64-bit sequence numbers for 529 replay protection, but to send only 32 bits of the sequence number in 530 the packet, enabling shorter packets and avoiding a re-design of the 531 packet format. The larger sequence numbers allow an existing IPsec 532 SA to be used for larger volumes of data. [RFC4304] describes an 533 optional extension to IKEv1 that enables IKEv1 to negotiate the use 534 of ESNs for IPsec SAs. For IKEv2, this capability is described in 535 [RFC4306]. 537 3.2.4. RFC 4322, Opportunistic Encryption using the Internet Key 538 Exchange (IKE) (I, Dec. 2005) 540 Opportunistic encryption allows a pair of end systems to use 541 encryption without any specific pre-arrangements. [RFC4322] 542 specifies a mechanism that uses DNS to distribute the public keys of 543 each system involved and uses DNSSEC to secure the mechanism against 544 active attackers. It specifies the changes that are needed in 545 existing IPsec and IKE implementations. The majority of the changes 546 are needed in the IKE implementation and these changes relate to 547 handling of key acquisition requests, lookup of public keys and TXT 548 records, and interactions with firewalls and other security 549 facilities that may be co-resident on the same gateway. 551 3.2.5. RFC 4891, Using IPsec to Secure IPv6-in-IPv4 Tunnels (I, May 552 2007) 554 [RFC4891] describes how to use IKE and transport-mode IPsec to 555 provide security protection to manually-configured IPv6-in-IPv4 556 tunnels. This document uses standard IKE and IPsec, without any new 557 extensions. It does not apply to tunnels that are initiated in an 558 automated manner (e.g., 6to4 tunnels [RFC3056]). 560 3.2.6. RFC 3884, Use of IPsec Transport Mode for Dynamic Routing (I, 561 Sep. 2004) 563 [RFC3884] describes the use of transport-mode IPsec to secure 564 IP-in-IP tunnels, which constitute the links of a multi-hop, 565 distributed virtual network (VN). This allows the traffic to be 566 dynamically routed via the VN's trusted routers, rather than routing 567 all traffic through a statically-routed IPsec tunnel. This RFC has 568 not been widely adopted. 570 3.2.7. RFC 5840, Wrapped Encapsulating Security Payload (ESP) for 571 Traffic Visibility (S, Apr. 2010) 573 ESP, as defined in [RFC4303], does not allow a network device to 574 easily determine whether protected traffic that is passing through 575 the device is encrypted, or only integrity-protected (referred to as 576 ESP-NULL packets). [RFC5840] extends ESPv3 to provide explicit 577 notification of integrity-protected packets, and extends IKEv2 to 578 negotiate this capability between the IPsec peers. 580 3.2.8. RFC 5879, Heuristics for Detecting ESP-NULL packets (I, May 581 2010) 583 [RFC5879] offers an alternative approach to differentiating between 584 ESP-encrypted and ESP-NULL packets, through packet inspection. This 585 method does not require any change to IKE or ESP; it can be used with 586 ESP-v2 or ESP-v3. 588 3.3. General Considerations 590 3.3.1. RFC 3715, IPsec-Network Address Translation (NAT) Compatibility 591 Requirements (I, Mar. 2004) 593 [RFC3715] "describes known incompatibilities between NAT and IPsec, 594 and describes the requirements for addressing them." This is a 595 critical issue, since IPsec is frequently used to provide VPN access 596 to the corporate network for telecommuters, and NATs are widely 597 deployed in home gateways, hotels, and other access networks 598 typically used for remote access. 600 3.3.2. RFC 5406, Guidelines for Specifying the Use of IPsec Version 2 601 (B, Feb. 2009) 603 [RFC5406] offers guidance to protocol designers on how to ascertain 604 whether IPsec is the appropriate security mechanism to provide an 605 interoperable security solution for the protocol. If this is not the 606 case, it advises against attempting to define a new security 607 protocol; rather, it suggests using another standards-based security 608 protocol. The details in this document apply only to IPsec-v2. 610 3.3.3. RFC 2521, ICMP Security Failures Messages (E, Mar. 1999) 612 [RFC2521] specifies an ICMP message for indicating failures related 613 to the use of IPsec protocols (AH and ESP). The specified ICMP 614 message defines several codes for handling common failure modes for 615 IPsec. The failures that are signaled by this message include 616 invalid or expired SPIs, failure of authenticity or integrity checks 617 on datagrams, decryption and decompression errors etc. These 618 messages can be used to trigger automated session-key management or 619 to signal to an operator the need to manually reconfigure the SAs. 620 This RFC has not been widely adopted. Furthermore, [RFC4301] 621 discusses the pros and cons of relying on unprotected ICMP messages. 623 3.3.4. draft-ietf-ipsecme-ipsec-ha, IPsec High Availability and Load 624 Sharing Problem Statement (I, Work in progress) 626 [ipsecme-3] describes the problems of using IKE and IPsec in a high 627 availability environment, in which one or both of the peers are 628 clusters of gateways. It details the numerous types of stateful 629 information shared by IKE and IPsec peers that would have to be 630 available to other members of the cluster in order to provide high 631 availablity, load sharing and/or failover capabilities. 633 4. IKE Documents 635 4.1. Base Documents 637 4.1.1. IKEv1 639 IKE is the preferred key management protocol for IPsec. It is used 640 for peer authentication; to negotiate, modify and delete SAs; and to 641 negotiate authenticated keying material for use within those SAs. 642 The standard peer authentication methods used by IKEv1 (pre-shared 643 secret keys and digital certificates) had several shortcomings 644 related to use of IKEv1 to enable remote user authentication to a 645 corporate VPN: it could not leverage the use of legacy authentication 646 systems (e.g. RADIUS databases) to authenticate a remote user to a 647 security gateway; and it could not be used to configure remote users 648 with network addresses or other information needed in order to access 649 the internal network. Automatic key distribution is required for 650 IPsec-v2, but alternatives to IKE may be used to satisfy that 651 requirement. 653 Several Internet Drafts were written to address these problems: two 654 such Internet Drafts include "Extended Authentication within IKE 655 (XAUTH)" (draft-beaulieu-ike-xauth and its predecessor, "Extended 656 Authentication within ISAKMP/Oakley (XAUTH)", 657 draft-ietf-ipsec-isakmp-xauth) and "The ISAKMP Configuration Method" 658 (draft-dukes-ike-mode-cfg and its predecessor 659 draft-ietf-ipsec-isakmp-mode-cfg). These drafts did not progress to 660 RFC status due to security flaws and other problems related to these 661 solutions. However, many current IKEv1 implementations incorporate 662 aspects of these solutions to facilitate remote user access to 663 corporate VPNs. These solutions were not standardized, and different 664 implementations implemented different versions. Thus, there is no 665 assurance that the implementations adhere fully to the suggested 666 solutions, or that one implementation can interoperate with others 667 that claim to incorporate the same features. Furthermore, these 668 solutions have known security issues. All of those problems and 669 security issues have been solved in IKEv2; thus use of these 670 non-standardized IKEv1 solutions is not recommended. 672 4.1.1.1. RFC 2409, The Internet Key Exchange (IKE) (S, Nov. 1998) 674 This document defines a key exchange protocol that can be used to 675 negotiate authenticated keying material for SAs. This document 676 implements a subset of the Oakley protocol in conjunction with ISAKMP 677 to obtain authenticated keying material for use with ISAKMP, and for 678 other security associations such as AH and ESP for the IETF IPsec 679 DOI. While historically IKEv1 was created by combining two security 680 protocols, ISAKMP and Oakley, in practice the combination (along with 681 the IPsec DOI) has commonly been viewed as one protocol, IKEv1. The 682 protocol's origins can be seen in the organization of the documents 683 that define it. 685 4.1.1.2. RFC 2408, Internet Security Association and Key Management 686 Protocol (ISAKMP) (S, Nov. 1998) 688 This document defines procedures and packet formats to establish, 689 negotiate, modify and delete Security Associations (SAs). It is 690 intended to support the negotiation of SAs for security protocols at 691 all layers of the network stack. ISAKMP can work with many different 692 key exchange protocols, each with different security properties. 694 4.1.1.3. RFC 2407, The Internet IP Security Domain of Interpretation 695 for ISAKMP (S, Nov. 1998) 697 Within ISAKMP, a Domain of Interpretation is used to group related 698 protocols using ISAKMP to negotiate security associations. Security 699 protocols sharing a DOI choose security protocol and cryptographic 700 transforms from a common namespace and share key exchange protocol 701 identifiers. This document defines the Internet IP Security DOI 702 (IPSEC DOI), which instantiates ISAKMP for use with IP when IP uses 703 ISAKMP to negotiate security associations. 705 4.1.1.4. RFC 2412, The OAKLEY Key Determination Protocol (I, Nov. 1998) 707 [RFC2412] describes a key establishment protocol which two 708 authenticated parties can use to agree on secure and secret keying 709 material. The Oakley protocol describes a series of key exchanges-- 710 called "modes"-- and details the services provided by each (e.g. 711 perfect forward secrecy for keys, identity protection, and 712 authentication). This document provides additional theory and 713 background to explain some of the design decisions and security 714 features of IKE and ISAKMP; it does not include details necessary for 715 the implementation of IKEv1. 717 4.1.2. IKEv2 719 4.1.2.1. RFC 4306, Internet Key Exchange (IKEv2) Protocol (S, Dec. 720 2005) 722 This document describes version 2 of the Internet Key Exchange (IKE) 723 protocol. It covers what was covered previously by separate 724 documents: ISAKMP, IKE and DOI. It also addresses NAT traversal, 725 legacy authentication and remote address acquisition. IKEv2 is not 726 interoperable with IKEv1. Automatic key distribution is required for 727 IPsec-v3, but alternatives to IKE may be used to satisfy that 728 requirement. 730 4.1.2.2. RFC 4718, IKEv2 Clarifications and Implementation Guidelines 731 (I, Oct. 2006) 733 [RFC4718] clarifies many areas of the IKEv2 specification that may be 734 difficult to understand for developers who are not intimately 735 familiar with the specification and its history. It does not 736 introduce any changes to the protocol, but rather provides 737 descriptions that are less prone to ambiguous interpretations. The 738 goal of this document is to encourage the development of 739 interoperable implementations. 741 4.1.2.3. draft-ietf-ipsecme-ikev2bis, Internet Key Exchange Protocol: 742 IKEv2 (S, Work in progress) 744 [ipsecme-1] combines the original IKEv2 RFC [RFC4306] with the 745 Clarifications RFC [RFC4718], and resolves many implementation issues 746 discovered by the community since the publication of these two 747 documents. This document was developed by the IPsecME (IPsec 748 Maintenance and Extensions) working group, after the conclusion of 749 the original IPsec working group. Automatic key distribution is 750 required for IPsec-v3, but alternatives to IKE may be used to satisfy 751 that requirement. 753 4.2. Additions and Extensions 755 4.2.1. Peer Authentication Methods 757 4.2.1.1. RFC 4478, Repeated Authentication in Internet Key Exchange 758 (IKEv2) Protocol (E, Apr. 2006) 760 [RFC4478] addresses a problem unique to remote access scenarios. How 761 can the gateway (the IKE responder) force the remote user (the IKE 762 initiator) to periodically re-authenticate, limiting the damage in 763 the case where an unauthorized user gains physical access to the 764 remote host? This document defines a new status notification, that a 765 responder can send to an initiator, notifying the initiator that the 766 IPsec SA will be revoked unless the initiator re-authenticates within 767 a specified period of time. This optional extension applies only to 768 IKEv2, not to IKEv1. 770 4.2.1.2. RFC 4739, Multiple Authentication Exchanges in the Internet 771 Key Exchange (IKEv2) Protocol (E, Nov. 2006) 773 IKEv2 supports several mechanisms for authenticating the parties but 774 each endpoint uses only one of these mechanisms to authenticate 775 itself. [RFC4739] specifies an extension to IKEv2 that allows the 776 use of multiple authentication exchanges, using either different 777 mechanisms or the same mechanism. This extension allows, for 778 instance, performing certificate-based authentication of the client 779 host followed by an EAP authentication of the user. This also allows 780 for authentication by multiple administrative domains, if needed. 781 This optional extension applies only to IKEv2, not to IKEv1. 783 4.2.1.3. RFC 4754, IKE and IKEv2 Authentication Using the Elliptic 784 Curve Digital Signature Algorithm (ECDSA) (S, Jan. 2007) 786 [RFC4754] describes how the Elliptic Curve Digital Signature 787 Algorithm (ECDSA) may be used as the authentication method within the 788 IKEv1 and IKEv2 protocols. ECDSA provides many benefits including 789 computational efficiency, small signature sizes, and minimal 790 bandwidth compared to other available digital signature methods like 791 RSA and DSA. This optional extension applies to both IKEv1 and 792 IKEv2. 794 4.2.1.4 draft-ietf-ipsecme-eap-mutual, An Extension for EAP-Only 795 Authentication in IKEv2 (S, Work in progress) 797 IKEv2 allows an initiator to use EAP for peer authentication, but 798 requires the responder to authenticate through the use of a digital 799 signature. [ipsecme-2] extends IKEv2 so that EAP methods that 800 provide mutual authentication and key agreement can also be used to 801 provide peer authentication for the responder. This optional 802 extension applies only to IKEv2, not to IKEv1. 804 4.2.2. Certificate Contents and Management (PKI4IPsec) 806 The format, contents and interpretation of Public Key Certificates 807 proved to be a source of interoperability problems within IKE and 808 IPsec. PKI4IPsec was an attempt to set in place some common 809 procedures and interpretations to mitigate those problems. 811 4.2.2.1. RFC 4809, Requirements for an IPsec Certificate Management 812 Profile (I, Feb. 2007) 814 [RFC4809] enumerates requirements for Public Key Certificate (PKC) 815 lifecycle transactions between different VPN System and PKI System 816 products in order to better enable large scale, PKI-enabled IPsec 817 deployments with a common set of transactions. This document 818 discusses requirements for both the IPsec and the PKI products. 819 These optional requirements apply to both IKEv1 and IKEv2. 821 4.2.2.2. RFC 4945, The Internet IP Security PKI Profile of 822 IKEv1/ISAKMP, IKEv2, and PKIX (S, Aug. 2007) 824 [RFC4945] defines a profile of the IKE and PKIX frameworks in order 825 to provide an agreed-upon standard for using PKI technology in the 826 context of IPsec. It also documents the contents of the relevant IKE 827 payloads and further specifies their semantics. It also summarizes 828 the current state of implementations and deployment and provides 829 advice to avoid common interoperability issues. This optional 830 extension applies to both IKEv1 and IKEv2. 832 4.2.2.3. RFC 4806, Online Certificate Status Protocol (OCSP) Extensions 833 to IKEv2 (S, Feb. 2007) 834 When certificates are used with IKEv2, the communicating peers need a 835 mechanism to determine the revocation status of the peer's 836 certificate. OCSP is one such mechanism. [RFC4806] defines the 837 "OCSP Content" extension to IKEv2. This document is applicable when 838 OCSP is desired and security policy (e.g. firewall policy) prevents 839 one of the IKEv2 peers from accessing the relevant OCSP responder 840 directly. This optional extension applies only to IKEv2, not to 841 IKEv1. 843 4.2.3. Dead Peer Detection 845 4.2.3.1. RFC 3706, A Traffic-Based Method of Detecting Dead Internet 846 Key Exchange (IKE) Peers (I, Feb. 2004) 848 When two peers communicate using IKE and IPsec, it is possible for 849 the connectivity between the two peers to drop unexpectedly. But the 850 SAs can still remain until their lifetimes expire, resulting in the 851 packets getting tunneled into a "black hole". [RFC3706] describes an 852 approach to detect peer liveliness without needing to send messages 853 at regular intervals. This RFC defines an optional extension to 854 IKEv1; dead peer detection (DPD) is an integral part of IKEv2, which 855 refers to this feature as a "liveness check" or "liveness test". 857 4.2.4. Remote Access 859 The IKEv2 Mobility and Multihoming (MOBIKE) protocol enables two 860 additional capabilities for IPsec VPN users: 1) moving from one 861 address to another without re-establishing existing SAs and 2) using 862 multiple interfaces simultaneously. These solutions are limited to 863 IPsec VPNs; they are not intended to provide more general mobility or 864 multi-homing capabilities. 866 The IPsecME working group identified some missing components needed 867 for more extensive IKEv2 and IPsec-v3 support for remote access 868 clients. These include: efficient client resumption of a previously 869 established session with a VPN gateway; efficient client redirection 870 to an alternate VPN gateway; and support for IPv6 client 871 configuration using IPsec configuration payloads. 873 4.2.4.1. RFC 4555, IKEv2 Mobility and Multihoming Protocol (MOBIKE) (S, 874 Jun. 2006) 876 IKEv2 assumes that an IKE SA is created implicitly between the IP 877 address pair that is used during the protocol execution when 878 establishing the IKEv2 SA. IPsec related documents had no provision 879 to change this pair after an IKE SA was created. [RFC4555] defines 880 extensions to IKEv2 that enable an efficient management of IKE and 881 IPsec Security Associations when a host possesses multiple IP 882 addresses and/or where IP addresses of an IPsec host change over 883 time. 885 4.2.4.2. RFC 4621, Design of the IKEv2 Mobility and Multihoming 886 (MOBIKE) Protocol (I, Aug. 2006) 888 [RFC4621] discusses the involved network entities and the 889 relationship between IKEv2 signaling and information provided by 890 other protocols. It also records design decisions for the MOBIKE 891 protocol, background information, and records discussions within the 892 working group. 894 4.2.4.3. RFC 5266, Secure Connectivity and Mobility Using Mobile IPv4 895 and IKEv2 Mobility and Multihoming (MOBIKE) (B, Jun. 2008) 897 [RFC5266] describes a solution using Mobile IPv4 (MIPv4) and mobility 898 extensions to IKEv2 (MOBIKE) to provide secure connectivity and 899 mobility to enterprise users when they roam into untrusted networks. 901 4.2.4.4. RFC 5723, Internet Key Exchange Protocol Version 2 (IKEv2) 902 Session Resumption (S, Jan. 2010) 904 [RFC5723] enables a remote client that has been disconnected from a 905 gateway to re-establish SAs with the gateway in an expedited manner, 906 without repeating the complete IKEv2 negotiation. This capability 907 requires changes to IKEv2. This optional extension applies only to 908 IKEv2, not to IKEv1. 910 4.2.4.5. RFC 5685, Re-direct Mechanism for the Internet Key Exchange 911 Protocol Version 2 (IKEv2) (S, Nov. 2009) 913 [RFC5685] enables a gateway to securely re-direct VPN clients to 914 another VPN gateway, either during or after the IKEv2 negotiation. 915 Possible reasons include, but are not limited to, an overloaded 916 gateway or a gateway that needs to shut down. This requires changes 917 to IKEv2. This optional extension applies only to IKEv2, not to 918 IKEv1. 920 4.2.4.6. RFC 5739, IPv6 Configuration in Internet Key Exchange Protocol 921 Version 2 (IKEv2) (E, Feb. 2010) 923 In IKEv2, a VPN gateway can assign an internal network address to a 924 remote VPN client. This is accomplished through the use of 925 configuration payloads. For an IPv6 client, the assignment of a 926 single address is not sufficient to enable full-fledged IPv6 927 communications. [RFC5739] proposes several solutions that might 928 remove this limitation. This optional extension applies only to 929 IKEv2, not to IKEv1. 931 5. Cryptographic Algorithms and Suites 933 Two basic requirements must be met for an algorithm to be used within 934 IKE and/or IPsec: assignment of one or more IANA values and an RFC 935 that describes how to use the algorithm within the relevant protocol, 936 packet formats, special considerations, etc. For each RFC that 937 describes a cryptographic algorithm, this roadmap will classify its 938 Requirements Level for each protocol, as either MUST, SHOULD or MAY 939 [RFC2119]; SHOULD+, SHOULD- or MUST- [RFC4835]; optional; undefined; 940 or N/A (not applicable). A designation of optional means that the 941 algorithm meets the two basic requirements, but its use is not 942 specifically recommended for that protocol. Undefined means that one 943 of the basic requirements is not met: either there is no relevant 944 IANA number for the algorithm, or there is no RFC specifying how it 945 should be used within that specific protocol. N/A means that use of 946 the algorithm is inappropriate in the context (e.g., NULL encryption 947 for IKE, which always requires encryption; or combined mode 948 algorithms, a new feature in IPsec-v3, for use with IPsec-v2). 950 This document categorizes the requirements level of each algorithm 951 for IKEv1, IKEv2, IPsec-v2 and IPsec-v3. If an algorithm is 952 recommended for use within IKEv1 or IKEv2, it is used either to 953 protect the IKE SA's traffic (encryption and integrity-protection 954 algorithms) or to generate keying material (Diffie-Hellman or DH 955 groups, Pseudo-Random Functions or PRFs). If an algorithm is 956 recommended for use within IPsec, it is used to protect the 957 IPsec/child SA's traffic, and IKE is capable of negotiating its use 958 for that purpose. These requirements are summarized in Table 1 959 (Appendix A). These levels are current as of August 2010; subsequent 960 RFCs may result in altered requirement levels. For algorithms, this 961 could mean the introduction of new algorithms; or upgrading or 962 downgrading the requirement levels of current algorithms. 964 The IANA registries for IKEv1 and IKEv2 include IANA values for 965 various cryptographic algorithms. IKE uses these values to negotiate 966 IPsec SAs that will provide protection using those algorithms. If a 967 specific algorithm lacks a value for IKEv1 and/or IKEv2, that 968 algorithm's use is classified as "undefined (no IANA #) within 969 IPsec-v2 and/or IPsec-v3. 971 5.1. Algorithm Requirements 973 Specifying a core set of mandatory algorithms for each protocol 974 facilitates interoperability. Defining those algorithms in an RFC 975 separate from the base protocol RFC enhances algorithm agility. 976 IPsec-v3 and IKEv2 each have an RFC that specifies their 977 mandatory-to-implement (MUST), recommended (SHOULD), optional (MAY), 978 and deprecated (SHOULD NOT) algorithms. For IPsec-v2, this is 979 included in the base protocol RFC. That was originally the case for 980 IKEv1, but IKEv1's algorithm requirements were updated in [RFC4109]. 982 5.1.1. RFC 4835, Cryptographic Algorithm Implementation Requirements 983 for Encapsulating Security Payload (ESP) and Authentication Header 984 (AH) (S, Apr. 2007) 986 [RFC4835] specifies the encryption and integrity-protection 987 algorithms for IPsec (both versions). Algorithms for IPsec-v2 were 988 originally defined in [RFC2402] and [RFC2406]. [RFC4305] obsoleted 989 those requirements, and was in turn obsoleted by [RFC4835]. 990 Therefore, [RFC4835] applies to IPsec-v2 as well as IPsec-v3. 991 Combined mode algorithms are mentioned, but not assigned a 992 requirement level. 994 5.1.2. RFC 4307, Cryptographic Algorithms for Use in the Internet Key 995 Exchange Version 2 (IKEv2) (S, Dec. 2005) 997 [RFC4307] specifies the encryption and integrity-protection 998 algorithms used by IKEv2 to protect its own traffic; the 999 Diffie-Hellman (DH) groups used within IKEv2; and the pseudo-random 1000 functions used by IKEv2 to generate keys, nonces and other random 1001 values. [RFC4307] contains conflicting requirements for IKEv2 1002 encryption and integrity-protection algorithms. Where there are 1003 contradictory requirements, this document takes its requirement 1004 levels from section 3.1.1 (Encrypted Payload Algorithms), rather than 1005 from section 3.1.3 (IKEv2 Transform Type 1 Algorithms) or section 1006 3.1.4 (IKEv2 Transform Type 2 Algorithms). 1008 5.1.3. RFC 4109, Algorithms for Internet Key Exchange version 1 (IKEv1) 1009 (S, May 2005) 1011 [RFC4109] updates IKEv1's algorithm specifications, which were 1012 originally defined in [RFC2409]. It specifies the encryption and 1013 integrity-protection algorithms used by IKEv1 to protect its own 1014 traffic; the Diffie-Hellman (DH) groups used within IKEv1; the hash 1015 and pseudo-random functions used by IKEv1 to generate keys, nonces 1016 and other random values; and the authentication methods and 1017 algorithms used by IKEv1 for peer authentication. 1019 5.2. Encryption Algorithms 1021 The encryption algorithm RFCs describe how to use these algorithms to 1022 encrypt IKE and/or ESP traffic, providing confidentiality protection 1023 to the traffic. They describe any special constraints, requirements, 1024 or changes to packet format appropriate for the specific algorithm. 1025 In general, they do not describe the detailed algorithmic 1026 computations; the reference section of each RFC includes pointers to 1027 documents that define the inner workings of the algorithm. Some of 1028 the RFCs include sample test data, to enable implementors to compare 1029 their results with standardized output. 1031 When any encryption algorithm is used to provide confidentiality, the 1032 use of integrity-protection is strongly recommended. If the 1033 encryption algorithm is a stream cipher, omitting 1034 integrity-protection seriously compromises the security properties of 1035 the algorithm. 1037 DES, as described in [RFC2405], was originally a required algorithm 1038 for IKEv1 and ESP-v2. Since the use of DES is now deprecated, this 1039 roadmap does not include [RFC2405]. 1041 5.2.1. RFC 2410, The NULL Encryption Algorithm and Its Use With IPsec 1042 (S, Nov. 1998) 1044 [RFC2410] is a tongue-in-cheek description of the no-op encryption 1045 algorithm (i.e. using ESP without encryption). In order for IKE to 1046 negotiate the selection of the NULL encryption algorithm for use in 1047 an ESP SA, an identifying IANA number is needed. This number (the 1048 value 11 for ESP_NULL) is found on the IANA registries for both IKEv1 1049 and IKEv2, but it is not mentioned in [RFC2410]. 1051 Requirements levels for ESP-NULL: 1052 IKEv1 - N/A 1053 IKEv2 - N/A 1054 ESP-v2 - MUST [RFC4835] 1055 ESP-v3 - MUST [RFC4835] 1057 NOTE: RFC 4307 erroneously classifies ESP-NULL as MAY for IKEv2; this 1058 has been corrected in an errata submission for RFC 4307. 1060 5.2.2. RFC 2451, The ESP CBC-Mode Cipher Algorithms (S, Nov. 1998) 1062 [RFC2451] describes how to use encryption algorithms in cipher block 1063 chaining (CBC) mode to encrypt IKE and ESP traffic. It specifically 1064 mentions Blowfish, CAST-128, Triple DES (3DES), IDEA and RC5, but it 1065 is applicable to any block cipher algorithm used in CBC mode. The 1066 algorithms mentioned in the RFC all have a 64-bit blocksize and a 1067 64-bit random IV that is sent in the packet along with the encrypted 1068 data. 1070 Requirements levels for 3DES-CBC: 1071 IKEv1 - MUST [RFC4109] 1072 IKEv2 - MUST- [RFC4307] 1073 ESP-v2 - MUST [RFC4835] 1074 ESP-v3 - MUST- [RFC4835] 1076 Requirements levels for other CBC algorithms (Blowfish, CAST, IDEA, 1077 RC5): 1078 IKEv1 - optional 1079 IKEv2 - optional 1080 ESP-v2 - optional 1081 ESP-v3 - optional 1083 5.2.3. RFC 3602, The AES-CBC Cipher Algorithm and Its Use with IPsec 1084 (S, Sep. 2003) 1086 [RFC3602] describes how to use AES in cipher block chaining (CBC) 1087 mode to encrypt IKE and ESP traffic. AES is the successor to DES. 1088 AES-CBC is a block-mode cipher with a 128-bit blocksize; a random IV 1089 that is sent in the packet along with the encrypted data; and 1090 keysizes of 128, 192 and 256 bits. If AES-CBC is implemented, 1091 128-bit keys are MUST; the other sizes are MAY. [RFC3602] includes 1092 IANA values for use in IKEv1 and ESP-v2. A single IANA value is 1093 defined for AES-CBC, so IKE negotiations need to specify the keysize. 1095 Requirements levels for AES-CBC with 128-bit keys: 1096 IKEv1 - SHOULD [RFC4109] 1097 IKEv2 - SHOULD+ [RFC4307] 1098 ESP-v2 - MUST [RFC4835] 1099 ESP-v3 - MUST [RFC4835] 1101 Requirements levels for AES-CBC with 192- or 256-bit keys: 1102 IKEv1 - optional 1103 IKEv2 - optional 1104 ESP-v2 - optional 1105 ESP-v3 - optional 1107 5.2.4. RFC 3686, Using Advanced Encryption Standard (AES) Counter Mode 1108 With IPsec Encapsulating Security Payload (ESP) (S, Jan. 2004) 1110 [RFC3686] describes how to use AES in counter (CTR) mode to encrypt 1111 ESP traffic. AES-CTR is a stream cipher with a 32-bit random nonce 1112 (1/SA) and a 64-bit IV. If AES-CTR is implemented, 128-bit keys are 1113 MUST; 192- and 256-byte keys are MAY. Reuse of the IV with the same 1114 key and nonce compromises the data's security; thus, AES-CTR should 1115 not be used with manual keying. AES-CTR can be pipelined and 1116 parallelized; it uses only the AES encryption operations for both 1117 encryption and decryption. 1119 Requirements levels for AES-CTR: 1120 IKEv1 - undefined (no IANA #) 1121 IKEv2 - optional [RFC5930] 1122 ESP-v2 - SHOULD [RFC4835] 1123 ESP-v3 - SHOULD [RFC4835] 1125 5.2.5. RFC 5930, Using Advanced Encryption Standard Counter Mode 1126 (AES-CTR) with the Internet Key Exchange version 02 (IKEv2) Protocol 1127 (I, Jul. 210). 1129 [RFC5930] extends [RFC3686] to enable the use of AES-CTR to provide 1130 encryption and integrity-protection for IKEv2 messages. 1132 5.2.6. RFC 4312, The Camellia Cipher Algorithm and Its Use with IPsec 1133 (S, Dec. 2005) 1135 [RFC4312] describes how to use Camellia in cipher block chaining 1136 (CBC) mode to encrypt IKE and ESP traffic. Camellia-CBC is a 1137 block-mode cipher with a 128-bit blocksize; a random IV that is sent 1138 in the packet along with the encrypted data; and keysizes of 128, 192 1139 and 256 bits. If Camellia-CBC is implemented, 128-bit keys are MUST; 1140 the other sizes are MAY. [RFC4312] includes IANA values for use in 1141 IKEv1 and IPsec-v2. A single IANA value is defined for Camellia-CBC, 1142 so IKEv1 negotiations need to specify the keysize. 1144 5.2.7. RFC 5529, Modes of Operation for Camellia for Use with IPsec (S, 1145 Apr. 2009) 1147 [RFC5529] describes the use of the Camellia block cipher algorithm in 1148 conjunction with several different modes of operation. It describes 1149 the use of Camellia in Cipher Block Chaining (CBC) mode and Counter 1150 (CTR) mode as an encryption algorithm within ESP. It also describes 1151 the use of Camellia in Counter with CBC-MAC (CCM) mode as a combined 1152 mode algorithm in ESP. This document defines how to use IKEv2 to 1153 generate keying material for a Camellia ESP SA; it does not define 1154 how to use Camellia within IKEv2 to protect an IKEv2 SA's traffic. 1155 However, this RFC, in conjunction with IKEv2's generalized 1156 description of block mode encryption, provide enough detail to allow 1157 the use of Camellia-CBC algorithms within IKEv2. All three modes can 1158 use keys of length 128-bits, 192-bits or 256-bits. [RFC5529] includes 1159 IANA values for use in IKEv2 and IPsec-v3. A single IANA value is 1160 defined for each Camellia mode, so IKEv2 negotiations need to specify 1161 the keysize. 1163 Requirements levels for Camellia-CBC: 1164 IKEv1 - optional 1165 IKEv2 - optional 1166 ESP-v2 - optional 1167 ESP-v3 - optional 1169 Requirements levels for Camellia-CTR: 1170 IKEv1 - undefined (no IANA #) 1171 IKEv2 - undefined (no RFC) 1172 ESP-v2 - optional (but no IANA #, so cannot be negotiated by IKE) 1173 ESP-v3 - optional 1175 Requirements levels for Camellia-CCM: 1176 IKEv1 - N/A 1177 IKEv2 - undefined (no RFC) 1178 ESP-v2 - N/A 1179 ESP-v3 - optional 1181 5.2.8. RFC 4196, The SEED Cipher Algorithm and Its Use with IPsec (S, 1182 Oct. 2005) 1184 [RFC4196] describes how to use SEED in cipher block chaining (CBC) 1185 mode to encrypt ESP traffic. It describes how to use IKEv1 to 1186 negotiate a SEED ESP SA, but does not define the use of SEED to 1187 protect IKEv1 traffic. SEED-CBC is a block-mode cipher with a 1188 128-bit blocksize; a random IV that is sent in the packet along with 1189 the encrypted data; and a keysizes of 128 bits. [RFC4196] includes 1190 IANA values for use in IKEv1 and IPsec-v2. [RFC4196] includes test 1191 data. 1193 Requirements levels for SEED-CBC: 1194 IKEv1 - undefined (no IANA #) 1195 IKEv2 - undefined (no IANA #) 1196 ESP-v2 - optional 1197 ESP-v3 - optional (but no IANA #, so cannot be negotiated by IKE) 1199 5.3. Integrity-Protection (Authentication) Algorithms 1201 The integrity-protection algorithm RFCs describe how to use these 1202 algorithms to authenticate IKE and/or IPsec traffic, providing 1203 integrity protection to the traffic. This protection is provided by 1204 computing an Integrity Check Value (ICV), which is sent in the 1205 packet. The RFCs describe any special constraints, requirements, or 1206 changes to packet format appropriate for the specific algorithm. In 1207 general, they do not describe the detailed algorithmic computations; 1208 the reference section of each RFC includes pointers to documents that 1209 define the inner workings of the algorithm. Some of the RFCs include 1210 sample test data, to enable implementors to compare their results 1211 with standardized output. 1213 Some of these algorithms generate a fixed-length ICV, which is 1214 truncated when it is included in an IPsec-protected packet. For 1215 example, standard HMAC-SHA-1 generates a 160-bit ICV, which is 1216 truncated to 96 bits when it is used to provide integrity-protection 1217 to an ESP or AH packet. The individual RFC descriptions mention those 1218 algorithms that are truncated. When these algorithms are used to 1219 protect IKEv2 SAs, they are also truncated. For IKEv1, HMAC-SHA-1 and 1220 HMAC-MD5 are negotiated by requesting the hash algorithms SHA-1 and 1221 MD5, respectively; these algorithms are not truncated when used to 1222 protect an IKEv1 SA. For HMAC-SHA-1 and HMAC-MD5, the IKEv2 IANA 1223 registry contains values for both the truncated version and the 1224 standard non-truncated version; thus, IKEv2 has the capability to 1225 negotiate either version of the algorithm. However, only the 1226 truncated version is used for IKEv2 SAs and for IPsec SAs. The 1227 non-truncated version is reserved for use by the Fibre Channel 1228 protocol [RFC4595]. For the other algorithms (AES-XCBC, 1229 HMAC-SHA-256/384/512, AES-CMAC and HMAC-RIPEMD), only the truncated 1230 version can be used for both IKEv2 and IPsec-v3 SAs. 1232 One other algorithm, AES-GMAC [RFC4543], can also provide 1233 integrity-protection. It has two versions: an integrity-protection 1234 algorithm for use within AH-v3, and a combined mode algorithm with 1235 null encryption for use within ESP-v3. [RFC4543] is described in 1236 Section 5.4, Combined Mode Algorithms. 1238 5.3.1. RFC 2404, The Use of HMAC-SHA-1-96 within ESP and AH (S, Nov. 1239 1998) 1241 [RFC2404] describes HMAC-SHA-1, an integrity-protection algorithm 1242 with a 512-bit blocksize, and a 160-bit key and Integrity Check Value 1243 (ICV). For use within IPsec, the ICV is truncated to 96 bits. This 1244 is currently the most commonly-used integrity-protection algorithm. 1246 Requirements levels for HMAC-SHA-1: 1247 IKEv1 - MUST [RFC4109] 1248 IKEv2 - MUST [RFC4307] 1249 IPsec-v2 - MUST [RFC4835] 1250 IPsec-v3 - MUST [RFC4835] 1252 5.3.2. RFC 3566, The AES-XCBC-MAC-96 Algorithm and Its Use With IPsec 1253 (S, Sep. 2003) 1255 [RFC3566] describes AES-XCBC-MAC, a variant of CBC-MAC which is 1256 secure for messages of varying lengths (unlike classic CBC-MAC). It 1257 is an integrity-protection algorithm with a 128-bit blocksize, and a 1258 128-bit key and ICV. For use within IPsec, the ICV is truncated to 1259 96 bits. [RFC3566] includes test data. 1261 Requirements levels for AES-XCBC-MAC: 1263 IKEv1 - undefined (no RFC) 1264 IKEv2 - optional 1265 IPsec-v2 - SHOULD+ [RFC4835] 1266 IPsec-v3 - SHOULD+ [RFC4835] 1268 5.3.3. RFC 4868, Using HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 1269 with IPsec (S, May 2007) 1271 [RFC4868] describes a family of algorithms, successors to HMAC-SHA-1. 1272 HMAC-SHA-256 has a 512-bit blocksize, and a 256-bit key and ICV. 1273 HMAC-SHA-384 has a 1024-bit blocksize, and a 384-bit key and ICV. 1274 HMAC-SHA-512 has a 1024-bit blocksize, and a 512-bit key and ICV. 1275 For use within IKE and IPsec, the ICV is truncated to half its 1276 original size (128 bits, 192 bits, or 256 bits). Each of the three 1277 algorithms has its own IANA value, so IKE does not have to negotiate 1278 the keysize. 1280 Requirements levels for HMAC-SHA-256, HMAC-SHA-384, HMAC-SHA-512: 1281 IKEv1 - optional 1282 IKEv2 - optional 1283 IPsec-v2 - optional 1284 IPsec-v3 - optional 1286 5.3.4. RFC 2403, The Use of HMAC-MD5-96 within ESP and AH (S, Nov. 1287 1998) 1289 [RFC2403] describes HMAC-MD5, an integrity-protection algorithm with 1290 a 512-bit blocksize, and a 128-bit key and Integrity Check Value 1291 (ICV). For use within IPsec, the ICV is truncated to 96 bits. It 1292 was a required algorithm for IKEv1 and IPsec-v2. The use of plain 1293 MD5 is now deprecated, but [RFC4835] states: "Weaknesses have become 1294 apparent in MD5; however, these should not affect the use of MD5 with 1295 HMAC." 1297 Requirements levels for HMAC-MD5: 1298 IKEv1 - MAY [RFC4109] 1299 IKEv2 - optional [RFC4307] 1300 IPsec-v2 - MAY [RFC4835] 1301 IPsec-v3 - MAY [RFC4835] 1303 5.3.5. RFC 4494, The AES-CMAC-96 Algorithm and Its Use with IPsec (S, 1304 Jun. 2006) 1306 [RFC4494] describes AES-CMAC, another variant of CBC-MAC which is 1307 secure for messages of varying lengths. It is an 1308 integrity-protection algorithm with a 128-bit blocksize, and 128-bit 1309 key and ICV. For use within IPsec, the ICV is truncated to 96 bits. 1310 [RFC4494] includes test data. 1312 Requirements levels for AES-CMAC: 1313 IKEv1 - undefined (no IANA #) 1314 IKEv2 - optional 1315 IPsec-v2 - optional (but no IANA #, so cannot be negotiated by IKE) 1316 IPsec-v3 - optional 1318 5.3.6. RFC 2857, The Use of HMAC-RIPEMD-160-96 within ESP and AH (S, 1319 Jun. 2000) 1321 [RFC2857] describes HMAC-RIPEMD, an integrity-protection algorithm 1322 with a 512-bit blocksize, and a 160-bit key and ICV. For use within 1323 IPsec, the ICV is truncated to 96 bits. 1325 Requirements levels for HMAC-RIPEMD: 1326 IKEv1 - undefined (no IANA #) 1327 IKEv2 - undefined (no IANA #) 1328 IPsec-v2 - optional 1329 IPsec-v3 - optional (but no IANA #, so cannot be negotiated by IKE) 1331 5.3.7. RFC 4894, Use of Hash Algorithms in Internet Key Exchange (IKE) 1332 and IPsec (I, May 2007) 1334 In light of recent attacks on MD5 and SHA-1, [RFC4894] examines 1335 whether it is necessary to replace the hash functions currently used 1336 by IKE and IPsec for key generation, integrity-protection, digital 1337 signatures, or PKIX certificates. It concludes that the algorithms 1338 recommended for IKEv2 [RFC4307] and IPsec-v3 [RFC4305] are not 1339 currently susceptible to any known attacks. Nonetheless, it suggests 1340 that implementors add support for AES-XCBC-MAC-96 [RFC3566], 1341 AES-XCBC-PRF-128 [RFC4434] and HMAC-SHA-256, -384, and -512 [RFC4868] 1342 for future use. It also suggests that IKEv2 implementors add support 1343 for PKIX certificates signed with SHA-256, -384, and -512. 1345 5.4. Combined Mode Algorithms 1347 IKEv1 and ESP-v2 use separate algorithms to provide encryption and 1348 integrity-protection, and IKEv1 can negotiate different combinations 1349 of algorithms for different SAs. In ESP-v3, a new class of 1350 algorithms was introduced, in which a single algorithm can provide 1351 both encryption and integrity-protection. [RFC4306] describes how 1352 IKEv2 can negotiate combined mode algorithms to be used in ESP-v3 1353 SAs. [RFC5282] adds that capability to IKEv2, enabling IKEv2 to 1354 negotiate and use combined mode algorithms for its own traffic. When 1355 properly designed, these algorithms can provide increased efficiency 1356 in both implementation and execution. 1358 Although ESP-v2 did not originally include combined mode algorithms, 1359 some IKEv1 implementations have added the capability to negotiate 1360 combined mode algorithms for use in IPsec SAs; these implementations 1361 do not include the capability to use combined mode algorithms to 1362 protect IKE SAs. IANA numbers for combined mode algorithms have been 1363 added to the IKEv1 registry. 1365 5.4.1. RFC 4309, Using Advanced Encryption Standard (AES) CCM Mode with 1366 IPsec Encapsulating Security Payload (ESP) (S, Dec. 2005) 1368 [RFC4309] describes how to use AES in Counter with CBC-MAC (CCM) 1369 mode, a combined alorithm, to encrypt and integrity-protect ESP 1370 traffic. AES-CCM is a block-mode cipher with a 128-bit blocksize; a 1371 random IV that is sent in the packet along with the encrypted data; a 1372 24-bit salt value (1/SA); keysizes of 128, 192 and 256 bits, and ICV 1373 sizes of 64, 96 and 128 bits. If AES-CCM is implemented, 128-bit 1374 keys are MUST; the other sizes are MAY. ICV sizes of 64 and 128 bit 1375 are MUST; 96 bits is MAY. The salt value is generated by IKE during 1376 the key generation process. Reuse of the IV with the same key 1377 compromises the data's security; thus, AES-CCM should not be used 1378 with manual keying. [RFC4309] includes IANA values that IKE can use 1379 to negotiate ESP-v3 SAs. Each of the three ICV lengths has its own 1380 IANA value, but IKE negotiations need to specify the keysize. 1381 [RFC4309] includes test data. [RFC4309] describes how IKE can 1382 negotiate the use of AES-CCM to use in an ESP SA. [RFC5282] extends 1383 this to the use of AES-CCM to protect an IKEv2 SA. 1385 Requirements levels for AES-CCM: 1386 IKEv1 - N/A 1387 IKEv2 - optional 1388 ESP-v2 - N/A 1389 ESP-v3 - optional [RFC4835] 1391 NOTE: The IPsec-v2 IANA registry includes values for AES-CCM, but 1392 combined mode algorithms are not a feature of IPsec-v2. Although 1393 some IKEv1/IPsec-v2 implementations include this capability (see 1394 Section 5.4), it is not part of the protocol. 1396 5.4.2. RFC 4106, The Use of Galois/Counter Mode (GCM) in IPsec 1397 Encapsulating Security Payload (ESP) (S, Jun. 2005) 1399 [RFC4106] describes how to use AES in Galois/Counter (GCM) mode, a 1400 combined alorithm, to encrypt and integrity-protect ESP traffic. 1401 AES-GCM is a block-mode cipher with a 128-bit blocksize; a random IV 1402 that is sent in the packet along with the encrypted data; a 32-bit 1403 salt value (1/SA); keysizes of 128, 192 and 256 bits; and ICV sizes 1404 of 64, 96 and 128 bits. If AES-GCM is implemented, 128-bit keys are 1405 MUST; the other sizes are MAY. An ICV size of 128 bits is a MUST; 64 1406 and 96 bits are MAY. The salt value is generated by IKE during the 1407 key generation process. Reuse of the IV with the same key 1408 compromises the data's security; thus, AES-GCM should not be used 1409 with manual keying. [RFC4106] includes IANA values that IKE can use 1410 to negotiate ESP-v3 SAs. Each of the three ICV lengths has its own 1411 IANA value, but IKE negotiations need to specify the keysize. 1412 [RFC4106] includes test data. [RFC4106] describes how IKE can 1413 negotiate the use of AES-GCM to use in an ESP SA. [RFC5282] extends 1414 this to the use of AES-GCM to protect an IKEv2 SA. 1416 Requirements levels for AES-GCM: 1417 IKEv1 - N/A 1418 IKEv2 - optional 1419 ESP-v2 - N/A 1420 ESP-v3 - optional [RFC4835] 1422 NOTE: The IPsec-v2 IANA registry includes values for AES-GCM, but 1423 combined mode algorithms are not a feature of IPsec-v2. Although 1424 some IKEv1/IPsec-v2 implementations include this capability (see 1425 Section 5.4), it is not part of the protocol. 1427 5.4.3. RFC 4543, The Use of Galois Message Authentication Code (GMAC) 1428 in IPsec ESP and AH (S, May 2006) 1430 [RFC4543] is the variant of AES-GCM [RFC4106] that provides 1431 integrity-protection without encryption. It has two versions: an 1432 integrity-protection algorithm for use within AH, and a combined mode 1433 algorithm with null encryption for use within ESP. It can use a key 1434 of 128-, 192-, or 256-bits; the ICV is always 128 bits, and is not 1435 truncated. AES-GMAC uses a nonce, consisting of a 64-bit IV and a 1436 32-bit salt (1/SA). The salt value is generated by IKE during the 1437 key generation process. Reuse of the salt value with the same key 1438 compromises the data's security; thus, AES-GMAC should not be used 1439 with manual keying. For use within AH, each keysize has its own IANA 1440 value, so IKE does not have to negotiate the keysize. For use within 1441 ESP, there is only one IANA value, so IKE negotiations must specify 1442 the keysize. AES-GMAC cannot be used by IKE to protect its own SAs, 1443 since IKE traffic requires encryption. 1445 Requirements levels for AES-GMAC: 1446 IKEv1 - N/A 1447 IKEv2 - N/A 1448 IPsec-v2 - N/A 1449 IPsec-v3 - optional 1451 NOTE: The IPsec-v2 IANA registry includes values for AES-GMAC, but 1452 combined mode algorithms are not a feature of IPsec-v2. Although 1453 some IKEv1/IPsec-v2 implementations include this capability (see 1454 Section 5.4), it is not part of the protocol. 1456 5.4.4. RFC 5282, Using Authenticated Encryption Algorithms with the 1457 Encrypted Payload of the Internet Key Exchange version 2 (IKEv2) 1458 Protocol (S, Aug. 2008) 1460 [RFC5282] extends [RFC4309] and [RFC4106] to enable the use of 1461 AES-CCM and AES-GCM to provide encryption and integrity-protection 1462 for IKEv2 messages. 1464 5.5. Pseudo-Random Functions (PRFs) 1466 IKE uses pseudo-random functions (PRFs) to generate the secret keys 1467 that are used in IKE SAs and IPsec SAs. These PRFs are generally the 1468 same algorithms used for integrity-protection, but their output is 1469 not truncated, since all of the generated bits are generally needed 1470 for the keys. If the PRF's output is not long enough to supply the 1471 required number of bits of keying material, the PRF is applied 1472 iteratively until the requisite amount of keying material is 1473 generated. 1475 For each IKEv2 SA, the peers negotiate both a PRF algorithm and an 1476 integrity-protection algorithm; the former is used to generate keying 1477 material and other values, and the latter is used to provide 1478 protection to the IKE SA's traffic. 1480 IKEv1's approach is more complicated. IKEv1 [RFC2409] does not 1481 specify any PRF algorithms. For each IKEv1 SA, the peers agree on an 1482 unkeyed hash function (e.g., SHA-1). IKEv1 uses the HMAC version of 1483 this function to generate keying material and to provide integrity 1484 protection for the IKE SA. Therefore PRFs that are not HMACs cannot 1485 currently be used in IKEv1. 1487 Requirements levels for PRF-HMAC-SHA1: 1488 IKEv1 - MUST [RFC4109] 1489 IKEv2 - MUST [RFC4307] 1491 Requirements levels for PRF-HMAC-SHA-256, PRF-HMAC-SHA-384, 1492 PRF-HMAC-SHA-512: 1493 IKEv1 - optional [RFC4868] 1494 IKEv2 - optional [RFC4868] 1496 5.5.1. RFC 4434, The AES-XCBC-PRF-128 Algorithm for the Internet Key 1497 Exchange Protocol (IKE) (S, Feb. 2006) 1499 [RFC3566] defines AES-XCBC-MAC-96, which is used for integrity 1500 protection within IKE and IPsec. [RFC4434] enables the use of 1501 AES-XCBC-MAC as a PRF within IKE. The PRF differs from the 1502 integrity-protection algorithm in two ways: its 128-bit output is not 1503 truncated to 96 bits; and it accepts a variable-length key, which is 1504 modified (lengthened via padding or shortened through application of 1505 AES-XCBC) to a 128-bit key. [RFC4434] includes test data. 1507 Requirements levels for AES-XCBC-PRF: 1508 IKEv1 - undefined (no RFC) 1509 IKEv2 - SHOULD+ [RFC4307] 1511 NOTE: RFC 4109 erroneously classifies AES-XCBC-PRF as SHOULD for 1512 IKEv1; this has been corrected in an errata submission for RFC 4109. 1514 5.5.2. RFC 4615, The Advanced Encryption Standard-Cipher-based Message 1515 Authentication Code-Pseudo-Random Function-128 (AES-CMAC-PRF-128) 1516 Algorithm for the Internet Key Exchange Protocol (IKE) (S, Aug. 2006) 1518 [RFC4615] extends [RFC4494] to enable the use of AES-CMAC as a PRF 1519 within IKEv2, in a manner analogous to that used by [RFC4434] for 1520 AES-XCBC. 1522 Requirements levels for AES-CMAC-PRF: 1523 IKEv1 - undefined (no IANA #) 1524 IKEv2 - optional 1526 5.6. Cryptographic Suites 1528 5.6.1. RFC 4308, Cryptographic Suites for IPsec (S, Dec. 2005) 1530 An IKE negotiation consists of multiple cryptographic attributes, 1531 both for the IKE SA and for the IPsec SA. The number of possible 1532 combinations can pose a challenge to peers trying to find a common 1533 policy. To enhance interoperability, [RFC4308] defines two 1534 pre-defined suites, consisting of combinations of algorithms that 1535 comprise typical security policies. IKE/ESP suite "VPN-A" includes 1536 use of 3DES, HMAC-SHA-1, and 1024-bit MODP Diffie-Hellman (DH); 1537 IKE/ESP suite "VPN-B" includes AES-CBC, AES-XCBC-MAC, and 2048-bit 1538 MODP DH. These suites are intended to be named "single-button" 1539 choices in the administrative interface, but do not prevent the use 1540 of alternative combinations. 1542 5.6.2. RFC 4869, Suite B Cryptographic Suites for IPsec (I, May 2007) 1544 [RFC4869] adds 4 pre-defined suites, based upon the United States 1545 National Security Agency's "Suite B" specifications, to those 1546 specified in [RFC4308]. IKE/ESP suites "Suite-B-GCM-128" and 1547 "Suite-B-GCM-256" include use of AES-CBC, AES-GCM, HMAC-SHA-256 or 1548 HMAC-SHA-384, and 256-bit or 384-bit elliptic curve (EC) DH groups. 1549 IKE/AH suites "Suite-B-GMAC-128" and "Suite-B-GMAC-256" include use 1550 of AES-CBC, AES-GMAC, HMAC-SHA-256 or HMAC-SHA-384, and 256-bit or 1551 384-bit EC DH groups. While [RFC4308] does not specify a peer 1552 authentication method, [RFC4869] mandates pre-shared key 1553 authentication for IKEv1; public key authentication using ECDSA is 1554 recommended for IKEv1 and required for IKEv2. 1556 5.7. Diffie-Hellman Algorithms 1558 IKE negotiations include a Diffie-Hellman exchange, which establishes 1559 a shared secret, to which both parties contributed. This value is 1560 used to generate keying material to protect both the IKE SA and the 1561 IPsec SA. 1563 IKEv1 [RFC2409] contains definitions of 2 DH MODP groups and 2 1564 elliptic curve (EC) groups; IKEv2 [RFC4306] only references the MODP 1565 groups. The requirements levels of these groups are: 1567 Requirements levels for DH MODP group 1: 1568 IKEv1 - MAY [RFC4109] 1569 IKEv2 - optional 1571 Requirements levels for DH MODP group 2: 1572 IKEv1 - MUST [RFC4109] 1573 IKEv2 - MUST- [RFC4307] 1575 Requirements levels for EC groups 3-4: 1576 IKEv1 - MAY [RFC4109] 1577 IKEv2 - undefined (no IANA #) 1579 5.7.1. RFC 3526, More Modular Exponential (MODP) Diffie-Hellman groups 1580 for Internet Key Exchange (IKE) (S, May 2003) 1582 [RFC2409] and [RFC4306] define 2 MODP DH groups (groups 1 and 2) for 1583 use within IKE. [RFC3526] adds six more groups (groups 5 and 14-18). 1584 Group 14 is a 2048-bit group that is strongly recommended for use in 1585 IKE. 1587 Requirements levels for DH MODP group 14: 1588 IKEv1 - SHOULD [RFC4109] 1589 IKEv2 - SHOULD+ [RFC4307] 1591 Requirements levels for DH MODP groups 5, 15-18: 1592 IKEv1 - optional [RFC4109] 1593 IKEv2 - optional 1595 5.7.2. RFC 4753, ECP Groups For IKE and IKEv2 (I, Jan. 2007) 1597 [RFC4753] defines 3 EC DH groups (groups 19-21) for use within IKE. 1599 The document includes test data. 1601 Requirements levels for DH EC groups 19-21: 1602 IKEv1 - optional [RFC4109] 1603 IKEv2 - optional 1605 5.7.3. RFC 5903, Elliptic Curve Groups modulo a Prime (ECP Groups) for 1606 IKE and IKEv2 (I, Jun. 2010) 1608 [RFC5903] obsoletes RFC4753, fixing an inconsistency in the DH shared 1609 secret value. 1611 5.7.4. RFC 5114, Additional Diffie-Hellman Groups for Use with IETF 1612 Standards (I, Jan. 2008) 1614 [RFC5114] defines 5 additional DH groups (MODP groups 22-24 and EC 1615 groups 25-26) for use in IKE. It also includes 3 EC DH groups 1616 (groups 19-21) that were originally defined in [RFC4753]; however, 1617 the current specification for these groups is [RFC5903]. The IANA 1618 group numbers are specific to IKE, but the DH groups are intended for 1619 use in multiple IETF protocols, including TLS/SSL, S/MIME, and X.509 1620 Certificates. 1622 Requirements levels for DH MODP groups 22-24, EC groups 25-26: 1623 IKEv1 - optional 1624 IKEv2 - optional 1626 6. IPsec/IKE for Multicast 1628 [RFC4301] describes IPsec processing for unicast and multicast 1629 traffic. However, classical IPsec SAs provide point-to-point 1630 protection; the security afforded by IPsec's cryptographic algorithms 1631 is not applicable when the SA is one-to-many or many-to-many, the 1632 case for multicast. The Multicast Security (msec) Working Group has 1633 defined alternatives to IKE and extensions to IPsec for use with 1634 multicast traffic. Different multicast groups have differing 1635 characteristics and requirements: number of senders (one-to-many or 1636 many-to-many), number of members (few, moderate, very large), 1637 volatility of membership, real-time delivery, etc. Their security 1638 requirements vary as well. Each solution defined by msec applies to 1639 a subset of the large variety of possible multicast groups. 1641 6.1. RFC 3740, The Multicast Group Security Architecture (I, Mar. 2004) 1643 [RFC3740] defines the multicast security architecture, which is used 1644 to provide security for packets exchanged by large multicast groups. 1645 It defines the components of the architectural framework; discusses 1646 Group Security Associations (GSAs), key management, data handling and 1647 security policies. Several existing protocols, including GDOI 1648 [RFC3547], GSAKMP [RFC4535] and MIKEY [RFC3830], satisfy the group 1649 key management requirements defined in this document. Both the 1650 architecture and the components for Multicast Group Security differ 1651 from IPsec. 1653 6.2. RFC 5374, Multicast Extensions to the Security Architecture for 1654 the Internet Protocol (S, Nov. 2008) 1656 [RFC5374] extends the security architecture defined in [RFC4301] to 1657 apply to multicast traffic. It defines a new class of SAs (GSAs - 1658 Group Security Associations) and additional databases used to apply 1659 IPsec protection to multicast traffic. It also describes revisions 1660 and additions to the processing algorithms in [RFC4301]. 1662 6.3. RFC 3547, The Group Domain of Interpretation (S, Jul. 2003) 1664 GDOI [RFC3547] extends IKEv1 so that it can be used to establish SAs 1665 to protect multicast traffic. This document defines additional 1666 exchanges and payloads to be used for that purpose. 1668 6.4. RFC 4046, Multicast Security (MSEC) Group Key Management 1669 Architecture (I, Apr. 2005) 1671 [RFC4046] sets out the general requirements and design principles for 1672 protocols that are used for multicast key management. It does not go 1673 into the specifics of an individual protocol that can be used for 1674 that purpose. 1676 6.5. RFC 4359, The Use of RSA/SHA-1 Signatures within Encapsulating 1677 Security Payload (ESP) and Authentication Header (AH) (S, Jan. 2006) 1679 [RFC4359] describes the use of the RSA digital signature algorithm to 1680 provide integrity-protection for multicast traffic within ESP and AH. 1681 The algorithms used for integrity-protection for unicast traffic 1682 (e.g., HMAC) are not suitable for this purpose when used with 1683 multicast traffic. 1685 7. Outgrowths of IPsec/IKE 1687 Operational experience with IPsec revealed additional capabilities 1688 that could make IPsec more useful in real-world scenarios. These 1689 include support for IPsec policy mechanisms, IPsec MIBs, payload 1690 compression (IPComp), extensions to facilitate additional peer 1691 authentication methods (BTNS, KINK and IPSECKEY), and additional 1692 capabilities for VPN clients (IPSRA). 1694 7.1. IPsec Policy 1696 The IPsec Policy Working Group (ipsp) originally planned an RFC that 1697 would allow entities with no common Trust Anchor and no prior 1698 knowledge of each others' security policies to establish an 1699 IPsec-protected connection. The solutions that were proposed for 1700 gateway discovery and security policy negotiation proved to be overly 1701 complex and fragile, in the absence of prior knowledge or compatible 1702 configuration policies. 1704 7.1.1. RFC 3586, IP Security Policy (IPSP) Requirements (S, Aug. 2003) 1706 [RFC3586] describes the functional requirements of a generalized 1707 IPsec policy framework, that could be used to discover, negotiate and 1708 manage IPsec policies. 1710 7.1.2. RFC 3585, IPsec Configuration Policy Information Model (S, Aug. 1711 2003) 1713 As stated in [RFC3585], "This document presents an object-oriented 1714 information model of IP Security (IPsec) policy designed to 1715 facilitate agreement about the content and semantics of IPsec policy, 1716 and enable derivations of task-specific representations of IPsec 1717 policy such as storage schema, distribution representations, and 1718 policy specification languages used to configure IPsec-enabled 1719 endpoints." This RFC has not been widely adopted. 1721 7.2. IPsec MIBs 1723 Over the years, several MIB-related Internet Drafts were proposed for 1724 IPsec and IKE, but only one progressed to RFC status. 1726 7.2.1. RFC 4807, IPsec Security Policy Database Configuration MIB (S, 1727 Mar. 2007) 1729 [RFC4807] defines a MIB module that can be used to configure the SPD 1730 of an IPsec device. This RFC has not been widely adopted. 1732 7.3. IPComp (Compression) 1734 The IP Payload Compression Protocol (IPComp) is a protocol that 1735 provides lossless compression for IP datagrams. Although IKE can be 1736 used to negotiate the use of IPComp in conjunction with IPsec, IPComp 1737 can also be used when IPsec is not applied. 1739 The IPComp protocol allows the compression of IP datagrams by 1740 supporting different compression algorithms. Three of these 1741 algorithms are: DEFLATE [RFC2394], LZS [RFC2395], and the ITU-T V.44 1742 Packet Method [RFC3051], which is based on the LZJH algorithm. 1744 7.3.1. RFC 3173, IP Payload Compression Protocol (IPComp) (S, Sep. 1745 2001) 1747 IP payload compression is especially useful when IPsec based 1748 encryption is applied to IP datagrams. Encrypting the IP datagram 1749 causes the data to be random in nature, rendering compression at 1750 lower protocol layers ineffective. If IKE is used to negotiate 1751 compression in conjunction with IPsec, compression can be performed 1752 prior to encryption. [RFC3173] defines the payload compression 1753 protocol, the IPComp packet structure, the IPComp Association (IPCA), 1754 and several methods to negotiate the IPCA. 1756 7.5. Better-than-Nothing Security (BTNS) 1758 One of the major obstacles to widespread implementation of IPsec is 1759 the lack of pre-existing credentials that can be used for peer 1760 authentication. Better-than-Nothing Security (BTNS) is an attempt to 1761 sidestep this problem by allowing IKE to negotiate unauthenticated 1762 (anonymous) IPsec SAs, using credentials such as self-signed 1763 certificates or "bare" public keys (public keys that are not 1764 connected to a Public Key Certificate) for peer authentication. This 1765 ensures that subsequent traffic protected by the SA is conducted with 1766 the same peer, and protects the communications from passive attack. 1767 These SAs can then be cryptographically bound to a higher-level 1768 application protocol, which performs its own peer authentication. 1770 7.5.1. RFC 5660, IPsec Channels: Connection Latching (S, Oct. 2009) 1772 [RFC5660] specifies, abstractly, how to interface applications and 1773 transport protocols with IPsec so as to create channels by latching 1774 connections (packet flows) to certain IPsec Security Association (SA) 1775 parameters for the lifetime of the connections. Connection latching 1776 is layered on top of IPsec and does not modify the underlying IPsec 1777 architecture. 1779 7.5.2. RFC 5386, Better-Than-Nothing-Security: An Unauthenticated Mode 1780 of IPsec (S, Nov. 2008) 1782 [RFC5386] specifies how to use IKEv2 to setup unauthenticated 1783 security associations (SAs) for use with the IPsec Encapsulating 1784 Security Payload (ESP) and the IPsec Authentication Header (AH). 1785 This document does not require any changes to the bits on the wire, 1786 but specifies extensions to the Peer Authorization Database (PAD) and 1787 Security Policy Database (SPD). 1789 7.5.3. RFC 5387, Problem and Applicability Statement for 1790 Better-Than-Nothing Security (BTNS) (I, Nov. 2008) 1792 [RFC5387] considers that the need to deploy authentication 1793 information and its associated identities is a significant obstacle 1794 to the use of IPsec. This document explains the rationale for 1795 extending the Internet network security protocol suite to enable use 1796 of IPsec security services without authentication. 1798 7.6. Kerberized Internet Negotiation of Keys (KINK) 1800 Kerberized Internet Negotiation of Keys (KINK) is an attempt to 1801 provide an alternative to IKE for IPsec peer authentication. It uses 1802 Kerberos, instead of IKE, to establish IPsec SAs. For enterprises 1803 that already deploy the Kerberos centralized key management system, 1804 IPsec can then be implemented without the need for additional peer 1805 credentials. Some vendors have implemented proprietary extensions 1806 for using Kerberos in IKEv1, as an alternative to the use of KINK. 1807 These extensions, as well as the KINK protocol, apply only to IKEv1, 1808 and not to IKEv2. 1810 7.6.1. RFC 3129, Requirements for Kerberized Internet Negotiation of 1811 Keys (I, Jun. 2001) 1813 [RFC3129] considers that peer to peer authentication and keying 1814 mechanisms have inherent drawbacks such as computational complexity 1815 and difficulty in enforcing security policies. This document 1816 specifies the requirements for using basic features of Kerberos and 1817 uses them to its advantage to create a protocol which can establish 1818 and maintain IPsec security associations ([RFC2401]). 1820 7.6.2. RFC 4430, Kerberized Internet Negotiation of Keys (KINK) (S, 1821 Mar. 2006) 1823 [RFC4430] defines a low-latency, computationally inexpensive, easily 1824 managed, and cryptographically sound protocol to establish and 1825 maintain security associations using the Kerberos authentication 1826 system. This document reuses the Quick Mode payloads of IKEv1 in 1827 order to foster substantial reuse of IKEv1 implementations. This RFC 1828 has not been widely adopted. 1830 7.7. IPsec Secure Remote Access (IPSRA) 1832 IPsec Secure Remote Access (IPSRA) was an attempt to extend IPsec 1833 protection to "road warriors," allowing IKE to authenticate not only 1834 the user's device but also the user, without changing IKEv1. The 1835 working group defined generic requirements of different IPsec remote 1836 access scenarios. An attempt was made to define an IKE-like protocol 1837 that would use legacy authentication mechanisms to create a temporary 1838 or short-lived user credential that could be used for peer 1839 authentication within IKE. This protocol proved to be more 1840 cumbersome than standard Public Key protocols, and was abandoned. 1841 This led to the development of IKEv2, which incorporates the use of 1842 EAP for user authentication. 1844 7.7.1. RFC 3457, Requirements for IPsec Remote Access Scenarios (I, 1845 Jan. 2003) 1847 [RFC3457] explores and enumerates the requirements of various IPsec 1848 remote access scenarios, without suggesting particular solutions for 1849 them. 1851 7.7.2. RFC 3456, Dynamic Host Configuration Protocol (DHCPv4) 1852 Configuration of IPsec Tunnel Mode (S, Jan. 2003) 1854 [RFC3456] explores the requirements for host configuration in IPsec 1855 tunnel mode, and describes how the Dynamic Host Configuration 1856 Protocol (DHCPv4) may be used for providing such configuration 1857 information. This RFC has not been widely adopted. 1859 7.8. IPsec Keying Information Resource Record (IPSECKEY) 1861 The IPsec Keying Information Resource Record (IPSECKEY) enables the 1862 storage of public keys and other information that can be used to 1863 facilitate opportunistic IPsec in a new type of DNS resource record. 1865 7.8.1. RFC 4025, A method for storing IPsec keying material in DNS (S, 1866 Feb. 2005) 1868 [RFC4025] describes a method of storing IPsec keying material in the 1869 DNS using a new type of resource record. This document describes how 1870 to store the public key of the target node in this resource record. 1871 This RFC has not been widely adopted. 1873 8. Other Protocols that use IPsec/IKE 1875 IPsec and IKE were designed to provide IP-layer security protection 1876 to other Internet protocols' traffic as well as generic 1877 communications. Since IPsec is a general-purpose protocol, in some 1878 cases its features do not provide the granularity or distinctive 1879 features required by another protocol; in some cases, its overhead or 1880 pre-requisites do not match another protocol's requirements. 1881 However, a number of other protocols do use IKE and/or IPsec to 1882 protect some or all of their communications. 1884 8.1. Mobile IP (MIPv4 and MIPv6) 1885 8.1.1. RFC 4093, Problem Statement: Mobile IPv4 Traversal of Virtual 1886 Private Network (VPN) Gateways (I, Aug. 2005) 1888 [RFC4093] describes the issues with deploying Mobile IPv4 across 1889 virtual private networks (VPNs). IPsec is one of the VPN 1890 technologies covered by this document. It identifes and describes 1891 practical deployment scenarios for Mobile IPv4 running alongside 1892 IPsec in enterprise and operator environments. It also specifies a 1893 set of framework guidelines to evaluate proposed solutions for 1894 supporting multi-vendor seamless IPv4 mobility across IPsec-based VPN 1895 gateways. 1897 8.1.2. RFC 5265, Mobile IPv4 Traversal across IPsec-Based VPN Gateways 1898 (S, Jun. 2008) 1900 [RFC5265] describes a basic solution that uses Mobile IPv4 and IPsec 1901 to provide session mobility between enterprise intranets and external 1902 networks. The proposed solution minimizes changes to existing 1903 firewall/VPN/DMZ deployments and does not require any changes to 1904 IPsec or key exchange protocols. It also proposes a mechanism to 1905 minimize IPsec renegotiation when the mobile node moves. 1907 8.1.3. RFC 3776, Using IPsec to Protect Mobile IPv6 Signaling Between 1908 Mobile Nodes and Home Agents (S, Jun. 2004) 1910 This document specifies the use of IPsec in securing Mobile IPv6 1911 traffic between mobile nodes and home agents. It specifies the 1912 required wire formats for the protected packets and illustrates 1913 examples of Security Policy Database and Security Association 1914 Database entries that can be used to protect Mobile IPv6 signaling 1915 messages. It also describes how to configure either manually keyed 1916 IPsec security associations or how to configure IKEv1 to establish 1917 the SAs automatically. Mobile IPv6 requires considering the Home 1918 Address destination option and Routing Header in IPsec processing. 1919 Also, IPsec and IKE security association addresses can be updated by 1920 Mobile IPv6 signaling messages. 1922 8.1.4. RFC 4877, Mobile IPv6 Operation with IKEv2 and the Revised IPsec 1923 Architecture (S, Apr. 2007) 1925 This document updates [RFC3776] in order to work with the revised 1926 IPsec architecture [RFC4301]. Since the revised IPsec architecture 1927 expands the list of selectors to include the Mobility Header message 1928 type, it becomes much easier to differentiate between different 1929 mobility header messages. Since the ICMP message type and code are 1930 also newly added as selectors, this document uses them to protect 1931 Mobile Prefix Discovery messages. This document also specifies the 1932 use of IKEv2 configuration payloads for dynamic home address 1933 configuration. Finally, this document describes the use of IKEv2 in 1934 order to set up the SAs for Mobile IPv6. 1936 8.1.5. RFC 5026, Mobile IPv6 Bootstrapping in Split Scenario (S, Oct. 1937 2007) 1939 [RFC5026] extends [RFC4877] to support dynamic discovery of home 1940 agents and the home network prefix; for the latter purpose, it 1941 specifies a new IKEv2 configuration attribute and notification. It 1942 describes how a Mobile IPv6 node can obtain the address of its Home 1943 Agent, its Home address, and create IPsec security associations with 1944 its Home Agent using DNS lookups and security credentials 1945 pre-configured on the Mobile Node. It defines how a MN can request 1946 its home address and home prefixes through the Configuration Payload 1947 in the IKE_AUTH exchange and what attributes need to be present in 1948 the CFG_REQUEST messages in order for doing so. It also specifies 1949 how the home agent can authorize the credentials used for IKEv2 1950 exchange. 1952 8.1.6. RFC 5213, Proxy Mobile IPv6 (S, Aug. 2008) 1954 [RFC5213] describes a network-based mobility management protocol that 1955 is used to provide mobility services hosts without requiring their 1956 participation in any mobility-related signaling. It uses IPsec to 1957 protect the mobility signaling messages between the two network 1958 entities called the mobile access gateway (MAG) and the local 1959 mobility anchor (LMA). It also uses IKEv2 in order to set up the 1960 security associations between the MAG and the LMA. 1962 8.1.7. RFC 5268, Mobile IPv6 Fast Handovers (S, Jun. 2008) 1964 When Mobile IPv6 is used for a handover, there is a period during 1965 which the Mobile Node is unable to send or receive packets because of 1966 link switching delay and IP protocol operations. [RFC5268] specifies 1967 a protocol between the Previous Access Router (PAR) and the New 1968 Access Router (NAR) to improve handover latency due to Mobile IPv6 1969 procedures. It uses IPsec ESP in transport mode with integrity 1970 protection for protecting the signaling messages between the PAR and 1971 the NAR. It also describes the SPD entries and the PAD entries when 1972 IKEv2 is used for setting up the required SAs. 1974 8.1.8. RFC 5380, Hierarchical Mobile IPv6 (HMIPv6) Mobility Management 1975 (S, Oct. 2008) 1977 [RFC5380] describes extensions to Mobile IPv6 and IPv6 Neighbour 1978 Discovery to allow for local mobility handling in order to reduce the 1979 amount of signalling between the mobile node, its correspondent 1980 nodes, and its home agent. It also improves handover speed of Mobile 1981 IPv6. It uses IPsec for protecting the signaling between the mobile 1982 node and a local mobility management entity called the Mobility 1983 Anchor Point (MAP). The MAP also uses IPsec Peer Authorization 1984 Database (PAD) entries and configuration payloads described in 1985 [RFC4877] in order to allocate a Regional Care-of Address (RCoA) for 1986 mobile nodes. 1988 8.2. Open Shortest Path First (OSPF) 1990 8.2.1. RFC 4552, Authentication/Confidentiality for OSPFv3 (S, Jun. 1991 2006) 1993 OSPF is a link-state routing protocol that is designed to be run 1994 inside a single Autonomous System. OSPFv2 provided its own 1995 authentication mechanisms using the AuType and Authentication 1996 protocol header fields but OSPFv3 removed these fields and uses IPsec 1997 instead. [RFC4552] describes how to use IPsec ESP and AH in order to 1998 protect OSPFv3 signaling between two routers. It also enumerates the 1999 IPsec capabilities the routers require in order to support this 2000 specification. Finally, it also describes the operation of OSPFv3 2001 with IPsec over virtual links where the other endpoint is not known 2002 at configuration time. Since OSPFv3 exchanges multicast packets as 2003 well as unicast ones, the use of IKE within OSPFv3 is not 2004 appropriate. Therefore, this document mandates the use of manual 2005 keys. 2007 8.3. Host Identity Protocol (HIP) 2009 8.3.1. RFC 5201, Host Identity Protocol (E, Apr. 2008) 2011 IP addresses perform two distinct functions: host identifier and 2012 locator. This document specifies a protocol that allows consenting 2013 hosts to securely establish and maintain shared IP-layer state, 2014 allowing separation of the identifier and locator roles of IP 2015 addresses. This enables continuity of communications across IP 2016 address (locator) changes. It uses public key identifiers from a new 2017 Host Identity (HI) namespace for peer authentication. It uses the 2018 HMAC-SHA-1-96 and the AES-CBC algorithms with IPsec ESP and AH for 2019 protecting its signaling messages. 2021 8.3.2. RFC 5202, Using the Encapsulating Security Payload (ESP) 2022 Transport Format with the Host Identity Protocol (HIP) (E, Apr. 2008) 2024 The HIP base exchange specification [RFC5201] does not describe any 2025 transport formats or methods for describing how ESP is used to 2026 protect user data to be used during the actual communication. 2027 [RFC5202] specifies a set of HIP protocol extensions for creating a 2028 pair of ESP Security Associations (SAs) between the hosts during the 2029 base exchange. After the HIP association and required ESP SAs have 2030 been established between the hosts, the user data communication is 2031 protected using ESP. In addition, this document specifies how to use 2032 the ESP Security Parameter Index (SPI) is used to indicate the right 2033 host context(host identity) and methods to update an existing ESP 2034 Security Association. 2036 8.3.3. RFC 5206, End-Host Mobility and Multihoming with the Host 2037 Identity (E, Apr. 2008) 2039 When a host uses HIP, the overlying protocol sublayers (e.g., 2040 transport layer sockets) and Encapsulating Security Payload (ESP) 2041 Security Associations (SAs) are bound to representations of these 2042 host identities, and the IP addresses are only used for packet 2043 forwarding. [RFC5206] defines a generalized LOCATOR parameter for 2044 use in HIP messages that allows a HIP host to notify a peer about 2045 alternate addresses at which it is reachable. It also specifies how 2046 a host can change its IP address and continue to send packets to its 2047 peers without necessarily rekeying. 2049 8.3.4. RFC 5207, NAT and Firewall Traversal Issues of Host Identity 2050 Protocol (HIP) (I, Apr. 2008) 2052 [RFC5207] discusses the problems associated with HIP communication 2053 across network paths that include network address translators and 2054 firewalls. It analyzes the impact of NATs and firewalls on the HIP 2055 base exchange and the ESP data exchange. It discusses possible 2056 changes to HIP that attempt to improve NAT and firewall traversal and 2057 proposes a rendezvous point for letting HIP nodes behind a NAT be 2058 reachable. It also suggests mechanisms for NATs to be more aware of 2059 the HIP messages. 2061 8.4. Stream Control Transmission Protocol (SCTP) 2063 8.4.1. RFC 3554, On the Use of Stream Control Transmission Protocol 2064 (SCTP) with IPsec (S, Jul. 2003) 2066 The Stream Control Transmission Protocol (SCTP) is a reliable 2067 transport protocol operating on top of a connection-less packet 2068 network such as IP. [RFC3554] describes functional requirements for 2069 IPsec and IKE to be used in securing SCTP traffic. It adds support 2070 for SCTP in the form of a new ID type in IKE [RFC2409] and 2071 implementation choices in the IPsec processing to account for the 2072 multiple source and destination addresses associated with a single 2073 SCTP association. This document applies only to IKEv1 and IPsec-v2; 2074 it does not apply to IKEv2 AND IPsec-v3. 2076 8.5. Robust Header Compression (ROHC) 2077 8.5.1. RFC 3095, RObust Header Compression (ROHC): Framework and four 2078 profiles: RTP, UDP, ESP, and uncompressed (S, July 2001) 2080 ROHC is a framework for header compression, intended to be used in 2081 resource-constrained environments. [RFC3095] applies this framework 2082 to four protocols, including ESP. 2084 8.5.2. RFC 5225, RObust Header Compression Version 2 (ROHCv2): Profiles 2085 for RTP, UDP, IP, ESP, and UDP-Lite (S, April 2008) 2087 [RFC5225] defines an updated ESP/IP profile for use with ROHC version 2088 2. It analyzes the ESP header and classifies the fields into several 2089 classes like static, well-known, irregular etc. in order to 2090 efficiently compress the headers. 2092 8.5.3. RFC 5856, Integration of Robust Header Compression over IPsec 2093 Security Associations (I, May 2010) 2095 [RFC5856] describes a mechanism to compress inner IP headers at the 2096 ingress point of IPsec tunnels and to decompress them at the egress 2097 point. Since the Robust Header Compression (ROHC) specifications 2098 only describe operations on a per-hop basis, this document also 2099 specifies extensions to enable ROHC over multiple hops. This 2100 document applies only to tunnel mode SAs and does not support 2101 transport mode SAs. 2103 8.5.4. RFC 5857, IKEv2 Extensions to Support Robust Header Compression 2104 over IPsec (S, May 2010) 2106 ROHC requires initial configuration at the compressor and 2107 decompressor ends. Since ROHC usually operates on a per-hop basis 2108 this configuration information is carried over link-layer protocols 2109 such as PPP. Since [RFC5856] operates over multiple hops a different 2110 signaling mechanism is required. [RFC5857] describes how to use 2111 IKEv2 in order to dynamically communicate the configuration 2112 parameters between the compressor and decompressor. 2114 8.5.5. RFC 5858, IPsec Extensions to Support Robust Header Compression 2115 over IPsec (S, May 2010) 2117 [RFC5856] describes how to use ROHC with IPsec. This is not possible 2118 without extensions to IPsec. [RFC5858] describes the extensions 2119 needed to IPsec in order to support ROHC. Specifically, it describes 2120 extensions needed to the IPsec SPD, SAD and to the IPsec processing 2121 including ICV computation and integrity verification. 2123 8.6. Border Gateway Protocol (BGP) 2124 8.6.1. RFC 5566, BGP IPsec Tunnel Encapsulation Attribute (S, Jun. 2125 2009) 2127 [RFC5566] adds an additional BGP Encapsulation Subsequent Address 2128 Family Identifier (SAFI), allowing the use of IPsec and, optionally, 2129 of IKE to protect BGP tunnels. It defines the use of AH and ESP in 2130 tunnel mode, and the use of AH and ESP in transport mode to protect 2131 IP in IP and MPLS-in-IP tunnels. It also defines how public key 2132 fingerprints (hashes) are distributed via BGP, and used later to 2133 authenticate IKEv2 exchange between the tunnel endpoints. 2135 8.7. IPsec Benchmarking 2137 8.7.1. draft-ietf-bmwg-ipsec-meth, Methodology for Benchmarking IPsec 2138 Devices (S, Work in progress) 2140 [bmwg-1] defines a set of tests that can be used to measure and 2141 report the performance characteristics of IPsec devices. It extends 2142 the methodology defined for benchmarking network interconnecting 2143 devices to include IPsec gateways and adds further tests which can be 2144 used to measure IPsec performance of end-hosts. The document 2145 focusses on establishing a performance testing methodology for IPsec 2146 devices that support manual keying and IKEv1, but does not cover 2147 IKEv2. 2149 8.7.2. draft-ietf-bmwg-ipsec-term, Terminology for Benchmarking IPsec 2150 Devices (I, Work in progress) 2152 [bmwg-2] is defines the standardized performance testing terminology 2153 for IPsec devices that support manual keying and IKEv1. It also 2154 describes the benchmark tests that would be used to test the 2155 performance of the IPsec devices. 2157 8.8. Network Address Translators (NAT) 2159 8.8.1. RFC 2709, Security Model with Tunnel-mode IPsec for NAT domains 2160 (I, Oct. 1999) 2162 NAT devices provide transparent routing to end hosts trying to 2163 communicate from disparate address realms, by modifying IP and 2164 transport headers en-route. This makes it difficult for applications 2165 to pursue end-to-end application level security. [RFC2709] describes 2166 a security model by which tunnel-mode IPsec security can be 2167 architected on NAT devices. It defines how NATs administer security 2168 policies and SA attributes based on private realm addressing. It 2169 also specifies how to operate IKE in such scenarios by specifying an 2170 IKE-ALG (Application Level Gateway) that translates policies from 2171 private realm addressing into public addressing. Although the model 2172 presented here uses terminology from IKEv1, it can be deployed within 2173 IKEv1, IKEv2, IPsec-v2 and IPsec-v3. This security model has not 2174 been widely adopted 2176 8.9. Session Initiation Protocol (SIP) 2178 8.9.1. RFC 3329, Security Mechanism Agreement for the Session 2179 Initiation Protocol (SIP) (S, Jan. 2003) 2181 [RFC3329] describes how a SIP client can select one of the various 2182 available SIP security mechanisms. In particular, the method allows 2183 secure negotiation to prevent bidding down attacks. It also 2184 describes a security mechanism called ipsec-3gpp and its associated 2185 parameters (algorithms, protocols, mode, SPIs and ports) as they are 2186 used in the 3GPP IP Multimedia Subsystem. 2188 8.10. Explicit Packet Sensitivity Labels 2190 8.10.1. RFC 5570, Common Architecture Label IPv6 Security Option 2191 (CALIPSO) (I, Jul. 2009) 2193 [RFC5570] describes a mechanism used to encode explicit packet 2194 Sensitivity Labels on IPv6 packets in Multi-Level Secure (MLS) 2195 networks. The method is implemented using an IPv6 hop-by-hop option. 2196 This document uses the IPsec Authentication Header (AH) in order to 2197 detect any malicious modification of the Sensitivity Label in a 2198 packet. 2200 9. Other Protocols that adapt IKE for non-IPsec functionality 2202 Some protocols protect their traffic through mechanisms other than 2203 IPsec, but use IKEv2 as a basic for their key negotiation and key 2204 management functionality. 2206 9.1. Extensible Authentication Protocol (EAP) 2208 9.1.1. RFC 5106, The Extensible Authentication Protocol-Internet Key 2209 Exchange Protocol version 2 (EAP-IKEv2) Method (E, Feb. 2008) 2211 [RFC5106] specifies an Extensible Authentication Protocol (EAP) 2212 method that is based on the Internet Key Exchange (IKEv2) protocol. 2213 EAP-IKEv2 provides mutual authentication and session key 2214 establishment between an EAP peer and an EAP server. It describes 2215 the full EAP-IKEv2 message exchange and the composition of the 2216 protocol messages. 2218 9.2. Fibre Channel 2219 9.2.1. RFC 4595, Use of IKEv2 in the Fibre Channel Security Association 2220 Management Protocol (I, Jul. 2006) 2222 Fibre Channel (FC) is a gigabit-speed network technology used for 2223 Storage Area Networking. The Fibre Channel Security Protocols 2224 standard (FC-SP) has adapted the IKEv2 protocol [RFC4306] to provide 2225 authentication of Fibre Channel entities and setup of security 2226 associations. Since IP is transported over Fibre Channel and Fibre 2227 Channel is transported over IP, there is the potential for confusion 2228 when IKEv2 is used for both IP and FC traffic. [RFC4595] specifies 2229 identifiers for IKEv2 over FC in a fashion that ensures that any 2230 mistaken usage of IKEv2/FC over IP or IKEv2/IP over FC will result in 2231 a negotiation failure due to the absence of an acceptable proposal. 2233 9.3. Wireless Security 2235 9.3.1. RFC 4705, GigaBeam High-Speed Radio Link Encryption (I, Oct. 2236 2006) 2238 [RFC4705] describes the encryption and key management used by 2239 GigaBeam as part of the WiFiber(tm) family of radio link products and 2240 is intended to serve as a guideline for similar wireless product 2241 development efforts to include comparable capabilities. It specifies 2242 the algorithms that are used to provide confidentiality and integrity 2243 protection of both subscriber and management traffic. It also 2244 specifies a custom security protocol that runs between two Gigabeam 2245 Radio Control Modules (RCMs). 2247 10. Acknowledgements 2249 The authors would like to thank Yaron Sheffer, Paul Hoffman, Yoav 2250 Nir, Rajeshwar Singh Jenwar, Alfred Hoenes, Al Morton, Gabriel 2251 Montenegro, Sean Turner, Julien Laganier, Grey Daley, Scott Moonen, 2252 Richard Graveman, Tero Kivinen, Pasi Eronen, Ran Atkinson, David 2253 Black and Tim Polk for reviewing this document and suggesting 2254 changes. 2256 11. Security Considerations 2258 There are no security considerations relevant to this document. 2260 12. IANA Considerations 2262 No actions are required from IANA as result of the publication of 2263 this document. 2265 13. References 2266 13.1. Normative References 2268 13.2. Informative References 2270 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2271 Requirement Levels", BCP 14, RFC 2119, March 1997. 2273 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 2274 3", RFC 2026, October 1996. 2276 [bmwg-1] Kaeo, M. and T. Van Herck, "Methodology for Benchmarking 2277 IPsec Devices", draft-ietf-bmwg-ipsec-meth, Work in 2278 Progress. 2280 [bmwg-2] Kaeo, M., Van Herck T. and M. Bustos, "Terminology for 2281 Benchmarking IPsec Devices", draft-ietf-bmwg-ipsec-term, 2282 Work in Progress. 2284 [ipsecme-1] Kaufman, C., P. Hoffman, Y. Nir and P. Eronen, "Internet 2285 Key Exchange Protocol: IKEv2", 2286 draft-ietf-ipsecme-ikev2bis, Work in Progress. 2288 [ipsecme-2] Eronen, P., H. Tschofenig and Y. Sheffer, 2289 draft-ietf-ipsecme-eap-mutual, "An Extension for EAP-Only 2290 Authentication in IKEv2", Work in Progress. 2292 [ipsecme-3] Nir, Y., draft-ietf-ipsecme-ipsec-ha, "IPsec High 2293 Availability and Load Sharing Problem Statement", Work in 2294 Progress. 2296 [RFC2394] Pereira, R., "IP Payload Compression Using DEFLATE", RFC 2297 2394, December 1998. 2299 [RFC2395] Friend, R. and R. Monsour, "IP Payload Compression Using 2300 LZS", RFC 2395, December 1998. 2302 [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the 2303 Internet Protocol", RFC 2401, November 1998 (obsolete). 2305 [RFC2402] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2306 2402, November 1998 (obsolete). 2308 [RFC2403] Madson, C. and R. Glenn, "The Use of HMAC-MD5-96 within 2309 ESP and AH", RFC 2403, November 1998. 2311 [RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within 2312 ESP and AH", RFC 2404, November 1998. 2314 [RFC2405] Madson, C. and N. Doraswamy, "The ESP DES-CBC Cipher 2315 Algorithm With Explicit IV", RFC 2405, November 1998. 2317 [RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security 2318 Payload (ESP)", RFC 2406, November 1998 (obsolete). 2320 [RFC2407] Piper, D., "The Internet IP Security Domain of 2321 Interpretation for ISAKMP", RFC 2407, November 1998 2322 (obsolete). 2324 [RFC2408] Maughan, D. M. Schertler, M. Schneider and J. Turner, 2325 "Internet Security Association and Key Management Protocol 2326 (ISAKMP)", RFC 2408, November 1998 (obsolete). 2328 [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange 2329 (IKE)", RFC 2409, November 1998 (obsolete). 2331 [RFC2410] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and 2332 Its Use With IPsec", RFC 2410, November 1998. 2334 [RFC2411] Thayer, R., N. Doraswamy and R. Glenn, "IP Security 2335 Document Roadmap", RFC 2411, November 1998. 2337 [RFC2412] Orman, H., "The OAKLEY Key Determination Protocol", RFC 2338 2412, November 1998. 2340 [RFC2451] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher 2341 Algorithms", RFC 2451, November 1998. 2343 [RFC2521] Karn, P. and W. Simpson, "ICMP Security Failures 2344 Messages", RFC 2521, March 1999. 2346 [RFC2709] Srisuresh, P., "Security Model with Tunnel-mode IPsec for 2347 NAT Domains", RFC 2709, October 1999. 2349 [RFC2857] Keromytis, A. and N. Provos, "The Use of 2350 HMAC-RIPEMD-160-96 within ESP and AH", RFC 2857, June 2351 2000. 2353 [RFC3051] Heath, J. and J. Border, "IP Payload Compression Using 2354 ITU-T V.44 Packet Method", RFC 3051, January 2001. 2356 [RFC3056] Carpenter, B., "Connection of IPv6 Domains via IPv4 2357 Clouds", RFC 3056, February 2001. 2359 [RFC3095] Bormann, C., Ed. et.al., "RObust Header Compression 2360 (ROHC): Framework and four profiles: RTP, UDP, ESP, and 2361 uncompressed", RFC 3095, July 2001. 2363 [RFC3129] Thomas, M., "Requirements for Kerberized Internet 2364 Negotiation of Keys", RFC 3129, June 2001. 2366 [RFC3173] Shacham, A. B. Monsour, R. Pereira and M. Thomas, "IP 2367 Payload Compression Protocol (IPComp)", RFC 3173, 2368 September 2001. 2370 [RFC3329] Arkko, J., V. Torvinen, G. Camarillo, A. Niemi and T. 2371 Haukka, "Security Mechanism Agreement for the Session 2372 Initiation Protocol (SIP)", RFC 3329, January 2003. 2374 [RFC3456] Patel, B. B. Aboba, S. Kelly and V. Gupta, "Dynamic Host 2375 Configuration Protocol (DHCPv4) Configuration of IPsec 2376 Tunnel Mode", RFC 3456, January 2003. 2378 [RFC3457] Kelly, S. and S. Ramamoorthi, "Requirements for IPsec 2379 Remote Access Scenarios", RFC 3457, January 2003. 2381 [RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) 2382 Diffie-Hellman groups for Internet Key Exchange (IKE)", 2383 RFC 3526, May 2003. 2385 [RFC3547] Baugher, M. B. Weis, T. Hardjono and H. Harney, "The Group 2386 Domain of Interpretation", RFC 3547, July 2003. 2388 [RFC3554] Bellovin, S. J. Ioannidis, A. Keromytis and R. Stewart, 2389 "On the Use of Stream Control Transmission Protocol (SCTP) 2390 with IPsec", RFC 3554, July 2003. 2392 [RFC3566] Frankel, S. and H. Herbert, "The AES-XCBC-MAC-96 Algorithm 2393 and Its Use With IPsec", RFC 3566, September 2003. 2395 [RFC3585] Jason, J. L. Rafalow, and E. Vyncke, "IPsec Configuration 2396 Policy Information Model", RFC 3585, August 2003. 2398 [RFC3586] Blaze, M. A. Keromytis, M. Richardson and L. Sanchez, "IP 2399 Security Policy (IPSP) Requirements", RFC 3586, August 2400 2003. 2402 [RFC3602] Frankel, S. R. Glenn and S. Kelly, "The AES-CBC Cipher 2403 Algorithm and Its Use with IPsec", RFC 3602, September 2404 2003. 2406 [RFC3686] Housley, R., "Using Advanced Encryption Standard (AES) 2407 Counter Mode With IPsec Encapsulating Security Payload 2408 (ESP)", RFC 3686, January 2004. 2410 [RFC3706] Huang, G., S. Beaulieu and D. Rochefort, "A Traffic-Based 2411 Method of Detecting Dead Internet Key Exchange (IKE) 2412 Peers", RFC 3706, February 2004. 2414 [RFC3715] Aboba, B. and W. Dixon, "IPsec-Network Address Translation 2415 (NAT) Compatibility Requirements", RFC 3715, March 2004. 2417 [RFC3740] Hardjono, T. and B. Weis, "The Multicast Group Security 2418 Architecture", RFC 3740, March 2004. 2420 [RFC3776] Arkko, J., V. Devarapalli and F. Dupont, "Using IPsec to 2421 Protect Mobile IPv6 Signaling Between Mobile Nodes and 2422 Home Agents", RFC 3776, June 2004. 2424 [RFC3830] Arkko, J., E. Carrara, F. Lindholm, M. Naslund and K. 2425 Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, 2426 August 2004. 2428 [RFC3884] Touch, J., L. Eggert and Y. Wang, "Use of IPsec Transport 2429 Mode for Dynamic Routing", RFC 3884, September 2004. 2431 [RFC3947] Kivinen, T., B. Swander, A. Huttunen and V. Volpe, 2432 "Negotiation of NAT-Traversal in the IKE", RFC 3947, 2433 January 2005. 2435 [RFC3948] Huttunen, A., B. Swander, V. Volpe, L. DiBurro and M. 2436 Stenberg, "UDP Encapsulation of IPsec ESP Packets", RFC 2437 3948, January 2005. 2439 [RFC4025] Richardson, M., "A method for storing IPsec keying 2440 material in DNS", RFC 4025, February 2005. 2442 [RFC4046] Baugher, M., R. Canetti, L. Dondeti and F. Lindholm, 2443 "Multicast Security (MSEC) Group Key Management 2444 Architecture", RFC 4046, April 2005. 2446 [RFC4093] Adrandi, F., Ed. and H. Levkowetz, Ed., "Problem 2447 Statement: Mobile IPv4 Traversal of Virtual Private 2448 Network (VPN) Gateways", RFC 4093, August 2005. 2450 [RFC4106] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode 2451 (GCM) in IPsec Encapsulating Security Payload (ESP)", RFC 2452 4106, June 2005. 2454 [RFC4109] Hoffman, P., "Algorithms for Internet Key Exchange version 2455 1 (IKEv1)", RFC 4109, May 2005. 2457 [RFC4196] Lee, H.J., J.H. Yoon, S.L. Lee and J.I. Lee, "The SEED 2458 Cipher Algorithm and Its Use with IPsec", RFC 4196, 2459 October 2005. 2461 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 2462 Internet Protocol", RFC 4301, December 2005. 2464 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 2465 2005. 2467 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 2468 4303, December 2005. 2470 [RFC4304] Kent, S., "Extended Sequence Number (ESN) Addendum to 2471 IPsec Domain of Interpretation (DOI) for Internet Security 2472 Association and Key Management Protocol (ISAKMP)", RFC 2473 4304, December 2005. 2475 [RFC4305] Eastlake, D. 3rd, "Cryptographic Algorithm Implementation 2476 Requirements for Encapsulating Security Payload (ESP) and 2477 Authentication Header (AH)", RFC 4305, December 2005 2478 (obsolete). 2480 [RFC4306] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) 2481 Protocol", RFC 4306, December 2005. 2483 [RFC4307] Schiller, J., "Cryptographic Algorithms for Use in the 2484 Internet Key Exchange Version 2 (IKEv2)", RFC 4307, 2485 December 2005. 2487 [RFC4308] Hoffman, P., "Cryptographic Suites for IPsec", RFC 4308, 2488 December 2005. 2490 [RFC4309] Housley, R., "Using Advanced Encryption Standard (AES) CCM 2491 Mode with IPsec Encapsulating Security Payload (ESP)", RFC 2492 4309, December 2005. 2494 [RFC4312] Kato, A., S. Moriai and M. Kanda, "The Camellia Cipher 2495 Algorithm and Its Use with IPsec", RFC 4312, December 2496 2005. 2498 [RFC4322] Richardson, M. and D.H. Redelmeier, "Opportunistic 2499 Encryption using the Internet Key Exchange (IKE)", RFC 2500 4322, December 2005. 2502 [RFC4359] Weis, B., "The Use of RSA/SHA-1 Signatures within 2503 Encapsulating Security Payload (ESP) and Authentication 2504 Header (AH)", RFC 4359, January 2006. 2506 [RFC4430] Sakane, S., K. Kamada, M. Thomas, and J. Vilhuber, 2507 "Kerberized Internet Negotiation of Keys (KINK)", RFC 2508 4430, March 2006. 2510 [RFC4434] Hoffman, P., "The AES-XCBC-PRF-128 Algorithm for the 2511 Internet Key Exchange Protocol (IKE)", RFC 4434, February 2512 2006. 2514 [RFC4478] Nir, Y., "Repeated Authentication in Internet Key Exchange 2515 (IKEv2) Protocol", RFC 4478, April 2006. 2517 [RFC4494] Song, JH., R. Poovendran and J. Lee, "The AES-CMAC-96 2518 Algorithm and Its Use with IPsec", RFC 4494, June 2006. 2520 [RFC4535] Harney, H., U. Meth, A. Colegrove and G. Gross, "GSAKMP: 2521 Group Secure Association Key Management Protocol", RFC 2522 4535, June 2006. 2524 [RFC4543] McGrew, D. and J. Viega, "The Use of Galois Message 2525 Authentication Code (GMAC) in IPsec ESP and AH", RFC 4543, 2526 May 2006. 2528 [RFC4552] Gupta, M. and N. Melam, "Authentication/Confidentiality 2529 for OSPFv3", RFC 4552, June 2006. 2531 [RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol 2532 (MOBIKE)", RFC 4555, June 2006. 2534 [RFC4595] Maino, F. and D. Black, "Use of IKEv2 in the Fibre Channel 2535 Security Association Management Protocol", RFC 4595, July 2536 2006. 2538 [RFC4615] Song, J., R. Poovendran, J. Lee and T. Iwata, "The 2539 Advanced Encryption Standard-Cipher-based Message 2540 Authentication Code-Pseudo-Random Function-128 2541 (AES-CMAC-PRF-128) Algorithm for the Internet Key Exchange 2542 Protocol (IKE)", RFC 4615, August 2006. 2544 [RFC4621] Kivinen, T. and H. Tschofenig, "Design of the IKEv2 2545 Mobility and Multihoming (MOBIKE) Protocol", RFC 4621, 2546 August 2006. 2548 [RFC4705] Housley, R. and A. Corry, "GigaBeam High-Speed Radio Link 2549 Encryption", RFC 4705, October 2006. 2551 [RFC4718] Eronen, P. and P. Hoffman, "IKEv2 Clarifications and 2552 Implementation Guidelines", RFC 4718, October 2006. 2554 [RFC4739] Eronen P. and J. Korhonen, "Multiple Authentication 2555 Exchanges in the Internet Key Exchange (IKEv2) Protocol", 2556 RFC 4739, November 2006. 2558 [RFC4753] Fu, D. and J. Solinas, "ECP Groups For IKE and IKEv2", RFC 2559 4753, January 2007. 2561 [RFC4754] Fu, D. and J. Solinas, "IKE and IKEv2 Authentication Using 2562 the Elliptic Curve Digital Signature Algorithm (ECDSA)", 2563 RFC 4754, January 2007. 2565 [RFC4806] Myers, M. and H. Tschofenig, "Online Certificate Status 2566 Protocol (OCSP) Extensions to IKEv2", RFC 4806, February 2567 2007. 2569 [RFC4807] Baer, M., R. Charlet, W. Hardaker, R. Story and C. Wang, 2570 "IPsec Security Policy Database Configuration MIB", RFC 2571 4807, March 2007. 2573 [RFC4809] Bonatti, C., Ed., and S. Turner, Ed., "Requirements for an 2574 IPsec Certificate Management Profile", RFC 4809, February 2575 2007. 2577 [RFC4835] Manral, V., "Cryptographic Algorithm Implementation 2578 Requirements for Encapsulating Security Payload (ESP) and 2579 Authentication Header (AH)", RFC 4835, April 2007. 2581 [RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, 2582 HMAC-SHA-384, and HMAC-SHA-512 with IPsec", RFC 4868, May 2583 2007. 2585 [RFC4869] Law, L. and J. Solinas, "Suite B Cryptographic Suites for 2586 IPsec", RFC 4869, May 2007. 2588 [RFC4877] Devarapalli, V. and R. Dupont, "Mobile IPv6 Operation with 2589 IKEv2 and the Revised IPsec Architecture", RFC 4877, April 2590 2007. 2592 [RFC4891] Graveman, R., M. Parthasarathy, P. Savola and H. 2593 Tschofenig, "Using IPsec to Secure IPv6-in-IPv4 Tunnels", 2594 RFC 4891, May 2007. 2596 [RFC4894] Hoffman, P., "Use of Hash Algorithms in Internet Key 2597 Exchange (IKE) and IPsec", RFC 4894, May 2007. 2599 [RFC4945] Korver, B., "The Internet IP Security PKI Profile of 2600 IKEv1/ISAKMP, IKEv2, and PKIX", RFC 4945, August 2007. 2602 [RFC5026] Giaretta, G., Ed., J. Kempf and V. Devarapalli, Ed., 2603 "Mobile IPv6 Bootstrapping in Split Scenario", RFC 5026, 2604 October 2007. 2606 [RFC5106] Tschofenig, H., D. Kroeselberg, A. Pashalidis, Y. Ohba and 2607 F. Bersani, "The Extensible Authentication 2608 Protocol-Internet Key Exchange Protocol version 2 2609 (EAP-IKEv2) Method", RFC 5106, February 2008. 2611 [RFC5114] Lepinski, M. and S. Kent, "Additional Diffie-Hellman 2612 Groups for Use with IETF Standards", RFC 5114, January 2613 2008. 2615 [RFC5201] Moskowitz, R., P. Nikander, P. Jokela, Ed., and T. 2616 Henderson, "Host Identity Protocol", RFC 5201, April 2008. 2618 [RFC5202] Jokela, P., R. Moskowitz and P. Nikander, "Using the 2619 Encapsulating Security Payload (ESP) Transport Format with 2620 the Host Identity Protocol (HIP)", RFC 5202, April 2008. 2622 [RFC5206] Nikander, P., T. Henderson, Ed., C. Vogt, and J. Arkko, 2623 "End-Host Mobility and Multihoming with the Host 2624 Identity", RFC 5206, April 2008. 2626 [RFC5207] Stiemerling, M., J. Quittek and L. Eggert, "NAT and 2627 Firewall Traversal Issues of Host Identity Protocol 2628 (HIP)", RFC 5207, April 2008. 2630 [RFC5213] Gundavelli, S., Ed., K. Leung, V. Devarapali, K. Chowdhury 2631 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 2633 [RFC5225] Pelletier, G. and K. Sandlund, "RObust Header Compression 2634 Version 2 (ROHCv2): Profiles for RTP, UDP, IP, ESP, and 2635 UDP-Lite", RFC 5225, April 2008. 2637 [RFC5265] Vaarala, S. and E. Klovning, "Mobile IPv4 Traversal across 2638 IPsec-Based VPN Gateways", RFC 5265, June 2008. 2640 [RFC5266] Devarapalli, V. and P. Eronen, "Secure Connectivity and 2641 Mobility Using Mobile IPv4 and IKEv2 Mobility and 2642 Multihoming (MOBIKE)", RFC 5266, June 2008. 2644 [RFC5268] Koodli, R., Ed., "Mobile IPv6 Fast Handovers", RFC 5268, 2645 June 2008. 2647 [RFC5282] Black, D. and D. McGrew, " Using Authenticated Encryption 2648 Algorithms with the Encrypted Payload of the Internet Key 2649 Exchange version 2 (IKEv2) Protocol", RFC 5282, August 2650 2008. 2652 [RFC5380] Soliman, H., C. Castelluccia, K. ElMalki and L. Bellier, 2653 "Hierarchical Mobile IPv6 (HMIPv6) Mobility Management", 2654 RFC 5380, October 2008. 2656 [RFC5386] Williams, N. and M. Richardson, 2657 "Better-Than-Nothing-Security: An Unauthenticated Mode of 2658 IPsec", RFC 5386, November 2008. 2660 [RFC5374] Weis, B., G. Gross and D. Ignjatic, "Multicast Extensions 2661 to the Security Architecture for the Internet Protocol", 2662 RFC 5374, November 2008. 2664 [RFC5387] Touch, J., D. Black and Y. Wang, "Problem and 2665 Applicability Statement for Better-Than-Nothing Security 2666 (BTNS)", RFC 5387, November 2008. 2668 [RFC5406] Bellovin, S., "Guidelines for Specifying the Use of IPsec 2669 Version 2", RFC 5406, February 2009. 2671 [RFC5529] Kato, A., M. Kanda and S. Kanno, "Modes of Operation for 2672 Camellia for Use with IPsec", RFC 5529, April 2009. 2674 [RFC5566] Berger, L., R. White and E. Rosen, "BGP IPsec Tunnel 2675 Encapsulation Attribute", RFC 5566, June 2009. 2677 [RFC5570] StJohns, M., R. Atkinson and G. Thomas, "Common 2678 Architecture Label IPv6 Security Option (CALIPSO)", RFC 2679 5570, July 2009. 2681 [RFC5660] Williams, N., "IPsec Channels: Connection Latching", RFC 2682 5660, October 2009. 2684 [RFC5685] Devarapalli, V and K. Weniger, "Re-direct Mechanism for 2685 the Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 2686 5685, November 2009. 2688 [RFC5723] Sheffer, Y., H. Tschofenig, L. Dondeti and V. Narayanan, 2689 "Internet Key Exchange Protocol Version 2 (IKEv2) Session 2690 Resumption", RFC 5723, January 2010. 2692 [RFC5739] Eronen, P., J. Laganier and C. Madson, "IPv6 Configuration 2693 in Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 2694 5739, February 2010. 2696 [RFC5840] Grewal, K. and G. Montenegro, "Wrapped Encapsulating 2697 Security Payload (ESP) for Traffic Visibility", RFC 5840, 2698 April 2010. 2700 [RFC5856] Ertekin, E., R. Jasani, C. Christou and C. Bormann, 2701 "Integration of Robust Header Compression over IPsec 2702 Security Associations", RFC 5856, May 2010. 2704 [RFC5857] Ertekin, E., C. Christou, R. Jasani, T. Kivinen and C. 2705 Bormann, "IKEv2 Extensions to Support Robust Header 2706 Compression over IPsec", RFC 5857, May 2010. 2708 [RFC5858] Ertekin, E., C. Christou and C. Bormann, "IPsec Extensions 2709 to Support Robust Header Compression over IPsec", RFC 2710 5858, May 2010. 2712 [RFC5879] Kivinen, T. and D. McDonald, "Heuristics for Detecting 2713 ESP-NULL packets", RFC 5879, May 2010. 2715 [RFC5903] Fu, D. and J. Solinas, "Elliptic Curve Groups modulo a 2716 Prime (ECP Groups) for IKE and IKEv2", RFC 5903, June 2717 2010. 2719 [RFC5930] Shen, S., Y. Mao and N.S.S. Murthy, "Using Advanced 2720 Encryption Standard Counter Mode (AES-CTR) with the 2721 Internet Key Exchange version 02 (IKEv2) Protocol", RFC 2722 5930, July 2010. 2724 Appendix A. Summary of Algorithm Requirement Levels 2726 Table 1: Algorithm Requirement Levels 2728 +--------------------------+----------------------------------------+ 2729 | ALGORITHM | REQUIREMENT LEVEL | 2730 | | IKEv1 IKEv2 IPsec-v2 IPsec-v3 | 2731 +--------------------------+----------------------------------------+ 2732 |Encryption Algorithms: | 2733 |--------------------- | 2734 | ESP-NULL | N/A N/A MUST MUST | 2735 | | | 2736 | 3DES-CBC | MUST MUST- MUST MUST- | 2737 | | | 2738 | Blowfish/CAST/IDEA/RC5 | optional optional optional optional | 2739 | | | 2740 | AES-CBC 128-bit key | SHOULD SHOULD+ MUST MUST | 2741 | | | 2742 | AES-CBC 192/256-bit key | optional optional optional optional | 2743 | | | 2744 | AES-CTR | undefined optional SHOULD SHOULD | 2745 | | | 2746 | Camellia-CBC | optional optional optional optional | 2747 | | | 2748 | Camellia-CTR | undefined undefined undefined optional | 2749 | | | 2750 | SEED-CBC | undefined undefined optional undefined| 2751 | | | 2752 |Integrity-Protection Algorihms: | 2753 |------------------------------ | 2754 | HMAC-SHA-1 | MUST MUST MUST MUST | 2755 | | | 2756 | AES-XCBC-MAC | undefined optional SHOULD+ SHOULD+ | 2757 | | | 2758 | HMAC-SHA-256/384/512 | optional optional optional optional | 2759 | | | 2760 | AES-GMAC | N/A N/A undefined optional | 2761 | | | 2762 | HMAC-MD5 | MAY optional MAY MAY | 2763 | | | 2764 | AES-CMAC | undefined optional undefined optional | 2765 | | | 2766 | HMAC-RIPEMD | undefined undefined optional undefined| 2767 +--------------------------+----------------------------------------+ 2768 Table 1: Algorithm Requirement Levels (continued) 2770 +--------------------------+----------------------------------------+ 2771 | ALGORITHM | REQUIREMENT LEVEL | 2772 | | IKEv1 IKEv2 IPsec-v2 IPsec-v3 | 2773 +--------------------------+----------------------------------------+ 2774 |Combined Mode Algorithms: | 2775 |------------------------ | 2776 | AES-CCM | N/A optional N/A optional | 2777 | | | 2778 | AES-GCM | N/A optional N/A optional | 2779 | | | 2780 | AES-GMAC | N/A N/A undefined optional | 2781 | | | 2782 | Camellia-CCM | N/A undefined N/A optional | 2783 | | | 2784 |Pseudo-Random Functions: | 2785 |----------------------- | 2786 | PRF-HMAC-SHA1 | MUST MUST | 2787 | | | 2788 | PRF-HMAC-SHA-256/384/512 | optional optional | 2789 | | | 2790 | AES-XCBC-PRF | undefined SHOULD+ | 2791 | | | 2792 | AES-CMAC-PRF | undefined optional | 2793 | | | 2794 |Diffie-Hellman Algorithms: | 2795 |------------------------- | 2796 | DH MODP grp 1 | MAY optional | 2797 | | | 2798 | DH MODP grp 2 | MUST MUST- | 2799 | | | 2800 | DH MODP grp 5 | optional optional | 2801 | | | 2802 | DH MODP grp 14 | SHOULD SHOULD+ | 2803 | | | 2804 | DH MODP grp 15-18 | optional optional | 2805 | | | 2806 | DH MODP grp 22-24 | optional optional | 2807 | | | 2808 | DH EC grp 3-4 | MAY undefined | 2809 | | | 2810 | DH EC grp 19-21 | optional optional | 2811 | | | 2812 | DH EC grp 25-26 | optional optional | 2813 +--------------------------+----------------------------------------+ 2815 Authors' Addresses 2817 Sheila Frankel 2818 NIST 2819 Bldg. 223 Rm. B366 2820 Gaithersburg, MD 20899 2822 Phone: 1-301-975-3297 2823 Email: sheila.frankel@nist.gov 2825 Suresh Krishnan 2826 Ericsson 2827 8400 Decarie Blvd. 2828 Town of Mount Royal, QC 2829 Canada 2831 Phone: 1-514-345-7900 x42871 2832 Email: suresh.krishnan@ericsson.com