draft-ietf-ipsecme-roadmap-00.txt   draft-ietf-ipsecme-roadmap-01.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: June 2009 December 22, 2008 Expires: August 2009 March 6, 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-00.txt> <draft-ietf-ipsecme-roadmap-01.txt>
Status of this Memo Status of this Memo
Distribution of this memo is unlimited. Distribution of this memo is unlimited.
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 35 skipping to change at page 1, line 35
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html. http://www.ietf.org/1id-abstracts.html.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on June 25, 2009. This Internet-Draft will expire on August 6, 2009.
Copyright and License Notice Copyright and License Notice
Copyright (c) 2008 IETF Trust and the persons identified as the Copyright (c) 2008 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 21 skipping to change at page 2, line 21
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
includes a brief description of each RFC, along with background includes a brief description of each RFC, along with background
information explaining the motivation and context of IPsec's information explaining the motivation and context of IPsec's
outgrowths and extensions. It obsoletes the previous IPsec Document outgrowths and extensions. It obsoletes the previous IPsec Document
Roadmap [RFC2411]. Roadmap [RFC2411].
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. IPsec/IKE Background Information . . . . . . . . . . . . . . . . 4 2. IPsec/IKE Background Information . . . . . . . . . . . . . . . . 4
2.1. Interrelationship of IPsec/IKE Documents . . . . . . . . . 4 2.1. Interrelationship of IPsec/IKE Documents . . . . . . . . . 4
2.2. Versions of IPsec . . . . . . . . . . . . . . . . . . . . . 5 2.2. Versions of IPsec . . . . . . . . . . . . . . . . . . . . . 5
2.2.1. Differences between "old" IPsec (IPsec-v2) and 2.2.1. Differences between "old" IPsec (IPsec-v2) and
"new" IPsec (IPsec-v3) . . . . . . . . . . . . . . . . 5 "new" IPsec (IPsec-v3) . . . . . . . . . . . . . . . . 6
2.3. Versions of IKE . . . . . . . . . . . . . . . . . . . . . . 6 2.3. Versions of IKE . . . . . . . . . . . . . . . . . . . . . . 7
2.3.1. Differences between IKEv1 and IKEv2 . . . . . . . . . 6 2.3.1. Differences between IKEv1 and IKEv2 . . . . . . . . . 7
2.4. IPsec and IKE IANA Registries . . . . . . . . . . . . . . . 7 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 . . . . . . . . . . . . . . . . . . 12
4. IKE Documents . . . . . . . . . . . . . . . . . . . . . . . . . 12 4. IKE Documents . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.1. Base Documents . . . . . . . . . . . . . . . . . . . . . . 12 4.1. Base Documents . . . . . . . . . . . . . . . . . . . . . . 13
4.1.1. IKEv1 . . . . . . . . . . . . . . . . . . . . . . . . . 12 4.1.1. IKEv1 . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.1.2. IKEv2 . . . . . . . . . . . . . . . . . . . . . . . . . 13 4.1.2. IKEv2 . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.2. Additions and Extensions . . . . . . . . . . . . . . . . . 14 4.2. Additions and Extensions . . . . . . . . . . . . . . . . . 14
4.2.1. Peer Authentication Methods . . . . . . . . . . . . . . 14 4.2.1. Peer Authentication Methods . . . . . . . . . . . . . . 15
4.2.2. Certificate Contents and Management . . . . . . . . . . 14 4.2.2. Certificate Contents and Management . . . . . . . . . . 15
4.2.3. Dead Peer Detection . . . . . . . . . . . . . . . . . . 15 4.2.3. Dead Peer Detection . . . . . . . . . . . . . . . . . . 16
4.2.4. Remote Access . . . . . . . . . . . . . . . . . . . . . 15 4.2.4. Remote Access . . . . . . . . . . . . . . . . . . . . . 16
5. Cryptographic Algorithms and Suites . . . . . . . . . . . . . . 16 5. Cryptographic Algorithms and Suites . . . . . . . . . . . . . . 17
5.1. Algorithm Requirements . . . . . . . . . . . . . . . . . . 16 5.1. Algorithm Requirements . . . . . . . . . . . . . . . . . . 17
5.2. Encryption Algorithms . . . . . . . . . . . . . . . . . . . 17 5.2. Encryption Algorithms . . . . . . . . . . . . . . . . . . . 18
5.3. Integrity-Protection (Authentication) Algorithms . . . . . 19 5.3. Integrity-Protection (Authentication) Algorithms . . . . . 21
5.3.1. General Considerations . . . . . . . . . . . . . . . . 22 5.3.1. General Considerations . . . . . . . . . . . . . . . . 23
5.4. Combined Algorithms . . . . . . . . . . . . . . . . . . . . 22 5.4. Combined Mode Algorithms . . . . . . . . . . . . . . . . . 23
5.4.1. General Considerations . . . . . . . . . . . . . . . . 23 5.4.1. General Considerations . . . . . . . . . . . . . . . . 25
5.5. Pseudo-Random Functions (PRFs) . . . . . . . . . . . . . . 23 5.5. Pseudo-Random Functions (PRFs) . . . . . . . . . . . . . . 25
5.6. Cryptographic Suites . . . . . . . . . . . . . . . . . . . 24 5.6. Cryptographic Suites . . . . . . . . . . . . . . . . . . . 26
5.7. Diffie-Hellman Algorithms . . . . . . . . . . . . . . . . . 24 5.7. Diffie-Hellman Algorithms . . . . . . . . . . . . . . . . . 26
6. IPsec/IKE for Multicast . . . . . . . . . . . . . . . . . . . . 26 6. IPsec/IKE for Multicast . . . . . . . . . . . . . . . . . . . . 28
7. Outgrowths of IPsec/IKE . . . . . . . . . . . . . . . . . . . . 27 7. Outgrowths of IPsec/IKE . . . . . . . . . . . . . . . . . . . . 30
7.1. IPComp (Compression) . . . . . . . . . . . . . . . . . . . 27 7.1. IPComp (Compression) . . . . . . . . . . . . . . . . . . . 31
7.2. IKEv2 Mobility and Multihoming (MobIKE) . . . . . . . . . . 27 7.2. IKEv2 Mobility and Multihoming (MobIKE) . . . . . . . . . . 31
7.3. Better-than-Nothing Security (Btns) . . . . . . . . . . . . 28 7.3. Better-than-Nothing Security (Btns) . . . . . . . . . . . . 32
7.4. Kerberized Internet Negotiation of Keys (Kink) . . . . . . 29 7.4. Kerberized Internet Negotiation of Keys (Kink) . . . . . . 32
7.5. IPsec Secure Remote Access (IPSRA) . . . . . . . . . . . . 29 7.5. IPsec Secure Remote Access (IPSRA) . . . . . . . . . . . . 33
7.6. IPsec Keying Information Resource Record (IPsecKEY) . . . . 29 7.6. IPsec Keying Information Resource Record (IPsecKEY) . . . . 33
8. Other Protocols that use IPsec/IKE . . . . . . . . . . . . . . . 30 8. Other Protocols that use IPsec/IKE . . . . . . . . . . . . . . . 33
8.1. Mobile IP (MIPv4 and MIPv6) . . . . . . . . . . . . . . . . 30 8.1. Mobile IP (MIPv4 and MIPv6) . . . . . . . . . . . . . . . . 33
8.2. Open Shortest Path First (OSPF) . . . . . . . . . . . . . . 30 8.2. Open Shortest Path First (OSPF) . . . . . . . . . . . . . . 36
8.3. Host Identity Protocol (HIP) . . . . . . . . . . . . . . . 30 8.3. Host Identity Protocol (HIP) . . . . . . . . . . . . . . . 36
8.4. Extensible Authentication Protocol (EAP) Method Update 8.4. Extensible Authentication Protocol (EAP) Method Update
(EMU) . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 (EMU) . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
8.5. Stream Control Transmission Protocol (SCTP) . . . . . . . . 31 8.5. Stream Control Transmission Protocol (SCTP) . . . . . . . . 37
8.6. Fibre Channel . . . . . . . . . . . . . . . . . . . . . . . 31 8.6. Fibre Channel . . . . . . . . . . . . . . . . . . . . . . . 37
8.7. Protocol for Carrying Authentication for Network Access 8.7. Robust Header Compression (ROHC) . . . . . . . . . . . . . 38
(PANA) . . . . . . . . . . . . . . . . . . . . . . . . . . 31 9. Security Considerations . . . . . . . . . . . . . . . . . . . . 38
9. Security Considerations . . . . . . . . . . . . . . . . . . . . 31 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 38
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 31 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 11.1. Normative References . . . . . . . . . . . . . . . . . . . 38
11.1. Normative References . . . . . . . . . . . . . . . . . . . 31 11.2. Informative References . . . . . . . . . . . . . . . . . . 38
11.2. Informative References . . . . . . . . . . . . . . . . . . 31
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 4, line 35 skipping to change at page 5, line 7
Architecture document which broadly covers the general concepts, Architecture document which broadly covers the general concepts,
security requirements, definitions, and mechanisms defining IPsec security requirements, definitions, and mechanisms defining IPsec
technology. technology.
There are an ESP Protocol document and an AH Protocol document which There are an ESP Protocol document and an AH Protocol document which
cover the packet format and general issues regarding the respective cover the packet format and general issues regarding the respective
protocols. The "Encryption Algorithm" document set, shown on the protocols. The "Encryption Algorithm" document set, shown on the
left, is the set of documents describing how various encryption left, is the set of documents describing how various encryption
algorithms are used for ESP. The "Combined Algorithm" document set, algorithms are used for ESP. The "Combined Algorithm" document set,
shown in the middle, is the set of documents describing how various shown in the middle, is the set of documents describing how various
combined algorithms are used to provide both encryption and combined mode algorithms are used to provide both encryption and
integrity-protection for ESP. The "Integ-Protection Algorithm" integrity-protection for ESP. The "Integ-Protection Algorithm"
document set, shown on the right, is the set of documents describing document set, shown on the right, is the set of documents describing
how various integrity-protection algorithms are used for both ESP and how various integrity-protection algorithms are used for both ESP and
AH. AH.
The "IKE Documents", shown at the bottom, are the documents The "IKE Documents", shown at the bottom, are the documents
describing the IETF standards-track key management schemes. describing the IETF standards-track key management schemes.
+--------------+ +--------------+
| Architecture | | Architecture |
skipping to change at page 5, line 41 skipping to change at page 6, line 4
| Protocol | | Protocol |
+------------+ +------------+
2.2. Versions of IPsec 2.2. Versions of IPsec
Two versions of IPsec can currently be found in implementations. The Two versions of IPsec can currently be found in implementations. The
"new" IPsec (referred to as IPsec-v3 in this document) obsoleted the "new" IPsec (referred to as IPsec-v3 in this document) obsoleted the
"old" IPsec (referred to as IPsec-v2 in this document); however, "old" IPsec (referred to as IPsec-v2 in this document); however,
IPsec-v2 is still commonly found in operational use. In this IPsec-v2 is still commonly found in operational use. In this
document, when the unqualified term IPsec is used, it pertains to document, when the unqualified term IPsec is used, it pertains to
both versions of IPsec. An earlier version of IPsec, obsoleted by both versions of IPsec. An earlier version of IPsec (defined in RFCs
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 in other protocols.
In addition, the documentation for IPsec-v3 clarifies and expands In addition, the documentation for IPsec-v3 clarifies and expands
skipping to change at page 7, line 15 skipping to change at page 7, line 27
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 in 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
called the IPsec SA in IKEv1 and the child SA in IKEv2, provides provides IPsec protection to data traffic between the peers and/or
IPsec protection to data traffic between the peers. This document other devices for which the peers are authorized to negotiate. It is
uses the term "IPsec SA". called the IPsec SA in IKEv1 and, in the IKEv2 RFCs, it is referred
to variously as a CHILD_SA, a child SA, and an IPsec SA. This
document uses the term "IPsec SA".
Changes to IKE include: Changes to IKE include:
o Multiple alternate exchange types replaced by a single, shorter o Multiple alternate exchange types replaced by a single, shorter
exchange exchange
o Streamlined negotiation format to avoid combinatorial bloat for o Streamlined negotiation format to avoid combinatorial bloat for
multiple proposals multiple proposals
o Protects responder from committing significant resources to the o Protects responder from committing significant resources to the
exchange until the initiator's existence and identity are exchange until the initiator's existence and identity are
confirmed confirmed
o Reliable exchanges: Every request expects a response o Reliable exchanges: Every request expects a response
o Protection of IKE messages based on ESP, rather than a method o Protection of IKE messages based on ESP, rather than a method
unique to IKE unique to IKE
o Add traffic selectors: distinct from peer IDs and more flexible o Add traffic selectors: distinct from peer IDs and more flexible
o Support of EAP-based authentication methods and asymmetric
authentication (i.e., initiator and responder can use different
authentication methods)
2.4. IPsec and IKE IANA Registries 2.4. IPsec and IKE IANA Registries
Numerous IANA registries contain values that are used in IPsec, IKE Numerous IANA registries contain values that are used in IPsec, IKE
and related protocols. They include: and related protocols. They include:
o IKE Attributes o IKE Attributes
(http://www.iana.org/assignments/ipsec-registry): values used (http://www.iana.org/assignments/ipsec-registry): values used
during IKEv1 Phase 1 exchanges, defined in [RFC2409] during IKEv1 Phase 1 exchanges, defined in [RFC2409]
skipping to change at page 8, line 4 skipping to change at page 8, line 21
and related protocols. They include: and related protocols. They include:
o IKE Attributes o IKE Attributes
(http://www.iana.org/assignments/ipsec-registry): values used (http://www.iana.org/assignments/ipsec-registry): values used
during IKEv1 Phase 1 exchanges, defined in [RFC2409] during IKEv1 Phase 1 exchanges, defined in [RFC2409]
o "Magic Numbers" for ISAKMP Protocol o "Magic Numbers" for ISAKMP Protocol
(http://www.iana.org/assignments/isakmp-registry): values used (http://www.iana.org/assignments/isakmp-registry): values used
during IKEv1 Phase 2 exchanges, defined in [RFC2407], [RFC2408] during IKEv1 Phase 2 exchanges, defined in [RFC2407], [RFC2408]
and numerous other cryptographic algorithm RFCs and numerous other cryptographic algorithm RFCs
o IKEv2 Parameters o IKEv2 Parameters
(http://www.iana.org/assignments/ikev2-parameters): values used (http://www.iana.org/assignments/ikev2-parameters): values used
in IKEv2 exchanges, defined in [RFC4306] and numerous other in IKEv2 exchanges, defined in [RFC4306] and numerous other
cryptographic algorithm RFCs cryptographic algorithm RFCs
o Cryptographic Suites for IKEv1, IKEv2, and IPsec o Cryptographic Suites for IKEv1, IKEv2, and IPsec
(http://www.iana.org/assignments/crypto-suites): names of (http://www.iana.org/assignments/crypto-suites): names of
cryptographic suites in [RFC4308] and [RFC4869] cryptographic suites in [RFC4308] and [RFC4869]
o Multimedia Internet KEYing (Mikey) Payload Name Spaces
(http://www.iana.org/assignments/mikey-payloads): values used in
MIKEY negotiations, defined in [RFC3830] and other multicast
IPsec/IKE RFCs
o IPseckey Resource Record Parameters
(http://www.iana.org/assignments/ipseckey-rr-parameters): values
used in IPsecKEY resource records, defined in [RFC4025]
o Extensible Authentication Protocol-Internet Key Exchange Version
2 (EAP-IKEv2) Payloads
(http://www.iana.org/assignments/eap-ikev2-payloads): payload
types used in EAP-IKEv2 [RFC5106]
3. IPsec Documents 3. IPsec Documents
3.1. Base Documents 3.1. Base Documents
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
skipping to change at page 11, line 4 skipping to change at page 11, line 7
configuration policies. configuration policies.
o RFC 3586, IP Security Policy (IPSP) Requirements (S, Aug. 2003) o RFC 3586, IP Security Policy (IPSP) Requirements (S, Aug. 2003)
[RFC3586] describes the functional requirements of a generalized [RFC3586] describes the functional requirements of a generalized
IPsec policy framework, that could be used to discover, negotiate and IPsec policy framework, that could be used to discover, negotiate and
manage IPsec policies. manage IPsec policies.
o RFC 3585, IPsec Configuration Policy Information Model (S, Aug. o RFC 3585, IPsec Configuration Policy Information Model (S, Aug.
2003) 2003)
As stated in [RFC3585], "This document presents an object-oriented As stated in [RFC3585], "This document presents an object-oriented
information model of IP Security (IPsec) policy designed to information model of IP Security (IPsec) policy designed to
facilitate agreement about the content and semantics of IPsec policy, facilitate agreement about the content and semantics of IPsec policy,
and enable derivations of task-specific representations of IPsec and enable derivations of task-specific representations of IPsec
policy such as storage schema, distribution representations, and policy such as storage schema, distribution representations, and
policy specification languages used to configure IPsec-enabled policy specification languages used to configure IPsec-enabled
endpoints." endpoints." This RFC has not been widely adopted.
3.3. MIBs 3.3. MIBs
Over the years, several MIB-related Internet Drafts were proposed for Over the years, several MIB-related Internet Drafts were proposed for
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. of an IPsec device. This RFC has not been widely adopted.
3.4. Additions to IPsec 3.4. Additions to IPsec
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].
skipping to change at page 12, line 24 skipping to change at page 12, line 27
extensions. It does not apply to tunnels that are initiated in an extensions. It does not apply to tunnels that are initiated in an
automated manner (e.g., 6to4 tunnels [RFC3056]). automated manner (e.g., 6to4 tunnels [RFC3056]).
o RFC 3884, Use of IPsec Transport Mode for Dynamic Routing (I, o RFC 3884, Use of IPsec Transport Mode for Dynamic Routing (I,
Sep. 2004) Sep. 2004)
[RFC3884] describes the use of transport-mode IPsec to secure [RFC3884] describes the use of transport-mode IPsec to secure
IP-in-IP tunnels, which constitute the links of a multi-hop, IP-in-IP tunnels, which constitute the links of a multi-hop,
distributed virtual network (VN). This allows the traffic to be distributed virtual network (VN). This allows the traffic to be
dynamically routed via the VN's trusted routers, rather than routing dynamically routed via the VN's trusted routers, rather than routing
all traffic through a statically-routed IPsec tunnel. all traffic through a statically-routed IPsec tunnel. This RFC has
not been widely adopted.
o draft-ietf-ipsecme-traffic-visibility-00.txt, Wrapped ESP for o draft-ietf-ipsecme-traffic-visibility, Wrapped ESP for Traffic
Traffic Visibility (S) Visibility (S)
ESP, as defined in [RFC4303], does not allow a network device to
easily determine whether protected traffic that is passing through
the device is encrypted, or only integrity-protected (referred to as
ESP-NULL packets). This document extends ESP to provide explicit
notification of integrity-protected packets, and extends IKEv2 to
negotiate this capability between the IPsec peers.
o draft-kivinen-ipsecme-esp-null-heuristics, Heuristics for
Detecting ESP-NULL packets (I)
This document offers an alternative approach to differentiating
between ESP-encrypted and ESP-NULL packets, through packet
inspection. This method does not require any change to IKEv2 or ESP.
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
(B, Feb. 2009)
[RFC5406] offers guidance to protocol designers on how to ascertain
whether IPsec is the appropriate security mechanism to provide an
interoperable security solution for the protocol. If this is not the
case, it advises against attempting to define a new security
protocol; rather, it suggests using another standards-based security
protocol.
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
negotiate authenticated keying material for SAs. This document negotiate authenticated keying material for SAs. This document
implements a subset of the Oakley protocol in conjunction with ISAKMP implements a subset of the Oakley protocol in conjunction with ISAKMP
to obtain authenticated keying material for use with ISAKMP, and for to obtain authenticated keying material for use with ISAKMP, and for
other security associations such as AH and ESP for the IETF IPsec other security associations such as AH and ESP for the IETF IPsec
DOI. DOI. While historically IKEv1 was created by combining two security
protocols, ISAKMP and Oakley, in practice the combination (along with
the IPsec DOI) has commonly been viewed as one protocol, IKEv1. The
protocol's origins can be seen in the organization of the documents
that define it.
o RFC 2408, Internet Security Association and Key Management o RFC 2408, Internet Security Association and Key Management
Protocol (ISAKMP) (S, Nov. 1998) Protocol (ISAKMP) (S, Nov. 1998)
This document defines procedures and packet formats to establish, This document defines procedures and packet formats to establish,
negotiate, modify and delete Security Associations (SAs). It is negotiate, modify and delete Security Associations (SAs). It is
intended to support the negotiation of SAs for security protocols at intended to support the negotiation of SAs for security protocols at
all layers of the network stack. ISAKMP can work with many different all layers of the network stack. ISAKMP can work with many different
key exchange protocols, each with different security properties. key exchange protocols, each with different security properties.
skipping to change at page 14, line 4 skipping to change at page 14, line 32
o RFC 4306, Internet Key Exchange (IKEv2) Protocol (S, Dec. 2005) o RFC 4306, Internet Key Exchange (IKEv2) Protocol (S, Dec. 2005)
This document describes version 2 of the Internet Key Exchange (IKE) This document describes version 2 of the Internet Key Exchange (IKE)
protocol. It covers what was covered previously by separate protocol. It covers what was covered previously by separate
documents: ISAKMP, IKE and DOI.It also addresses NAT traversal, documents: ISAKMP, IKE and DOI.It also addresses NAT traversal,
legacy authentication and remote address acquisition. IKEv2 is not legacy authentication and remote address acquisition. IKEv2 is not
interoperable with IKEv1. interoperable with IKEv1.
o RFC 4718, IKEv2 Clarifications and Implementation Guidelines (I, o RFC 4718, IKEv2 Clarifications and Implementation Guidelines (I,
Oct. 2006) Oct. 2006)
[RFC4718] clarifies many areas of the IKEv2 specification that may be [RFC4718] clarifies many areas of the IKEv2 specification that may be
difficult to understand for developers who are not intimately difficult to understand for developers who are not intimately
familiar with the specification and its history. It does not familiar with the specification and its history. It does not
introduce any changes to the protocol, but rather provides introduce any changes to the protocol, but rather provides
descriptions that are less prone to ambiguous interpretations. The descriptions that are less prone to ambiguous interpretations. The
goal of this document is to encourage the development of goal of this document is to encourage the development of
interoperable implementations. interoperable implementations.
o draft-ietf-ipsecme-ikev2bis-xx.txt, Internet Key Exchange o draft-ietf-ipsecme-ikev2bis, Internet Key Exchange Protocol:
Protocol: IKEv2 (S) IKEv2 (S)
This document combines the original IKEv2 RFC [RFC4306] with the
Clarifications RFC [RFC4718], and resolves many implementation issues
discovered by the community since the publication of these two
documents.
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
can the gateway (the IKE responder) force the remote user (the IKE
initiator) to periodically re-authenticate, limiting the damage in
the case where an unauthorized user gains physical access to the
remote host? This document defines a new informational message that a
responder can send to an initiator, notifying the initiator that the
IPsec SA will be revoked unless the initiator re-authenticates.
o RFC 4739, Multiple Authentication Exchanges in the Internet Key o RFC 4739, Multiple Authentication Exchanges in the Internet Key
Exchange (IKEv2) Protocol (E, Nov. 2006) Exchange (IKEv2) Protocol (E, Nov. 2006)
IKEv2 supports several mechanisms for authenticating the parties but IKEv2 supports several mechanisms for authenticating the parties but
each endpoint uses only one of these mechanisms to authenticate each endpoint uses only one of these mechanisms to authenticate
itself. [RFC4739] specifies an extension to IKEv2 that allows the itself. [RFC4739] specifies an extension to IKEv2 that allows the
use of multiple authentication exchanges, using either different use of multiple authentication exchanges, using either different
mechanisms or the same mechanism. This extension allows, for mechanisms or the same mechanism. This extension allows, for
instance, performing certificate-based authentication of the client instance, performing certificate-based authentication of the client
host followed by an EAP authentication of the user. This also allows host followed by an EAP authentication of the user. This also allows
skipping to change at page 15, line 38 skipping to change at page 16, line 33
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. at regular intervals. This RFC defines an optional extension to
IKEv1; dead peer detection (DPD) is an integral part of IKEv2.
4.2.3. Remote Access 4.2.4. Remote Access
o draft-ietf-ipsecme-ikev2-resumption-00.txt, IKEv2 Session o draft-ietf-ipsecme-ikev2-resumption, IKEv2 Session Resumption
Resumption (S) (S)
o draft-ietf-ipsecme-ikev2-redirect-02.txt, Re-direct Mechanism This document enables a remote client that has been disconnected from
for IKEv2 (S) a gateway to re-establish SAs with the gateway in an expedited
manner, without repeating the complete IKEv2 negotiation. This
capability requires changes to IKEv2.
o draft-ietf-ipsecme-ikev2-ipv6-config-00.txt, IPv6 Configuration o draft-ietf-ipsecme-ikev2-redirect, Re-direct Mechanism for IKEv2
in IKEv2 (S) (S)
This document enables a gateway to securely re-direct VPN clients to
another VPN gateway, either during or after the IKEv2 negotiation.
Possible reasons include, but are not limited to, an overloaded
gateway or a gateway that needs to shut down. This requires changes
to IKEv2.
o draft-ietf-ipsecme-ikev2-ipv6-config, IPv6 Configuration in
IKEv2 (S)
In IKEv2, a VPN gateway can assign an internal network address to a
remote VPN client. This is accomplished through the use of
configuration payloads. For an IPv6 client, the assignment of a
single address is not sufficient to enable full-fledged IPv6
communications. This document proposes several solutions that might
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
[RFC2119]; optional; not defined; or N/A (not applicable). Optional [RFC2119]; optional; not defined; or N/A (not applicable). Optional
skipping to change at page 16, line 31 skipping to change at page 17, line 45
combined mode algorithms, a new feature in IPsec-v3, for use with combined mode algorithms, a new feature in IPsec-v3, for use with
IPsec-v2). IPsec-v2).
This document categorizes the requirements level of each algorithm This document categorizes the requirements level of each algorithm
for IKEv1, IKEv2, IPsec-v2 and IPsec-v3. If an algorithm is for IKEv1, IKEv2, IPsec-v2 and IPsec-v3. If an algorithm is
recommended for use within IKEv1 or IKEv2, it is used either to recommended for use within IKEv1 or IKEv2, it is used either to
protect the IKE SA's traffic (encryption and integrity-protection protect the IKE SA's traffic (encryption and integrity-protection
algorithms) or to generate keying material (Diffie-Hellman or DH algorithms) or to generate keying material (Diffie-Hellman or DH
groups, Pseudo-Random Functions or PRFs). If an algorithm is groups, Pseudo-Random Functions or PRFs). If an algorithm is
recommended for use within IPsec, it is used to protect the recommended for use within IPsec, it is used to protect the
IPsec/child SA}s traffic, and IKE is capable of negotiating its use IPsec/child SA's traffic, and IKE is capable of negotiating its use
for that purpose. for that purpose.
5.1. Algorithm Requirements 5.1. Algorithm Requirements
Specifying a core set of mandatory algorithms for each protocol Specifying a core set of mandatory algorithms for each protocol
facilitates interoperability. Defining those algorithms in an RFC facilitates interoperability. Defining those algorithms in an RFC
separate from the base protocol RFC enhances algorithm agility. separate from the base protocol RFC enhances algorithm agility.
IPsec-v3 and IKEv2 each have an RFC that specifies their IPsec-v3 and IKEv2 each have an RFC that specifies their
mandatory-to-implement (MUST), recommended (SHOULD), optional (MAY), mandatory-to-implement (MUST), recommended (SHOULD), optional (MAY),
and deprecated (SHOULD NOT) algorithms. For IPsec-v2, this is and deprecated (SHOULD NOT) algorithms. For IPsec-v2, this is
included in the base protocol RFC. That was originally the case for included in the base protocol RFC. That was originally the case for
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 algorithms are algorithms for IPsec (both versions). Combined mode algorithms are
mentioned, but not assigned a requirement level. mentioned, but not assigned a requirement level.
NOTE: Algorithms for IPsec-v2 were originally defined in [RFC2402] NOTE: Algorithms for IPsec-v2 were originally defined in [RFC2402]
and [RFC2406]. [RFC4305] obsoleted those requirements, and was in and [RFC2406]. [RFC4305] obsoleted those requirements, and was in
turn obsoleted by [RFC4835]. Therefore, by inference [RFC4835] turn obsoleted by [RFC4835]. Therefore, by inference [RFC4835]
applies to IPsec-v2 as well as IPsec-v3. 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)
skipping to change at page 17, line 43 skipping to change at page 19, line 11
The encryption algorithm RFCs describe how to use these algorithms to The encryption algorithm RFCs describe how to use these algorithms to
encrypt IKE and/or ESP traffic, providing confidentiality protection encrypt IKE and/or ESP traffic, providing confidentiality protection
to the traffic. They describe any special constraints, requirements, to the traffic. They describe any special constraints, requirements,
or changes to packet format appropriate for the specific algorithm. or changes to packet format appropriate for the specific algorithm.
In general, they do not describe the detailed algorithmic In general, they do not describe the detailed algorithmic
computations; the reference section of each RFC includes pointers to computations; the reference section of each RFC includes pointers to
documents that define the inner workings of the algorithm. Some of documents that define the inner workings of the algorithm. Some of
the RFCs include sample test data, to enable implementors to compare the RFCs include sample test data, to enable implementors to compare
their results with standardized output. their results with standardized output.
Some of the encryption algorithms are stream ciphers, which must be When any encryption algorithm is used to provide confidentiality, the
used in conjunction with an integrity-protection algorithm. Even use of integrity(protection is strongly recommended. If the
when using other types of encryption algorithms, the use of encryption algorithm is a stream cipher, omitting
integrity-protection is strongly recommended. integrity-protection seriously compromises the security properties of
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
skipping to change at page 19, line 16 skipping to change at page 20, line 34
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. When AES-CTR is used as the encryption with manual keying. AES-CTR can be pipelined and parallelized; it
algorithm, integrity-protection must also be used. AES-CTR can be uses only the AES encryption operations for both encryption and
pipelined and parallelized; it uses only the AES encryption decryption.
operations for both encryption and decryption.
Requirements levels for AES-CTR: IKEv1 - not defined (no IANA #); Requirements levels for AES-CTR: IKEv1 - not defined (no IANA #);
IKEv2 - optional or not defined (see NOTE); ESP-v2 - SHOULD IKEv2 - optional or not defined (see NOTE); ESP-v2 - SHOULD
[RFC4835]; ESP-v3 - SHOULD [RFC4835] [RFC4835]; ESP-v3 - SHOULD [RFC4835]
NOTE: AES-CTR does not have an IANA number for IKEv1; since the same NOTE: AES-CTR does not have an IANA number for IKEv1; since the same
IANA numbers are used for IKEv2 and IPsec-v3, does [RFC3686] suffice IANA numbers are used for IKEv2 and IPsec-v3, does [RFC3686] suffice
to define the use of AES-CTR within IKEv2? 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
skipping to change at page 20, line 12 skipping to change at page 21, line 28
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;
the reference section of each RFC includes pointers to documents that the reference section of each RFC includes pointers to documents that
define the inner workings of the algorithm. Some of the RFCs include define the inner workings of the algorithm. Some of the RFCs include
sample test data, to enable implementors to compare their results sample test data, to enable implementors to compare their results
with standardized output. with standardized output.
HMAC-MD5, as described in [RFC2403], was originally a required
algorithm for IKEv1 and IPsec-v2. Since the use of MD5 and HMAC-MD5
is now deprecated, this roadmap does not include [RFC2403].
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: IKEv1 - MUST [RFC4109]; IKEv2 -
MUST [RFC4307]; IPsec-v2 - MUST [RFC4835]; IPsec-v3 - MUST [RFC4835] MUST [RFC4307]; IPsec-v2 - MUST [RFC4835]; IPsec-v3 - MUST [RFC4835]
skipping to change at page 21, line 29 skipping to change at page 22, line 40
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: IKEv1 - N/A; IKEv2 - optional;
IPsec-v2 - not defined (no IANA #); IPsec-v3 - 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.
1998)
[RFC2403] describes HMAC-MD5, an integrity-protection algorithm with
a 512-bit blocksize, and a 128-bit key and Integrity Check Value
(ICV). For use within IPsec, the ICV is truncated to 96 bits. It
was a required algorithm for IKEv1 and IPsec-v2. The use of plain
MD5 is now deprecated, but [RFC4835] states: "Weaknesses have become
apparent in MD5; however, these should not affect the use of MD5 with
HMAC."
Requirements levels for HMAC-MD5: IKEv1 - MAY [RFC4109]; IKEv2 -
optional [RFC4307]; IPsec-v2 - MAY [RFC4835]; IPsec-v3 - MAY
[RFC4835]
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: IKEv1 - not defined (no IANA #);
skipping to change at page 22, line 21 skipping to change at page 23, line 47
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
recommended for IKEv2 [RFC4307] and IPsec-v3 [RFC4305] are not recommended for IKEv2 [RFC4307] and IPsec-v3 [RFC4305] are not
currently susceptible to any known attacks. Nonetheless, it suggests currently susceptible to any known attacks. Nonetheless, it suggests
that implementors add support for AES-XCBC-MAC-96 [RFC3566], that implementors add support for AES-XCBC-MAC-96 [RFC3566],
AES-XCBC-PRF-128 [RFC4434] and HMAC-SHA-256, -384, and -512 [RFC4868] AES-XCBC-PRF-128 [RFC4434] and HMAC-SHA-256, -384, and -512 [RFC4868]
for future use. It also suggests that IKEv2 implementors add support for future use. It also suggests that IKEv2 implementors add support
for PKIX certificates signed with HMAC-SHA-256, -384, and -512. for PKIX certificates signed with HMAC-SHA-256, -384, and -512.
5.4. Combined Algorithms 5.4. Combined Mode Algorithms
IKEv1 and ESP-v2 use separate algorithms to provide encryption and
integrity-protection, and IKEv1 can negotiate different combinations
of algorithms for different SAs. In ESP-v3, a new class of
algorithms was introduced, in which a single algorithm can provide
both encryption and integrity-protection. [RFC4306] describes how
IKEv2 can negotiate combined mode algorithms to be used in ESP-v3
SAs. [RFC5282] adds that capability to IKEv2, enabling IKEv2 to
negotiate and use combined mode algorithms for its own traffic. When
properly designed, these algorithms can provide increased efficiency
in both implementation and execution.
o RFC 4309, Using Advanced Encryption Standard (AES) CCM Mode with o RFC 4309, Using Advanced Encryption Standard (AES) CCM Mode with
IPsec Encapsulating Security Payload (ESP) (S, Dec. 2005) IPsec Encapsulating Security Payload (ESP) (S, Dec. 2005)
[RFC4309] describes how to use AES in Counter with CBC-MAC (CCM) [RFC4309] describes how to use AES in Counter with CBC-MAC (CCM)
mode, a combined alorithm, to encrypt and integrity-protect ESP-v3 mode, a combined alorithm, to encrypt and integrity-protect ESP-v3
traffic. AES-CCM is a block-mode cipher with a 128-bit blocksize; a traffic. AES-CCM is a block-mode cipher with a 128-bit blocksize; a
random IV that is sent in the packet along with the encrypted data; a random IV that is sent in the packet along with the encrypted data; a
24-bit salt value (1/SA); keysizes of 128, 192 and 256 bits, and ICV 24-bit salt value (1/SA); keysizes of 128, 192 and 256 bits, and ICV
sizes of 64, 96 and 128 bits. 128-bit keys are MUST; the other sizes sizes of 64, 96 and 128 bits. 128-bit keys are MUST; the other sizes
skipping to change at page 23, line 39 skipping to change at page 25, line 30
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)
[RFC5282] extends [RFC4309] and [RFC4106] to enable the use of [RFC5282] extends [RFC4309] and [RFC4106] to enable the use of
AES-CCM and AES-GCM to provide encryption and integrity-protection AES-CCM and AES-GCM to provide encryption and integrity-protection
for IKEv2 messages. for IKEv2 messages.
5.5. Pseudo-Random Functions (PRFs) 5.5. Pseudo-Random Functions (PRFs)
IKE uses pseudo-random functions (PRFs) to generate the secret keys
that are used in IKE SAs and IPsec SAs. These PRFs are generally the
same algorithms used for integrity-protection, but their output is
not truncated, since all of the generated bits are generally needed
for the keys. If the PRF's output is not long enough to supply the
required number of bits of keying material, the PRF is applied
iteratively until the requisite amount of keying material is
generated.
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.
skipping to change at page 25, line 47 skipping to change at page 27, line 47
Requirements levels for DH EC groups 19-21: IKEv1 - optional Requirements levels for DH EC groups 19-21: IKEv1 - optional
[RFC4109]; IKEv2 - 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/SSH, SMIME, 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: IKEv1
- optional; IKEv2 - optional - 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
skipping to change at page 26, line 23 skipping to change at page 28, line 23
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 infinite 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
to provide security for packets exchanged by large multicast groups.
It defines the components of the architectural framework; discusses
Group Security Associations (GSAs), key management, data handling and
security policies. Several existing protocols, including GDOI
[RFC3547], GSAKMP [RFC4535] and MIKEY [RFC3830], satisfy the group
key management requirements defined in this document.
o RFC 5374, Multicast Extensions to the Security Architecture for
the Internet Protocol (S, Nov. 2008)
[RFC5374] extends the security architecture defined in [4301] to
apply to multicast traffic. It defines a new class of SAs (GSAs -
Group Security Associations) and additional databases used to apply
IPsec protection to multicast traffic. It also describes revisions
and additions to the processing algorithms in [RFC4301].
o RFC 3547, The Group Domain of Interpretation (S, Jul. 2003) o RFC 3547, The Group Domain of Interpretation (S, Jul. 2003)
GDOI [RFC3547] extends IKEv1 so that it can be used to establish SAs
to protect multicast traffic. This document defines additional
exchanges and payloads to be used for that purpose.
o RFC 4046, Multicast Security (MSEC) Group Key Management o RFC 4046, Multicast Security (MSEC) Group Key Management
Architecture (I, Apr. 2005) Architecture (I, Apr. 2005)
[RFC4046] sets out the general requirements and design principles for
protocols that are used for multicast key management. It does not go
into the specifics of an individual protocol that can be used for
that purposel
o RFC 4535, GSAKMP: Group Secure Association Key Management o RFC 4535, GSAKMP: Group Secure Association Key Management
Protocol (S, Jun. 2006) Protocol (S, Jun. 2006)
[RFC4535] defines a protocol that can be used to generate, distribute
and manage keys to be used for secure group communications. GSAKMP
is also used to distribute and enforce group security policies. It
can be used to facilitate many-to-many communications and distributed
architectures.
o RFC 4534, Group Security Policy Token v1 (S, Jun. 2006) o RFC 4534, Group Security Policy Token v1 (S, Jun. 2006)
[RFC4534] specifies the structure of the Group Security Policy Token,
"a structure used to specify the security policy and configurable
parameters for a cryptographic group, such as a secure multicast
group." This token can be used within GSAKMP to define and enforce
group polices such as secure access control.
o RFC 3830, MIKEY: Multimedia Internet KEYing (S, Aug. 2004) o RFC 3830, MIKEY: Multimedia Internet KEYing (S, Aug. 2004)
MIKEY [RFC3830] is a key management protocol, an alternative to GDOI
[RFC3547] and GSAKMP [RFC4535], that is well-suited for use in
real-time, low-latency secure multimedia scenarios.
o RFC 4738, MIKEY-RSA-R: An Additional Mode of Key Distribution in o RFC 4738, MIKEY-RSA-R: An Additional Mode of Key Distribution in
Multimedia Internet KEYing (MIKEY) (S, Nov. 2006) Multimedia Internet KEYing (MIKEY) (S, Nov. 2006)
[RFC4738] adds an additional key distribution method to MIKEY:
MIKEY-RSA-R, reverse-mode RSA.
o RFC 5197, On the Applicability of Various Multimedia Internet o RFC 5197, On the Applicability of Various Multimedia Internet
KEYing (MIKEY) Modes and Extensions (I, Jun. 2008) KEYing (MIKEY) Modes and Extensions (I, Jun. 2008)
[RFC5197] provides in in-depth, integrated description of MIKEY modes
and extensions. It also includes sample real-world use cases.
o RFC 4563, The Key ID Information Type for the General Extension o RFC 4563, The Key ID Information Type for the General Extension
Payload in Multimedia Internet KEYing (MIKEY) (S, Jun. 2006) Payload in Multimedia Internet KEYing (MIKEY) (S, Jun. 2006)
[RFC4563] defines a MIKEY extension that satisfies the need for
frequent, efficient key update in the 3GPP environment.
o RFC 4359, The Use of RSA/SHA-1 Signatures within Encapsulating o RFC 4359, The Use of RSA/SHA-1 Signatures within Encapsulating
Security Payload (ESP) and Authentication Header (AH) (S, Jan. Security Payload (ESP) and Authentication Header (AH) (S, Jan.
2006) 2006)
[RFC4359] describes the use of the RSA digital signature algorithm to
provide integrity-protection for multicast traffic within ESP and AH.
The algorithms used for integrity-protection for unicast traffic
(e.g., HMAC) are not suitable for this purpose when used with
multicast traffic.
o RFC 4650, HMAC-Authenticated Diffie-Hellman for Multimedia o RFC 4650, HMAC-Authenticated Diffie-Hellman for Multimedia
Internet KEYing (MIKEY) (S, Sep. 2006) Internet KEYing (MIKEY) (S, Sep. 2006)
[RFC4650] "describes a lightweight point-to-point key management
protocol variant for the multimedia Internet keying (MIKEY) project."
o RFC 5410, Multimedia Internet KEYing (MIKEY) General Extension
Payload for Open Mobile Alliance BCAST 1.0 (I, Jan. 2009)
[RFC5410] describes one use of the General Extension Payload, defined
as part of the base MIKEY [RFC3830] protocol. This document
specifies a payload that can be used to transport keying material or
management data that is defined in the Open Mobile Alliance's (OMA)
Broadcast (BCAST) group's Service and Content protection
specification.
o RFC 4082, Timed Efficient Stream Loss-Tolerant Authentication o RFC 4082, Timed Efficient Stream Loss-Tolerant Authentication
(TESLA): Multicast Source Authentication Transform Introduction (TESLA): Multicast Source Authentication Transform Introduction
(I, Jun. 2005) (I, Jun. 2005)
TESLA is a scheme that provides source authentication and
integrity-protection to receivers of multicast traffic. Symmetric
algorithms cannot generally be used for this purpose with multicast
traffic; public-key algorithms, which can afford this protection,
require considerably greater overhead. TESLA leverages time
synchronization and delayed key disclosure to provide this protection
via the more efficient symmetric key algorithms. It can be used in
multicast groups with a very large number of receivers.
o RFC 4442, Bootstrapping Timed Efficient Stream Loss-Tolerant o RFC 4442, Bootstrapping Timed Efficient Stream Loss-Tolerant
Authentication (TESLA) (S, Mar. 2006) Authentication (TESLA) (S, Mar. 2006)
[RFC4442] describes MIKEY payloads that can be used to specify TESLA
parameters, thus bootstrapping the use of TESLA within the Secure
Real-time Transport Protocol (SRTP).
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
and broadcast traffic.
7. Outgrowths of IPsec/IKE 7. Outgrowths of IPsec/IKE
7.1. IPComp (Compression) 7.1. IPComp (Compression)
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 IPComp is a protocol that provides lossless compression for IP
datagrams. IP payload compression is especially useful when IPsec datagrams. IP payload compression is especially useful when IPsec
based encryption is applied to IP datagrams. Encrypting the IP based encryption is applied to IP datagrams. Encrypting the IP
skipping to change at page 28, line 28 skipping to change at page 32, line 16
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)
o draft-ietf-btns-connection-latching-xx.txt, IPsec Channels: o draft-ietf-btns-connection-latching, IPsec Channels: Connection
Connection Latching Latching
This document specifies, abstractly, how to interface applications This document specifies, abstractly, how to interface applications
and transport protocols with IPsec so as to create channels by and transport protocols with IPsec so as to create channels by
latching connections (packet flows) to certain IPsec Security latching connections (packet flows) to certain IPsec Security
Association (SA) parameters for the lifetime of the connections. Association (SA) parameters for the lifetime of the connections.
Connection latching is layered on top of IPsec and does not modify Connection latching is layered on top of IPsec and does not modify
the underlying IPsec architecture. the underlying IPsec 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)
skipping to change at page 29, line 4 skipping to change at page 32, line 39
[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
Security Policy Database (SPD). Security Policy Database (SPD).
o RFC 5387, Problem and Applicability Statement for o RFC 5387, Problem and Applicability Statement for
Better-Than-Nothing Security (BTNS) (I, Nov. 2008) Better-Than-Nothing Security (BTNS) (I, Nov. 2008)
[RFC5387] considers that the need to deploy authentication [RFC5387] considers that the need to deploy authentication
information and its associated identities is a significant obstacle information and its associated identities is a significant obstacle
to the use of IPsec. This document explains the rationale for to the use of IPsec. This document explains the rationale for
extending the Internet network security protocol suite to enable use extending the Internet network security protocol suite to enable use
of IPsec security services without authentication. of IPsec security services without authentication.
o RFC 5056, On the Use of Channel Bindings to Secure Channels (S,
Nov. 2007)
7.4. Kerberized Internet Negotiation of Keys (Kink) 7.4. Kerberized Internet Negotiation of Keys (Kink)
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 29, line 32 skipping to change at page 33, line 18
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)
[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. order to foster substantial reuse of IKEv1 implementations. This RFC
has not been widely adopted.
7.5. IPsec Secure Remote Access (IPSRA) 7.5. IPsec Secure Remote Access (IPSRA)
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. information. This RFC has not been widely adopted.
7.6. IPsec Keying Information Resource Record (IPsecKEY) 7.6. IPsec Keying Information Resource Record (IPsecKEY)
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 DNS using a new type of resource record. This document describes how
to store the public key of the target node in this resource record. to store the public key of the target node in this resource record.
This RFC has not been widely adopted.
8. Other Protocols that use IPsec/IKE 8. Other Protocols that use IPsec/IKE
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
virtual private networks (VPNs). IPsec is one of the VPN
technologies covered by this document. It identifes and describes
practical deployment scenarios for Mobile IPv4 running alongside
IPsec in enterprise and operator environments. It also specifies a
set of framework guidelines to evaluate proposed solutions for
supporting multi-vendor seamless IPv4 mobility across IPsec-based VPN
gateways.
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)
o RFC 4877, Mobile IPv6 Operation with IKEv2 and the Revised IPsec This document describes a basic solution that uses Mobile IPv4 and
Architecture (S, Apr. 2007) IPsec to provide session mobility between enterprise intranets and
external networks. The proposed solution minimizes changes to
existing firewall/VPN/DMZ deployments and does not require any
changes to IPsec or key exchange protocols. It also proposes a
mechanism to minimize IPsec renegotiation when the mobile node moves.
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)
o draft-ietf-mip6-cn-ipsec-xx.txt, Using IPsec between Mobile and This document illustrates the use of IPsec in securing Mobile IPv6
traffic between mobile nodes and home agents. It specifies the
required wire formats for the protected packets and illustrates
examples of Security Policy Database and Security Association
Database entries that can be used to protect Mobile IPv6 signaling
messages. It also describes how to configure either manually keyed
IPsec security associations or how to configure IKEv1 to establish
the SAs automatically.
o RFC 4877, Mobile IPv6 Operation with IKEv2 and the Revised IPsec
Architecture (S, Apr. 2007)
This document updates [RFC3776] in order to work with the revised
IPsec architecture [RFC4301]. Since the revised IPsec architecture
expands the list of selectors to include the Mobility Header message
type, it becomes much easier to differentiate between different
mobility header messages. Since the ICMP message type and code are
also newly added as selectors, this document uses them to protect
Mobile Prefix Discovery messages. Finally, this document describes
the use of IKEv2 in order to set up the SAs for Mobile IPv6.
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"
(RO) mode that enables the mobile node to communicate with a
corresponding node using the most direct path between them instead of
passing through the home agent. It also defines a mechanism called
the return routability procedure in order to secure the RO signaling.
This document defines an alternative mechanism for Mobile IPv6 route
optimization based on strong authentication and IPsec. It specifies
which IPsec configurations can be useful in a Mobile IPv6 context and
how they can validate Home Address Options and protect mobility
signaling. It also provides detailed IKEv1 and IKEv2 configuration
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
that is used to provide mobility services hosts without requiring
their participation in any mobility-related signaling. It uses IPsec
to protect the mobility signaling messages between the two network
entities called the mobile access gateway (MAG) and the local
mobility anchor (LMA). It also uses IKEv2 in order to set up the
security associations between the MAG and the LMA.
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
which the Mobile Node is unable to send or receive packets because of
link switching delay and IP protocol operations. This document
specifies a protocol between the Previous Access Router (PAR) and the
New Access Router (NAR) to improve handover latency due to Mobile
IPv6 procedures. It uses IPsec ESP in transport mode with integrity
protection for protecting the signaling messages between the PAR and
the NAR. It also describes the SPD entries and the PAD entries when
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
Discovery to allow for local mobility handling in order to reduce the
amount of signalling between the mobile node, its correspondent
nodes, and its home agent. It also improves handover speed of Mobile
IPv6. It uses IPsec for protecting the signaling between the mobile
node and a local mobility management entity called the Mobility
Anchor Point (MAP). The MAP also uses IPsec Peer Authorization
Database (PAD) entries and configuration payloads described in
[RFC4877] in order to allocate a Regional Care-of Address (RCoA) for
mobile nodes.
8.2. Open Shortest Path First (OSPF) 8.2. Open Shortest Path First (OSPF)
o RFC 4552, Authentication/Confidentiality for OSPFv3 (S, Jun. o RFC 4552, Authentication/Confidentiality for OSPFv3 (S, Jun.
2006) 2006)
OSPF is a link-state routing protocol that is designed to be run
inside a single Autonomous System. OSPFv2 provided its own
authentication mechanisms using the AuType and Authentication
protocol header fields but OSPFv3 removed these fields and uses IPsec
instead. This document describes how to use IPsec ESP and AH in
order to protect OSPFv3 signaling between two routers. It also
enumerates the IPsec capabilities the routers require in order to
support this specification. Finally, it also describes the operation
of OSPFv3 with IPsec over virtual links where the other endpoint is
not known at configuration time.
8.3. Host Identity Protocol (HIP) 8.3. Host Identity Protocol (HIP)
o RFC 5201, Host Identity Protocol (E, Apr. 2008) o RFC 5201, Host Identity Protocol (E, Apr. 2008)
This document specifies a protocol that allows consenting hosts to
securely establish and maintain shared IP-layer state, allowing
separation of the identifier and locator roles of IP addresses. This
enables continuity of communications across IP address (locator)
changes. It uses the HMAC-SHA-1-96 and the AES-CBC algorithms with
IPsec ESP and AH for protecting its signaling messages.
o RFC 5202, Using the Encapsulating Security Payload (ESP) o RFC 5202, Using the Encapsulating Security Payload (ESP)
Transport Format with the Host Identity Protocol (HIP) (E, Apr. Transport Format with the Host Identity Protocol (HIP) (E, Apr.
2008) 2008)
The HIP base exchange specification [RFC5201] does not describe any
transport formats or methods for for describing how ESP is used to
protect user data to be used during the actual communication. This
document specifies a set of HIP protocol extensions for creating a
pair of ESP Security Associations (SAs) between the hosts during the
base exchange. After the HIP association and required ESP SAs have
been established between the hosts, the user data communication is
protected using ESP. In addition, this document specifies how to use
the ESP Security Parameter Index (SPI) is used to indicate the right
host context(host identity) and methods to update an existing ESP
Security Association.
o RFC 5206, End-Host Mobility and Multihoming with the Host o RFC 5206, End-Host Mobility and Multihoming with the Host
Identity (E, Apr. 2008) Identity (E, Apr. 2008)
When a host uses HIP, the overlying protocol sublayers (e.g.,
transport layer sockets and Encapsulating Security Payload (ESP)
Security Associations (SAs) are bound to representations of these
host identities, and the IP addresses are only used for packet
forwarding. This document defines a generalized LOCATOR parameter
for use in HIP messages that allows a HIP host to notify a peer about
alternate addresses at which it is reachable. It also specifies how
a host can change its IP address and continue to send packets to its
peers without necessarily rekeying.
o RFC 5207, NAT and Firewall Traversal Issues of Host Identity o RFC 5207, NAT and Firewall Traversal Issues of Host Identity
Protocol (HIP) (I, Apr. 2008) Protocol (HIP) (I, Apr. 2008)
This document discusses the problems associated with HIP
communication across network paths that include network address
translators and firewalls. It analyzes the impact of NATs and
firewalls on the HIP base exchange and the ESP data exchange. It
discusses possible changes to HIP that attempt to improve NAT and
firewall traversal and proposes a rendezvous point for letting HIP
nodes behind a NAT be reachable. It also suggests mechanisms for
NATs to be more aware of the HIP messages.
8.4. Extensible Authentication Protocol (EAP) Method Update (EMU) 8.4. Extensible Authentication Protocol (EAP) Method Update (EMU)
o RFC 5106, The Extensible Authentication Protocol-Internet Key o RFC 5106, The Extensible Authentication Protocol-Internet Key
Exchange Protocol version 2 (EAP-IKEv2) Method (E, Feb. 2008) Exchange Protocol version 2 (EAP-IKEv2) Method (E, Feb. 2008)
This document specifies an Extensible Authentication Protocol (EAP)
method that is based on the Internet Key Exchange (IKEv2) protocol.
EAP-IKEv2 provides mutual authentication and session key
establishment between an EAP peer and an EAP server. It describes
the full EAP-IKEv2 message exchange and the composition of the
protocol messages.
8.5. Stream Control Transmission Protocol (SCTP) 8.5. Stream Control Transmission Protocol (SCTP)
o RFC 3554, On the Use of Stream Control Transmission Protocol o RFC 3554, On the Use of Stream Control Transmission Protocol
(SCTP) with IPsec (S, Jul. 2003) (SCTP) with IPsec (S, Jul. 2003)
The Stream Control Transmission Protocol (SCTP) is a reliable
transport protocol operating on top of a connection-less packet
network such as IP. This document describes functional requirements
for IPsec and IKE to be used in securing SCTP traffic. It adds
support for SCTP in the form of a new ID type in IKE [RFC2409] and
implementation choices in the IPsec processing to account for the
multiple source and destination addresses associated with a single
SCTP association.
8.6. Fibre Channel 8.6. Fibre Channel
o RFC 4595, Use of IKEv2 in the Fibre Channel Security Association
Management Protocol (I, Jul. 2006)
o RFC 4595, Use of IKEv2 in the Fibre Channel Security Fibre Channel (FC) is a gigabit-speed network technology used for
Association Management Protocol (I, Jul. 2006) Storage Area Networking. The Fibre Channel Security Protocols
standard (FC-SP) has adapted the IKEv2 protocol [RFC4306] to provide
authentication of Fibre Channel entities and setup of security
associations. Since IP is transported over Fibre Channel [RFC4338]
and Fibre Channel/SCSI are transported over IP [RFC3643], [RFC3821]
there is the potential for confusion when IKEv2 is used for both IP
and FC traffic. This document specifies identifiers for IKEv2 over
FC in a fashion that ensures that any mistaken usage of IKEv2/FC over
IP or IKEv2/IP over FC will result in a negotiation failure due to
the absence of an acceptable proposal.
8.7. Protocol for Carrying Authentication for Network Access (PANA) 8.7. Robust Header Compression (ROHC)
o RFC 5191, Protocol for Carrying Authentication for Network o RFC 3095, RObust Header Compression (ROHC): Framework and four
Access (PANA) (S, May 2008) profiles: RTP, UDP, ESP, and uncompressed (S, July 2001)
ROHC is a framework for header compression, intended to be used in
resource-constrained environments. [RFC3095] applies this framework
to four protocols, including ESP.
o RFC 5225, RObust Header Compression Version 2 (ROHCv2): Profiles
for RTP, UDP, IP, ESP, and UDP-Lite (S, April 2008)
[RFC5225] includes an ESP profile for use with ROHC version 2.
9. Security Considerations 9. Security Considerations
There are no security considerations relevant to this document. There are no security considerations relevant to this document.
10. IANA Considerations 10. 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.
skipping to change at page 31, line 49 skipping to change at page 39, line 9
11.2. Informative References 11.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.
[btns-1] Williams, N., "IPsec Channels: Connection Latching", [btns-1] Williams, N., "IPsec Channels: Connection Latching",
draft-ietf-btns-connection-latching-xx.txt, Work in draft-ietf-btns-connection-latching, Work in Progress.
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-xx.txt, 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-00.txt, IPv6 draft-ietf-ipsecme-ikev2-ipv6-config, IPv6 Configuration
Configuration in IKEv2, Work in Progress. in IKEv2, Work in Progress.
[ipsecme-3] Devarapalli, V and K. Weniger, [ipsecme-3] Devarapalli, V and K. Weniger,
draft-ietf-ipsecme-ikev2-redirect-02.txt, Re-direct draft-ietf-ipsecme-ikev2-redirect, Re-direct Mechanism for
Mechanism for IKEv2, Work in Progress. IKEv2, Work in Progress.
[ipsecme-4] Sheffer, Y., H. Tschofenig, L. Dondeti and V. Narayanan, [ipsecme-4] Sheffer, Y., H. Tschofenig, L. Dondeti and V. Narayanan,
draft-ietf-ipsecme-ikev2-resumption-00.txt, IKEv2 Session draft-ietf-ipsecme-ikev2-resumption, IKEv2 Session
Resumption, Work in Progress. Resumption, Work in Progress.
[ipsecme-5] Grewal, K. and G. Montenegro, [ipsecme-5] Grewal, K. and G. Montenegro,
draft-ietf-ipsecme-traffic-visibility-00.txt, Wrapped ESP draft-ietf-ipsecme-traffic-visibility, Wrapped ESP for
for Traffic Visibility, Work in Progress. Traffic Visibility, Work in Progress.
[mip6-1] Dupong, F. and J-M. Combes, "Using IPsec between Mobile and [ipsecme-6] Kivinen, T. and D. McDonald,
Correspondent IPv6 Nodes", draft-kivinen-ipsecme-esp-null-heuristics, Heuristics for
draft-ietf-mip6-cn-ipsec-xx.txt, Work in Progress. Detecting ESP-NULL packets, Work in Progress.
[mip6-1] Dupont, F. and J-M. Combes, "Using IPsec between Mobile
and Correspondent IPv6 Nodes", draft-ietf-mip6-cn-ipsec,
Work in Progress.
[RFC2394] Pereira, R., "IP Payload Compression Using DEFLATE", RFC [RFC2394] Pereira, R., "IP Payload Compression Using DEFLATE", RFC
2394, December 1998. 2394, December 1998.
[RFC2395] Friend, R. and R. Monsour, "IP Payload Compression Using [RFC2395] Friend, R. and R. Monsour, "IP Payload Compression Using
LZS", RFC 2395, December 1998. LZS", RFC 2395, December 1998.
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998 (obsolete). Internet Protocol", RFC 2401, November 1998 (obsolete).
skipping to change at page 33, line 35 skipping to change at page 40, line 44
[RFC2451] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher [RFC2451] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher
Algorithms", RFC 2451, November 1998. Algorithms", RFC 2451, November 1998.
[RFC2857] Keromytis, A. and N. Provos, "The Use of [RFC2857] Keromytis, A. and N. Provos, "The Use of
HMAC-RIPEMD-160-96 within ESP and AH", RFC 2857, June HMAC-RIPEMD-160-96 within ESP and AH", RFC 2857, June
2000. 2000.
[RFC3056] Carpenter, B., "Connection of IPv6 Domains via IPv4 [RFC3056] Carpenter, B., "Connection of IPv6 Domains via IPv4
Clouds", RFC 3056, February 2001. Clouds", RFC 3056, February 2001.
[RFC3095] Bormann, C., Ed. et.al., "RObust Header Compression
(ROHC): Framework and four profiles: RTP, UDP, ESP, and
uncompressed", RFC 3095, July 2001.
[RFC3129] Thomas, M., "Requirements for Kerberized Internet [RFC3129] Thomas, M., "Requirements for Kerberized Internet
Negotiation of Keys", RFC 3129, June 2001. Negotiation of Keys", RFC 3129, June 2001.
[RFC3173] Shacham, A. B. Monsour, R. Pereira and M. Thomas, "IP [RFC3173] Shacham, A. B. Monsour, R. Pereira and M. Thomas, "IP
Payload Compression Protocol (IPComp)", RFC 3173, Payload Compression Protocol (IPComp)", RFC 3173,
September 2001. September 2001.
[RFC3456] Patel, B. B. Aboba, S. Kelly and V. Gupta, "Dynamic Host [RFC3456] Patel, B. B. Aboba, S. Kelly and V. Gupta, "Dynamic Host
Configuration Protocol (DHCPv4) Configuration of IPsec Configuration Protocol (DHCPv4) Configuration of IPsec
Tunnel Mode", RFC 3456, January 2003. Tunnel Mode", RFC 3456, January 2003.
skipping to change at page 38, line 52 skipping to change at page 46, line 15
[RFC4894] Hoffman, P., "Use of Hash Algorithms in Internet Key [RFC4894] Hoffman, P., "Use of Hash Algorithms in Internet Key
Exchange (IKE) and IPsec", RFC 4894, May 2007. Exchange (IKE) and IPsec", RFC 4894, May 2007.
[RFC4945] Korver, B., "The Internet IP Security PKI Profile of [RFC4945] Korver, B., "The Internet IP Security PKI Profile of
IKEv1/ISAKMP, IKEv2, and PKIX", RFC 4945, August 2007. IKEv1/ISAKMP, IKEv2, and PKIX", RFC 4945, August 2007.
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2", RFC [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", RFC
4949, August 2007. 4949, August 2007.
[RFC5056] Williams, N., "On the Use of Channel Bindings to Secure
Channels", RFC 5056, November 2007.
[RFC5106] Tschofenig, H., D. Kroeselberg, A. Pashalidis, Y. Ohba and [RFC5106] Tschofenig, H., D. Kroeselberg, A. Pashalidis, Y. Ohba and
F. Bersani, "The Extensible Authentication F. Bersani, "The Extensible Authentication
Protocol-Internet Key Exchange Protocol version 2 Protocol-Internet Key Exchange Protocol version 2
(EAP-IKEv2) Method", RFC 5106, February 2008. (EAP-IKEv2) Method", RFC 5106, February 2008.
[RFC5114] Lepinski, M. and S. Kent, "Additional Diffie-Hellman [RFC5114] Lepinski, M. and S. Kent, "Additional Diffie-Hellman
Groups for Use with IETF Standards", RFC 5114, January Groups for Use with IETF Standards", RFC 5114, January
2008. 2008.
[RFC 5191] Forsberg, D., Y. Ohba, Ed., B. Patil, H. Tschofenig and
A. Yegin, Protocol for Carrying Authentication for Network
Access (PANA), RFC 5191, May 2008.
[RFC5197] Fries, S. and D. Ignjatic, "On the Applicability of [RFC5197] Fries, S. and D. Ignjatic, "On the Applicability of
Various Multimedia Internet KEYing (MIKEY) Modes and Various Multimedia Internet KEYing (MIKEY) Modes and
Extensions", RFC 5197, June 2008. Extensions", RFC 5197, June 2008.
[RFC5201] Moskowitz, R., P. Nikander, P. Jokela, Ed., and T. [RFC5201] Moskowitz, R., P. Nikander, P. Jokela, Ed., and T.
Henderson, "Host Identity Protocol", RFC 5201, April 2008. Henderson, "Host Identity Protocol", RFC 5201, April 2008.
[RFC5202] Jokela, P., R. Moskowitz and P. Nikander, "Using the [RFC5202] Jokela, P., R. Moskowitz and P. Nikander, "Using the
Encapsulating Security Payload (ESP) Transport Format with Encapsulating Security Payload (ESP) Transport Format with
the Host Identity Protocol (HIP)", RFC 5202, April 2008. the Host Identity Protocol (HIP)", RFC 5202, April 2008.
[RFC5206] Nikander, P., T. Henderson, Ed., C. Vogt, and J. Arkko, [RFC5206] Nikander, P., T. Henderson, Ed., C. Vogt, and J. Arkko,
"End-Host Mobility and Multihoming with the Host "End-Host Mobility and Multihoming with the Host
Identity", RFC 5206, April 2008. Identity", RFC 5206, April 2008.
[RFC5207] Stiemerling, M., J. Quittek and L. Eggert, "NAT and [RFC5207] Stiemerling, M., J. Quittek and L. Eggert, "NAT and
Firewall Traversal Issues of Host Identity Protocol Firewall Traversal Issues of Host Identity Protocol
(HIP)", RFC 5207, April 2008. (HIP)", RFC 5207, April 2008.
[RFC5213] Gundavelli, Ed., K. Leung, V. Devarapali, K. Chowdhury and [RFC5213] Gundavelli, S., Ed., K. Leung, V. Devarapali, K. Chowdhury
B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
[RFC5225] Pelletier, G. and K. Sandlund, "RObust Header Compression
Version 2 (ROHCv2): Profiles for RTP, UDP, IP, ESP, and
UDP-Lite", RFC 5225, April 2008.
[RFC5265] Vaarala, S. and E. Klovning, "Mobile IPv4 Traversal across [RFC5265] Vaarala, S. and E. Klovning, "Mobile IPv4 Traversal across
IPsec-Based VPN Gateways", RFC 5265, June 2008. IPsec-Based VPN Gateways", RFC 5265, June 2008.
[RFC5266] Devarapalli, V. and P. Eronen, "Secure Connectivity and [RFC5266] Devarapalli, V. and P. Eronen, "Secure Connectivity and
Mobility Using Mobile IPv4 and IKEv2 Mobility and Mobility Using Mobile IPv4 and IKEv2 Mobility and
Multihoming (MOBIKE)", RFC 5266, June 2008. Multihoming (MOBIKE)", RFC 5266, June 2008.
[RFC5268] Koodli, R., Ed., "Mobile IPv6 Fast Handovers", RFC 5268, [RFC5268] Koodli, R., Ed., "Mobile IPv6 Fast Handovers", RFC 5268,
June 2008. June 2008.
skipping to change at page 40, line 16 skipping to change at page 47, line 25
2008. 2008.
[RFC5380] Soliman, H., C. Castelluccia, K. ElMalki and L. Bellier, [RFC5380] Soliman, H., C. Castelluccia, K. ElMalki and L. Bellier,
"Hierarchical Mobile IPv6 (HMIPv6) Mobility Management", "Hierarchical Mobile IPv6 (HMIPv6) Mobility Management",
RFC 5380, October 2008. RFC 5380, October 2008.
[RFC5386] Williams, N. and M. Richardson, [RFC5386] Williams, N. and M. Richardson,
"Better-Than-Nothing-Security: An Unauthenticated Mode of "Better-Than-Nothing-Security: An Unauthenticated Mode of
IPsec", RFC 5386, November 2008. IPsec", RFC 5386, November 2008.
[RFC5374] Weis, B., G. Gross and D. Ignjatic, "Multicast Extensions
to the Security Architecture for the Internet Protocol",
RFC 5374, November 2008.
[RFC5387] Touch, J., D. Black and Y. Wang, "Problem and [RFC5387] Touch, J., D. Black and Y. Wang, "Problem and
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
Version 2", RFC 5406, February 2009.
[RFC 5410] Jerichow, A., Ed., and L. Piron, "Multimedia Internet
KEYing (MIKEY) General Extension Payload for Open Mobile
Alliance BCAST 1.0", RFC 5410, January 2009.
Authors' Addresses Authors' Addresses
Sheila Frankel Sheila Frankel
NIST Bldg. 223 Rm. B366 NIST
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
 End of changes. 95 change blocks. 
143 lines changed or deleted 487 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/