< draft-ietf-ipsecme-implicit-iv-07.txt		draft-ietf-ipsecme-implicit-iv-08.txt >
	IPSECME D. Migault		IPSECME D. Migault
	Internet-Draft Ericsson		Internet-Draft Ericsson
	Intended status: Standards Track T. Guggemos		Intended status: Standards Track T. Guggemos
	Expires: October 8, 2019 LMU Munich		Expires: April 18, 2020 LMU Munich
	Y. Nir		Y. Nir
	Dell EMC		Dell EMC
	April 6, 2019		October 16, 2019
	Implicit IV for Counter-based Ciphers in Encapsulating Security Payload		Implicit IV for Counter-based Ciphers in Encapsulating Security Payload
	(ESP)		(ESP)
	draft-ietf-ipsecme-implicit-iv-07		draft-ietf-ipsecme-implicit-iv-08
	Abstract		Abstract
	Encapsulating Security Payload (ESP) sends an initialization vector		Encapsulating Security Payload (ESP) sends an initialization vector
	(IV) or nonce in each packet. The size of IV depends on the applied		(IV) in each packet. The size of IV depends on the applied
	transform, being usually 8 or 16 octets for the transforms defined by		transform, being usually 8 or 16 octets for the transforms defined by
	the time this document is written. Some algorithms such as AES-GCM,		the time this document is written. Some algorithms such as AES-GCM,
	AES-CCM, AES-CTR and ChaCha20-Poly1305 require a unique nonce but do		AES-CCM and ChaCha20-Poly1305 when used with IPsec, take the IV to
	not require an unpredictable nonce. When using such algorithms the		generate a nonce that is used as an input parameter for encrypting
	packet counter value can be used to generate a nonce. This avoids		and decrypting. These algorithms require a unique IV but do not
	sending the nonce itself, and saves in the case of AES-GCM, AES-CCM,		require an unpredictable IV. As a result, the value provided in the
	AES-CTR and ChaCha20-Poly1305 8 octets per packet. This document		ESP Sequence Number (SN) can be used instead to generate the nonce.
			This avoids sending the IV itself, and saves in the case of AES-GCM,
			AES-CCM and ChaCha20-Poly1305 8 octets per packet. This document
	describes how to do this.		describes how to do this.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted 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). 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 https://datatracker.ietf.org/drafts/current/.		Drafts is at https://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 October 8, 2019.		This Internet-Draft will expire on April 18, 2020.
	Copyright Notice		Copyright Notice
	Copyright (c) 2019 IETF Trust and the persons identified as the		Copyright (c) 2019 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
	(https://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
	skipping to change at page 2, line 21 ¶		skipping to change at page 2, line 26 ¶
	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. Requirements notation . . . . . . . . . . . . . . . . . . . . 2		1. Requirements notation . . . . . . . . . . . . . . . . . . . . 2
	2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3		3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
	4. Implicit IV . . . . . . . . . . . . . . . . . . . . . . . . . 3		4. Implicit IV . . . . . . . . . . . . . . . . . . . . . . . . . 3
	5. Initiator Behavior . . . . . . . . . . . . . . . . . . . . . 4		5. IKEv2 Initiator Behavior . . . . . . . . . . . . . . . . . . 4
	6. Responder Behavior . . . . . . . . . . . . . . . . . . . . . 4		6. IKEv2 Responder Behavior . . . . . . . . . . . . . . . . . . 5
	7. Security Consideration . . . . . . . . . . . . . . . . . . . 4		7. Security Considerations . . . . . . . . . . . . . . . . . . . 5
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
	9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5		9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . 5		10. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
	10.1. Normative References . . . . . . . . . . . . . . . . . . 6		10.1. Normative References . . . . . . . . . . . . . . . . . . 6
	10.2. Informational References . . . . . . . . . . . . . . . . 7		10.2. Informational References . . . . . . . . . . . . . . . . 8
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
	1. Requirements notation		1. Requirements notation
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	document are to be interpreted as described in [RFC2119].		"OPTIONAL" in this document are to be interpreted as described BCP 14
			[RFC2119], [RFC8174] when, and only when, they appear in all
			capitals, as shown here.
	2. Introduction		2. Introduction
	Counter-based AES modes of operation such as AES-CTR ([RFC3686]),		Counter-based AES modes of operation such as AES-CCM ([RFC4309]), and
	AES-CCM ([RFC4309]), and AES-GCM ([RFC4106]) require the		AES-GCM ([RFC4106]) require the specification of an nonce for each
	specification of an nonce for each ESP packet. The same applies for		ESP packet. The same applies for ChaCha20-Poly1305 ([RFC7634]).
	ChaCha20-Poly1305 ([RFC7634]). Currently this nonce is sent in each		Currently this nonce is generated thanks to the Initialize Vector
	ESP packet ([RFC4303]). This practice is designated in this document		(IV) provided in each ESP packet ([RFC4303]). This practice is
	as "explicit nonce".		designated in this document as "explicit IV".
	In some context, such as IoT, it may be preferable to avoid carrying		In some contexts, such as IoT, it may be preferable to avoid carrying
	the extra bytes associated to the IV and instead generate it locally		the extra bytes associated to the IV and instead generate it locally
	on each peer. The local generation of the nonce is designated in		on each peer. The local generation of the IV is designated in this
	this document as "implicit IV".		document as "implicit IV".
	The size of this nonce depends on the specific algorithm, but all of		The size of this IV depends on the specific algorithm, but all of the
	the algorithms mentioned above take an 8-octet nonce.		algorithms mentioned above take an 8-octet IV.
	This document defines how to compute the nonce locally when it is		This document defines how to compute the IV locally when it is
	implicit. It also specifies how peers agree with the Internet Key		implicit. It also specifies how peers agree with the Internet Key
	Exchange version 2 (IKEv2 - [RFC7296]) on using an implicit IV versus		Exchange version 2 (IKEv2 - [RFC7296]) on using an implicit IV versus
	an explicit IV.		an explicit IV.
	This document limits its scope to the algorithms mentioned above.		This document limits its scope to the algorithms mentioned above.
	Other algorithms with similar properties may later be defined to use		Other algorithms with similar properties may later be defined to use
	this extension.		similar mechanism.
	This document does not consider AES-CBC ([RFC3602]) as AES-CBC		This document does not consider AES-CBC ([RFC3602]) as AES-CBC
	requires the IV to be unpredictable. Deriving it directly from the		requires the IV to be unpredictable. Deriving it directly from the
	packet counter as described below is insecure as mentioned in		packet counter as described below is insecure as mentioned in
	Security Consideration of [RFC3602] and has led to real world chosen		Security Consideration of [RFC3602] and has led to real world chosen
	plain-text attack such as BEAST [BEAST].		plain-text attack such as BEAST [BEAST].
			This document does not consider AES-CTR [RFC3686] as it focuses on
			the recommended AEAD suites provided in [RFC8221].
	3. Terminology		3. Terminology
	o IoT: Internet of Things.		o IoT: Internet of Things.
	o IV: Initialization Vector.		o IV: Initialization Vector.
	o IIV: Implicit Initialization Vector.		o IIV: Implicit Initialization Vector.
	o Nonce: a fixed-size octet string used only once. This is similar		o Nonce: a fixed-size octet string used only once. In our case, the
	to IV, except that in common usage there is no implication of non-		nonce takes the IV as input and is provided as an input parameter
	predictability.		for encryption/decryption.
	4. Implicit IV		4. Implicit IV
	With the algorithms listed in Section 2, the 8 byte nonce MUST NOT		With the algorithms listed in Section 2, the 8-byte IV MUST NOT
	repeat. The binding between a ESP packet and its nonce is provided		repeat for a given key. The binding between an ESP packet and its IV
	using the Sequence Number or the Extended Sequence Number. Figure 1		is provided using the Sequence Number or the Extended Sequence
	and Figure 2 represent the IV with a regular 4-byte Sequence Number		Number. Figure 1 and Figure 2 represent the IV with a regular 4-byte
	and with an 8-byte Extended Sequence Number respectively.		Sequence Number and with an 8-byte Extended Sequence Number
			respectively.
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Zero |		| Zero |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Sequence Number |		| Sequence Number |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 1: Implicit IV with a 4 byte Sequence Number		Figure 1: Implicit IV with a 4 byte Sequence Number
	skipping to change at page 4, line 14 ¶		skipping to change at page 4, line 27 ¶
	o Zero: a 4 byte array with all bits set to zero.		o Zero: a 4 byte array with all bits set to zero.
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Extended |		| Extended |
	| Sequence Number |		| Sequence Number |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 2: Implicit IV with an 8 byte Extended Sequence Number		Figure 2: Implicit IV with an 8-byte Extended Sequence Number
	o Extended Sequence Number: the 8 byte Extended Sequence Number of		o Extended Sequence Number: the 8-byte Extended Sequence Number of
	the Security Association. The 4 byte low order bytes are carried		the Security Association. The 4 byte low order bytes are carried
	in the ESP packet.		in the ESP packet.
	This document solely defines the IV generation of the algorithms		This document solely defines the IV generation of the algorithms
	defined in [RFC4106] for AES-GCM, [RFC4309] for AES-CCM and [RFC7634]		defined in [RFC4106] for AES-GCM, [RFC4309] for AES-CCM and [RFC7634]
	for ChaCha20-Poly1305. Any other aspect (including using the Key		for ChaCha20-Poly1305. All other aspects and parameters of those
	Length attribute) of applying those ciphers with the new Transform		algorithms are unchanged, and are used as defined in their respective
	Types defined in this document MUST be taken from the documents		specifications.
	defining the use of the algorithms in ESP.
	5. Initiator Behavior		5. IKEv2 Initiator Behavior
	An initiator supporting this feature SHOULD propose implicit IV		An initiator supporting this feature SHOULD propose implicit IV (IIV)
	algorithms in the Transform Type 1 (Encryption Algorithm)		algorithms in the Transform Type 1 (Encryption Algorithm)
	Substructure of the Proposal Substructure inside the SA Payload. To		Substructure of the Proposal Substructure inside the Security
			Association Payload (SA Payload) in the IKEv2 Exchange. To
	facilitate backward compatibility with non-supporting peers the		facilitate backward compatibility with non-supporting peers the
	initiator SHOULD also include those same algorithms without Implicit		initiator SHOULD also include those same algorithms with explicit IV
	IV (IIV) as separate transforms.		as separate transforms.
	6. Responder Behavior		6. IKEv2 Responder Behavior
	The rules of SA Payload processing require that responder picks its		The rules of SA Payload processing require that responder picks its
	algorithms from the proposal sent by the initiator, thus this will		algorithms from the proposal sent by the initiator, thus this will
	ensure that the responder will never send an SA payload containing		ensure that the responder will never send an SA payload containing
	the IIV transform to an initiator that did not propose it.		the IIV transform to an initiator that did not propose it.
	7. Security Consideration		7. Security Considerations
	Nonce generation for these algorithms has not been explicitly		Nonce generation for these algorithms has not been explicitly
	defined. It has been left to the implementation as long as certain		defined. It has been left to the implementation as long as certain
	security requirements are met. Typically, for AES-GCM, AES-CCM, AES-		security requirements are met. Typically, for AES-GCM, AES-CCM and
	CTR and ChaCha20-Poly1305, the IV is not allowed being repeated for		ChaCha20-Poly1305, the IV is not allowed to be repeated for one
	one particular key. This document provides an explicit and normative		particular key. This document provides an explicit and normative way
	way to generate IVs. The mechanism described in this document meets		to generate IVs. The mechanism described in this document meets the
	the IV security requirements of all relevant algorithms.		IV security requirements of all relevant algorithms.
	As the IV must not repeat for one SA when Counter-Mode ciphers are		As the IV must not repeat for one SA when Counter-Mode ciphers are
	used, Implicit IV as described in this document MUST NOT be used in		used, implicit IV as described in this document MUST NOT be used in
	setups with the chance that the Sequence Number overlaps for one SA.		setups with the chance that the Sequence Number overlaps for one SA.
	Multicast as described in [RFC5374], [RFC6407] and		The sender's counter and the receiver's counter MUST be reset (by
	[I-D.yeung-g-ikev2] is a prominent example, where many senders share		establishing a new SA and thus a new key) prior to the transmission
	one secret and thus one SA. As such, Implicit IV may only be used		of the 2^32nd packet for an SA that uses a non extended Sequence
	with Multicast if some mechanisms are employed that prevent Sequence		Number (respectively the 2^64nd packet for an SA that uses an
	Number to overlap for one SA, otherwise Implicit IV MUST NOT be used		Extended Sequence Number). This prevents sequence number overlaps
	with Multicast.		for the mundane point-to-point case. Multicast as described in
			[RFC5374], [RFC6407] and [I-D.yeung-g-ikev2] is a prominent example,
			where many senders share one secret and thus one SA. As such,
			Implicit IV may only be used with Multicast if some mechanisms are
			employed that prevent Sequence Number to overlap for one SA,
			otherwise Implicit IV MUST NOT be used with Multicast.
	This document defines three new encryption transforms that use		This document defines three new encryption transforms that use
	implicit IV. Unlike most encryption transforms defined to date,		implicit IV. Unlike most encryption transforms defined to date,
	which can be used for both ESP and IKEv2, these transforms are		which can be used for both ESP and IKEv2, these transforms are
	defined for ESP only and cannot be used in IKEv2. The reason is that		defined for ESP only and cannot be used in IKEv2. The reason is that
	IKEv2 messages don't contain unique per-message value, that can be		IKEv2 messages don't contain a unique per-message value that can be
	used for IV generation. The Message-ID field in IKEv2 header is		used for IV generation. The Message-ID field in IKEv2 header is
	somewhat counterpart of SN field in ESP header, but recent IKEv2		similar to the SN field in ESP header, but recent IKEv2 extensions
	extensions ([RFC6311], [RFC7383]) do allow it to repeat, so there is		([RFC6311], [RFC7383]) do allow it to repeat, so there is not an easy
	no an easy way to derive unique IV from IKEv2 header fields.		way to derive unique IV from IKEv2 header fields.
	8. IANA Considerations		8. IANA Considerations
	This section assigns new code points to the recommended AEAD suites		The IANA has assigned the following code points:
	provided in [RFC8221], thus the new Transform Type 1 - Encryption
	Algorithm Transform IDs [IANA] are as defined below:
	- ENCR_AES_CCM_8_IIV: 29		- ENCR_AES_CCM_8_IIV: 29
	- ENCR_AES_GCM_16_IIV: 30		- ENCR_AES_GCM_16_IIV: 30
	- ENCR_CHACHA20_POLY1305_IIV: 31		- ENCR_CHACHA20_POLY1305_IIV: 31
	These algorithms should be added with this document as ESP Reference		These algorithms should be added with this document as ESP Reference
	and "Not Allowed" for IKEv2 Reference.		and "Not Allowed" for IKEv2 Reference.
	9. Acknowledgements		9. Acknowledgements
	We would like to thanks people Valery Smyslov for their valuable		We would like to thank Valery Smyslov, Eric Vyncke, Magnus Nystrom
	comments, David Schinazi for its implementation, as well as the		(security directorate), as well as our three ADs Eric Rescorla,
	ipseceme chairs Tero Kivinen and David Waltermire for moving this		Benjamin Kaduk and Roman Danyliw for their valuable comments. We
	work forward.		also would like to thank David Schinazi for its implementation, as
			well as the ipseceme chairs Tero Kivinen and David Waltermire for
			moving this work forward.
			NOTE TO THE EDITOR Eric has a accent on E and Magnus has double
			points on o.
	10. References		10. References
	10.1. Normative References		10.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,
	<https://www.rfc-editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
	[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,
	skipping to change at page 7, line 20 ¶		skipping to change at page 7, line 39 ¶
	[RFC7383] Smyslov, V., "Internet Key Exchange Protocol Version 2		[RFC7383] Smyslov, V., "Internet Key Exchange Protocol Version 2
	(IKEv2) Message Fragmentation", RFC 7383,		(IKEv2) Message Fragmentation", RFC 7383,
	DOI 10.17487/RFC7383, November 2014,		DOI 10.17487/RFC7383, November 2014,
	<https://www.rfc-editor.org/info/rfc7383>.		<https://www.rfc-editor.org/info/rfc7383>.
	[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,
	<https://www.rfc-editor.org/info/rfc7634>.		<https://www.rfc-editor.org/info/rfc7634>.
			[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>.
	[RFC8221] Wouters, P., Migault, D., Mattsson, J., Nir, Y., and T.		[RFC8221] Wouters, P., Migault, D., Mattsson, J., Nir, Y., and T.
	Kivinen, "Cryptographic Algorithm Implementation		Kivinen, "Cryptographic Algorithm Implementation
	Requirements and Usage Guidance for Encapsulating Security		Requirements and Usage Guidance for Encapsulating Security
	Payload (ESP) and Authentication Header (AH)", RFC 8221,		Payload (ESP) and Authentication Header (AH)", RFC 8221,
	DOI 10.17487/RFC8221, October 2017,		DOI 10.17487/RFC8221, October 2017,
	<https://www.rfc-editor.org/info/rfc8221>.		<https://www.rfc-editor.org/info/rfc8221>.
	10.2. Informational References		10.2. Informational References
	[BEAST] Thai, T. and J. Juliano, "Here Come The xor Ninjas", ,		[BEAST] Thai, T. and J. Juliano, "Here Come The xor Ninjas", ,
	May 2011, <https://www.researchgate.net/		May 2011, <https://www.researchgate.net/
	publication/266529975_Here_Come_The_Ninjas>.		publication/266529975_Here_Come_The_Ninjas>.
	[I-D.yeung-g-ikev2]		[I-D.yeung-g-ikev2]
	Weis, B. and V. Smyslov, "Group Key Management using		Weis, B. and V. Smyslov, "Group Key Management using
	IKEv2", draft-yeung-g-ikev2-15 (work in progress), March		IKEv2", draft-yeung-g-ikev2-16 (work in progress), July
	2019.		2019.
	[IANA] "IANA IKEv2 Parameter - Type 1 - Encryption Algorithm		[IANA] "IANA IKEv2 Parameter - Type 1 - Encryption Algorithm
	Transform IDs", <https://www.iana.org/assignments/ikev2-		Transform IDs", <https://www.iana.org/assignments/ikev2-
	parameters/ikev2-parameters.xhtml#ikev2-parameters-5>.		parameters/ikev2-parameters.xhtml#ikev2-parameters-5>.
	Authors' Addresses		Authors' Addresses
	Daniel Migault		Daniel Migault
	Ericsson		Ericsson
End of changes. 39 change blocks.
	78 lines changed or deleted		98 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/