< draft-ietf-ipsecme-implicit-iv-03.txt		draft-ietf-ipsecme-implicit-iv-04.txt >
	skipping to change at page 1, line 13 ¶		skipping to change at page 1, line 13 ¶
	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: November 10, 2018 LMU Munich		Expires: November 10, 2018 LMU Munich
	Y. Nir		Y. Nir
	Dell EMC		Dell EMC
	May 9, 2018		May 9, 2018
	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-03		draft-ietf-ipsecme-implicit-iv-04
	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) or nonce 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, AES-CTR and ChaCha20-Poly1305 require a unique nonce but do
	not require an unpredictable nonce. When using such algorithms the		not require an unpredictable nonce. When using such algorithms the
	packet counter value can be used to generate a nonce. This avoids		packet counter value can be used to generate a nonce. This avoids
	skipping to change at page 2, line 22 ¶		skipping to change at page 2, line 22 ¶
	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. Initiator Behavior . . . . . . . . . . . . . . . . . . . . . 4
	6. Responder Behavior . . . . . . . . . . . . . . . . . . . . . 5		6. Responder Behavior . . . . . . . . . . . . . . . . . . . . . 4
	7. Security Consideration . . . . . . . . . . . . . . . . . . . 5		7. Security Consideration . . . . . . . . . . . . . . . . . . . 4
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
	9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5		9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . 5		10. References . . . . . . . . . . . . . . . . . . . . . . . . . 5
	10.1. Normative References . . . . . . . . . . . . . . . . . . 6		10.1. Normative References . . . . . . . . . . . . . . . . . . 5
	10.2. Informational References . . . . . . . . . . . . . . . . 7		10.2. Informational References . . . . . . . . . . . . . . . . 6
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
	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", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [RFC2119].		document are to be interpreted as described in [RFC2119].
	2. Introduction		2. Introduction
	skipping to change at page 4, line 25 ¶		skipping to change at page 4, line 25 ¶
	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.
	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		Multicast as described in [RFC5374], [RFC6407] and
	[I-D.yeung-g-ikev2] is a prominent example, where many senders share		[I-D.yeung-g-ikev2] is a prominent example, where many senders share
	one secret and thus one SA. Section 3.5 of [RFC6407] provides a		one secret and thus one SA. As such, it is NOT RECOMMENDED to use
	mechanism that MAY be used to prevent IV collisions when the same key		Implicit IV with Multicast.
	is used by multiple users. The mechanism consists in partitioning
	the IV space between users by assigning the most significant byte to
	a user. When implicit IV transforms are used, such mechanism cannot
	be applied as the IV is not sent, but instead it is derived from the
	Sequence Number. A similar mechanism could be used by associating
	the most significant byte of the Sequence Number to a sender, while
	the 3 remaining bytes will be used to carry the counter value. Such
	mechanism prevents the use of Extended Sequence Number and limits the
	number of packet to be sent to 2** 24 = 16777216, that is 16 M. Note
	that associating instead the least significant byte of the Sequence
	Number to the sender, would enable the system to use Extended
	Sequence Number and as such extend the limit of packet to be sent to
	2 ** ( 24 + 32 ) = 72057594037927936, that is 72 P. Note also that
	in both cases the Sequence Number are not interpreted as numeric
	values which impacts the replay window processing defined in
	[RFC4302] and [RFC4302].
	Unless some mechanism are provided to avoid collision between
	Sequence Number, ( and so IV ), Implicit IV MUST NOT be used. As
	such, it is NOT RECOMMENDED to use Implicit IV with Multicast.
	5. Initiator Behavior		5. Initiator Behavior
	An initiator supporting this feature SHOULD propose implicit IV		An initiator supporting this feature SHOULD propose implicit IV
	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 SA Payload. 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 without Implicit
	IV (IIV) as separate transforms.		IV (IIV) as separate transforms.
	skipping to change at page 6, line 26 ¶		skipping to change at page 6, line 5 ¶
	[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,
	<https://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,
	<https://www.rfc-editor.org/info/rfc4106>.		<https://www.rfc-editor.org/info/rfc4106>.
	[RFC4302] Kent, S., "IP Authentication Header", RFC 4302,
	DOI 10.17487/RFC4302, December 2005,
	<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,
	<https://www.rfc-editor.org/info/rfc4303>.		<https://www.rfc-editor.org/info/rfc4303>.
	[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,
	<https://www.rfc-editor.org/info/rfc4309>.		<https://www.rfc-editor.org/info/rfc4309>.
	[RFC5374] Weis, B., Gross, G., and D. Ignjatic, "Multicast		[RFC5374] Weis, B., Gross, G., and D. Ignjatic, "Multicast
End of changes. 5 change blocks.
	31 lines changed or deleted		7 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/