< draft-ietf-ipsecme-implicit-iv-09.txt		draft-ietf-ipsecme-implicit-iv-10.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: April 20, 2020 LMU Munich		Expires: April 22, 2020 LMU Munich
	Y. Nir		Y. Nir
	Dell EMC		Dell EMC
	October 18, 2019		October 20, 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-09		draft-ietf-ipsecme-implicit-iv-10
	Abstract		Abstract
	Encapsulating Security Payload (ESP) sends an initialization vector		Encapsulating Security Payload (ESP) sends an initialization vector
	(IV) 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 and ChaCha20-Poly1305 when used with IPsec, take the IV to		AES-CCM and ChaCha20-Poly1305 when used with IPsec, take the IV to
	generate a nonce that is used as an input parameter for encrypting		generate a nonce that is used as an input parameter for encrypting
	and decrypting. This IV must be unique but can be predictable. As a		and decrypting. This IV must be unique but can be predictable. As a
	skipping to change at page 1, line 45 ¶		skipping to change at page 1, line 45 ¶
	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 April 20, 2020.		This Internet-Draft will expire on April 22, 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 5, line 49 ¶		skipping to change at page 5, line 49 ¶
	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 a 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
	similar to the SN field in ESP header, but recent IKEv2 extensions		similar to the SN field in ESP header, but recent IKEv2 extensions
	([RFC6311], [RFC7383]) do allow it to repeat, so there is not an easy		([RFC6311], [RFC7383]) do allow it to repeat, so there is not 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
	The IANA has assigned the following code points:		The IANA has assigned the following code points to the registry
			Transform Type 1 - Encryption Algorithm Transform IDs [IANA]:
	- 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
End of changes. 5 change blocks.
	5 lines changed or deleted		6 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/