< 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.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/