draft-ietf-ipsecme-roadmap-09.txt   draft-ietf-ipsecme-roadmap-10.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: February 2011 August 10, 2010 Expires: February 2011 August 13, 2010
IP Security (IPsec) and Internet Key Exchange (IKE) Document Roadmap IP Security (IPsec) and Internet Key Exchange (IKE) Document Roadmap
<draft-ietf-ipsecme-roadmap-09.txt> <draft-ietf-ipsecme-roadmap-10.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 February 10, 2011. This Internet-Draft will expire on February 13, 2011.
Copyright and License Notice Copyright and License Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 19 skipping to change at page 2, line 19
that these RFCs originate from numerous IETF working groups: the that these RFCs originate from numerous IETF working groups: the
original IPsec WG, its various spin-offs, and other WGs that use original IPsec WG, its various spin-offs, and other WGs that use
IPsec and/or IKE to protect their protocols' traffic. IPsec and/or IKE to protect their protocols' traffic.
This document is a snapshot of IPsec- and IKE-related RFCs. It This document is a snapshot of IPsec- and IKE-related RFCs. It
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].
The obsoleted IPsec roadmap [RFC2411] briefly described the
interrelationship of the various classes of base IPsec documents.
The major focus of [RFC2411] was to specify the recommended contents
of documents specifying additional encryption and authentication
algorithms.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. IPsec/IKE Background Information . . . . . . . . . . . . . . . . 4 2. IPsec/IKE Background Information . . . . . . . . . . . . . . . . 4
2.1. Interrelationship of IPsec/IKE Documents . . . . . . . . . 5 2.1. Interrelationship of IPsec/IKE Documents . . . . . . . . . 5
2.2. Versions of IPsec . . . . . . . . . . . . . . . . . . . . . 6 2.2. Versions of IPsec . . . . . . . . . . . . . . . . . . . . . 6
2.2.1. Differences between "old" IPsec (IPsec-v2) and 2.2.1. Differences between "old" IPsec (IPsec-v2) and
"new" IPsec (IPsec-v3) . . . . . . . . . . . . . . . . 6 "new" IPsec (IPsec-v3) . . . . . . . . . . . . . . . . 6
2.3. Versions of IKE . . . . . . . . . . . . . . . . . . . . . . 7 2.3. Versions of IKE . . . . . . . . . . . . . . . . . . . . . . 7
2.3.1. Differences between IKEv1 and IKEv2 . . . . . . . . . . 8 2.3.1. Differences between IKEv1 and IKEv2 . . . . . . . . . . 8
skipping to change at page 3, line 34 skipping to change at page 3, line 39
8.10. Explicit Packet Sensitivity Labels . . . . . . . . . . . . 47 8.10. Explicit Packet Sensitivity Labels . . . . . . . . . . . . 47
9. Other Protocols that adapt IKE for non-IPsec 9. Other Protocols that adapt IKE for non-IPsec
functionality . . . . . . . . . . . . . . . . . . . . . . . . . 47 functionality . . . . . . . . . . . . . . . . . . . . . . . . . 47
9.1. Extensible Authentication Protocol (EAP) . . . . . . . . . 47 9.1. Extensible Authentication Protocol (EAP) . . . . . . . . . 47
9.2. Fibre Channel . . . . . . . . . . . . . . . . . . . . . . . 47 9.2. Fibre Channel . . . . . . . . . . . . . . . . . . . . . . . 47
9.3. Wireless Security . . . . . . . . . . . . . . . . . . . . . 48 9.3. Wireless Security . . . . . . . . . . . . . . . . . . . . . 48
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 48 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 48
11. Security Considerations . . . . . . . . . . . . . . . . . . . . 48 11. Security Considerations . . . . . . . . . . . . . . . . . . . . 48
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 48 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 48
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
13.1. Normative References . . . . . . . . . . . . . . . . . . . 48 13.1. Normative References . . . . . . . . . . . . . . . . . . . 49
13.2. Informative References . . . . . . . . . . . . . . . . . . 49 13.2. Informative References . . . . . . . . . . . . . . . . . . 49
Appendix A. Summary of Algorithm Requirement Levels . . . . . . . . 59 Appendix A. Summary of Algorithm Requirement Levels . . . . . . . . 59
1. Introduction 1. Introduction
IPsec (Internet Protocol Security) is a suite of protocols that IPsec (Internet Protocol Security) is a suite of protocols that
provides security to Internet communications at the IP layer. The provides security to Internet communications at the IP layer. The
most common current use of IPsec is to provide a Virtual Private most common current use of IPsec is to provide a Virtual Private
Network (VPN), either between two locations (gateway-to-gateway) or Network (VPN), either between two locations (gateway-to-gateway) or
between a remote user and an enterprise network (host-to-gateway); it between a remote user and an enterprise network (host-to-gateway); it
can also provide end-to-end, or host-to-host, security. IPsec is can also provide end-to-end, or host-to-host, security. IPsec is
skipping to change at page 23, line 31 skipping to change at page 23, line 31
roadmap does not include [RFC2405]. roadmap does not include [RFC2405].
5.2.1. RFC 2410, The NULL Encryption Algorithm and Its Use With IPsec 5.2.1. RFC 2410, The NULL Encryption Algorithm and Its Use With IPsec
(S, Nov. 1998) (S, Nov. 1998)
[RFC2410] is a tongue-in-cheek description of the no-op encryption [RFC2410] is a tongue-in-cheek description of the no-op encryption
algorithm (i.e. using ESP without encryption). In order for IKE to algorithm (i.e. using ESP without encryption). In order for IKE to
negotiate the selection of the NULL encryption algorithm for use in negotiate the selection of the NULL encryption algorithm for use in
an ESP SA, an identifying IANA number is needed. This number (the an ESP SA, an identifying IANA number is needed. This number (the
value 11 for ESP_NULL) is found on the IANA registries for both IKEv1 value 11 for ESP_NULL) is found on the IANA registries for both IKEv1
and IKEv2, but it is not mentioned in this RFC. and IKEv2, but it is not mentioned in [RFC2410].
Requirements levels for ESP-NULL: Requirements levels for ESP-NULL:
IKEv1 - N/A IKEv1 - N/A
IKEv2 - N/A IKEv2 - N/A
ESP-v2 - MUST [RFC4835] ESP-v2 - MUST [RFC4835]
ESP-v3 - MUST [RFC4835] ESP-v3 - MUST [RFC4835]
NOTE: RFC 4307 erroneously classifies ESP-NULL as MAY for IKEv2; this NOTE: RFC 4307 erroneously classifies ESP-NULL as MAY for IKEv2; this
has been corrected in an errata submission for RFC 4307. has been corrected in an errata submission for RFC 4307.
skipping to change at page 47, line 5 skipping to change at page 47, line 5
communicate from disparate address realms, by modifying IP and communicate from disparate address realms, by modifying IP and
transport headers en-route. This makes it difficult for applications transport headers en-route. This makes it difficult for applications
to pursue end-to-end application level security. [RFC2709] describes to pursue end-to-end application level security. [RFC2709] describes
a security model by which tunnel-mode IPsec security can be a security model by which tunnel-mode IPsec security can be
architected on NAT devices. It defines how NATs administer security architected on NAT devices. It defines how NATs administer security
policies and SA attributes based on private realm addressing. It policies and SA attributes based on private realm addressing. It
also specifies how to operate IKE in such scenarios by specifying an also specifies how to operate IKE in such scenarios by specifying an
IKE-ALG (Application Level Gateway) that translates policies from IKE-ALG (Application Level Gateway) that translates policies from
private realm addressing into public addressing. Although the model private realm addressing into public addressing. Although the model
presented here uses terminology from IKEv1, it can be deployed within presented here uses terminology from IKEv1, it can be deployed within
IKEv1, IKEv2, IPsec-v2 and IPsec-v3. IKEv1, IKEv2, IPsec-v2 and IPsec-v3. This security model has not
been widely adopted
8.9. Session Initiation Protocol (SIP) 8.9. Session Initiation Protocol (SIP)
8.9.1. RFC 3329, Security Mechanism Agreement for the Session 8.9.1. RFC 3329, Security Mechanism Agreement for the Session
Initiation Protocol (SIP) (S, Jan. 2003) Initiation Protocol (SIP) (S, Jan. 2003)
[RFC3329] describes how a SIP client can select one of the various [RFC3329] describes how a SIP client can select one of the various
available SIP security mechanisms. In particular, the method allows available SIP security mechanisms. In particular, the method allows
secure negotiation to prevent bidding down attacks. It also secure negotiation to prevent bidding down attacks. It also
describes a security mechanism called ipsec-3gpp and its associated describes a security mechanism called ipsec-3gpp and its associated
skipping to change at page 48, line 36 skipping to change at page 48, line 37
the algorithms that are used to provide confidentiality and integrity the algorithms that are used to provide confidentiality and integrity
protection of both subscriber and management traffic. It also protection of both subscriber and management traffic. It also
specifies a custom security protocol that runs between two Gigabeam specifies a custom security protocol that runs between two Gigabeam
Radio Control Modules (RCMs). Radio Control Modules (RCMs).
10. Acknowledgements 10. Acknowledgements
The authors would like to thank Yaron Sheffer, Paul Hoffman, Yoav The authors would like to thank Yaron Sheffer, Paul Hoffman, Yoav
Nir, Rajeshwar Singh Jenwar, Alfred Hoenes, Al Morton, Gabriel Nir, Rajeshwar Singh Jenwar, Alfred Hoenes, Al Morton, Gabriel
Montenegro, Sean Turner, Julien Laganier, Grey Daley, Scott Moonen, Montenegro, Sean Turner, Julien Laganier, Grey Daley, Scott Moonen,
Richard Graveman, Tero Kivinen, Pasi Eronen, and Ran Atkinson for Richard Graveman, Tero Kivinen, Pasi Eronen, Ran Atkinson, David
reviewing this document and suggesting changes. Black and Tim Polk for reviewing this document and suggesting
changes.
11. Security Considerations 11. Security Considerations
There are no security considerations relevant to this document. There are no security considerations relevant to this document.
12. IANA Considerations 12. 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.
 End of changes. 8 change blocks. 
8 lines changed or deleted 16 lines changed or added

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