draft-ietf-ipsecme-roadmap-01.txt   draft-ietf-ipsecme-roadmap-02.txt 
Network Working Group S. Frankel Network Working Group S. Frankel
Internet Draft NIST Internet Draft NIST
Obsoletes: 2411 (if approved) S. Krishnan Obsoletes: 2411 (if approved) S. Krishnan
Intended Status: Informational Ericsson Intended Status: Informational Ericsson
Expires: August 2009 March 6, 2009 Expires: January 2010 July 3, 2009
IP Security (IPsec) and Internet Key Exchange (IKE) Document Roadmap IP Security (IPsec) and Internet Key Exchange (IKE) Document Roadmap
<draft-ietf-ipsecme-roadmap-01.txt> <draft-ietf-ipsecme-roadmap-02.txt>
Status of this Memo Status of this Memo
Distribution of this memo is unlimited.
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as other groups may also distribute working documents as Internet-
Internet-Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 6, 2009. This Internet-Draft will expire on January 3, 2010.
Copyright and License Notice Copyright Notice
Copyright (c) 2008 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents in effect on the date of
(http://trustee.ietf.org/license-info) in effect on the date of publication of this document (http://trustee.ietf.org/license-info).
publication of this document. Please review these documents Please review these documents carefully, as they describe your rights
carefully, as they describe your rights and restrictions with respect and restrictions with respect to this document.
to this document.
Abstract Abstract
Over the past few years, the number of RFCs that define and use IPsec 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 and IKE has greatly proliferated. This is complicated by the fact
that these RFCs originate from numerous IETF working groups: the that these RFCs originate from numerous IETF working groups: the
original IPsec WG, its various spin-offs, and other WGs that use original IPsec WG, its various spin-offs, and other WGs that use
IPsec and/or IKE to protect their protocols' traffic. IPsec and/or IKE to protect their protocols' traffic.
This document is a snapshot of IPsec- and IKE-related RFCs. It This document is a snapshot of IPsec- and IKE-related RFCs. It
skipping to change at page 2, line 37 skipping to change at page 2, line 37
2.3. Versions of IKE . . . . . . . . . . . . . . . . . . . . . . 7 2.3. Versions of IKE . . . . . . . . . . . . . . . . . . . . . . 7
2.3.1. Differences between IKEv1 and IKEv2 . . . . . . . . . 7 2.3.1. Differences between IKEv1 and IKEv2 . . . . . . . . . 7
2.4. IPsec and IKE IANA Registries . . . . . . . . . . . . . . . 8 2.4. IPsec and IKE IANA Registries . . . . . . . . . . . . . . . 8
3. IPsec Documents . . . . . . . . . . . . . . . . . . . . . . . . 8 3. IPsec Documents . . . . . . . . . . . . . . . . . . . . . . . . 8
3.1. Base Documents . . . . . . . . . . . . . . . . . . . . . . 8 3.1. Base Documents . . . . . . . . . . . . . . . . . . . . . . 8
3.1.1. "Old" IPsec . . . . . . . . . . . . . . . . . . . . . . 8 3.1.1. "Old" IPsec . . . . . . . . . . . . . . . . . . . . . . 8
3.1.2. "New" IPsec . . . . . . . . . . . . . . . . . . . . . . 10 3.1.2. "New" IPsec . . . . . . . . . . . . . . . . . . . . . . 10
3.2. Policy . . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.2. Policy . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.3. MIBs . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 3.3. MIBs . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.4. Additions to IPsec . . . . . . . . . . . . . . . . . . . . 11 3.4. Additions to IPsec . . . . . . . . . . . . . . . . . . . . 11
3.5. General Considerations . . . . . . . . . . . . . . . . . . 12 3.5. General Considerations . . . . . . . . . . . . . . . . . . 13
4. IKE Documents . . . . . . . . . . . . . . . . . . . . . . . . . 13 4. IKE Documents . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.1. Base Documents . . . . . . . . . . . . . . . . . . . . . . 13 4.1. Base Documents . . . . . . . . . . . . . . . . . . . . . . 13
4.1.1. IKEv1 . . . . . . . . . . . . . . . . . . . . . . . . . 13 4.1.1. IKEv1 . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.1.2. IKEv2 . . . . . . . . . . . . . . . . . . . . . . . . . 14 4.1.2. IKEv2 . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.2. Additions and Extensions . . . . . . . . . . . . . . . . . 14 4.2. Additions and Extensions . . . . . . . . . . . . . . . . . 15
4.2.1. Peer Authentication Methods . . . . . . . . . . . . . . 15 4.2.1. Peer Authentication Methods . . . . . . . . . . . . . . 15
4.2.2. Certificate Contents and Management . . . . . . . . . . 15 4.2.2. Certificate Contents and Management . . . . . . . . . . 16
4.2.3. Dead Peer Detection . . . . . . . . . . . . . . . . . . 16 4.2.3. Dead Peer Detection . . . . . . . . . . . . . . . . . . 16
4.2.4. Remote Access . . . . . . . . . . . . . . . . . . . . . 16 4.2.4. Remote Access . . . . . . . . . . . . . . . . . . . . . 17
5. Cryptographic Algorithms and Suites . . . . . . . . . . . . . . 17 5. Cryptographic Algorithms and Suites . . . . . . . . . . . . . . 18
5.1. Algorithm Requirements . . . . . . . . . . . . . . . . . . 17 5.1. Algorithm Requirements . . . . . . . . . . . . . . . . . . 18
5.2. Encryption Algorithms . . . . . . . . . . . . . . . . . . . 18 5.2. Encryption Algorithms . . . . . . . . . . . . . . . . . . . 19
5.3. Integrity-Protection (Authentication) Algorithms . . . . . 21 5.3. Integrity-Protection (Authentication) Algorithms . . . . . 23
5.3.1. General Considerations . . . . . . . . . . . . . . . . 23 5.3.1. General Considerations . . . . . . . . . . . . . . . . 25
5.4. Combined Mode Algorithms . . . . . . . . . . . . . . . . . 23 5.4. Combined Mode Algorithms . . . . . . . . . . . . . . . . . 26
5.4.1. General Considerations . . . . . . . . . . . . . . . . 25 5.4.1. General Considerations . . . . . . . . . . . . . . . . 27
5.5. Pseudo-Random Functions (PRFs) . . . . . . . . . . . . . . 25 5.5. Pseudo-Random Functions (PRFs) . . . . . . . . . . . . . . 27
5.6. Cryptographic Suites . . . . . . . . . . . . . . . . . . . 26 5.6. Cryptographic Suites . . . . . . . . . . . . . . . . . . . 28
5.7. Diffie-Hellman Algorithms . . . . . . . . . . . . . . . . . 26 5.7. Diffie-Hellman Algorithms . . . . . . . . . . . . . . . . . 29
6. IPsec/IKE for Multicast . . . . . . . . . . . . . . . . . . . . 28 6. IPsec/IKE for Multicast . . . . . . . . . . . . . . . . . . . . 30
7. Outgrowths of IPsec/IKE . . . . . . . . . . . . . . . . . . . . 30 7. Outgrowths of IPsec/IKE . . . . . . . . . . . . . . . . . . . . 33
7.1. IPComp (Compression) . . . . . . . . . . . . . . . . . . . 31 7.1. IPComp (Compression) . . . . . . . . . . . . . . . . . . . 33
7.2. IKEv2 Mobility and Multihoming (MobIKE) . . . . . . . . . . 31 7.2. IKEv2 Mobility and Multihoming (MobIKE) . . . . . . . . . . 34
7.3. Better-than-Nothing Security (Btns) . . . . . . . . . . . . 32 7.3. Better-than-Nothing Security (Btns) . . . . . . . . . . . . 35
7.4. Kerberized Internet Negotiation of Keys (Kink) . . . . . . 32 7.4. Kerberized Internet Negotiation of Keys (Kink) . . . . . . 36
7.5. IPsec Secure Remote Access (IPSRA) . . . . . . . . . . . . 33 7.5. IPsec Secure Remote Access (IPSRA) . . . . . . . . . . . . 36
7.6. IPsec Keying Information Resource Record (IPsecKEY) . . . . 33 7.6. IPsec Keying Information Resource Record (IPSECKEY) . . . . 37
8. Other Protocols that use IPsec/IKE . . . . . . . . . . . . . . . 33 8. Other Protocols that use IPsec/IKE . . . . . . . . . . . . . . . 37
8.1. Mobile IP (MIPv4 and MIPv6) . . . . . . . . . . . . . . . . 33 8.1. Mobile IP (MIPv4 and MIPv6) . . . . . . . . . . . . . . . . 37
8.2. Open Shortest Path First (OSPF) . . . . . . . . . . . . . . 36 8.2. Open Shortest Path First (OSPF) . . . . . . . . . . . . . . 39
8.3. Host Identity Protocol (HIP) . . . . . . . . . . . . . . . 36 8.3. Host Identity Protocol (HIP) . . . . . . . . . . . . . . . 40
8.4. Extensible Authentication Protocol (EAP) Method Update 8.4. Extensible Authentication Protocol (EAP) Method Update
(EMU) . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 (EMU) . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
8.5. Stream Control Transmission Protocol (SCTP) . . . . . . . . 37 8.5. Stream Control Transmission Protocol (SCTP) . . . . . . . . 41
8.6. Fibre Channel . . . . . . . . . . . . . . . . . . . . . . . 37 8.6. Fibre Channel . . . . . . . . . . . . . . . . . . . . . . . 41
8.7. Robust Header Compression (ROHC) . . . . . . . . . . . . . 38 8.7. Robust Header Compression (ROHC) . . . . . . . . . . . . . 42
9. Security Considerations . . . . . . . . . . . . . . . . . . . . 38 8.8. Border Gateway Protocol (BGP) . . . . . . . . . . . . . . . 42
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 38 8.9. IPsec benchmarking . . . . . . . . . . . . . . . . . . . . 42
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 43
11.1. Normative References . . . . . . . . . . . . . . . . . . . 38 10. Security Considerations . . . . . . . . . . . . . . . . . . . . 43
11.2. Informative References . . . . . . . . . . . . . . . . . . 38 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 43
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
12.1. Normative References . . . . . . . . . . . . . . . . . . . 43
12.2. Informative References . . . . . . . . . . . . . . . . . . 43
Appendix A. Summary of Algorithm Requirement Levels . . . . . . . . 53
1. Introduction 1. Introduction
IPsec is a suite of protocols that provides security to Internet IPsec is a suite of protocols that provides security to Internet
communications at the IP layer. The most common current use of IPsec communications at the IP layer. The most common current use of IPsec
is to provide a Virtual Private Network (VPN), either between two is to provide a Virtual Private Network (VPN), either between two
locations (gateway-to-gateway) or between a remote user and an locations (gateway-to-gateway) or between a remote user and an
enterprise network (host-to-gateway); it can also provide end-to-end, enterprise network (host-to-gateway); it can also provide end-to-end,
or host-to-host, security. IPsec is also used by other Internet or host-to-host, security. IPsec is also used by other Internet
protocols (e.g. MIPv6) to protect some or all of their traffic. protocols (e.g. MIPv6) to protect some or all of their traffic.
skipping to change at page 6, line 14 skipping to change at page 6, line 14
both versions of IPsec. An earlier version of IPsec (defined in RFCs both versions of IPsec. An earlier version of IPsec (defined in RFCs
1825-1829), obsoleted by IPsec-v2, is not covered in this document. 1825-1829), obsoleted by IPsec-v2, is not covered in this document.
2.2.1. Differences between "old" IPsec (IPsec-v2) and "new" IPsec 2.2.1. Differences between "old" IPsec (IPsec-v2) and "new" IPsec
(IPsec-v3) (IPsec-v3)
IPsec-v3 incorporates "lessons learned" from implementation and IPsec-v3 incorporates "lessons learned" from implementation and
operational experience with IPsec-v2 and its predecessor, IPsec-v1. operational experience with IPsec-v2 and its predecessor, IPsec-v1.
Knowledge was gained about the barriers to IPsec deployment, the Knowledge was gained about the barriers to IPsec deployment, the
scenarios in which IPsec is most effective, and requirements that scenarios in which IPsec is most effective, and requirements that
needed to be added to IPsec to facilitate its use in other protocols. needed to be added to IPsec to facilitate its use with other
In addition, the documentation for IPsec-v3 clarifies and expands protocols. In addition, the documentation for IPsec-v3 clarifies and
details that were underspecified or ambiguous in IPsec-v2. expands details that were underspecified or ambiguous in IPsec-v2.
Changes to the architecture document [RFC4301] include: Changes to the architecture document [RFC4301] include:
o More detailed descriptions of IPsec processing, both unicast and o More detailed descriptions of IPsec processing, both unicast and
multicast, and the interactions among the various IPsec multicast, and the interactions among the various IPsec
databases databases
o In IPsec-v2, an SA (Security Association) is uniquely identified o In IPsec-v2, an SA (Security Association) is uniquely identified
by a combination of the SPI (Security Parameters Index), by a combination of the SPI (Security Parameters Index),
protocol (ESP or AH), and destination address. In IPsec-v3, a protocol (ESP or AH), and destination address. In IPsec-v3, a
skipping to change at page 7, line 19 skipping to change at page 7, line 19
(generally referred to as IKEv1); however, IKEv1 is still commonly (generally referred to as IKEv1); however, IKEv1 is still commonly
found in operational use. In this document, when the unqualified found in operational use. In this document, when the unqualified
term IKE is used, it pertains to both versions of IKE. term IKE is used, it pertains to both versions of IKE.
2.3.1. Differences between IKEv1 and IKEv2 2.3.1. Differences between IKEv1 and IKEv2
As with IPsec-v3, IKEv2 incorporates "lessons learned" from As with IPsec-v3, IKEv2 incorporates "lessons learned" from
implementation and operational experience with IKEv1. Knowledge was implementation and operational experience with IKEv1. Knowledge was
gained about the barriers to IKE deployment, the scenarios in which gained about the barriers to IKE deployment, the scenarios in which
IKE is most effective, and requirements that needed to be added to IKE is most effective, and requirements that needed to be added to
IKE to facilitate its use in other protocols as well as in IKE to facilitate its use with other protocols as well as in
general-purpose use. The documentation for IKEv2 replaces multiple, general-purpose use. The documentation for IKEv2 replaces multiple,
at time contradictory documents, with a single document; it also at time contradictory documents, with a single document; it also
clarifies and expands details that were underspecified or ambiguous clarifies and expands details that were underspecified or ambiguous
in IKEv1. in IKEv1.
Once an IKE negotiation is successfully completed, the peers have Once an IKE negotiation is successfully completed, the peers have
established two pairs of one-way (inbound and outbound) SAs. The established two pairs of one-way (inbound and outbound) SAs. The
first SA, the IKE SA, is used to protect IKE traffic. The second SA 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 provides IPsec protection to data traffic between the peers and/or
other devices for which the peers are authorized to negotiate. It is other devices for which the peers are authorized to negotiate. It is
skipping to change at page 8, line 45 skipping to change at page 8, line 45
IPsec protections are provided by two extension headers: the IPsec protections are provided by two extension headers: the
Encapsulating Security Payload (ESP) Header and the Authentication Encapsulating Security Payload (ESP) Header and the Authentication
Header (AH). There are 3 base documents: one that describes the IP Header (AH). There are 3 base documents: one that describes the IP
security architecture, and one for each of the IPsec headers. security architecture, and one for each of the IPsec headers.
3.1.1. "Old" IPsec 3.1.1. "Old" IPsec
o RFC 2401, Security Architecture for the Internet Protocol (S, o RFC 2401, Security Architecture for the Internet Protocol (S,
Nov. 1998) Nov. 1998)
[RFC2401] specifies the the mechanisms, procedures and components [RFC2401] specifies the mechanisms, procedures and components
required to provide security services at the IP layer. It also required to provide security services at the IP layer. It also
describes their interrelationship, and the general processing describes their interrelationship, and the general processing
required to inject IPsec protections into the network architecture. required to inject IPsec protections into the network architecture.
The components include: The components include:
- SA (Security Association): a one-way (inbound or outbound) - SA (Security Association): a one-way (inbound or outbound)
agreement between two communicating peers that specifies the IPsec agreement between two communicating peers that specifies the IPsec
protections to be provided to their communications. This includes protections to be provided to their communications. This includes
the specific security protections, cryptographic algorithms, and the specific security protections, cryptographic algorithms, and
secret keys to be applied, as well as the specific types of traffic secret keys to be applied, as well as the specific types of traffic
to be protected. to be protected.
- SPI (Security Parameters Index): a value that, together with - SPI (Security Parameters Index): a value that, together with
the Destination Address and security protocol (AH or ESP), uniquely the Destination Address and security protocol (AH or ESP), uniquely
identifies a single SA identifies a single SA
- SAD (Security Association Database): each peer's SA - SAD (Security Association Database): each peer's SA
repository. The RFC describes how this database functions (SA repository. The RFC describes how this database functions (SA
lookup, etc.) and the types of information it must contain to lookup, etc.) and the types of information it must contain to
factilitate SA processing; it does not dictate the format or layout facilitate SA processing; it does not dictate the format or layout of
of the database. SAs can be established in either transport mode or the database. SAs can be established in either transport mode or
tunnel mode (see below). tunnel mode (see below).
- SPD (Security Policy Database): an ordered database that - SPD (Security Policy Database): an ordered database that
expresses the security protections to be afforded to different types expresses the security protections to be afforded to different types
and classes of traffic. The 3 general classes of traffic are: and classes of traffic. The 3 general classes of traffic are:
traffic to be discarded, traffic that is allowed without IPsec traffic to be discarded, traffic that is allowed without IPsec
protection, and traffic that requires IPsec protection. protection, and traffic that requires IPsec protection.
The RFC describes general inbound and outbound IPsec processing; it The RFC describes general inbound and outbound IPsec processing; it
also includes details on several special cases: packet fragments, also includes details on several special cases: packet fragments,
skipping to change at page 10, line 17 skipping to change at page 10, line 17
optionally, replay and/or traffic analysis protection. A transport optionally, replay and/or traffic analysis protection. A transport
mode ESP SA protects the upper-layer data, but not the IP header. A mode ESP SA protects the upper-layer data, but not the IP header. A
tunnel mode ESP SA protects the upper-layer data and the inner tunnel mode ESP SA protects the upper-layer data and the inner
header, but not the outer header. header, but not the outer header.
3.1.2. "New" IPsec 3.1.2. "New" IPsec
o RFC 4301, Security Architecture for the Internet Protocol (S, o RFC 4301, Security Architecture for the Internet Protocol (S,
Dec. 2005) Dec. 2005)
[RFC4301] updates [RFC2401], including a more complete and detailed [RFC4301] obsoletes [RFC2401], including a more complete and detailed
processing model. The most notable changes are detailed above in processing model. The most notable changes are detailed above in
Section 2.2.1. IPsec-v3 processing incorporates an additional Section 2.2.1. IPsec-v3 processing incorporates an additional
database: database:
- PAD (Peer Authorization Database): contains information - PAD (Peer Authorization Database): contains information
necessary to conduct peer authentication, providing a link between necessary to conduct peer authentication, providing a link between
IPsec and the key management procotol (e.g. IKE) IPsec and the key management procotol (e.g. IKE)
o RFC 4302, IP Authentication Header (S, Dec. 2005) o RFC 4302, IP Authentication Header (S, Dec. 2005)
[RFC4302] updates [RFC2402]. Unlike IPsec-v2, IPsec-v3 classifies AH [RFC4302] obsoletes [RFC2402]. Unlike IPsec-v2, IPsec-v3 classifies
as optional. AH as optional.
o RFC 4303, IP Encapsulating Security Payload (ESP) (S, Dec. 2005) o RFC 4303, IP Encapsulating Security Payload (ESP) (S, Dec. 2005)
[RFC4303] updates [RFC2406]. The most notable changes are detailed [RFC4303] obsoletes [RFC2406]. The most notable changes are detailed
above in Section 2.2.1. above in Section 2.2.1.
3.2. Policy 3.2. Policy
The IPsec Policy Working Group (ipsp) originally planned an RFC that The IPsec Policy Working Group (ipsp) originally planned an RFC that
would allow entities with no common Trust Anchor and no prior would allow entities with no common Trust Anchor and no prior
knowledge of each others' security policies to establish an knowledge of each others' security policies to establish an
IPsec-protected connection. The solutions that were proposed for IPsec-protected connection. The solutions that were proposed for
gateway discovery and security policy negotiation proved to be overly gateway discovery and security policy negotiation proved to be overly
complex and fragile, in the absence of prior knowledge or compatible complex and fragile, in the absence of prior knowledge or compatible
skipping to change at page 11, line 29 skipping to change at page 11, line 29
IPsec and IKE, but only one progressed to RFC status. IPsec and IKE, but only one progressed to RFC status.
o RFC 4807, IPsec Security Policy Database Configuration MIB (S, o RFC 4807, IPsec Security Policy Database Configuration MIB (S,
Mar. 2007) Mar. 2007)
[RFC4807] defines a MIB module that can be used to configure the SPD [RFC4807] defines a MIB module that can be used to configure the SPD
of an IPsec device. This RFC has not been widely adopted. of an IPsec device. This RFC has not been widely adopted.
3.4. Additions to IPsec 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.
o RFC 3947, Negotiation of NAT-Traversal in the IKE (S, Jan. 2005) o RFC 3947, Negotiation of NAT-Traversal in the IKE (S, Jan. 2005)
[RFC3947] enables IKEv1 to detect whether there are any NATs between [RFC3947] enables IKEv1 to detect whether there are any NATs between
the negotiating peers, and whether both peers support NAT traversal. the negotiating peers, and whether both peers support NAT traversal.
It also describes how IKEv1 can be used to negotiate the use of UDP 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 encapsulation of ESP packets for the IPsec SA. For IKEv2, this
capability is described in [RFC4306]. capability is described in [RFC4306].
o RFC 4304, Extended Sequence Number (ESN) Addendum to IPsec o RFC 4304, Extended Sequence Number (ESN) Addendum to IPsec
Domain of Interpretation (DOI) for Internet Security Association Domain of Interpretation (DOI) for Internet Security Association
skipping to change at page 12, line 36 skipping to change at page 13, line 5
dynamically routed via the VN's trusted routers, rather than routing dynamically routed via the VN's trusted routers, rather than routing
all traffic through a statically-routed IPsec tunnel. This RFC has all traffic through a statically-routed IPsec tunnel. This RFC has
not been widely adopted. not been widely adopted.
o draft-ietf-ipsecme-traffic-visibility, Wrapped ESP for Traffic o draft-ietf-ipsecme-traffic-visibility, Wrapped ESP for Traffic
Visibility (S) Visibility (S)
ESP, as defined in [RFC4303], does not allow a network device to ESP, as defined in [RFC4303], does not allow a network device to
easily determine whether protected traffic that is passing through easily determine whether protected traffic that is passing through
the device is encrypted, or only integrity-protected (referred to as the device is encrypted, or only integrity-protected (referred to as
ESP-NULL packets). This document extends ESP to provide explicit ESP-NULL packets). [ipsecme-5] extends ESP to provide explicit
notification of integrity-protected packets, and extends IKEv2 to notification of integrity-protected packets, and extends IKEv2 to
negotiate this capability between the IPsec peers. negotiate this capability between the IPsec peers.
o draft-kivinen-ipsecme-esp-null-heuristics, Heuristics for o draft-kivinen-ipsecme-esp-null-heuristics, Heuristics for
Detecting ESP-NULL packets (I) Detecting ESP-NULL packets (I)
This document offers an alternative approach to differentiating [ipsecme-6] offers an alternative approach to differentiating between
between ESP-encrypted and ESP-NULL packets, through packet ESP-encrypted and ESP-NULL packets, through packet inspection. This
inspection. This method does not require any change to IKEv2 or ESP. method does not require any change to IKEv2 or ESP.
3.5. General Considerations 3.5. General Considerations
o RFC 3715, IPsec-Network Address Translation (NAT) Compatibility o RFC 3715, IPsec-Network Address Translation (NAT) Compatibility
Requirements (I, Mar. 2004) Requirements (I, Mar. 2004)
[RFC3715] "describes known incompatibilities between NAT and IPsec, [RFC3715] "describes known incompatibilities between NAT and IPsec,
and describes the requirements for addressing them." This is a and describes the requirements for addressing them." This is a
critical issue, since IPsec is frequently used to provide VPN access critical issue, since IPsec is frequently used to provide VPN access
to the corporate network for telecommuters, and NATs are widely to the corporate network for telecommuters, and NATs are widely
deployed in home gateways, hotels, and other access networks deployed in home gateways, hotels, and other access networks
typically used for remote access. typically used for remote access.
o RFC 5406, Guidelines for Specifying the Use of IPsec Version 2 o RFC 5406, Guidelines for Specifying the Use of IPsec Version 2
(B, Feb. 2009) (B, Feb. 2009)
skipping to change at page 13, line 19 skipping to change at page 13, line 36
typically used for remote access. typically used for remote access.
o RFC 5406, Guidelines for Specifying the Use of IPsec Version 2 o RFC 5406, Guidelines for Specifying the Use of IPsec Version 2
(B, Feb. 2009) (B, Feb. 2009)
[RFC5406] offers guidance to protocol designers on how to ascertain [RFC5406] offers guidance to protocol designers on how to ascertain
whether IPsec is the appropriate security mechanism to provide an whether IPsec is the appropriate security mechanism to provide an
interoperable security solution for the protocol. If this is not the interoperable security solution for the protocol. If this is not the
case, it advises against attempting to define a new security case, it advises against attempting to define a new security
protocol; rather, it suggests using another standards-based security protocol; rather, it suggests using another standards-based security
protocol. protocol. The details in this document apply only to IPsec-v2.
4. IKE Documents 4. IKE Documents
4.1. Base Documents 4.1. Base Documents
4.1.1. IKEv1 4.1.1. IKEv1
o RFC 2409, The Internet Key Exchange (IKE) (S, Nov. 1998) o RFC 2409, The Internet Key Exchange (IKE) (S, Nov. 1998)
This document defines a key exchange protocol that can be used to This document defines a key exchange protocol that can be used to
skipping to change at page 14, line 44 skipping to change at page 15, line 15
difficult to understand for developers who are not intimately difficult to understand for developers who are not intimately
familiar with the specification and its history. It does not familiar with the specification and its history. It does not
introduce any changes to the protocol, but rather provides introduce any changes to the protocol, but rather provides
descriptions that are less prone to ambiguous interpretations. The descriptions that are less prone to ambiguous interpretations. The
goal of this document is to encourage the development of goal of this document is to encourage the development of
interoperable implementations. interoperable implementations.
o draft-ietf-ipsecme-ikev2bis, Internet Key Exchange Protocol: o draft-ietf-ipsecme-ikev2bis, Internet Key Exchange Protocol:
IKEv2 (S) IKEv2 (S)
This document combines the original IKEv2 RFC [RFC4306] with the [ipsecme-1] combines the original IKEv2 RFC [RFC4306] with the
Clarifications RFC [RFC4718], and resolves many implementation issues Clarifications RFC [RFC4718], and resolves many implementation issues
discovered by the community since the publication of these two discovered by the community since the publication of these two
documents. documents. This document was developed by the IPsecme (IPsec
Maintenance and Extensions) working group, after the conclusion of
the original IPsec working group.
4.2. Additions and Extensions 4.2. Additions and Extensions
4.2.1. Peer Authentication Methods 4.2.1. Peer Authentication Methods
o RFC 4478, Repeated Authentication in Internet Key Exchange o RFC 4478, Repeated Authentication in Internet Key Exchange
(IKEv2) Protocol (E, Apr. 2006) (IKEv2) Protocol (E, Apr. 2006)
[RFC4478] addresses a problem unique to remote access scenarios. How [RFC4478] addresses a problem unique to remote access scenarios. How
can the gateway (the IKE responder) force the remote user (the IKE can the gateway (the IKE responder) force the remote user (the IKE
skipping to change at page 15, line 32 skipping to change at page 16, line 4
each endpoint uses only one of these mechanisms to authenticate each endpoint uses only one of these mechanisms to authenticate
itself. [RFC4739] specifies an extension to IKEv2 that allows the itself. [RFC4739] specifies an extension to IKEv2 that allows the
use of multiple authentication exchanges, using either different use of multiple authentication exchanges, using either different
mechanisms or the same mechanism. This extension allows, for mechanisms or the same mechanism. This extension allows, for
instance, performing certificate-based authentication of the client instance, performing certificate-based authentication of the client
host followed by an EAP authentication of the user. This also allows host followed by an EAP authentication of the user. This also allows
for authentication by multiple administrative domains, if needed. for authentication by multiple administrative domains, if needed.
o RFC 4754, IKE and IKEv2 Authentication Using the Elliptic Curve o RFC 4754, IKE and IKEv2 Authentication Using the Elliptic Curve
Digital Signature Algorithm (ECDSA) (S, Jan. 2007) Digital Signature Algorithm (ECDSA) (S, Jan. 2007)
[RFC4754] describes how the Elliptic Curve Digital Signature [RFC4754] describes how the Elliptic Curve Digital Signature
Algorithm (ECDSA) may be used as the authentication method within the Algorithm (ECDSA) may be used as the authentication method within the
IKEv1 and IKEv2 protocols. ECDSA provides many benefits including IKEv1 and IKEv2 protocols. ECDSA provides many benefits including
computational efficiency, small signature sizes, and minimal computational efficiency, small signature sizes, and minimal
bandwidth compared to other available digital signature methods like bandwidth compared to other available digital signature methods like
RSA and DSA. RSA and DSA.
4.2.2. Certificate Contents and Management (PKI4IPsec) 4.2.2. Certificate Contents and Management (PKI4IPsec)
The format, contents and interpretation of Public Key Certificates
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.
o RFC 4809, Requirements for an IPsec Certificate Management o RFC 4809, Requirements for an IPsec Certificate Management
Profile (I, Feb. 2007) Profile (I, Feb. 2007)
[RFC4809] enumerates requirements for Public Key Certificate (PKC) [RFC4809] enumerates requirements for Public Key Certificate (PKC)
lifecycle transactions between different VPN System and PKI System lifecycle transactions between different VPN System and PKI System
products in order to better enable large scale, PKI-enabled IPsec products in order to better enable large scale, PKI-enabled IPsec
deployments with a common set of transactions. This document deployments with a common set of transactions. This document
discusses requirements for both the IPsec and the PKI products. discusses requirements for both the IPsec and the PKI products.
o RFC 4945, The Internet IP Security PKI Profile of IKEv1/ISAKMP, o RFC 4945, The Internet IP Security PKI Profile of IKEv1/ISAKMP,
skipping to change at page 16, line 20 skipping to change at page 16, line 44
the current state of implementations and deployment and provides the current state of implementations and deployment and provides
advice to avoid common interoperability issues. advice to avoid common interoperability issues.
o RFC 4806, Online Certificate Status Protocol (OCSP) Extensions o RFC 4806, Online Certificate Status Protocol (OCSP) Extensions
to IKEv2 (S, Feb. 2007) to IKEv2 (S, Feb. 2007)
When certificates are used with IKEv2, the communicating peers need a When certificates are used with IKEv2, the communicating peers need a
mechanism to determine the revocation status of the peer's mechanism to determine the revocation status of the peer's
certificate. OCSP is one such mechanism. [RFC4806] defines the certificate. OCSP is one such mechanism. [RFC4806] defines the
"OCSP Content" extension to IKEv2. This document is applicable when "OCSP Content" extension to IKEv2. This document is applicable when
OCSP is desired and security policy (e.g. firewall) prevents one of OCSP is desired and security policy (e.g. firewall policy) prevents
the IKEv2 peers from accessing the relevant OCSP responder directly. one of the IKEv2 peers from accessing the relevant OCSP responder
directly.
4.2.3. Dead Peer Detection 4.2.3. Dead Peer Detection
o RFC 3706, A Traffic-Based Method of Detecting Dead Internet Key o RFC 3706, A Traffic-Based Method of Detecting Dead Internet Key
Exchange (IKE) Peers (I, Feb. 2004) Exchange (IKE) Peers (I, Feb. 2004)
When two peers communicate using IKE and IPsec, it is possible for When two peers communicate using IKE and IPsec, it is possible for
the connectivity between the two peers to drop unexpectedly. But the the connectivity between the two peers to drop unexpectedly. But the
SAs can still remain until their lifetimes expire, resulting in the SAs can still remain until their lifetimes expire, resulting in the
packets getting tunneled into a "black hole". [RFC3706] describes an packets getting tunneled into a "black hole". [RFC3706] describes an
approach to detect peer liveliness without needing to send messages approach to detect peer liveliness without needing to send messages
at regular intervals. This RFC defines an optional extension to at regular intervals. This RFC defines an optional extension to
IKEv1; dead peer detection (DPD) is an integral part of IKEv2. IKEv1; dead peer detection (DPD) is an integral part of IKEv2.
skipping to change at page 16, line 38 skipping to change at page 17, line 17
When two peers communicate using IKE and IPsec, it is possible for When two peers communicate using IKE and IPsec, it is possible for
the connectivity between the two peers to drop unexpectedly. But the the connectivity between the two peers to drop unexpectedly. But the
SAs can still remain until their lifetimes expire, resulting in the SAs can still remain until their lifetimes expire, resulting in the
packets getting tunneled into a "black hole". [RFC3706] describes an packets getting tunneled into a "black hole". [RFC3706] describes an
approach to detect peer liveliness without needing to send messages approach to detect peer liveliness without needing to send messages
at regular intervals. This RFC defines an optional extension to at regular intervals. This RFC defines an optional extension to
IKEv1; dead peer detection (DPD) is an integral part of IKEv2. IKEv1; dead peer detection (DPD) is an integral part of IKEv2.
4.2.4. Remote Access 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
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.
o draft-ietf-ipsecme-ikev2-resumption, IKEv2 Session Resumption o draft-ietf-ipsecme-ikev2-resumption, IKEv2 Session Resumption
(S) (S)
This document enables a remote client that has been disconnected from [ipsecme-4] enables a remote client that has been disconnected from a
a gateway to re-establish SAs with the gateway in an expedited gateway to re-establish SAs with the gateway in an expedited manner,
manner, without repeating the complete IKEv2 negotiation. This without repeating the complete IKEv2 negotiation. This capability
capability requires changes to IKEv2. requires changes to IKEv2.
o draft-ietf-ipsecme-ikev2-redirect, Re-direct Mechanism for IKEv2 o draft-ietf-ipsecme-ikev2-redirect, Re-direct Mechanism for IKEv2
(S) (S)
This document enables a gateway to securely re-direct VPN clients to [ipsecme-3] enables a gateway to securely re-direct VPN clients to
another VPN gateway, either during or after the IKEv2 negotiation. another VPN gateway, either during or after the IKEv2 negotiation.
Possible reasons include, but are not limited to, an overloaded Possible reasons include, but are not limited to, an overloaded
gateway or a gateway that needs to shut down. This requires changes gateway or a gateway that needs to shut down. This requires changes
to IKEv2. to IKEv2.
o draft-ietf-ipsecme-ikev2-ipv6-config, IPv6 Configuration in o draft-ietf-ipsecme-ikev2-ipv6-config, IPv6 Configuration in
IKEv2 (S) IKEv2 (S)
In IKEv2, a VPN gateway can assign an internal network address to a In IKEv2, a VPN gateway can assign an internal network address to a
remote VPN client. This is accomplished through the use of remote VPN client. This is accomplished through the use of
configuration payloads. For an IPv6 client, the assignment of a configuration payloads. For an IPv6 client, the assignment of a
single address is not sufficient to enable full-fledged IPv6 single address is not sufficient to enable full-fledged IPv6
communications. This document proposes several solutions that might communications. [psecme-2] proposes several solutions that might
remove this limitation. remove this limitation.
5. Cryptographic Algorithms and Suites 5. Cryptographic Algorithms and Suites
Two basic requirements must be met for an algorithm to be used within Two basic requirements must be met for an algorithm to be used within
IKE and/or IPsec: assignment of one or more IANA values and an RFC IKE and/or IPsec: assignment of one or more IANA values and an RFC
that describes how to use the algorithm within the relevant protocol, that describes how to use the algorithm within the relevant protocol,
packet formats, special considerations, etc. For each RFC that packet formats, special considerations, etc. For each RFC that
describes a cryptographic algorithm, this document will classify its describes a cryptographic algorithm, this document will classify its
Requirements Level for each protocol, as either MUST, SHALL or MAY Requirements Level for each protocol, as either MUST, SHALL or MAY
skipping to change at page 18, line 17 skipping to change at page 18, line 50
mandatory-to-implement (MUST), recommended (SHOULD), optional (MAY), mandatory-to-implement (MUST), recommended (SHOULD), optional (MAY),
and deprecated (SHOULD NOT) algorithms. For IPsec-v2, this is and deprecated (SHOULD NOT) algorithms. For IPsec-v2, this is
included in the base protocol RFC. That was originally the case for included in the base protocol RFC. That was originally the case for
IKEv1, but IKEv1's algorithm requirements were updated in [RFC4109]. IKEv1, but IKEv1's algorithm requirements were updated in [RFC4109].
o RFC 4835, Cryptographic Algorithm Implementation Requirements o RFC 4835, Cryptographic Algorithm Implementation Requirements
for Encapsulating Security Payload (ESP) and Authentication for Encapsulating Security Payload (ESP) and Authentication
Header (AH) (S, Apr. 2007) Header (AH) (S, Apr. 2007)
[RFC4835] specifies the encryption and integrity-protection [RFC4835] specifies the encryption and integrity-protection
algorithms for IPsec (both versions). Combined mode algorithms are algorithms for IPsec (both versions). Algorithms for IPsec-v2 were
mentioned, but not assigned a requirement level. originally defined in [RFC2402] and [RFC2406]. [RFC4305] obsoleted
those requirements, and was in turn obsoleted by [RFC4835].
NOTE: Algorithms for IPsec-v2 were originally defined in [RFC2402] Therefore, [RFC4835] applies to IPsec-v2 as well as IPsec-v3.
and [RFC2406]. [RFC4305] obsoleted those requirements, and was in Combined mode algorithms are mentioned, but not assigned a
turn obsoleted by [RFC4835]. Therefore, by inference [RFC4835] requirement level.
applies to IPsec-v2 as well as IPsec-v3.
o RFC 4307, Cryptographic Algorithms for Use in the Internet Key o RFC 4307, Cryptographic Algorithms for Use in the Internet Key
Exchange Version 2 (IKEv2) (S, Dec. 2005) Exchange Version 2 (IKEv2) (S, Dec. 2005)
[RFC4307] specifies the encryption and integrity-protection [RFC4307] specifies the encryption and integrity-protection
algorithms used by IKEv2 to protect its own traffic; the algorithms used by IKEv2 to protect its own traffic; the
Diffie-Hellman (DH) groups used within IKEv2; and the pseudo-random Diffie-Hellman (DH) groups used within IKEv2; and the pseudo-random
functions used by IKEv2 to generate keys, nonces and other random functions used by IKEv2 to generate keys, nonces and other random
values. It also specifies the encryption and integrity-protection values. It also specifies the encryption and integrity-protection
algorithms that IKEv2 negotiates for use within IPsec. algorithms that IKEv2 negotiates for use within IPsec.
skipping to change at page 19, line 12 skipping to change at page 19, line 43
encrypt IKE and/or ESP traffic, providing confidentiality protection encrypt IKE and/or ESP traffic, providing confidentiality protection
to the traffic. They describe any special constraints, requirements, to the traffic. They describe any special constraints, requirements,
or changes to packet format appropriate for the specific algorithm. or changes to packet format appropriate for the specific algorithm.
In general, they do not describe the detailed algorithmic In general, they do not describe the detailed algorithmic
computations; the reference section of each RFC includes pointers to computations; the reference section of each RFC includes pointers to
documents that define the inner workings of the algorithm. Some of documents that define the inner workings of the algorithm. Some of
the RFCs include sample test data, to enable implementors to compare the RFCs include sample test data, to enable implementors to compare
their results with standardized output. their results with standardized output.
When any encryption algorithm is used to provide confidentiality, the When any encryption algorithm is used to provide confidentiality, the
use of integrity(protection is strongly recommended. If the use of integrity-protection is strongly recommended. If the
encryption algorithm is a stream cipher, omitting encryption algorithm is a stream cipher, omitting
integrity-protection seriously compromises the security properties of integrity-protection seriously compromises the security properties of
the algorithm. the algorithm.
DES, as described in [RFC2405], was originally a required 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 for IKEv1 and ESP-v2. Since the use of DES is now deprecated, this
roadmap does not include [RFC2405]. roadmap does not include [RFC2405].
o RFC 2410, The NULL Encryption Algorithm and Its Use With IPsec o RFC 2410, The NULL Encryption Algorithm and Its Use With IPsec
(S, Nov. 1998) (S, Nov. 1998)
[RFC2410] is a tongue-in-cheek description of the no-op encryption [RFC2410] is a tongue-in-cheek description of the no-op encryption
algorithm (i.e. using ESP without encryption). In order for IKE to algorithm (i.e. using ESP without encryption). In order for IKE to
negotiate the selection of the NULL encryption algorithm for use in negotiate the selection of the NULL encryption algorithm for use in
an ESP SA, an identifying IANA number is needed. This number (the 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 value 11 for ESP_NULL) is found on the IANA registries for both IKEv1
and IKEv2, but it is not mentioned in this RFC. and IKEv2, but it is not mentioned in this RFC.
Requirements levels for ESP-NULL: IKEv1 - N/A; IKEv2 - N/A; ESP-v2 - Requirements levels for ESP-NULL:
MUST [RFC4835]; ESP-v3 - MUST [RFC4835] IKEv1 - N/A
IKEv2 - N/A
NOTE: [RFC4307] lists ESP-NULL as MAY for ESP-v3, which conflicts ESP-v2 - MUST [RFC4835]
with the MUST in [RFC4835]. ESP-v3 - MUST [RFC4835]
o RFC 2451, The ESP CBC-Mode Cipher Algorithms (S, Nov. 1998) o RFC 2451, The ESP CBC-Mode Cipher Algorithms (S, Nov. 1998)
[RFC2451] describes how to use encryption algorithms in cipher block [RFC2451] describes how to use encryption algorithms in cipher block
chaining (CBC) mode to encrypt IKE and ESP traffic. It specifically chaining (CBC) mode to encrypt IKE and ESP traffic. It specifically
mentions Blowfish, CAST-128, Triple DES (3DES), IDEA and RC5, but it mentions Blowfish, CAST-128, Triple DES (3DES), IDEA and RC5, but it
is applicable to any block cipher algorithm used in CBC mode. The 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 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 64-bit random IV that is sent in the packet along with the encrypted
data. data.
Requirements levels for 3DES-CBC: IKEv1 - MUST [RFC4109]; IKEv2 - Requirements levels for 3DES-CBC:
MUST- [RFC4307]; ESP-v2 - MUST [RFC4835]; ESP-v3 - MUST- [RFC4835] IKEv1 - MUST [RFC4109]
IKEv2 - MUST- [RFC4307]
ESP-v2 - MUST [RFC4835]
ESP-v3 - MUST- [RFC4835]
Requirements levels for other CBC algorithms (Blowfish, CAST, IDEA, Requirements levels for other CBC algorithms (Blowfish, CAST, IDEA,
RC5): IKEv1 - optional; IKEv2 - optional; ESP-v2 - optional; ESP-v3 - RC5):
optional IKEv1 - optional
IKEv2 - optional
ESP-v2 - optional
ESP-v3 - optional
o RFC 3602, The AES-CBC Cipher Algorithm and Its Use with IPsec o RFC 3602, The AES-CBC Cipher Algorithm and Its Use with IPsec
(S, Sep. 2003) (S, Sep. 2003)
[RFC3602] describes how to use AES in cipher block chaining (CBC) [RFC3602] describes how to use AES in cipher block chaining (CBC)
mode to encrypt IKE and ESP traffic. AES is the successor to DES. 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 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 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 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 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 ESP-v2. A single IANA value is defined for AES-CBC, so IKE
negotiations need to specify the keysize. negotiations need to specify the keysize.
Requirements levels for AES-CBC with 128-bit keys: IKEv1 - SHOULD Requirements levels for AES-CBC with 128-bit keys:
[RFC4109]; IKEv2 - SHOULD+ [RFC4307]; ESP-v2 - MUST [RFC4835]; ESP-v3 IKEv1 - SHOULD [RFC4109]
- MUST [RFC4835] IKEv2 - SHOULD+ [RFC4307]
ESP-v2 - MUST [RFC4835]
ESP-v3 - MUST [RFC4835]
Requirements levels for AES-CBC with 192- or 256-bit keys: IKEv1 - Requirements levels for AES-CBC with 192- or 256-bit keys:
optional; IKEv2 - optional; ESP-v2 - optional; ESP-v3 - optional IKEv1 - optional
IKEv2 - optional
ESP-v2 - optional
ESP-v3 - optional
o RFC 3686, Using Advanced Encryption Standard (AES) Counter Mode o RFC 3686, Using Advanced Encryption Standard (AES) Counter Mode
With IPsec Encapsulating Security Payload (ESP) (S, Jan. 2004) With IPsec Encapsulating Security Payload (ESP) (S, Jan. 2004)
[RFC3686] describes how to use AES in counter (CTR) mode to encrypt [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 ESP traffic. AES-CTR is a stream cipher with a 32-bit random nonce
(1/SA) and a 64-bit IV, both of which are sent in the packet along (1/SA) and a 64-bit IV, both of which are sent in the packet along
with the encrypted data. 128-bit keys are MUST; 192- and 256-byte with the encrypted data. 128-bit keys are MUST; 192- and 256-byte
keys are MAY. Reuse of the IV with the same key and nonce 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 compromises the data's security; thus, AES-CTR should not be used
with manual keying. AES-CTR can be pipelined and parallelized; it with manual keying. AES-CTR can be pipelined and parallelized; it
uses only the AES encryption operations for both encryption and uses only the AES encryption operations for both encryption and
decryption. decryption.
Requirements levels for AES-CTR: IKEv1 - not defined (no IANA #); Requirements levels for AES-CTR:
IKEv2 - optional or not defined (see NOTE); ESP-v2 - SHOULD IKEv1 - not defined (no IANA #)
[RFC4835]; ESP-v3 - SHOULD [RFC4835] IKEv2 - not defined (no RFC)
ESP-v2 - SHOULD [RFC4835]
NOTE: AES-CTR does not have an IANA number for IKEv1; since the same ESP-v3 - SHOULD [RFC4835]
IANA numbers are used for IKEv2 and IPsec-v3, does [RFC3686] suffice
to define the use of AES-CTR within IKEv2?
o RFC 4312, The Camellia Cipher Algorithm and Its Use with IPsec o RFC 4312, The Camellia Cipher Algorithm and Its Use with IPsec
(S, Dec. 2005) (S, Dec. 2005)
[RFC4312] describes how to use Camellia in cipher block chaining [RFC4312] describes how to use Camellia in cipher block chaining
(CBC) mode to encrypt IKE and ESP traffic. Camellia-CBC is a (CBC) mode to encrypt IKE and ESP traffic. Camellia-CBC is a
block-mode cipher with a 128-bit blocksize; a random IV that is sent block-mode cipher with a 128-bit blocksize; a random IV that is sent
in the packet along with the encrypted data; and keysizes of 128, 192 in the packet along with the encrypted data; and keysizes of 128, 192
and 256 bits. 128-bit keys are MUST; the other sizes are MAY. and 256 bits. 128-bit keys are MUST; the other sizes are MAY.
[RFC4312] includes IANA values for use in IKEv1 and IPsec-v2. A [RFC4312] includes IANA values for use in IKEv1 and IPsec-v2. A
single IANA value is defined for Camellia-CBC, so IKEv1 negotiations single IANA value is defined for Camellia-CBC, so IKEv1 negotiations
need to specify the keysize. need to specify the keysize.
Requirements levels for Camellia-CBC: IKEv1 - optional; IKEv2 - not o RFC 5529, Modes of Operation for Camellia for Use with IPsec (S,
defined (no IANA #); ESP-v2 - optional; ESP-v3 - not defined (no IANA 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. 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 - not defined (no RFC)
ESP-v2 - optional
ESP-v3 - optional
Requirements levels for Camellia-CTR:
IKEv1 - not defined (no IANA #)
IKEv2 - not defined (no RFC)
ESP-v2 - not defined (no IANA #)
ESP-v3 - optional
Requirements levels for Camellia-CCM:
IKEv1 - N/A
IKEv2 - not defined (no RFC)
ESP-v2 - N/A
ESP-v3 - optional
o 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 - not defined (no IANA #)
IKEv2 - not defined (no IANA #)
ESP-v2 - optional
ESP-v3 - not defined (no IANA #)
5.3. Integrity-Protection (Authentication) Algorithms 5.3. Integrity-Protection (Authentication) Algorithms
The integrity-protection algorithm RFCs describe how to use these The integrity-protection algorithm RFCs describe how to use these
algorithms to authenticate IKE and/or IPsec traffic, providing algorithms to authenticate IKE and/or IPsec traffic, providing
integrity protection to the traffic. This protection is provided by integrity protection to the traffic. This protection is provided by
computing an Integrity Check Value (ICV), which is sent in the computing an Integrity Check Value (ICV), which is sent in the
packet. The RFCs describe any special constraints, requirements, or packet. The RFCs describe any special constraints, requirements, or
changes to packet format appropriate for the specific algorithm. In changes to packet format appropriate for the specific algorithm. In
general, they do not describe the detailed algorithmic computations; general, they do not describe the detailed algorithmic computations;
skipping to change at page 21, line 36 skipping to change at page 23, line 27
with standardized output. with standardized output.
o RFC 2404, The Use of HMAC-SHA-1-96 within ESP and AH (S, Nov. o RFC 2404, The Use of HMAC-SHA-1-96 within ESP and AH (S, Nov.
1998) 1998)
[RFC2404] describes HMAC-SHA-1, an integrity-protection algorithm [RFC2404] describes HMAC-SHA-1, an integrity-protection algorithm
with a 512-bit blocksize, and a 160-bit key and Integrity Check Value 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 (ICV). For use within IPsec, the ICV is truncated to 96 bits. This
is currently the most commonly-used integrity-protection algorithm. is currently the most commonly-used integrity-protection algorithm.
Requirements levels for HMAC-SHA-1: IKEv1 - MUST [RFC4109]; IKEv2 - Requirements levels for HMAC-SHA-1:
MUST [RFC4307]; IPsec-v2 - MUST [RFC4835]; IPsec-v3 - MUST [RFC4835] IKEv1 - MUST [RFC4109]
IKEv2 - MUST [RFC4307]
IPsec-v2 - MUST [RFC4835]
IPsec-v3 - MUST [RFC4835]
o RFC 3566, The AES-XCBC-MAC-96 Algorithm and Its Use With IPsec o RFC 3566, The AES-XCBC-MAC-96 Algorithm and Its Use With IPsec
(S, Sep. 2003) (S, Sep. 2003)
[RFC3566] describes AES-XCBC-MAC, a variant of CBC-MAC which is [RFC3566] describes AES-XCBC-MAC, a variant of CBC-MAC which is
secure for messages of varying lengths (unlike classic CBC-MAC). It secure for messages of varying lengths (unlike classic CBC-MAC). It
is an integrity-protection algorithm with a 128-bit blocksize, and a 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 128-bit key and ICV. For use within IPsec, the ICV is truncated to
96 bits. [RFC3566] includes test data. 96 bits. [RFC3566] includes test data.
Requirements levels for AES-XCBC-MAC: IKEv1 - SHOULD [RFC4109]; IKEv2 Requirements levels for AES-XCBC-MAC:
- optional; IPsec-v2 - SHOULD+ [RFC4835]; IPsec-v3 - SHOULD+ IKEv1 - SHOULD [RFC4109]
[RFC4835] IKEv2 - optional
IPsec-v2 - SHOULD+ [RFC4835]
IPsec-v3 - SHOULD+ [RFC4835]
o RFC 4868, Using HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 o RFC 4868, Using HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512
with IPsec (S, May 2007) with IPsec (S, May 2007)
[RFC4868] describes a family of algorithms, successors to HMAC-SHA-1. [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-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-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. 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 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 original size (128 bits, 192 bits, or 256 bits). Each of the three
algorithms has its own IANA value, so IKE does not have to negotiate algorithms has its own IANA value, so IKE does not have to negotiate
the keysize. the keysize.
Requirements levels for HMAC-SHA-256, HMAC-SHA-384, HMC-SHA-512: Requirements levels for HMAC-SHA-256, HMAC-SHA-384, HMC-SHA-512:
IKEv1 - optional; IKEv2 - optional; IPsec-v2 - optional; IPsec-v3 - IKEv1 - optional
optional IKEv2 - optional
IPsec-v2 - optional
IPsec-v3 - optional
o RFC 4543, The Use of Galois Message Authentication Code (GMAC) o RFC 4543, The Use of Galois Message Authentication Code (GMAC)
in IPsec ESP and AH (S, May 2006) in IPsec ESP and AH (S, May 2006)
[RFC4543] is the variant of AES-GCM [RFC4106] that provides [RFC4543] is the variant of AES-GCM [RFC4106] that provides
integrity-protection without encryption. It has two versions: an integrity-protection without encryption. It has two versions: an
integrity-protection algorithm for use within AH-v3, and a integrity-protection algorithm for use within AH-v3, and a
combined-mode algorithm with null encryption for use within ESP-v3. 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 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 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 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 IKEv2 during the key generation process. Reuse of the salt value
with the same key compromises the data's security; thus, AES-GMAC 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 should not be used with manual keying. For use within AH-v3, each
keysize has its own IANA value, so IKE does not have to negotiate the keysize has its own IANA value, so IKE does not have to negotiate the
keysize. For use within ESP-v3, there is only one IANA value, so IKE keysize. For use within ESP-v3, there is only one IANA value, so IKE
negotiations must specify the keysize. negotiations must specify the keysize.
Requirements levels for AES-GMAC: IKEv1 - N/A; IKEv2 - optional; Requirements levels for AES-GMAC:
IPsec-v2 - not defined (no IANA #); IPsec-v3 - optional IKEv1 - N/A
IKEv2 - optional
IPsec-v2 - not defined (no IANA #)
IPsec-v3 - optional
o RFC 2403, The Use of HMAC-MD5-96 within ESP and AH (S, Nov. o RFC 2403, The Use of HMAC-MD5-96 within ESP and AH (S, Nov.
1998) 1998)
[RFC2403] describes HMAC-MD5, an integrity-protection algorithm with [RFC2403] describes HMAC-MD5, an integrity-protection algorithm with
a 512-bit blocksize, and a 128-bit key and Integrity Check Value 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 (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 was a required algorithm for IKEv1 and IPsec-v2. The use of plain
MD5 is now deprecated, but [RFC4835] states: "Weaknesses have become MD5 is now deprecated, but [RFC4835] states: "Weaknesses have become
apparent in MD5; however, these should not affect the use of MD5 with apparent in MD5; however, these should not affect the use of MD5 with
HMAC." HMAC."
Requirements levels for HMAC-MD5: IKEv1 - MAY [RFC4109]; IKEv2 - Requirements levels for HMAC-MD5:
optional [RFC4307]; IPsec-v2 - MAY [RFC4835]; IPsec-v3 - MAY
[RFC4835] IKEv1 - MAY [RFC4109]
IKEv2 - optional [RFC4307]
IPsec-v2 - MAY [RFC4835]
IPsec-v3 - MAY [RFC4835]
o RFC 4494, The AES-CMAC-96 Algorithm and Its Use with IPsec (S, o RFC 4494, The AES-CMAC-96 Algorithm and Its Use with IPsec (S,
Jun. 2006) Jun. 2006)
[RFC4494] describes AES-CMAC, another variant of CBC-MAC which is [RFC4494] describes AES-CMAC, another variant of CBC-MAC which is
secure for messages of varying lengths. It is an secure for messages of varying lengths. It is an
integrity-protection algorithm with a 128-bit blocksize, and 128-bit 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. key and ICV. For use within IPsec, the ICV is truncated to 96 bits.
[RFC4494] includes test data. [RFC4494] includes test data.
Requirements levels for AES-CMAC: IKEv1 - not defined (no IANA #); Requirements levels for AES-CMAC:
IKEv2 - optional; IPsec-v2 - not defined (no IANA #); IPsec-v3 - IKEv1 - not defined (no IANA #)
optional IKEv2 - optional
IPsec-v2 - not defined (no IANA #)
IPsec-v3 - optional
o RFC 2857, The Use of HMAC-RIPEMD-160-96 within ESP and AH (S, o RFC 2857, The Use of HMAC-RIPEMD-160-96 within ESP and AH (S,
Jun. 2000) Jun. 2000)
[RFC2857] describes HMAC-RIPEMD, an integrity-protection algorithm [RFC2857] describes HMAC-RIPEMD, an integrity-protection algorithm
with a 512-bit blocksize, and a 160-bit key and ICV. For use within with a 512-bit blocksize, and a 160-bit key and ICV. For use within
IPsec, the ICV is truncated to 96 bits. IPsec, the ICV is truncated to 96 bits.
Requirements levels for HMAC-RIPEMD: IKEv1 - not defined (no IANA #); Requirements levels for HMAC-RIPEMD:
IKEv2 - not defined (no IANA #); IPsec-v2 - optional; IPsec-v3 - not IKEv1 - not defined (no IANA #)
defined (no IANA #) IKEv2 - not defined (no IANA #)
IPsec-v2 - optional
IPsec-v3 - not defined (no IANA #)
5.3.1. General Considerations 5.3.1. General Considerations
o RFC 4894, Use of Hash Algorithms in Internet Key Exchange (IKE) o RFC 4894, Use of Hash Algorithms in Internet Key Exchange (IKE)
and IPsec (I, May 2007) and IPsec (I, May 2007)
In light of recent attacks on MD5 and SHA-1, [RFC4894] examines In light of recent attacks on MD5 and SHA-1, [RFC4894] examines
whether it is necessary to replace the hash functions currently used whether it is necessary to replace the hash functions currently used
by IKE and IPsec for key generation, integrity-protection, digital by IKE and IPsec for key generation, integrity-protection, digital
signatures, or PKIX certificates. It concludes that the algorithms signatures, or PKIX certificates. It concludes that the algorithms
skipping to change at page 24, line 34 skipping to change at page 26, line 39
salt value is generated by IKEv2 during the key generation process. salt value is generated by IKEv2 during the key generation process.
Reuse of the IV with the same key compromises the data's security; Reuse of the IV with the same key compromises the data's security;
thus, AES-CCM should not be used with manual keying. [RFC4309] thus, AES-CCM should not be used with manual keying. [RFC4309]
includes IANA values for use in ESP-v3. Each of the three ICV includes IANA values for use in ESP-v3. Each of the three ICV
lengths has its own IANA value, but IKEv2 negotiations need to lengths has its own IANA value, but IKEv2 negotiations need to
specify the keysize. [RFC4309] includes test data. [RFC4309] specify the keysize. [RFC4309] includes test data. [RFC4309]
describes how IKEv2 can negotiate the use of AES-CCM to use in an 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 ESP-v3 SA. [RFC5282] extends this to the use of AES-CCM to protect
an IKEv2 SA. an IKEv2 SA.
Requirements levels for AES-CCM: IKEv1 - N/A; IKEv2 - optional; Requirements levels for AES-CCM:
ESP-v2 - N/A; ESP-v3 - optional [RFC4835] 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 NOTE: The IPsec-v2 IANA registry includes values for AES-CCM, but
combined-mode algorithms are not a feature of IPsec-v2. combined-mode algorithms are not a feature of IPsec-v2.
o RFC 4106, The Use of Galois/Counter Mode (GCM) in IPsec o RFC 4106, The Use of Galois/Counter Mode (GCM) in IPsec
Encapsulating Security Payload (ESP) (S, Jun. 2005) Encapsulating Security Payload (ESP) (S, Jun. 2005)
[RFC4106] describes how to use AES in Galois/Counter (GCM) mode, a [RFC4106] describes how to use AES in Galois/Counter (GCM) mode, a
combined alorithm, to encrypt and integrity-protect ESP-v3 traffic. combined alorithm, to encrypt and integrity-protect ESP-v3 traffic.
AES-GCM is a block-mode cipher with a 128-bit blocksize; a random IV AES-GCM is a block-mode cipher with a 128-bit blocksize; a random IV
that is sent in the packet along with the encrypted data; a 32-bit that is sent in the packet along with the encrypted data; a 32-bit
salt value (1/SA); keysizes of 128, 192 and 256 bits; and ICV sizes salt value (1/SA); keysizes of 128, 192 and 256 bits; and ICV sizes
of 64, 96 and 128 bits. 128-bit keys are MUST; the other sizes are of 64, 96 and 128 bits. 128-bit keys are MUST; the other sizes are
MAY. An ICV size of 128 bits is a MUST; 64 and 96 bits are MAY. The MAY. An ICV size of 128 bits is a MUST; 64 and 96 bits are MAY. The
salt value is generated by IKEv2 during the key generation process. salt value is generated by IKEv2 during the key generation process.
Reuse of the IV with the same key compromises the data's security; Reuse of the IV with the same key compromises the data's security;
thus, AES-GCM should not be used with manual keying. [RFC4106] thus, AES-GCM should not be used with manual keying. [RFC4106]
skipping to change at page 25, line 12 skipping to change at page 27, line 21
salt value is generated by IKEv2 during the key generation process. salt value is generated by IKEv2 during the key generation process.
Reuse of the IV with the same key compromises the data's security; Reuse of the IV with the same key compromises the data's security;
thus, AES-GCM should not be used with manual keying. [RFC4106] thus, AES-GCM should not be used with manual keying. [RFC4106]
includes IANA values for use in ESP-v3. Each of the three ICV includes IANA values for use in ESP-v3. Each of the three ICV
lengths has its own IANA value, but IKEv2 negotiations need to lengths has its own IANA value, but IKEv2 negotiations need to
specify the keysize. [RFC4106] includes test data. [RFC4106] specify the keysize. [RFC4106] includes test data. [RFC4106]
describes how IKEv2 can negotiate the use of AES-GCM to use in an 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 ESP-v3 SA. [RFC5282] extends this to the use of AES-GCM to protect
an IKEv2 SA. an IKEv2 SA.
Requirements levels for AES-GCM: IKEv1 - N/A; IKEv2 - optional; Requirements levels for AES-GCM:
ESP-v2 - N/A; ESP-v3 - optional [RFC4835] IKEv1 - N/A
IKEv2 - optional
ESP-v2 - N/A
ESP-v3 - optional [RFC4835]
NOTE: The IPsec-v2 IANA registry includes values for AES-GCM, but NOTE: The IPsec-v2 IANA registry includes values for AES-GCM, but
combined-mode algorithms are not a feature of IPsec-v2. combined-mode algorithms are not a feature of IPsec-v2.
5.4.1. General Considerations 5.4.1. General Considerations
o RFC 5282, Using Authenticated Encryption Algorithms with the o RFC 5282, Using Authenticated Encryption Algorithms with the
Encrypted Payload of the Internet Key Exchange version 2 (IKEv2) Encrypted Payload of the Internet Key Exchange version 2 (IKEv2)
Protocol (S, Aug. 2008) Protocol (S, Aug. 2008)
skipping to change at page 25, line 39 skipping to change at page 28, line 5
IKE uses pseudo-random functions (PRFs) to generate the secret keys IKE uses pseudo-random functions (PRFs) to generate the secret keys
that are used in IKE SAs and IPsec SAs. These PRFs are generally the that are used in IKE SAs and IPsec SAs. These PRFs are generally the
same algorithms used for integrity-protection, but their output is same algorithms used for integrity-protection, but their output is
not truncated, since all of the generated bits are generally needed not truncated, since all of the generated bits are generally needed
for the keys. If the PRF's output is not long enough to supply the for the keys. If the PRF's output is not long enough to supply the
required number of bits of keying material, the PRF is applied required number of bits of keying material, the PRF is applied
iteratively until the requisite amount of keying material is iteratively until the requisite amount of keying material is
generated. generated.
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]
o RFC 4434, The AES-XCBC-PRF-128 Algorithm for the Internet Key o RFC 4434, The AES-XCBC-PRF-128 Algorithm for the Internet Key
Exchange Protocol (IKE) (S, Feb. 2006) Exchange Protocol (IKE) (S, Feb. 2006)
[RFC3566] defines AES-XCBC-MAC-96, which is used for integrity [RFC3566] defines AES-XCBC-MAC-96, which is used for integrity
protection within IKE and IPsec. [RFC4434] enables the use of protection within IKE and IPsec. [RFC4434] enables the use of
AES-XCBC-MAC as a PRF within IKE. The PRF differs from the 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 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 truncated to 96 bits; and it accepts a variable-length key, which is
modified (lengthened via padding or shortened through application of modified (lengthened via padding or shortened through application of
AES-XCBC) to a 128-bit key. [RFC4434] includes test data. AES-XCBC) to a 128-bit key. [RFC4434] includes test data.
Requirements levels for AES-XCBC-PRF: IKEv1 - SHOULD [RFC4109]; IKEv2 Requirements levels for AES-XCBC-PRF:
- SHOULD+ [RFC4307] IKEv1 - SHOULD [RFC4109]
IKEv2 - SHOULD+ [RFC4307]
o RFC 4615, The Advanced Encryption Standard-Cipher-based Message o RFC 4615, The Advanced Encryption Standard-Cipher-based Message
Authentication Code-Pseudo-Random Function-128 Authentication Code-Pseudo-Random Function-128
(AES-CMAC-PRF-128) Algorithm for the Internet Key Exchange (AES-CMAC-PRF-128) Algorithm for the Internet Key Exchange
Protocol (IKE) (S, Aug. 2006) Protocol (IKE) (S, Aug. 2006)
[RFC4615] extends [RFC4494] to enable the use of AES-CMAC as a PRF [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 within IKEv2, in a manner analogous to that used by [RFC4434] for
AES-XCBC. AES-XCBC.
Requirements levels for AES-CMAC-PRF: IKEv1 - not defined (no IANA Requirements levels for AES-CMAC-PRF:
#); IKEv2 - optional IKEv1 - not defined (no IANA #)
IKEv2 - optional
5.6. Cryptographic Suites 5.6. Cryptographic Suites
o RFC 4308, Cryptographic Suites for IPsec (S, Dec. 2005) o RFC 4308, Cryptographic Suites for IPsec (S, Dec. 2005)
An IKE negotiation consists of multiple cryptographic attributes, An IKE negotiation consists of multiple cryptographic attributes,
both for the IKE SA and for the IPsec SA. The infinite number of both for the IKE SA and for the IPsec SA. The number of possible
possible combinations can pose a challenge to peers trying to find a combinations can pose a challenge to peers trying to find a common
common policy. To enhance interoperability, [RFC4308] defines two policy. To enhance interoperability, [RFC4308] defines two
pre-defined suites, consisting of combinations of algorithms that pre-defined suites, consisting of combinations of algorithms that
comprise typical security policies. IKE/ESP suite "VPN-A" includes comprise typical security policies. IKE/ESP suite "VPN-A" includes
use of 3DES, HMAC-SHA-1, and 1024-bit MODP Diffie-Hellman (DH); use of 3DES, HMAC-SHA-1, and 1024-bit MODP Diffie-Hellman (DH);
IKE/ESP suite "VPN-B" includes AES-CBC, AES-XCBC-MAC, and 2048-bit IKE/ESP suite "VPN-B" includes AES-CBC, AES-XCBC-MAC, and 2048-bit
MODP DH. These suites are intended to be named "single-button" MODP DH. These suites are intended to be named "single-button"
choices in the administrative interface, but do not prevent the use choices in the administrative interface, but do not prevent the use
of alternative combinations. of alternative combinations.
o RFC 4869, Suite B Cryptographic Suites for IPsec (I, May 2007) o RFC 4869, Suite B Cryptographic Suites for IPsec (I, May 2007)
skipping to change at page 27, line 9 skipping to change at page 29, line 31
IKE negotiations include a Diffie-Hellman exchange, which establishes IKE negotiations include a Diffie-Hellman exchange, which establishes
a shared secret, to which both parties contributed. This value is a shared secret, to which both parties contributed. This value is
used to generate keying material to protect both the IKE SA and the used to generate keying material to protect both the IKE SA and the
IPsec SA. IPsec SA.
IKEv1 [RFC2409] contains definitions of 2 DH MODP groups and 2 IKEv1 [RFC2409] contains definitions of 2 DH MODP groups and 2
elliptic curve (EC) groups; IKEv2 [RFC4306] only references the MODP elliptic curve (EC) groups; IKEv2 [RFC4306] only references the MODP
groups. The requirements levels of these groups are: groups. The requirements levels of these groups are:
Requirements levels for DH MODP group 1: IKEv1 - MAY [RFC4109]; IKEv2 Requirements levels for DH MODP group 1:
- optional IKEv1 - MAY [RFC4109]
IKEv2 - optional
Requirements levels for DH MODP group 2: IKEv1 - MUST [RFC4109]; Requirements levels for DH MODP group 2:
IKEv1 - MUST [RFC4109]
IKEv2 - MUST- [RFC4307] IKEv2 - MUST- [RFC4307]
Requirements levels for EC groups 3-4: IKEv1 - MAY [RFC4109]; IKEv2 - Requirements levels for EC groups 3-4:
not defined (no IANA #) IKEv1 - MAY [RFC4109]
IKEv2 - not defined (no IANA #)
o RFC 3526, More Modular Exponential (MODP) Diffie-Hellman groups o RFC 3526, More Modular Exponential (MODP) Diffie-Hellman groups
for Internet Key Exchange (IKE) (S, May 2003) for Internet Key Exchange (IKE) (S, May 2003)
[RFC2409] and [RFC4306] define 2 MODP DH groups (groups 1 and 2) for [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). 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 Group 14 is a 2048-bit group that is strongly recommended for use in
IKE. IKE.
Requirements levels for DH MODP group 14: IKEv1 - SHOULD [RFC4109]; Requirements levels for DH MODP group 14:
IKEv1 - SHOULD [RFC4109]
IKEv2 - SHOULD+ [RFC4307] IKEv2 - SHOULD+ [RFC4307]
Requirements levels for DH MODP groups 5, 15-18: IKEv1 - optional Requirements levels for DH MODP groups 5, 15-18:
[RFC4109]; IKEv2 - optional IKEv1 - optional [RFC4109]
IKEv2 - optional
o RFC 4753, ECP Groups For IKE and IKEv2 (I, Jan. 2007) o RFC 4753, ECP Groups For IKE and IKEv2 (I, Jan. 2007)
[RFC4753] defines 3 EC DH groups (groups 19-21) for use within IKE. [RFC4753] defines 3 EC DH groups (groups 19-21) for use within IKE.
The document includes test data. The document includes test data.
Requirements levels for DH EC groups 19-21: IKEv1 - optional Requirements levels for DH EC groups 19-21:
[RFC4109]; IKEv2 - optional IKEv1 - optional [RFC4109]
IKEv2 - optional
o RFC 5114, Additional Diffie-Hellman Groups for Use with IETF o RFC 5114, Additional Diffie-Hellman Groups for Use with IETF
Standards (I, Jan. 2008) Standards (I, Jan. 2008)
[RFC5114] defines 5 additional DH groups (MODP groups 22-24 and EC [RFC5114] defines 5 additional DH groups (MODP groups 22-24 and EC
groups 25-26) for use in IKE. It also includes 3 EC DH groups groups 25-26) for use in IKE. It also includes 3 EC DH groups
(groups 19-21) that were previously defined in [RFC4753]. The IANA (groups 19-21) that were previously defined in [RFC4753]. The IANA
group numbers are specific to IKE, but the DH groups are intended for group numbers are specific to IKE, but the DH groups are intended for
use in multiple IETF protocols, including TLS/SSL, S/MIME, and X.509 use in multiple IETF protocols, including TLS/SSL, S/MIME, and X.509
Certificates. Certificates.
Requirements levels for DH MODP groups 22-24, EC groups 25-26: IKEv1 Requirements levels for DH MODP groups 22-24, EC groups 25-26:
- optional; IKEv2 - optional IKEv1 - optional
IKEv2 - optional
6. IPsec/IKE for Multicast 6. IPsec/IKE for Multicast
[RFC4301] describes IPsec processing for unicast and multicast [RFC4301] describes IPsec processing for unicast and multicast
traffic. However, classical IPsec SAs provide point-to-point traffic. However, classical IPsec SAs provide point-to-point
protection; the security afforded by IPsec's cryptographic algorithms protection; the security afforded by IPsec's cryptographic algorithms
is not applicable when the SA is one-to-many or many-to-many, the 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 case for multicast. The Multicast Security (msec) Working Group has
defined alternatives to IKE and extensions to IPsec for use with defined alternatives to IKE and extensions to IPsec for use with
multicast traffic. Different multicast groups have differing multicast traffic. Different multicast groups have differing
characteristics and requirements: number of senders (one-to-many or characteristics and requirements: number of senders (one-to-many or
many-to-many), number of members (few, moderate, very large), many-to-many), number of members (few, moderate, very large),
volatility of membership, real-time delivery, etc. Their security volatility of membership, real-time delivery, etc. Their security
requirements vary as well. Each solution defined by msec applies to requirements vary as well. Each solution defined by msec applies to
a subset of the infinite variety of possible multicast groups. a subset of the large variety of possible multicast groups.
o RFC 3740, The Multicast Group Security Architecture (I, Mar. o RFC 3740, The Multicast Group Security Architecture (I, Mar.
2004) 2004)
[RFC3740] defines the multicast security architecture, which is used [RFC3740] defines the multicast security architecture, which is used
to provide security for packets exchanged by large multicast groups. to provide security for packets exchanged by large multicast groups.
It defines the components of the architectural framework; discusses It defines the components of the architectural framework; discusses
Group Security Associations (GSAs), key management, data handling and Group Security Associations (GSAs), key management, data handling and
security policies. Several existing protocols, including GDOI security policies. Several existing protocols, including GDOI
[RFC3547], GSAKMP [RFC4535] and MIKEY [RFC3830], satisfy the group [RFC3547], GSAKMP [RFC4535] and MIKEY [RFC3830], satisfy the group
key management requirements defined in this document. key management requirements defined in this document.
skipping to change at page 31, line 5 skipping to change at page 33, line 37
o RFC 4383, The Use of Timed Efficient Stream Loss-Tolerant o RFC 4383, The Use of Timed Efficient Stream Loss-Tolerant
Authentication (TESLA) in the Secure Real-time Transport Authentication (TESLA) in the Secure Real-time Transport
Protocol (SRTP) (S, Feb. 2006) Protocol (SRTP) (S, Feb. 2006)
[RFC4383] describes the use of TESLA within SRTP to protect multicast [RFC4383] describes the use of TESLA within SRTP to protect multicast
and broadcast traffic. and broadcast traffic.
7. Outgrowths of IPsec/IKE 7. Outgrowths of IPsec/IKE
Operational experience with IPsec revealed additional capabilities
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) 7.1. IPComp (Compression)
The IP Payload Compression Protocol (IPComp) is a protocol that
provides losslesss 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
o RFC 3173, IP Payload Compression Protocol (IPComp) (S, Sep. o RFC 3173, IP Payload Compression Protocol (IPComp) (S, Sep.
2001) 2001)
IPComp is a protocol that provides lossless compression for IP IP payload compression is especially useful when IPsec based
datagrams. IP payload compression is especially useful when IPsec encryption is applied to IP datagrams. Encrypting the IP datagram
based encryption is applied to IP datagrams. Encrypting the IP causes the data to be random in nature, rendering compression at
datagram causes the data to be random in nature, rendering lower protocol layers ineffective. If IKE is used to negotiate
compression at lower protocol layers ineffective. If IKE is used to compression in conjunction with IPsec, compression can be performed
negotiate compression in conjunction with IPsec, compression can be prior to encryption. [RFC3173] defines the payload compression
performed prior to encryption. [RFC3173] defines the payload protocol, the IPComp packet structure, the IPComp Association (IPCA),
compression protocol, the IPComp packet structure, the IPComp and several methods to negotiate the IPCA.
Association (IPCA), and several methods to negotiate the IPCA.
o RFC 2394, IP Payload Compression Using DEFLATE (I, Dec. 1998) o RFC 2394, IP Payload Compression Using DEFLATE (I, Dec. 1998)
The IPComp protocol allows the compression of IP datagrams by The IPComp protocol allows the compression of IP datagrams by
supporting different compression algorithms. [RFC2394] defines the supporting different compression algorithms. [RFC2394] defines the
application of the DEFLATE algorithm as a compression method to application of the DEFLATE algorithm as a compression method to
IPComp. IPComp.
o RFC 2395, IP Payload Compression Using LZS (I, Dec. 1998) o RFC 2395, IP Payload Compression Using LZS (I, Dec. 1998)
The IPComp protocol allows the compression of IP datagrams by The IPComp protocol allows the compression of IP datagrams by
supporting different compression algorithms. [RFC2395] defines the supporting different compression algorithms. [RFC2395] defines the
application of the LZS algorithm as a compression method to IPComp. application of the LZS algorithm as a compression method to IPComp.
7.2. IKEv2 Mobility and Multihoming (MobIKE) 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.
o RFC 4621, Design of the IKEv2 Mobility and Multihoming (MOBIKE) o RFC 4621, Design of the IKEv2 Mobility and Multihoming (MOBIKE)
Protocol (I, Aug. 2006) Protocol (I, Aug. 2006)
[RFC4621] discusses the involved network entities and the [RFC4621] discusses the involved network entities and the
relationship between IKEv2 signaling and information provided by relationship between IKEv2 signaling and information provided by
other protocols. It also records design decisions for the MOBIKE other protocols. It also records design decisions for the MOBIKE
protocol, background information, and records discussions within the protocol, background information, and records discussions within the
working group. working group.
o RFC 4555, IKEv2 Mobility and Multihoming Protocol (MOBIKE) (S, o RFC 4555, IKEv2 Mobility and Multihoming Protocol (MOBIKE) (S,
skipping to change at page 32, line 16 skipping to change at page 35, line 20
o RFC 5266, Secure Connectivity and Mobility Using Mobile IPv4 and o RFC 5266, Secure Connectivity and Mobility Using Mobile IPv4 and
IKEv2 Mobility and Multihoming (MOBIKE) (B, Jun. 2008) IKEv2 Mobility and Multihoming (MOBIKE) (B, Jun. 2008)
[RFC5266] describes a solution using Mobile IPv4 (MIPv4) and mobility [RFC5266] describes a solution using Mobile IPv4 (MIPv4) and mobility
extensions to IKEv2 (MOBIKE) to provide secure connectivity and extensions to IKEv2 (MOBIKE) to provide secure connectivity and
mobility to enterprise users when they roam into untrusted networks. mobility to enterprise users when they roam into untrusted networks.
7.3. Better-than-Nothing Security (Btns) 7.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.
o draft-ietf-btns-connection-latching, IPsec Channels: Connection o draft-ietf-btns-connection-latching, IPsec Channels: Connection
Latching Latching
This document specifies, abstractly, how to interface applications [btns-1] specifies, abstractly, how to interface applications and
and transport protocols with IPsec so as to create channels by transport protocols with IPsec so as to create channels by latching
latching connections (packet flows) to certain IPsec Security connections (packet flows) to certain IPsec Security Association (SA)
Association (SA) parameters for the lifetime of the connections. parameters for the lifetime of the connections. Connection latching
Connection latching is layered on top of IPsec and does not modify is layered on top of IPsec and does not modify the underlying IPsec
the underlying IPsec architecture. architecture.
o RFC 5386, Better-Than-Nothing-Security: An Unauthenticated Mode o RFC 5386, Better-Than-Nothing-Security: An Unauthenticated Mode
of IPsec (S, Nov. 2008) of IPsec (S, Nov. 2008)
[RFC5386] specifies how to use the Internet Key Exchange (IKE) [RFC5386] specifies how to use the Internet Key Exchange (IKE)
protocols, such as IKEv1 and IKEv2, to setup unauthenticated security protocols, such as IKEv1 and IKEv2, to setup unauthenticated security
associations (SAs) for use with the IPsec Encapsulating Security associations (SAs) for use with the IPsec Encapsulating Security
Payload (ESP) and the IPsec Authentication Header (AH). This Payload (ESP) and the IPsec Authentication Header (AH). This
document does not require any changes to the bits on the wire, but document does not require any changes to the bits on the wire, but
specifies extensions to the Peer Authorization Database (PAD) and specifies extensions to the Peer Authorization Database (PAD) and
skipping to change at page 32, line 48 skipping to change at page 36, line 17
Better-Than-Nothing Security (BTNS) (I, Nov. 2008) Better-Than-Nothing Security (BTNS) (I, Nov. 2008)
[RFC5387] considers that the need to deploy authentication [RFC5387] considers that the need to deploy authentication
information and its associated identities is a significant obstacle information and its associated identities is a significant obstacle
to the use of IPsec. This document explains the rationale for to the use of IPsec. This document explains the rationale for
extending the Internet network security protocol suite to enable use extending the Internet network security protocol suite to enable use
of IPsec security services without authentication. of IPsec security services without authentication.
7.4. Kerberized Internet Negotiation of Keys (Kink) 7.4. Kerberized Internet Negotiation of Keys (Kink)
Kerberized Internet Negotiation of Keys (Kink) is another 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,
IPsec can then be implemented without the need for additional peer
credentials.
o RFC 3129, Requirements for Kerberized Internet Negotiation of o RFC 3129, Requirements for Kerberized Internet Negotiation of
Keys (I, Jun. 2001) Keys (I, Jun. 2001)
[RFC3129] considers that peer to peer authentication and keying [RFC3129] considers that peer to peer authentication and keying
mechanisms have inherent drawbacks such as computational complexity mechanisms have inherent drawbacks such as computational complexity
and difficulty in enforcing security policies. This document and difficulty in enforcing security policies. This document
specifies the requirements for using basic features of Kerberos and specifies the requirements for using basic features of Kerberos and
uses them to its advantage to create a protocol which can establish uses them to its advantage to create a protocol which can establish
and maintain IPsec security associations ([RFC2401]). and maintain IPsec security associations ([RFC2401]).
o RFC 4430, Kerberized Internet Negotiation of Keys (KINK) (S, o RFC 4430, Kerberized Internet Negotiation of Keys (KINK) (S,
Mar. 2006) Mar. 2006)
skipping to change at page 33, line 23 skipping to change at page 36, line 46
[RFC4430] defines a low-latency, computationally inexpensive, easily [RFC4430] defines a low-latency, computationally inexpensive, easily
managed, and cryptographically sound protocol to establish and managed, and cryptographically sound protocol to establish and
maintain security associations using the Kerberos authentication maintain security associations using the Kerberos authentication
system. This document reuses the Quick Mode payloads of IKEv1 in system. This document reuses the Quick Mode payloads of IKEv1 in
order to foster substantial reuse of IKEv1 implementations. This RFC order to foster substantial reuse of IKEv1 implementations. This RFC
has not been widely adopted. has not been widely adopted.
7.5. IPsec Secure Remote Access (IPSRA) 7.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. 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.
o RFC 3457, Requirements for IPsec Remote Access Scenarios (I, o RFC 3457, Requirements for IPsec Remote Access Scenarios (I,
Jan. 2003) Jan. 2003)
[RFC3457] explores and enumerates the requirements of various IPsec [RFC3457] explores and enumerates the requirements of various IPsec
remote access scenarios, without suggesting particular solutions for remote access scenarios, without suggesting particular solutions for
them. them.
o RFC 3456, Dynamic Host Configuration Protocol (DHCPv4) o RFC 3456, Dynamic Host Configuration Protocol (DHCPv4)
Configuration of IPsec Tunnel Mode (S, Jan. 2003) Configuration of IPsec Tunnel Mode (S, Jan. 2003)
[RFC3456] explores the requirements for host configuration in IPsec [RFC3456] explores the requirements for host configuration in IPsec
tunnel mode, and describes how the Dynamic Host Configuration tunnel mode, and describes how the Dynamic Host Configuration
Protocol (DHCPv4) may be used for providing such configuration Protocol (DHCPv4) may be used for providing such configuration
information. This RFC has not been widely adopted. information. This RFC has not been widely adopted.
7.6. IPsec Keying Information Resource Record (IPsecKEY) 7.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.
o RFC 4025, A method for storing IPsec keying material in DNS (S, o RFC 4025, A method for storing IPsec keying material in DNS (S,
Feb. 2005) Feb. 2005)
This document describes a method of storing IPsec keying material in This document describes a method of storing IPsec keying material in
DNS using a new type of resource record. This document describes how the DNS using a new type of resource record. This document describes
to store the public key of the target node in this resource record. how to store the public key of the target node in this resource
This RFC has not been widely adopted. record. This RFC has not been widely adopted.
8. Other Protocols that use IPsec/IKE 8. Other Protocols that use IPsec/IKE
IPsec and IKE were designed to provide IP-layer security protection
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. Mobile IP (MIPv4 and MIPv6)
o RFC 4093, Problem Statement: Mobile IPv4 Traversal of Virtual o RFC 4093, Problem Statement: Mobile IPv4 Traversal of Virtual
Private Network (VPN) Gateways (I, Aug. 2005) Private Network (VPN) Gateways (I, Aug. 2005)
This document describes the issues with deploying Mobile IPv4 across This document describes the issues with deploying Mobile IPv4 across
virtual private networks (VPNs). IPsec is one of the VPN virtual private networks (VPNs). IPsec is one of the VPN
technologies covered by this document. It identifes and describes technologies covered by this document. It identifes and describes
practical deployment scenarios for Mobile IPv4 running alongside practical deployment scenarios for Mobile IPv4 running alongside
IPsec in enterprise and operator environments. It also specifies a IPsec in enterprise and operator environments. It also specifies a
set of framework guidelines to evaluate proposed solutions for set of framework guidelines to evaluate proposed solutions for
supporting multi-vendor seamless IPv4 mobility across IPsec-based VPN supporting multi-vendor seamless IPv4 mobility across IPsec-based VPN
gateways. gateways.
o RFC 5265, Mobile IPv4 Traversal across IPsec-Based VPN Gateways o RFC 5265, Mobile IPv4 Traversal across IPsec-Based VPN Gateways
skipping to change at page 34, line 19 skipping to change at page 38, line 16
technologies covered by this document. It identifes and describes technologies covered by this document. It identifes and describes
practical deployment scenarios for Mobile IPv4 running alongside practical deployment scenarios for Mobile IPv4 running alongside
IPsec in enterprise and operator environments. It also specifies a IPsec in enterprise and operator environments. It also specifies a
set of framework guidelines to evaluate proposed solutions for set of framework guidelines to evaluate proposed solutions for
supporting multi-vendor seamless IPv4 mobility across IPsec-based VPN supporting multi-vendor seamless IPv4 mobility across IPsec-based VPN
gateways. gateways.
o RFC 5265, Mobile IPv4 Traversal across IPsec-Based VPN Gateways o RFC 5265, Mobile IPv4 Traversal across IPsec-Based VPN Gateways
(S, Jun. 2008) (S, Jun. 2008)
This document describes a basic solution that uses Mobile IPv4 and [RFC5265] describes a basic solution that uses Mobile IPv4 and IPsec
IPsec to provide session mobility between enterprise intranets and to provide session mobility between enterprise intranets and external
external networks. The proposed solution minimizes changes to networks. The proposed solution minimizes changes to existing
existing firewall/VPN/DMZ deployments and does not require any firewall/VPN/DMZ deployments and does not require any changes to
changes to IPsec or key exchange protocols. It also proposes a IPsec or key exchange protocols. It also proposes a mechanism to
mechanism to minimize IPsec renegotiation when the mobile node moves. minimize IPsec renegotiation when the mobile node moves.
o RFC 3776, Using IPsec to Protect Mobile IPv6 Signaling Between o RFC 3776, Using IPsec to Protect Mobile IPv6 Signaling Between
Mobile Nodes and Home Agents (S, Jun. 2004) Mobile Nodes and Home Agents (S, Jun. 2004)
This document illustrates the use of IPsec in securing Mobile IPv6 This document illustrates the use of IPsec in securing Mobile IPv6
traffic between mobile nodes and home agents. It specifies the traffic between mobile nodes and home agents. It specifies the
required wire formats for the protected packets and illustrates required wire formats for the protected packets and illustrates
examples of Security Policy Database and Security Association examples of Security Policy Database and Security Association
Database entries that can be used to protect Mobile IPv6 signaling Database entries that can be used to protect Mobile IPv6 signaling
messages. It also describes how to configure either manually keyed messages. It also describes how to configure either manually keyed
skipping to change at page 35, line 4 skipping to change at page 38, line 49
IPsec architecture [RFC4301]. Since the revised IPsec architecture IPsec architecture [RFC4301]. Since the revised IPsec architecture
expands the list of selectors to include the Mobility Header message expands the list of selectors to include the Mobility Header message
type, it becomes much easier to differentiate between different type, it becomes much easier to differentiate between different
mobility header messages. Since the ICMP message type and code are mobility header messages. Since the ICMP message type and code are
also newly added as selectors, this document uses them to protect also newly added as selectors, this document uses them to protect
Mobile Prefix Discovery messages. Finally, this document describes Mobile Prefix Discovery messages. Finally, this document describes
the use of IKEv2 in order to set up the SAs for Mobile IPv6. the use of IKEv2 in order to set up the SAs for Mobile IPv6.
o draft-ietf-mip6-cn-ipsec, Using IPsec between Mobile and o draft-ietf-mip6-cn-ipsec, Using IPsec between Mobile and
Correspondent IPv6 Nodes Correspondent IPv6 Nodes
The Mobile IPv6 protocol contains a mode called "route optimization" The Mobile IPv6 protocol contains a mode called "route optimization"
(RO) mode that enables the mobile node to communicate with a (RO) mode that enables the mobile node to communicate with a
corresponding node using the most direct path between them instead of corresponding node using the most direct path between them instead of
passing through the home agent. It also defines a mechanism called passing through the home agent. It also defines a mechanism called
the return routability procedure in order to secure the RO signaling. the return routability procedure in order to secure the RO signaling.
This document defines an alternative mechanism for Mobile IPv6 route [mip6-1] defines an alternative mechanism for Mobile IPv6 route
optimization based on strong authentication and IPsec. It specifies optimization based on strong authentication and IPsec. It specifies
which IPsec configurations can be useful in a Mobile IPv6 context and which IPsec configurations can be useful in a Mobile IPv6 context and
how they can validate Home Address Options and protect mobility how they can validate Home Address Options and protect mobility
signaling. It also provides detailed IKEv1 and IKEv2 configuration signaling. It also provides detailed IKEv1 and IKEv2 configuration
guidelines for common usage scenarios. guidelines for common usage scenarios.
o RFC 5213, Proxy Mobile IPv6 (S, Aug. 2008) o RFC 5213, Proxy Mobile IPv6 (S, Aug. 2008)
This document describes a network-based mobility management protocol [RFC5213] describes a network-based mobility management protocol that
that is used to provide mobility services hosts without requiring is used to provide mobility services hosts without requiring their
their participation in any mobility-related signaling. It uses IPsec participation in any mobility-related signaling. It uses IPsec to
to protect the mobility signaling messages between the two network protect the mobility signaling messages between the two network
entities called the mobile access gateway (MAG) and the local entities called the mobile access gateway (MAG) and the local
mobility anchor (LMA). It also uses IKEv2 in order to set up the mobility anchor (LMA). It also uses IKEv2 in order to set up the
security associations between the MAG and the LMA. security associations between the MAG and the LMA.
o RFC 5268, Mobile IPv6 Fast Handovers (S, Jun. 2008) o RFC 5268, Mobile IPv6 Fast Handovers (S, Jun. 2008)
When Mobile IPv6 is used for a handover, there is a period during When Mobile IPv6 is used for a handover, there is a period during
which the Mobile Node is unable to send or receive packets because of which the Mobile Node is unable to send or receive packets because of
link switching delay and IP protocol operations. This document link switching delay and IP protocol operations. [RFC5268] specifies
specifies a protocol between the Previous Access Router (PAR) and the a protocol between the Previous Access Router (PAR) and the New
New Access Router (NAR) to improve handover latency due to Mobile Access Router (NAR) to improve handover latency due to Mobile IPv6
IPv6 procedures. It uses IPsec ESP in transport mode with integrity procedures. It uses IPsec ESP in transport mode with integrity
protection for protecting the signaling messages between the PAR and protection for protecting the signaling messages between the PAR and
the NAR. It also describes the SPD entries and the PAD entries when the NAR. It also describes the SPD entries and the PAD entries when
IKEv2 is used for setting up the required SAs. IKEv2 is used for setting up the required SAs.
o RFC 5380, Hierarchical Mobile IPv6 (HMIPv6) Mobility Management o RFC 5380, Hierarchical Mobile IPv6 (HMIPv6) Mobility Management
(S, Oct. 2008) (S, Oct. 2008)
This document describes extensions to Mobile IPv6 and IPv6 Neighbour [RFC5380] describes extensions to Mobile IPv6 and IPv6 Neighbour
Discovery to allow for local mobility handling in order to reduce the Discovery to allow for local mobility handling in order to reduce the
amount of signalling between the mobile node, its correspondent amount of signalling between the mobile node, its correspondent
nodes, and its home agent. It also improves handover speed of Mobile nodes, and its home agent. It also improves handover speed of Mobile
IPv6. It uses IPsec for protecting the signaling between the mobile IPv6. It uses IPsec for protecting the signaling between the mobile
node and a local mobility management entity called the Mobility node and a local mobility management entity called the Mobility
Anchor Point (MAP). The MAP also uses IPsec Peer Authorization Anchor Point (MAP). The MAP also uses IPsec Peer Authorization
Database (PAD) entries and configuration payloads described in Database (PAD) entries and configuration payloads described in
[RFC4877] in order to allocate a Regional Care-of Address (RCoA) for [RFC4877] in order to allocate a Regional Care-of Address (RCoA) for
mobile nodes. mobile nodes.
skipping to change at page 38, line 4 skipping to change at page 41, line 49
The Stream Control Transmission Protocol (SCTP) is a reliable The Stream Control Transmission Protocol (SCTP) is a reliable
transport protocol operating on top of a connection-less packet transport protocol operating on top of a connection-less packet
network such as IP. This document describes functional requirements network such as IP. This document describes functional requirements
for IPsec and IKE to be used in securing SCTP traffic. It adds 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 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 implementation choices in the IPsec processing to account for the
multiple source and destination addresses associated with a single multiple source and destination addresses associated with a single
SCTP association. SCTP association.
8.6. Fibre Channel 8.6. Fibre Channel
o RFC 4595, Use of IKEv2 in the Fibre Channel Security Association o RFC 4595, Use of IKEv2 in the Fibre Channel Security Association
Management Protocol (I, Jul. 2006) Management Protocol (I, Jul. 2006)
Fibre Channel (FC) is a gigabit-speed network technology used for Fibre Channel (FC) is a gigabit-speed network technology used for
Storage Area Networking. The Fibre Channel Security Protocols Storage Area Networking. The Fibre Channel Security Protocols
standard (FC-SP) has adapted the IKEv2 protocol [RFC4306] to provide standard (FC-SP) has adapted the IKEv2 protocol [RFC4306] to provide
authentication of Fibre Channel entities and setup of security authentication of Fibre Channel entities and setup of security
associations. Since IP is transported over Fibre Channel [RFC4338] associations. Since IP is transported over Fibre Channel and Fibre
and Fibre Channel/SCSI are transported over IP [RFC3643], [RFC3821] Channel/SCSI are transported over IP, there is the potential for
there is the potential for confusion when IKEv2 is used for both IP confusion when IKEv2 is used for both IP and FC traffic. This
and FC traffic. This document specifies identifiers for IKEv2 over document specifies identifiers for IKEv2 over FC in a fashion that
FC in a fashion that ensures that any mistaken usage of IKEv2/FC over ensures that any mistaken usage of IKEv2/FC over IP or IKEv2/IP over
IP or IKEv2/IP over FC will result in a negotiation failure due to FC will result in a negotiation failure due to the absence of an
the absence of an acceptable proposal. acceptable proposal.
8.7. Robust Header Compression (ROHC) 8.7. Robust Header Compression (ROHC)
o RFC 3095, RObust Header Compression (ROHC): Framework and four o RFC 3095, RObust Header Compression (ROHC): Framework and four
profiles: RTP, UDP, ESP, and uncompressed (S, July 2001) profiles: RTP, UDP, ESP, and uncompressed (S, July 2001)
ROHC is a framework for header compression, intended to be used in ROHC is a framework for header compression, intended to be used in
resource-constrained environments. [RFC3095] applies this framework resource-constrained environments. [RFC3095] applies this framework
to four protocols, including ESP. to four protocols, including ESP.
o RFC 5225, RObust Header Compression Version 2 (ROHCv2): Profiles o RFC 5225, RObust Header Compression Version 2 (ROHCv2): Profiles
for RTP, UDP, IP, ESP, and UDP-Lite (S, April 2008) for RTP, UDP, IP, ESP, and UDP-Lite (S, April 2008)
[RFC5225] includes an ESP profile for use with ROHC version 2. [RFC5225] includes an ESP profile for use with ROHC version 2.
9. Security Considerations 8.8. Border Gateway Protocol (BGP)
o 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
o 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.
o 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 and Al Morton for
reviewing this document and suggesting changes.
10. Security Considerations
There are no security considerations relevant to this document. There are no security considerations relevant to this document.
10. IANA Considerations 11. IANA Considerations
No actions are required from IANA as result of the publication of No actions are required from IANA as result of the publication of
this document. this document.
11. References 12. References
11.1. Normative References 12.1. Normative References
11.2. Informative References 12.2. Informative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision [RFC2026] Bradner, S., "The Internet Standards Process -- Revision
3", RFC 2026, October 1996. 3", RFC 2026, October 1996.
[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.
[btns-1] Williams, N., "IPsec Channels: Connection Latching", [btns-1] Williams, N., "IPsec Channels: Connection Latching",
draft-ietf-btns-connection-latching, Work in Progress. draft-ietf-btns-connection-latching, Work in Progress.
[ipsecme-1] Kaufman, C., P. Hoffman, Y. Nir and P. Eronen, "Internet [ipsecme-1] Kaufman, C., P. Hoffman, Y. Nir and P. Eronen, "Internet
Key Exchange Protocol: IKEv2", Key Exchange Protocol: IKEv2",
draft-ietf-ipsecme-ikev2bis, Work in Progress. draft-ietf-ipsecme-ikev2bis, Work in Progress.
[ipsecme-2] Eronen, P., J. Laganier and C. Madson, [ipsecme-2] Eronen, P., J. Laganier and C. Madson,
draft-ietf-ipsecme-ikev2-ipv6-config, IPv6 Configuration draft-ietf-ipsecme-ikev2-ipv6-config, IPv6 Configuration
in IKEv2, Work in Progress. in IKEv2, Work in Progress.
skipping to change at page 42, line 47 skipping to change at page 47, line 43
Statement: Mobile IPv4 Traversal of Virtual Private Statement: Mobile IPv4 Traversal of Virtual Private
Network (VPN) Gateways", RFC 4093, August 2005. Network (VPN) Gateways", RFC 4093, August 2005.
[RFC4106] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode [RFC4106] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode
(GCM) in IPsec Encapsulating Security Payload (ESP)", RFC (GCM) in IPsec Encapsulating Security Payload (ESP)", RFC
4106, June 2005. 4106, June 2005.
[RFC4109] Hoffman, P., "Algorithms for Internet Key Exchange version [RFC4109] Hoffman, P., "Algorithms for Internet Key Exchange version
1 (IKEv1)", RFC 4109, May 2005. 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 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005. Internet Protocol", RFC 4301, December 2005.
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December
2005. 2005.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC
4303, December 2005. 4303, December 2005.
[RFC4304] Kent, S., "Extended Sequence Number (ESN) Addendum to [RFC4304] Kent, S., "Extended Sequence Number (ESN) Addendum to
skipping to change at page 48, line 5 skipping to change at page 52, line 40
Applicability Statement for Better-Than-Nothing Security Applicability Statement for Better-Than-Nothing Security
(BTNS)", RFC 5387, November 2008. (BTNS)", RFC 5387, November 2008.
[RFC5406] Bellovin, S., "Guidelines for Specifying the Use of IPsec [RFC5406] Bellovin, S., "Guidelines for Specifying the Use of IPsec
Version 2", RFC 5406, February 2009. Version 2", RFC 5406, February 2009.
[RFC 5410] Jerichow, A., Ed., and L. Piron, "Multimedia Internet [RFC 5410] Jerichow, A., Ed., and L. Piron, "Multimedia Internet
KEYing (MIKEY) General Extension Payload for Open Mobile KEYing (MIKEY) General Extension Payload for Open Mobile
Alliance BCAST 1.0", RFC 5410, January 2009. 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.
Appendix A. Summary of Algorithm Requirement Levels
Table 1: Algorithm Requirement Levels
+--------------------------+----------------------------------------+
| ALGORITHM | REQUIREMENT LEVEL |
| | IKEv1 IKEv2 ESP-v2 ESP-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 undefined SHOULD SHOULD |
| | |
| Camellia-CBC | optional undefined 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 | SHOULD optional SHOULD+ SHOULD+ |
| | |
| HMAC-SHA-256/384/512 | optional optional optional optional |
| | |
| AES-GMAC | N/A optional undefined optional |
| | |
| HMAC-MD5 | MAY optional MAY MAY |
| | |
| AES-CMAC | undefined optional undefined optional |
| | |
| HMAC-RIPEMD | undefined undefined optional undefined|
+--------------------------+----------------------------------------+
Table 1: Algorithm Requirement Levels (continued)
+--------------------------+----------------------------------------+
| ALGORITHM | REQUIREMENT LEVEL |
| | IKEv1 IKEv2 ESP-v2 ESP-v3 |
+--------------------------+----------------------------------------+
|Combined Mode Algorithms: |
|------------------------ |
| AES-CCM | N/A optional N/A optional |
| | |
| AES-GCM | N/A optional N/A 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 | SHOULD 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 |
+--------------------------+----------------------------------------+
Authors' Addresses Authors' Addresses
Sheila Frankel Sheila Frankel
NIST NIST
Bldg. 223 Rm. B366 Bldg. 223 Rm. B366
Gaithersburg, MD 20899 Gaithersburg, MD 20899
Phone: 1-301-975-3297 Phone: 1-301-975-3297
Email: sheila.frankel@nist.gov Email: sheila.frankel@nist.gov
Suresh Krishnan Suresh Krishnan
Ericsson Ericsson
8400 Decarie Blvd. 8400 Decarie Blvd.
Town of Mount Royal, QC Town of Mount Royal, QC
Canada Canada
Phone: 1-514-345-7900 x42871 Phone: 1-514-345-7900 x42871
Email: suresh.krishnan@ericsson.com Email: suresh.krishnan@ericsson.com
Intellectual Property
All IETF Documents and the information contained herein are provided
on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY
RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
PARTICULAR PURPOSE.
The IETF Trust takes no position regarding the validity or scope of
any Intellectual Property Rights or other rights that might be
claimed to pertain to the implementation or use of the technology
described in any IETF Document or the extent to which any license
under such rights might or might not be available; nor does it
represent that it has made any independent effort to identify any
such rights.
Copies of Intellectual Property disclosures made to the IETF
Secretariat and any assurances of licenses to be made available, or
the result of an attempt made to obtain a general license or
permission for the use of such proprietary rights by implementers or
users of this specification can be obtained from the IETF on-line IPR
repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
any standard or specification contained in an IETF Document. Please
address the information to the IETF at ietf-ipr@ietf.org.
The definitive version of an IETF Document is that published by, or
under the auspices of, the IETF. Versions of IETF Documents that are
published by third parties, including those that are translated into
other languages, should not be considered to be definitive versions
of IETF Documents. The definitive version of these Legal Provisions
is that published by, or under the auspices, of the IETF. Versions
of these Legal Provisions that are published by third parties,
including those that are translated into other languages, should not
be considered to be definitive versions of these Legal Provisions.
For the avoidance of doubt, each Contributor to the IETF Standards
Process licenses each Contribution that he or she makes as part of
the IETF Standards Process to the IETF Trust pursuant to the
provisions of RFC 5378. No language to the contrary, or terms,
conditions or rights that differ from or are inconsistent with the
rights and licenses granted under RFC 5378, shall have any effect and
shall be null and void, whether published or posted by such
Contributor, or included with or in such Contribution.
 End of changes. 101 change blocks. 
202 lines changed or deleted 538 lines changed or added

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