draft-ietf-ipsecme-rfc7321bis-06.txt		rfc8221.txt
	Network Working Group P. Wouters		Internet Engineering Task Force (IETF) P. Wouters
	Internet-Draft Red Hat		Request for Comments: 8221 Red Hat
	Obsoletes: 7321 (if approved) D. Migault		Obsoletes: 7321 D. Migault
	Intended status: Standards Track J. Mattsson		Category: Standards Track J. Mattsson
	Expires: December 21, 2017 Ericsson		ISSN: 2070-1721 Ericsson
	Y. Nir		Y. Nir
	Check Point		Check Point
	T. Kivinen		T. Kivinen
	INSIDE Secure		October 2017
	June 19, 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-06
	Abstract		Abstract
	This document updates the Cryptographic Algorithm Implementation		This document replaces RFC 7321, "Cryptographic Algorithm
	Requirements for ESP and AH. The goal of these document is to enable		Implementation Requirements and Usage Guidance for Encapsulating
	ESP and AH to benefit from cryptography that is up to date while		Security Payload (ESP) and Authentication Header (AH)". The goal of
	making IPsec interoperable.		this document is to enable ESP and AH to benefit from cryptography
			that is up to date while making IPsec interoperable.
	This document obsoletes RFC 7321.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This is an Internet Standards Track document.
	provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		This document is a product of the Internet Engineering Task Force
	and may be updated, replaced, or obsoleted by other documents at any		(IETF). It represents the consensus of the IETF community. It has
	time. It is inappropriate to use Internet-Drafts as reference		received public review and has been approved for publication by the
	material or to cite them other than as "work in progress."		Internet Engineering Steering Group (IESG). Further information on
			Internet Standards is available in Section 2 of RFC 7841.
	This Internet-Draft will expire on December 21, 2017.		Information about the current status of this document, any errata,
			and how to provide feedback on it may be obtained at
			https://www.rfc-editor.org/info/rfc8221.
	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		(https://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
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	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 . . . . . . . . . . . . . . . . . . . . 5
	3. Manual Keying . . . . . . . . . . . . . . . . . . . . . . . . 5		3. Manual Keying . . . . . . . . . . . . . . . . . . . . . . . . 5
	4. Encryption must be Authenticated . . . . . . . . . . . . . . 5		4. Encryption Must Be Authenticated . . . . . . . . . . . . . . 6
	5. ESP Encryption Algorithms . . . . . . . . . . . . . . . . . . 6		5. ESP Encryption Algorithms . . . . . . . . . . . . . . . . . . 7
	6. ESP and AH Authentication Algorithms . . . . . . . . . . . . 8		6. ESP and AH Authentication Algorithms . . . . . . . . . . . . 9
	7. ESP and AH Compression Algorithms . . . . . . . . . . . . . . 9		7. ESP and AH Compression Algorithms . . . . . . . . . . . . . . 10
	8. Summary of Changes from RFC 7321 . . . . . . . . . . . . . . 10		8. Summary of Changes from RFC 7321 . . . . . . . . . . . . . . 11
	9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
	10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10		10. Security Considerations . . . . . . . . . . . . . . . . . . . 11
	11. Security Considerations . . . . . . . . . . . . . . . . . . . 10		11. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
	12. References . . . . . . . . . . . . . . . . . . . . . . . . . 11		11.1. Normative References . . . . . . . . . . . . . . . . . . 12
	12.1. Normative References . . . . . . . . . . . . . . . . . . 11		11.2. Informative References . . . . . . . . . . . . . . . . . 12
	12.2. Informative References . . . . . . . . . . . . . . . . . 11		Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 15
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
	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
	AH can be used with a cryptographic algorithms that are up to date.		AH can be used with cryptographic algorithms that are up to date.
	The challenge of such document is to make sure that over the time		The challenge of such documents is making sure that, over time, IPsec
	IPsec implementations can use secure and up-to-date cryptographic		implementations can use secure and up-to-date cryptographic
	algorithms while keeping IPsec interoperable.		algorithms while keeping IPsec interoperable.
	1.1. Updating Algorithm Implementation Requirements and Usage Guidance		1.1. Updating Algorithm Implementation Requirements and Usage Guidance
	The field of cryptography evolves continuously. New stronger		The field of cryptography evolves continuously: new, stronger
	algorithms appear and existing algorithms are found to be less secure		algorithms appear, and existing algorithms are found to be less
	than originally thought. Therefore, algorithm implementation		secure than originally thought. Therefore, algorithm implementation
	requirements and usage guidance need to be updated from time to time		requirements and usage guidance need to be updated from time to time
	to reflect the new reality. The choices for algorithms must be		to reflect the new reality. The choices for algorithms must be
	conservative to minimize the risk of algorithm compromise.		conservative to minimize the risk of algorithm compromise.
	Algorithms need to be suitable for a wide variety of CPU		Algorithms need to be suitable for a wide variety of CPU
	architectures and device deployments ranging from high end bulk		architectures and device deployments ranging from high-end bulk
	encryption devices to small low-power IoT devices.		encryption devices to small, low-power Internet of Things (IoT)
			devices.
	The algorithm implementation requirements and usage guidance may need		The algorithm implementation requirements and usage guidance may need
	to change over time to adapt to the changing world. For this reason,		to change over time to adapt to the changing world. For this reason,
	the selection of mandatory-to-implement algorithms was removed from		the selection of mandatory-to-implement algorithms was removed from
	the main IKEv2 specification and placed in a separate document.		the main Internet Key Exchange Protocol Version 2 (IKEv2)
			specification [RFC7296] and placed in a separate document.
	1.2. Updating Algorithm Requirement Levels		1.2. Updating Algorithm Requirement Levels
	The mandatory-to-implement algorithm of tomorrow should already be		The mandatory-to-implement algorithm of tomorrow should already be
	available in most implementations of AH/ESP by the time it is made		available in most implementations of AH/ESP by the time it is made
	mandatory. This document attempts to identify and introduce those		mandatory. This document attempts to identify and introduce those
	algorithms for future mandatory-to-implement status. There is no		algorithms for future mandatory-to-implement status. There is no
	guarantee that the algorithms in use today may become mandatory in		guarantee that the algorithms in use today may become mandatory in
	the future. Published algorithms are continuously subjected to		the future. Published algorithms are continuously subjected to
	cryptographic attack and may become too weak or could become		cryptographic attack and may become too weak or could become
	completely broken before this document is updated.		completely broken before this document is updated.
	This document only provides recommendations for the mandatory-to-		This document only provides recommendations for the mandatory-to-
	implement algorithms and algorithms too weak that are recommended not		implement algorithms and "too weak" algorithms that are recommended
	to be implemented. As a result, any algorithm listed at the IPsec		not to be implemented. As a result, any algorithm listed at the
	IANA registry not mentioned in this document MAY be implemented. It		IPsec IANA registry that is not mentioned in this document MAY be
	is expected that this document will be updated over time and next		implemented. It is expected that this document will be updated over
	versions will only mention algorithms which status has evolved. For		time and future versions will only mention algorithms that have
	clarification when an algorithm has been mentioned in [RFC7321], this		evolved in status. For clarification, when an algorithm has been
	document states explicitly the update of the status.		mentioned in [RFC7321], this document states explicitly the update of
			the status.
	Although this document updates the algorithms to keep the AH/ESP		Although this document updates the algorithms to keep the AH/ESP
	communication secure over time, it also aims at providing		communication secure over time, it also aims at providing
	recommendations so that AH/ESP implementations remain interoperable.		recommendations so that AH/ESP implementations remain interoperable.
	AH/ESP interoperability is addressed by an incremental introduction		AH/ESP interoperability is addressed by an incremental introduction
	or deprecation of algorithms. In addition, this document also		or deprecation of algorithms. In addition, this document also
	considers the new use cases for AH/ESP deployment, such as Internet		considers the new use cases for AH/ESP deployment, such as IoT.
	of Things (IoT).
	It is expected that deprecation of an algorithm is performed		It is expected that deprecation of an algorithm be performed
	gradually. This provides time for various implementations to update		gradually. This provides time for various implementations to update
	their implemented algorithms while remaining interoperable. Unless		their implemented algorithms while remaining interoperable. Unless
	there are strong security reasons, an algorithm is expected to be		there are strong security reasons, an algorithm is expected to be
	downgraded from MUST to MUST- or SHOULD, instead of MUST NOT.		downgraded from MUST to MUST- or SHOULD, instead of MUST NOT (see
	Similarly, an algorithm that has not been mentioned as mandatory-to-		Section 2). Similarly, an algorithm that has not been mentioned as
	implement is expected to be introduced with a SHOULD instead of a		mandatory-to-implement is expected to be introduced with a SHOULD
	MUST.		instead of a MUST.
	The current trend toward Internet of Things and its adoption of AH/		The current trend toward IoT and its adoption of AH/ESP requires this
	ESP requires this specific use case to be taken into account as well.		specific use case to be taken into account as well. IoT devices are
	IoT devices are resource constrained devices and their choice of		resource-constrained devices, and their choice of algorithms is
	algorithms are motivated by minimizing the footprint of the code, the		motivated by minimizing the footprint of the code, the computation
	computation effort and the size of the messages to send. This		effort, and the size of the messages to send. This document
	document indicates "(IoT)" when a specified algorithm is specifically		indicates "(IoT)" when a specified algorithm is specifically listed
	listed for IoT devices. Requirement levels that are marked as "IoT"		for IoT devices. Requirement levels that are marked as "IoT" apply
	apply to IoT devices and to server-side implementations that might		to IoT devices and to server-side implementations that might
	presumably need to interoperate with them, including any general-		presumably need to interoperate with them, including any general-
	purpose VPN gateways.		purpose VPN gateways.
	1.3. Document Audience		1.3. Document Audience
	The recommendations of this document mostly target AH/ESP		The recommendations of this document mostly target AH/ESP
	implementers as implementations need to meet both high security		implementers as implementations need to meet both high security
	expectations as well as high interoperability between various vendors		expectations as well as high interoperability between various vendors
	and with different versions. Interoperability requires a smooth move		and with different versions. Interoperability requires a smooth move
	to more secure cipher suites. This may differ from a user point of		to more secure cipher suites. This may differ from a user point of
	view that may deploy and configure AH/ESP with only the safest cipher		view that may deploy and configure AH/ESP with only the safest cipher
	suite.		suite.
	This document does not give any recommendations for the use of		This document does not give any recommendations for the use of
	algorithms, it only gives implementation recommendations for		algorithms, it only gives recommendations for implementations. The
	implementations. The use of algorithms by users is dictated by the		use of algorithms by a specific user is dictated by their own
	security policy requirements for that specific user, and are outside		security policy requirements, which are outside the scope of this
	the scope of this document.		document.
	The algorithms considered here are listed by the IANA as part of the		The algorithms considered here are listed by IANA as part of the
	IKEv2 parameters. IKEv1 is out of scope of this document. IKEv1 is		IKEv2 parameters. IKEv1 is out of scope of this document. IKEv1 is
	deprecated and the recommendations of this document must not be		deprecated; the recommendations of this document must not be
	considered for IKEv1, nor IKEv1 parameters be considered by this		considered for IKEv1, nor may IKEv1 parameters be considered by this
	document.		document.
	The IANA registry for Internet Key Exchange Version 2 (IKEv2)		The IANA registry for "Internet Key Exchange Version 2 (IKEv2)
	Parameters contains some entries that are not for use with ESP or AH.		Parameters" contains some entries that are not for use with ESP or
	This document does not modify the status of those algorithms.		AH. This document does not modify the status of those algorithms.
	2. Requirements Language		2. Requirements Language
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in		"OPTIONAL" in this document are to be interpreted as described in
	[RFC2119].		BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
			capitals, as shown here.
	We define some additional terms here:		We define some additional terms here:
	SHOULD+ This term means the same as SHOULD. However, it is likely		SHOULD+ This term means the same as SHOULD. However, it is likely
	that an algorithm marked as SHOULD+ will be promoted at		that an algorithm marked as SHOULD+ will be promoted at
	some future time to be a MUST.		some future time to be a MUST.
	SHOULD- This term means the same as SHOULD. However, an algorithm		SHOULD- This term means the same as SHOULD. However, an algorithm
	marked as SHOULD- may be deprecated to a MAY in a future		marked as SHOULD- may be deprecated to a MAY in a future
	version of this document.		version of this document.
	MUST- This term means the same as MUST. However, we expect at		MUST- This term means the same as MUST. However, we expect at
	some point that this algorithm will no longer be a MUST in		some point that this algorithm will no longer be a MUST in
	a future document. Although its status will be determined		a future document. Although its status will be determined
	at a later time, it is reasonable to expect that if a		at a later time, it is reasonable to expect that if a
	future revision of a document alters the status of a MUST-		future revision of a document alters the status of a MUST-
	algorithm, it will remain at least a SHOULD or a SHOULD-		algorithm, it will remain at least a SHOULD or a SHOULD-
	level.		level.
	IoT stands for Internet of Things.		IoT The Internet of Things.
	3. Manual Keying		3. Manual Keying
	Manual Keying SHOULD NOT be used as it is inherently dangerous.		Manual keying SHOULD NOT be used, as it is inherently dangerous.
	Without any secure keying protocol such a IKE, IPsec does not offer		Without any secure keying protocol, such as IKE, IPsec does not offer
	Perfect Forward Secrecy ("PFS") protection and there is no entity to		Perfect Forward Secrecy (PFS) protection; there is no entity to
	ensure refreshing of session keys, tracking SPI uniqueness and		ensure the refreshing of session keys, the tracking of Security
	ensuring nonces, IVs and counters are never re-used. This document		Parameter Index (SPI) uniqueness, and the single use of nonces,
	was written for deploying ESP/AH using IKE ([RFC7296]) and assumes		Initialization Vectors (IVs), and counters. This document was
	that keying happens using IKE version 2 or higher.		written for deploying ESP/AH using IKE [RFC7296] and assumes that
			keying happens using IKEv2 or higher.
	If Manual Keying is used regardless, Counter Mode algorithms such as		If manual keying is used regardless, Counter Mode algorithms such as
	ENCR_AES_CTR, ENCR_AES_CCM, ENCR_AES_GCM and ENCR_CHACHA20_POLY1305		ENCR_AES_CTR, ENCR_AES_CCM, ENCR_AES_GCM, and ENCR_CHACHA20_POLY1305
	MUST NOT be used as it is incompatible with a secure and persistent		MUST NOT be used, as it is incompatible with a secure and persistent
	handling of the counter, as explained in the Security Considerations		handling of the counter (as explained in the Security Considerations
	Section of [RFC3686]. This particularly applies to IoT devices that		section of [RFC3686]). This particularly applies to IoT devices that
	have no state across reboots. As of publication date of this		have no state across reboots. At the time of writing, ENCR_AES_CBC
	document, ENCR_AES_CBC is the only Mandatory-To-Implement encryption		is the only mandatory-to-implement encryption algorithm suitable for
	algorithm suitable for Manual Keying.		manual keying.
	4. Encryption must be Authenticated		4. Encryption Must Be Authenticated
	Encryption without authentication is not effective and MUST NOT be		Encryption without authentication is not effective and MUST NOT be
	used. IPsec offers three ways to provide both encryption and		used. IPsec offers three ways to provide both encryption and
	authentication:		authentication:
	o ESP with an AEAD cipher		o ESP with an Authenticated Encryption with Associated Data (AEAD)
			cipher
	o ESP with a non-AEAD cipher + authentication		o ESP with a non-AEAD cipher + authentication
	o ESP with a non-AEAD cipher + AH with 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		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		cipher, such as an AEAD cipher, that handles encryption/decryption
	authentication in a single step. In this case, the AEAD cipher is		and authentication in a single step. In this case, the AEAD cipher
	set as the encryption algorithm and the authentication algorithm is		is set as the encryption algorithm, and the authentication algorithm
	set to none. Examples of this are ENCR_AES_GCM_16 and		is set to none. Examples of this are ENCR_AES_GCM_16 and
	ENCR_CHACHA20_POLY1305.		ENCR_CHACHA20_POLY1305.
	A more traditional approach is to use ESP with an encryption and an		A more traditional approach is to use ESP with an encryption and an
	authentication algorithm. This approach is slower, as the data has		authentication algorithm. This approach is slower, as the data has
	to be processed twice, once for encryption/decryption and once for		to be processed twice: once for encryption/decryption and once for
	authentication. An example of this is ENCR_AES_CBC combined with		authentication. An example of this is ENCR_AES_CBC combined with
	AUTH_HMAC_SHA2_512_256.		AUTH_HMAC_SHA2_512_256.
	The last method that can be used is ESP+AH. This method is NOT		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		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		due to the double header of ESP+AH. This results in a smaller
	MTU for the encrypted data. With this method, ESP is only used for		effective MTU for the encrypted data. With this method, ESP is only
	confidentiality without an authentication algorithm and a second		used for confidentiality without an authentication algorithm, and a
	IPsec protocol of type AH is used for authentication. An example of		second IPsec protocol of type AH is used for authentication. An
	this is ESP with ENCR_AES_CBC with AH with AUTH_HMAC_SHA2_512_256.		example of this is ESP with ENCR_AES_CBC with AH with
			AUTH_HMAC_SHA2_512_256.
	5. ESP Encryption Algorithms		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] |
	| ENCR_AES_CBC | MUST | No | [RFC3602][1] |		| ENCR_AES_CBC | MUST | No | [RFC3602][1] |
	| ENCR_AES_CCM_8 | SHOULD(IoT) | Yes | [RFC4309] |		| ENCR_AES_CCM_8 | SHOULD | Yes | [RFC4309](IoT) |
	| ENCR_AES_GCM_16 | MUST | Yes | [RFC4106][1] |		| ENCR_AES_GCM_16 | MUST | Yes | [RFC4106][1] |
	| ENCR_CHACHA20_POLY1305 | SHOULD | Yes | [RFC7634] |		| ENCR_CHACHA20_POLY1305 | SHOULD | Yes | [RFC7634] |
	+-------------------------+-------------+---------+--------------+		+-------------------------+------------+---------+----------------+
	[1] - This requirement level is for 128-bit and 256-bit keys.		[1] - This requirement level is for 128-bit and 256-bit keys. 192-bit
	192-bit keys remain at MAY level. (IoT) - This requirement is for		keys remain at the MAY level.
	interoperability with IoT. Only 128-bit keys are at the given level.
	IPsec sessions may have very long life time, and carry multiple		(IoT) - This requirement is for interoperability with IoT. Only
			128-bit keys are at the given level.
			IPsec sessions may have very long lifetime and carry multiple
	packets, so there is a need to move to 256-bit keys in the long term.		packets, so there is a need to move to 256-bit keys in the long term.
	For that purpose the requirement level for 128 bit keys and 256 bit		For that purpose, the requirement level for 128-bit keys and 256-bit
	keys are at MUST (when applicable). In that sense 256 bit keys		keys is MUST (when applicable). In that sense, the status for
	status has been raised from MAY in RFC7321 to MUST.		256-bit keys has been raised from MAY in [RFC7321] to MUST.
	IANA has allocated codes for cryptographic algorithms that have not		IANA has allocated codes for cryptographic algorithms that have not
	been specified by the IETF. Such algorithms are noted as		been specified by the IETF. Such algorithms are noted as
	UNSPECIFIED. Usually, the use of theses algorithms is limited to		UNSPECIFIED. Usually, the use of these algorithms is limited to
	specific cases, and the absence of specification makes		specific cases, and the absence of specification makes
	interoperability difficult for IPsec communications. These		interoperability difficult for IPsec communications. These
	algorithms were not been mentioned in [RFC7321] and this document		algorithms were not mentioned in [RFC7321], and this document
	clarify that such algorithms MUST NOT be implemented for IPsec		clarifies that such algorithms MUST NOT be implemented for IPsec
	communications.		communications.
	Similarly IANA also allocated code points for algorithms that are not		Similarly, IANA also allocated code points for algorithms that are
	expected to be used to secure IPsec communications. Such algorithms		not expected to be used to secure IPsec communications. Such
	are noted as Non IPsec. As a result, these algorithms MUST NOT be		algorithms are noted as non-IPsec. As a result, these algorithms
	implemented.		MUST NOT be implemented.
	Various older and not well tested and never widely implemented		Various ciphers that are older, not well tested, and never widely
	ciphers have been changed to MUST NOT.		implemented have been changed to MUST NOT.
	ENCR_3DES status has been downgraded from MAY in RFC7321 to SHOULD		ENCR_3DES status has been downgraded from MAY in [RFC7321] to SHOULD
	NOT. ENCR_CHACHA20_POLY1305 is a more modern approach alternative		NOT. ENCR_CHACHA20_POLY1305 is a more modern approach and
	for ENCR_3DES than ENCR_AES_CBC and so it expected to be favored to		alternative for ENCR_3DES than ENCR_AES_CBC, and so it is expected to
	replace ENCR_3DES.		be favored to replace ENCR_3DES.
	ENCR_BLOWFISH has been downgraded to MUST NOT as it has been		ENCR_BLOWFISH has been downgraded to MUST NOT as it has been
	deprecated for years by TWOFISH, which is not standarized for ESP and		deprecated for years by TWOFISH, which is not standardized for ESP
	therefore not listed in this document. Some implementations support		and therefore not listed in this document. Some implementations
	TWOFISH using a private range number.		support TWOFISH using a private range number.
	ENCR_NULL status was set to MUST in [RFC7321] and remains a MUST to		ENCR_NULL status was set to MUST in [RFC7321] and remains a MUST to
	enable the use of ESP with only authentication which is preferred		enable the use of ESP with only authentication, which is preferred
	over AH due to NAT traversal. ENCR_NULL is expected to remain MUST		over AH due to NAT traversal. ENCR_NULL is expected to remain MUST
	by protocol requirements.		by protocol requirements.
	ENCR_AES_CBC status remains at MUST. ENCR_AES_CBC MUST be		ENCR_AES_CBC status remains at MUST. ENCR_AES_CBC MUST be
	implemented in order to enable interoperability between		implemented in order to enable interoperability between
	implementations that followed RFC7321. However, there is a trend for		implementations that followed [RFC7321]. However, there is a trend
	the industry to move to AEAD encryption, and the overhead of		for the industry to move to AEAD encryption, and the overhead of
	ENCR_AES_CBC remains quite large so it is expected to be replaced by		ENCR_AES_CBC remains quite large, so it is expected to be replaced by
	AEAD algorithms in the long term.		AEAD algorithms in the long term.
	ENCR_AES_CCM_8 status was set to MAY in [RFC7321] and has been raised		ENCR_AES_CCM_8 status was set to MAY in [RFC7321] and has been raised
	from MAY to SHOULD in order to interact with Internet of Things		from MAY to SHOULD in order to interact with IoT devices. As this
	devices. As this case is not a general use case for VPNs, its status		case is not a general use case for VPNs, its status is expected to
	is expected to remain as SHOULD.		remain as SHOULD.
	ENCR_AES_GCM_16 status has been updated from SHOULD+ to MUST in order		ENCR_AES_GCM_16 status has been updated from SHOULD+ to MUST in order
	to favor the use of authenticated encryption and AEAD algorithms.		to favor the use of authenticated encryption and AEAD algorithms.
	ENCR_AES_GCM_16 has been widely implemented for ESP due to its		ENCR_AES_GCM_16 has been widely implemented for ESP due to its
	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 Crypto Forum Research
	alternative to AES-CBC and AES-GCM. It is also being standardized		Group (CFRG) and others as an alternative to AES-CBC and AES-GCM. At
	for ESP for the same reasons. At the time of writing, there are not		the time of writing, there are not enough ESP implementations of
	enough ESP implementations of ENCR_CHACHA20_POLY1305 to be able to		ENCR_CHACHA20_POLY1305 to be able to introduce it at the SHOULD+
	introduce it at the SHOULD+ level. Its status has been set to SHOULD		level. Its status has been set to SHOULD and is expected to become
	and is expected to become MUST in the long term.		MUST in the long term.
	6. ESP and AH Authentication Algorithms		6. ESP and AH Authentication Algorithms
	Authentication algorithm recommendations in this section are		Authentication algorithm recommendations in this section are
	targeting two types of communications:		targeting two types of communications:
	o Authenticated only communications without encryption, such as ESP		o Authenticated-only communications without encryption, such as ESP
	with NULL encryption or AH communications.		with NULL encryption or AH communications.
	o Communications that are encrypted with non-AEAD algorithm which
			o Communications that are encrypted with a non-AEAD algorithm that
	MUST be combined with an authentication algorithm.		MUST be combined with an authentication algorithm.
	+------------------------+------------------+-----------------------+		+------------------------+----------------+-------------------------+
	| Name | Status | Comment |		| Name | Status | Comment |
	+------------------------+------------------+-----------------------+		+------------------------+----------------+-------------------------+
	| AUTH_NONE | MUST / MUST NOT | [RFC7296] AEAD |		| AUTH_NONE | MUST / | [RFC7296][RFC5282] |
	| AUTH_HMAC_MD5_96 | MUST NOT | [RFC2403][RFC7296] |		| | MUST NOT | AEAD-only |
	| AUTH_HMAC_SHA1_96 | MUST- | [RFC2404][RFC7296] |		| AUTH_HMAC_MD5_96 | MUST NOT | [RFC2403][RFC7296] |
	| AUTH_DES_MAC | MUST NOT | [UNSPECIFIED] |		| AUTH_HMAC_SHA1_96 | MUST- | [RFC2404][RFC7296] |
	| AUTH_KPDK_MD5 | MUST NOT | [UNSPECIFIED] |		| AUTH_DES_MAC | MUST NOT | UNSPECIFIED |
	| AUTH_AES_XCBC_96 | SHOULD | [RFC3566][RFC7296] |		| AUTH_KPDK_MD5 | MUST NOT | UNSPECIFIED |
	| | | (IoT) |		| AUTH_AES_XCBC_96 | SHOULD / MAY | [RFC3566][RFC7296] |
	| AUTH_AES_128_GMAC | MAY | [RFC4543] |		| | | (IoT) |
	| AUTH_AES_256_GMAC | MAY | [RFC4543] |		| AUTH_AES_128_GMAC | MAY | [RFC4543] |
	| AUTH_HMAC_SHA2_256_128 | MUST | [RFC4868] |		| AUTH_AES_256_GMAC | MAY | [RFC4543] |
	| AUTH_HMAC_SHA2_512_256 | SHOULD | [RFC4868] |		| AUTH_HMAC_SHA2_256_128 | MUST | [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 case where AUTH_NONE is acceptable is when authenticated		only case where AUTH_NONE is acceptable is when authenticated
	encryption algorithms are selected from Section 5. In all other		encryption algorithms are selected from Section 5. In all other
	cases, AUTH_NONE MUST NOT be selected. As ESP and AH both provide		cases, AUTH_NONE MUST NOT be selected. As ESP and AH both provide
	authentication, one may be tempted to combine these protocols to		authentication, one may be tempted to combine these protocols to
	provide authentication. As mentioned by RFC7321, it is NOT		provide authentication. As mentioned by [RFC7321], it is NOT
	RECOMMENDED to use ESP with NULL authentication - with non		RECOMMENDED to use ESP with NULL authentication (with non-
	authenticated encryption - in conjunction with AH; some		authenticated encryption) in conjunction with AH; some configurations
	configurations of this combination of services have been shown to be		of this combination of services have been shown to be insecure
	insecure [PD10]. In addition, AUTH_NONE authentication cannot be		[PD10]. In addition, AUTH_NONE authentication cannot be combined
	combined with ESP NULL encryption.		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].
	MD5 is known to be vulnerable to collisions, these algorithms MUST		As 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.
	AUTH_AES_XCBC_96 is set as SHOULD only in the scope of IoT, as		AUTH_AES_XCBC_96 is set as SHOULD only in the scope of IoT, as IoT
	Internet of Things deployments tend to prefer AES based HMAC		deployments tend to prefer AES-based Hashed Message Authentication
	functions in order to avoid implementing SHA2. For the wide VPN		Code (HMAC) functions in order to avoid implementing SHA2. For the
	deployment, as it has not been widely adopted, it has been downgraded		wide VPN deployment, as it has not been widely adopted, it has been
	from SHOULD to MAY.		downgraded from SHOULD to MAY.
	AUTH_AES_128_GMAC status has been downgraded from SHOULD+ to MAY.		AUTH_AES_128_GMAC status has been downgraded from SHOULD+ to MAY.
	Along with AUTH_AES_192_GMAC and AUTH_AES_256_GMAC, these algorithms		Along with AUTH_AES_192_GMAC and AUTH_AES_256_GMAC, these algorithms
	should only be used for AH and not for ESP. If using ENCR_NULL,		should only be used for AH and not for ESP. If using ENCR_NULL,
	AUTH_HMAC_SHA2_256_128 is recommended for integrity. If using AES-		AUTH_HMAC_SHA2_256_128 is recommended for integrity. If using AES-
	GMAC in ESP without authentication, ENCR_NULL_AUTH_AES_GMAC is		GMAC in ESP without authentication, ENCR_NULL_AUTH_AES_GMAC is
	recommended. Therefore, these ciphers are kept at MAY.		recommended. Therefore, these algorithms are kept at MAY.
	AUTH_HMAC_SHA2_256_128 was not mentioned in RFC7321, as no SHA2 based		AUTH_HMAC_SHA2_256_128 was not mentioned in [RFC7321], as no
	authentication was mentioned. AUTH_HMAC_SHA2_256_128 MUST be		SHA2-based authentication was mentioned. AUTH_HMAC_SHA2_256_128 MUST
	implemented in order to replace AUTH_HMAC_SHA1_96. Note that due to		be implemented in order to replace AUTH_HMAC_SHA1_96. Note that due
	a long standing common implementation bug of this algorithm that		to 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.
	7. 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 | [RFC3173] |
	| IPCOMP_LZS | MAY | [RFC2395] |		| IPCOMP_LZS | MAY | [RFC2395] |
	| IPCOMP_LZJH | MAY | [RFC3051] |		| IPCOMP_LZJH | MAY | [RFC3051] |
	+----------------+----------+-------------+		+----------------+----------+-------------+
	(IoT) - This requirement is for interoperability with IoT		Compression was not mentioned in [RFC7321]. As it is not widely
			deployed, it remains optional and at the MAY level.
	Compression was not mentioned in RFC7321. As it is not widely
	deployed, it remains optional and at the MAY-level.
	8. 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
	TABLE BELOW WITH THE NUMBER OF THIS RFC
	+-------------------+----------+-----------------+		+-------------------+----------+-----------------+
	| Algorithm | RFC 7321 | RFC XXXX |		| Algorithm | RFC 7321 | RFC 8221 |
	+-------------------+----------+-----------------+		+-------------------+----------+-----------------+
	| 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 | 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.
	9. Acknowledgements
	Some of the wording in this document was adapted from [RFC7321], the
	document that this one obsoletes, which was written by D. McGrew and
	P. Hoffman.
	10. IANA Considerations		9. IANA Considerations
	This document has no IANA actions.		This document does not require any IANA actions.
	11. Security Considerations		10. 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
	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.
	12. References		11. References
	12.1. Normative References		11.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>.		<https://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, <https://www.rfc-editor.org/info/rfc4301>.
	[RFC4302] Kent, S., "IP Authentication Header", RFC 4302,		[RFC4302] Kent, S., "IP Authentication Header", RFC 4302,
	DOI 10.17487/RFC4302, December 2005,		DOI 10.17487/RFC4302, December 2005,
	<http://www.rfc-editor.org/info/rfc4302>.		<https://www.rfc-editor.org/info/rfc4302>.
	[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>.		<https://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>.		<https://www.rfc-editor.org/info/rfc7321>.
	12.2. Informative References		[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
			2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
			May 2017, <https://www.rfc-editor.org/info/rfc8174>.
	[PD10] Paterson, K. and J. Degabriele, "On the (in)security of		11.2. Informative References
	IPsec in MAC-then-encrypt configurations (ACM Conference
	on Computer and Communications Security, ACM CCS)", 2010.
	[RFC2393] Shacham, A., Monsour, R., Pereira, R., and M. Thomas, "IP		[PD10] Paterson, K. and J. Degabriele, "On the (in)security of
	Payload Compression Protocol (IPComp)", RFC 2393,		IPsec in MAC-then-encrypt configurations", Proceedings of
	DOI 10.17487/RFC2393, December 1998,		the 17th ACM Conference on Computer and Communications
	<http://www.rfc-editor.org/info/rfc2393>.		Security (ACM CCS), DOI 10.1145/1866307.1866363, 2010.
	[RFC2395] Friend, R. and R. Monsour, "IP Payload Compression Using		[RFC2395] Friend, R. and R. Monsour, "IP Payload Compression Using
	LZS", RFC 2395, DOI 10.17487/RFC2395, December 1998,		LZS", RFC 2395, DOI 10.17487/RFC2395, December 1998,
	<http://www.rfc-editor.org/info/rfc2395>.		<https://www.rfc-editor.org/info/rfc2395>.
	[RFC2403] Madson, C. and R. Glenn, "The Use of HMAC-MD5-96 within		[RFC2403] Madson, C. and R. Glenn, "The Use of HMAC-MD5-96 within
	ESP and AH", RFC 2403, DOI 10.17487/RFC2403, November		ESP and AH", RFC 2403, DOI 10.17487/RFC2403, November
	1998, <http://www.rfc-editor.org/info/rfc2403>.		1998, <https://www.rfc-editor.org/info/rfc2403>.
	[RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within		[RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within
	ESP and AH", RFC 2404, DOI 10.17487/RFC2404, November		ESP and AH", RFC 2404, DOI 10.17487/RFC2404, November
	1998, <http://www.rfc-editor.org/info/rfc2404>.		1998, <https://www.rfc-editor.org/info/rfc2404>.
	[RFC2405] Madson, C. and N. Doraswamy, "The ESP DES-CBC Cipher		[RFC2405] Madson, C. and N. Doraswamy, "The ESP DES-CBC Cipher
	Algorithm With Explicit IV", RFC 2405,		Algorithm With Explicit IV", RFC 2405,
	DOI 10.17487/RFC2405, November 1998,		DOI 10.17487/RFC2405, November 1998,
	<http://www.rfc-editor.org/info/rfc2405>.		<https://www.rfc-editor.org/info/rfc2405>.
	[RFC2410] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and		[RFC2410] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and
	Its Use With IPsec", RFC 2410, DOI 10.17487/RFC2410,		Its Use With IPsec", RFC 2410, DOI 10.17487/RFC2410,
	November 1998, <http://www.rfc-editor.org/info/rfc2410>.		November 1998, <https://www.rfc-editor.org/info/rfc2410>.
	[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, DOI 10.17487/RFC2451, November		Algorithms", RFC 2451, DOI 10.17487/RFC2451, November
	1998, <http://www.rfc-editor.org/info/rfc2451>.		1998, <https://www.rfc-editor.org/info/rfc2451>.
	[RFC3051] Heath, J. and J. Border, "IP Payload Compression Using		[RFC3051] Heath, J. and J. Border, "IP Payload Compression Using
	ITU-T V.44 Packet Method", RFC 3051, DOI 10.17487/RFC3051,		ITU-T V.44 Packet Method", RFC 3051, DOI 10.17487/RFC3051,
	January 2001, <http://www.rfc-editor.org/info/rfc3051>.		January 2001, <https://www.rfc-editor.org/info/rfc3051>.
			[RFC3173] Shacham, A., Monsour, B., Pereira, R., and M. Thomas, "IP
			Payload Compression Protocol (IPComp)", RFC 3173,
			DOI 10.17487/RFC3173, September 2001,
			<https://www.rfc-editor.org/info/rfc3173>.
	[RFC3566] Frankel, S. and H. Herbert, "The AES-XCBC-MAC-96 Algorithm		[RFC3566] Frankel, S. and H. Herbert, "The AES-XCBC-MAC-96 Algorithm
	and Its Use With IPsec", RFC 3566, DOI 10.17487/RFC3566,		and Its Use With IPsec", RFC 3566, DOI 10.17487/RFC3566,
	September 2003, <http://www.rfc-editor.org/info/rfc3566>.		September 2003, <https://www.rfc-editor.org/info/rfc3566>.
	[RFC3602] Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC Cipher		[RFC3602] Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC Cipher
	Algorithm and Its Use with IPsec", RFC 3602,		Algorithm and Its Use with IPsec", RFC 3602,
	DOI 10.17487/RFC3602, September 2003,		DOI 10.17487/RFC3602, September 2003,
	<http://www.rfc-editor.org/info/rfc3602>.		<https://www.rfc-editor.org/info/rfc3602>.
	[RFC3686] Housley, R., "Using Advanced Encryption Standard (AES)		[RFC3686] Housley, R., "Using Advanced Encryption Standard (AES)
	Counter Mode With IPsec Encapsulating Security Payload		Counter Mode With IPsec Encapsulating Security Payload
	(ESP)", RFC 3686, DOI 10.17487/RFC3686, January 2004,		(ESP)", RFC 3686, DOI 10.17487/RFC3686, January 2004,
	<http://www.rfc-editor.org/info/rfc3686>.		<https://www.rfc-editor.org/info/rfc3686>.
	[RFC4106] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode		[RFC4106] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode
	(GCM) in IPsec Encapsulating Security Payload (ESP)",		(GCM) in IPsec Encapsulating Security Payload (ESP)",
	RFC 4106, DOI 10.17487/RFC4106, June 2005,		RFC 4106, DOI 10.17487/RFC4106, June 2005,
	<http://www.rfc-editor.org/info/rfc4106>.		<https://www.rfc-editor.org/info/rfc4106>.
	[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>.		<https://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>.		<https://www.rfc-editor.org/info/rfc4543>.
	[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>.		<https://www.rfc-editor.org/info/rfc4868>.
			[RFC5282] Black, D. and D. McGrew, "Using Authenticated Encryption
			Algorithms with the Encrypted Payload of the Internet Key
			Exchange version 2 (IKEv2) Protocol", RFC 5282,
			DOI 10.17487/RFC5282, August 2008,
			<https://www.rfc-editor.org/info/rfc5282>.
	[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, <https://www.rfc-editor.org/info/rfc7296>.
	[RFC7634] Nir, Y., "ChaCha20, Poly1305, and Their Use in the		[RFC7634] Nir, Y., "ChaCha20, Poly1305, and Their Use in the
	Internet Key Exchange Protocol (IKE) and IPsec", RFC 7634,		Internet Key Exchange Protocol (IKE) and IPsec", RFC 7634,
	DOI 10.17487/RFC7634, August 2015,		DOI 10.17487/RFC7634, August 2015,
	<http://www.rfc-editor.org/info/rfc7634>.		<https://www.rfc-editor.org/info/rfc7634>.
			Acknowledgements
			Some of the wording in this document was adapted from [RFC7321], the
			document that this one obsoletes, which was written by D. McGrew and
			P. Hoffman.
	Authors' Addresses		Authors' Addresses
	Paul Wouters		Paul Wouters
	Red Hat		Red Hat
	Email: pwouters@redhat.com		Email: pwouters@redhat.com
	Daniel Migault		Daniel Migault
	Ericsson		Ericsson
	8400 boulevard Decarie		8275 Trans Canada Route
	Montreal, QC H4P 2N2		Saint-Laurent, QC H4S 0B6
	Canada		Canada
	Phone: +1 514-452-2160		Phone: +1 514-452-2160
	Email: daniel.migault@ericsson.com		Email: daniel.migault@ericsson.com
	John Mattsson		John Mattsson
	Ericsson AB		Ericsson AB
	SE-164 80 Stockholm		SE-164 80 Stockholm
	Sweden		Sweden
	skipping to change at page 14, line 4 ¶		skipping to change at page 15, line 33 ¶
	Phone: +1 514-452-2160		Phone: +1 514-452-2160
	Email: daniel.migault@ericsson.com		Email: daniel.migault@ericsson.com
	John Mattsson		John Mattsson
	Ericsson AB		Ericsson AB
	SE-164 80 Stockholm		SE-164 80 Stockholm
	Sweden		Sweden
	Email: john.mattsson@ericsson.com		Email: john.mattsson@ericsson.com
	Yoav Nir		Yoav Nir
	Check Point Software Technologies Ltd.		Check Point Software Technologies Ltd.
	5 Hasolelim st.		5 Hasolelim St.
	Tel Aviv 6789735		Tel Aviv 6789735
	Israel		Israel
	Email: ynir.ietf@gmail.com		Email: ynir.ietf@gmail.com
	Tero Kivinen		Tero Kivinen
	INSIDE Secure
	Eerikinkatu 28
	HELSINKI FI-00180
	FI
	Email: kivinen@iki.fi		Email: kivinen@iki.fi
End of changes. 104 change blocks.
	265 lines changed or deleted		275 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/