Network Working Group S. Frankel
Internet Draft NIST
Obsoletes: 2411 (if approved) S. Krishnan
Intended Status: Informational Ericsson
Expires: August 2010 February 4, 2010
IP Security (IPsec) and Internet Key Exchange (IKE) Document Roadmap
<draft-ietf-ipsecme-roadmap-05.txt>
Status of this Memo
Distribution of this memo is unlimited.
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 4, 2010.
Copyright and License Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Frankel & Krishnan Expires August 2010 [Page 1]
Internet Draft IPsec/IKE Roadmap February 4, 2010
Abstract
Over the past few years, the number of RFCs that define and use IPsec
and IKE has greatly proliferated. This is complicated by the fact
that these RFCs originate from numerous IETF working groups: the
original IPsec WG, its various spin-offs, and other WGs that use
IPsec and/or IKE to protect their protocols' traffic.
This document is a snapshot of IPsec- and IKE-related RFCs. It
includes a brief description of each RFC, along with background
information explaining the motivation and context of IPsec's
outgrowths and extensions. It obsoletes the previous IPsec Document
Roadmap [RFC2411].
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. IPsec/IKE Background Information . . . . . . . . . . . . . . . . 5
2.1. Interrelationship of IPsec/IKE Documents . . . . . . . . . 5
2.2. Versions of IPsec . . . . . . . . . . . . . . . . . . . . . 6
2.2.1. Differences between "old" IPsec (IPsec-v2) and
"new" IPsec (IPsec-v3) . . . . . . . . . . . . . . . . 6
2.3. Versions of IKE . . . . . . . . . . . . . . . . . . . . . . 7
2.3.1. Differences between IKEv1 and IKEv2 . . . . . . . . . . 7
2.4. IPsec and IKE IANA Registries . . . . . . . . . . . . . . . 8
3. IPsec Documents . . . . . . . . . . . . . . . . . . . . . . . . 9
3.1. Base Documents . . . . . . . . . . . . . . . . . . . . . . 9
3.1.1. "Old" IPsec . . . . . . . . . . . . . . . . . . . . . . 9
3.1.2. "New" IPsec . . . . . . . . . . . . . . . . . . . . . . 11
3.2. Policy . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.3. MIBs . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.4. Additions to IPsec . . . . . . . . . . . . . . . . . . . . 13
3.5. General Considerations . . . . . . . . . . . . . . . . . . 15
4. IKE Documents . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.1. Base Documents . . . . . . . . . . . . . . . . . . . . . . 16
4.1.1. IKEv1 . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.1.2. IKEv2 . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.2. Additions and Extensions . . . . . . . . . . . . . . . . . 19
4.2.1. Peer Authentication Methods . . . . . . . . . . . . . . 19
4.2.2. Certificate Contents and Management . . . . . . . . . . 20
4.2.3. Dead Peer Detection . . . . . . . . . . . . . . . . . . 21
4.2.4. Remote Access . . . . . . . . . . . . . . . . . . . . . 21
5. Cryptographic Algorithms and Suites . . . . . . . . . . . . . . 22
5.1. Algorithm Requirements . . . . . . . . . . . . . . . . . . 23
5.2. Encryption Algorithms . . . . . . . . . . . . . . . . . . . 24
5.3. Integrity-Protection (Authentication) Algorithms . . . . . 28
5.4. Combined Mode Algorithms . . . . . . . . . . . . . . . . . 31
5.5. Pseudo-Random Functions (PRFs) . . . . . . . . . . . . . . 33
Frankel & Krishnan Expires August 2010 [Page 2]
Internet Draft IPsec/IKE Roadmap February 4, 2010
5.6. Cryptographic Suites . . . . . . . . . . . . . . . . . . . 35
5.7. Diffie-Hellman Algorithms . . . . . . . . . . . . . . . . . 36
6. IPsec/IKE for Multicast . . . . . . . . . . . . . . . . . . . . 37
7. Outgrowths of IPsec/IKE . . . . . . . . . . . . . . . . . . . . 40
7.1. IPComp (Compression) . . . . . . . . . . . . . . . . . . . 40
7.2. IKEv2 Mobility and Multihoming (MOBIKE) . . . . . . . . . . 41
7.3. Better-than-Nothing Security (BTNS) . . . . . . . . . . . . 42
7.4. Kerberized Internet Negotiation of Keys (KINK) . . . . . . 42
7.5. IPsec Secure Remote Access (IPSRA) . . . . . . . . . . . . 43
7.6. IPsec Keying Information Resource Record (IPSECKEY) . . . . 44
8. Other Protocols that use IPsec/IKE . . . . . . . . . . . . . . . 44
8.1. Mobile IP (MIPv4 and MIPv6) . . . . . . . . . . . . . . . . 44
8.2. Open Shortest Path First (OSPF) . . . . . . . . . . . . . . 46
8.3. Host Identity Protocol (HIP) . . . . . . . . . . . . . . . 46
8.4. Extensible Authentication Protocol (EAP) Method Update
(EMU) . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
8.5. Stream Control Transmission Protocol (SCTP) . . . . . . . . 48
8.6. Fibre Channel . . . . . . . . . . . . . . . . . . . . . . . 48
8.7. Robust Header Compression (ROHC) . . . . . . . . . . . . . 48
8.8. Border Gateway Protocol (BGP) . . . . . . . . . . . . . . . 49
8.9. IPsec benchmarking . . . . . . . . . . . . . . . . . . . . 49
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 50
10. Security Considerations . . . . . . . . . . . . . . . . . . . . 50
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 50
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
12.1. Normative References . . . . . . . . . . . . . . . . . . . 50
12.2. Informative References . . . . . . . . . . . . . . . . . . 50
Appendix A. Summary of IPsec/IKE Document Requirement Levels . . . 61
Appendix B. Summary of Algorithm Requirement Levels . . . . . . . . 64
Frankel & Krishnan Expires August 2010 [Page 3]
Internet Draft IPsec/IKE Roadmap February 4, 2010
1. Introduction
IPsec (Internet Protocol Security) is a suite of protocols that
provides security to Internet communications at the IP layer. The
most common current use of IPsec is to provide a Virtual Private
Network (VPN), either between two locations (gateway-to-gateway) or
between a remote user and an enterprise network (host-to-gateway); it
can also provide end-to-end, or host-to-host, security. IPsec is
also used by other Internet protocols (e.g. MIPv6) to protect some or
all of their traffic. IKE (Internet Key Exchange) is the key
negotiation and management protocol that is most commonly used to
provide dynamically negotiated and updated keying material for IPsec.
IPsec and IKE can be used in conjunction with both IPv4 and IPv6.
In addition to the base documents for IPsec and IKE, there are
numerous RFCs that reference, extend, and in some cases alter the
core specifications. This document is an attempt to list and briefly
describe those RFCs, providing context and rationale where indicated.
The title of each RFC is followed by a letter that indicates its
category in the RFC series [RFC2026], as follows:
o S: Standards Track (Proposed Standard, Draft Standard, or
Standard)
o E: Experimental
o B: Best Current Practice
o I: Informational
For each RFC, the publication date is also given.
This document also categorizes the requirements level for the IPsec,
IKE and cryptographic algorithms documents for use with IKEv1, IKEv2,
IPsec-v2 and IPsec-v3. These requirements are summarized in
Appendices A and B.
For each core IPsec and IKE RFC, this document will classify its
Requirements Level for each protocol (IKEv1, IKEv2, IPsec-v2,
IPsec-v3), as either MUST, SHALL or MAY [RFC2119]; optional;
undefined; or N/A (not applicable). Optional means that either the
RFC describes features that are not required to be implemented or
settings or procedures that are recommended but not mandatory.
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
is inappropriate in the context (e.g., combined mode algorithms, a
new feature in IPsec-v3, for use with IPsec-v2). The classification
of the cryptographic algorithm RFCs is further explained in Section
Frankel & Krishnan Expires August 2010 [Page 4]
Internet Draft IPsec/IKE Roadmap February 4, 2010
5.
The usage of terms in this document conforms to definitions in
[RFC4949].
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
2. IPsec/IKE Background Information
2.1. Interrelationship of IPsec/IKE Documents
The main documents describing the set of IPsec protocols are divided
into seven groups. This is illustrated in Figure 1. There is a main
Architecture document which broadly covers the general concepts,
security requirements, definitions, and mechanisms defining IPsec
technology.
There are an ESP Protocol document and an AH Protocol document which
cover the packet format and general issues regarding the respective
protocols. The "Encryption Algorithm" document set, shown on the
left, is the set of documents describing how various encryption
algorithms are used for ESP. The "Combined Algorithm" document set,
shown in the middle, is the set of documents describing how various
combined mode algorithms are used to provide both encryption and
integrity-protection for ESP. The "Integ-Protection Algorithm"
document set, shown on the right, is the set of documents describing
how various integrity-protection algorithms are used for both ESP and
AH.
The "IKE Documents", shown at the bottom, are the documents
describing the IETF standards-track key management schemes.
Frankel & Krishnan Expires August 2010 [Page 5]
Internet Draft IPsec/IKE Roadmap February 4, 2010
+--------------+
| Architecture |
+--------------+
v v
+<-<-<-<-<-<-<-<-+ +->->->->->->->->+
v v
+----------+ +----------+
| ESP | | AH |
| Protocol | | Protocol |
+----------+ +----------+
v v v v
v +->->->->->->->->+->->->->->->->->+ v v
v v v v v v
v v v v v v
v +------------+ +-----------+ +----------------+ v
v | +------------+ | +------------+ | +----------------+ v
v | | Encryption | | | Combined | | |Integ-Protection| v
v +-| Algorithm | +-| Algorithm | +-| Algorithm | v
v +------------+ +------------+ +----------------+ v
v v v v v
v v v v v
+>->->->-+->->->->->->->->->--<-<-<-<-<-<-<-<-<-+-<-<-<-<-+
^
^
+------------+
| IKE |
| Protocol |
+------------+
2.2. Versions of IPsec
Two versions of IPsec can currently be found in implementations. The
"new" IPsec (referred to as IPsec-v3 in this document) obsoleted the
"old" IPsec (referred to as IPsec-v2 in this document); however,
IPsec-v2 is still commonly found in operational use. In this
document, when the unqualified term IPsec is used, it pertains to
both versions of IPsec. An earlier version of IPsec (defined in RFCs
1825-1829), obsoleted by IPsec-v2, is not covered in this document.
2.2.1. Differences between "old" IPsec (IPsec-v2) and "new" IPsec
(IPsec-v3)
IPsec-v3 incorporates "lessons learned" from implementation and
operational experience with IPsec-v2 and its predecessor, IPsec-v1.
Knowledge was gained about the barriers to IPsec deployment, the
scenarios in which IPsec is most effective, and requirements that
needed to be added to IPsec to facilitate its use with other
protocols. In addition, the documentation for IPsec-v3 clarifies and
Frankel & Krishnan Expires August 2010 [Page 6]
Internet Draft IPsec/IKE Roadmap February 4, 2010
expands details that were underspecified or ambiguous in IPsec-v2.
Changes to the architecture document [RFC4301] include:
o More detailed descriptions of IPsec processing, both unicast and
multicast, and the interactions among the various IPsec
databases
o In IPsec-v2, an SA (Security Association) is uniquely identified
by a combination of the SPI (Security Parameters Index),
protocol (ESP or AH), and destination address. In IPsec-v3, a
unicast SA is uniquely identified by the SPI and, optionally, by
the protocol; a multicast SA is identified by a combination of
the SPI and the destination address and, optionally, the source
address.
o More flexible SPD (Security Policy Database) selectors,
including ranges of values and ICMP message types as selectors
o Decorrelated (order-independent) SAD (Security Association
Database) replaced the former ordered SAD
o Added extended sequence numbers (ESNs)
o Mandatory algorithms defined in standalone document
o AH [RFC4302] is mandatory-to-implement (MUST) in IPsec-v2,
optional (MAY) in IPsec-v3
Changes to ESP [RFC4303] include:
o Added combined mode algorithms, necessitating changes to packet
format and processing
o NULL authentication, mandatory (MUST) in ESP-v2, is optional
(MAY) in ESP-v3
2.3. Versions of IKE
Two versions of IKE can currently be found in implementations. The
"new" IKE (generally referred to as IKEv2) obsoleted the "old" IKE
(generally referred to as IKEv1); however, IKEv1 is still commonly
found in operational use. In this document, when the unqualified
term IKE is used, it pertains to both versions of IKE.
2.3.1. Differences between IKEv1 and IKEv2
As with IPsec-v3, IKEv2 incorporates "lessons learned" from
Frankel & Krishnan Expires August 2010 [Page 7]
Internet Draft IPsec/IKE Roadmap February 4, 2010
implementation and operational experience with IKEv1. Knowledge was
gained about the barriers to IKE deployment, the scenarios in which
IKE is most effective, and requirements that needed to be added to
IKE to facilitate its use with other protocols as well as in
general-purpose use. The documentation for IKEv2 replaces multiple,
at times contradictory documents, with a single document; it also
clarifies and expands details that were underspecified or ambiguous
in IKEv1.
Once an IKE negotiation is successfully completed, the peers have
established two pairs of one-way (inbound and outbound) SAs. Since
IKE always negotiates pairs of SAs, the term "SA" is generally used
to refer to a pair of SAs (e.g., an "IKE SA" or an "IPsec SA" is in
reality a pair of one-way SAs). The first SA, the IKE SA, is used to
protect IKE traffic. The second SA provides IPsec protection to data
traffic between the peers and/or other devices for which the peers
are authorized to negotiate. It is called the IPsec SA in IKEv1 and,
in the IKEv2 RFCs, it is referred to variously as a CHILD_SA, a child
SA, and an IPsec SA. This document uses the term "IPsec SA". To
further complicate the terminology, since IKEv1 consists of two
sequential negotiations, called phases, the IKE SA is also referred
to as a phase 1 SA and the IPsec SA is referred to as a phase 2 SA.
Changes to IKE include:
o Multiple alternate exchange types replaced by a single, shorter
exchange
o Streamlined negotiation format to avoid combinatorial bloat for
multiple proposals
o Protects responder from committing significant resources to the
exchange until the initiator's existence and identity are
confirmed
o Reliable exchanges: Every request expects a response
o Protection of IKE messages based on ESP, rather than a method
unique to IKE
o Add traffic selectors: distinct from peer IDs and more flexible
o Support of EAP-based authentication methods and asymmetric
authentication (i.e., initiator and responder can use different
authentication methods)
2.4. IPsec and IKE IANA Registries
Frankel & Krishnan Expires August 2010 [Page 8]
Internet Draft IPsec/IKE Roadmap February 4, 2010
Numerous IANA registries contain values that are used in IPsec, IKE
and related protocols. They include:
o IKE Attributes
(http://www.iana.org/assignments/ipsec-registry): values used
during IKEv1 Phase 1 exchanges, defined in [RFC2409]
o "Magic Numbers" for ISAKMP Protocol
(http://www.iana.org/assignments/isakmp-registry): values used
during IKEv1 Phase 2 exchanges, defined in [RFC2407], [RFC2408]
and numerous other cryptographic algorithm RFCs
o IKEv2 Parameters
(http://www.iana.org/assignments/ikev2-parameters): values used
in IKEv2 exchanges, defined in [RFC4306] and numerous other
cryptographic algorithm RFCs
o Cryptographic Suites for IKEv1, IKEv2, and IPsec
(http://www.iana.org/assignments/crypto-suites): names of
cryptographic suites in [RFC4308] and [RFC4869]
3. IPsec Documents
3.1. Base Documents
IPsec protections are provided by two special headers: the
Encapsulating Security Payload (ESP) Header and the Authentication
Header (AH). In IPv4, these headers take the form of protocol
headers; in IPv6, they are classified as extension headers. There are
3 base IPsec documents: one that describes the IP security
architecture, and one for each of the IPsec headers.
3.1.1. "Old" IPsec
3.1.1.1. RFC 2401, Security Architecture for the Internet Protocol (S,
Nov. 1998)
[RFC2401] specifies the mechanisms, procedures and components
required to provide security services at the IP layer. It also
describes their interrelationship, and the general processing
required to inject IPsec protections into the network architecture.
The components include:
- SA (Security Association): a one-way (inbound or outbound)
agreement between two communicating peers that specifies the IPsec
protections to be provided to their communications. This includes
Frankel & Krishnan Expires August 2010 [Page 9]
Internet Draft IPsec/IKE Roadmap February 4, 2010
the specific security protections, cryptographic algorithms, and
secret keys to be applied, as well as the specific types of traffic
to be protected.
- SPI (Security Parameters Index): a value that, together with
the Destination Address and security protocol (AH or ESP), uniquely
identifies a single SA
- SAD (Security Association Database): each peer's SA
repository. The RFC describes how this database functions (SA
lookup, etc.) and the types of information it must contain to
facilitate SA processing; it does not dictate the format or layout of
the database. SAs can be established in either transport mode or
tunnel mode (see below).
- SPD (Security Policy Database): an ordered database that
expresses the security protections to be afforded to different types
and classes of traffic. The 3 general classes of traffic are:
traffic to be discarded, traffic that is allowed without IPsec
protection, and traffic that requires IPsec protection.
The RFC describes general inbound and outbound IPsec processing; it
also includes details on several special cases: packet fragments,
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)
[RFC2402] defines the Authentication Header (AH), which provides
integrity protection; it also provides data origin authentication,
access control, and, optionally, replay protection. A transport mode
AH SA, used to protect peer-to-peer communications, protects
upper-layer data, as well as those portions of the IP header that do
not vary unpredictably during packet delivery. A tunnel mode AH SA
can be used to protect gateway-to-gateway or host-to-gateway traffic;
it can optionally be used for host-to-host traffic. This class of AH
SA protects the inner (original) header and upper-layer data, as well
as those portions of the outer (tunnel) header that do not vary
unpredictably during packet delivery. Because portions of the IP
header are not included in the AH calculations, AH processing is more
complex than ESP processing. AH also does not work in the presence
of Network Address Translation (NAT). Unlike IPsec-v3, IPsec-v2
classifies AH as mandatory-to-implement.
Frankel & Krishnan Expires August 2010 [Page 10]
Internet Draft IPsec/IKE Roadmap February 4, 2010
Requirements levels for RFC2402:
IPsec-v2 - MUST
IPsec-v3 - N/A
3.1.1.3. RFC 2406, IP Encapsulating Security Payload (ESP) (S, Nov.
1998)
[RFC2406] defines the IP Encapsulating Security Payload (ESP), which
provides confidentiality (encryption) and/or integrity protection; it
also provides data origin authentication, access control, and,
optionally, replay and/or traffic analysis protection. A transport
mode ESP SA protects the upper-layer data, but not the IP header. A
tunnel mode ESP SA protects the upper-layer data and the inner
header, but not the outer header.
Requirements levels for RFC2406:
IPsec-v2 - MUST
IPsec-v3 - N/A
3.1.2. "New" IPsec
3.1.2.1. RFC 4301, Security Architecture for the Internet Protocol (S,
Dec. 2005)
[RFC4301] obsoletes [RFC2401], including a more complete and detailed
processing model. The most notable changes are detailed above in
Section 2.2.1. IPsec-v3 processing incorporates an additional
database:
- PAD (Peer Authorization Database): contains information
necessary to conduct peer authentication, providing a link between
IPsec and the key management 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)
[RFC4302] obsoletes [RFC2402]. Unlike IPsec-v2, IPsec-v3 classifies
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.
2005)
Frankel & Krishnan Expires August 2010 [Page 11]
Internet Draft IPsec/IKE Roadmap February 4, 2010
[RFC4303] obsoletes [RFC2406]. The most notable changes are detailed
above in Section 2.2.1.
Requirements levels for RFC4303:
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
Frankel & Krishnan Expires August 2010 [Page 12]
Internet Draft IPsec/IKE Roadmap February 4, 2010
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
were defined in separate documents: negotiation of NAT traversal,
extended sequence numbers, and UDP encapsulation of ESP packets.
Additional uses of IPsec transport mode were also described:
protection of manually-configured IPv6-in-IPv4 tunnels and protection
of IP-in-IP tunnels. These documents describe atypical uses of IPsec
transport mode, but do not define any new IPsec features.
Once the original IPsec working group concluded, additional
IPsec-related issues were handled by the IPsecME (IPsec Maintenance
and Extensions) working group. One such problem is the capability of
middleboxes to distinguish unencrypted ESP packets (ESP-NULL) from
encrypted ones in a fast and accurate manner. Two solutions are
described: a new protocol that requires changes to IKEv2 and
IPsec-v3, and a heuristic method that imposes no new requirements.
3.4.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)
[RFC3948] defines how to encapsulate ESP packets in UDP packets to
Frankel & Krishnan Expires August 2010 [Page 13]
Internet Draft IPsec/IKE Roadmap February 4, 2010
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:
IPsec-v2 - optional
IPsec-v3 - optional
3.4.3. RFC 4304, Extended Sequence Number (ESN) Addendum to IPsec
Domain of Interpretation (DOI) for Internet Security Association and
Key Management Protocol (ISAKMP) (S, Dec. 2005)
The use of ESNs allows IPsec to use 64-bit sequence numbers for
replay protection, but to send only 32 bits of the sequence number in
the packet, enabling shorter packets and avoiding a re-design of the
packet format. The larger sequence numbers allow an existing IPsec
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.
For IKEv2, this capability is described in [RFC4306].
Requirements levels for RFC4304:
IKEv1 - optional
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
2007)
[RFC4891] describes how to use IKE and transport-mode IPsec to
provide security protection to manually-configured IPv6-in-IPv4
tunnels. This document uses standard IKE and IPsec, without any new
extensions. It does not apply to tunnels that are initiated in an
automated manner (e.g., 6to4 tunnels [RFC3056]).
Requirements levels for RFC4891:
IPsec-v2 - optional
IPsec-v3 - optional
3.4.5. RFC 3884, Use of IPsec Transport Mode for Dynamic Routing (I,
Sep. 2004)
[RFC3884] describes the use of transport-mode IPsec to secure
IP-in-IP tunnels, which constitute the links of a multi-hop,
distributed virtual network (VN). This allows the traffic to be
dynamically routed via the VN's trusted routers, rather than routing
Frankel & Krishnan Expires August 2010 [Page 14]
Internet Draft IPsec/IKE Roadmap February 4, 2010
all traffic through a statically-routed IPsec tunnel. This RFC has
not been widely adopted.
Requirements levels for RFC3884:
IPsec-v2 - optional
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
easily determine whether protected traffic that is passing through
the device is encrypted, or only integrity-protected (referred to as
ESP-NULL packets). [ipsecme-3] extends ESP to provide explicit
notification of integrity-protected packets, and extends IKEv2 to
negotiate this capability between the IPsec peers.
Requirements levels for draft-ietf-ipsecme-traffic-visibility:
IPsec-v2 - N/A
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
ESP-encrypted and ESP-NULL packets, through packet inspection. This
method does not require any change to IKEv2 or ESP.
Requirements levels for draft-ietf-ipsecme-esp-null-heuristics:
IPsec-v2 - optional
IPsec-v3 - optional
3.5. General Considerations
3.5.1. RFC 3715, IPsec-Network Address Translation (NAT) Compatibility
Requirements (I, Mar. 2004)
[RFC3715] "describes known incompatibilities between NAT and IPsec,
and describes the requirements for addressing them." This is a
critical issue, since IPsec is frequently used to provide VPN access
to the corporate network for telecommuters, and NATs are widely
deployed in home gateways, hotels, and other access networks
typically used for remote access.
Requirements levels for RFC3715:
IPsec-v2 - optional
Frankel & Krishnan Expires August 2010 [Page 15]
Internet Draft IPsec/IKE Roadmap February 4, 2010
IPsec-v3 - optional
3.5.2. RFC 5406, Guidelines for Specifying the Use of IPsec Version 2
(B, Feb. 2009)
[RFC5406] offers guidance to protocol designers on how to ascertain
whether IPsec is the appropriate security mechanism to provide an
interoperable security solution for the protocol. If this is not the
case, it advises against attempting to define a new security
protocol; rather, it suggests using another standards-based security
protocol. The details in this document apply only to IPsec-v2.
Requirements levels for RFC5406:
IPsec-v2 - optional
IPsec-v3 - N/A
4. IKE Documents
4.1. Base Documents
4.1.1. IKEv1
IKE is the preferred key management protocol for IPsec. It is used
for peer authentication; to negotiate, modify and delete SAs; and to
negotiate authenticated keying material for use within those SAs.
The standard peer authentication methods used by IKEv1 (pre-shared
secret keys and digital certificates) had several shortcomings
related to use of IKEv1 to enable remote user authentication to a
corporate VPN: it could not leverage the use of legacy authentication
systems (e.g. RADIUS databases) to authenticate a remote user to a
security gateway; and it could not be used to configure remote users
with network addresses or other information needed in order to access
the internal network.
Several Internet Drafts were written to address these problems: two
such Internet Drafts include "Extended Authentication within IKE
(XAUTH)" (draft-beaulieu-ike-xauth and its predecessor, "Extended
Authentication within ISAKMP/Oakley (XAUTH)",
draft-ietf-ipsec-isakmp-xauth) and "The ISAKMP Configuration Method"
(draft-dukes-ike-mode-cfg and its predecessor
draft-ietf-ipsec-isakmp-mode-cfg). These drafts did not progress to
RFC status due to security flaws and other problems related to these
solutions. However, many current IKEv1 implementations incorporate
aspects of these solutions to facilitate remote user access to
corporate VPNs. These solutions were not standardized, and different
implementations implemented different versions. Thus, there is no
assurance that the implementations adhere fully to the suggested
solutions, or that one implementation can interoperate with others
Frankel & Krishnan Expires August 2010 [Page 16]
Internet Draft IPsec/IKE Roadmap February 4, 2010
that claim to incorporate the same features. Furthermore, these
solutions have known security issues. All of those problems and
security issues have been solved in IKEv2; thus use of these
non-standardized IKEv1 solutions is not recommended.
4.1.1.1. RFC 2409, The Internet Key Exchange (IKE) (S, Nov. 1998)
This document defines a key exchange protocol that can be used to
negotiate authenticated keying material for SAs. This document
implements a subset of the Oakley protocol in conjunction with ISAKMP
to obtain authenticated keying material for use with ISAKMP, and for
other security associations such as AH and ESP for the IETF IPsec
DOI. While historically IKEv1 was created by combining two security
protocols, ISAKMP and Oakley, in practice the combination (along with
the IPsec DOI) has commonly been viewed as one protocol, IKEv1. The
protocol's origins can be seen in the organization of the documents
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
Protocol (ISAKMP) (S, Nov. 1998)
This document defines procedures and packet formats to establish,
negotiate, modify and delete Security Associations (SAs). It is
intended to support the negotiation of SAs for security protocols at
all layers of the network stack. ISAKMP can work with many different
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
for ISAKMP (S, Nov. 1998)
Within ISAKMP, a Domain of Interpretation is used to group related
protocols using ISAKMP to negotiate security associations. Security
protocols sharing a DOI choose security protocol and cryptographic
transforms from a common namespace and share key exchange protocol
identifiers. This document defines the Internet IP Security DOI
(IPSEC DOI), which instantiates ISAKMP for use with IP when IP uses
ISAKMP to negotiate security associations.
Frankel & Krishnan Expires August 2010 [Page 17]
Internet Draft IPsec/IKE Roadmap February 4, 2010
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)
[RFC2412] describes a key establishment protocol using which two
authenticated parties can agree on secure and secret keying material.
The Oakley protocol describes a series of key exchanges-- called
"modes"-- and details the services provided by each (e.g. perfect
forward secrecy for keys, identity protection, and authentication).
This document provides additional theory and background to explain
some of the design decisions and security features of IKE and ISAKMP;
it does not include details necessary for the implementation of
IKEv1.
Requirements levels for RFC2412:
IPsec-v2 - optional
IPsec-v3 - N/A
4.1.2. IKEv2
4.1.2.1. RFC 4306, Internet Key Exchange (IKEv2) Protocol (S, Dec.
2005)
This document describes version 2 of the Internet Key Exchange (IKE)
protocol. It covers what was covered previously by separate
documents: ISAKMP, IKE and DOI. It also addresses NAT traversal,
legacy authentication and remote address acquisition. IKEv2 is not
interoperable with IKEv1.
Requirements levels for RFC4306:
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
(I, Oct. 2006)
[RFC4718] clarifies many areas of the IKEv2 specification that may be
difficult to understand for developers who are not intimately
familiar with the specification and its history. It does not
introduce any changes to the protocol, but rather provides
descriptions that are less prone to ambiguous interpretations. The
goal of this document is to encourage the development of
interoperable implementations.
Frankel & Krishnan Expires August 2010 [Page 18]
Internet Draft IPsec/IKE Roadmap February 4, 2010
Requirements levels for RFC4718:
IPsec-v2 - N/A
IPsec-v3 - optional
4.1.2.3. draft-ietf-ipsecme-ikev2bis, Internet Key Exchange Protocol:
IKEv2 (S)
[ipsecme-1] combines the original IKEv2 RFC [RFC4306] with the
Clarifications RFC [RFC4718], and resolves many implementation issues
discovered by the community since the publication of these two
documents. This document was developed by the IPsecME (IPsec
Maintenance and Extensions) working group, after the conclusion of
the original IPsec working group.
Requirements levels for draft-ietf-ipsecme-ikev2bis:
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.1. Peer Authentication Methods
4.2.1.1. RFC 4478, Repeated Authentication in Internet Key Exchange
(IKEv2) Protocol (E, Apr. 2006)
[RFC4478] addresses a problem unique to remote access scenarios. How
can the gateway (the IKE responder) force the remote user (the IKE
initiator) to periodically re-authenticate, limiting the damage in
the case where an unauthorized user gains physical access to the
remote host? This document defines a new status notification, that a
responder can send to an initiator, notifying the initiator that the
IPsec SA will be revoked unless the initiator re-authenticates within
a specified period of time.
Requirements levels for RFC4478:
IKEv1 - N/A
IKEv2 - optional
4.2.1.2. RFC 4739, Multiple Authentication Exchanges in the Internet
Key Exchange (IKEv2) Protocol (E, Nov. 2006)
IKEv2 supports several mechanisms for authenticating the parties but
each endpoint uses only one of these mechanisms to authenticate
itself. [RFC4739] specifies an extension to IKEv2 that allows the
use of multiple authentication exchanges, using either different
mechanisms or the same mechanism. This extension allows, for
Frankel & Krishnan Expires August 2010 [Page 19]
Internet Draft IPsec/IKE Roadmap February 4, 2010
instance, performing certificate-based authentication of the client
host followed by an EAP authentication of the user. This also allows
for authentication by multiple administrative domains, if needed.
Requirements levels for RFC4739:
IKEv1 - N/A
IKEv2 - optional
4.2.1.3. RFC 4754, IKE and IKEv2 Authentication Using the Elliptic
Curve Digital Signature Algorithm (ECDSA) (S, Jan. 2007)
[RFC4754] describes how the Elliptic Curve Digital Signature
Algorithm (ECDSA) may be used as the authentication method within the
IKEv1 and IKEv2 protocols. ECDSA provides many benefits including
computational efficiency, small signature sizes, and minimal
bandwidth compared to other available digital signature methods like
RSA and DSA.
Requirements levels for RFC4754:
IKEv1 - optional
IKEv2 - optional
4.2.2. Certificate Contents and Management (PKI4IPsec)
The format, contents and interpretation of Public Key Certificates
proved to be a source of interoperability problems within IKE and
IPsec. PKI4IPsec was an attempt to set in place some common
procedures and interpretations to mitigate those problems.
4.2.2.1. RFC 4809, Requirements for an IPsec Certificate Management
Profile (I, Feb. 2007)
[RFC4809] enumerates requirements for Public Key Certificate (PKC)
lifecycle transactions between different VPN System and PKI System
products in order to better enable large scale, PKI-enabled IPsec
deployments with a common set of transactions. This document
discusses requirements for both the IPsec and the PKI products.
Requirements levels for RFC4809:
IKEv1 - optional
IKEv2 - optional
4.2.2.2. RFC 4945, The Internet IP Security PKI Profile of
IKEv1/ISAKMP, IKEv2, and PKIX (S, Aug. 2007)
[RFC4945] defines a profile of the IKE and PKIX frameworks in order
to provide an agreed-upon standard for using PKI technology in the
Frankel & Krishnan Expires August 2010 [Page 20]
Internet Draft IPsec/IKE Roadmap February 4, 2010
context of IPsec. It also documents the contents of the relevant IKE
payloads and further specifies their semantics. It also summarizes
the current state of implementations and deployment and provides
advice to avoid common interoperability issues.
Requirements levels for RFC4945:
IKEv1 - optional
IKEv2 - optional
4.2.2.3. RFC 4806, Online Certificate Status Protocol (OCSP) Extensions
to IKEv2 (S, Feb. 2007)
When certificates are used with IKEv2, the communicating peers need a
mechanism to determine the revocation status of the peer's
certificate. OCSP is one such mechanism. [RFC4806] defines the
"OCSP Content" extension to IKEv2. This document is applicable when
OCSP is desired and security policy (e.g. firewall policy) prevents
one of the IKEv2 peers from accessing the relevant OCSP responder
directly.
Requirements levels for RFC4806:
IKEv1 - N/A
IKEv2 - optional
4.2.3. Dead Peer Detection
4.2.3.1. RFC 3706, A Traffic-Based Method of Detecting Dead Internet
Key Exchange (IKE) Peers (I, Feb. 2004)
When two peers communicate using IKE and IPsec, it is possible for
the connectivity between the two peers to drop unexpectedly. But the
SAs can still remain until their lifetimes expire, resulting in the
packets getting tunneled into a "black hole". [RFC3706] describes an
approach to detect peer liveliness without needing to send messages
at regular intervals. This RFC defines an optional extension to
IKEv1; dead peer detection (DPD) is an integral part of IKEv2, which
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
The IPsecME working group identified some missing components needed
for more extensive IKEv2 and IPsec-v3 support for remote access
Frankel & Krishnan Expires August 2010 [Page 21]
Internet Draft IPsec/IKE Roadmap February 4, 2010
clients. These include: efficient client resumption of a previously
established session with a VPN gateway; efficient client redirection
to an alternate VPN gateway; and support for IPv6 client
configuration using IPsec configuration payloads.
4.2.4.1. RFC 5723, Internet Key Exchange Protocol Version 2 (IKEv2)
Session Resumption (S, Jan. 2010)
[RFC5723] enables a remote client that has been disconnected from a
gateway to re-establish SAs with the gateway in an expedited manner,
without repeating the complete IKEv2 negotiation. This capability
requires changes to IKEv2.
Requirements levels for RFC5723:
IKEv1 - N/A
IKEv2 - optional
4.2.4.2. RFC 5685, Re-direct Mechanism for the Internet Key Exchange
Protocol Version 2 (IKEv2) (S, Nov. 2009)
[RFC5685] enables a gateway to securely re-direct VPN clients to
another VPN gateway, either during or after the IKEv2 negotiation.
Possible reasons include, but are not limited to, an overloaded
gateway or a gateway that needs to shut down. This requires changes
to IKEv2.
Requirements levels for RFC5685:
IKEv1 - N/A
IKEv2 - optional
4.2.4.3. draft-ietf-ipsecme-ikev2-ipv6-config, IPv6 Configuration in
IKEv2 (E)
In IKEv2, a VPN gateway can assign an internal network address to a
remote VPN client. This is accomplished through the use of
configuration payloads. For an IPv6 client, the assignment of a
single address is not sufficient to enable full-fledged IPv6
communications. [ipsecme-2] proposes several solutions that might
remove this limitation.
Requirements levels for draft-ietf-ipsecme-ikev2-ipv6-config:
IKEv1 - N/A
IKEv2 - optional
5. Cryptographic Algorithms and Suites
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
Frankel & Krishnan Expires August 2010 [Page 22]
Internet Draft IPsec/IKE Roadmap February 4, 2010
that describes how to use the algorithm within the relevant protocol,
packet formats, special considerations, etc. For each RFC that
describes a cryptographic algorithm, this document will classify its
Requirements Level for each protocol, as either MUST, SHALL or MAY
[RFC2119]; optional; undefined; or N/A (not applicable). Optional
means that the algorithm meets the two basic requirements, but its
use is not specifically recommended for that protocol. Undefined
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
specifying how it should be used within that specific protocol. N/A
means that use of the algorithm is inappropriate in the context
(e.g., NULL encryption for IKE, which always requires encryption; or
combined mode algorithms, a new feature in IPsec-v3, for use with
IPsec-v2).
This document categorizes the requirements level of each algorithm
for IKEv1, IKEv2, IPsec-v2 and IPsec-v3. If an algorithm is
recommended for use within IKEv1 or IKEv2, it is used either to
protect the IKE SA's traffic (encryption and integrity-protection
algorithms) or to generate keying material (Diffie-Hellman or DH
groups, Pseudo-Random Functions or PRFs). If an algorithm is
recommended for use within IPsec, it is used to protect the
IPsec/child SA's traffic, and IKE is capable of negotiating its use
for that purpose. These requirements are summarized in Appendix B.
5.1. Algorithm Requirements
Specifying a core set of mandatory algorithms for each protocol
facilitates interoperability. Defining those algorithms in an RFC
separate from the base protocol RFC enhances algorithm agility.
IPsec-v3 and IKEv2 each have an RFC that specifies their
mandatory-to-implement (MUST), recommended (SHOULD), optional (MAY),
and deprecated (SHOULD NOT) algorithms. For IPsec-v2, this is
included in the base protocol RFC. That was originally the case for
IKEv1, but IKEv1's algorithm requirements were updated in [RFC4109].
5.1.1. RFC 4835, Cryptographic Algorithm Implementation Requirements
for Encapsulating Security Payload (ESP) and Authentication Header
(AH) (S, Apr. 2007)
[RFC4835] specifies the encryption and integrity-protection
algorithms for IPsec (both versions). Algorithms for IPsec-v2 were
originally defined in [RFC2402] and [RFC2406]. [RFC4305] obsoleted
those requirements, and was in turn obsoleted by [RFC4835].
Therefore, [RFC4835] applies to IPsec-v2 as well as IPsec-v3.
Combined mode algorithms are mentioned, but not assigned a
requirement level.
Frankel & Krishnan Expires August 2010 [Page 23]
Internet Draft IPsec/IKE Roadmap February 4, 2010
Requirements levels for RFC4835:
IPsec-v2 - MUST
IPsec-v3 - MUST
5.1.2. RFC 4307, Cryptographic Algorithms for Use in the Internet Key
Exchange Version 2 (IKEv2) (S, Dec. 2005)
[RFC4307] specifies the encryption and integrity-protection
algorithms used by IKEv2 to protect its own traffic; the
Diffie-Hellman (DH) groups used within IKEv2; and the pseudo-random
functions used by IKEv2 to generate keys, nonces and other random
values.
Requirements levels for RFC4307:
IKEv1 - N/A
IKEv2 - MUST
5.1.3. RFC 4109, Algorithms for Internet Key Exchange version 1 (IKEv1)
(S, May 2005)
[RFC4109] updates IKEv1's algorithm specifications, which were
originally defined in [RFC2409]. It specifies the encryption and
integrity-protection algorithms used by IKEv1 to protect its own
traffic; the Diffie-Hellman (DH) groups used within IKEv1; the hash
and pseudo-random functions used by IKEv1 to generate keys, nonces
and other random values; and the authentication methods and
algorithms used by IKEv1 for peer authentication.
Requirements levels for RFC4109:
IKEv1 - MUST
IKEv2 - N/A
5.2. Encryption Algorithms
The encryption algorithm RFCs describe how to use these algorithms to
encrypt IKE and/or ESP traffic, providing confidentiality protection
to the traffic. They describe any special constraints, requirements,
or changes to packet format appropriate for the specific algorithm.
In general, they do not describe the detailed algorithmic
computations; the reference section of each RFC includes pointers to
documents that define the inner workings of the algorithm. Some of
the RFCs include sample test data, to enable implementors to compare
their results with standardized output.
When any encryption algorithm is used to provide confidentiality, the
use of integrity-protection is strongly recommended. If the
encryption algorithm is a stream cipher, omitting
Frankel & Krishnan Expires August 2010 [Page 24]
Internet Draft IPsec/IKE Roadmap February 4, 2010
integrity-protection seriously compromises the security properties of
the algorithm.
DES, as described in [RFC2405], was originally a required algorithm
for IKEv1 and ESP-v2. Since the use of DES is now deprecated, this
roadmap does not include [RFC2405].
5.2.1. RFC 2410, The NULL Encryption Algorithm and Its Use With IPsec
(S, Nov. 1998)
[RFC2410] is a tongue-in-cheek description of the no-op encryption
algorithm (i.e. using ESP without encryption). In order for IKE to
negotiate the selection of the NULL encryption algorithm for use in
an ESP SA, an identifying IANA number is needed. This number (the
value 11 for ESP_NULL) is found on the IANA registries for both IKEv1
and IKEv2, but it is not mentioned in this RFC.
Requirements levels for ESP-NULL:
IKEv1 - N/A
IKEv2 - N/A
ESP-v2 - MUST [RFC4835]
ESP-v3 - MUST [RFC4835]
NOTE: RFC 4307 erroneously classifies ESP-NULL as MAY for IKEv2.
5.2.2. RFC 2451, The ESP CBC-Mode Cipher Algorithms (S, Nov. 1998)
[RFC2451] describes how to use encryption algorithms in cipher block
chaining (CBC) mode to encrypt IKE and ESP traffic. It specifically
mentions Blowfish, CAST-128, Triple DES (3DES), IDEA and RC5, but it
is applicable to any block cipher algorithm used in CBC mode. The
algorithms mentioned in the RFC all have a 64-bit blocksize and a
64-bit random IV that is sent in the packet along with the encrypted
data.
Requirements levels for 3DES-CBC:
IKEv1 - MUST [RFC4109]
IKEv2 - MUST- [RFC4307]
ESP-v2 - MUST [RFC4835]
ESP-v3 - MUST- [RFC4835]
Requirements levels for other CBC algorithms (Blowfish, CAST, IDEA,
RC5):
IKEv1 - optional
IKEv2 - optional
ESP-v2 - optional
ESP-v3 - optional
Frankel & Krishnan Expires August 2010 [Page 25]
Internet Draft IPsec/IKE Roadmap February 4, 2010
5.2.3. RFC 3602, The AES-CBC Cipher Algorithm and Its Use with IPsec
(S, Sep. 2003)
[RFC3602] describes how to use AES in cipher block chaining (CBC)
mode to encrypt IKE and ESP traffic. AES is the successor to DES.
AES-CBC is a 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 and 256 bits. 128-bit keys are MUST; the other
sizes are MAY. [RFC3602] includes IANA values for use in IKEv1 and
ESP-v2. A single IANA value is defined for AES-CBC, so IKE
negotiations need to specify the keysize.
Requirements levels for AES-CBC with 128-bit keys:
IKEv1 - SHOULD [RFC4109]
IKEv2 - SHOULD+ [RFC4307]
ESP-v2 - MUST [RFC4835]
ESP-v3 - MUST [RFC4835]
Requirements levels for AES-CBC with 192- or 256-bit keys:
IKEv1 - optional
IKEv2 - optional
ESP-v2 - optional
ESP-v3 - optional
5.2.4. RFC 3686, Using Advanced Encryption Standard (AES) Counter Mode
With IPsec Encapsulating Security Payload (ESP) (S, Jan. 2004)
[RFC3686] describes how to use AES in counter (CTR) mode to encrypt
ESP traffic. AES-CTR is a stream cipher with a 32-bit random nonce
(1/SA) and a 64-bit IV. 128-bit keys are MUST; 192- and 256-byte
keys are MAY. Reuse of the IV with the same key and nonce
compromises the data's security; thus, AES-CTR should not be used
with manual keying. AES-CTR can be pipelined and parallelized; it
uses only the AES encryption operations for both encryption and
decryption.
Requirements levels for AES-CTR:
IKEv1 - undefined (no IANA #)
IKEv2 - optional [draft-ietf-ipsecme-aes-ctr-ikev2]
ESP-v2 - SHOULD [RFC4835]
ESP-v3 - SHOULD [RFC4835]
5.2.5. draft-ietf-ipsecme-aes-ctr-ikev2, Using Advanced Encryption
Standard (AES) Counter Mode with IKEv2 (S)
[ipsecme-5] extends [RFC3686] to enable the use of AES-CTR to provide
encryption and integrity-protection for IKEv2 messages.
5.2.6. RFC 4312, The Camellia Cipher Algorithm and Its Use with IPsec
Frankel & Krishnan Expires August 2010 [Page 26]
Internet Draft IPsec/IKE Roadmap February 4, 2010
(S, Dec. 2005)
[RFC4312] describes how to use Camellia in cipher block chaining
(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
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.
[RFC4312] includes IANA values for use in IKEv1 and IPsec-v2. A
single IANA value is defined for Camellia-CBC, so IKEv1 negotiations
need to specify the keysize.
5.2.7. RFC 5529, Modes of Operation for Camellia for Use with IPsec (S,
Apr. 2009)
[RFC5529] describes the use of the Camellia block cipher algorithm in
conjunction with several different modes of operation. It describes
the use of Camellia in Cipher Block Chaining (CBC) mode and Counter
(CTR) mode as an encryption algorithm within ESP. It also describes
the use of Camellia in Counter with CBC-MAC (CCM) mode as a combined
mode algorithm in ESP. This document defines how to use IKEv2 to
generate keying material for a Camellia ESP SA; it does not define
how to use Camellia within IKEv2 to protect an IKEv2 SA's traffic.
However, this RFC, in conjunction with IKEv2's generalized
description of block mode encryption, provide enough detail to allow
the use of Camellia-CBC algorithms within IKEv2. All three modes can
use keys of length 128-bits, 192-bits or 256-bits. [RFC5529] includes
IANA values for use in IKEv2 and IPsec-v3. A single IANA value is
defined for each Camellia mode, so IKEv2 negotiations need to specify
the keysize.
Requirements levels for Camellia-CBC:
IKEv1 - optional
IKEv2 - optional
ESP-v2 - optional
ESP-v3 - optional
Requirements levels for Camellia-CTR:
IKEv1 - undefined (no IANA #)
IKEv2 - undefined (no RFC)
ESP-v2 - undefined (no IANA #)
ESP-v3 - optional
Requirements levels for Camellia-CCM:
IKEv1 - N/A
IKEv2 - undefined (no RFC)
ESP-v2 - N/A
ESP-v3 - optional
Frankel & Krishnan Expires August 2010 [Page 27]
Internet Draft IPsec/IKE Roadmap February 4, 2010
5.2.8. RFC 4196, The SEED Cipher Algorithm and Its Use with IPsec (S,
Oct. 2005)
[RFC4196] describes how to use SEED in cipher block chaining (CBC)
mode to encrypt ESP traffic. It describes how to use IKEv1 to
negotiate a SEED ESP SA, but does not define the use of SEED to
protect IKEv1 traffic. SEED-CBC is a block-mode cipher with a
128-bit blocksize; a random IV that is sent in the packet along with
the encrypted data; and a keysizes of 128 bits. [RFC4196] includes
IANA values for use in IKEv1 and IPsec-v2. [RFC4196] includes test
data.
Requirements levels for SEED-CBC:
IKEv1 - undefined (no IANA #)
IKEv2 - undefined (no IANA #)
ESP-v2 - optional
ESP-v3 - undefined (no IANA #)
5.3. Integrity-Protection (Authentication) Algorithms
The integrity-protection algorithm RFCs describe how to use these
algorithms to authenticate IKE and/or IPsec traffic, providing
integrity protection to the traffic. This protection is provided by
computing an Integrity Check Value (ICV), which is sent in the
packet. The RFCs describe any special constraints, requirements, or
changes to packet format appropriate for the specific algorithm. In
general, they do not describe the detailed algorithmic computations;
the reference section of each RFC includes pointers to documents that
define the inner workings of the algorithm. Some of the RFCs include
sample test data, to enable implementors to compare their results
with standardized output.
Some of these algorithms generate a fixed-length ICV, which is
truncated when it is included in an IPsec-protected packet. For
example, standard HMAC-SHA-1 generates a 160-bit ICV, which is
truncated to 96 bits when it is used to provide integrity-protection
to an ESP or AH packet. The individual RFC descriptions mention those
algorithms that are truncated. When these algorithms are used to
protect IKEv2 SAs, they are also truncated. For IKEv1, HMAC-SHA-1 and
HMAC-MD5 are negotiated by requesting the hash algorithms SHA-1 and
MD5, respectively; these algorithms are not truncated when used to
protect an IKEv1 SA. For HMAC-SHA-1 and HMAC-MD5, the IKEv2 IANA
registry contains values for both the truncated version and the
standard non-truncated version; thus, IKEv2 has the capability to
negotiate either version of the algorithm. However, only the
truncated version is used for IKEv2 SAs and for IPsec SAs. The
non-truncated version is reserved for use by the Fibre Channel
Frankel & Krishnan Expires August 2010 [Page 28]
Internet Draft IPsec/IKE Roadmap February 4, 2010
protocol [RFC4595]. For the other algorithms (AES-XCBC,
HMAC-SHA-256/384/512, AES-CMAC and HMAC-RIPEMD), only the truncated
version can be used for both IKEv2 and IPsec-v3 SAs.
One other algorithm, AES-GMAC [RFC4543], can also provide
integrity-protection. It has two versions: an integrity-protection
algorithm for use within AH-v3, and a combined mode algorithm with
null encryption for use within ESP-v3. [RFC4543] is described in
Section 5.4, Combined Mode Algorithms.
5.3.1. RFC 2404, The Use of HMAC-SHA-1-96 within ESP and AH (S, Nov.
1998)
[RFC2404] describes HMAC-SHA-1, an integrity-protection algorithm
with a 512-bit blocksize, and a 160-bit key and Integrity Check Value
(ICV). For use within IPsec, the ICV is truncated to 96 bits. This
is currently the most commonly-used integrity-protection algorithm.
Requirements levels for HMAC-SHA-1:
IKEv1 - MUST [RFC4109]
IKEv2 - MUST [RFC4307]
IPsec-v2 - MUST [RFC4835]
IPsec-v3 - MUST [RFC4835]
5.3.2. RFC 3566, The AES-XCBC-MAC-96 Algorithm and Its Use With IPsec
(S, Sep. 2003)
[RFC3566] describes AES-XCBC-MAC, a variant of CBC-MAC which is
secure for messages of varying lengths (unlike classic CBC-MAC). It
is an integrity-protection algorithm with a 128-bit blocksize, and a
128-bit key and ICV. For use within IPsec, the ICV is truncated to
96 bits. [RFC3566] includes test data.
Requirements levels for AES-XCBC-MAC:
IKEv1 - undefined (no RFC)
IKEv2 - optional
IPsec-v2 - SHOULD+ [RFC4835]
IPsec-v3 - SHOULD+ [RFC4835]
5.3.3. RFC 4868, Using HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512
with IPsec (S, May 2007)
[RFC4868] describes a family of algorithms, successors to HMAC-SHA-1.
HMAC-SHA-256 has a 512-bit blocksize, and a 256-bit key and ICV.
HMAC-SHA-384 has a 1024-bit blocksize, and a 384-bit key and ICV.
HMAC-SHA-512 has a 1024-bit blocksize, and a 512-bit key and ICV.
For use within IKE and IPsec, the ICV is truncated to half its
original size (128 bits, 192 bits, or 256 bits). Each of the three
Frankel & Krishnan Expires August 2010 [Page 29]
Internet Draft IPsec/IKE Roadmap February 4, 2010
algorithms has its own IANA value, so IKE does not have to negotiate
the keysize.
Requirements levels for HMAC-SHA-256, HMAC-SHA-384, HMAC-SHA-512:
IKEv1 - optional
IKEv2 - optional
IPsec-v2 - optional
IPsec-v3 - optional
5.3.4. RFC 2403, The Use of HMAC-MD5-96 within ESP and AH (S, Nov.
1998)
[RFC2403] describes HMAC-MD5, an integrity-protection algorithm with
a 512-bit blocksize, and a 128-bit key and Integrity Check Value
(ICV). For use within IPsec, the ICV is truncated to 96 bits. It
was a required algorithm for IKEv1 and IPsec-v2. The use of plain
MD5 is now deprecated, but [RFC4835] states: "Weaknesses have become
apparent in MD5; however, these should not affect the use of MD5 with
HMAC."
Requirements levels for HMAC-MD5:
IKEv1 - MAY [RFC4109]
IKEv2 - optional [RFC4307]
IPsec-v2 - MAY [RFC4835]
IPsec-v3 - MAY [RFC4835]
5.3.5. RFC 4494, The AES-CMAC-96 Algorithm and Its Use with IPsec (S,
Jun. 2006)
[RFC4494] describes AES-CMAC, another variant of CBC-MAC which is
secure for messages of varying lengths. It is an
integrity-protection algorithm with a 128-bit blocksize, and 128-bit
key and ICV. For use within IPsec, the ICV is truncated to 96 bits.
[RFC4494] includes test data.
Requirements levels for AES-CMAC:
IKEv1 - undefined (no IANA #)
IKEv2 - optional
IPsec-v2 - undefined (no IANA #)
IPsec-v3 - optional
5.3.6. RFC 2857, The Use of HMAC-RIPEMD-160-96 within ESP and AH (S,
Jun. 2000)
[RFC2857] describes HMAC-RIPEMD, an integrity-protection algorithm
with a 512-bit blocksize, and a 160-bit key and ICV. For use within
IPsec, the ICV is truncated to 96 bits.
Frankel & Krishnan Expires August 2010 [Page 30]
Internet Draft IPsec/IKE Roadmap February 4, 2010
Requirements levels for HMAC-RIPEMD:
IKEv1 - undefined (no IANA #)
IKEv2 - undefined (no IANA #)
IPsec-v2 - optional
IPsec-v3 - undefined (no IANA #)
5.3.7. RFC 4894, Use of Hash Algorithms in Internet Key Exchange (IKE)
and IPsec (I, May 2007)
In light of recent attacks on MD5 and SHA-1, [RFC4894] examines
whether it is necessary to replace the hash functions currently used
by IKE and IPsec for key generation, integrity-protection, digital
signatures, or PKIX certificates. It concludes that the algorithms
recommended for IKEv2 [RFC4307] and IPsec-v3 [RFC4305] are not
currently susceptible to any known attacks. Nonetheless, it suggests
that implementors add support for AES-XCBC-MAC-96 [RFC3566],
AES-XCBC-PRF-128 [RFC4434] and HMAC-SHA-256, -384, and -512 [RFC4868]
for future use. It also suggests that IKEv2 implementors add support
for PKIX certificates signed with SHA-256, -384, and -512.
5.4. Combined Mode Algorithms
IKEv1 and ESP-v2 use separate algorithms to provide encryption and
integrity-protection, and IKEv1 can negotiate different combinations
of algorithms for different SAs. In ESP-v3, a new class of
algorithms was introduced, in which a single algorithm can provide
both encryption and integrity-protection. [RFC4306] describes how
IKEv2 can negotiate combined mode algorithms to be used in ESP-v3
SAs. [RFC5282] adds that capability to IKEv2, enabling IKEv2 to
negotiate and use combined mode algorithms for its own traffic. When
properly designed, these algorithms can provide increased efficiency
in both implementation and execution.
Some IKEv1 implementations have added the capability to negotiate
combined mode algorithms for use in IPsec SAs; these implementations
do not include the capability to use combined mode algorithms to
protect IKE SAs. Since combined mode algorithms are not a feature of
IPsec-v2, these IKEv1 implementations are used in conjunction with
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
IPsec Encapsulating Security Payload (ESP) (S, Dec. 2005)
[RFC4309] describes how to use AES in Counter with CBC-MAC (CCM)
mode, a combined alorithm, to encrypt and integrity-protect ESP-v3
traffic. AES-CCM is a block-mode cipher with a 128-bit blocksize; a
Frankel & Krishnan Expires August 2010 [Page 31]
Internet Draft IPsec/IKE Roadmap February 4, 2010
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
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
salt value is generated by IKEv2 during the key generation process.
Reuse of the IV with the same key compromises the data's security;
thus, AES-CCM should not be used with manual keying. [RFC4309]
includes IANA values for use in ESP-v3. Each of the three ICV
lengths has its own IANA value, but IKEv2 negotiations need to
specify the keysize. [RFC4309] includes test data. [RFC4309]
describes how IKEv2 can negotiate the use of AES-CCM to use in an
ESP-v3 SA. [RFC5282] extends this to the use of AES-CCM to protect
an IKEv2 SA.
Requirements levels for AES-CCM:
IKEv1 - N/A
IKEv2 - optional
ESP-v2 - N/A
ESP-v3 - optional [RFC4835]
NOTE: The IPsec-v2 IANA registry includes values for AES-CCM, but
combined mode algorithms are not a feature of IPsec-v2.
5.4.2. RFC 4106, The Use of Galois/Counter Mode (GCM) in IPsec
Encapsulating Security Payload (ESP) (S, Jun. 2005)
[RFC4106] describes how to use AES in Galois/Counter (GCM) mode, a
combined alorithm, to encrypt and integrity-protect ESP-v3 traffic.
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
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
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.
Reuse of the IV with the same key compromises the data's security;
thus, AES-GCM should not be used with manual keying. [RFC4106]
includes IANA values for use in ESP-v3. Each of the three ICV
lengths has its own IANA value, but IKEv2 negotiations need to
specify the keysize. [RFC4106] includes test data. [RFC4106]
describes how IKEv2 can negotiate the use of AES-GCM to use in an
ESP-v3 SA. [RFC5282] extends this to the use of AES-GCM to protect
an IKEv2 SA.
Requirements levels for AES-GCM:
IKEv1 - N/A
IKEv2 - optional
ESP-v2 - N/A
ESP-v3 - optional [RFC4835]
Frankel & Krishnan Expires August 2010 [Page 32]
Internet Draft IPsec/IKE Roadmap February 4, 2010
NOTE: The IPsec-v2 IANA registry includes values for AES-GCM, but
combined mode algorithms are not a feature of IPsec-v2.
5.4.3. RFC 4543, The Use of Galois Message Authentication Code (GMAC)
in IPsec ESP and AH (S, May 2006)
[RFC4543] is the variant of AES-GCM [RFC4106] that provides
integrity-protection without encryption. It has two versions: an
integrity-protection algorithm for use within AH-v3, and a combined
mode algorithm with null encryption for use within ESP-v3. It can
use a key of 128-, 192-, or 256-bits; the ICV is always 128 bits, and
is not truncated. AES-GMAC uses a nonce, consisting of a 64-bit IV
and a 32-bit salt (1/SA). The salt value is generated by IKEv2
during the key generation process. Reuse of the salt value with the
same key compromises the data's security; thus, AES-GMAC should not
be used with manual keying. For use within AH-v3, each keysize has
its own IANA value, so IKEv2 does not have to negotiate the keysize.
For use within ESP-v3, there is only one IANA value, so IKEv2
negotiations must specify the keysize. AES-GMAC cannot be used by
IKEv2 to protect its own SAs, since IKEv2 traffic requires
encryption.
Requirements levels for AES-GMAC:
IKEv1 - N/A
IKEv2 - N/A
IPsec-v2 - undefined (no IANA #)
IPsec-v3 - optional
5.4.4. RFC 5282, Using Authenticated Encryption Algorithms with the
Encrypted Payload of the Internet Key Exchange version 2 (IKEv2)
Protocol (S, Aug. 2008)
[RFC5282] extends [RFC4309] and [RFC4106] to enable the use of
AES-CCM and AES-GCM to provide encryption and integrity-protection
for IKEv2 messages.
Requirements levels for RFC5282:
IKEv1 - N/A
IKEv2 - optional
5.5. Pseudo-Random Functions (PRFs)
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
same algorithms used for integrity-protection, but their output is
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
required number of bits of keying material, the PRF is applied
Frankel & Krishnan Expires August 2010 [Page 33]
Internet Draft IPsec/IKE Roadmap February 4, 2010
iteratively until the requisite amount of keying material is
generated.
For each IKEv2 SA, the peers negotiate both a PRF algorithm and an
integrity-protection algorithm; the former is used to generate keying
material and other values, and the latter is used to provide
protection to the IKE SA's traffic.
IKEv1's approach is more complicated. IKEv1 [RFC2409] does not
specify any PRF algorithms. For each IKEv1 SA, the peers agree on an
unkeyed hash function (e.g., SHA-1). IKEv1 uses the HMAC version of
this function to generate keying material and to provide integrity
protection for the IKE SA. Therefore PRFs that are not HMACs cannot
currently be used in IKEv1.
Requirements levels for PRF-HMAC-SHA1:
IKEv1 - MUST [RFC4109]
IKEv2 - MUST [RFC4307]
Requirements levels for PRF-HMAC-SHA-256, PRF-HMAC-SHA-384,
PRF-HMAC-SHA-512:
IKEv1 - optional [RFC4868]
IKEv2 - optional [RFC4868]
5.5.1. RFC 4434, The AES-XCBC-PRF-128 Algorithm for the Internet Key
Exchange Protocol (IKE) (S, Feb. 2006)
[RFC3566] defines AES-XCBC-MAC-96, which is used for integrity
protection within IKE and IPsec. [RFC4434] enables the use of
AES-XCBC-MAC as a PRF within IKE. The PRF differs from the
integrity-protection algorithm in two ways: its 128-bit output is not
truncated to 96 bits; and it accepts a variable-length key, which is
modified (lengthened via padding or shortened through application of
AES-XCBC) to a 128-bit key. [RFC4434] includes test data.
Requirements levels for AES-XCBC-PRF:
IKEv1 - undefined (no RFC)
IKEv2 - SHOULD+ [RFC4307]
NOTE: RFC 4109 erroneously classifies AES-XCBC-PRF as SHOULD for
IKEv1.
5.5.2. RFC 4615, The Advanced Encryption Standard-Cipher-based Message
Authentication Code-Pseudo-Random Function-128 (AES-CMAC-PRF-128)
Algorithm for the Internet Key Exchange Protocol (IKE) (S, Aug. 2006)
[RFC4615] extends [RFC4494] to enable the use of AES-CMAC as a PRF
within IKEv2, in a manner analogous to that used by [RFC4434] for
Frankel & Krishnan Expires August 2010 [Page 34]
Internet Draft IPsec/IKE Roadmap February 4, 2010
AES-XCBC.
Requirements levels for AES-CMAC-PRF:
IKEv1 - undefined (no IANA #)
IKEv2 - optional
5.6. Cryptographic Suites
5.6.1. RFC 4308, Cryptographic Suites for IPsec (S, Dec. 2005)
An IKE negotiation consists of multiple cryptographic attributes,
both for the IKE SA and for the IPsec SA. The number of possible
combinations can pose a challenge to peers trying to find a common
policy. To enhance interoperability, [RFC4308] defines two
pre-defined suites, consisting of combinations of algorithms that
comprise typical security policies. IKE/ESP suite "VPN-A" includes
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
MODP DH. These suites are intended to be named "single-button"
choices in the administrative interface, but do not prevent the use
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)
[RFC4869] adds 4 pre-defined suites, based upon the United States
National Security Agency's "Suite B" specifications, to those
specified in [RFC4308]. IKE/ESP-v3 suites "Suite-B-GCM-128" and
"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.
IKE/AH-v3 suites "Suite-B-GMAC-128" and "Suite-B-GMAC-256" include
use of AES-CBC, AES-GMAC, HMAC-SHA-256 or HMAC-SHA-384, and 256-bit
or 384-bit EC DH groups. While [RFC4308] does not specify a peer
authentication method, [RFC4869] mandates pre-shared key
authentication for IKEv1; public key authentication using ECDSA is
recommended for IKEv1 and required for IKEv2.
Requirements levels for RFC4869:
IKEv1 - optional
IKEv2 - optional
ESP-v2 - N/A
ESP-v3 - optional
Frankel & Krishnan Expires August 2010 [Page 35]
Internet Draft IPsec/IKE Roadmap February 4, 2010
5.7. Diffie-Hellman Algorithms
IKE negotiations include a Diffie-Hellman exchange, which establishes
a shared secret, to which both parties contributed. This value is
used to generate keying material to protect both the IKE SA and the
IPsec SA.
IKEv1 [RFC2409] contains definitions of 2 DH MODP groups and 2
elliptic curve (EC) groups; IKEv2 [RFC4306] only references the MODP
groups. The requirements levels of these groups are:
Requirements levels for DH MODP group 1:
IKEv1 - MAY [RFC4109]
IKEv2 - optional
Requirements levels for DH MODP group 2:
IKEv1 - MUST [RFC4109]
IKEv2 - MUST- [RFC4307]
Requirements levels for EC groups 3-4:
IKEv1 - MAY [RFC4109]
IKEv2 - undefined (no IANA #)
5.7.1. RFC 3526, More Modular Exponential (MODP) Diffie-Hellman groups
for Internet Key Exchange (IKE) (S, May 2003)
[RFC2409] and [RFC4306] define 2 MODP DH groups (groups 1 and 2) for
use within IKE. [RFC3526] adds six more groups (groups 5 and 14-18).
Group 14 is a 2048-bit group that is strongly recommended for use in
IKE.
Requirements levels for DH MODP group 14:
IKEv1 - SHOULD [RFC4109]
IKEv2 - SHOULD+ [RFC4307]
Requirements levels for DH MODP groups 5, 15-18:
IKEv1 - optional [RFC4109]
IKEv2 - optional
5.7.2. RFC 4753, ECP Groups For IKE and IKEv2 (I, Jan. 2007)
[RFC4753] defines 3 EC DH groups (groups 19-21) for use within IKE.
The document includes test data.
Requirements levels for DH EC groups 19-21:
IKEv1 - optional [RFC4109]
IKEv2 - optional
Frankel & Krishnan Expires August 2010 [Page 36]
Internet Draft IPsec/IKE Roadmap February 4, 2010
5.7.3. draft-solinas-rfc4753bis, ECP Groups for IKE and IKEv2 (I)
[ecp-ike1] obsoletes RFC4753, fixing an inconsistency in the DH
shared secret value.
5.7.4. RFC 5114, Additional Diffie-Hellman Groups for Use with IETF
Standards (I, Jan. 2008)
[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 19-21) that were previously defined in [RFC4753]. The IANA
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
Certificates.
Requirements levels for DH MODP groups 22-24, EC groups 25-26:
IKEv1 - optional
IKEv2 - optional
6. IPsec/IKE for Multicast
[RFC4301] describes IPsec processing for unicast and multicast
traffic. However, classical IPsec SAs provide point-to-point
protection; the security afforded by IPsec's cryptographic algorithms
is not applicable when the SA is one-to-many or many-to-many, the
case for multicast. The Multicast Security (msec) Working Group has
defined alternatives to IKE and extensions to IPsec for use with
multicast traffic. Different multicast groups have differing
characteristics and requirements: number of senders (one-to-many or
many-to-many), number of members (few, moderate, very large),
volatility of membership, real-time delivery, etc. Their security
requirements vary as well. Each solution defined by msec applies to
a subset of the large variety of possible multicast groups.
6.1. RFC 3740, The Multicast Group Security Architecture (I, Mar. 2004)
[RFC3740] defines the multicast security architecture, which is used
to provide security for packets exchanged by large multicast groups.
It defines the components of the architectural framework; discusses
Group Security Associations (GSAs), key management, data handling and
security policies. Several existing protocols, including GDOI
[RFC3547], GSAKMP [RFC4535] and MIKEY [RFC3830], satisfy the group
key management requirements defined in this document.
6.2. RFC 5374, Multicast Extensions to the Security Architecture for
the Internet Protocol (S, Nov. 2008)
Frankel & Krishnan Expires August 2010 [Page 37]
Internet Draft IPsec/IKE Roadmap February 4, 2010
[RFC5374] extends the security architecture defined in [RFC4301] to
apply to multicast traffic. It defines a new class of SAs (GSAs -
Group Security Associations) and additional databases used to apply
IPsec protection to multicast traffic. It also describes revisions
and additions to the processing algorithms in [RFC4301].
6.3. RFC 3547, The Group Domain of Interpretation (S, Jul. 2003)
GDOI [RFC3547] extends IKEv1 so that it can be used to establish SAs
to protect multicast traffic. This document defines additional
exchanges and payloads to be used for that purpose.
6.4. RFC 4046, Multicast Security (MSEC) Group Key Management
Architecture (I, Apr. 2005)
[RFC4046] sets out the general requirements and design principles for
protocols that are used for multicast key management. It does not go
into the specifics of an individual protocol that can be used for
that purposel
6.5. RFC 4535, GSAKMP: Group Secure Association Key Management Protocol
(S, Jun. 2006)
[RFC4535] defines a protocol that can be used to generate, distribute
and manage keys to be used for secure group communications. GSAKMP
is also used to distribute and enforce group security policies. It
can be used to facilitate many-to-many communications and distributed
architectures.
6.6. RFC 4534, Group Security Policy Token v1 (S, Jun. 2006)
[RFC4534] specifies the structure of the Group Security Policy Token,
"a structure used to specify the security policy and configurable
parameters for a cryptographic group, such as a secure multicast
group." This token can be used within GSAKMP to define and enforce
group polices such as secure access control.
6.7. RFC 3830, MIKEY: Multimedia Internet KEYing (S, Aug. 2004)
MIKEY [RFC3830] is a key management protocol, an alternative to GDOI
[RFC3547] and GSAKMP [RFC4535], that is well-suited for use in
real-time, low-latency secure multimedia scenarios.
6.8. RFC 4738, MIKEY-RSA-R: An Additional Mode of Key Distribution in
Multimedia Internet KEYing (MIKEY) (S, Nov. 2006)
[RFC4738] adds an additional key distribution method to MIKEY:
MIKEY-RSA-R, reverse-mode RSA.
Frankel & Krishnan Expires August 2010 [Page 38]
Internet Draft IPsec/IKE Roadmap February 4, 2010
6.9. RFC 5197, On the Applicability of Various Multimedia Internet
KEYing (MIKEY) Modes and Extensions (I, Jun. 2008)
[RFC5197] provides an in-depth, integrated description of MIKEY modes
and extensions. It also includes sample real-world use cases.
6.10. RFC 4563, The Key ID Information Type for the General Extension
Payload in Multimedia Internet KEYing (MIKEY) (S, Jun. 2006)
[RFC4563] defines a MIKEY extension that satisfies the need for
frequent, efficient key update in the 3GPP environment.
6.11. RFC 4359, The Use of RSA/SHA-1 Signatures within Encapsulating
Security Payload (ESP) and Authentication Header (AH) (S, Jan. 2006)
[RFC4359] describes the use of the RSA digital signature algorithm to
provide integrity-protection for multicast traffic within ESP and AH.
The algorithms used for integrity-protection for unicast traffic
(e.g., HMAC) are not suitable for this purpose when used with
multicast traffic.
6.12. RFC 4650, HMAC-Authenticated Diffie-Hellman for Multimedia
Internet KEYing (MIKEY) (S, Sep. 2006)
[RFC4650] "describes a lightweight point-to-point key management
protocol variant for the multimedia Internet keying (MIKEY) project."
6.13. RFC 5410, Multimedia Internet KEYing (MIKEY) General Extension
Payload for Open Mobile Alliance BCAST 1.0 (I, Jan. 2009)
[RFC5410] describes one use of the General Extension Payload, defined
as part of the base MIKEY [RFC3830] protocol. This document
specifies a payload that can be used to transport keying material or
management data that is defined in the Open Mobile Alliance's (OMA)
Broadcast (BCAST) group's Service and Content protection
specification.
6.14. RFC 4082, Timed Efficient Stream Loss-Tolerant Authentication
(TESLA): Multicast Source Authentication Transform Introduction (I,
Jun. 2005)
TESLA [RFC4082] is a scheme that provides source authentication and
integrity-protection to receivers of multicast traffic. Symmetric
algorithms cannot generally be used for this purpose with multicast
traffic; public-key algorithms, which can afford this protection,
require considerably greater overhead. TESLA leverages time
synchronization and delayed key disclosure to provide this protection
via the more efficient symmetric key algorithms. It can be used in
Frankel & Krishnan Expires August 2010 [Page 39]
Internet Draft IPsec/IKE Roadmap February 4, 2010
multicast groups with a very large number of receivers.
6.15. RFC 4442, Bootstrapping Timed Efficient Stream Loss-Tolerant
Authentication (TESLA) (S, Mar. 2006)
[RFC4442] describes MIKEY payloads that can be used to specify TESLA
parameters, thus bootstrapping the use of TESLA within the Secure
Real-time Transport Protocol (SRTP).
6.16. RFC 4383, The Use of Timed Efficient Stream Loss-Tolerant
Authentication (TESLA) in the Secure Real-time Transport Protocol
(SRTP) (S, Feb. 2006)
[RFC4383] describes the use of TESLA within SRTP to protect multicast
and broadcast traffic.
7. Outgrowths of IPsec/IKE
Operational experience with IPsec revealed additional capabilities
that could make IPsec more useful in real-world scenarios. These
include support for payload compression (IPComp), extensions to
facilitate additional peer authentication methods (BTNS, KINK and
IPSECKEY), and additional capabilities for VPN clients (MOBIKE and
IPSRA).
7.1. IPComp (Compression)
The IP Payload Compression Protocol (IPComp) is a protocol that
provides lossless compression for IP datagrams. Although IKE can be
used to negotiate the use of IPComp in conjunction with IPsec, IPComp
can also be used when IPsec is not applied
7.1.1. RFC 3173, IP Payload Compression Protocol (IPComp) (S, Sep.
2001)
IP payload compression is especially useful when IPsec based
encryption is applied to IP datagrams. Encrypting the IP datagram
causes the data to be random in nature, rendering compression at
lower protocol layers ineffective. If IKE is used to negotiate
compression in conjunction with IPsec, compression can be performed
prior to encryption. [RFC3173] defines the payload compression
protocol, the IPComp packet structure, the IPComp Association (IPCA),
and several methods to negotiate the IPCA.
7.1.2. RFC 2394, IP Payload Compression Using DEFLATE (I, Dec. 1998)
The IPComp protocol allows the compression of IP datagrams by
Frankel & Krishnan Expires August 2010 [Page 40]
Internet Draft IPsec/IKE Roadmap February 4, 2010
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
additional capabilities for IPsec VPN users: 1) moving from one
address to another without re-establishing existing SAs and 2) using
multiple interfaces simultaneously. These solutions are limited to
IPsec VPNs; they are not intended to provide more general mobility or
multi-homing capabilities.
7.2.1. 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.2.2. RFC 4555, IKEv2 Mobility and Multihoming Protocol (MOBIKE) (S,
Jun. 2006)
IKEv2 assumes that an IKE SA is created implicitly between the IP
address pair that is used during the protocol execution when
establishing the IKEv2 SA. IPsec related documents had no provision
to change this pair after an IKE SA was created. [RFC4555] defines
extensions to IKEv2 that enable an efficient management of IKE and
IPsec Security Associations when a host possesses multiple IP
addresses and/or where IP addresses of an IPsec host change over
time.
7.2.3. RFC 5266, Secure Connectivity and Mobility Using Mobile IPv4 and
IKEv2 Mobility and Multihoming (MOBIKE) (B, Jun. 2008)
[RFC5266] describes a solution using Mobile IPv4 (MIPv4) and mobility
extensions to IKEv2 (MOBIKE) to provide secure connectivity and
mobility to enterprise users when they roam into untrusted networks.
Frankel & Krishnan Expires August 2010 [Page 41]
Internet Draft IPsec/IKE Roadmap February 4, 2010
7.3. Better-than-Nothing Security (BTNS)
One of the major obstacles to widespread implementation of IPsec is
the lack of pre-existing credentials that can be used for peer
authentication. Better-than-Nothing Security (BTNS) is an attempt to
sidestep this problem by allowing IKE to negotiate unauthenticated
(anonymous) IPsec SAs, using credentials such as self-signed
certificates or "bare" public keys (public keys that are not
connected to a Public Key Certificate) for peer authentication. This
ensures that subsequent traffic protected by the SA is conducted with
the same peer, and protects the communications from passive attack.
These SAs can then be cryptographically bound to a higher-level
application protocol, which performs its own peer authentication.
7.3.1. RFC 5660, IPsec Channels: Connection Latching (S, Oct. 2009)
[RFC5660] specifies, abstractly, how to interface applications and
transport protocols with IPsec so as to create channels by latching
connections (packet flows) to certain IPsec Security Association (SA)
parameters for the lifetime of the connections. Connection latching
is layered on top of IPsec and does not modify the underlying IPsec
architecture.
7.3.2. RFC 5386, Better-Than-Nothing-Security: An Unauthenticated Mode
of IPsec (S, Nov. 2008)
[RFC5386] specifies how to use IKEv2 to setup unauthenticated
security associations (SAs) for use with the IPsec Encapsulating
Security Payload (ESP) and the IPsec Authentication Header (AH).
This document does not require any changes to the bits on the wire,
but specifies extensions to the Peer Authorization Database (PAD) and
Security Policy Database (SPD).
7.3.3. RFC 5387, Problem and Applicability Statement for
Better-Than-Nothing Security (BTNS) (I, Nov. 2008)
[RFC5387] considers that the need to deploy authentication
information and its associated identities is a significant obstacle
to the use of IPsec. This document explains the rationale for
extending the Internet network security protocol suite to enable use
of IPsec security services without authentication.
7.4. Kerberized Internet Negotiation of Keys (KINK)
Kerberized Internet Negotiation of Keys (KINK) is an attempt to
provide an alternative to IKE for IPsec peer authentication. It uses
Kerberos, instead of IKE, to establish IPsec SAs. For enterprises
that already deploy the Kerberos centralized key management system,
Frankel & Krishnan Expires August 2010 [Page 42]
Internet Draft IPsec/IKE Roadmap February 4, 2010
IPsec can then be implemented without the need for additional peer
credentials.
7.4.1. RFC 3129, Requirements for Kerberized Internet Negotiation of
Keys (I, Jun. 2001)
[RFC3129] considers that peer to peer authentication and keying
mechanisms have inherent drawbacks such as computational complexity
and difficulty in enforcing security policies. This document
specifies the requirements for using basic features of Kerberos and
uses them to its advantage to create a protocol which can establish
and maintain IPsec security associations ([RFC2401]).
7.4.2. RFC 4430, Kerberized Internet Negotiation of Keys (KINK) (S,
Mar. 2006)
[RFC4430] defines a low-latency, computationally inexpensive, easily
managed, and cryptographically sound protocol to establish and
maintain security associations using the Kerberos authentication
system. This document reuses the Quick Mode payloads of IKEv1 in
order to foster substantial reuse of IKEv1 implementations. This RFC
has not been widely adopted.
7.5. IPsec Secure Remote Access (IPSRA)
IPsec Secure Remote Access (IPSRA) was an attempt to extend IPsec
protection to "road warriors," allowing IKE to authenticate not only
the user's device but also the user, without changing IKEv1. The
working group defined generic requirements of different IPsec remote
access scenarios. An attempt was made to define an IKE-like protocol
that would use legacy authentication mechanisms to create a temporary
or short-lived user credential that could be used for peer
authentication within IKE. This protocol proved to be more
cumbersome than standard Public Key protocols, and was abandoned.
This led to the development of IKEv2, which incorporates the use of
EAP for user authentication.
7.5.1. RFC 3457, Requirements for IPsec Remote Access Scenarios (I,
Jan. 2003)
[RFC3457] explores and enumerates the requirements of various IPsec
remote access scenarios, without suggesting particular solutions for
them.
7.5.2. RFC 3456, Dynamic Host Configuration Protocol (DHCPv4)
Configuration of IPsec Tunnel Mode (S, Jan. 2003)
[RFC3456] explores the requirements for host configuration in IPsec
Frankel & Krishnan Expires August 2010 [Page 43]
Internet Draft IPsec/IKE Roadmap February 4, 2010
tunnel mode, and describes how the Dynamic Host Configuration
Protocol (DHCPv4) may be used for providing such configuration
information. This RFC has not been widely adopted.
7.6. IPsec Keying Information Resource Record (IPSECKEY)
The IPsec Keying Information Resource Record (IPSECKEY) enables the
storage of public keys and other information that can be used to
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,
Feb. 2005)
[RFC4025] describes a method of storing IPsec keying material in the
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.
This RFC has not been widely adopted.
8. Other Protocols that use IPsec/IKE
IPsec and IKE were designed to provide IP-layer security protection
to other Internet protocols' traffic as well as generic
communications. Since IPsec is a general-purpose protocol, in some
cases its features do not provide the granularity or distinctive
features required by another protocol; in some cases, its overhead or
pre-requisites do not match another protocol's requirements.
However, a number of other protocols do use IKE and/or IPsec to
protect some or all of their communications.
8.1. Mobile IP (MIPv4 and MIPv6)
8.1.1. RFC 4093, Problem Statement: Mobile IPv4 Traversal of Virtual
Private Network (VPN) Gateways (I, Aug. 2005)
[RFC4093] describes the issues with deploying Mobile IPv4 across
virtual private networks (VPNs). IPsec is one of the VPN
technologies covered by this document. It identifes and describes
practical deployment scenarios for Mobile IPv4 running alongside
IPsec in enterprise and operator environments. It also specifies a
set of framework guidelines to evaluate proposed solutions for
supporting multi-vendor seamless IPv4 mobility across IPsec-based VPN
gateways.
8.1.2. RFC 5265, Mobile IPv4 Traversal across IPsec-Based VPN Gateways
(S, Jun. 2008)
[RFC5265] describes a basic solution that uses Mobile IPv4 and IPsec
to provide session mobility between enterprise intranets and external
Frankel & Krishnan Expires August 2010 [Page 44]
Internet Draft IPsec/IKE Roadmap February 4, 2010
networks. The proposed solution minimizes changes to existing
firewall/VPN/DMZ deployments and does not require any changes to
IPsec or key exchange protocols. It also proposes a mechanism to
minimize IPsec renegotiation when the mobile node moves.
8.1.3. RFC 3776, Using IPsec to Protect Mobile IPv6 Signaling Between
Mobile Nodes and Home Agents (S, Jun. 2004)
This document illustrates the use of IPsec in securing Mobile IPv6
traffic between mobile nodes and home agents. It specifies the
required wire formats for the protected packets and illustrates
examples of Security Policy Database and Security Association
Database entries that can be used to protect Mobile IPv6 signaling
messages. It also describes how to configure either manually keyed
IPsec security associations or how to configure IKEv1 to establish
the SAs automatically.
8.1.4. RFC 4877, Mobile IPv6 Operation with IKEv2 and the Revised IPsec
Architecture (S, Apr. 2007)
This document updates [RFC3776] in order to work with the revised
IPsec architecture [RFC4301]. Since the revised IPsec architecture
expands the list of selectors to include the Mobility Header message
type, it becomes much easier to differentiate between different
mobility header messages. Since the ICMP message type and code are
also newly added as selectors, this document uses them to protect
Mobile Prefix Discovery messages. 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)
[RFC5213] describes a network-based mobility management protocol that
is used to provide mobility services hosts without requiring their
participation in any mobility-related signaling. It uses IPsec to
protect the mobility signaling messages between the two network
entities called the mobile access gateway (MAG) and the local
mobility anchor (LMA). It also uses IKEv2 in order to set up the
security associations between the MAG and the LMA.
8.1.6. RFC 5268, Mobile IPv6 Fast Handovers (S, Jun. 2008)
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
link switching delay and IP protocol operations. [RFC5268] specifies
a protocol between the Previous Access Router (PAR) and the New
Access Router (NAR) to improve handover latency due to Mobile IPv6
procedures. It uses IPsec ESP in transport mode with integrity
protection for protecting the signaling messages between the PAR and
Frankel & Krishnan Expires August 2010 [Page 45]
Internet Draft IPsec/IKE Roadmap February 4, 2010
the NAR. It also describes the SPD entries and the PAD entries when
IKEv2 is used for setting up the required SAs.
8.1.7. RFC 5380, Hierarchical Mobile IPv6 (HMIPv6) Mobility Management
(S, Oct. 2008)
[RFC5380] describes extensions to Mobile IPv6 and IPv6 Neighbour
Discovery to allow for local mobility handling in order to reduce the
amount of signalling between the mobile node, its correspondent
nodes, and its home agent. It also improves handover speed of Mobile
IPv6. It uses IPsec for protecting the signaling between the mobile
node and a local mobility management entity called the Mobility
Anchor Point (MAP). The MAP also uses IPsec Peer Authorization
Database (PAD) entries and configuration payloads described in
[RFC4877] in order to allocate a Regional Care-of Address (RCoA) for
mobile nodes.
8.2. Open Shortest Path First (OSPF)
8.2.1. RFC 4552, Authentication/Confidentiality for OSPFv3 (S, Jun.
2006)
OSPF is a link-state routing protocol that is designed to be run
inside a single Autonomous System. OSPFv2 provided its own
authentication mechanisms using the AuType and Authentication
protocol header fields but OSPFv3 removed these fields and uses IPsec
instead. [RFC4552] describes how to use IPsec ESP and AH in order to
protect OSPFv3 signaling between two routers. It also enumerates the
IPsec capabilities the routers require in order to support this
specification. Finally, it also describes the operation of OSPFv3
with IPsec over virtual links where the other endpoint is not known
at configuration time. Since OSPFv3 exchanges multicast packets as
well as unicast ones, the use of IKE within OSPFv3 is not
appropriate. Therefore, this document mandates the use of manual
keys.
8.3. Host Identity Protocol (HIP)
8.3.1. RFC 5201, Host Identity Protocol (E, Apr. 2008)
IP addresses perform two distinct functions: host identifier and
locator. This document specifies a protocol that allows consenting
hosts to securely establish and maintain shared IP-layer state,
allowing separation of the identifier and locator roles of IP
addresses. This enables continuity of communications across IP
address (locator) changes. It uses public key identifiers from a new
Host Identity (HI) namespace for peer authentication. It uses the
HMAC-SHA-1-96 and the AES-CBC algorithms with IPsec ESP and AH for
Frankel & Krishnan Expires August 2010 [Page 46]
Internet Draft IPsec/IKE Roadmap February 4, 2010
protecting its signaling messages.
8.3.2. RFC 5202, Using the Encapsulating Security Payload (ESP)
Transport Format with the Host Identity Protocol (HIP) (E, Apr. 2008)
The HIP base exchange specification [RFC5201] does not describe any
transport formats or methods for describing how ESP is used to
protect user data to be used during the actual communication.
[RFC5202] specifies a set of HIP protocol extensions for creating a
pair of ESP Security Associations (SAs) between the hosts during the
base exchange. After the HIP association and required ESP SAs have
been established between the hosts, the user data communication is
protected using ESP. In addition, this document specifies how to use
the ESP Security Parameter Index (SPI) is used to indicate the right
host context(host identity) and methods to update an existing ESP
Security Association.
8.3.3. RFC 5206, End-Host Mobility and Multihoming with the Host
Identity (E, Apr. 2008)
When a host uses HIP, the overlying protocol sublayers (e.g.,
transport layer sockets) and Encapsulating Security Payload (ESP)
Security Associations (SAs) are bound to representations of these
host identities, and the IP addresses are only used for packet
forwarding. [RFC5206] defines a generalized LOCATOR parameter for
use in HIP messages that allows a HIP host to notify a peer about
alternate addresses at which it is reachable. It also specifies how
a host can change its IP address and continue to send packets to its
peers without necessarily rekeying.
8.3.4. RFC 5207, NAT and Firewall Traversal Issues of Host Identity
Protocol (HIP) (I, Apr. 2008)
[RFC5207] discusses the problems associated with HIP communication
across network paths that include network address translators and
firewalls. It analyzes the impact of NATs and firewalls on the HIP
base exchange and the ESP data exchange. It discusses possible
changes to HIP that attempt to improve NAT and firewall traversal and
proposes a rendezvous point for letting HIP nodes behind a NAT be
reachable. It also suggests mechanisms for NATs to be more aware of
the HIP messages.
8.4. Extensible Authentication Protocol (EAP) Method Update (EMU)
8.4.1. RFC 5106, The Extensible Authentication Protocol-Internet Key
Exchange Protocol version 2 (EAP-IKEv2) Method (E, Feb. 2008)
[RFC5106] specifies an Extensible Authentication Protocol (EAP)
Frankel & Krishnan Expires August 2010 [Page 47]
Internet Draft IPsec/IKE Roadmap February 4, 2010
method that is based on the Internet Key Exchange (IKEv2) protocol.
EAP-IKEv2 provides mutual authentication and session key
establishment between an EAP peer and an EAP server. It describes
the full EAP-IKEv2 message exchange and the composition of the
protocol messages.
8.5. Stream Control Transmission Protocol (SCTP)
8.5.1. RFC 3554, On the Use of Stream Control Transmission Protocol
(SCTP) with IPsec (S, Jul. 2003)
The Stream Control Transmission Protocol (SCTP) is a reliable
transport protocol operating on top of a connection-less packet
network such as IP. [RFC3554] describes functional requirements for
IPsec and IKE to be used in securing SCTP traffic. It adds support
for SCTP in the form of a new ID type in IKE [RFC2409] and
implementation choices in the IPsec processing to account for the
multiple source and destination addresses associated with a single
SCTP association.
8.6. Fibre Channel
8.6.1. RFC 4595, Use of IKEv2 in the Fibre Channel Security Association
Management Protocol (I, Jul. 2006)
Fibre Channel (FC) is a gigabit-speed network technology used for
Storage Area Networking. The Fibre Channel Security Protocols
standard (FC-SP) has adapted the IKEv2 protocol [RFC4306] to provide
authentication of Fibre Channel entities and setup of security
associations. Since IP is transported over Fibre Channel and Fibre
Channel/SCSI are transported over IP, there is the potential for
confusion when IKEv2 is used for both IP and FC traffic. [RFC4595]
specifies identifiers for IKEv2 over FC in a fashion that ensures
that any mistaken usage of IKEv2/FC over IP or IKEv2/IP over FC will
result in a negotiation failure due to the absence of an acceptable
proposal.
8.7. Robust Header Compression (ROHC)
8.7.1. RFC 3095, RObust Header Compression (ROHC): Framework and four
profiles: RTP, UDP, ESP, and uncompressed (S, July 2001)
ROHC is a framework for header compression, intended to be used in
resource-constrained environments. [RFC3095] applies this framework
to four protocols, including ESP.
8.7.2. RFC 5225, RObust Header Compression Version 2 (ROHCv2): Profiles
for RTP, UDP, IP, ESP, and UDP-Lite (S, April 2008)
Frankel & Krishnan Expires August 2010 [Page 48]
Internet Draft IPsec/IKE Roadmap February 4, 2010
[RFC5225] defines an updated ESP/IP profile for use with ROHC version
2. It analyzes the ESP header and classifies the fields into several
classes like static, well-known, irregular etc. in order to
efficiently compress the headers.
8.7.3. draft-ietf-rohc-hcoipsec, Integration of Robust Header
Compression (ROHC) over IPsec Security Associations (I)
[rohc-1] describes a mechanism to compress inner IP headers at the
ingress point of IPsec tunnels and to decompress them at the egress
point. Since the ROHC specifications only describe operations on a
per-hop basis, this document also specifies extensions to enable ROHC
over multiple hops. This 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
Support Robust Header Compression over IPsec (ROHCoIPsec) (S)
ROHC requires initial configuration at the compressor and
decompressor ends. Since ROHC usually operates on a per-hop basis
this configuration information is carried over link-layer protocols
such as PPP. Since [rohc-1] operates over multiple hops a different
signaling mechanism is required. [rohc-2] describes how to use IKEv2
in order to dynamically communicate the configuration parameters
between the compressor and decompressor.
8.7.5. draft-ietf-rohc-ipsec-extensions-hcoipsec, IPsec Extensions to
Support Robust Header Compression over IPsec (ROHCoIPsec) (S)
[rohc-1] describes how to use ROHC with IPsec. This is not possible
without extensions to IPsec. [rohc-3] describes the extensions
needed to IPsec in order to support ROHC. Specifically, it describes
extensions needed to the IPsec SPD, SAD and to the IPsec processing
including ICV computation and integrity verification.
8.8. Border Gateway Protocol (BGP)
8.8.1. RFC 5566, BGP IPsec Tunnel Encapsulation Attribute (S, June
2009)
[RFC5566] adds an additional BGP Encapsulation Subsequent Address
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
tunnel mode, and the use of AH and ESP in transport mode to protect
IP in IP and MPLS-in-IP tunnels.
8.9. IPsec benchmarking
Frankel & Krishnan Expires August 2010 [Page 49]
Internet Draft IPsec/IKE Roadmap February 4, 2010
8.9.1. draft-ietf-bmwg-ipsec-meth, Methodology for Benchmarking IPsec
Devices (S)
[bmwg-1] defines a set of tests that can be used to measure and
report the performance characteristics of IPsec devices. It extends
the methodology defined for benchmarking network interconnecting
devices to include IPsec gateways and adds further tests which can be
used to measure IPsec performance of end-hosts. The document
focusses on establishing a performance testing methodology for IPsec
devices that support manual keying and IKEv1, but does not cover
IKEv2.
8.9.2. draft-ietf-bmwg-ipsec-term, Terminology for Benchmarking IPsec
Devices (I)
[bmwg-2] is defines the standardized performance testing terminology
for IPsec devices that support manual keying and IKEv1. It also
describes the benchmark tests that would be used to test the
performance of the IPsec devices.
9. Acknowledgements
The authors would like to thank Yaron Sheffer, Paul Hoffman, Yoav
Nir, Rajeshwar Singh Jenwar, Alfred Hoenes, Al Morton, Gabriel
Montenegro, Sean Turner, Julien Laganier, Grey Daley and Scott Moonen
for reviewing this document and suggesting changes.
10. Security Considerations
There are no security considerations relevant to this document.
11. IANA Considerations
No actions are required from IANA as result of the publication of
this document.
12. References
12.1. Normative References
12.2. Informative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision
3", RFC 2026, October 1996.
Frankel & Krishnan Expires August 2010 [Page 50]
Internet Draft IPsec/IKE Roadmap February 4, 2010
[bmwg-1] Kaeo, M. and T. Van Herck, "Methodology for Benchmarking
IPsec Devices", draft-ietf-bmwg-ipsec-meth, Work in
Progress.
[bmwg-2] Kaeo, M., Van Herck T. and M. Bustos, "Terminology for
Benchmarking IPsec Devices", draft-ietf-bmwg-ipsec-term,
Work in Progress.
[ecp-ike1] Fu, D. and J. Solinas, "ECP Groups for IKE and IKEv2",
draft-solinas-rfc4753bis, Work in Progress.
[ipsecme-1] Kaufman, C., P. Hoffman, Y. Nir and P. Eronen, "Internet
Key Exchange Protocol: IKEv2",
draft-ietf-ipsecme-ikev2bis, Work in Progress.
[ipsecme-2] Eronen, P., J. Laganier and C. Madson,
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
Encryption Standard (AES) Counter Mode with IKEv2", Work
in Progress.
[rohc-1] Ertekin, E., R. Jasani, C. Christou and C. Bormann,
"Integration of Robust Header Compression (ROHC) over
IPsec Security Associations", draft-ietf-rohc-hcoipsec,
Work in Progress.
[rohc-2] Ertekin, E., C. Christou, R. Jasani, T. Kivinen and C.
Bormann, "IKEv2 Extensions to Support Robust Header
Compression over IPsec (ROHCoIPsec)",
draft-ietf-rohc-ikev2-extensions-hcoipsec, Work in
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.
Frankel & Krishnan Expires August 2010 [Page 51]
Internet Draft IPsec/IKE Roadmap February 4, 2010
[RFC2394] Pereira, R., "IP Payload Compression Using DEFLATE", RFC
2394, December 1998.
[RFC2395] Friend, R. and R. Monsour, "IP Payload Compression Using
LZS", RFC 2395, December 1998.
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998 (obsolete).
[RFC2402] Kent, S. and R. Atkinson, "IP Authentication Header", RFC
2402, November 1998 (obsolete).
[RFC2403] Madson, C. and R. Glenn, "The Use of HMAC-MD5-96 within
ESP and AH", RFC 2403, November 1998.
[RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within
ESP and AH", RFC 2404, November 1998.
[RFC2405] Madson, C. and N. Doraswamy, "The ESP DES-CBC Cipher
Algorithm With Explicit IV", RFC 2405, November 1998.
[RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security
Payload (ESP)", RFC 2406, November 1998 (obsolete).
[RFC2407] Piper, D., "The Internet IP Security Domain of
Interpretation for ISAKMP", RFC 2407, November 1998
(obsolete).
[RFC2408] Maughan, D. M. Schertler, M. Schneider and J. Turner,
"Internet Security Association and Key Management Protocol
(ISAKMP)", RFC 2408, November 1998 (obsolete).
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange
(IKE)", RFC 2409, November 1998 (obsolete).
[RFC2410] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and
Its Use With IPsec", RFC 2410, November 1998.
[RFC2411] Thayer, R., N. Doraswamy and R. Glenn, "IP Security
Document Roadmap", RFC 2411, November 1998.
[RFC2412] Orman, H., "The OAKLEY Key Determination Protocol", RFC
2412, November 1998.
[RFC2451] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher
Algorithms", RFC 2451, November 1998.
[RFC2857] Keromytis, A. and N. Provos, "The Use of
Frankel & Krishnan Expires August 2010 [Page 52]
Internet Draft IPsec/IKE Roadmap February 4, 2010
HMAC-RIPEMD-160-96 within ESP and AH", RFC 2857, June
2000.
[RFC3056] Carpenter, B., "Connection of IPv6 Domains via IPv4
Clouds", RFC 3056, February 2001.
[RFC3095] Bormann, C., Ed. et.al., "RObust Header Compression
(ROHC): Framework and four profiles: RTP, UDP, ESP, and
uncompressed", RFC 3095, July 2001.
[RFC3129] Thomas, M., "Requirements for Kerberized Internet
Negotiation of Keys", RFC 3129, June 2001.
[RFC3173] Shacham, A. B. Monsour, R. Pereira and M. Thomas, "IP
Payload Compression Protocol (IPComp)", RFC 3173,
September 2001.
[RFC3456] Patel, B. B. Aboba, S. Kelly and V. Gupta, "Dynamic Host
Configuration Protocol (DHCPv4) Configuration of IPsec
Tunnel Mode", RFC 3456, January 2003.
[RFC3457] Kelly, S. and S. Ramamoorthi, "Requirements for IPsec
Remote Access Scenarios", RFC 3457, January 2003.
[RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP)
Diffie-Hellman groups for Internet Key Exchange (IKE)",
RFC 3526, May 2003.
[RFC3547] Baugher, M. B. Weis, T. Hardjono and H. Harney, "The Group
Domain of Interpretation", RFC 3547, July 2003.
[RFC3554] Bellovin, S. J. Ioannidis, A. Keromytis and R. Stewart,
"On the Use of Stream Control Transmission Protocol (SCTP)
with IPsec", RFC 3554, July 2003.
[RFC3566] Frankel, S. and H. Herbert, "The AES-XCBC-MAC-96 Algorithm
and Its Use With IPsec", RFC 3566, September 2003.
[RFC3585] Jason, J. L. Rafalow, and E. Vyncke, "IPsec Configuration
Policy Information Model", RFC 3585, August 2003.
[RFC3586] Blaze, M. A. Keromytis, M. Richardson and L. Sanchez, "IP
Security Policy (IPSP) Requirements", RFC 3586, August
2003.
[RFC3602] Frankel, S. R. Glenn and S. Kelly, "The AES-CBC Cipher
Algorithm and Its Use with IPsec", RFC 3602, September
2003.
Frankel & Krishnan Expires August 2010 [Page 53]
Internet Draft IPsec/IKE Roadmap February 4, 2010
[RFC3686] Housley, R., "Using Advanced Encryption Standard (AES)
Counter Mode With IPsec Encapsulating Security Payload
(ESP)", RFC 3686, January 2004.
[RFC3706] Huang, G., S. Beaulieu and D. Rochefort, "A Traffic-Based
Method of Detecting Dead Internet Key Exchange (IKE)
Peers", RFC 3706, February 2004.
[RFC3715] Aboba, B. and W. Dixon, "IPsec-Network Address Translation
(NAT) Compatibility Requirements", RFC 3715, March 2004.
[RFC3740] Hardjono, T. and B. Weis, "The Multicast Group Security
Architecture", RFC 3740, March 2004.
[RFC3776] Arkko, J., V. Devarapalli and F. Dupont, "Using IPsec to
Protect Mobile IPv6 Signaling Between Mobile Nodes and
Home Agents", RFC 3776, June 2004.
[RFC3830] Arkko, J., E. Carrara, F. Lindholm, M. Naslund and K.
Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830,
August 2004.
[RFC3884] Touch, J., L. Eggert and Y. Wang, "Use of IPsec Transport
Mode for Dynamic Routing", RFC 3884, September 2004.
[RFC3947] Kivinen, T., B. Swander, A. Huttunen and V. Volpe,
"Negotiation of NAT-Traversal in the IKE", RFC 3947,
January 2005.
[RFC3948] Huttunen, A., B. Swander, V. Volpe, L. DiBurro and M.
Stenberg, "UDP Encapsulation of IPsec ESP Packets", RFC
3948, January 2005.
[RFC4025] Richardson, M., "A method for storing IPsec keying
material in DNS", RFC 4025, February 2005.
[RFC4046] Baugher, M., R. Canetti, L. Dondeti and F. Lindholm,
"Multicast Security (MSEC) Group Key Management
Architecture", RFC 4046, April 2005.
[RFC4082] Perrig, A., D. Song, R. Canetti, J. D. Tygar and B.
Briscoe, "Timed Efficient Stream Loss-Tolerant
Authentication (TESLA): Multicast Source Authentication
Transform Introduction", RFC 4082, June 2005.
[RFC4093] Adrandi, F., Ed. and H. Levkowetz, Ed., "Problem
Statement: Mobile IPv4 Traversal of Virtual Private
Network (VPN) Gateways", RFC 4093, August 2005.
Frankel & Krishnan Expires August 2010 [Page 54]
Internet Draft IPsec/IKE Roadmap February 4, 2010
[RFC4106] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode
(GCM) in IPsec Encapsulating Security Payload (ESP)", RFC
4106, June 2005.
[RFC4109] Hoffman, P., "Algorithms for Internet Key Exchange version
1 (IKEv1)", RFC 4109, May 2005.
[RFC4196] Lee, H.J., J.H. Yoon, S.L. Lee and J.I. Lee, "The SEED
Cipher Algorithm and Its Use with IPsec", RFC 4196,
October 2005.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December
2005.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC
4303, December 2005.
[RFC4304] Kent, S., "Extended Sequence Number (ESN) Addendum to
IPsec Domain of Interpretation (DOI) for Internet Security
Association and Key Management Protocol (ISAKMP)", RFC
4304, December 2005.
[RFC4305] Eastlake, D. 3rd, "Cryptographic Algorithm Implementation
Requirements for Encapsulating Security Payload (ESP) and
Authentication Header (AH)", RFC 4305, December 2005
(obsolete).
[RFC4306] Kaufman, C., Ed., "Internet Key Exchange (IKEv2)
Protocol", RFC 4306, December 2005.
[RFC4307] Schiller, J., "Cryptographic Algorithms for Use in the
Internet Key Exchange Version 2 (IKEv2)", RFC 4307,
December 2005.
[RFC4308] Hoffman, P., "Cryptographic Suites for IPsec", RFC 4308,
December 2005.
[RFC4309] Housley, R., "Using Advanced Encryption Standard (AES) CCM
Mode with IPsec Encapsulating Security Payload (ESP)", RFC
4309, December 2005.
[RFC4312] Kato, A., S. Moriai and M. Kanda, "The Camellia Cipher
Algorithm and Its Use with IPsec", RFC 4312, December
2005.
Frankel & Krishnan Expires August 2010 [Page 55]
Internet Draft IPsec/IKE Roadmap February 4, 2010
[RFC4359] Weis, B., "The Use of RSA/SHA-1 Signatures within
Encapsulating Security Payload (ESP) and Authentication
Header (AH)", RFC 4359, January 2006.
[RFC4383] Baugher, M. and E. Carrara, "The Use of Timed Efficient
Stream Loss-Tolerant Authentication (TESLA) in the Secure
Real-time Transport Protocol (SRTP)", RFC 4383, February
2006.
[RFC4430] Sakane, S., K. Kamada, M. Thomas, and J. Vilhuber,
"Kerberized Internet Negotiation of Keys (KINK)", RFC
4430, March 2006.
[RFC4434] Hoffman, P., "The AES-XCBC-PRF-128 Algorithm for the
Internet Key Exchange Protocol (IKE)", RFC 4434, February
2006.
[RFC4442] Fries, S. and H. Tschofenig, "Bootstrapping Timed
Efficient Stream Loss-Tolerant Authentication (TESLA)",
RFC 4442, March 2006.
[RFC4478] Nir, Y., "Repeated Authentication in Internet Key Exchange
(IKEv2) Protocol", RFC 4478, April 2006.
[RFC4494] Song, JH., R. Poovendran and J. Lee, "The AES-CMAC-96
Algorithm and Its Use with IPsec", RFC 4494, June 2006.
[RFC4534] Colegrove, A. and H. Harney, "Group Security Policy Token
v1", RFC 4534, June 2006.
[RFC4535] Harney, H., U. Meth, A. Colegrove and G. Gross, "GSAKMP:
Group Secure Association Key Management Protocol", RFC
4535, June 2006.
[RFC4543] McGrew, D. and J. Viega, "The Use of Galois Message
Authentication Code (GMAC) in IPsec ESP and AH", RFC 4543,
May 2006.
[RFC4552] Gupta, M. and N. Melam, "Authentication/Confidentiality
for OSPFv3", RFC 4552, June 2006.
[RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol
(MOBIKE)", RFC 4555, June 2006.
[RFC4563] Carrara, E., V. Lehtovirta and K. Norrman, "The Key ID
Information Type for the General Extension Payload in
Multimedia Internet KEYing (MIKEY)", RFC 4563, June 2006.
Frankel & Krishnan Expires August 2010 [Page 56]
Internet Draft IPsec/IKE Roadmap February 4, 2010
[RFC4595] Maino, F. and D. Black, "Use of IKEv2 in the Fibre Channel
Security Association Management Protocol", RFC 4595, July
2006.
[RFC4615] Song, J., R. Poovendran, J. Lee and T. Iwata, "The
Advanced Encryption Standard-Cipher-based Message
Authentication Code-Pseudo-Random Function-128
(AES-CMAC-PRF-128) Algorithm for the Internet Key Exchange
Protocol (IKE)", RFC 4615, August 2006.
[RFC4621] Kivinen, T. and H. Tschofenig, "Design of the IKEv2
Mobility and Multihoming (MOBIKE) Protocol", RFC 4621,
August 2006.
[RFC4650] Euchner, M., "HMAC-Authenticated Diffie-Hellman for
Multimedia Internet KEYing (MIKEY)", RFC 4650, September
2006.
[RFC4718] Eronen, P. and P. Hoffman, "IKEv2 Clarifications and
Implementation Guidelines", RFC 4718, October 2006.
[RFC4738] Ignjatic, D., L. Dondeti, F. Audet and P. Lin,
"MIKEY-RSA-R: An Additional Mode of Key Distribution in
Multimedia Internet KEYing (MIKEY)", RFC 4738, November
2006.
[RFC4739] Eronen P. and J. Korhonen, "Multiple Authentication
Exchanges in the Internet Key Exchange (IKEv2) Protocol",
RFC 4739, November 2006.
[RFC4753] Fu, D. and J. Solinas, "ECP Groups For IKE and IKEv2", RFC
4753, January 2007.
[RFC4754] Fu, D. and J. Solinas, "IKE and IKEv2 Authentication Using
the Elliptic Curve Digital Signature Algorithm (ECDSA)",
RFC 4754, January 2007.
[RFC4806] Myers, M. and H. Tschofenig, "Online Certificate Status
Protocol (OCSP) Extensions to IKEv2", RFC 4806, February
2007.
[RFC4807] Baer, M., R. Charlet, W. Hardaker, R. Story and C. Wang,
"IPsec Security Policy Database Configuration MIB", RFC
4807, March 2007.
[RFC4809] Bonatti, C., Ed., and S. Turner, Ed., "Requirements for an
IPsec Certificate Management Profile", RFC 4809, February
2007.
Frankel & Krishnan Expires August 2010 [Page 57]
Internet Draft IPsec/IKE Roadmap February 4, 2010
[RFC4835] Manral, V., "Cryptographic Algorithm Implementation
Requirements for Encapsulating Security Payload (ESP) and
Authentication Header (AH)", RFC 4835, April 2007.
[RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256,
HMAC-SHA-384, and HMAC-SHA-512 with IPsec", RFC 4868, May
2007.
[RFC4869] Law, L. and J. Solinas, "Suite B Cryptographic Suites for
IPsec", RFC 4869, May 2007.
[RFC4877] Devarapalli, V. and R. Dupont, "Mobile IPv6 Operation with
IKEv2 and the Revised IPsec Architecture", RFC 4877, April
2007.
[RFC4891] Graveman, R., M. Parthasarathy, P. Savola and H.
Tschofenig, "Using IPsec to Secure IPv6-in-IPv4 Tunnels",
RFC 4891, May 2007.
[RFC4894] Hoffman, P., "Use of Hash Algorithms in Internet Key
Exchange (IKE) and IPsec", RFC 4894, May 2007.
[RFC4945] Korver, B., "The Internet IP Security PKI Profile of
IKEv1/ISAKMP, IKEv2, and PKIX", RFC 4945, August 2007.
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2", RFC
4949, August 2007.
[RFC5106] Tschofenig, H., D. Kroeselberg, A. Pashalidis, Y. Ohba and
F. Bersani, "The Extensible Authentication
Protocol-Internet Key Exchange Protocol version 2
(EAP-IKEv2) Method", RFC 5106, February 2008.
[RFC5114] Lepinski, M. and S. Kent, "Additional Diffie-Hellman
Groups for Use with IETF Standards", RFC 5114, January
2008.
[RFC5197] Fries, S. and D. Ignjatic, "On the Applicability of
Various Multimedia Internet KEYing (MIKEY) Modes and
Extensions", RFC 5197, June 2008.
[RFC5201] Moskowitz, R., P. Nikander, P. Jokela, Ed., and T.
Henderson, "Host Identity Protocol", RFC 5201, April 2008.
[RFC5202] Jokela, P., R. Moskowitz and P. Nikander, "Using the
Encapsulating Security Payload (ESP) Transport Format with
the Host Identity Protocol (HIP)", RFC 5202, April 2008.
Frankel & Krishnan Expires August 2010 [Page 58]
Internet Draft IPsec/IKE Roadmap February 4, 2010
[RFC5206] Nikander, P., T. Henderson, Ed., C. Vogt, and J. Arkko,
"End-Host Mobility and Multihoming with the Host
Identity", RFC 5206, April 2008.
[RFC5207] Stiemerling, M., J. Quittek and L. Eggert, "NAT and
Firewall Traversal Issues of Host Identity Protocol
(HIP)", RFC 5207, April 2008.
[RFC5213] Gundavelli, S., Ed., K. Leung, V. Devarapali, K. Chowdhury
and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
[RFC5225] Pelletier, G. and K. Sandlund, "RObust Header Compression
Version 2 (ROHCv2): Profiles for RTP, UDP, IP, ESP, and
UDP-Lite", RFC 5225, April 2008.
[RFC5265] Vaarala, S. and E. Klovning, "Mobile IPv4 Traversal across
IPsec-Based VPN Gateways", RFC 5265, June 2008.
[RFC5266] Devarapalli, V. and P. Eronen, "Secure Connectivity and
Mobility Using Mobile IPv4 and IKEv2 Mobility and
Multihoming (MOBIKE)", RFC 5266, June 2008.
[RFC5268] Koodli, R., Ed., "Mobile IPv6 Fast Handovers", RFC 5268,
June 2008.
[RFC5282] Black, D. and D. McGrew, " Using Authenticated Encryption
Algorithms with the Encrypted Payload of the Internet Key
Exchange version 2 (IKEv2) Protocol", RFC 5282, August
2008.
[RFC5380] Soliman, H., C. Castelluccia, K. ElMalki and L. Bellier,
"Hierarchical Mobile IPv6 (HMIPv6) Mobility Management",
RFC 5380, October 2008.
[RFC5386] Williams, N. and M. Richardson,
"Better-Than-Nothing-Security: An Unauthenticated Mode of
IPsec", RFC 5386, November 2008.
[RFC5374] Weis, B., G. Gross and D. Ignjatic, "Multicast Extensions
to the Security Architecture for the Internet Protocol",
RFC 5374, November 2008.
[RFC5387] Touch, J., D. Black and Y. Wang, "Problem and
Applicability Statement for Better-Than-Nothing Security
(BTNS)", RFC 5387, November 2008.
[RFC5406] Bellovin, S., "Guidelines for Specifying the Use of IPsec
Version 2", RFC 5406, February 2009.
Frankel & Krishnan Expires August 2010 [Page 59]
Internet Draft IPsec/IKE Roadmap February 4, 2010
[RFC5410] Jerichow, A., Ed., and L. Piron, "Multimedia Internet
KEYing (MIKEY) General Extension Payload for Open Mobile
Alliance BCAST 1.0", RFC 5410, January 2009.
[RFC5529] Kato, A., M. Kanda and S. Kanno, "Modes of Operation for
Camellia for Use with IPsec", RFC 5529, April 2009.
[RFC5566] Berger, L., R. White and E. Rosen, "BGP IPsec Tunnel
Encapsulation Attribute", RFC 5566, June 2009.
[RFC5660] Williams, N., "IPsec Channels: Connection Latching", RFC
5660, October 2009.
[RFC5685] Devarapalli, V and K. Weniger, "Re-direct Mechanism for
the Internet Key Exchange Protocol Version 2 (IKEv2)", RFC
5685, November 2009.
[RFC5723] Sheffer, Y., H. Tschofenig, L. Dondeti and V. Narayanan,
"Internet Key Exchange Protocol Version 2 (IKEv2) Session
Resumption", RFC 5723, January 2010.
Frankel & Krishnan Expires August 2010 [Page 60]
Internet Draft IPsec/IKE Roadmap February 4, 2010
Appendix A. Summary of IPsec/IKE Document Requirement Levels
Table 1: Document Requirement Levels
+--------------------------+----------------------------------------+
| DOCUMENT | REQUIREMENT LEVEL |
| | IKEv1 IKEv2 IPsec-v2 IPsec-v3 |
+--------------------------+----------------------------------------+
|IPsec-v2: |
|-------- |
| RFC 2401 | MUST N/A |
| | |
| RFC 2402 | MUST N/A |
| | |
| RFC 2406 | MUST N/A |
| | |
|IPsec-v3: |
|-------- |
| RFC 4301 | N/A MUST |
| | |
| RFC 4302 | N/A optional |
| | |
| 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 |
+--------------------------+----------------------------------------+
Frankel & Krishnan Expires August 2010 [Page 61]
Internet Draft IPsec/IKE Roadmap February 4, 2010
Table 1: Document Requirement Levels (continued)
+--------------------------+----------------------------------------+
| DOCUMENT | REQUIREMENT LEVEL |
| | IKEv1 IKEv2 IPsec-v2 IPsec-v3 |
+--------------------------+----------------------------------------+
|Additions to IPsec: |
|------------------ |
| RFC 3947 | optional N/A |
| | |
| RFC 3948 | optional optional |
| | |
| RFC 4304 | optional N/A optional optional |
| | |
| RFC 4891 | optional optional |
| | |
| RFC 3884 | optional optional |
| | |
| draft-ietf-ipsecme- | N/A optional |
| traffic-visibility | |
| | |
| draft-ietf-ipsecme- | optional optional |
| esp-null-heuristics | |
| | |
|General Considerations: |
|---------------------- |
| RFC 3715 | optional optional |
| | |
| RFC 5406 | optional N/A |
| | |
|IKEv1: |
|----- |
| RFC 2409 | optional N/A |
| | |
| RFC 2408 | optional N/A |
| | |
| RFC 2407 | optional N/A |
| | |
| RFC 2412 | optional N/A |
| | |
|IKEv2: |
|----- |
| RFC 4306 | N/A optional |
| | |
| RFC 4718 | N/A optional |
| | |
| draft-ietf-ipsecme-ikev2bis N/A optional |
+--------------------------+----------------------------------------+
Frankel & Krishnan Expires August 2010 [Page 62]
Internet Draft IPsec/IKE Roadmap February 4, 2010
Table 1: Document Requirement Levels (continued)
+--------------------------+----------------------------------------+
| DOCUMENT | REQUIREMENT LEVEL |
| | IKEv1 IKEv2 IPsec-v2 IPsec-v3 |
+--------------------------+----------------------------------------+
|Peer Authentication Methods: |
|--------------------------- |
| RFC 4478 | N/A optional |
| | |
| RFC 4739 | N/A optional |
| | |
| RFC 4754 | optional optional |
| | |
|Certificate Contents and Management: |
|----------------------------------- |
| RFC 4809 | optional optional |
| | |
| RFC 4945 | optional optional |
| | |
| RFC 4806 | N/A optional |
| | |
|Dead Peer Detection: |
|------------------- |
| RFC 3706 | optional N/A |
| | |
|Remote Access: |
|------------- |
| RFC 5723 | N/A optional |
| | |
| RFC 5685 | N/A optional |
| | |
| draft-ietf-ipsecme- | N/A optional |
| ikev2-ipv6-config | |
| | |
|Algorithm Requirements: |
|---------------------- |
| RFC 4835 | MUST MUST |
| | |
| RFC 4307 | N/A MUST |
| | |
| RFC 4109 | MUST N/A |
+--------------------------+----------------------------------------+
Frankel & Krishnan Expires August 2010 [Page 63]
Internet Draft IPsec/IKE Roadmap February 4, 2010
Appendix B. Summary of Algorithm Requirement Levels
Table 2: Algorithm Requirement Levels
+--------------------------+----------------------------------------+
| ALGORITHM | REQUIREMENT LEVEL |
| | IKEv1 IKEv2 IPsec-v2 IPsec-v3 |
+--------------------------+----------------------------------------+
|Encryption Algorithms: |
|--------------------- |
| ESP-NULL | N/A N/A MUST MUST |
| | |
| 3DES-CBC | MUST MUST- MUST MUST- |
| | |
| Blowfish/CAST/IDEA/RC5 | optional optional optional optional |
| | |
| AES-CBC 128-bit key | SHOULD SHOULD+ MUST MUST |
| | |
| AES-CBC 192/256-bit key | optional optional optional optional |
| | |
| AES-CTR | undefined optional SHOULD SHOULD |
| | |
| Camellia-CBC | optional optional optional optional |
| | |
| Camellia-CTR | undefined undefined undefined optional |
| | |
| SEED-CBC | undefined undefined optional undefined|
| | |
|Integrity-Protection Algorihms: |
|------------------------------ |
| HMAC-SHA-1 | MUST MUST MUST MUST |
| | |
| AES-XCBC-MAC | undefined optional SHOULD+ SHOULD+ |
| | |
| HMAC-SHA-256/384/512 | optional optional optional optional |
| | |
| AES-GMAC | N/A N/A undefined optional |
| | |
| HMAC-MD5 | MAY optional MAY MAY |
| | |
| AES-CMAC | undefined optional undefined optional |
| | |
| HMAC-RIPEMD | undefined undefined optional undefined|
+--------------------------+----------------------------------------+
Frankel & Krishnan Expires August 2010 [Page 64]
Internet Draft IPsec/IKE Roadmap February 4, 2010
Table 2: Algorithm Requirement Levels (continued)
+--------------------------+----------------------------------------+
| ALGORITHM | REQUIREMENT LEVEL |
| | IKEv1 IKEv2 IPsec-v2 IPsec-v3 |
+--------------------------+----------------------------------------+
|Combined Mode Algorithms: |
|------------------------ |
| AES-CCM | N/A optional N/A optional |
| | |
| AES-GCM | N/A optional N/A optional |
| | |
| AES-GMAC | N/A N/A undefined optional |
| | |
| Camellia-CCM | N/A undefined N/A optional |
| | |
|Pseudo-Random Functions: |
|----------------------- |
| PRF-HMAC-SHA1 | MUST MUST |
| | |
| PRF-HMAC-SHA-256/384/512 | optional optional |
| | |
| AES-XCBC-PRF | undefined SHOULD+ |
| | |
| AES-CMAC-PRF | undefined optional |
| | |
|Diffie-Hellman Algorithms: |
|------------------------- |
| DH MODP grp 1 | MAY optional |
| | |
| DH MODP grp 2 | MUST MUST- |
| | |
| DH MODP grp 5 | optional optional |
| | |
| DH MODP grp 14 | SHOULD SHOULD+ |
| | |
| DH MODP grp 15-18 | optional optional |
| | |
| DH MODP grp 22-24 | optional optional |
| | |
| DH EC grp 3-4 | MAY undefined |
| | |
| DH EC grp 19-21 | optional optional |
| | |
| DH EC grp 25-26 | optional optional |
+--------------------------+----------------------------------------+
Frankel & Krishnan Expires August 2010 [Page 65]
Internet Draft IPsec/IKE Roadmap February 4, 2010
Authors' Addresses
Sheila Frankel
NIST
Bldg. 223 Rm. B366
Gaithersburg, MD 20899
Phone: 1-301-975-3297
Email: sheila.frankel@nist.gov
Suresh Krishnan
Ericsson
8400 Decarie Blvd.
Town of Mount Royal, QC
Canada
Phone: 1-514-345-7900 x42871
Email: suresh.krishnan@ericsson.com
Frankel & Krishnan Expires August 2010 [Page 66]
