< draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt-04.txt		draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt-05.txt >
	IPSECME Working Group S. Kampati		IPSECME Working Group S. Kampati
	Internet-Draft W. Pan		Internet-Draft W. Pan
	Intended status: Standards Track Huawei		Intended status: Standards Track Huawei
	Expires: October 22, 2021 M. Bharath		Expires: January 5, 2022 M. Bharath
	Mavenir		Mavenir
	M. Chen		M. Chen
	CMCC		CMCC
	April 20, 2021		July 04, 2021
	IKEv2 Optional SA&TS Payloads in Child Exchange		IKEv2 Optional SA&TS Payloads in Child Exchange
	draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt-04		draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt-05
	Abstract		Abstract
	This document describes a method for reducing the size of the		This document describes a method for reducing the size of the
	Internet Key Exchange version 2 (IKEv2) exchanges at time of rekeying		Internet Key Exchange version 2 (IKEv2) exchanges at time of rekeying
	IKE SAs and Child SAs by removing or making optional of SA & TS		IKE SAs and Child SAs by removing or making optional of SA & TS
	payloads. Reducing size of IKEv2 exchanges is desirable for low		payloads. Reducing size of IKEv2 exchanges is desirable for low
	power consumption battery powered devices. It also helps to avoid IP		power consumption battery powered devices. It also helps to avoid IP
	fragmentation of IKEv2 messages.		fragmentation of IKEv2 messages.
	skipping to change at page 1, line 39 ¶		skipping to change at page 1, line 39 ¶
	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 22, 2021.		This Internet-Draft will expire on January 5, 2022.
	Copyright Notice		Copyright Notice
	Copyright (c) 2021 IETF Trust and the persons identified as the		Copyright (c) 2021 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 16 ¶		skipping to change at page 2, line 16 ¶
	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 . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Conventions Used in This Document . . . . . . . . . . . . . . 3		2. Conventions Used in This Document . . . . . . . . . . . . . . 3
	2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3		2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
	3. Protocol Details . . . . . . . . . . . . . . . . . . . . . . 3		3. Protocol Details . . . . . . . . . . . . . . . . . . . . . . 3
	3.1. Negotiation of Support for Optimizing Optional Payload at		3.1. Negotiation of Support for Optimizing Payloads at
	Rekeying IKE SAs and Child SAs . . . . . . . . . . . . . 4		Rekeying IKE SAs and Child SAs . . . . . . . . . . . . . 4
	3.2. Payload Optimization at Rekeying IKE SAs . . . . . . . . 5		3.2. Payload Optimization at Rekeying IKE SAs . . . . . . . . 4
	3.2.1. Rekeying IKE SAs When No Change of Initiator and		3.3. Payload Optimization at Rekeying Child SAs . . . . . . . 6
	Responder's Cryptographic Suites . . . . . . . . . . 5		4. Payload Formats . . . . . . . . . . . . . . . . . . . . . . . 6
	3.2.2. Rekeying IKE SAs When Responder's Cryptographic		4.1. MINIMAL_REKEY_SUPPORTED Notification . . . . . . . . . . 7
	Suites Changed . . . . . . . . . . . . . . . . . . . 6		4.2. REKEY_OPTIMIZED Notification . . . . . . . . . . . . . . 7
	3.3. Payload Optimization at Rekeying Child SAs . . . . . . . 7		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
	3.3.1. Rekeying Child SAs When No Change of Initiator and		6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
	Responder's Cryptographic Suites and ACL		7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8
	Configuration . . . . . . . . . . . . . . . . . . . . 7		8. Normative References . . . . . . . . . . . . . . . . . . . . 8
	3.3.2. Rekeying Child SAs When Responder's Cryptographic		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
	Suites or ACL Configuration Changed . . . . . . . . . 8
	4. Payload Formats . . . . . . . . . . . . . . . . . . . . . . . 9
	4.1. MINIMAL_REKEY_SUPPORTED Notification . . . . . . . . . . 9
	4.2. SA_UNCHANGED Notification . . . . . . . . . . . . . . . . 10
	4.3. SA_TS_UNCHANGED Notification . . . . . . . . . . . . . . 10
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
	7. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
	7.1. Normative References . . . . . . . . . . . . . . . . . . 11
	7.2. Informative References . . . . . . . . . . . . . . . . . 12
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
	1. Introduction		1. Introduction
	The Internet Key Exchange protocol version 2 (IKEv2) specified in		The Internet Key Exchange protocol version 2 (IKEv2) specified in
	[RFC7296] is used in the IP Security (IPsec) architecture for the		[RFC7296] is used in the IP Security (IPSec) architecture for the
	purposes of Security Association (SA) parameters negotiation and		purposes of Security Association (SA) parameters negotiation and
	authenticated key exchange. The protocol uses UDP as the transport		authenticated key exchange. The protocol uses UDP as the transport
	for its messages, which size varies from less than one hundred bytes		for its messages, which size varies from less than one hundred bytes
	to several kilobytes.		to several kilobytes.
	According to [RFC7296], the secret keys used by IKE/IPSec SAs should		According to [RFC7296], the secret keys used by IKE/IPSec SAs should
	be used only for a limited amount of time and to protect a limited		be used only for a limited amount of time and to protect a limited
	amount of data. When the lifetime of an SA expires or is about to		amount of data. When the lifetime of an SA expires or is about to
	expire, the peers can rekey the SA to reestablish a new SA to take		expire, the peers can rekey the SA to reestablish a new SA to take
	the place of the old one.		the place of the old one.
	For security gateways/ePDG in 4G networks and cRAN/Cloud in 5G		For security gateways/ePDG in 4G networks and cRAN/Cloud in 5G
	networks, they will support more than 100,000 IKE/IPSEC tunnels. So		networks, they will support more than 100,000 IKE/IPSEC tunnels. So
	on an average, for every second there may be hundreds or thousands of		on an average, for every second there may be hundreds or thousands of
	IKE SAs and Child SAs that are rekeying. This takes huge amount of		IKE SAs and Child SAs that are rekeying. This takes huge amount of
	bandwidth, packet fragmentation and more processing resources. For		bandwidth, packet fragmentation and more processing resources. For
	these devices, these problems can be solved by introducing the		these devices, these problems can be solved by introducing the
	solution described in this document.		solution described in this document.
	This is also useful in Internet of Things (IoT) devices which		This is also useful in Internet of Things (IoT) devices which
	utilizing lower power consumption technology. The appendix A of		utilizing lower power consumption technology. For these devices,
	[I-D.mglt-6lo-diet-esp-requirements] gives some estimate data. For		reducing the length of IKE/Child SA rekeying messages can save the
	these devices, reducing the length of IKE/Child SA rekeying messages		bandwidth consumption. At the same time, it can also save the
	can save the bandwidth consumption. At the same time, it can also		computing processes by less payload are included.
	save the computing processes by less payload are included.
	Most devices don't prefer to change cryptographic suites frequently.		Most devices don't prefer to change cryptographic suites frequently.
	By taking this advantage the SA and TS payloads can be made optional		By taking this advantage the SA and TS payloads can be made optional
	at the time of rekeying IKE SAs and Child SAs. In such situation,		at the time of rekeying IKE SAs and Child SAs. In such situation,
	only a new SPI value is needed to create the new IKE SA and Child SA.		only a new SPI value is needed to create the new IKE SA and Child SA.
	So a new Notify payload which contains the needed SPI value can be		So a new Notify payload which contains the needed SPI value can be
	sent instead of the SA and TS payloads.		sent instead of the SA and TS payloads.
	In case of rekeying IKE SAs, the SA payloads can be optimized if		In case of rekeying IKE SAs, the SA payloads can be optimized if
	there is no change of cryptographic suites. In case of rekeying		there is no change of cryptographic suites. In case of rekeying
	skipping to change at page 4, line 15 ¶		skipping to change at page 4, line 5 ¶
	failure from happening, the first step is to negotiate the support of		failure from happening, the first step is to negotiate the support of
	this optimization between the two peers. There are two specific		this optimization between the two peers. There are two specific
	rekeying SAs cases: rekeying IKE SAs and rekeying Child SAs. After		rekeying SAs cases: rekeying IKE SAs and rekeying Child SAs. After
	the negotiation, the initiator can optimize the rekeying message		the negotiation, the initiator can optimize the rekeying message
	payloads in both cases. In other words, once the negotiation of		payloads in both cases. In other words, once the negotiation of
	support for optimizing payloads at rekeying IKE SAs and Child SAs is		support for optimizing payloads at rekeying IKE SAs and Child SAs is
	complete, both IKE SAs and Child SAs rekeying are supported by the		complete, both IKE SAs and Child SAs rekeying are supported by the
	two sides. The responder can react based on the received rekeying		two sides. The responder can react based on the received rekeying
	message.		message.
	3.1. Negotiation of Support for Optimizing Optional Payload at Rekeying		3.1. Negotiation of Support for Optimizing Payloads at Rekeying IKE SAs
	IKE SAs and Child SAs		and Child SAs
	The initiator indicates its support for optimizing optional payloads		The initiator indicates its support for optimizing payloads at
	at rekeying IKE SAs and Child SAs by including a Notify payload of		rekeying IKE SAs and Child SAs by including a Notify payload of type
	type MINIMAL_REKEY_SUPPORTED in the IKE_AUTH request message. By		MINIMAL_REKEY_SUPPORTED in the IKE_AUTH request message. By
	observing the MINIMAL_REKEY_SUPPORTED notification in the received		observing the MINIMAL_REKEY_SUPPORTED notification in the received
	message, the responder can deduce the initiator's support of this		message, the responder can deduce the initiator's support of this
	extension. If the responder also supports this extension, it		extension. If the responder also supports this extension, it
	includes the MINIMAL_REKEY_SUPPORTED notification in the		includes the MINIMAL_REKEY_SUPPORTED notification in the
	corresponding response message. After receiving the response		corresponding response message. After receiving the response
	message, the initiator can also know the support of this extension of		message, the initiator can also know the support of this extension of
	the responder side.		the responder side.
	The IKE_AUTH message exchange in this case is shown below:		The IKE_AUTH message exchange in this case is shown below:
	skipping to change at page 5, line 17 ¶		skipping to change at page 4, line 52 ¶
	HDR, SK {IDi, [CERT,] [CERTREQ,]		HDR, SK {IDi, [CERT,] [CERTREQ,]
	[IDr,] AUTH, SAi2, TSi, TSr,		[IDr,] AUTH, SAi2, TSi, TSr,
	N(MINIMAL_REKEY_SUPPORTED)} -->		N(MINIMAL_REKEY_SUPPORTED)} -->
	<-- HDR, SK {IDr, [CERT,] AUTH,		<-- HDR, SK {IDr, [CERT,] AUTH,
	SAr2, TSi, TSr}		SAr2, TSi, TSr}
	3.2. Payload Optimization at Rekeying IKE SAs		3.2. Payload Optimization at Rekeying IKE SAs
	The payload optimization at rekeying IKE SAs MUST NOT be used unless		The payload optimization at rekeying IKE SAs MUST NOT be used unless
	both peers have indicated their support of this extension by using		both peers have indicated their support of this extension by using
	the negotiation method described in Section 3.1. If the initiator		the negotiation method described in Section 3.1.
	decides to optimize the payloads at the time of rekeying IKE SAs,
	then it includes the SA_UNCHANGED notification in its CREATE_CHILD_SA
	exchange message. If the initiator decides not to do the
	optimization, then it just sends the rekeying request message as the
	original way, the rekeying is conducted as [RFC7296] defined. If the
	initiator and responder decides to do the optimization, then the IKE
	SA rekeying uses PFS by default.
	3.2.1. Rekeying IKE SAs When No Change of Initiator and Responder's
	Cryptographic Suites
	At the time of rekeying an IKE SA, when the initiator determines		At the time of rekeying an IKE SA, when the initiator determines
	there is no change on its cryptographic suites since this IKE SA was		there is no change on its cryptographic suites since this IKE SA was
	created or last rekeyed, it MAY send the SA_UNCHANGED notification		created or last rekeyed, it MUST send the REKEY_OPTIMIZED
	payload instead of the SA payloads in the rekeying request message.		notification payload instead of the SA payloads in the rekeying
	In this SA_UNCHANGED notification, it contains the initiator's new		request message. In this REKEY_OPTIMIZED notification, it contains
	Security Parameter Index (SPI) used for creating the new IKE SA.		the initiator's new Security Parameter Index (SPI) used for creating
			the new IKE SA.
	After receiving the initiator's rekeying request message with the		After receiving the initiator's rekeying request message with the
	SA_UNCHANGED notification and no SA payloads, the responder knows		REKEY_OPTIMIZED notification and no SA payloads, the responder knows
	that the initiator wants to optimize the rekeying payload. Then when		that the initiator wants to optimize the rekeying payload. Then when
	it determines that there is also no change in its cryptographic		it determines that there is also no change in its cryptographic
	suites, the responder MAY send the rekeying respond message to the		suites, the responder MUST send the rekeying respond message to the
	initiator with the SA_UNCHANGED notification payload instead of the		initiator with the REKEY_OPTIMIZED notification payload instead of
	SA payloads. In this SA_UNCHANGED notification, it contains the		the SA payloads. In this REKEY_OPTIMIZED notification, it contains
	responder's new SPI used for creating the new IKE SA.		the responder's new SPI used for creating the new IKE SA.
	According to the initiator's new SPI and the responder's new SPI, the		According to the initiator's new SPI and the responder's new SPI, the
	initiator and the responder can rekey the IKE SA on both sides.		initiator and the responder can rekey the IKE SA on both sides.
	The CREATE_CHILD_SA message exchange in this case is shown below:		The CREATE_CHILD_SA message exchange in this case is shown below:
	Initiator Responder		Initiator Responder
	--------------------------------------------------------------------		--------------------------------------------------------------------
	HDR, SK {N(SA_UNCHANGED), Ni, KEi} -->		HDR, SK {N(REKEY_OPTIMIZED),
	<-- HDR, SK {N(SA_UNCHANGED), Nr, KEr}		Ni, KEi} -->
			<-- HDR, SK {N(REKEY_OPTIMIZED),
			Nr, KEr}
	The initiator sends a SA_UNCHANGED notification payload, a Nonce		The initiator sends a REKEY_OPTIMIZED notification payload, a Nonce
	payload and a Diffie-Hellman value in the KEi payload. A new		payload and a Diffie-Hellman value in the KEi payload. A new
	initiator SPI is supplied in the SPI field of the SA_UNCHANGED		initiator SPI is supplied in the SPI field of the REKEY_OPTIMIZED
	notification payload. These messages also follow the original PFS		notification payload. These messages also follow the original
	with the signature and encryption algorithms used as last message.		Perfect Forwarding Secrecy (PFS) with the signature and encryption
			algorithms used as last message.
	The responder replies (using the same Message ID to respond) with a		The responder replies (using the same Message ID to respond) with a
	SA_UNCHANGED notification payload, a Nonce payload and a Diffie-		REKEY_OPTIMIZED notification payload, a Nonce payload and a Diffie-
	Hellman value in the KEr payload. A new responder SPI is supplied in		Hellman value in the KEr payload. A new responder SPI is supplied in
	the SPI field of the SA_UNCHANGED notification payload.		the SPI field of the REKEY_OPTIMIZED notification payload.
	This SA_UNCHANGED notification MUST be included in a CREATE_CHILD_SA
	exchange message when there is no SA payloads included. When the
	SA_UNCHANGED notification payload is included, the SA payload MUST
	NOT be included.
	3.2.2. Rekeying IKE SAs When Responder's Cryptographic Suites Changed
	At the time of or before rekeying IKE SAs, the responder's
	cryptographic suites may be changed while there is no change of
	initiator's cryptographic suites. New cryptographic suites may be
	added to the responder, or some outdated cryptographic suites may be
	deleted from the responder. In this situation, the initiator MAY
	send the SA_UNCHANGED notification payload instead of the SA payloads
	in the CREATE_CHILD_SA request message at the time of rekeying IKE
	SAs.
	If the responder decides to continue using the previously negotiated
	cryptographic suite to rekey the IKE SA, it MAY send the SA_UNCHANGED
	notification payload in the CREATE_CHILD_SA response message, then
	the rekeying is conducted like the way described in Section 3.2.1.
	If the responder decides to re-negotiate the cryptographic suite, it
	MUST send NO_PROPOSAL_CHOSEN notification payload in the
	CREATE_CHILD_SA response message. After receiving this error
	notification, the initiator MUST retry the CREATE_CHILD_SA exchange
	with the SA payloads. Then the rekeying is conducted in the original
	way defined in [RFC7296]. The CREATE_CHILD_SA message exchange in
	this case is shown below:
	Initiator Responder
	--------------------------------------------------------------------
	HDR, SK {N(SA_UNCHANGED), Ni, KEi} -->
	<-- HDR, SK {N(NO_PROPOSAL_CHOSEN),
	Nr, KEr}
	HDR, SK {SA, Ni, KEi} -->
	<-- HDR, SK {SA, Ni, KEi}
	Besides, if the responder only supports the Child SA rekeying		This REKEY_OPTIMIZED notification MUST be included in a
	optimization and doesn't support the IKE SA rekeying optimization, it		CREATE_CHILD_SA exchange message when there is no SA payloads
	can also follow the way described above, i.e., it MUST send		included. When the REKEY_OPTIMIZED notification payload is included,
	NO_PROPOSAL_CHOSEN notification payload in the CREATE_CHILD_SA		the SA payload MUST NOT be included.
	response message when receiving the SA_UNCHANGED notification at the
	time of rekeying IKE SAs.
	3.3. Payload Optimization at Rekeying Child SAs		3.3. Payload Optimization at Rekeying Child SAs
	The payload optimization at rekeying Child SAs MUST NOT be used		The payload optimization at rekeying Child SAs MUST NOT be used
	unless both peers have indicated their support of this extension by		unless both peers have indicated their support of this extension by
	using the negotiation method described in Section 3.1. If the		using the negotiation method described in Section 3.1.
	initiator decides to optimize the payloads at the time of rekeying
	Child SAs, then it includes the SA_TS_UNCHANGED notification in its
	CREATE_CHILD_SA exchange message. If the initiator decides not to do
	the optimization, then it just sends the rekeying request message as
	the original way, the rekeying is conducted as [RFC7296] defined.
	This SA_TS_UNCHANGED notification MUST be included in a
	CREATE_CHILD_SA exchange message when there is no SA and TS payloads
	included. The new Child SA is created with the SPI value in the
	SA_TS_UNCHANGED notification.
	3.3.1. Rekeying Child SAs When No Change of Initiator and Responder's
	Cryptographic Suites and ACL Configuration
	At the time of rekeying Child SAs, the initiator MAY send the
	SA_TS_UNCHANGED notification payload instead of the SA and TS
	payloads when there is no change in its cryptographic suites and ACL
	configuration since last negotiation. After receiving the
	initiator's request message with the SA_TS_UNCHANGED notification,
	the responder MAY respond to the initiator with the SA_TS_UNCHANGED
	notification payload instead of the SA and TS payloads if there is
	also no change in its cryptographic suites and ACL configuration
	since last negotiation.
	At the time of rekeying a Child SA, when the initiator determines		At the time of rekeying a Child SA, when the initiator determines
	there is no change in its cryptographic suites and ACL configuration		there is no change in its cryptographic suites and ACL configuration
	since this Child SA was created or last rekeyed, it MAY send the		since this Child SA was created or last rekeyed, it MUST send the
	SA_TS_UNCHANGED notification payload instead of the SA and TS		REKEY_OPTIMIZED notification payload instead of the SA and TS
	payloads in the rekeying request message. In this SA_TS_UNCHANGED		payloads in the rekeying request message. In this REKEY_OPTIMIZED
	notification, it contains the initiator's new Security Parameter		notification, it contains the initiator's new Security Parameter
	Index (SPI) used for creating the new Child SA.		Index (SPI) used for creating the new Child SA.
	After receiving the initiator's rekeying request message with the		After receiving the initiator's rekeying request message with the
	SA_TS_UNCHANGED notification and no SA and TS payloads, the responder		REKEY_OPTIMIZED notification and no SA and TS payloads, the responder
	knows that the initiator wants to optimize the rekeying payload.		knows that the initiator wants to optimize the rekeying payload.
	Then when it determines that there is also no change in its		Then when it determines that there is also no change in its
	cryptographic suites and ACL configuration, the responder MAY send		cryptographic suites and ACL configuration, the responder MUST send
	the rekeying respond message to the initiator with the		the rekeying respond message to the initiator with the
	SA_TS_UNCHANGED notification payload instead of the SA and TS		REKEY_OPTIMIZED notification payload instead of the SA and TS
	payloads. In this SA_TS_UNCHANGED notification, it contains the		payloads. In this REKEY_OPTIMIZED notification, it contains the
	responder's new SPI used for creating the new Child SA.		responder's new SPI used for creating the new Child SA.
	According to the initiator's new SPI and the responder's new SPI, the		According to the old SPIs included in the REKEY_SA payloads and the
	initiator and the responder can rekey the Child SA on both sides.		new SPIs included in the REKEY_OPTIMIZED payloads, the initiator and
			the responder can rekey the Child SA on both sides.
	The CREATE_CHILD_SA message exchange in this case is shown below:		The CREATE_CHILD_SA message exchange in this case is shown below:
	Initiator Responder		Initiator Responder
	--------------------------------------------------------------------		--------------------------------------------------------------------
	HDR, SK {N(REKEY_SA), N(SA_TS_UNCHANGED),		HDR, SK {N(REKEY_SA), N(REKEY_OPTIMIZED),
	Ni, [KEi,]} -->		Ni, [KEi,]} -->
	<-- HDR, SK {N(SA_TS_UNCHANGED),		<-- HDR, SK {N(REKEY_OPTIMIZED),
	Nr, [KEr,]}		Nr, [KEr,]}
	This SA_TS_UNCHANGED notification MUST be included in a		This REKEY_OPTIMIZED notification MUST be included in a
	CREATE_CHILD_SA exchange message when there is no SA and TS payloads		CREATE_CHILD_SA exchange message when there is no SA and TS payloads
	included at the time of rekeying Child SAs. When the SA_TS_UNCHANGED		included at the time of rekeying Child SAs. When the REKEY_OPTIMIZED
	notification payload is included, the SA and TS payloads MUST NOT be		notification payload is included, the SA and TS payloads MUST NOT be
	included.		included.
	3.3.2. Rekeying Child SAs When Responder's Cryptographic Suites or ACL
	Configuration Changed
	At the time of or before rekeying Child SAs, the responder's
	cryptographic suites or ACL configuration may be changed while there
	is no change of initiator's cryptographic suites and ACL
	configuration. In this situation, the initiator MAY send the
	SA_TS_UNCHANGED notification payload instead of the SA and TS
	payloads in the CREATE_CHILD_SA request message at the time of
	rekeying Child SAs.
	If the responder decides to continue using the previously negotiated
	cryptographic suite and Traffic Selectors to rekey the Child SA, it
	MAY send the SA_TS_UNCHANGED notification payload in the
	CREATE_CHILD_SA response message, then the rekeying is conducted like
	Section 3.3.1.
	If the responder decides to re-negotiate the cryptographic suite or
	Traffic Selectors, it MUST send NO_PROPOSAL_CHOSEN notification
	payload in the CREATE_CHILD_SA response message. After receiving
	this error notification, the initiator MUST retry the CREATE_CHILD_SA
	exchange with the SA and TS payloads. Then the rekeying is conducted
	in the original way defined in [RFC7296]. The CREATE_CHILD_SA
	message exchange in this case is shown below:
	Initiator Responder
	--------------------------------------------------------------------
	HDR, SK {N(SA_TS_UNCHANGED), Ni, KEi} -->
	<-- HDR, SK {N(NO_PROPOSAL_CHOSEN),
	Nr, KEr}
	HDR, SK {N(REKEY_SA), SA, Ni, [KEi,]
	TSi, TSr} -->
	<-- HDR, SK {SA, Nr, [KEr,]
	TSi, TSr}
	Besides, if the responder only supports the IKE SA rekeying
	optimization and doesn't support the Child SA rekeying optimization,
	it can also follow the way described above, i.e., it MUST send
	NO_PROPOSAL_CHOSEN notification payload in the CREATE_CHILD_SA
	response message when receiving the SA_TS_UNCHANGED notification at
	the time of rekeying Child SAs.
	4. Payload Formats		4. Payload Formats
	4.1. MINIMAL_REKEY_SUPPORTED Notification		4.1. MINIMAL_REKEY_SUPPORTED Notification
	The MINIMAL_REKEY_SUPPORTED notification is used by the initiator and		The MINIMAL_REKEY_SUPPORTED notification is used by the initiator and
	responder to inform their ability of optimizing optional payload at		responder to inform their ability of optimizing payloads at the time
	the time of rekeying IKE SAs and Child SAs to the peers. It is		of rekeying IKE SAs and Child SAs to the peers. It is formatted as
	formatted as follows:		follows:
	1 2 3		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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Next Payload |C| RESERVED | Payload Length |		| Next Payload |C| RESERVED | Payload Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|Protocol ID(=0)| SPI Size (=0) | Notify Message Type |		|Protocol ID(=0)| SPI Size (=0) | Notify Message Type |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	o Protocol ID (1 octet) - MUST be 0.		o Protocol ID (1 octet) - MUST be 0.
	o SPI Size (1 octet) - MUST be 0, meaning no SPI is present.		o SPI Size (1 octet) - MUST be 0, meaning no SPI is present.
	o Notify Message Type (2 octets) - MUST be <Need to get value from		o Notify Message Type (2 octets) - MUST be <Need to get value from
	IANA>, the value assigned for the MINIMAL_REKEY_SUPPORTED		IANA>, the value assigned for the MINIMAL_REKEY_SUPPORTED
	notification.		notification.
	This notification contains no data.		This notification contains no data.
	4.2. SA_UNCHANGED Notification		4.2. REKEY_OPTIMIZED Notification
	The SA_UNCHANGED notification is used to replace the SA payloads at		The REKEY_OPTIMIZED notification is used to replace the SA payloads
	the time of rekeying IKE SAs when there is no change of cryptographic		at the time of rekeying IKE SAs when there is no change of
	suites in initiator or responder. It is formatted as follows:		cryptographic suites in initiator and responder, and to replace the
			SA payloads and TS payloads at the time of rekeying Child SAs when
			there is no change of cryptographic suites and ACL configuration in
			initiator and responder. It is formatted as follows:
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Next Payload |C| RESERVED | Payload Length |		| Next Payload |C| RESERVED | Payload Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|Protocol ID | SPI Size (=8) | Notify Message Type |		|Protocol ID | SPI Size (=8) | Notify Message Type |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Security Parameter Index (SPI) |		| Security Parameter Index (SPI) |
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	o Protocol ID (1 octet) - MUST be 1.		o Protocol ID (1 octet) - MUST be 1.
	o SPI Size (1 octet) - MUST be 8.		o SPI Size (1 octet) - MUST be 8 when used at the time of rekeying
			IKE SAs and be 4 when used at the time of rekeying Child SAs.
	o Notify Message Type (2 octets) - MUST be <Need to get value from
	IANA>, the value assigned for the SA_UNCHANGED notification.
	o SPI (8 octets) - Security Parameter Index. The initiator sends
	initiator SPI. The responder sends responder SPI.
	4.3. SA_TS_UNCHANGED Notification
	The SA_TS_UNCHANGED notification is used to replace the SA payloads
	and TS payloads at the time of rekeying Child SAs when there is no
	change of cryptographic suites and ACL configuration in initiator or
	responder. The SPI of the new Child SA is included in this payload,
	and the SPI of the old Child SA is in the REKEY_SA notification
	payload. The SA_TS_UNCHANGED notification is formatted as follows:
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Next Payload |C| RESERVED | Payload Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|Protocol ID | SPI Size (=4) | Notify Message Type |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Security Parameter Index (SPI) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	o Protocol ID (1 octet) - MUST be either (2) to indicate AH or (3)
	to indicate ESP.
	o SPI Size (1 octet) - MUST be 4.
	o Notify Message Type (2 octets) - MUST be <Need to get value from		o Notify Message Type (2 octets) - MUST be <Need to get value from
	IANA>, the value assigned for the SA_TS_UNCHANGED notification.		IANA>, the value assigned for the REKEY_OPTIMIZED notification.
	o SPI (4 octets) - Security Parameter Index. The initiator sends		o SPI (4 octets or 8 octets) - Security Parameter Index. The
	initiator SPI. The responder sends responder SPI.		initiator sends initiator SPI. The responder sends responder SPI.
	5. IANA Considerations		5. IANA Considerations
	This document defines two new Notify Message Types in the "IKEv2		This document defines two new Notify Message Types in the "IKEv2
	Notify Message Types - Status Types" registry. IANA is requested to		Notify Message Types - Status Types" registry. IANA is requested to
	assign codepoints in this registry.		assign codepoints in this registry.
	NOTIFY messages: status types Value		NOTIFY messages: status types Value
	----------------------------------------------------------		----------------------------------------------------------
	MINIMAL_REKEY_SUPPORTED TBD		MINIMAL_REKEY_SUPPORTED TBD
	SA_UNCHANGED TBD		REKEY_OPTIMIZED TBD
	SA_TS_UNCHANGED TBD
	6. Security Considerations		6. Security Considerations
	TBD		When using the payload optimization defined in this document, the
			rekeying of IKE SAs and Child SAs are using the same cryptographic
			suites. If changes to the configurations are wanted, such as
			supporting a new cryptographic algorithm, the rekeying won't apply
			these changes. The initiator or responder should start a new IKE SA
			or Child SA to apply the new changes.
	7. References		7. Acknowledgments
	7.1. Normative References		Special thanks go to Paul Wouters, Valery Smyslov, and Antony Antony.
			8. 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>.
	[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, <https://www.rfc-editor.org/info/rfc7296>.		2014, <https://www.rfc-editor.org/info/rfc7296>.
	[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC		[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
	2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,		2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
	May 2017, <https://www.rfc-editor.org/info/rfc8174>.		May 2017, <https://www.rfc-editor.org/info/rfc8174>.
	7.2. Informative References
	[I-D.mglt-6lo-diet-esp-requirements]
	Migault, D., Guggemos, T., and C. Bormann, "Requirements
	for Diet-ESP the IPsec/ESP protocol for IoT", draft-mglt-
	6lo-diet-esp-requirements-02 (work in progress), July
	2016.
	Authors' Addresses		Authors' Addresses
	Sandeep Kampati		Sandeep Kampati
	Huawei Technologies		Huawei Technologies
	Divyashree Techno Park, Whitefield		Divyashree Techno Park, Whitefield
	Bangalore, Karnataka 560066		Bangalore, Karnataka 560066
	India		India
	Email: sandeepkampati@huawei.com		Email: sandeepkampati@huawei.com
	skipping to change at page 13, line 4 ¶		skipping to change at page 9, line 30 ¶
	Email: william.panwei@huawei.com		Email: william.panwei@huawei.com
	Meduri S S Bharath		Meduri S S Bharath
	Mavenir Systems Pvt Ltd		Mavenir Systems Pvt Ltd
	Manyata Tech Park		Manyata Tech Park
	Bangalore, Karnataka		Bangalore, Karnataka
	India		India
	Email: bharath.meduri@mavenir.com		Email: bharath.meduri@mavenir.com
	Meiling Chen		Meiling Chen
	China Mobile		China Mobile
	32 Xuanwumen West Street, West District		32 Xuanwumen West Street, West District
	Beijing, Beijing 100053		Beijing, Beijing 100053
			China
	Email: chenmeiling@chinamobile.com		Email: chenmeiling@chinamobile.com
End of changes. 45 change blocks.
	242 lines changed or deleted		94 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/