draft-ietf-ipsecme-roadmap-05.txt   draft-ietf-ipsecme-roadmap-06.txt 
Network Working Group S. Frankel Network Working Group S. Frankel
Internet Draft NIST Internet Draft NIST
Obsoletes: 2411 (if approved) S. Krishnan Obsoletes: 2411 (if approved) S. Krishnan
Intended Status: Informational Ericsson Intended Status: Informational Ericsson
Expires: August 2010 February 4, 2010 Expires: November 2010 May 28, 2010
IP Security (IPsec) and Internet Key Exchange (IKE) Document Roadmap IP Security (IPsec) and Internet Key Exchange (IKE) Document Roadmap
<draft-ietf-ipsecme-roadmap-05.txt> <draft-ietf-ipsecme-roadmap-06.txt>
Status of this Memo Status of this Memo
Distribution of this memo is unlimited. Distribution of this memo is unlimited.
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 35 skipping to change at page 1, line 35
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html. http://www.ietf.org/1id-abstracts.html.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 4, 2010. This Internet-Draft will expire on November 28, 2010.
Copyright and License Notice Copyright and License Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 34 skipping to change at page 2, line 34
2.2. Versions of IPsec . . . . . . . . . . . . . . . . . . . . . 6 2.2. Versions of IPsec . . . . . . . . . . . . . . . . . . . . . 6
2.2.1. Differences between "old" IPsec (IPsec-v2) and 2.2.1. Differences between "old" IPsec (IPsec-v2) and
"new" IPsec (IPsec-v3) . . . . . . . . . . . . . . . . 6 "new" IPsec (IPsec-v3) . . . . . . . . . . . . . . . . 6
2.3. Versions of IKE . . . . . . . . . . . . . . . . . . . . . . 7 2.3. Versions of IKE . . . . . . . . . . . . . . . . . . . . . . 7
2.3.1. Differences between IKEv1 and IKEv2 . . . . . . . . . . 7 2.3.1. Differences between IKEv1 and IKEv2 . . . . . . . . . . 7
2.4. IPsec and IKE IANA Registries . . . . . . . . . . . . . . . 8 2.4. IPsec and IKE IANA Registries . . . . . . . . . . . . . . . 8
3. IPsec Documents . . . . . . . . . . . . . . . . . . . . . . . . 9 3. IPsec Documents . . . . . . . . . . . . . . . . . . . . . . . . 9
3.1. Base Documents . . . . . . . . . . . . . . . . . . . . . . 9 3.1. Base Documents . . . . . . . . . . . . . . . . . . . . . . 9
3.1.1. "Old" IPsec . . . . . . . . . . . . . . . . . . . . . . 9 3.1.1. "Old" IPsec . . . . . . . . . . . . . . . . . . . . . . 9
3.1.2. "New" IPsec . . . . . . . . . . . . . . . . . . . . . . 11 3.1.2. "New" IPsec . . . . . . . . . . . . . . . . . . . . . . 11
3.2. Policy . . . . . . . . . . . . . . . . . . . . . . . . . . 12 3.2. Additions to IPsec . . . . . . . . . . . . . . . . . . . . 11
3.3. MIBs . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 3.3. General Considerations . . . . . . . . . . . . . . . . . . 13
3.4. Additions to IPsec . . . . . . . . . . . . . . . . . . . . 13 4. IKE Documents . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.5. General Considerations . . . . . . . . . . . . . . . . . . 15 4.1. Base Documents . . . . . . . . . . . . . . . . . . . . . . 14
4. IKE Documents . . . . . . . . . . . . . . . . . . . . . . . . . 16 4.1.1. IKEv1 . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.1. Base Documents . . . . . . . . . . . . . . . . . . . . . . 16 4.1.2. IKEv2 . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.1.1. IKEv1 . . . . . . . . . . . . . . . . . . . . . . . . . 16 4.2. Additions and Extensions . . . . . . . . . . . . . . . . . 17
4.1.2. IKEv2 . . . . . . . . . . . . . . . . . . . . . . . . . 18 4.2.1. Peer Authentication Methods . . . . . . . . . . . . . . 17
4.2. Additions and Extensions . . . . . . . . . . . . . . . . . 19 4.2.2. Certificate Contents and Management . . . . . . . . . . 18
4.2.1. Peer Authentication Methods . . . . . . . . . . . . . . 19 4.2.3. Dead Peer Detection . . . . . . . . . . . . . . . . . . 19
4.2.2. Certificate Contents and Management . . . . . . . . . . 20 4.2.4. Remote Access . . . . . . . . . . . . . . . . . . . . . 19
4.2.3. Dead Peer Detection . . . . . . . . . . . . . . . . . . 21 5. Cryptographic Algorithms and Suites . . . . . . . . . . . . . . 20
4.2.4. Remote Access . . . . . . . . . . . . . . . . . . . . . 21 5.1. Algorithm Requirements . . . . . . . . . . . . . . . . . . 21
5. Cryptographic Algorithms and Suites . . . . . . . . . . . . . . 22 5.2. Encryption Algorithms . . . . . . . . . . . . . . . . . . . 22
5.1. Algorithm Requirements . . . . . . . . . . . . . . . . . . 23 5.3. Integrity-Protection (Authentication) Algorithms . . . . . 25
5.2. Encryption Algorithms . . . . . . . . . . . . . . . . . . . 24 5.4. Combined Mode Algorithms . . . . . . . . . . . . . . . . . 28
5.3. Integrity-Protection (Authentication) Algorithms . . . . . 28 5.5. Pseudo-Random Functions (PRFs) . . . . . . . . . . . . . . 31
5.4. Combined Mode Algorithms . . . . . . . . . . . . . . . . . 31 5.6. Cryptographic Suites . . . . . . . . . . . . . . . . . . . 32
5.5. Pseudo-Random Functions (PRFs) . . . . . . . . . . . . . . 33 5.7. Diffie-Hellman Algorithms . . . . . . . . . . . . . . . . . 33
5.6. Cryptographic Suites . . . . . . . . . . . . . . . . . . . 35
5.7. Diffie-Hellman Algorithms . . . . . . . . . . . . . . . . . 36 6. IPsec/IKE for Multicast . . . . . . . . . . . . . . . . . . . . 34
6. IPsec/IKE for Multicast . . . . . . . . . . . . . . . . . . . . 37 7. Outgrowths of IPsec/IKE . . . . . . . . . . . . . . . . . . . . 37
7. Outgrowths of IPsec/IKE . . . . . . . . . . . . . . . . . . . . 40 7.1. IPsec Policy . . . . . . . . . . . . . . . . . . . . . . . 37
7.1. IPComp (Compression) . . . . . . . . . . . . . . . . . . . 40 7.2. IPsec MIBs . . . . . . . . . . . . . . . . . . . . . . . . 38
7.2. IKEv2 Mobility and Multihoming (MOBIKE) . . . . . . . . . . 41 7.3. IPComp (Compression) . . . . . . . . . . . . . . . . . . . 38
7.3. Better-than-Nothing Security (BTNS) . . . . . . . . . . . . 42 7.4. IKEv2 Mobility and Multihoming (MOBIKE) . . . . . . . . . . 38
7.4. Kerberized Internet Negotiation of Keys (KINK) . . . . . . 42 7.5. Better-than-Nothing Security (BTNS) . . . . . . . . . . . . 39
7.5. IPsec Secure Remote Access (IPSRA) . . . . . . . . . . . . 43 7.6. Kerberized Internet Negotiation of Keys (KINK) . . . . . . 40
7.6. IPsec Keying Information Resource Record (IPSECKEY) . . . . 44 7.7. IPsec Secure Remote Access (IPSRA) . . . . . . . . . . . . 41
8. Other Protocols that use IPsec/IKE . . . . . . . . . . . . . . . 44 7.8. IPsec Keying Information Resource Record (IPSECKEY) . . . . 41
8.1. Mobile IP (MIPv4 and MIPv6) . . . . . . . . . . . . . . . . 44 8. Other Protocols that use IPsec/IKE . . . . . . . . . . . . . . . 42
8.2. Open Shortest Path First (OSPF) . . . . . . . . . . . . . . 46 8.1. Mobile IP (MIPv4 and MIPv6) . . . . . . . . . . . . . . . . 42
8.3. Host Identity Protocol (HIP) . . . . . . . . . . . . . . . 46 8.2. Open Shortest Path First (OSPF) . . . . . . . . . . . . . . 44
8.4. Extensible Authentication Protocol (EAP) Method Update 8.3. Host Identity Protocol (HIP) . . . . . . . . . . . . . . . 44
(EMU) . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 8.4. Extensible Authentication Protocol (EAP) . . . . . . . . . 46
8.5. Stream Control Transmission Protocol (SCTP) . . . . . . . . 48 8.5. Stream Control Transmission Protocol (SCTP) . . . . . . . . 46
8.6. Fibre Channel . . . . . . . . . . . . . . . . . . . . . . . 48 8.6. Fibre Channel . . . . . . . . . . . . . . . . . . . . . . . 46
8.7. Robust Header Compression (ROHC) . . . . . . . . . . . . . 48 8.7. Robust Header Compression (ROHC) . . . . . . . . . . . . . 46
8.8. Border Gateway Protocol (BGP) . . . . . . . . . . . . . . . 49 8.8. Border Gateway Protocol (BGP) . . . . . . . . . . . . . . . 47
8.9. IPsec benchmarking . . . . . . . . . . . . . . . . . . . . 49 8.9. IPsec Benchmarking . . . . . . . . . . . . . . . . . . . . 48
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 50 8.10. Network Address Translators (NAT) . . . . . . . . . . . . 48
10. Security Considerations . . . . . . . . . . . . . . . . . . . . 50 8.11. Session Initiation Protocol (SIP) . . . . . . . . . . . . 49
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 50 8.12. Wireless Security . . . . . . . . . . . . . . . . . . . . 49
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 49
12.1. Normative References . . . . . . . . . . . . . . . . . . . 50 10. Security Considerations . . . . . . . . . . . . . . . . . . . . 49
12.2. Informative References . . . . . . . . . . . . . . . . . . 50 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 49
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
12.1. Normative References . . . . . . . . . . . . . . . . . . . 49
12.2. Informative References . . . . . . . . . . . . . . . . . . 49
Appendix A. Summary of IPsec/IKE Document Requirement Levels . . . 61 Appendix A. Summary of IPsec/IKE Document Requirement Levels . . . 61
Appendix B. Summary of Algorithm Requirement Levels . . . . . . . . 64 Appendix B. Summary of Algorithm Requirement Levels . . . . . . . . 64
1. Introduction 1. Introduction
IPsec (Internet Protocol Security) is a suite of protocols that IPsec (Internet Protocol Security) is a suite of protocols that
provides security to Internet communications at the IP layer. The provides security to Internet communications at the IP layer. The
most common current use of IPsec is to provide a Virtual Private most common current use of IPsec is to provide a Virtual Private
Network (VPN), either between two locations (gateway-to-gateway) or Network (VPN), either between two locations (gateway-to-gateway) or
between a remote user and an enterprise network (host-to-gateway); it between a remote user and an enterprise network (host-to-gateway); it
can also provide end-to-end, or host-to-host, security. IPsec is can also provide end-to-end, or host-to-host, security. IPsec is
skipping to change at page 4, line 39 skipping to change at page 4, line 39
o B: Best Current Practice o B: Best Current Practice
o I: Informational o I: Informational
For each RFC, the publication date is also given. For each RFC, the publication date is also given.
This document also categorizes the requirements level for the IPsec, This document also categorizes the requirements level for the IPsec,
IKE and cryptographic algorithms documents for use with IKEv1, IKEv2, IKE and cryptographic algorithms documents for use with IKEv1, IKEv2,
IPsec-v2 and IPsec-v3. These requirements are summarized in IPsec-v2 and IPsec-v3. These requirements are summarized in
Appendices A and B. Appendices A and B. These levels are current as of May 2010;
subsequent RFCs may result in altered requirement levels.
For each core IPsec and IKE RFC, this document will classify its For each core IPsec and IKE RFC, Table 1 (Appendix A) classifies its
Requirements Level for each protocol (IKEv1, IKEv2, IPsec-v2, Requirements Level for each protocol (IKEv1, IKEv2, IPsec-v2,
IPsec-v3), as either MUST, SHALL or MAY [RFC2119]; optional; IPsec-v3), as either MUST, SHOULD or MAY [RFC2119]; optional;
undefined; or N/A (not applicable). Optional means that either the undefined; or N/A (not applicable). Optional means that either the
RFC describes features that are not required to be implemented or RFC describes features that are not required to be implemented or
settings or procedures that are recommended but not mandatory. settings or procedures that are recommended but not mandatory.
Undefined means that some aspect of the RFC is not fully defined for Undefined means that some aspect of the RFC is not fully defined for
the specific version of the protocol. N/A means that use of the RFC the specific version of the protocol. N/A means that use of the RFC
is inappropriate in the context (e.g., combined mode algorithms, a is inappropriate in the context (e.g., combined mode algorithms, a
new feature in IPsec-v3, for use with IPsec-v2). The classification new feature in IPsec-v3, for use with IPsec-v2). The classification
of the cryptographic algorithm RFCs is further explained in Section of the cryptographic algorithm RFCs is further explained in Section
5. 5.
The usage of terms in this document conforms to definitions in This document does not define requirement levels; it simply restates
[RFC4949]. those found in the IKE and IPsec RFCs. If there is a conflict
between this document and any other RFC, then the other RFC takes
precedence.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2. IPsec/IKE Background Information 2. IPsec/IKE Background Information
2.1. Interrelationship of IPsec/IKE Documents 2.1. Interrelationship of IPsec/IKE Documents
The main documents describing the set of IPsec protocols are divided The main documents describing the set of IPsec protocols are divided
skipping to change at page 10, line 29 skipping to change at page 10, line 29
- SPD (Security Policy Database): an ordered database that - SPD (Security Policy Database): an ordered database that
expresses the security protections to be afforded to different types expresses the security protections to be afforded to different types
and classes of traffic. The 3 general classes of traffic are: and classes of traffic. The 3 general classes of traffic are:
traffic to be discarded, traffic that is allowed without IPsec traffic to be discarded, traffic that is allowed without IPsec
protection, and traffic that requires IPsec protection. protection, and traffic that requires IPsec protection.
The RFC describes general inbound and outbound IPsec processing; it The RFC describes general inbound and outbound IPsec processing; it
also includes details on several special cases: packet fragments, also includes details on several special cases: packet fragments,
ICMP messages, and multicast traffic. ICMP messages, and multicast traffic.
Requirements levels for RFC2401:
IPsec-v2 - MUST
IPsec-v3 - N/A
3.1.1.2. RFC 2402, IP Authentication Header (S, Nov. 1998) 3.1.1.2. RFC 2402, IP Authentication Header (S, Nov. 1998)
[RFC2402] defines the Authentication Header (AH), which provides [RFC2402] defines the Authentication Header (AH), which provides
integrity protection; it also provides data origin authentication, integrity protection; it also provides data origin authentication,
access control, and, optionally, replay protection. A transport mode access control, and, optionally, replay protection. A transport mode
AH SA, used to protect peer-to-peer communications, protects AH SA, used to protect peer-to-peer communications, protects
upper-layer data, as well as those portions of the IP header that do upper-layer data, as well as those portions of the IP header that do
not vary unpredictably during packet delivery. A tunnel mode AH SA not vary unpredictably during packet delivery. A tunnel mode AH SA
can be used to protect gateway-to-gateway or host-to-gateway traffic; can be used to protect gateway-to-gateway or host-to-gateway traffic;
it can optionally be used for host-to-host traffic. This class of AH it can optionally be used for host-to-host traffic. This class of AH
SA protects the inner (original) header and upper-layer data, as well SA protects the inner (original) header and upper-layer data, as well
as those portions of the outer (tunnel) header that do not vary as those portions of the outer (tunnel) header that do not vary
unpredictably during packet delivery. Because portions of the IP unpredictably during packet delivery. Because portions of the IP
header are not included in the AH calculations, AH processing is more header are not included in the AH calculations, AH processing is more
complex than ESP processing. AH also does not work in the presence complex than ESP processing. AH also does not work in the presence
of Network Address Translation (NAT). Unlike IPsec-v3, IPsec-v2 of Network Address Translation (NAT). Unlike IPsec-v3, IPsec-v2
classifies AH as mandatory-to-implement. classifies AH as mandatory-to-implement.
Requirements levels for RFC2402:
IPsec-v2 - MUST
IPsec-v3 - N/A
3.1.1.3. RFC 2406, IP Encapsulating Security Payload (ESP) (S, Nov. 3.1.1.3. RFC 2406, IP Encapsulating Security Payload (ESP) (S, Nov.
1998) 1998)
[RFC2406] defines the IP Encapsulating Security Payload (ESP), which [RFC2406] defines the IP Encapsulating Security Payload (ESP), which
provides confidentiality (encryption) and/or integrity protection; it provides confidentiality (encryption) and/or integrity protection; it
also provides data origin authentication, access control, and, also provides data origin authentication, access control, and,
optionally, replay and/or traffic analysis protection. A transport optionally, replay and/or traffic analysis protection. A transport
mode ESP SA protects the upper-layer data, but not the IP header. A mode ESP SA protects the upper-layer data, but not the IP header. A
tunnel mode ESP SA protects the upper-layer data and the inner tunnel mode ESP SA protects the upper-layer data and the inner
header, but not the outer header. header, but not the outer header.
Requirements levels for RFC2406:
IPsec-v2 - MUST
IPsec-v3 - N/A
3.1.2. "New" IPsec 3.1.2. "New" IPsec
3.1.2.1. RFC 4301, Security Architecture for the Internet Protocol (S, 3.1.2.1. RFC 4301, Security Architecture for the Internet Protocol (S,
Dec. 2005) Dec. 2005)
[RFC4301] obsoletes [RFC2401], including a more complete and detailed [RFC4301] obsoletes [RFC2401], including a more complete and detailed
processing model. The most notable changes are detailed above in processing model. The most notable changes are detailed above in
Section 2.2.1. IPsec-v3 processing incorporates an additional Section 2.2.1. IPsec-v3 processing incorporates an additional
database: database:
- PAD (Peer Authorization Database): contains information - PAD (Peer Authorization Database): contains information
necessary to conduct peer authentication, providing a link between necessary to conduct peer authentication, providing a link between
IPsec and the key management procotol (e.g. IKE) IPsec and the key management procotol (e.g. IKE)
Requirements levels for RFC4301:
IPsec-v2 - N/A
IPsec-v3 - MUST
3.1.2.2. RFC 4302, IP Authentication Header (S, Dec. 2005) 3.1.2.2. RFC 4302, IP Authentication Header (S, Dec. 2005)
[RFC4302] obsoletes [RFC2402]. Unlike IPsec-v2, IPsec-v3 classifies [RFC4302] obsoletes [RFC2402]. Unlike IPsec-v2, IPsec-v3 classifies
AH as optional. AH as optional.
Requirements levels for RFC4302:
IPsec-v2 - N/A
IPsec-v3 - optional
3.1.2.3. RFC 4303, IP Encapsulating Security Payload (ESP) (S, Dec. 3.1.2.3. RFC 4303, IP Encapsulating Security Payload (ESP) (S, Dec.
2005) 2005)
[RFC4303] obsoletes [RFC2406]. The most notable changes are detailed [RFC4303] obsoletes [RFC2406]. The most notable changes are detailed
above in Section 2.2.1. above in Section 2.2.1.
Requirements levels for RFC4303: 3.2. Additions to IPsec
IPsec-v2 - N/A
IPsec-v3 - MUST
3.2. Policy
The IPsec Policy Working Group (ipsp) originally planned an RFC that
would allow entities with no common Trust Anchor and no prior
knowledge of each others' security policies to establish an
IPsec-protected connection. The solutions that were proposed for
gateway discovery and security policy negotiation proved to be overly
complex and fragile, in the absence of prior knowledge or compatible
configuration policies.
3.2.1. RFC 3586, IP Security Policy (IPSP) Requirements (S, Aug. 2003)
[RFC3586] describes the functional requirements of a generalized
IPsec policy framework, that could be used to discover, negotiate and
manage IPsec policies.
Requirements levels for RFC3586:
IKEv1 - optional
IKEv2 - N/A
IPsec-v2 - optional
IPsec-v3 - N/A
3.2.2. RFC 3585, IPsec Configuration Policy Information Model (S, Aug.
2003)
As stated in [RFC3585], "This document presents an object-oriented
information model of IP Security (IPsec) policy designed to
facilitate agreement about the content and semantics of IPsec policy,
and enable derivations of task-specific representations of IPsec
policy such as storage schema, distribution representations, and
policy specification languages used to configure IPsec-enabled
endpoints." This RFC has not been widely adopted.
Requirements levels for RFC3585:
IKEv1 - optional
IKEv2 - N/A
IPsec-v2 - optional
IPsec-v3 - N/A
3.3. MIBs
Over the years, several MIB-related Internet Drafts were proposed for
IPsec and IKE, but only one progressed to RFC status.
3.3.1. RFC 4807, IPsec Security Policy Database Configuration MIB (S,
Mar. 2007)
[RFC4807] defines a MIB module that can be used to configure the SPD
of an IPsec device. This RFC has not been widely adopted.
Requirements levels for RFC4807:
IPsec-v2 - optional
IPsec-v3 - N/A
3.4. Additions to IPsec
Once the IKEv1 and IPsec-v2 RFCs were finalized, several additions Once the IKEv1 and IPsec-v2 RFCs were finalized, several additions
were defined in separate documents: negotiation of NAT traversal, were defined in separate documents: negotiation of NAT traversal,
extended sequence numbers, and UDP encapsulation of ESP packets. extended sequence numbers, UDP encapsulation of ESP packets,
opportunistic encryption, and IPsec-related ICMP messages.
Additional uses of IPsec transport mode were also described: Additional uses of IPsec transport mode were also described:
protection of manually-configured IPv6-in-IPv4 tunnels and protection protection of manually-configured IPv6-in-IPv4 tunnels and protection
of IP-in-IP tunnels. These documents describe atypical uses of IPsec of IP-in-IP tunnels. These documents describe atypical uses of IPsec
transport mode, but do not define any new IPsec features. transport mode, but do not define any new IPsec features.
Once the original IPsec working group concluded, additional Once the original IPsec working group concluded, additional
IPsec-related issues were handled by the IPsecME (IPsec Maintenance IPsec-related issues were handled by the IPsecME (IPsec Maintenance
and Extensions) working group. One such problem is the capability of and Extensions) working group. One such problem is the capability of
middleboxes to distinguish unencrypted ESP packets (ESP-NULL) from middleboxes to distinguish unencrypted ESP packets (ESP-NULL) from
encrypted ones in a fast and accurate manner. Two solutions are encrypted ones in a fast and accurate manner. Two solutions are
described: a new protocol that requires changes to IKEv2 and described: a new protocol that requires changes to IKEv2 and
IPsec-v3, and a heuristic method that imposes no new requirements. IPsec-v3, and a heuristic method that imposes no new requirements.
Another issue that was addressed is the problems of using IKE and
IPsec in a high availability environment.
3.4.1. RFC 3947, Negotiation of NAT-Traversal in the IKE (S, Jan. 2005) 3.2.1. RFC 3947, Negotiation of NAT-Traversal in the IKE (S, Jan. 2005)
[RFC3947] enables IKEv1 to detect whether there are any NATs between
the negotiating peers, and whether both peers support NAT traversal.
It also describes how IKEv1 can be used to negotiate the use of UDP
encapsulation of ESP packets for the IPsec SA. For IKEv2, this
capability is described in [RFC4306].
Requirements levels for RFC3947:
IKEv1 - optional
IKEv2 - N/A (included in RFC4306)
3.4.2. RFC 3948, UDP Encapsulation of IPsec ESP Packets (S, Jan. 2005) [RFC3947] defines an optional extension to IKEv1. It enables IKEv1
to detect whether there are any NATs between the negotiating peers,
and whether both peers support NAT traversal. It also describes how
IKEv1 can be used to negotiate the use of UDP encapsulation of ESP
packets for the IPsec SA. For IKEv2, this capability is described in
[RFC4306].
[RFC3948] defines how to encapsulate ESP packets in UDP packets to 3.2.2. RFC 3948, UDP Encapsulation of IPsec ESP Packets (S, Jan. 2005)
enable the traversal of NATs that discard packets with protocols
other than UDP or TCP. This makes it possible for ESP packets to
pass through the NAT device without requiring any change to the NAT
device itself. The use of this solution is negotiated by IKE, as
described in [RFC3947] for IKEv1 and [RFC4306] for IKEv2.
Requirements levels for RFC3948: [RFC3948] is an optional extension for IPsec-v2 and IPsec-v3. It
IPsec-v2 - optional defines how to encapsulate ESP packets in UDP packets to enable the
IPsec-v3 - optional traversal of NATs that discard packets with protocols other than UDP
or TCP. This makes it possible for ESP packets to pass through the
NAT device without requiring any change to the NAT device itself.
The use of this solution is negotiated by IKE, as described in
[RFC3947] for IKEv1 and [RFC4306] for IKEv2.
3.4.3. RFC 4304, Extended Sequence Number (ESN) Addendum to IPsec 3.2.3. RFC 4304, Extended Sequence Number (ESN) Addendum to IPsec
Domain of Interpretation (DOI) for Internet Security Association and Domain of Interpretation (DOI) for Internet Security Association and
Key Management Protocol (ISAKMP) (S, Dec. 2005) Key Management Protocol (ISAKMP) (S, Dec. 2005)
The use of ESNs allows IPsec to use 64-bit sequence numbers for The use of ESNs allows IPsec to use 64-bit sequence numbers for
replay protection, but to send only 32 bits of the sequence number in replay protection, but to send only 32 bits of the sequence number in
the packet, enabling shorter packets and avoiding a re-design of the the packet, enabling shorter packets and avoiding a re-design of the
packet format. The larger sequence numbers allow an existing IPsec packet format. The larger sequence numbers allow an existing IPsec
SA to be used for larger volumes of data. [RFC4304] describes an SA to be used for larger volumes of data. [RFC4304] describes an
extension to IKEv1 to negotiate the use of ESNs for IPsec-v3 SAs. optional extension to IKEv1 that enables IKEv1 to negotiate the use
For IKEv2, this capability is described in [RFC4306]. of ESNs for IPsec SAs. For IKEv2, this capability is described in
[RFC4306].
Requirements levels for RFC4304: 3.2.4. RFC 4322, Opportunistic Encryption using the Internet Key
IKEv1 - optional Exchange (IKE) (I, Dec. 2005)
IKEv2 - N/A (included in RFC4306)
IPsec-v2 - optional
IPsec-v3 - optional
3.4.4. RFC 4891, Using IPsec to Secure IPv6-in-IPv4 Tunnels (I, May Opportunistic encryption allows a pair of end systems to use
encryption without any specific pre-arrangements. [RFC4322]
specifies a mechanism that uses DNS to distribute the public keys of
each system involved and uses DNSSEC to secure the mechanism against
active attackers. It specifies the changes that are needed in
existing IPsec and IKE implementations. The majority of the changes
are needed in the IKE implementation and these changes relate to
handling of key acquisition requests, lookup of public keys and TXT
records, and interactions with firewalls and other security
facilities that may be co-resident on the same gateway.
3.2.5. RFC 4891, Using IPsec to Secure IPv6-in-IPv4 Tunnels (I, May
2007) 2007)
[RFC4891] describes how to use IKE and transport-mode IPsec to [RFC4891] describes how to use IKE and transport-mode IPsec to
provide security protection to manually-configured IPv6-in-IPv4 provide security protection to manually-configured IPv6-in-IPv4
tunnels. This document uses standard IKE and IPsec, without any new tunnels. This document uses standard IKE and IPsec, without any new
extensions. It does not apply to tunnels that are initiated in an extensions. It does not apply to tunnels that are initiated in an
automated manner (e.g., 6to4 tunnels [RFC3056]). automated manner (e.g., 6to4 tunnels [RFC3056]).
Requirements levels for RFC4891: 3.2.6. RFC 3884, Use of IPsec Transport Mode for Dynamic Routing (I,
IPsec-v2 - optional
IPsec-v3 - optional
3.4.5. RFC 3884, Use of IPsec Transport Mode for Dynamic Routing (I,
Sep. 2004) Sep. 2004)
[RFC3884] describes the use of transport-mode IPsec to secure [RFC3884] describes the use of transport-mode IPsec to secure
IP-in-IP tunnels, which constitute the links of a multi-hop, IP-in-IP tunnels, which constitute the links of a multi-hop,
distributed virtual network (VN). This allows the traffic to be distributed virtual network (VN). This allows the traffic to be
dynamically routed via the VN's trusted routers, rather than routing dynamically routed via the VN's trusted routers, rather than routing
all traffic through a statically-routed IPsec tunnel. This RFC has all traffic through a statically-routed IPsec tunnel. This RFC has
not been widely adopted. not been widely adopted.
Requirements levels for RFC3884: 3.2.7. RFC 5840, Wrapped Encapsulating Security Payload (ESP) for
IPsec-v2 - optional Traffic Visibility (S, Apr. 2010)
IPsec-v3 - optional
3.4.6. draft-ietf-ipsecme-traffic-visibility, Wrapped ESP for Traffic
Visibility (S)
ESP, as defined in [RFC4303], does not allow a network device to ESP, as defined in [RFC4303], does not allow a network device to
easily determine whether protected traffic that is passing through easily determine whether protected traffic that is passing through
the device is encrypted, or only integrity-protected (referred to as the device is encrypted, or only integrity-protected (referred to as
ESP-NULL packets). [ipsecme-3] extends ESP to provide explicit ESP-NULL packets). [RFC5840] extends ESPv3 to provide explicit
notification of integrity-protected packets, and extends IKEv2 to notification of integrity-protected packets, and extends IKEv2 to
negotiate this capability between the IPsec peers. negotiate this capability between the IPsec peers.
Requirements levels for draft-ietf-ipsecme-traffic-visibility: 3.2.8. RFC 5840, Heuristics for Detecting ESP-NULL packets (I, May
IPsec-v2 - N/A 2010)
IPsec-v3 - optional
3.4.7. draft-ietf-ipsecme-esp-null-heuristics, Heuristics for Detecting
ESP-NULL packets (I)
[ipsecme-4] offers an alternative approach to differentiating between [RFC5840] offers an alternative approach to differentiating between
ESP-encrypted and ESP-NULL packets, through packet inspection. This ESP-encrypted and ESP-NULL packets, through packet inspection. This
method does not require any change to IKEv2 or ESP. method does not require any change to IKE or ESP; it can be used with
ESP-v2 or ESP-v3.
Requirements levels for draft-ietf-ipsecme-esp-null-heuristics:
IPsec-v2 - optional
IPsec-v3 - optional
3.5. General Considerations 3.3. General Considerations
3.5.1. RFC 3715, IPsec-Network Address Translation (NAT) Compatibility 3.3.1. RFC 3715, IPsec-Network Address Translation (NAT) Compatibility
Requirements (I, Mar. 2004) Requirements (I, Mar. 2004)
[RFC3715] "describes known incompatibilities between NAT and IPsec, [RFC3715] "describes known incompatibilities between NAT and IPsec,
and describes the requirements for addressing them." This is a and describes the requirements for addressing them." This is a
critical issue, since IPsec is frequently used to provide VPN access critical issue, since IPsec is frequently used to provide VPN access
to the corporate network for telecommuters, and NATs are widely to the corporate network for telecommuters, and NATs are widely
deployed in home gateways, hotels, and other access networks deployed in home gateways, hotels, and other access networks
typically used for remote access. typically used for remote access.
Requirements levels for RFC3715: 3.3.2. RFC 5406, Guidelines for Specifying the Use of IPsec Version 2
IPsec-v2 - optional
IPsec-v3 - optional
3.5.2. RFC 5406, Guidelines for Specifying the Use of IPsec Version 2
(B, Feb. 2009) (B, Feb. 2009)
[RFC5406] offers guidance to protocol designers on how to ascertain [RFC5406] offers guidance to protocol designers on how to ascertain
whether IPsec is the appropriate security mechanism to provide an whether IPsec is the appropriate security mechanism to provide an
interoperable security solution for the protocol. If this is not the interoperable security solution for the protocol. If this is not the
case, it advises against attempting to define a new security case, it advises against attempting to define a new security
protocol; rather, it suggests using another standards-based security protocol; rather, it suggests using another standards-based security
protocol. The details in this document apply only to IPsec-v2. protocol. The details in this document apply only to IPsec-v2.
Requirements levels for RFC5406: 3.3.3. RFC 2521, ICMP Security Failures Messages (E, Mar. 1999)
IPsec-v2 - optional
IPsec-v3 - N/A [RFC2521] specifies an ICMP message for indicating failures related
to the use of IPsec protocols (AH and ESP). The specified ICMP
message defines several codes for handling common failure modes for
IPsec. The failures that are signaled by this message include
invalid or expired SPIs, failure of authenticity or integrity checks
on datagrams, decryption and decompression errors etc. These
messages can be used to trigger automated session-key management or
to signal to an operator the need to manually reconfigure the SAs.
This RFC has not been widely adopted. Furthermore, [RFC4301]
discusses the pros and cons of relying on unprotected ICMP messages.
3.3.4. draft-ietf-ipsecme-ipsec-ha, IPsec High Availability and Load
Sharing Problem Statement (I)
[ipsecme-4] describes the problems of using IKE and IPsec in a high
availability environment, in which one or both of the peers are
clusters of gateways. It details the numerous types of stateful
information shared by IKE and IPsec peers that would have to be
available to other members of the cluster in order to provide high
availablity, load sharing and/or failover capabilities.
4. IKE Documents 4. IKE Documents
4.1. Base Documents 4.1. Base Documents
4.1.1. IKEv1 4.1.1. IKEv1
IKE is the preferred key management protocol for IPsec. It is used IKE is the preferred key management protocol for IPsec. It is used
for peer authentication; to negotiate, modify and delete SAs; and to for peer authentication; to negotiate, modify and delete SAs; and to
negotiate authenticated keying material for use within those SAs. negotiate authenticated keying material for use within those SAs.
The standard peer authentication methods used by IKEv1 (pre-shared The standard peer authentication methods used by IKEv1 (pre-shared
secret keys and digital certificates) had several shortcomings secret keys and digital certificates) had several shortcomings
related to use of IKEv1 to enable remote user authentication to a related to use of IKEv1 to enable remote user authentication to a
corporate VPN: it could not leverage the use of legacy authentication corporate VPN: it could not leverage the use of legacy authentication
systems (e.g. RADIUS databases) to authenticate a remote user to a systems (e.g. RADIUS databases) to authenticate a remote user to a
security gateway; and it could not be used to configure remote users security gateway; and it could not be used to configure remote users
with network addresses or other information needed in order to access with network addresses or other information needed in order to access
the internal network. the internal network. Automatic key distribution is required for
IPsec-v2, but alternatives to IKE may be used to satisfy that
requirement.
Several Internet Drafts were written to address these problems: two Several Internet Drafts were written to address these problems: two
such Internet Drafts include "Extended Authentication within IKE such Internet Drafts include "Extended Authentication within IKE
(XAUTH)" (draft-beaulieu-ike-xauth and its predecessor, "Extended (XAUTH)" (draft-beaulieu-ike-xauth and its predecessor, "Extended
Authentication within ISAKMP/Oakley (XAUTH)", Authentication within ISAKMP/Oakley (XAUTH)",
draft-ietf-ipsec-isakmp-xauth) and "The ISAKMP Configuration Method" draft-ietf-ipsec-isakmp-xauth) and "The ISAKMP Configuration Method"
(draft-dukes-ike-mode-cfg and its predecessor (draft-dukes-ike-mode-cfg and its predecessor
draft-ietf-ipsec-isakmp-mode-cfg). These drafts did not progress to draft-ietf-ipsec-isakmp-mode-cfg). These drafts did not progress to
RFC status due to security flaws and other problems related to these RFC status due to security flaws and other problems related to these
solutions. However, many current IKEv1 implementations incorporate solutions. However, many current IKEv1 implementations incorporate
skipping to change at page 17, line 22 skipping to change at page 15, line 44
negotiate authenticated keying material for SAs. This document negotiate authenticated keying material for SAs. This document
implements a subset of the Oakley protocol in conjunction with ISAKMP implements a subset of the Oakley protocol in conjunction with ISAKMP
to obtain authenticated keying material for use with ISAKMP, and for to obtain authenticated keying material for use with ISAKMP, and for
other security associations such as AH and ESP for the IETF IPsec other security associations such as AH and ESP for the IETF IPsec
DOI. While historically IKEv1 was created by combining two security DOI. While historically IKEv1 was created by combining two security
protocols, ISAKMP and Oakley, in practice the combination (along with protocols, ISAKMP and Oakley, in practice the combination (along with
the IPsec DOI) has commonly been viewed as one protocol, IKEv1. The the IPsec DOI) has commonly been viewed as one protocol, IKEv1. The
protocol's origins can be seen in the organization of the documents protocol's origins can be seen in the organization of the documents
that define it. that define it.
Requirements levels for RFC2409:
IPsec-v2 - optional
(Automatic key distribution is required for IPsec-v2, but
alternatives to IKE may be used to satisfy that requirement.)
IPsec-v3 - N/A
4.1.1.2. RFC 2408, Internet Security Association and Key Management 4.1.1.2. RFC 2408, Internet Security Association and Key Management
Protocol (ISAKMP) (S, Nov. 1998) Protocol (ISAKMP) (S, Nov. 1998)
This document defines procedures and packet formats to establish, This document defines procedures and packet formats to establish,
negotiate, modify and delete Security Associations (SAs). It is negotiate, modify and delete Security Associations (SAs). It is
intended to support the negotiation of SAs for security protocols at intended to support the negotiation of SAs for security protocols at
all layers of the network stack. ISAKMP can work with many different all layers of the network stack. ISAKMP can work with many different
key exchange protocols, each with different security properties. key exchange protocols, each with different security properties.
Requirements levels for RFC2408:
IPsec-v2 - optional
IPsec-v3 - N/A
4.1.1.3. RFC 2407, The Internet IP Security Domain of Interpretation 4.1.1.3. RFC 2407, The Internet IP Security Domain of Interpretation
for ISAKMP (S, Nov. 1998) for ISAKMP (S, Nov. 1998)
Within ISAKMP, a Domain of Interpretation is used to group related Within ISAKMP, a Domain of Interpretation is used to group related
protocols using ISAKMP to negotiate security associations. Security protocols using ISAKMP to negotiate security associations. Security
protocols sharing a DOI choose security protocol and cryptographic protocols sharing a DOI choose security protocol and cryptographic
transforms from a common namespace and share key exchange protocol transforms from a common namespace and share key exchange protocol
identifiers. This document defines the Internet IP Security DOI identifiers. This document defines the Internet IP Security DOI
(IPSEC DOI), which instantiates ISAKMP for use with IP when IP uses (IPSEC DOI), which instantiates ISAKMP for use with IP when IP uses
ISAKMP to negotiate security associations. ISAKMP to negotiate security associations.
Requirements levels for RFC2407:
IPsec-v2 - optional
IPsec-v3 - N/A
4.1.1.4. RFC 2412, The OAKLEY Key Determination Protocol (I, Nov. 1998) 4.1.1.4. RFC 2412, The OAKLEY Key Determination Protocol (I, Nov. 1998)
[RFC2412] describes a key establishment protocol using which two [RFC2412] describes a key establishment protocol using which two
authenticated parties can agree on secure and secret keying material. authenticated parties can agree on secure and secret keying material.
The Oakley protocol describes a series of key exchanges-- called The Oakley protocol describes a series of key exchanges-- called
"modes"-- and details the services provided by each (e.g. perfect "modes"-- and details the services provided by each (e.g. perfect
forward secrecy for keys, identity protection, and authentication). forward secrecy for keys, identity protection, and authentication).
This document provides additional theory and background to explain This document provides additional theory and background to explain
some of the design decisions and security features of IKE and ISAKMP; some of the design decisions and security features of IKE and ISAKMP;
it does not include details necessary for the implementation of it does not include details necessary for the implementation of
IKEv1. IKEv1.
Requirements levels for RFC2412:
IPsec-v2 - optional
IPsec-v3 - N/A
4.1.2. IKEv2 4.1.2. IKEv2
4.1.2.1. RFC 4306, Internet Key Exchange (IKEv2) Protocol (S, Dec. 4.1.2.1. RFC 4306, Internet Key Exchange (IKEv2) Protocol (S, Dec.
2005) 2005)
This document describes version 2 of the Internet Key Exchange (IKE) This document describes version 2 of the Internet Key Exchange (IKE)
protocol. It covers what was covered previously by separate protocol. It covers what was covered previously by separate
documents: ISAKMP, IKE and DOI. It also addresses NAT traversal, documents: ISAKMP, IKE and DOI. It also addresses NAT traversal,
legacy authentication and remote address acquisition. IKEv2 is not legacy authentication and remote address acquisition. IKEv2 is not
interoperable with IKEv1. interoperable with IKEv1. Automatic key distribution is required for
IPsec-v3, but alternatives to IKE may be used to satisfy that
Requirements levels for RFC4306: requirement.
IPsec-v2 - N/A
IPsec-v3 - optional
(Automatic key distribution is required for IPsec-v3, but
alternatives to IKE may be used to satisfy that requirement.)
4.1.2.2. RFC 4718, IKEv2 Clarifications and Implementation Guidelines 4.1.2.2. RFC 4718, IKEv2 Clarifications and Implementation Guidelines
(I, Oct. 2006) (I, Oct. 2006)
[RFC4718] clarifies many areas of the IKEv2 specification that may be [RFC4718] clarifies many areas of the IKEv2 specification that may be
difficult to understand for developers who are not intimately difficult to understand for developers who are not intimately
familiar with the specification and its history. It does not familiar with the specification and its history. It does not
introduce any changes to the protocol, but rather provides introduce any changes to the protocol, but rather provides
descriptions that are less prone to ambiguous interpretations. The descriptions that are less prone to ambiguous interpretations. The
goal of this document is to encourage the development of goal of this document is to encourage the development of
interoperable implementations. interoperable implementations.
Requirements levels for RFC4718:
IPsec-v2 - N/A
IPsec-v3 - optional
4.1.2.3. draft-ietf-ipsecme-ikev2bis, Internet Key Exchange Protocol: 4.1.2.3. draft-ietf-ipsecme-ikev2bis, Internet Key Exchange Protocol:
IKEv2 (S) IKEv2 (S)
[ipsecme-1] combines the original IKEv2 RFC [RFC4306] with the [ipsecme-1] combines the original IKEv2 RFC [RFC4306] with the
Clarifications RFC [RFC4718], and resolves many implementation issues Clarifications RFC [RFC4718], and resolves many implementation issues
discovered by the community since the publication of these two discovered by the community since the publication of these two
documents. This document was developed by the IPsecME (IPsec documents. This document was developed by the IPsecME (IPsec
Maintenance and Extensions) working group, after the conclusion of Maintenance and Extensions) working group, after the conclusion of
the original IPsec working group. the original IPsec working group. Automatic key distribution is
required for IPsec-v3, but alternatives to IKE may be used to satisfy
Requirements levels for draft-ietf-ipsecme-ikev2bis: that requirement.
IPsec-v2 - N/A
IPsec-v3 - optional
(Automatic key distribution is required for IPsec-v3, but
alternatives to IKE may be used to satisfy that requirement.)
4.2. Additions and Extensions 4.2. Additions and Extensions
4.2.1. Peer Authentication Methods 4.2.1. Peer Authentication Methods
4.2.1.1. RFC 4478, Repeated Authentication in Internet Key Exchange 4.2.1.1. RFC 4478, Repeated Authentication in Internet Key Exchange
(IKEv2) Protocol (E, Apr. 2006) (IKEv2) Protocol (E, Apr. 2006)
[RFC4478] addresses a problem unique to remote access scenarios. How [RFC4478] addresses a problem unique to remote access scenarios. How
can the gateway (the IKE responder) force the remote user (the IKE can the gateway (the IKE responder) force the remote user (the IKE
initiator) to periodically re-authenticate, limiting the damage in initiator) to periodically re-authenticate, limiting the damage in
the case where an unauthorized user gains physical access to the the case where an unauthorized user gains physical access to the
remote host? This document defines a new status notification, that a remote host? This document defines a new status notification, that a
responder can send to an initiator, notifying the initiator that the responder can send to an initiator, notifying the initiator that the
IPsec SA will be revoked unless the initiator re-authenticates within IPsec SA will be revoked unless the initiator re-authenticates within
a specified period of time. a specified period of time. This optional extension applies only to
IKEv2, not to IKEv1.
Requirements levels for RFC4478:
IKEv1 - N/A
IKEv2 - optional
4.2.1.2. RFC 4739, Multiple Authentication Exchanges in the Internet 4.2.1.2. RFC 4739, Multiple Authentication Exchanges in the Internet
Key Exchange (IKEv2) Protocol (E, Nov. 2006) Key Exchange (IKEv2) Protocol (E, Nov. 2006)
IKEv2 supports several mechanisms for authenticating the parties but IKEv2 supports several mechanisms for authenticating the parties but
each endpoint uses only one of these mechanisms to authenticate each endpoint uses only one of these mechanisms to authenticate
itself. [RFC4739] specifies an extension to IKEv2 that allows the itself. [RFC4739] specifies an extension to IKEv2 that allows the
use of multiple authentication exchanges, using either different use of multiple authentication exchanges, using either different
mechanisms or the same mechanism. This extension allows, for mechanisms or the same mechanism. This extension allows, for
instance, performing certificate-based authentication of the client instance, performing certificate-based authentication of the client
host followed by an EAP authentication of the user. This also allows host followed by an EAP authentication of the user. This also allows
for authentication by multiple administrative domains, if needed. for authentication by multiple administrative domains, if needed.
This optional extension applies only to IKEv2, not to IKEv1.
Requirements levels for RFC4739:
IKEv1 - N/A
IKEv2 - optional
4.2.1.3. RFC 4754, IKE and IKEv2 Authentication Using the Elliptic 4.2.1.3. RFC 4754, IKE and IKEv2 Authentication Using the Elliptic
Curve Digital Signature Algorithm (ECDSA) (S, Jan. 2007) Curve Digital Signature Algorithm (ECDSA) (S, Jan. 2007)
[RFC4754] describes how the Elliptic Curve Digital Signature [RFC4754] describes how the Elliptic Curve Digital Signature
Algorithm (ECDSA) may be used as the authentication method within the Algorithm (ECDSA) may be used as the authentication method within the
IKEv1 and IKEv2 protocols. ECDSA provides many benefits including IKEv1 and IKEv2 protocols. ECDSA provides many benefits including
computational efficiency, small signature sizes, and minimal computational efficiency, small signature sizes, and minimal
bandwidth compared to other available digital signature methods like bandwidth compared to other available digital signature methods like
RSA and DSA. RSA and DSA. This optional extension applies to both IKEv1 and
IKEv2.
Requirements levels for RFC4754: 4.2.1.4 draft-ietf-ipsecme-eap-mutual, An Extension for EAP-Only
IKEv1 - optional Authentication in IKEv2 (S)
IKEv2 - optional
IKEv2 allows an initiator to use EAP for peer authentication, but
requires the responder to authenticate through the use of a digital
signature. [ipsecme-3] extends IKEv2 so that EAP methods that
provide mutual authentication and key agreement can also be used to
provide peer authentication for the responder. This optional
extension applies only to IKEv2, not to IKEv1.
4.2.2. Certificate Contents and Management (PKI4IPsec) 4.2.2. Certificate Contents and Management (PKI4IPsec)
The format, contents and interpretation of Public Key Certificates The format, contents and interpretation of Public Key Certificates
proved to be a source of interoperability problems within IKE and proved to be a source of interoperability problems within IKE and
IPsec. PKI4IPsec was an attempt to set in place some common IPsec. PKI4IPsec was an attempt to set in place some common
procedures and interpretations to mitigate those problems. procedures and interpretations to mitigate those problems.
4.2.2.1. RFC 4809, Requirements for an IPsec Certificate Management 4.2.2.1. RFC 4809, Requirements for an IPsec Certificate Management
Profile (I, Feb. 2007) Profile (I, Feb. 2007)
[RFC4809] enumerates requirements for Public Key Certificate (PKC) [RFC4809] enumerates requirements for Public Key Certificate (PKC)
lifecycle transactions between different VPN System and PKI System lifecycle transactions between different VPN System and PKI System
products in order to better enable large scale, PKI-enabled IPsec products in order to better enable large scale, PKI-enabled IPsec
deployments with a common set of transactions. This document deployments with a common set of transactions. This document
discusses requirements for both the IPsec and the PKI products. discusses requirements for both the IPsec and the PKI products. This
optional extension applies to both IKEv1 and IKEv2.
Requirements levels for RFC4809:
IKEv1 - optional
IKEv2 - optional
4.2.2.2. RFC 4945, The Internet IP Security PKI Profile of 4.2.2.2. RFC 4945, The Internet IP Security PKI Profile of
IKEv1/ISAKMP, IKEv2, and PKIX (S, Aug. 2007) IKEv1/ISAKMP, IKEv2, and PKIX (S, Aug. 2007)
[RFC4945] defines a profile of the IKE and PKIX frameworks in order [RFC4945] defines a profile of the IKE and PKIX frameworks in order
to provide an agreed-upon standard for using PKI technology in the to provide an agreed-upon standard for using PKI technology in the
context of IPsec. It also documents the contents of the relevant IKE context of IPsec. It also documents the contents of the relevant IKE
payloads and further specifies their semantics. It also summarizes payloads and further specifies their semantics. It also summarizes
the current state of implementations and deployment and provides the current state of implementations and deployment and provides
advice to avoid common interoperability issues. advice to avoid common interoperability issues. This optional
extension applies to both IKEv1 and IKEv2.
Requirements levels for RFC4945:
IKEv1 - optional
IKEv2 - optional
4.2.2.3. RFC 4806, Online Certificate Status Protocol (OCSP) Extensions 4.2.2.3. RFC 4806, Online Certificate Status Protocol (OCSP) Extensions
to IKEv2 (S, Feb. 2007) to IKEv2 (S, Feb. 2007)
When certificates are used with IKEv2, the communicating peers need a When certificates are used with IKEv2, the communicating peers need a
mechanism to determine the revocation status of the peer's mechanism to determine the revocation status of the peer's
certificate. OCSP is one such mechanism. [RFC4806] defines the certificate. OCSP is one such mechanism. [RFC4806] defines the
"OCSP Content" extension to IKEv2. This document is applicable when "OCSP Content" extension to IKEv2. This document is applicable when
OCSP is desired and security policy (e.g. firewall policy) prevents OCSP is desired and security policy (e.g. firewall policy) prevents
one of the IKEv2 peers from accessing the relevant OCSP responder one of the IKEv2 peers from accessing the relevant OCSP responder
directly. directly. This optional extension applies only to IKEv2, not to
IKEv1.
Requirements levels for RFC4806:
IKEv1 - N/A
IKEv2 - optional
4.2.3. Dead Peer Detection 4.2.3. Dead Peer Detection
4.2.3.1. RFC 3706, A Traffic-Based Method of Detecting Dead Internet 4.2.3.1. RFC 3706, A Traffic-Based Method of Detecting Dead Internet
Key Exchange (IKE) Peers (I, Feb. 2004) Key Exchange (IKE) Peers (I, Feb. 2004)
When two peers communicate using IKE and IPsec, it is possible for When two peers communicate using IKE and IPsec, it is possible for
the connectivity between the two peers to drop unexpectedly. But the the connectivity between the two peers to drop unexpectedly. But the
SAs can still remain until their lifetimes expire, resulting in the SAs can still remain until their lifetimes expire, resulting in the
packets getting tunneled into a "black hole". [RFC3706] describes an packets getting tunneled into a "black hole". [RFC3706] describes an
approach to detect peer liveliness without needing to send messages approach to detect peer liveliness without needing to send messages
at regular intervals. This RFC defines an optional extension to at regular intervals. This RFC defines an optional extension to
IKEv1; dead peer detection (DPD) is an integral part of IKEv2, which IKEv1; dead peer detection (DPD) is an integral part of IKEv2, which
refers to this feature as a "liveness check" or "liveness test". refers to this feature as a "liveness check" or "liveness test".
Requirements levels for RFC3706:
IKEv1 - optional
IKEv2 - N/A (included in RFC4306)
4.2.4. Remote Access 4.2.4. Remote Access
The IPsecME working group identified some missing components needed The IPsecME working group identified some missing components needed
for more extensive IKEv2 and IPsec-v3 support for remote access for more extensive IKEv2 and IPsec-v3 support for remote access
clients. These include: efficient client resumption of a previously clients. These include: efficient client resumption of a previously
established session with a VPN gateway; efficient client redirection established session with a VPN gateway; efficient client redirection
to an alternate VPN gateway; and support for IPv6 client to an alternate VPN gateway; and support for IPv6 client
configuration using IPsec configuration payloads. configuration using IPsec configuration payloads.
4.2.4.1. RFC 5723, Internet Key Exchange Protocol Version 2 (IKEv2) 4.2.4.1. RFC 5723, Internet Key Exchange Protocol Version 2 (IKEv2)
Session Resumption (S, Jan. 2010) Session Resumption (S, Jan. 2010)
[RFC5723] enables a remote client that has been disconnected from a [RFC5723] enables a remote client that has been disconnected from a
gateway to re-establish SAs with the gateway in an expedited manner, gateway to re-establish SAs with the gateway in an expedited manner,
without repeating the complete IKEv2 negotiation. This capability without repeating the complete IKEv2 negotiation. This capability
requires changes to IKEv2. requires changes to IKEv2. This optional extension applies only to
IKEv2, not to IKEv1.
Requirements levels for RFC5723:
IKEv1 - N/A
IKEv2 - optional
4.2.4.2. RFC 5685, Re-direct Mechanism for the Internet Key Exchange 4.2.4.2. RFC 5685, Re-direct Mechanism for the Internet Key Exchange
Protocol Version 2 (IKEv2) (S, Nov. 2009) Protocol Version 2 (IKEv2) (S, Nov. 2009)
[RFC5685] enables a gateway to securely re-direct VPN clients to [RFC5685] enables a gateway to securely re-direct VPN clients to
another VPN gateway, either during or after the IKEv2 negotiation. another VPN gateway, either during or after the IKEv2 negotiation.
Possible reasons include, but are not limited to, an overloaded Possible reasons include, but are not limited to, an overloaded
gateway or a gateway that needs to shut down. This requires changes gateway or a gateway that needs to shut down. This requires changes
to IKEv2. to IKEv2. This optional extension applies only to IKEv2, not to
IKEv1.
Requirements levels for RFC5685:
IKEv1 - N/A
IKEv2 - optional
4.2.4.3. draft-ietf-ipsecme-ikev2-ipv6-config, IPv6 Configuration in 4.2.4.3. RFC 5739, IPv6 Configuration in Internet Key Exchange Protocol
IKEv2 (E) Version 2 (IKEv2) (E, Feb. 2010)
In IKEv2, a VPN gateway can assign an internal network address to a In IKEv2, a VPN gateway can assign an internal network address to a
remote VPN client. This is accomplished through the use of remote VPN client. This is accomplished through the use of
configuration payloads. For an IPv6 client, the assignment of a configuration payloads. For an IPv6 client, the assignment of a
single address is not sufficient to enable full-fledged IPv6 single address is not sufficient to enable full-fledged IPv6
communications. [ipsecme-2] proposes several solutions that might communications. [RFC5739] proposes several solutions that might
remove this limitation. remove this limitation. This optional extension applies only to
IKEv2, not to IKEv1.
Requirements levels for draft-ietf-ipsecme-ikev2-ipv6-config:
IKEv1 - N/A
IKEv2 - optional
5. Cryptographic Algorithms and Suites 5. Cryptographic Algorithms and Suites
Two basic requirements must be met for an algorithm to be used within Two basic requirements must be met for an algorithm to be used within
IKE and/or IPsec: assignment of one or more IANA values and an RFC IKE and/or IPsec: assignment of one or more IANA values and an RFC
that describes how to use the algorithm within the relevant protocol, that describes how to use the algorithm within the relevant protocol,
packet formats, special considerations, etc. For each RFC that packet formats, special considerations, etc. For each RFC that
describes a cryptographic algorithm, this document will classify its describes a cryptographic algorithm, this document will classify its
Requirements Level for each protocol, as either MUST, SHALL or MAY Requirements Level for each protocol, as either MUST, SHOULD or MAY
[RFC2119]; optional; undefined; or N/A (not applicable). Optional [RFC2119]; optional; undefined; or N/A (not applicable). Optional
means that the algorithm meets the two basic requirements, but its means that the algorithm meets the two basic requirements, but its
use is not specifically recommended for that protocol. Undefined use is not specifically recommended for that protocol. Undefined
means that one of the basic requirements is not met: either there is means that one of the basic requirements is not met: either there is
no relevant IANA number for the algorithm, or there is no RFC no relevant IANA number for the algorithm, or there is no RFC
specifying how it should be used within that specific protocol. N/A specifying how it should be used within that specific protocol. N/A
means that use of the algorithm is inappropriate in the context means that use of the algorithm is inappropriate in the context
(e.g., NULL encryption for IKE, which always requires encryption; or (e.g., NULL encryption for IKE, which always requires encryption; or
combined mode algorithms, a new feature in IPsec-v3, for use with combined mode algorithms, a new feature in IPsec-v3, for use with
IPsec-v2). IPsec-v2).
This document categorizes the requirements level of each algorithm This document categorizes the requirements level of each algorithm
for IKEv1, IKEv2, IPsec-v2 and IPsec-v3. If an algorithm is for IKEv1, IKEv2, IPsec-v2 and IPsec-v3. If an algorithm is
recommended for use within IKEv1 or IKEv2, it is used either to recommended for use within IKEv1 or IKEv2, it is used either to
protect the IKE SA's traffic (encryption and integrity-protection protect the IKE SA's traffic (encryption and integrity-protection
algorithms) or to generate keying material (Diffie-Hellman or DH algorithms) or to generate keying material (Diffie-Hellman or DH
groups, Pseudo-Random Functions or PRFs). If an algorithm is groups, Pseudo-Random Functions or PRFs). If an algorithm is
recommended for use within IPsec, it is used to protect the recommended for use within IPsec, it is used to protect the
IPsec/child SA's traffic, and IKE is capable of negotiating its use IPsec/child SA's traffic, and IKE is capable of negotiating its use
for that purpose. These requirements are summarized in Appendix B. for that purpose. These requirements are summarized in Table 2
(Appendix B). These levels are current as of May 2010; subsequent
RFCs may result in altered requirement levels. For algorithms, this
could mean the introduction of new algorithms; or upgrading or
downgrading the requirement levels of current algorithms.
The IANA registries for IKEv1 and IKEv2 include IANA values for
various cryptographic algorithms. IKE uses these values to negotiate
IPsec SAs that will provide protection using those algorithms. If a
specific algorithm lacks a value for IKEv1 and/or IKEv2, that
algorithm's use is classified as "undefined (no IANA #) within
IPsec-v2 and/or IPsec-v3.
5.1. Algorithm Requirements 5.1. Algorithm Requirements
Specifying a core set of mandatory algorithms for each protocol Specifying a core set of mandatory algorithms for each protocol
facilitates interoperability. Defining those algorithms in an RFC facilitates interoperability. Defining those algorithms in an RFC
separate from the base protocol RFC enhances algorithm agility. separate from the base protocol RFC enhances algorithm agility.
IPsec-v3 and IKEv2 each have an RFC that specifies their IPsec-v3 and IKEv2 each have an RFC that specifies their
mandatory-to-implement (MUST), recommended (SHOULD), optional (MAY), mandatory-to-implement (MUST), recommended (SHOULD), optional (MAY),
and deprecated (SHOULD NOT) algorithms. For IPsec-v2, this is and deprecated (SHOULD NOT) algorithms. For IPsec-v2, this is
included in the base protocol RFC. That was originally the case for included in the base protocol RFC. That was originally the case for
skipping to change at page 24, line 5 skipping to change at page 21, line 32
(AH) (S, Apr. 2007) (AH) (S, Apr. 2007)
[RFC4835] specifies the encryption and integrity-protection [RFC4835] specifies the encryption and integrity-protection
algorithms for IPsec (both versions). Algorithms for IPsec-v2 were algorithms for IPsec (both versions). Algorithms for IPsec-v2 were
originally defined in [RFC2402] and [RFC2406]. [RFC4305] obsoleted originally defined in [RFC2402] and [RFC2406]. [RFC4305] obsoleted
those requirements, and was in turn obsoleted by [RFC4835]. those requirements, and was in turn obsoleted by [RFC4835].
Therefore, [RFC4835] applies to IPsec-v2 as well as IPsec-v3. Therefore, [RFC4835] applies to IPsec-v2 as well as IPsec-v3.
Combined mode algorithms are mentioned, but not assigned a Combined mode algorithms are mentioned, but not assigned a
requirement level. requirement level.
Requirements levels for RFC4835:
IPsec-v2 - MUST
IPsec-v3 - MUST
5.1.2. RFC 4307, Cryptographic Algorithms for Use in the Internet Key 5.1.2. RFC 4307, Cryptographic Algorithms for Use in the Internet Key
Exchange Version 2 (IKEv2) (S, Dec. 2005) Exchange Version 2 (IKEv2) (S, Dec. 2005)
[RFC4307] specifies the encryption and integrity-protection [RFC4307] specifies the encryption and integrity-protection
algorithms used by IKEv2 to protect its own traffic; the algorithms used by IKEv2 to protect its own traffic; the
Diffie-Hellman (DH) groups used within IKEv2; and the pseudo-random Diffie-Hellman (DH) groups used within IKEv2; and the pseudo-random
functions used by IKEv2 to generate keys, nonces and other random functions used by IKEv2 to generate keys, nonces and other random
values. values. [RFC4307] contains conflicting requirements for IKEv2
encryption and integrity-protection algorithms. Where there are
Requirements levels for RFC4307: contradictory requirements, this document takes its requirement
IKEv1 - N/A levels from section 3.1.1 (Encrypted Payload Algorithms), rather than
IKEv2 - MUST from section 3.1.3 (IKEv2 Transform Type 1 Algorithms) or section
3.1.4 (IKEv2 Transform Type 2 Algorithms).
5.1.3. RFC 4109, Algorithms for Internet Key Exchange version 1 (IKEv1) 5.1.3. RFC 4109, Algorithms for Internet Key Exchange version 1 (IKEv1)
(S, May 2005) (S, May 2005)
[RFC4109] updates IKEv1's algorithm specifications, which were [RFC4109] updates IKEv1's algorithm specifications, which were
originally defined in [RFC2409]. It specifies the encryption and originally defined in [RFC2409]. It specifies the encryption and
integrity-protection algorithms used by IKEv1 to protect its own integrity-protection algorithms used by IKEv1 to protect its own
traffic; the Diffie-Hellman (DH) groups used within IKEv1; the hash traffic; the Diffie-Hellman (DH) groups used within IKEv1; the hash
and pseudo-random functions used by IKEv1 to generate keys, nonces and pseudo-random functions used by IKEv1 to generate keys, nonces
and other random values; and the authentication methods and and other random values; and the authentication methods and
algorithms used by IKEv1 for peer authentication. algorithms used by IKEv1 for peer authentication.
Requirements levels for RFC4109:
IKEv1 - MUST
IKEv2 - N/A
5.2. Encryption Algorithms 5.2. Encryption Algorithms
The encryption algorithm RFCs describe how to use these algorithms to The encryption algorithm RFCs describe how to use these algorithms to
encrypt IKE and/or ESP traffic, providing confidentiality protection encrypt IKE and/or ESP traffic, providing confidentiality protection
to the traffic. They describe any special constraints, requirements, to the traffic. They describe any special constraints, requirements,
or changes to packet format appropriate for the specific algorithm. or changes to packet format appropriate for the specific algorithm.
In general, they do not describe the detailed algorithmic In general, they do not describe the detailed algorithmic
computations; the reference section of each RFC includes pointers to computations; the reference section of each RFC includes pointers to
documents that define the inner workings of the algorithm. Some of documents that define the inner workings of the algorithm. Some of
the RFCs include sample test data, to enable implementors to compare the RFCs include sample test data, to enable implementors to compare
skipping to change at page 26, line 49 skipping to change at page 24, line 22
decryption. decryption.
Requirements levels for AES-CTR: Requirements levels for AES-CTR:
IKEv1 - undefined (no IANA #) IKEv1 - undefined (no IANA #)
IKEv2 - optional [draft-ietf-ipsecme-aes-ctr-ikev2] IKEv2 - optional [draft-ietf-ipsecme-aes-ctr-ikev2]
ESP-v2 - SHOULD [RFC4835] ESP-v2 - SHOULD [RFC4835]
ESP-v3 - SHOULD [RFC4835] ESP-v3 - SHOULD [RFC4835]
5.2.5. draft-ietf-ipsecme-aes-ctr-ikev2, Using Advanced Encryption 5.2.5. draft-ietf-ipsecme-aes-ctr-ikev2, Using Advanced Encryption
Standard (AES) Counter Mode with IKEv2 (S) Standard (AES) Counter Mode with IKEv2 (S)
[ipsecme-5] extends [RFC3686] to enable the use of AES-CTR to provide [ipsecme-2] extends [RFC3686] to enable the use of AES-CTR to provide
encryption and integrity-protection for IKEv2 messages. encryption and integrity-protection for IKEv2 messages.
5.2.6. RFC 4312, The Camellia Cipher Algorithm and Its Use with IPsec 5.2.6. RFC 4312, The Camellia Cipher Algorithm and Its Use with IPsec
(S, Dec. 2005) (S, Dec. 2005)
[RFC4312] describes how to use Camellia in cipher block chaining [RFC4312] describes how to use Camellia in cipher block chaining
(CBC) mode to encrypt IKE and ESP traffic. Camellia-CBC is a (CBC) mode to encrypt IKE and ESP traffic. Camellia-CBC is a
block-mode cipher with a 128-bit blocksize; a random IV that is sent block-mode cipher with a 128-bit blocksize; a random IV that is sent
in the packet along with the encrypted data; and keysizes of 128, 192 in the packet along with the encrypted data; and keysizes of 128, 192
and 256 bits. 128-bit keys are MUST; the other sizes are MAY. and 256 bits. 128-bit keys are MUST; the other sizes are MAY.
skipping to change at page 31, line 38 skipping to change at page 29, line 11
integrity-protection, and IKEv1 can negotiate different combinations integrity-protection, and IKEv1 can negotiate different combinations
of algorithms for different SAs. In ESP-v3, a new class of of algorithms for different SAs. In ESP-v3, a new class of
algorithms was introduced, in which a single algorithm can provide algorithms was introduced, in which a single algorithm can provide
both encryption and integrity-protection. [RFC4306] describes how both encryption and integrity-protection. [RFC4306] describes how
IKEv2 can negotiate combined mode algorithms to be used in ESP-v3 IKEv2 can negotiate combined mode algorithms to be used in ESP-v3
SAs. [RFC5282] adds that capability to IKEv2, enabling IKEv2 to SAs. [RFC5282] adds that capability to IKEv2, enabling IKEv2 to
negotiate and use combined mode algorithms for its own traffic. When negotiate and use combined mode algorithms for its own traffic. When
properly designed, these algorithms can provide increased efficiency properly designed, these algorithms can provide increased efficiency
in both implementation and execution. in both implementation and execution.
Some IKEv1 implementations have added the capability to negotiate Although ESP-v2 did not originally include combined mode algorithms,
some IKEv1 implementations have added the capability to negotiate
combined mode algorithms for use in IPsec SAs; these implementations combined mode algorithms for use in IPsec SAs; these implementations
do not include the capability to use combined mode algorithms to do not include the capability to use combined mode algorithms to
protect IKE SAs. Since combined mode algorithms are not a feature of protect IKE SAs. IANA numbers for combined mode algorithms have been
IPsec-v2, these IKEv1 implementations are used in conjunction with added to the IKEv1 registry.
IPsec-v3. IANA numbers for combined mode algorithms have been added
to the IKEv1 registry.
5.4.1. RFC 4309, Using Advanced Encryption Standard (AES) CCM Mode with 5.4.1. RFC 4309, Using Advanced Encryption Standard (AES) CCM Mode with
IPsec Encapsulating Security Payload (ESP) (S, Dec. 2005) IPsec Encapsulating Security Payload (ESP) (S, Dec. 2005)
[RFC4309] describes how to use AES in Counter with CBC-MAC (CCM) [RFC4309] describes how to use AES in Counter with CBC-MAC (CCM)
mode, a combined alorithm, to encrypt and integrity-protect ESP-v3 mode, a combined alorithm, to encrypt and integrity-protect ESP
traffic. AES-CCM is a block-mode cipher with a 128-bit blocksize; a traffic. AES-CCM is a block-mode cipher with a 128-bit blocksize; a
random IV that is sent in the packet along with the encrypted data; a random IV that is sent in the packet along with the encrypted data; a
24-bit salt value (1/SA); keysizes of 128, 192 and 256 bits, and ICV 24-bit salt value (1/SA); keysizes of 128, 192 and 256 bits, and ICV
sizes of 64, 96 and 128 bits. 128-bit keys are MUST; the other sizes sizes of 64, 96 and 128 bits. 128-bit keys are MUST; the other sizes
are MAY. ICV sizes of 64 and 128 bit are MUST; 96 bits is MAY. The are MAY. ICV sizes of 64 and 128 bit are MUST; 96 bits is MAY. The
salt value is generated by IKEv2 during the key generation process. salt value is generated by IKE during the key generation process.
Reuse of the IV with the same key compromises the data's security; Reuse of the IV with the same key compromises the data's security;
thus, AES-CCM should not be used with manual keying. [RFC4309] thus, AES-CCM should not be used with manual keying. [RFC4309]
includes IANA values for use in ESP-v3. Each of the three ICV includes IANA values that IKE can use to negotiate ESP-v3 SAs. Each
lengths has its own IANA value, but IKEv2 negotiations need to of the three ICV lengths has its own IANA value, but IKE negotiations
specify the keysize. [RFC4309] includes test data. [RFC4309] need to specify the keysize. [RFC4309] includes test data.
describes how IKEv2 can negotiate the use of AES-CCM to use in an [RFC4309] describes how IKE can negotiate the use of AES-CCM to use
ESP-v3 SA. [RFC5282] extends this to the use of AES-CCM to protect in an ESP SA. [RFC5282] extends this to the use of AES-CCM to
an IKEv2 SA. protect an IKEv2 SA.
Requirements levels for AES-CCM: Requirements levels for AES-CCM:
IKEv1 - N/A IKEv1 - N/A
IKEv2 - optional IKEv2 - optional
ESP-v2 - N/A ESP-v2 - N/A
ESP-v3 - optional [RFC4835] ESP-v3 - optional [RFC4835]
NOTE: The IPsec-v2 IANA registry includes values for AES-CCM, but NOTE: The IPsec-v2 IANA registry includes values for AES-CCM, but
combined mode algorithms are not a feature of IPsec-v2. combined mode algorithms are not a feature of IPsec-v2.
5.4.2. RFC 4106, The Use of Galois/Counter Mode (GCM) in IPsec 5.4.2. RFC 4106, The Use of Galois/Counter Mode (GCM) in IPsec
Encapsulating Security Payload (ESP) (S, Jun. 2005) Encapsulating Security Payload (ESP) (S, Jun. 2005)
[RFC4106] describes how to use AES in Galois/Counter (GCM) mode, a [RFC4106] describes how to use AES in Galois/Counter (GCM) mode, a
combined alorithm, to encrypt and integrity-protect ESP-v3 traffic. combined alorithm, to encrypt and integrity-protect ESP traffic.
AES-GCM is a block-mode cipher with a 128-bit blocksize; a random IV AES-GCM is a block-mode cipher with a 128-bit blocksize; a random IV
that is sent in the packet along with the encrypted data; a 32-bit that is sent in the packet along with the encrypted data; a 32-bit
salt value (1/SA); keysizes of 128, 192 and 256 bits; and ICV sizes salt value (1/SA); keysizes of 128, 192 and 256 bits; and ICV sizes
of 64, 96 and 128 bits. 128-bit keys are MUST; the other sizes are of 64, 96 and 128 bits. 128-bit keys are MUST; the other sizes are
MAY. An ICV size of 128 bits is a MUST; 64 and 96 bits are MAY. The MAY. An ICV size of 128 bits is a MUST; 64 and 96 bits are MAY. The
salt value is generated by IKEv2 during the key generation process. salt value is generated by IKE during the key generation process.
Reuse of the IV with the same key compromises the data's security; Reuse of the IV with the same key compromises the data's security;
thus, AES-GCM should not be used with manual keying. [RFC4106] thus, AES-GCM should not be used with manual keying. [RFC4106]
includes IANA values for use in ESP-v3. Each of the three ICV includes IANA values that IKE can use to negotiate ESP-v3 SAs. Each
lengths has its own IANA value, but IKEv2 negotiations need to of the three ICV lengths has its own IANA value, but IKE negotiations
specify the keysize. [RFC4106] includes test data. [RFC4106] need to specify the keysize. [RFC4106] includes test data.
describes how IKEv2 can negotiate the use of AES-GCM to use in an [RFC4106] describes how IKE can negotiate the use of AES-GCM to use
ESP-v3 SA. [RFC5282] extends this to the use of AES-GCM to protect in an ESP SA. [RFC5282] extends this to the use of AES-GCM to
an IKEv2 SA. protect an IKEv2 SA.
Requirements levels for AES-GCM: Requirements levels for AES-GCM:
IKEv1 - N/A IKEv1 - N/A
IKEv2 - optional IKEv2 - optional
ESP-v2 - N/A ESP-v2 - N/A
ESP-v3 - optional [RFC4835] ESP-v3 - optional [RFC4835]
NOTE: The IPsec-v2 IANA registry includes values for AES-GCM, but NOTE: The IPsec-v2 IANA registry includes values for AES-GCM, but
combined mode algorithms are not a feature of IPsec-v2. combined mode algorithms are not a feature of IPsec-v2.
5.4.3. RFC 4543, The Use of Galois Message Authentication Code (GMAC) 5.4.3. RFC 4543, The Use of Galois Message Authentication Code (GMAC)
in IPsec ESP and AH (S, May 2006) in IPsec ESP and AH (S, May 2006)
[RFC4543] is the variant of AES-GCM [RFC4106] that provides [RFC4543] is the variant of AES-GCM [RFC4106] that provides
integrity-protection without encryption. It has two versions: an integrity-protection without encryption. It has two versions: an
integrity-protection algorithm for use within AH-v3, and a combined integrity-protection algorithm for use within AH, and a combined mode
mode algorithm with null encryption for use within ESP-v3. It can algorithm with null encryption for use within ESP. It can use a key
use a key of 128-, 192-, or 256-bits; the ICV is always 128 bits, and of 128-, 192-, or 256-bits; the ICV is always 128 bits, and is not
is not truncated. AES-GMAC uses a nonce, consisting of a 64-bit IV truncated. AES-GMAC uses a nonce, consisting of a 64-bit IV and a
and a 32-bit salt (1/SA). The salt value is generated by IKEv2 32-bit salt (1/SA). The salt value is generated by IKE during the
during the key generation process. Reuse of the salt value with the key generation process. Reuse of the salt value with the same key
same key compromises the data's security; thus, AES-GMAC should not compromises the data's security; thus, AES-GMAC should not be used
be used with manual keying. For use within AH-v3, each keysize has with manual keying. For use within AH, each keysize has its own IANA
its own IANA value, so IKEv2 does not have to negotiate the keysize. value, so IKE does not have to negotiate the keysize. For use within
For use within ESP-v3, there is only one IANA value, so IKEv2 ESP, there is only one IANA value, so IKE negotiations must specify
negotiations must specify the keysize. AES-GMAC cannot be used by the keysize. AES-GMAC cannot be used by IKE to protect its own SAs,
IKEv2 to protect its own SAs, since IKEv2 traffic requires since IKE traffic requires encryption.
encryption.
Requirements levels for AES-GMAC: Requirements levels for AES-GMAC:
IKEv1 - N/A IKEv1 - N/A
IKEv2 - N/A IKEv2 - N/A
IPsec-v2 - undefined (no IANA #) IPsec-v2 - undefined (no IANA #)
IPsec-v3 - optional IPsec-v3 - optional
5.4.4. RFC 5282, Using Authenticated Encryption Algorithms with the 5.4.4. RFC 5282, Using Authenticated Encryption Algorithms with the
Encrypted Payload of the Internet Key Exchange version 2 (IKEv2) Encrypted Payload of the Internet Key Exchange version 2 (IKEv2)
Protocol (S, Aug. 2008) Protocol (S, Aug. 2008)
[RFC5282] extends [RFC4309] and [RFC4106] to enable the use of [RFC5282] extends [RFC4309] and [RFC4106] to enable the use of
AES-CCM and AES-GCM to provide encryption and integrity-protection AES-CCM and AES-GCM to provide encryption and integrity-protection
for IKEv2 messages. for IKEv2 messages.
Requirements levels for RFC5282:
IKEv1 - N/A
IKEv2 - optional
5.5. Pseudo-Random Functions (PRFs) 5.5. Pseudo-Random Functions (PRFs)
IKE uses pseudo-random functions (PRFs) to generate the secret keys IKE uses pseudo-random functions (PRFs) to generate the secret keys
that are used in IKE SAs and IPsec SAs. These PRFs are generally the that are used in IKE SAs and IPsec SAs. These PRFs are generally the
same algorithms used for integrity-protection, but their output is same algorithms used for integrity-protection, but their output is
not truncated, since all of the generated bits are generally needed not truncated, since all of the generated bits are generally needed
for the keys. If the PRF's output is not long enough to supply the for the keys. If the PRF's output is not long enough to supply the
required number of bits of keying material, the PRF is applied required number of bits of keying material, the PRF is applied
iteratively until the requisite amount of keying material is iteratively until the requisite amount of keying material is
generated. generated.
skipping to change at page 35, line 26 skipping to change at page 32, line 42
combinations can pose a challenge to peers trying to find a common combinations can pose a challenge to peers trying to find a common
policy. To enhance interoperability, [RFC4308] defines two policy. To enhance interoperability, [RFC4308] defines two
pre-defined suites, consisting of combinations of algorithms that pre-defined suites, consisting of combinations of algorithms that
comprise typical security policies. IKE/ESP suite "VPN-A" includes comprise typical security policies. IKE/ESP suite "VPN-A" includes
use of 3DES, HMAC-SHA-1, and 1024-bit MODP Diffie-Hellman (DH); use of 3DES, HMAC-SHA-1, and 1024-bit MODP Diffie-Hellman (DH);
IKE/ESP suite "VPN-B" includes AES-CBC, AES-XCBC-MAC, and 2048-bit IKE/ESP suite "VPN-B" includes AES-CBC, AES-XCBC-MAC, and 2048-bit
MODP DH. These suites are intended to be named "single-button" MODP DH. These suites are intended to be named "single-button"
choices in the administrative interface, but do not prevent the use choices in the administrative interface, but do not prevent the use
of alternative combinations. of alternative combinations.
Requirements levels for RFC4308:
IKEv1 - optional
IKEv2 - optional
IPsec-v2 - optional
IPsec-v3 - optional
5.6.2. RFC 4869, Suite B Cryptographic Suites for IPsec (I, May 2007) 5.6.2. RFC 4869, Suite B Cryptographic Suites for IPsec (I, May 2007)
[RFC4869] adds 4 pre-defined suites, based upon the United States [RFC4869] adds 4 pre-defined suites, based upon the United States
National Security Agency's "Suite B" specifications, to those National Security Agency's "Suite B" specifications, to those
specified in [RFC4308]. IKE/ESP-v3 suites "Suite-B-GCM-128" and specified in [RFC4308]. IKE/ESP suites "Suite-B-GCM-128" and
"Suite-B-GCM-256" include use of AES-CBC, AES-GCM, HMAC-SHA-256 or "Suite-B-GCM-256" include use of AES-CBC, AES-GCM, HMAC-SHA-256 or
HMAC-SHA-384, and 256-bit or 384-bit elliptic curve (EC) DH groups. HMAC-SHA-384, and 256-bit or 384-bit elliptic curve (EC) DH groups.
IKE/AH-v3 suites "Suite-B-GMAC-128" and "Suite-B-GMAC-256" include IKE/AH suites "Suite-B-GMAC-128" and "Suite-B-GMAC-256" include use
use of AES-CBC, AES-GMAC, HMAC-SHA-256 or HMAC-SHA-384, and 256-bit of AES-CBC, AES-GMAC, HMAC-SHA-256 or HMAC-SHA-384, and 256-bit or
or 384-bit EC DH groups. While [RFC4308] does not specify a peer 384-bit EC DH groups. While [RFC4308] does not specify a peer
authentication method, [RFC4869] mandates pre-shared key authentication method, [RFC4869] mandates pre-shared key
authentication for IKEv1; public key authentication using ECDSA is authentication for IKEv1; public key authentication using ECDSA is
recommended for IKEv1 and required for IKEv2. recommended for IKEv1 and required for IKEv2.
Requirements levels for RFC4869:
IKEv1 - optional
IKEv2 - optional
ESP-v2 - N/A
ESP-v3 - optional
5.7. Diffie-Hellman Algorithms 5.7. Diffie-Hellman Algorithms
IKE negotiations include a Diffie-Hellman exchange, which establishes IKE negotiations include a Diffie-Hellman exchange, which establishes
a shared secret, to which both parties contributed. This value is a shared secret, to which both parties contributed. This value is
used to generate keying material to protect both the IKE SA and the used to generate keying material to protect both the IKE SA and the
IPsec SA. IPsec SA.
IKEv1 [RFC2409] contains definitions of 2 DH MODP groups and 2 IKEv1 [RFC2409] contains definitions of 2 DH MODP groups and 2
elliptic curve (EC) groups; IKEv2 [RFC4306] only references the MODP elliptic curve (EC) groups; IKEv2 [RFC4306] only references the MODP
groups. The requirements levels of these groups are: groups. The requirements levels of these groups are:
skipping to change at page 37, line 15 skipping to change at page 34, line 21
5.7.3. draft-solinas-rfc4753bis, ECP Groups for IKE and IKEv2 (I) 5.7.3. draft-solinas-rfc4753bis, ECP Groups for IKE and IKEv2 (I)
[ecp-ike1] obsoletes RFC4753, fixing an inconsistency in the DH [ecp-ike1] obsoletes RFC4753, fixing an inconsistency in the DH
shared secret value. shared secret value.
5.7.4. RFC 5114, Additional Diffie-Hellman Groups for Use with IETF 5.7.4. RFC 5114, Additional Diffie-Hellman Groups for Use with IETF
Standards (I, Jan. 2008) Standards (I, Jan. 2008)
[RFC5114] defines 5 additional DH groups (MODP groups 22-24 and EC [RFC5114] defines 5 additional DH groups (MODP groups 22-24 and EC
groups 25-26) for use in IKE. It also includes 3 EC DH groups groups 25-26) for use in IKE. It also includes 3 EC DH groups
(groups 19-21) that were previously defined in [RFC4753]. The IANA (groups 19-21) that were originally defined in [RFC4753]; however,
the current specification for these groups is [ecp-ike1]. The IANA
group numbers are specific to IKE, but the DH groups are intended for group numbers are specific to IKE, but the DH groups are intended for
use in multiple IETF protocols, including TLS/SSL, S/MIME, and X.509 use in multiple IETF protocols, including TLS/SSL, S/MIME, and X.509
Certificates. Certificates.
Requirements levels for DH MODP groups 22-24, EC groups 25-26: Requirements levels for DH MODP groups 22-24, EC groups 25-26:
IKEv1 - optional IKEv1 - optional
IKEv2 - optional IKEv2 - optional
6. IPsec/IKE for Multicast 6. IPsec/IKE for Multicast
skipping to change at page 40, line 24 skipping to change at page 37, line 31
Authentication (TESLA) in the Secure Real-time Transport Protocol Authentication (TESLA) in the Secure Real-time Transport Protocol
(SRTP) (S, Feb. 2006) (SRTP) (S, Feb. 2006)
[RFC4383] describes the use of TESLA within SRTP to protect multicast [RFC4383] describes the use of TESLA within SRTP to protect multicast
and broadcast traffic. and broadcast traffic.
7. Outgrowths of IPsec/IKE 7. Outgrowths of IPsec/IKE
Operational experience with IPsec revealed additional capabilities Operational experience with IPsec revealed additional capabilities
that could make IPsec more useful in real-world scenarios. These that could make IPsec more useful in real-world scenarios. These
include support for payload compression (IPComp), extensions to include support for IPsec policy mechanisms, IPsec MIBs, payload
facilitate additional peer authentication methods (BTNS, KINK and compression (IPComp), extensions to facilitate additional peer
IPSECKEY), and additional capabilities for VPN clients (MOBIKE and authentication methods (BTNS, KINK and IPSECKEY), and additional
IPSRA). capabilities for VPN clients (MOBIKE and IPSRA).
7.1. IPComp (Compression) 7.1. IPsec Policy
The IPsec Policy Working Group (ipsp) originally planned an RFC that
would allow entities with no common Trust Anchor and no prior
knowledge of each others' security policies to establish an
IPsec-protected connection. The solutions that were proposed for
gateway discovery and security policy negotiation proved to be overly
complex and fragile, in the absence of prior knowledge or compatible
configuration policies.
7.1.1. RFC 3586, IP Security Policy (IPSP) Requirements (S, Aug. 2003)
[RFC3586] describes the functional requirements of a generalized
IPsec policy framework, that could be used to discover, negotiate and
manage IPsec policies.
7.1.2. RFC 3585, IPsec Configuration Policy Information Model (S, Aug.
2003)
As stated in [RFC3585], "This document presents an object-oriented
information model of IP Security (IPsec) policy designed to
facilitate agreement about the content and semantics of IPsec policy,
and enable derivations of task-specific representations of IPsec
policy such as storage schema, distribution representations, and
policy specification languages used to configure IPsec-enabled
endpoints." This RFC has not been widely adopted.
7.2. IPsec MIBs
Over the years, several MIB-related Internet Drafts were proposed for
IPsec and IKE, but only one progressed to RFC status.
7.2.1. RFC 4807, IPsec Security Policy Database Configuration MIB (S,
Mar. 2007)
[RFC4807] defines a MIB module that can be used to configure the SPD
of an IPsec device. This RFC has not been widely adopted.
7.3. IPComp (Compression)
The IP Payload Compression Protocol (IPComp) is a protocol that The IP Payload Compression Protocol (IPComp) is a protocol that
provides lossless compression for IP datagrams. Although IKE can be provides lossless compression for IP datagrams. Although IKE can be
used to negotiate the use of IPComp in conjunction with IPsec, IPComp used to negotiate the use of IPComp in conjunction with IPsec, IPComp
can also be used when IPsec is not applied can also be used when IPsec is not applied.
7.1.1. RFC 3173, IP Payload Compression Protocol (IPComp) (S, Sep. The IPComp protocol allows the compression of IP datagrams by
supporting different compression algorithms. Three of these
algorithms are: DEFLATE [RFC2394], LZS [RFC2395], and the ITU-T V.44
Packet Method [RFC3051], which is based on the LZJH algorithm
7.3.1. RFC 3173, IP Payload Compression Protocol (IPComp) (S, Sep.
2001) 2001)
IP payload compression is especially useful when IPsec based IP payload compression is especially useful when IPsec based
encryption is applied to IP datagrams. Encrypting the IP datagram encryption is applied to IP datagrams. Encrypting the IP datagram
causes the data to be random in nature, rendering compression at causes the data to be random in nature, rendering compression at
lower protocol layers ineffective. If IKE is used to negotiate lower protocol layers ineffective. If IKE is used to negotiate
compression in conjunction with IPsec, compression can be performed compression in conjunction with IPsec, compression can be performed
prior to encryption. [RFC3173] defines the payload compression prior to encryption. [RFC3173] defines the payload compression
protocol, the IPComp packet structure, the IPComp Association (IPCA), protocol, the IPComp packet structure, the IPComp Association (IPCA),
and several methods to negotiate the IPCA. and several methods to negotiate the IPCA.
7.1.2. RFC 2394, IP Payload Compression Using DEFLATE (I, Dec. 1998) 7.4. IKEv2 Mobility and Multihoming (MOBIKE)
The IPComp protocol allows the compression of IP datagrams by
supporting different compression algorithms. [RFC2394] defines the
application of the DEFLATE algorithm as a compression method to
IPComp.
7.1.3. RFC 2395, IP Payload Compression Using LZS (I, Dec. 1998)
The IPComp protocol allows the compression of IP datagrams by
supporting different compression algorithms. [RFC2395] defines the
application of the LZS algorithm as a compression method to IPComp.
7.2. IKEv2 Mobility and Multihoming (MOBIKE)
The IKEv2 Mobility and Multihoming (MOBIKE) protocol enables two The IKEv2 Mobility and Multihoming (MOBIKE) protocol enables two
additional capabilities for IPsec VPN users: 1) moving from one additional capabilities for IPsec VPN users: 1) moving from one
address to another without re-establishing existing SAs and 2) using address to another without re-establishing existing SAs and 2) using
multiple interfaces simultaneously. These solutions are limited to multiple interfaces simultaneously. These solutions are limited to
IPsec VPNs; they are not intended to provide more general mobility or IPsec VPNs; they are not intended to provide more general mobility or
multi-homing capabilities. multi-homing capabilities.
7.2.1. RFC 4621, Design of the IKEv2 Mobility and Multihoming (MOBIKE) 7.4.1. RFC 4555, IKEv2 Mobility and Multihoming Protocol (MOBIKE) (S,
Protocol (I, Aug. 2006)
[RFC4621] discusses the involved network entities and the
relationship between IKEv2 signaling and information provided by
other protocols. It also records design decisions for the MOBIKE
protocol, background information, and records discussions within the
working group.
7.2.2. RFC 4555, IKEv2 Mobility and Multihoming Protocol (MOBIKE) (S,
Jun. 2006) Jun. 2006)
IKEv2 assumes that an IKE SA is created implicitly between the IP IKEv2 assumes that an IKE SA is created implicitly between the IP
address pair that is used during the protocol execution when address pair that is used during the protocol execution when
establishing the IKEv2 SA. IPsec related documents had no provision establishing the IKEv2 SA. IPsec related documents had no provision
to change this pair after an IKE SA was created. [RFC4555] defines to change this pair after an IKE SA was created. [RFC4555] defines
extensions to IKEv2 that enable an efficient management of IKE and extensions to IKEv2 that enable an efficient management of IKE and
IPsec Security Associations when a host possesses multiple IP IPsec Security Associations when a host possesses multiple IP
addresses and/or where IP addresses of an IPsec host change over addresses and/or where IP addresses of an IPsec host change over
time. time.
7.2.3. RFC 5266, Secure Connectivity and Mobility Using Mobile IPv4 and 7.4.2. RFC 4621, Design of the IKEv2 Mobility and Multihoming (MOBIKE)
Protocol (I, Aug. 2006)
[RFC4621] discusses the involved network entities and the
relationship between IKEv2 signaling and information provided by
other protocols. It also records design decisions for the MOBIKE
protocol, background information, and records discussions within the
working group.
7.4.3. RFC 5266, Secure Connectivity and Mobility Using Mobile IPv4 and
IKEv2 Mobility and Multihoming (MOBIKE) (B, Jun. 2008) IKEv2 Mobility and Multihoming (MOBIKE) (B, Jun. 2008)
[RFC5266] describes a solution using Mobile IPv4 (MIPv4) and mobility [RFC5266] describes a solution using Mobile IPv4 (MIPv4) and mobility
extensions to IKEv2 (MOBIKE) to provide secure connectivity and extensions to IKEv2 (MOBIKE) to provide secure connectivity and
mobility to enterprise users when they roam into untrusted networks. mobility to enterprise users when they roam into untrusted networks.
7.3. Better-than-Nothing Security (BTNS) 7.5. Better-than-Nothing Security (BTNS)
One of the major obstacles to widespread implementation of IPsec is One of the major obstacles to widespread implementation of IPsec is
the lack of pre-existing credentials that can be used for peer the lack of pre-existing credentials that can be used for peer
authentication. Better-than-Nothing Security (BTNS) is an attempt to authentication. Better-than-Nothing Security (BTNS) is an attempt to
sidestep this problem by allowing IKE to negotiate unauthenticated sidestep this problem by allowing IKE to negotiate unauthenticated
(anonymous) IPsec SAs, using credentials such as self-signed (anonymous) IPsec SAs, using credentials such as self-signed
certificates or "bare" public keys (public keys that are not certificates or "bare" public keys (public keys that are not
connected to a Public Key Certificate) for peer authentication. This connected to a Public Key Certificate) for peer authentication. This
ensures that subsequent traffic protected by the SA is conducted with ensures that subsequent traffic protected by the SA is conducted with
the same peer, and protects the communications from passive attack. the same peer, and protects the communications from passive attack.
These SAs can then be cryptographically bound to a higher-level These SAs can then be cryptographically bound to a higher-level
application protocol, which performs its own peer authentication. application protocol, which performs its own peer authentication.
7.3.1. RFC 5660, IPsec Channels: Connection Latching (S, Oct. 2009) 7.5.1. RFC 5660, IPsec Channels: Connection Latching (S, Oct. 2009)
[RFC5660] specifies, abstractly, how to interface applications and [RFC5660] specifies, abstractly, how to interface applications and
transport protocols with IPsec so as to create channels by latching transport protocols with IPsec so as to create channels by latching
connections (packet flows) to certain IPsec Security Association (SA) connections (packet flows) to certain IPsec Security Association (SA)
parameters for the lifetime of the connections. Connection latching parameters for the lifetime of the connections. Connection latching
is layered on top of IPsec and does not modify the underlying IPsec is layered on top of IPsec and does not modify the underlying IPsec
architecture. architecture.
7.3.2. RFC 5386, Better-Than-Nothing-Security: An Unauthenticated Mode 7.5.2. RFC 5386, Better-Than-Nothing-Security: An Unauthenticated Mode
of IPsec (S, Nov. 2008) of IPsec (S, Nov. 2008)
[RFC5386] specifies how to use IKEv2 to setup unauthenticated [RFC5386] specifies how to use IKEv2 to setup unauthenticated
security associations (SAs) for use with the IPsec Encapsulating security associations (SAs) for use with the IPsec Encapsulating
Security Payload (ESP) and the IPsec Authentication Header (AH). Security Payload (ESP) and the IPsec Authentication Header (AH).
This document does not require any changes to the bits on the wire, This document does not require any changes to the bits on the wire,
but specifies extensions to the Peer Authorization Database (PAD) and but specifies extensions to the Peer Authorization Database (PAD) and
Security Policy Database (SPD). Security Policy Database (SPD).
7.3.3. RFC 5387, Problem and Applicability Statement for 7.5.3. RFC 5387, Problem and Applicability Statement for
Better-Than-Nothing Security (BTNS) (I, Nov. 2008) Better-Than-Nothing Security (BTNS) (I, Nov. 2008)
[RFC5387] considers that the need to deploy authentication [RFC5387] considers that the need to deploy authentication
information and its associated identities is a significant obstacle information and its associated identities is a significant obstacle
to the use of IPsec. This document explains the rationale for to the use of IPsec. This document explains the rationale for
extending the Internet network security protocol suite to enable use extending the Internet network security protocol suite to enable use
of IPsec security services without authentication. of IPsec security services without authentication.
7.4. Kerberized Internet Negotiation of Keys (KINK) 7.6. Kerberized Internet Negotiation of Keys (KINK)
Kerberized Internet Negotiation of Keys (KINK) is an attempt to Kerberized Internet Negotiation of Keys (KINK) is an attempt to
provide an alternative to IKE for IPsec peer authentication. It uses provide an alternative to IKE for IPsec peer authentication. It uses
Kerberos, instead of IKE, to establish IPsec SAs. For enterprises Kerberos, instead of IKE, to establish IPsec SAs. For enterprises
that already deploy the Kerberos centralized key management system, that already deploy the Kerberos centralized key management system,
IPsec can then be implemented without the need for additional peer IPsec can then be implemented without the need for additional peer
credentials. credentials. Some vendors have implemented proprietary extensions
for using Kerberos in IKEv1, as an alternative to the use of KINK.
7.4.1. RFC 3129, Requirements for Kerberized Internet Negotiation of 7.6.1. RFC 3129, Requirements for Kerberized Internet Negotiation of
Keys (I, Jun. 2001) Keys (I, Jun. 2001)
[RFC3129] considers that peer to peer authentication and keying [RFC3129] considers that peer to peer authentication and keying
mechanisms have inherent drawbacks such as computational complexity mechanisms have inherent drawbacks such as computational complexity
and difficulty in enforcing security policies. This document and difficulty in enforcing security policies. This document
specifies the requirements for using basic features of Kerberos and specifies the requirements for using basic features of Kerberos and
uses them to its advantage to create a protocol which can establish uses them to its advantage to create a protocol which can establish
and maintain IPsec security associations ([RFC2401]). and maintain IPsec security associations ([RFC2401]).
7.4.2. RFC 4430, Kerberized Internet Negotiation of Keys (KINK) (S, 7.6.2. RFC 4430, Kerberized Internet Negotiation of Keys (KINK) (S,
Mar. 2006) Mar. 2006)
[RFC4430] defines a low-latency, computationally inexpensive, easily [RFC4430] defines a low-latency, computationally inexpensive, easily
managed, and cryptographically sound protocol to establish and managed, and cryptographically sound protocol to establish and
maintain security associations using the Kerberos authentication maintain security associations using the Kerberos authentication
system. This document reuses the Quick Mode payloads of IKEv1 in system. This document reuses the Quick Mode payloads of IKEv1 in
order to foster substantial reuse of IKEv1 implementations. This RFC order to foster substantial reuse of IKEv1 implementations. This RFC
has not been widely adopted. has not been widely adopted.
7.5. IPsec Secure Remote Access (IPSRA) 7.7. IPsec Secure Remote Access (IPSRA)
IPsec Secure Remote Access (IPSRA) was an attempt to extend IPsec IPsec Secure Remote Access (IPSRA) was an attempt to extend IPsec
protection to "road warriors," allowing IKE to authenticate not only protection to "road warriors," allowing IKE to authenticate not only
the user's device but also the user, without changing IKEv1. The the user's device but also the user, without changing IKEv1. The
working group defined generic requirements of different IPsec remote working group defined generic requirements of different IPsec remote
access scenarios. An attempt was made to define an IKE-like protocol access scenarios. An attempt was made to define an IKE-like protocol
that would use legacy authentication mechanisms to create a temporary that would use legacy authentication mechanisms to create a temporary
or short-lived user credential that could be used for peer or short-lived user credential that could be used for peer
authentication within IKE. This protocol proved to be more authentication within IKE. This protocol proved to be more
cumbersome than standard Public Key protocols, and was abandoned. cumbersome than standard Public Key protocols, and was abandoned.
This led to the development of IKEv2, which incorporates the use of This led to the development of IKEv2, which incorporates the use of
EAP for user authentication. EAP for user authentication.
7.5.1. RFC 3457, Requirements for IPsec Remote Access Scenarios (I, 7.7.1. RFC 3457, Requirements for IPsec Remote Access Scenarios (I,
Jan. 2003) Jan. 2003)
[RFC3457] explores and enumerates the requirements of various IPsec [RFC3457] explores and enumerates the requirements of various IPsec
remote access scenarios, without suggesting particular solutions for remote access scenarios, without suggesting particular solutions for
them. them.
7.5.2. RFC 3456, Dynamic Host Configuration Protocol (DHCPv4) 7.7.2. RFC 3456, Dynamic Host Configuration Protocol (DHCPv4)
Configuration of IPsec Tunnel Mode (S, Jan. 2003) Configuration of IPsec Tunnel Mode (S, Jan. 2003)
[RFC3456] explores the requirements for host configuration in IPsec [RFC3456] explores the requirements for host configuration in IPsec
tunnel mode, and describes how the Dynamic Host Configuration tunnel mode, and describes how the Dynamic Host Configuration
Protocol (DHCPv4) may be used for providing such configuration Protocol (DHCPv4) may be used for providing such configuration
information. This RFC has not been widely adopted. information. This RFC has not been widely adopted.
7.6. IPsec Keying Information Resource Record (IPSECKEY) 7.8. IPsec Keying Information Resource Record (IPSECKEY)
The IPsec Keying Information Resource Record (IPSECKEY) enables the The IPsec Keying Information Resource Record (IPSECKEY) enables the
storage of public keys and other information that can be used to storage of public keys and other information that can be used to
facilitate opportunistic IPsec in a new type of DNS resource record. facilitate opportunistic IPsec in a new type of DNS resource record.
7.6.1. RFC 4025, A method for storing IPsec keying material in DNS (S, 7.8.1. RFC 4025, A method for storing IPsec keying material in DNS (S,
Feb. 2005) Feb. 2005)
[RFC4025] describes a method of storing IPsec keying material in the [RFC4025] describes a method of storing IPsec keying material in the
DNS using a new type of resource record. This document describes how DNS using a new type of resource record. This document describes how
to store the public key of the target node in this resource record. to store the public key of the target node in this resource record.
This RFC has not been widely adopted. This RFC has not been widely adopted.
8. Other Protocols that use IPsec/IKE 8. Other Protocols that use IPsec/IKE
IPsec and IKE were designed to provide IP-layer security protection IPsec and IKE were designed to provide IP-layer security protection
skipping to change at page 45, line 12 skipping to change at page 42, line 49
[RFC5265] describes a basic solution that uses Mobile IPv4 and IPsec [RFC5265] describes a basic solution that uses Mobile IPv4 and IPsec
to provide session mobility between enterprise intranets and external to provide session mobility between enterprise intranets and external
networks. The proposed solution minimizes changes to existing networks. The proposed solution minimizes changes to existing
firewall/VPN/DMZ deployments and does not require any changes to firewall/VPN/DMZ deployments and does not require any changes to
IPsec or key exchange protocols. It also proposes a mechanism to IPsec or key exchange protocols. It also proposes a mechanism to
minimize IPsec renegotiation when the mobile node moves. minimize IPsec renegotiation when the mobile node moves.
8.1.3. RFC 3776, Using IPsec to Protect Mobile IPv6 Signaling Between 8.1.3. RFC 3776, Using IPsec to Protect Mobile IPv6 Signaling Between
Mobile Nodes and Home Agents (S, Jun. 2004) Mobile Nodes and Home Agents (S, Jun. 2004)
This document illustrates the use of IPsec in securing Mobile IPv6 This document specifies the use of IPsec in securing Mobile IPv6
traffic between mobile nodes and home agents. It specifies the traffic between mobile nodes and home agents. It specifies the
required wire formats for the protected packets and illustrates required wire formats for the protected packets and illustrates
examples of Security Policy Database and Security Association examples of Security Policy Database and Security Association
Database entries that can be used to protect Mobile IPv6 signaling Database entries that can be used to protect Mobile IPv6 signaling
messages. It also describes how to configure either manually keyed messages. It also describes how to configure either manually keyed
IPsec security associations or how to configure IKEv1 to establish IPsec security associations or how to configure IKEv1 to establish
the SAs automatically. the SAs automatically. Mobile IPv6 requires considering the Home
Address destination option and Routing Header in IPsec processing.
Also, IPsec and IKE security association addresses can be updated by
Mobile IPv6 signaling messages.
8.1.4. RFC 4877, Mobile IPv6 Operation with IKEv2 and the Revised IPsec 8.1.4. RFC 4877, Mobile IPv6 Operation with IKEv2 and the Revised IPsec
Architecture (S, Apr. 2007) Architecture (S, Apr. 2007)
This document updates [RFC3776] in order to work with the revised This document updates [RFC3776] in order to work with the revised
IPsec architecture [RFC4301]. Since the revised IPsec architecture IPsec architecture [RFC4301]. Since the revised IPsec architecture
expands the list of selectors to include the Mobility Header message expands the list of selectors to include the Mobility Header message
type, it becomes much easier to differentiate between different type, it becomes much easier to differentiate between different
mobility header messages. Since the ICMP message type and code are mobility header messages. Since the ICMP message type and code are
also newly added as selectors, this document uses them to protect also newly added as selectors, this document uses them to protect
Mobile Prefix Discovery messages. Finally, this document describes Mobile Prefix Discovery messages. This document also specifies the
the use of IKEv2 in order to set up the SAs for Mobile IPv6. use of IKEv2 configuration payloads for dynamic home address
configuration. Finally, this document describes the use of IKEv2 in
order to set up the SAs for Mobile IPv6.
8.1.5. RFC 5213, Proxy Mobile IPv6 (S, Aug. 2008) 8.1.5. RFC 5026, Mobile IPv6 Bootstrapping in Split Scenario (S, Oct.
2007)
[RFC5026] extends [RFC4877] to support dynamic discovery of home
agents and the home network prefix; for the latter purpose, it
specifies a new IKEv2 configuration attribute and notification. It
describes how a Mobile IPv6 node can obtain the address of its Home
Agent, its Home address, and create IPsec security associations with
its Home Agent using DNS lookups and security credentials
pre-configured on the Mobile Node. It defines how a MN can request
its home address and home prefixes through the Configuration Payload
in the IKE_AUTH exchange and what attributes need to be present in
the CFG_REQUEST messages in order for doing so. It also specifies
how the home agent can authorize the credentials used for IKEv2
exchange.
8.1.6. RFC 5213, Proxy Mobile IPv6 (S, Aug. 2008)
[RFC5213] describes a network-based mobility management protocol that [RFC5213] describes a network-based mobility management protocol that
is used to provide mobility services hosts without requiring their is used to provide mobility services hosts without requiring their
participation in any mobility-related signaling. It uses IPsec to participation in any mobility-related signaling. It uses IPsec to
protect the mobility signaling messages between the two network protect the mobility signaling messages between the two network
entities called the mobile access gateway (MAG) and the local entities called the mobile access gateway (MAG) and the local
mobility anchor (LMA). It also uses IKEv2 in order to set up the mobility anchor (LMA). It also uses IKEv2 in order to set up the
security associations between the MAG and the LMA. security associations between the MAG and the LMA.
8.1.6. RFC 5268, Mobile IPv6 Fast Handovers (S, Jun. 2008) 8.1.7. RFC 5268, Mobile IPv6 Fast Handovers (S, Jun. 2008)
When Mobile IPv6 is used for a handover, there is a period during When Mobile IPv6 is used for a handover, there is a period during
which the Mobile Node is unable to send or receive packets because of which the Mobile Node is unable to send or receive packets because of
link switching delay and IP protocol operations. [RFC5268] specifies link switching delay and IP protocol operations. [RFC5268] specifies
a protocol between the Previous Access Router (PAR) and the New a protocol between the Previous Access Router (PAR) and the New
Access Router (NAR) to improve handover latency due to Mobile IPv6 Access Router (NAR) to improve handover latency due to Mobile IPv6
procedures. It uses IPsec ESP in transport mode with integrity procedures. It uses IPsec ESP in transport mode with integrity
protection for protecting the signaling messages between the PAR and protection for protecting the signaling messages between the PAR and
the NAR. It also describes the SPD entries and the PAD entries when the NAR. It also describes the SPD entries and the PAD entries when
IKEv2 is used for setting up the required SAs. IKEv2 is used for setting up the required SAs.
8.1.7. RFC 5380, Hierarchical Mobile IPv6 (HMIPv6) Mobility Management 8.1.8. RFC 5380, Hierarchical Mobile IPv6 (HMIPv6) Mobility Management
(S, Oct. 2008) (S, Oct. 2008)
[RFC5380] describes extensions to Mobile IPv6 and IPv6 Neighbour [RFC5380] describes extensions to Mobile IPv6 and IPv6 Neighbour
Discovery to allow for local mobility handling in order to reduce the Discovery to allow for local mobility handling in order to reduce the
amount of signalling between the mobile node, its correspondent amount of signalling between the mobile node, its correspondent
nodes, and its home agent. It also improves handover speed of Mobile nodes, and its home agent. It also improves handover speed of Mobile
IPv6. It uses IPsec for protecting the signaling between the mobile IPv6. It uses IPsec for protecting the signaling between the mobile
node and a local mobility management entity called the Mobility node and a local mobility management entity called the Mobility
Anchor Point (MAP). The MAP also uses IPsec Peer Authorization Anchor Point (MAP). The MAP also uses IPsec Peer Authorization
Database (PAD) entries and configuration payloads described in Database (PAD) entries and configuration payloads described in
skipping to change at page 47, line 46 skipping to change at page 46, line 6
[RFC5207] discusses the problems associated with HIP communication [RFC5207] discusses the problems associated with HIP communication
across network paths that include network address translators and across network paths that include network address translators and
firewalls. It analyzes the impact of NATs and firewalls on the HIP firewalls. It analyzes the impact of NATs and firewalls on the HIP
base exchange and the ESP data exchange. It discusses possible base exchange and the ESP data exchange. It discusses possible
changes to HIP that attempt to improve NAT and firewall traversal and changes to HIP that attempt to improve NAT and firewall traversal and
proposes a rendezvous point for letting HIP nodes behind a NAT be proposes a rendezvous point for letting HIP nodes behind a NAT be
reachable. It also suggests mechanisms for NATs to be more aware of reachable. It also suggests mechanisms for NATs to be more aware of
the HIP messages. the HIP messages.
8.4. Extensible Authentication Protocol (EAP) Method Update (EMU) 8.4. Extensible Authentication Protocol (EAP)
8.4.1. RFC 5106, The Extensible Authentication Protocol-Internet Key 8.4.1. RFC 5106, The Extensible Authentication Protocol-Internet Key
Exchange Protocol version 2 (EAP-IKEv2) Method (E, Feb. 2008) Exchange Protocol version 2 (EAP-IKEv2) Method (E, Feb. 2008)
[RFC5106] specifies an Extensible Authentication Protocol (EAP) [RFC5106] specifies an Extensible Authentication Protocol (EAP)
method that is based on the Internet Key Exchange (IKEv2) protocol. method that is based on the Internet Key Exchange (IKEv2) protocol.
EAP-IKEv2 provides mutual authentication and session key EAP-IKEv2 provides mutual authentication and session key
establishment between an EAP peer and an EAP server. It describes establishment between an EAP peer and an EAP server. It describes
the full EAP-IKEv2 message exchange and the composition of the the full EAP-IKEv2 message exchange and the composition of the
protocol messages. protocol messages.
skipping to change at page 49, line 10 skipping to change at page 47, line 18
to four protocols, including ESP. to four protocols, including ESP.
8.7.2. RFC 5225, RObust Header Compression Version 2 (ROHCv2): Profiles 8.7.2. RFC 5225, RObust Header Compression Version 2 (ROHCv2): Profiles
for RTP, UDP, IP, ESP, and UDP-Lite (S, April 2008) for RTP, UDP, IP, ESP, and UDP-Lite (S, April 2008)
[RFC5225] defines an updated ESP/IP profile for use with ROHC version [RFC5225] defines an updated ESP/IP profile for use with ROHC version
2. It analyzes the ESP header and classifies the fields into several 2. It analyzes the ESP header and classifies the fields into several
classes like static, well-known, irregular etc. in order to classes like static, well-known, irregular etc. in order to
efficiently compress the headers. efficiently compress the headers.
8.7.3. draft-ietf-rohc-hcoipsec, Integration of Robust Header 8.7.3. RFC 5856, Integration of Robust Header Compression over IPsec
Compression (ROHC) over IPsec Security Associations (I) Security Associations (I, May 2010)
[rohc-1] describes a mechanism to compress inner IP headers at the [RFC5856] describes a mechanism to compress inner IP headers at the
ingress point of IPsec tunnels and to decompress them at the egress ingress point of IPsec tunnels and to decompress them at the egress
point. Since the ROHC specifications only describe operations on a point. Since the Robust Header Compression (ROHC) specifications
per-hop basis, this document also specifies extensions to enable ROHC only describe operations on a per-hop basis, this document also
over multiple hops. This document applies only to tunnel mode SAs specifies extensions to enable ROHC over multiple hops. This
and does not support transport mode SAs. document applies only to tunnel mode SAs and does not support
transport mode SAs.
8.7.4. draft-ietf-rohc-ikev2-extensions-hcoipsec, IKEv2 Extensions to 8.7.4. RFC 5857, IKEv2 Extensions to Support Robust Header Compression
Support Robust Header Compression over IPsec (ROHCoIPsec) (S) over IPsec (S, May 2010)
ROHC requires initial configuration at the compressor and ROHC requires initial configuration at the compressor and
decompressor ends. Since ROHC usually operates on a per-hop basis decompressor ends. Since ROHC usually operates on a per-hop basis
this configuration information is carried over link-layer protocols this configuration information is carried over link-layer protocols
such as PPP. Since [rohc-1] operates over multiple hops a different such as PPP. Since [RFC5856] operates over multiple hops a different
signaling mechanism is required. [rohc-2] describes how to use IKEv2 signaling mechanism is required. [RFC5857] describes how to use
in order to dynamically communicate the configuration parameters IKEv2 in order to dynamically communicate the configuration
between the compressor and decompressor. parameters between the compressor and decompressor.
8.7.5. draft-ietf-rohc-ipsec-extensions-hcoipsec, IPsec Extensions to 8.7.5. RFC 5858, IPsec Extensions to Support Robust Header Compression
Support Robust Header Compression over IPsec (ROHCoIPsec) (S) over IPsec (S, May 2010)
[rohc-1] describes how to use ROHC with IPsec. This is not possible [RFC5856] describes how to use ROHC with IPsec. This is not possible
without extensions to IPsec. [rohc-3] describes the extensions without extensions to IPsec. [RFC5858] describes the extensions
needed to IPsec in order to support ROHC. Specifically, it describes needed to IPsec in order to support ROHC. Specifically, it describes
extensions needed to the IPsec SPD, SAD and to the IPsec processing extensions needed to the IPsec SPD, SAD and to the IPsec processing
including ICV computation and integrity verification. including ICV computation and integrity verification.
8.8. Border Gateway Protocol (BGP) 8.8. Border Gateway Protocol (BGP)
8.8.1. RFC 5566, BGP IPsec Tunnel Encapsulation Attribute (S, June 8.8.1. RFC 5566, BGP IPsec Tunnel Encapsulation Attribute (S, Jun.
2009) 2009)
[RFC5566] adds an additional BGP Encapsulation Subsequent Address [RFC5566] adds an additional BGP Encapsulation Subsequent Address
Family Identifier (SAFI), allowing the use of IPsec and, optionally, Family Identifier (SAFI), allowing the use of IPsec and, optionally,
of IKE to protect BGP tunnels. It defines the use of AH and ESP in of IKE to protect BGP tunnels. It defines the use of AH and ESP in
tunnel mode, and the use of AH and ESP in transport mode to protect tunnel mode, and the use of AH and ESP in transport mode to protect
IP in IP and MPLS-in-IP tunnels. IP in IP and MPLS-in-IP tunnels. It also defines how public key
fingerprints (hashes) are distributed via BGP, and used later to
authenticate IKEv2 exchange between the tunnel endpoints.
8.9. IPsec Benchmarking
8.9. IPsec benchmarking
8.9.1. draft-ietf-bmwg-ipsec-meth, Methodology for Benchmarking IPsec 8.9.1. draft-ietf-bmwg-ipsec-meth, Methodology for Benchmarking IPsec
Devices (S) Devices (S)
[bmwg-1] defines a set of tests that can be used to measure and [bmwg-1] defines a set of tests that can be used to measure and
report the performance characteristics of IPsec devices. It extends report the performance characteristics of IPsec devices. It extends
the methodology defined for benchmarking network interconnecting the methodology defined for benchmarking network interconnecting
devices to include IPsec gateways and adds further tests which can be devices to include IPsec gateways and adds further tests which can be
used to measure IPsec performance of end-hosts. The document used to measure IPsec performance of end-hosts. The document
focusses on establishing a performance testing methodology for IPsec focusses on establishing a performance testing methodology for IPsec
devices that support manual keying and IKEv1, but does not cover devices that support manual keying and IKEv1, but does not cover
IKEv2. IKEv2.
8.9.2. draft-ietf-bmwg-ipsec-term, Terminology for Benchmarking IPsec 8.9.2. draft-ietf-bmwg-ipsec-term, Terminology for Benchmarking IPsec
Devices (I) Devices (I)
[bmwg-2] is defines the standardized performance testing terminology [bmwg-2] is defines the standardized performance testing terminology
for IPsec devices that support manual keying and IKEv1. It also for IPsec devices that support manual keying and IKEv1. It also
describes the benchmark tests that would be used to test the describes the benchmark tests that would be used to test the
performance of the IPsec devices. performance of the IPsec devices.
8.10. Network Address Translators (NAT)
8.10.1. RFC 2709, Security Model with Tunnel-mode IPsec for NAT domains
(I, Oct. 1999)
NAT devices provide transparent routing to end hosts trying to
communicate from disparate address realms, by modifying IP and
transport headers en-route. This makes it difficult for applications
to pursue end-to-end application level security. [RFC2709] describes
a security model by which tunnel-mode IPsec security can be
architected on NAT devices. It defines how NATs administer security
policies and SA attributes based on private realm addressing. It
also specifies how to operate IKE in such scenarios by specifying an
IKE-ALG (Application Level Gateway) that translates policies from
private realm addressing into public addressing.
8.11. Session Initiation Protocol (SIP)
8.11.1. RFC 3329, Security Mechanism Agreement for the Session
Initiation Protocol (SIP) (S, Jan. 2003)
[RFC3329] describes how a SIP client can select one of the various
available SIP security mechanisms. In particular, the method allows
secure negotiation to prevent bidding down attacks. It also
describes a security mechanism called ipsec-3gpp and its associated
parameters (algorithms, protocols, mode, SPIs and ports) as they are
used in the 3GPP IP Multimedia Subsystem.
8.12. Wireless Security
8.12.1. RFC 4705, GigaBeam High-Speed Radio Link Encryption (I, Oct.
2006)
[RFC4705] describes the encryption and key management used by
GigaBeam as part of the WiFiber(tm) family of radio link products and
is intended to serve as a guideline for similar wireless product
development efforts to include comparable capabilities. It specifies
the algorithms that are used to provide confidentiality and integrity
protection of both subscriber and management traffic. It also
specifies a custom security protocol that runs between two Gigabeam
Radio Control Modules (RCMs).
9. Acknowledgements 9. Acknowledgements
The authors would like to thank Yaron Sheffer, Paul Hoffman, Yoav The authors would like to thank Yaron Sheffer, Paul Hoffman, Yoav
Nir, Rajeshwar Singh Jenwar, Alfred Hoenes, Al Morton, Gabriel Nir, Rajeshwar Singh Jenwar, Alfred Hoenes, Al Morton, Gabriel
Montenegro, Sean Turner, Julien Laganier, Grey Daley and Scott Moonen Montenegro, Sean Turner, Julien Laganier, Grey Daley and Scott Moonen
for reviewing this document and suggesting changes. for reviewing this document and suggesting changes.
10. Security Considerations 10. Security Considerations
There are no security considerations relevant to this document. There are no security considerations relevant to this document.
skipping to change at page 51, line 20 skipping to change at page 50, line 26
Benchmarking IPsec Devices", draft-ietf-bmwg-ipsec-term, Benchmarking IPsec Devices", draft-ietf-bmwg-ipsec-term,
Work in Progress. Work in Progress.
[ecp-ike1] Fu, D. and J. Solinas, "ECP Groups for IKE and IKEv2", [ecp-ike1] Fu, D. and J. Solinas, "ECP Groups for IKE and IKEv2",
draft-solinas-rfc4753bis, Work in Progress. draft-solinas-rfc4753bis, Work in Progress.
[ipsecme-1] Kaufman, C., P. Hoffman, Y. Nir and P. Eronen, "Internet [ipsecme-1] Kaufman, C., P. Hoffman, Y. Nir and P. Eronen, "Internet
Key Exchange Protocol: IKEv2", Key Exchange Protocol: IKEv2",
draft-ietf-ipsecme-ikev2bis, Work in Progress. draft-ietf-ipsecme-ikev2bis, Work in Progress.
[ipsecme-2] Eronen, P., J. Laganier and C. Madson, [ipsecme-2] Shen, S., Y. Mao and N.S.S. Murthy,
draft-ietf-ipsecme-ikev2-ipv6-config, "IPv6 Configuration
in IKEv2", Work in Progress.
[ipsecme-3] Grewal, K. and G. Montenegro,
draft-ietf-ipsecme-traffic-visibility, "Wrapped ESP for
Traffic Visibility", Work in Progress.
[ipsecme-4] Kivinen, T. and D. McDonald,
draft-ietf-ipsecme-esp-null-heuristics, "Heuristics for
Detecting ESP-NULL packets", Work in Progress.
[ipsecme-5] Shen, S., Y. Mao and N.S.S. Murthy,
draft-ietf-ipsecme-aes-ctr-ikev2, "Using Advanced draft-ietf-ipsecme-aes-ctr-ikev2, "Using Advanced
Encryption Standard (AES) Counter Mode with IKEv2", Work Encryption Standard (AES) Counter Mode with IKEv2", Work
in Progress. in Progress.
[rohc-1] Ertekin, E., R. Jasani, C. Christou and C. Bormann, [ipsecme-3] Eronen, P., H. Tschofenig and Y. Sheffer,
"Integration of Robust Header Compression (ROHC) over draft-ietf-ipsecme-eap-mutual, "An Extension for EAP-Only
IPsec Security Associations", draft-ietf-rohc-hcoipsec, Authentication in IKEv2", Work in Progress.
Work in Progress.
[rohc-2] Ertekin, E., C. Christou, R. Jasani, T. Kivinen and C. [ipsecme-4] Nir, Y., draft-ietf-ipsecme-ipsec-ha, "IPsec High
Bormann, "IKEv2 Extensions to Support Robust Header Availability and Load Sharing Problem Statement", Work in
Compression over IPsec (ROHCoIPsec)",
draft-ietf-rohc-ikev2-extensions-hcoipsec, Work in
Progress. Progress.
[rohc-3] Ertekin, E., C. Christou and C. Bormann, "IPsec Extensions
to Support Robust Header Compression over IPsec
(ROHCoIPsec)", draft-ietf-rohc-ipsec-extensions-hcoipsec,
Work in Progress.
[RFC2394] Pereira, R., "IP Payload Compression Using DEFLATE", RFC [RFC2394] Pereira, R., "IP Payload Compression Using DEFLATE", RFC
2394, December 1998. 2394, December 1998.
[RFC2395] Friend, R. and R. Monsour, "IP Payload Compression Using [RFC2395] Friend, R. and R. Monsour, "IP Payload Compression Using
LZS", RFC 2395, December 1998. LZS", RFC 2395, December 1998.
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998 (obsolete). Internet Protocol", RFC 2401, November 1998 (obsolete).
[RFC2402] Kent, S. and R. Atkinson, "IP Authentication Header", RFC [RFC2402] Kent, S. and R. Atkinson, "IP Authentication Header", RFC
skipping to change at page 52, line 52 skipping to change at page 51, line 37
[RFC2411] Thayer, R., N. Doraswamy and R. Glenn, "IP Security [RFC2411] Thayer, R., N. Doraswamy and R. Glenn, "IP Security
Document Roadmap", RFC 2411, November 1998. Document Roadmap", RFC 2411, November 1998.
[RFC2412] Orman, H., "The OAKLEY Key Determination Protocol", RFC [RFC2412] Orman, H., "The OAKLEY Key Determination Protocol", RFC
2412, November 1998. 2412, November 1998.
[RFC2451] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher [RFC2451] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher
Algorithms", RFC 2451, November 1998. Algorithms", RFC 2451, November 1998.
[RFC2521] Karn, P. and W. Simpson, "ICMP Security Failures
Messages", RFC 2521, March 1999.
[RFC2709] Srisuresh, P., "Security Model with Tunnel-mode IPsec for
NAT Domains", RFC 2709, October 1999.
[RFC2857] Keromytis, A. and N. Provos, "The Use of [RFC2857] Keromytis, A. and N. Provos, "The Use of
HMAC-RIPEMD-160-96 within ESP and AH", RFC 2857, June HMAC-RIPEMD-160-96 within ESP and AH", RFC 2857, June
2000. 2000.
[RFC3051] Heath, J. and J. Border, "IP Payload Compression Using
ITU-T V.44 Packet Method", RFC 3051, January 2001.
[RFC3056] Carpenter, B., "Connection of IPv6 Domains via IPv4 [RFC3056] Carpenter, B., "Connection of IPv6 Domains via IPv4
Clouds", RFC 3056, February 2001. Clouds", RFC 3056, February 2001.
[RFC3095] Bormann, C., Ed. et.al., "RObust Header Compression [RFC3095] Bormann, C., Ed. et.al., "RObust Header Compression
(ROHC): Framework and four profiles: RTP, UDP, ESP, and (ROHC): Framework and four profiles: RTP, UDP, ESP, and
uncompressed", RFC 3095, July 2001. uncompressed", RFC 3095, July 2001.
[RFC3129] Thomas, M., "Requirements for Kerberized Internet [RFC3129] Thomas, M., "Requirements for Kerberized Internet
Negotiation of Keys", RFC 3129, June 2001. Negotiation of Keys", RFC 3129, June 2001.
[RFC3173] Shacham, A. B. Monsour, R. Pereira and M. Thomas, "IP [RFC3173] Shacham, A. B. Monsour, R. Pereira and M. Thomas, "IP
Payload Compression Protocol (IPComp)", RFC 3173, Payload Compression Protocol (IPComp)", RFC 3173,
September 2001. September 2001.
[RFC3329] Arkko, J., V. Torvinen, G. Camarillo, A. Niemi and T.
Haukka, "Security Mechanism Agreement for the Session
Initiation Protocol (SIP)", RFC 3329, January 2003.
[RFC3456] Patel, B. B. Aboba, S. Kelly and V. Gupta, "Dynamic Host [RFC3456] Patel, B. B. Aboba, S. Kelly and V. Gupta, "Dynamic Host
Configuration Protocol (DHCPv4) Configuration of IPsec Configuration Protocol (DHCPv4) Configuration of IPsec
Tunnel Mode", RFC 3456, January 2003. Tunnel Mode", RFC 3456, January 2003.
[RFC3457] Kelly, S. and S. Ramamoorthi, "Requirements for IPsec [RFC3457] Kelly, S. and S. Ramamoorthi, "Requirements for IPsec
Remote Access Scenarios", RFC 3457, January 2003. Remote Access Scenarios", RFC 3457, January 2003.
[RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) [RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP)
Diffie-Hellman groups for Internet Key Exchange (IKE)", Diffie-Hellman groups for Internet Key Exchange (IKE)",
RFC 3526, May 2003. RFC 3526, May 2003.
skipping to change at page 56, line 5 skipping to change at page 55, line 5
December 2005. December 2005.
[RFC4309] Housley, R., "Using Advanced Encryption Standard (AES) CCM [RFC4309] Housley, R., "Using Advanced Encryption Standard (AES) CCM
Mode with IPsec Encapsulating Security Payload (ESP)", RFC Mode with IPsec Encapsulating Security Payload (ESP)", RFC
4309, December 2005. 4309, December 2005.
[RFC4312] Kato, A., S. Moriai and M. Kanda, "The Camellia Cipher [RFC4312] Kato, A., S. Moriai and M. Kanda, "The Camellia Cipher
Algorithm and Its Use with IPsec", RFC 4312, December Algorithm and Its Use with IPsec", RFC 4312, December
2005. 2005.
[RFC4322] Richardson, M. and D.H. Redelmeier, "Opportunistic
Encryption using the Internet Key Exchange (IKE)", RFC
4322, December 2005.
[RFC4359] Weis, B., "The Use of RSA/SHA-1 Signatures within [RFC4359] Weis, B., "The Use of RSA/SHA-1 Signatures within
Encapsulating Security Payload (ESP) and Authentication Encapsulating Security Payload (ESP) and Authentication
Header (AH)", RFC 4359, January 2006. Header (AH)", RFC 4359, January 2006.
[RFC4383] Baugher, M. and E. Carrara, "The Use of Timed Efficient [RFC4383] Baugher, M. and E. Carrara, "The Use of Timed Efficient
Stream Loss-Tolerant Authentication (TESLA) in the Secure Stream Loss-Tolerant Authentication (TESLA) in the Secure
Real-time Transport Protocol (SRTP)", RFC 4383, February Real-time Transport Protocol (SRTP)", RFC 4383, February
2006. 2006.
[RFC4430] Sakane, S., K. Kamada, M. Thomas, and J. Vilhuber, [RFC4430] Sakane, S., K. Kamada, M. Thomas, and J. Vilhuber,
skipping to change at page 57, line 23 skipping to change at page 56, line 27
Protocol (IKE)", RFC 4615, August 2006. Protocol (IKE)", RFC 4615, August 2006.
[RFC4621] Kivinen, T. and H. Tschofenig, "Design of the IKEv2 [RFC4621] Kivinen, T. and H. Tschofenig, "Design of the IKEv2
Mobility and Multihoming (MOBIKE) Protocol", RFC 4621, Mobility and Multihoming (MOBIKE) Protocol", RFC 4621,
August 2006. August 2006.
[RFC4650] Euchner, M., "HMAC-Authenticated Diffie-Hellman for [RFC4650] Euchner, M., "HMAC-Authenticated Diffie-Hellman for
Multimedia Internet KEYing (MIKEY)", RFC 4650, September Multimedia Internet KEYing (MIKEY)", RFC 4650, September
2006. 2006.
[RFC4705] Housley, R. and A. Corry, "GigaBeam High-Speed Radio Link
Encryption", RFC 4705, October 2006.
[RFC4718] Eronen, P. and P. Hoffman, "IKEv2 Clarifications and [RFC4718] Eronen, P. and P. Hoffman, "IKEv2 Clarifications and
Implementation Guidelines", RFC 4718, October 2006. Implementation Guidelines", RFC 4718, October 2006.
[RFC4738] Ignjatic, D., L. Dondeti, F. Audet and P. Lin, [RFC4738] Ignjatic, D., L. Dondeti, F. Audet and P. Lin,
"MIKEY-RSA-R: An Additional Mode of Key Distribution in "MIKEY-RSA-R: An Additional Mode of Key Distribution in
Multimedia Internet KEYing (MIKEY)", RFC 4738, November Multimedia Internet KEYing (MIKEY)", RFC 4738, November
2006. 2006.
[RFC4739] Eronen P. and J. Korhonen, "Multiple Authentication [RFC4739] Eronen P. and J. Korhonen, "Multiple Authentication
Exchanges in the Internet Key Exchange (IKEv2) Protocol", Exchanges in the Internet Key Exchange (IKEv2) Protocol",
skipping to change at page 58, line 30 skipping to change at page 57, line 38
[RFC4891] Graveman, R., M. Parthasarathy, P. Savola and H. [RFC4891] Graveman, R., M. Parthasarathy, P. Savola and H.
Tschofenig, "Using IPsec to Secure IPv6-in-IPv4 Tunnels", Tschofenig, "Using IPsec to Secure IPv6-in-IPv4 Tunnels",
RFC 4891, May 2007. RFC 4891, May 2007.
[RFC4894] Hoffman, P., "Use of Hash Algorithms in Internet Key [RFC4894] Hoffman, P., "Use of Hash Algorithms in Internet Key
Exchange (IKE) and IPsec", RFC 4894, May 2007. Exchange (IKE) and IPsec", RFC 4894, May 2007.
[RFC4945] Korver, B., "The Internet IP Security PKI Profile of [RFC4945] Korver, B., "The Internet IP Security PKI Profile of
IKEv1/ISAKMP, IKEv2, and PKIX", RFC 4945, August 2007. IKEv1/ISAKMP, IKEv2, and PKIX", RFC 4945, August 2007.
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2", RFC [RFC5026] Giaretta, G., Ed., J. Kempf and V. Devarapalli, Ed.,
4949, August 2007. "Mobile IPv6 Bootstrapping in Split Scenario", RFC 5026,
October 2007.
[RFC5106] Tschofenig, H., D. Kroeselberg, A. Pashalidis, Y. Ohba and [RFC5106] Tschofenig, H., D. Kroeselberg, A. Pashalidis, Y. Ohba and
F. Bersani, "The Extensible Authentication F. Bersani, "The Extensible Authentication
Protocol-Internet Key Exchange Protocol version 2 Protocol-Internet Key Exchange Protocol version 2
(EAP-IKEv2) Method", RFC 5106, February 2008. (EAP-IKEv2) Method", RFC 5106, February 2008.
[RFC5114] Lepinski, M. and S. Kent, "Additional Diffie-Hellman [RFC5114] Lepinski, M. and S. Kent, "Additional Diffie-Hellman
Groups for Use with IETF Standards", RFC 5114, January Groups for Use with IETF Standards", RFC 5114, January
2008. 2008.
skipping to change at page 61, line 5 skipping to change at page 59, line 35
5660, October 2009. 5660, October 2009.
[RFC5685] Devarapalli, V and K. Weniger, "Re-direct Mechanism for [RFC5685] Devarapalli, V and K. Weniger, "Re-direct Mechanism for
the Internet Key Exchange Protocol Version 2 (IKEv2)", RFC the Internet Key Exchange Protocol Version 2 (IKEv2)", RFC
5685, November 2009. 5685, November 2009.
[RFC5723] Sheffer, Y., H. Tschofenig, L. Dondeti and V. Narayanan, [RFC5723] Sheffer, Y., H. Tschofenig, L. Dondeti and V. Narayanan,
"Internet Key Exchange Protocol Version 2 (IKEv2) Session "Internet Key Exchange Protocol Version 2 (IKEv2) Session
Resumption", RFC 5723, January 2010. Resumption", RFC 5723, January 2010.
[RFC5739] Eronen, P., J. Laganier and C. Madson, "IPv6 Configuration
in Internet Key Exchange Protocol Version 2 (IKEv2)", RFC
5739, February 2010.
[RFC5840] Grewal, K. and G. Montenegro, "Wrapped Encapsulating
Security Payload (ESP) for Traffic Visibility", RFC 5840,
April 2010.
[RFC5856] Ertekin, E., R. Jasani, C. Christou and C. Bormann,
"Integration of Robust Header Compression over IPsec
Security Associations", RFC 5856, May 2010.
[RFC5857] Ertekin, E., C. Christou, R. Jasani, T. Kivinen and C.
Bormann, "IKEv2 Extensions to Support Robust Header
Compression over IPsec", RFC 5857, May 2010.
[RFC5858] Ertekin, E., C. Christou and C. Bormann, "IPsec Extensions
to Support Robust Header Compression over IPsec", RFC
5858, May 2010.
[RFC5879] Kivinen, T. and D. McDonald, "Heuristics for Detecting
ESP-NULL packets", RFC 5879, May 2010.
Appendix A. Summary of IPsec/IKE Document Requirement Levels Appendix A. Summary of IPsec/IKE Document Requirement Levels
Table 1: Document Requirement Levels Table 1: Document Requirement Levels
+--------------------------+----------------------------------------+ +--------------------------+----------------------------------------+
| DOCUMENT | REQUIREMENT LEVEL | | DOCUMENT | REQUIREMENT LEVEL |
| | IKEv1 IKEv2 IPsec-v2 IPsec-v3 | | | IKEv1 IKEv2 IPsec-v2 IPsec-v3 |
+--------------------------+----------------------------------------+ +--------------------------+----------------------------------------+
|IPsec-v2: | |IPsec-v2: |
|-------- | |-------- |
skipping to change at page 61, line 29 skipping to change at page 61, line 29
| RFC 2406 | MUST N/A | | RFC 2406 | MUST N/A |
| | | | | |
|IPsec-v3: | |IPsec-v3: |
|-------- | |-------- |
| RFC 4301 | N/A MUST | | RFC 4301 | N/A MUST |
| | | | | |
| RFC 4302 | N/A optional | | RFC 4302 | N/A optional |
| | | | | |
| RFC 4303 | N/A MUST | | RFC 4303 | N/A MUST |
| | | | | |
|Policy: |
|------ |
| RFC 3586 | optional N/A optional N/A |
| | |
| RFC 3585 | optional N/A optional N/A |
| | |
|MIBs: |
|---- |
| RFC 4807 | optional N/A |
+--------------------------+----------------------------------------+
Table 1: Document Requirement Levels (continued)
+--------------------------+----------------------------------------+
| DOCUMENT | REQUIREMENT LEVEL |
| | IKEv1 IKEv2 IPsec-v2 IPsec-v3 |
+--------------------------+----------------------------------------+
|Additions to IPsec: | |Additions to IPsec: |
|------------------ | |------------------ |
| RFC 3947 | optional N/A | | RFC 3947 | optional N/A |
| | | | | |
| RFC 3948 | optional optional | | RFC 3948 | optional optional |
| | | | | |
| RFC 4304 | optional N/A optional optional | | RFC 4304 | optional N/A |
| | |
| RFC 4322 | optional optional optional optional |
| | | | | |
| RFC 4891 | optional optional | | RFC 4891 | optional optional |
| | | | | |
| RFC 3884 | optional optional | | RFC 3884 | optional optional |
| | | | | |
| draft-ietf-ipsecme- | N/A optional | | RFC 5840 | N/A optional N/A optional |
| traffic-visibility | |
| | |
| draft-ietf-ipsecme- | optional optional |
| esp-null-heuristics | |
| | | | | |
| RFC 5879 | optional optional |
+--------------------------+----------------------------------------+
Table 1: Document Requirement Levels (continued)
+--------------------------+----------------------------------------+
| DOCUMENT | REQUIREMENT LEVEL |
| | IKEv1 IKEv2 IPsec-v2 IPsec-v3 |
+--------------------------+----------------------------------------+
|General Considerations: | |General Considerations: |
|---------------------- | |---------------------- |
| RFC 3715 | optional optional | | RFC 3715 | optional optional |
| | | | | |
| RFC 5406 | optional N/A | | RFC 5406 | optional N/A |
| | | | | |
| RFC 2521 | optional optional |
| | |
| draft-ietf-ipsecme-ipsec-| N/A optional N/A optional |
| ha | |
| | |
|IKEv1: | |IKEv1: |
|----- | |----- |
| RFC 2409 | optional N/A | | RFC 2409 | optional N/A |
| | | | | |
| RFC 2408 | optional N/A | | RFC 2408 | optional N/A |
| | | | | |
| RFC 2407 | optional N/A | | RFC 2407 | optional N/A |
| | | | | |
| RFC 2412 | optional N/A | | RFC 2412 | optional N/A |
| | | | | |
|IKEv2: | |IKEv2: |
|----- | |----- |
| RFC 4306 | N/A optional | | RFC 4306 | N/A optional |
| | | | | |
| RFC 4718 | N/A optional | | RFC 4718 | N/A optional |
| | | | | |
| draft-ietf-ipsecme-ikev2bis N/A optional | | draft-ietf-ipsecme-ikev2bis N/A optional |
+--------------------------+----------------------------------------+ | | |
Table 1: Document Requirement Levels (continued)
+--------------------------+----------------------------------------+
| DOCUMENT | REQUIREMENT LEVEL |
| | IKEv1 IKEv2 IPsec-v2 IPsec-v3 |
+--------------------------+----------------------------------------+
|Peer Authentication Methods: | |Peer Authentication Methods: |
|--------------------------- | |--------------------------- |
| RFC 4478 | N/A optional | | RFC 4478 | N/A optional |
| | | | | |
| RFC 4739 | N/A optional | | RFC 4739 | N/A optional |
| | | | | |
| RFC 4754 | optional optional | | RFC 4754 | optional optional |
| | | | | |
| draft-ietf-ipsecme-eap- | N/A optional |
| mutual | |
+--------------------------+----------------------------------------+
Table 1: Document Requirement Levels (continued)
+--------------------------+----------------------------------------+
| DOCUMENT | REQUIREMENT LEVEL |
| | IKEv1 IKEv2 IPsec-v2 IPsec-v3 |
+--------------------------+----------------------------------------+
|Certificate Contents and Management: | |Certificate Contents and Management: |
|----------------------------------- | |----------------------------------- |
| RFC 4809 | optional optional | | RFC 4809 | optional optional |
| | | | | |
| RFC 4945 | optional optional | | RFC 4945 | optional optional |
| | | | | |
| RFC 4806 | N/A optional | | RFC 4806 | N/A optional |
| | | | | |
|Dead Peer Detection: | |Dead Peer Detection: |
|------------------- | |------------------- |
| RFC 3706 | optional N/A | | RFC 3706 | optional N/A |
| | | | | |
|Remote Access: | |Remote Access: |
|------------- | |------------- |
| RFC 5723 | N/A optional | | RFC 5723 | N/A optional |
| | | | | |
| RFC 5685 | N/A optional | | RFC 5685 | N/A optional |
| | | | | |
| draft-ietf-ipsecme- | N/A optional | | RFC 5739 | N/A optional |
| ikev2-ipv6-config | |
| | | | | |
|Algorithm Requirements: | |Algorithm Requirements: |
|---------------------- | |---------------------- |
| RFC 4835 | MUST MUST | | RFC 4835 | MUST MUST |
| | | | | |
| RFC 4307 | N/A MUST | | RFC 4307 | N/A MUST |
| | | | | |
| RFC 4109 | MUST N/A | | RFC 4109 | MUST N/A |
+--------------------------+----------------------------------------+ +--------------------------+----------------------------------------+
 End of changes. 133 change blocks. 
489 lines changed or deleted 482 lines changed or added

This html diff was produced by rfcdiff 1.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/