draft-ietf-ipsecme-rfc7321bis-04.txt		draft-ietf-ipsecme-rfc7321bis-05.txt
	Network Working Group D. Migault		Network Working Group D. Migault
	Internet-Draft J. Mattsson		Internet-Draft J. Mattsson
	Obsoletes: 7321 (if approved) Ericsson		Obsoletes: 7321 (if approved) Ericsson
	Intended status: Standards Track P. Wouters		Intended status: Standards Track P. Wouters
	Expires: August 19, 2017 Red Hat		Expires: August 31, 2017 Red Hat
	Y. Nir		Y. Nir
	Check Point		Check Point
	T. Kivinen		T. Kivinen
	INSIDE Secure		INSIDE Secure
	February 15, 2017		February 27, 2017
	Cryptographic Algorithm Implementation Requirements and Usage Guidance		Cryptographic Algorithm Implementation Requirements and Usage Guidance
	for Encapsulating Security Payload (ESP) and Authentication Header (AH)		for Encapsulating Security Payload (ESP) and Authentication Header (AH)
	draft-ietf-ipsecme-rfc7321bis-04		draft-ietf-ipsecme-rfc7321bis-05
	Abstract		Abstract
	This document updates the Cryptographic Algorithm Implementation		This document updates the Cryptographic Algorithm Implementation
	Requirements for ESP and AH. The goal of these document is to enable		Requirements for ESP and AH. The goal of these document is to enable
	ESP and AH to benefit from cryptography that is up to date while		ESP and AH to benefit from cryptography that is up to date while
	making IPsec interoperable.		making IPsec interoperable.
	This document obsoletes RFC 7321 on the cryptographic recommendations		This document obsoletes RFC 7321 on the cryptographic recommendations
	only.		only.
	skipping to change at page 1, line 43 ¶		skipping to change at page 1, line 43 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on August 19, 2017.		This Internet-Draft will expire on August 31, 2017.
	Copyright Notice		Copyright Notice
	Copyright (c) 2017 IETF Trust and the persons identified as the		Copyright (c) 2017 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 24 ¶		skipping to change at page 2, line 24 ¶
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	1.1. Updating Algorithm Implementation Requirements and Usage		1.1. Updating Algorithm Implementation Requirements and Usage
	Guidance . . . . . . . . . . . . . . . . . . . . . . . . 3		Guidance . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.2. Updating Algorithm Requirement Levels . . . . . . . . . . 3		1.2. Updating Algorithm Requirement Levels . . . . . . . . . . 3
	1.3. Document Audience . . . . . . . . . . . . . . . . . . . . 4		1.3. Document Audience . . . . . . . . . . . . . . . . . . . . 4
	2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4		2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4
	3. Manual Keying . . . . . . . . . . . . . . . . . . . . . . . . 5		3. Manual Keying . . . . . . . . . . . . . . . . . . . . . . . . 5
	4. ESP Encryption Algorithms . . . . . . . . . . . . . . . . . . 5		4. Encryption must be Authenticated . . . . . . . . . . . . . . 5
	5. ESP and AH Authentication Algorithms . . . . . . . . . . . . 7		5. ESP Encryption Algorithms . . . . . . . . . . . . . . . . . . 6
	6. ESP and AH Compression Algorithms . . . . . . . . . . . . . . 9		6. ESP and AH Authentication Algorithms . . . . . . . . . . . . 8
	7. Summary of Changes from RFC 7321 . . . . . . . . . . . . . . 9		7. ESP and AH Compression Algorithms . . . . . . . . . . . . . . 9
	8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10		8. Summary of Changes from RFC 7321 . . . . . . . . . . . . . . 10
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10		9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
	10. Security Considerations . . . . . . . . . . . . . . . . . . . 10		10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . 11		11. Security Considerations . . . . . . . . . . . . . . . . . . . 10
	11.1. Normative References . . . . . . . . . . . . . . . . . . 11		12. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
	11.2. Informative References . . . . . . . . . . . . . . . . . 11		12.1. Normative References . . . . . . . . . . . . . . . . . . 11
			12.2. Informative References . . . . . . . . . . . . . . . . . 11
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
	1. Introduction		1. Introduction
	The Encapsulating Security Payload (ESP) [RFC4303] and the		The Encapsulating Security Payload (ESP) [RFC4303] and the
	Authentication Header (AH) [RFC4302] are the mechanisms for applying		Authentication Header (AH) [RFC4302] are the mechanisms for applying
	cryptographic protection to data being sent over an IPsec Security		cryptographic protection to data being sent over an IPsec Security
	Association (SA) [RFC4301].		Association (SA) [RFC4301].
	This document provides guidance and recommendations so that ESP and		This document provides guidance and recommendations so that ESP and
	skipping to change at page 5, line 38 ¶		skipping to change at page 5, line 38 ¶
	Secrecy ("PFS") protection. Deployments tend to never be		Secrecy ("PFS") protection. Deployments tend to never be
	reconfigured with fresh session keys. It also fails to scale and		reconfigured with fresh session keys. It also fails to scale and
	keeping SPI's unique amongst many servers is impractical. This		keeping SPI's unique amongst many servers is impractical. This
	document was written for deploying ESP/AH using IKE ([RFC7296]) and		document was written for deploying ESP/AH using IKE ([RFC7296]) and
	assumes that keying happens using IKEv2.		assumes that keying happens using IKEv2.
	If manual keying is used anyway, ENCR_AES_CBC MUST be used, and		If manual keying is used anyway, ENCR_AES_CBC MUST be used, and
	ENCR_AES_CCM, ENCR_AES_GCM and ENCR_CHACHA20_POLY1305 MUST NOT be		ENCR_AES_CCM, ENCR_AES_GCM and ENCR_CHACHA20_POLY1305 MUST NOT be
	used as these algorithms require IKE.		used as these algorithms require IKE.
	4. ESP Encryption Algorithms		4. Encryption must be Authenticated
			Encryption without authentication is not effective and MUST NOT be
			used. IPsec offers three ways to provide both encryption and
			authentication:
			o ESP with an AEAD cipher
			o ESP with a non-AEAD cipher + authentication
			o ESP with a non-AEAD cipher + AH with authentication
			The fastest and most modern method is to use ESP with a combined mode
			cipher such as an AEAD cipher that handles encryption/decryption and
			authentication in a single step. In this case, the AEAD cipher is
			set as the encryption algorithm and the authentication algorithm is
			set to none. Examples of this are ENCR_AES_GCM_16 and
			ENCR_CHACHA20_POLY1305.
			A more traditional approach is to use ESP with an encryption and an
			authentication algorithm. This approach is slower, as the data has
			to be processed twice, once for encryption/decryption and once for
			authentication. An example of this is ENCR_AES_CBC combined with
			AUTH_HMAC_SHA2_512_256.
			The last method that can be used is ESP+AH. This method is NOT
			RECOMMENDED. It is the slowest method and also takes up more octets
			due to the double header of ESP+AH, resulting in a smaller effective
			MTU for the encrypted data. With this method, ESP is only used for
			confidentiality without an authentication algorithm and a second
			IPsec protocol of type AH is used for authentication. An example of
			this is ESP with ENCR_AES_CBC with AH with AUTH_HMAC_SHA2_512_256.
			5. ESP Encryption Algorithms
	+-------------------------+-------------+---------+--------------+		+-------------------------+-------------+---------+--------------+
	| Name | Status | AEAD | Comment |		| Name | Status | AEAD | Comment |
	+-------------------------+-------------+---------+--------------+		+-------------------------+-------------+---------+--------------+
	| ENCR_DES_IV64 | MUST NOT | No | UNSPECIFIED |		| ENCR_DES_IV64 | MUST NOT | No | UNSPECIFIED |
	| ENCR_DES | MUST NOT | No | [RFC2405] |		| ENCR_DES | MUST NOT | No | [RFC2405] |
	| ENCR_3DES | SHOULD NOT | No | [RFC2451] |		| ENCR_3DES | SHOULD NOT | No | [RFC2451] |
	| ENCR_BLOWFISH | MUST NOT | No | [RFC2451] |		| ENCR_BLOWFISH | MUST NOT | No | [RFC2451] |
	| ENCR_3IDEA | MUST NOT | No | UNSPECIFIED |		| ENCR_3IDEA | MUST NOT | No | UNSPECIFIED |
	| ENCR_DES_IV32 | MUST NOT | No | UNSPECIFIED |		| ENCR_DES_IV32 | MUST NOT | No | UNSPECIFIED |
	| ENCR_NULL | MUST | No | [RFC2410] |		| ENCR_NULL | MUST | No | [RFC2410] |
	skipping to change at page 7, line 40 ¶		skipping to change at page 8, line 10 ¶
	increased performance and key longevity compared to ENCR_AES_CBC.		increased performance and key longevity compared to ENCR_AES_CBC.
	ENCR_CHACHA20_POLY1305 was not ready to be considered at the time of		ENCR_CHACHA20_POLY1305 was not ready to be considered at the time of
	RFC7321. It has been recommended by the CRFG and others as an		RFC7321. It has been recommended by the CRFG and others as an
	alternative to AES-CBC and AES-GCM. It is also being standardized		alternative to AES-CBC and AES-GCM. It is also being standardized
	for ESP for the same reasons. At the time of writing, there are not		for ESP for the same reasons. At the time of writing, there are not
	enough ESP implementations of ENCR_CHACHA20_POLY1305 to be able to		enough ESP implementations of ENCR_CHACHA20_POLY1305 to be able to
	introduce it at the SHOULD+ level. Its status has been set to SHOULD		introduce it at the SHOULD+ level. Its status has been set to SHOULD
	and is expected to become MUST in the long term.		and is expected to become MUST in the long term.
	5. ESP and AH Authentication Algorithms		6. ESP and AH Authentication Algorithms
	Encryption without authentication MUST NOT be used. As a result,		Authentication algorithm recommendations in this section are
	authentication algorithm recommendations in this section are		targeting two types of communications:
	targeting two types of communications: Firstly authenticated only
	communications without encryption. Such communications can be ESP		o Authenticated only communications without encryption, such as ESP
	with NULL encryption or AH communications. Secondly, communications		with NULL encryption or AH communications.
	that are encrypted with non AEAD encryption algorithms mentioned		o Communications that are encrypted with non-AEAD algorithm which
	above. In this case, they MUST be combined with an authentication		MUST be combined with an authentication algorithm.
	algorithm.
	+------------------------+------------------+-----------------------+		+------------------------+------------------+-----------------------+
	| Name | Status | Comment |		| Name | Status | Comment |
	+------------------------+------------------+-----------------------+		+------------------------+------------------+-----------------------+
	| AUTH_NONE | MUST / MUST NOT | [RFC7296] AEAD |		| AUTH_NONE | MUST / MUST NOT | [RFC7296] AEAD |
	| AUTH_HMAC_MD5_96 | MUST NOT | [RFC2403][RFC7296] |		| AUTH_HMAC_MD5_96 | MUST NOT | [RFC2403][RFC7296] |
	| AUTH_HMAC_SHA1_96 | MUST- | [RFC2404][RFC7296] |		| AUTH_HMAC_SHA1_96 | MUST- | [RFC2404][RFC7296] |
	| AUTH_DES_MAC | MUST NOT | [UNSPECIFIED] |		| AUTH_DES_MAC | MUST NOT | [UNSPECIFIED] |
	| AUTH_KPDK_MD5 | MUST NOT | [UNSPECIFIED] |		| AUTH_KPDK_MD5 | MUST NOT | [UNSPECIFIED] |
	| AUTH_AES_XCBC_96 | SHOULD | [RFC3566][RFC7296] |		| AUTH_AES_XCBC_96 | SHOULD | [RFC3566][RFC7296] |
	skipping to change at page 8, line 25 ¶		skipping to change at page 8, line 40 ¶
	| AUTH_AES_128_GMAC | MAY | [RFC4543] |		| AUTH_AES_128_GMAC | MAY | [RFC4543] |
	| AUTH_AES_256_GMAC | MAY | [RFC4543] |		| AUTH_AES_256_GMAC | MAY | [RFC4543] |
	| AUTH_HMAC_SHA2_256_128 | MUST | [RFC4868] |		| AUTH_HMAC_SHA2_256_128 | MUST | [RFC4868] |
	| AUTH_HMAC_SHA2_512_256 | SHOULD | [RFC4868] |		| AUTH_HMAC_SHA2_512_256 | SHOULD | [RFC4868] |
	+------------------------+------------------+-----------------------+		+------------------------+------------------+-----------------------+
	(IoT) - This requirement is for interoperability with IoT		(IoT) - This requirement is for interoperability with IoT
	AUTH_NONE has been downgraded from MAY in RFC7321 to MUST NOT. The		AUTH_NONE has been downgraded from MAY in RFC7321 to MUST NOT. The
	only reason NULL is acceptable is when authenticated encryption		only reason NULL is acceptable is when authenticated encryption
	algorithms are selected from Section 4. In all other cases, NULL		algorithms are selected from Section 5. In all other cases, NULL
	MUST NOT be selected. As ESP and AH both provides authentication,		MUST NOT be selected. As ESP and AH both provide authentication, one
	one may be tempted to combine these protocols to provide		may be tempted to combine these protocols to provide authentication.
	authentication. As mentioned by RFC7321, it is NOT RECOMMENDED to		As mentioned by RFC7321, it is NOT RECOMMENDED to use ESP with NULL
	use ESP with NULL authentication - with non authenticated encryption		authentication - with non authenticated encryption - in conjunction
	- in conjunction with AH; some configurations of this combination of		with AH; some configurations of this combination of services have
	services have been shown to be insecure [PD10]. In addition, NULL		been shown to be insecure [PD10]. In addition, NULL authentication
	authentication cannot be combined with ESP NULL encryption.		cannot be combined with ESP NULL encryption.
	AUTH_HMAC_MD5_96 and AUTH_KPDK_MD5 were not mentioned in RFC7321. As		AUTH_HMAC_MD5_96 and AUTH_KPDK_MD5 were not mentioned in RFC7321. As
	MD5 is known to be vulnerable to collisions, these algorithms MUST		MD5 is known to be vulnerable to collisions, these algorithms MUST
	NOT be used.		NOT be used.
	AUTH_HMAC_SHA1_96 has been downgraded from MUST in RFC7321 to MUST-		AUTH_HMAC_SHA1_96 has been downgraded from MUST in RFC7321 to MUST-
	as there is an industry-wide trend to deprecate its usage.		as there is an industry-wide trend to deprecate its usage.
	AUTH_DES_MAC was not mentioned in RFC7321. As DES is known to be		AUTH_DES_MAC was not mentioned in RFC7321. As DES is known to be
	vulnerable, it MUST NOT be used.		vulnerable, it MUST NOT be used.
	skipping to change at page 9, line 21 ¶		skipping to change at page 9, line 37 ¶
	a long standing common implementation bug of this algorithm that		a long standing common implementation bug of this algorithm that
	truncates the hash at 96-bits instead of 128-bits, it is recommended		truncates the hash at 96-bits instead of 128-bits, it is recommended
	that implementations prefer AUTH_HMAC_SHA2_512_256 over		that implementations prefer AUTH_HMAC_SHA2_512_256 over
	AUTH_HMAC_SHA2_256_128 if they implement AUTH_HMAC_SHA2_512_256.		AUTH_HMAC_SHA2_256_128 if they implement AUTH_HMAC_SHA2_512_256.
	AUTH_HMAC_SHA2_512_256 SHOULD be implemented as a future replacement		AUTH_HMAC_SHA2_512_256 SHOULD be implemented as a future replacement
	of AUTH_HMAC_SHA2_256_128 or when stronger security is required.		of AUTH_HMAC_SHA2_256_128 or when stronger security is required.
	This value has been preferred to AUTH_HMAC_SHA2_384, as the		This value has been preferred to AUTH_HMAC_SHA2_384, as the
	additional overhead of AUTH_HMAC_SHA2_512 is negligible.		additional overhead of AUTH_HMAC_SHA2_512 is negligible.
	6. ESP and AH Compression Algorithms		7. ESP and AH Compression Algorithms
	+----------------+----------+-------------+		+----------------+----------+-------------+
	| Name | Status | Comment |		| Name | Status | Comment |
	+----------------+----------+-------------+		+----------------+----------+-------------+
	| IPCOMP_OUI | MUST NOT | UNSPECIFIED |		| IPCOMP_OUI | MUST NOT | UNSPECIFIED |
	| IPCOMP_DEFLATE | MAY | [RFC2393] |		| IPCOMP_DEFLATE | MAY | [RFC2393] |
	| IPCOMP_LZS | MAY | [RFC2395] |		| IPCOMP_LZS | MAY | [RFC2395] |
	| IPCOMP_LZJH | MAY | [RFC3051] |		| IPCOMP_LZJH | MAY | [RFC3051] |
	+----------------+----------+-------------+		+----------------+----------+-------------+
	(IoT) - This requirement is for interoperability with IoT		(IoT) - This requirement is for interoperability with IoT
	Compression was not mentioned in RFC7321. As it is not widely		Compression was not mentioned in RFC7321. As it is not widely
	deployed, it remains optional and at the MAY-level.		deployed, it remains optional and at the MAY-level.
	7. Summary of Changes from RFC 7321		8. Summary of Changes from RFC 7321
	The following table summarizes the changes from RFC 7321.		The following table summarizes the changes from RFC 7321.
	RFC EDITOR: PLEASE REMOVE THIS PARAGRAPH AND REPLACE XXXX IN THE		RFC EDITOR: PLEASE REMOVE THIS PARAGRAPH AND REPLACE XXXX IN THE
	TABLE BELOW WITH THE NUMBER OF THIS RFC		TABLE BELOW WITH THE NUMBER OF THIS RFC
	+-------------------+----------+-----------------+		+-------------------+----------+-----------------+
	| Algorithm | RFC 7321 | RFC XXXX |		| Algorithm | RFC 7321 | RFC XXXX |
	+-------------------+----------+-----------------+		+-------------------+----------+-----------------+
	| ENCR_AES_GCM_16 | SHOULD+ | MUST |		| ENCR_AES_GCM_16 | SHOULD+ | MUST |
	| ENCR_AES_CCM_8 | MAY | SHOULD |		| ENCR_AES_CCM_8 | MAY | SHOULD |
	| ENCR_AES_CTR | MAY | (*) |		| ENCR_AES_CTR | MAY | (*) |
	| ENCR_3DES | MAY | SHOULD NOT |		| ENCR_3DES | MAY | SHOULD NOT |
	| AUTH_HMAC_SHA1_96 | MUST | MUST- |		| AUTH_HMAC_SHA1_96 | MUST | MUST- |
	| AUTH_AES_128_GMAC | SHOULD+ | MAY |		| AUTH_AES_128_GMAC | SHOULD+ | MAY |
	| AUTH_NONE | MAY | MUST / MUST NOT |		| AUTH_NONE | MAY | MUST / MUST NOT |
	skipping to change at page 10, line 19 ¶		skipping to change at page 10, line 27 ¶
	| ENCR_AES_CTR | MAY | (*) |		| ENCR_AES_CTR | MAY | (*) |
	| ENCR_3DES | MAY | SHOULD NOT |		| ENCR_3DES | MAY | SHOULD NOT |
	| AUTH_HMAC_SHA1_96 | MUST | MUST- |		| AUTH_HMAC_SHA1_96 | MUST | MUST- |
	| AUTH_AES_128_GMAC | SHOULD+ | MAY |		| AUTH_AES_128_GMAC | SHOULD+ | MAY |
	| AUTH_NONE | MAY | MUST / MUST NOT |		| AUTH_NONE | MAY | MUST / MUST NOT |
	+-------------------+----------+-----------------+		+-------------------+----------+-----------------+
	(*) This algorithm is not mentioned in the above sections, so it		(*) This algorithm is not mentioned in the above sections, so it
	defaults to MAY.		defaults to MAY.
	8. Acknowledgements		9. Acknowledgements
	Some of the wording in this document was adapted from [RFC7321], the		Some of the wording in this document was adapted from [RFC7321], the
	document that this one obsoletes, which was written by D. McGrew and		document that this one obsoletes, which was written by D. McGrew and
	P. Hoffman.		P. Hoffman.
	9. IANA Considerations		10. IANA Considerations
	This document has no IANA actions.		This document has no IANA actions.
	10. Security Considerations		11. Security Considerations
	The security of a system that uses cryptography depends on both the		The security of a system that uses cryptography depends on both the
	strength of the cryptographic algorithms chosen and the strength of		strength of the cryptographic algorithms chosen and the strength of
	the keys used with those algorithms. The security also depends on		the keys used with those algorithms. The security also depends on
	the engineering and administration of the protocol used by the system		the engineering and administration of the protocol used by the system
	to ensure that there are no non-cryptographic ways to bypass the		to ensure that there are no non-cryptographic ways to bypass the
	security of the overall system.		security of the overall system.
	This document concerns itself with the selection of cryptographic		This document concerns itself with the selection of cryptographic
	algorithms for the use of ESP and AH, specifically with the selection		algorithms for the use of ESP and AH, specifically with the selection
	skipping to change at page 10, line 45 ¶		skipping to change at page 11, line 4 ¶
	to ensure that there are no non-cryptographic ways to bypass the		to ensure that there are no non-cryptographic ways to bypass the
	security of the overall system.		security of the overall system.
	This document concerns itself with the selection of cryptographic		This document concerns itself with the selection of cryptographic
	algorithms for the use of ESP and AH, specifically with the selection		algorithms for the use of ESP and AH, specifically with the selection
	of mandatory-to-implement algorithms. The algorithms identified in		of mandatory-to-implement algorithms. The algorithms identified in
	this document as "MUST implement" or "SHOULD implement" are not known		this document as "MUST implement" or "SHOULD implement" are not known
	to be broken at the current time, and cryptographic research to date		to be broken at the current time, and cryptographic research to date
	leads us to believe that they will likely remain secure into the		leads us to believe that they will likely remain secure into the
	foreseeable future. However, this is not necessarily forever.		foreseeable future. However, this is not necessarily forever.
	Therefore, we expect that revisions of that document will be issued		Therefore, we expect that revisions of that document will be issued
	from time to time to reflect the current best practice in this area.		from time to time to reflect the current best practice in this area.
	11. References		12. References
	11.1. Normative References		12.1. Normative 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,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<http://www.rfc-editor.org/info/rfc2119>.		<http://www.rfc-editor.org/info/rfc2119>.
	[RFC4301] Kent, S. and K. Seo, "Security Architecture for the		[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
	Internet Protocol", RFC 4301, DOI 10.17487/RFC4301,		Internet Protocol", RFC 4301, DOI 10.17487/RFC4301,
	December 2005, <http://www.rfc-editor.org/info/rfc4301>.		December 2005, <http://www.rfc-editor.org/info/rfc4301>.
	skipping to change at page 11, line 32 ¶		skipping to change at page 11, line 35 ¶
	[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",		[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
	RFC 4303, DOI 10.17487/RFC4303, December 2005,		RFC 4303, DOI 10.17487/RFC4303, December 2005,
	<http://www.rfc-editor.org/info/rfc4303>.		<http://www.rfc-editor.org/info/rfc4303>.
	[RFC7321] McGrew, D. and P. Hoffman, "Cryptographic Algorithm		[RFC7321] McGrew, D. and P. Hoffman, "Cryptographic Algorithm
	Implementation Requirements and Usage Guidance for		Implementation Requirements and Usage Guidance for
	Encapsulating Security Payload (ESP) and Authentication		Encapsulating Security Payload (ESP) and Authentication
	Header (AH)", RFC 7321, DOI 10.17487/RFC7321, August 2014,		Header (AH)", RFC 7321, DOI 10.17487/RFC7321, August 2014,
	<http://www.rfc-editor.org/info/rfc7321>.		<http://www.rfc-editor.org/info/rfc7321>.
	11.2. Informative References		12.2. Informative References
	[PD10] Paterson, K. and J. Degabriele, "On the (in)security of		[PD10] Paterson, K. and J. Degabriele, "On the (in)security of
	IPsec in MAC-then-encrypt configurations (ACM Conference		IPsec in MAC-then-encrypt configurations (ACM Conference
	on Computer and Communications Security, ACM CCS)", 2010.		on Computer and Communications Security, ACM CCS)", 2010.
	[RFC2393] Shacham, A., Monsour, R., Pereira, R., and M. Thomas, "IP		[RFC2393] Shacham, A., Monsour, R., Pereira, R., and M. Thomas, "IP
	Payload Compression Protocol (IPComp)", RFC 2393,		Payload Compression Protocol (IPComp)", RFC 2393,
	DOI 10.17487/RFC2393, December 1998,		DOI 10.17487/RFC2393, December 1998,
	<http://www.rfc-editor.org/info/rfc2393>.		<http://www.rfc-editor.org/info/rfc2393>.
	skipping to change at page 13, line 5 ¶		skipping to change at page 13, line 5 ¶
	[RFC4309] Housley, R., "Using Advanced Encryption Standard (AES) CCM		[RFC4309] Housley, R., "Using Advanced Encryption Standard (AES) CCM
	Mode with IPsec Encapsulating Security Payload (ESP)",		Mode with IPsec Encapsulating Security Payload (ESP)",
	RFC 4309, DOI 10.17487/RFC4309, December 2005,		RFC 4309, DOI 10.17487/RFC4309, December 2005,
	<http://www.rfc-editor.org/info/rfc4309>.		<http://www.rfc-editor.org/info/rfc4309>.
	[RFC4543] McGrew, D. and J. Viega, "The Use of Galois Message		[RFC4543] McGrew, D. and J. Viega, "The Use of Galois Message
	Authentication Code (GMAC) in IPsec ESP and AH", RFC 4543,		Authentication Code (GMAC) in IPsec ESP and AH", RFC 4543,
	DOI 10.17487/RFC4543, May 2006,		DOI 10.17487/RFC4543, May 2006,
	<http://www.rfc-editor.org/info/rfc4543>.		<http://www.rfc-editor.org/info/rfc4543>.
	[RFC4835] Manral, V., "Cryptographic Algorithm Implementation
	Requirements for Encapsulating Security Payload (ESP) and
	Authentication Header (AH)", RFC 4835,
	DOI 10.17487/RFC4835, April 2007,
	<http://www.rfc-editor.org/info/rfc4835>.
	[RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA-		[RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA-
	384, and HMAC-SHA-512 with IPsec", RFC 4868,		384, and HMAC-SHA-512 with IPsec", RFC 4868,
	DOI 10.17487/RFC4868, May 2007,		DOI 10.17487/RFC4868, May 2007,
	<http://www.rfc-editor.org/info/rfc4868>.		<http://www.rfc-editor.org/info/rfc4868>.
	[RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.		[RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.
	Kivinen, "Internet Key Exchange Protocol Version 2		Kivinen, "Internet Key Exchange Protocol Version 2
	(IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October		(IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October
	2014, <http://www.rfc-editor.org/info/rfc7296>.		2014, <http://www.rfc-editor.org/info/rfc7296>.
End of changes. 20 change blocks.
	46 lines changed or deleted		74 lines changed or added
This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/