< draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt-05.txt		draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt-06.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: January 5, 2022 M. Bharath		Expires: 13 January 2022 M. Bharath
	Mavenir		Mavenir
	M. Chen		M. Chen
	CMCC		CMCC
	July 04, 2021		12 July 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-05		draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt-06
	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) CREATE_CHILD_SA exchanges
	IKE SAs and Child SAs by removing or making optional of SA & TS		used for rekeying of the IKE or Child SA by replacing the SA and TS
	payloads. Reducing size of IKEv2 exchanges is desirable for low		payloads with a Notify Message payload. Reducing size and complexity
	power consumption battery powered devices. It also helps to avoid IP		of IKEv2 exchanges is especially useful for low power consumption
	fragmentation of IKEv2 messages.		battery powered devices.
	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 January 5, 2022.		This Internet-Draft will expire on 13 January 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/
	(https://trustee.ietf.org/license-info) in effect on the date of		license-info) in effect on the date of publication of this document.
	publication of this document. Please review these documents		Please review these documents carefully, as they describe your rights
	carefully, as they describe your rights and restrictions with respect		and restrictions with respect to this document. Code Components
	to this document. Code Components extracted from this document must		extracted from this document must include Simplified BSD License text
	include Simplified BSD License text as described in Section 4.e of		as described in Section 4.e of the Trust Legal Provisions and are
	the Trust Legal Provisions and are provided without warranty as		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. Negotiation of Support for OPTIMIZED REKEY . . . . . . . . . 3
	3.1. Negotiation of Support for Optimizing Payloads at		4. Optimized Rekey of the IKE SA . . . . . . . . . . . . . . . . 4
	Rekeying IKE SAs and Child SAs . . . . . . . . . . . . . 4		5. Optimized Rekey of Child SAs . . . . . . . . . . . . . . . . 5
	3.2. Payload Optimization at Rekeying IKE SAs . . . . . . . . 4		6. Payload Formats . . . . . . . . . . . . . . . . . . . . . . . 5
	3.3. Payload Optimization at Rekeying Child SAs . . . . . . . 6		6.1. OPTIMIZED_REKEY_SUPPORTED Notify . . . . . . . . . . . . 5
	4. Payload Formats . . . . . . . . . . . . . . . . . . . . . . . 6		6.2. OPTIMIZED_REKEY Notify . . . . . . . . . . . . . . . . . 6
	4.1. MINIMAL_REKEY_SUPPORTED Notification . . . . . . . . . . 7		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
	4.2. REKEY_OPTIMIZED Notification . . . . . . . . . . . . . . 7		8. Operational Considerations . . . . . . . . . . . . . . . . . 7
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8		9. Security Considerations . . . . . . . . . . . . . . . . . . . 7
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 8		10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7
	7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8		11. Normative References . . . . . . . . . . . . . . . . . . . . 7
	8. Normative References . . . . . . . . . . . . . . . . . . . . 8		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
	1. Introduction		1. Introduction
	The Internet Key Exchange protocol version 2 (IKEv2) specified in		The Internet Key Exchange protocol version 2 (IKEv2) [RFC7296] is
	[RFC7296] is used in the IP Security (IPSec) architecture for the		used to negotiate Security Association (SA) parameters for the IKE SA
	purposes of Security Association (SA) parameters negotiation and		and the Child SAs. Cryptographic key material for these SAs have a
	authenticated key exchange. The protocol uses UDP as the transport		limited lifetime before it needs to be refreshed, a process referred
	for its messages, which size varies from less than one hundred bytes		to as "rekeying". IKEv2 uses the CREATE_CHILD_SA exchange to rekey
	to several kilobytes.		either the IKE SA or the Child SAs.
	According to [RFC7296], the secret keys used by IKE/IPSec SAs should		When rekeying, a full set of previously negotiated parameters are
	be used only for a limited amount of time and to protect a limited		exchanged. However, most of these parameters will be the same, and
	amount of data. When the lifetime of an SA expires or is about to		some of these parameters MUST be the same.
	expire, the peers can rekey the SA to reestablish a new SA to take
	the place of the old one.
	For security gateways/ePDG in 4G networks and cRAN/Cloud in 5G		For example, the Traffic Selector (TS) negotiated for the new Child
	networks, they will support more than 100,000 IKE/IPSEC tunnels. So		SA MUST cover the Traffic Selectors negotiated for the old Child SA.
	on an average, for every second there may be hundreds or thousands of		And in practically all cases, a new Child SA would not need to cover
	IKE SAs and Child SAs that are rekeying. This takes huge amount of		more Traffic Selectors. In the rare case where this would be needed,
	bandwidth, packet fragmentation and more processing resources. For		a new Child SA could be negotiated instead of the current Child SA
	these devices, these problems can be solved by introducing the		being rekeyed. Similarly, IKEv2 states that the cryptographic
	solution described in this document.		parameters negotiated for rekeying SHOULD NOT be different. This
			means that the security properties of the IKE or Child SA in practise
			do not change during a typical rekey.
	This is also useful in Internet of Things (IoT) devices which		This document specifies a method to omit these parameters and replace
	utilizing lower power consumption technology. For these devices,		them with a single Notify Message declaring that all these parameters
	reducing the length of IKE/Child SA rekeying messages can save the		are identical to the originally negotiated parameters.
	bandwidth consumption. At the same time, it can also save the
	computing processes by less payload are included.
	Most devices don't prefer to change cryptographic suites frequently.		For security gateways/ePDG in 4G networks or cRAN/Cloud gateways in
	By taking this advantage the SA and TS payloads can be made optional		5G networks, gateways typically support more than 100,000 IKE/IPSec
	at the time of rekeying IKE SAs and Child SAs. In such situation,		tunnels. At any point in time, there will be hundreds or thousands
	only a new SPI value is needed to create the new IKE SA and Child SA.		of IKE SAs and Child SAs that are being rekeyed. This takes a large
	So a new Notify payload which contains the needed SPI value can be		amount of bandwidth and CPU power and any protocol simplification or
	sent instead of the SA and TS payloads.		bandwidth reducing would result in an significant resource saving.
	In case of rekeying IKE SAs, the SA payloads can be optimized if		For Internet of Things (IoT) devices which utilize low power
	there is no change of cryptographic suites. In case of rekeying		consumption technology, reducing the size of rekey exchange reduces
	Child SAs, the SA and TS payloads can be optimized if there is no		its power consumption, as sending bytes over the air is usually the
	change of cryptographic suites and ACL configuration.		most power consuming operation of such a device. Reducing the CPU
			operations required to verify the rekey exchanges parameters will
			also save power and extend the lifetime for these devices.
			When using identical parameters during the IKE or Child SA rekey, the
			SA and TS payloads can be omitted. For an IKE SA rekey, instead of
			the (large) SA payload, only a Key Exchange (KE) payload and a new
			Notify Type payload with the new SPI is required. For a Child SA
			payload, instead of the SA or TS payloads, only an optional Nonce
			payload (when using PFS) and a new Notify Type payload with the new
			SPI is needed. This makes the rekey exchange packets much smaller
			and the peers do not need to verify that the SA or TS parameters are
			compatible with the old SA.
	2. Conventions Used in This Document		2. Conventions Used in This Document
	2.1. Requirements Language		2.1. 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 BCP		"OPTIONAL" in this document are to be interpreted as described in BCP
	14 [RFC2119] [RFC8174] when, and only when, they appear in all		14 [RFC2119] [RFC8174] when, and only when, they appear in all
	capitals, as shown here.		capitals, as shown here.
	3. Protocol Details		3. Negotiation of Support for OPTIMIZED REKEY
	This section provides protocol details and contains the normative
	parts.
	Before using this new optimization, the IPSec implementation who
	supports it has to know that the peer also supports it. Without the
	support on both sides, the optimized rekeying messages sent by one
	peer may be unrecognizable for the other peer. To prevent this
	failure from happening, the first step is to negotiate the support of
	this optimization between the two peers. There are two specific
	rekeying SAs cases: rekeying IKE SAs and rekeying Child SAs. After
	the negotiation, the initiator can optimize the rekeying message
	payloads in both cases. In other words, once the negotiation of
	support for optimizing payloads at rekeying IKE SAs and Child SAs is
	complete, both IKE SAs and Child SAs rekeying are supported by the
	two sides. The responder can react based on the received rekeying
	message.
	3.1. Negotiation of Support for Optimizing Payloads at Rekeying IKE SAs		To indicate support for the optimized rekey negotiation, the
	and Child SAs		initiator includes the OPTIMIZED_REKEY_SUPPORTED Notify payload in
			the IKE_AUTH exchange request. A responder that supports the
			optimized rekey exchange includes the OPTIMIZED_REKEY_SUPPORTED
			Notify payload in its response. Note that the notify indicates
			support for optimized rekey for both IKE and Child SAs.
	The initiator indicates its support for optimizing payloads at		When a peer wishes to rekey an IKE SA or Child SA, it MAY use the
	rekeying IKE SAs and Child SAs by including a Notify payload of type		optimized rekey method during the CREATE_CHILD_SA exchange. A
	MINIMAL_REKEY_SUPPORTED in the IKE_AUTH request message. By		responder MUST accept that the initiator uses a regular or optimized
	observing the MINIMAL_REKEY_SUPPORTED notification in the received		rekey.
	message, the responder can deduce the initiator's support of this
	extension. If the responder also supports this extension, it
	includes the MINIMAL_REKEY_SUPPORTED notification in the
	corresponding response message. After receiving the response
	message, the initiator can also know the support of this extension of
	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:
	Initiator Responder		Initiator Responder
	--------------------------------------------------------------------		--------------------------------------------------------------------
	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(OPTIMIZED_REKEY_SUPPORTED)} -->
	<-- HDR, SK {IDr, [CERT,] AUTH,		<-- HDR, SK {IDr, [CERT,] AUTH,
	SAr2, TSi, TSr,		SAr2, TSi, TSr,
	N(MINIMAL_REKEY_SUPPORTED)}		N(OPTIMIZED_REKEY_SUPPORTED)}
	If the responder doesn't support this extension, it MUST ignore the
	MINIMAL_REKEY_SUPPORTED notification sent by the initiator and MUST
	NOT respond error to the initiator. With no MINIMAL_REKEY_SUPPORTED
	notification in the response message, the initiator can deduce that
	the responder doesn't support this extension. In this case, the IKE
	SAs and Child SAs rekeyings happen as the usual way without the
	optimizations defined in this document.
	The IKE_AUTH message exchange in this case is shown below:
	Initiator Responder
	--------------------------------------------------------------------
	HDR, SK {IDi, [CERT,] [CERTREQ,]
	[IDr,] AUTH, SAi2, TSi, TSr,
	N(MINIMAL_REKEY_SUPPORTED)} -->
	<-- HDR, SK {IDr, [CERT,] AUTH,
	SAr2, TSi, TSr}
	3.2. Payload Optimization at Rekeying IKE SAs		If the responder does not support this extension, as per regular
			IKEv2 processing, it MUST ignore the unknown Notify payload. The
			initiator will notice the lack of the OPTIMIZED_REKEY_SUPPORTED
			Notify in the reply and thus know it cannot use the optimized rekey
			method.
	The payload optimization at rekeying IKE SAs MUST NOT be used unless		4. Optimized Rekey of the IKE SA
	both peers have indicated their support of this extension by using
	the negotiation method described in Section 3.1.
	At the time of rekeying an IKE SA, when the initiator determines		The initiator of an optimized rekey request sends a CREATE_CHILD_SA
	there is no change on its cryptographic suites since this IKE SA was		payload with the OPTIMIZED_REKEY notify payload containing the new
	created or last rekeyed, it MUST send the REKEY_OPTIMIZED		Security Parameter Index (SPI) for the new IKE SA. It omits the SA
	notification payload instead of the SA payloads in the rekeying		payload.
	request message. In this REKEY_OPTIMIZED notification, it contains
	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		The responder of an optimized rekey request performs the same
	REKEY_OPTIMIZED notification and no SA payloads, the responder knows		process. It includes the OPTIMIZED_REKEY notify with its new IKE SPI
	that the initiator wants to optimize the rekeying payload. Then when		and omits the SA payload.
	it determines that there is also no change in its cryptographic
	suites, the responder MUST send the rekeying respond message to the
	initiator with the REKEY_OPTIMIZED notification payload instead of
	the SA payloads. In this REKEY_OPTIMIZED notification, it contains
	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		Both parties send Nonce and KE payloads just as they would do for a
	initiator and the responder can rekey the IKE SA on both sides.		regular IKE SA rekey.
	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_OPTIMIZED),		HDR, SK {N(OPTIMIZED_REKEY),
	Ni, KEi} -->		Ni, KEi} -->
	<-- HDR, SK {N(REKEY_OPTIMIZED),		<-- HDR, SK {N(OPTIMIZED_REKEY),
	Nr, KEr}		Nr, KEr}
	The initiator sends a REKEY_OPTIMIZED notification payload, a Nonce		5. Optimized Rekey of Child SAs
	payload and a Diffie-Hellman value in the KEi payload. A new
	initiator SPI is supplied in the SPI field of the REKEY_OPTIMIZED
	notification payload. These messages also follow the original
	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
	REKEY_OPTIMIZED notification payload, a Nonce payload and a Diffie-
	Hellman value in the KEr payload. A new responder SPI is supplied in
	the SPI field of the REKEY_OPTIMIZED notification payload.
	This REKEY_OPTIMIZED notification MUST be included in a
	CREATE_CHILD_SA exchange message when there is no SA payloads
	included. When the REKEY_OPTIMIZED notification payload is included,
	the SA payload MUST NOT be included.
	3.3. Payload Optimization at Rekeying Child SAs
	The payload optimization at rekeying Child SAs MUST NOT be used		The initiator of an optimized rekey request sends a CREATE_CHILD_SA
	unless both peers have indicated their support of this extension by		payload with the OPTIMIZED_REKEY notify payload containing the new
	using the negotiation method described in Section 3.1.		Security Parameter Index (SPI) for the new Child SA. It omits the SA
			and TS payloads. If the current Child SA was negotiated with Perfect
			Forward Secrecy (PFS), a KEi payload MUST be included as well. If no
			PFS was negotiated for the current Child SA, a KEi payload MUST NOT
			be included.
	At the time of rekeying a Child SA, when the initiator determines		The responder of an optimized rekey request performs the same
	there is no change in its cryptographic suites and ACL configuration		process. It includes the OPTIMIZED_REKEY notify with its new IKE SPI
	since this Child SA was created or last rekeyed, it MUST send the		and omits the SA and TS payloads. Depending on the PFS negotiation
	REKEY_OPTIMIZED notification payload instead of the SA and TS		of the current Child SA, the responder includes a KEr payload.
	payloads in the rekeying request message. In this REKEY_OPTIMIZED
	notification, it contains the initiator's new Security Parameter
	Index (SPI) used for creating the new Child SA.
	After receiving the initiator's rekeying request message with the		Both parties send Nonce payloads just as they would do for a regular
	REKEY_OPTIMIZED notification and no SA and TS payloads, the responder		Child SA rekey.
	knows that the initiator wants to optimize the rekeying payload.
	Then when it determines that there is also no change in its
	cryptographic suites and ACL configuration, the responder MUST send
	the rekeying respond message to the initiator with the
	REKEY_OPTIMIZED notification payload instead of the SA and TS
	payloads. In this REKEY_OPTIMIZED notification, it contains the
	responder's new SPI used for creating the new Child SA.
	According to the old SPIs included in the REKEY_SA payloads and the		Using the received old SPI from the REKEY_SA payload and the new SPI
	new SPIs included in the REKEY_OPTIMIZED payloads, the initiator and		received from the OPTIMIZED_REKEY payload, both parties can perform
	the responder can rekey the Child SA on both sides.		the Child SA rekey operation.
	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(REKEY_OPTIMIZED),		HDR, SK {N(REKEY_SA), N(OPTIMIZED_REKEY),
	Ni, [KEi,]} -->		Ni, [KEi,]} -->
	<-- HDR, SK {N(REKEY_OPTIMIZED),		<-- HDR, SK {N(OPTIMIZED_REKEY),
	Nr, [KEr,]}		Nr, [KEr,]}
	This REKEY_OPTIMIZED notification MUST be included in a		6. Payload Formats
	CREATE_CHILD_SA exchange message when there is no SA and TS payloads
	included at the time of rekeying Child SAs. When the REKEY_OPTIMIZED
	notification payload is included, the SA and TS payloads MUST NOT be
	included.
	4. Payload Formats		6.1. OPTIMIZED_REKEY_SUPPORTED Notify
	4.1. MINIMAL_REKEY_SUPPORTED Notification
	The MINIMAL_REKEY_SUPPORTED notification is used by the initiator and		The OPTIMIZED_REKEY_SUPPORTED Notify Message type notification is
	responder to inform their ability of optimizing payloads at the time		used by the initiator and responder to indicate their support for the
	of rekeying IKE SAs and Child SAs to the peers. It is formatted as		optimized rekey negotiation.
	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.		* Protocol ID (1 octet) - MUST be 0.
	o SPI Size (1 octet) - MUST be 0, meaning no SPI is present.		* 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		* Notify Message Type (2 octets) - MUST be set to the value [TBD1].
	IANA>, the value assigned for the MINIMAL_REKEY_SUPPORTED
	notification.
	This notification contains no data.		This Notify Message type contains no data.
	4.2. REKEY_OPTIMIZED Notification		6.2. OPTIMIZED_REKEY Notify
	The REKEY_OPTIMIZED notification is used to replace the SA payloads		The OPTIMIZED_REKEY Notify Message type is used to perform an
	at the time of rekeying IKE SAs when there is no change of		optimized IKE SA or Child SA rekey.
	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.		* Protocol ID (1 octet) - MUST be 1.
	o SPI Size (1 octet) - MUST be 8 when used at the time of rekeying		* SPI Size (1 octet) - MUST be 8 when rekeying an IKE SA. MUST be 4
	IKE SAs and be 4 when used at the time of rekeying Child SAs.		when rekeying a Child SA.
	o Notify Message Type (2 octets) - MUST be <Need to get value from		* Notify Message Type (2 octets) - MUST be set to the value [TBD2].
	IANA>, the value assigned for the REKEY_OPTIMIZED notification.
	o SPI (4 octets or 8 octets) - Security Parameter Index. The		* SPI (4 octets or 8 octets) - Security Parameter Index. The peer's
	initiator sends initiator SPI. The responder sends responder SPI.		new SPI.
	5. IANA Considerations		7. 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		OPTIMIZED_REKEY_SUPPORTED TBD1
	REKEY_OPTIMIZED TBD		OPTIMIZED_REKEY TBD2
	6. Security Considerations		8. Operational Considerations
	When using the payload optimization defined in this document, the		Some implementations allow sending rekey messages with a different
	rekeying of IKE SAs and Child SAs are using the same cryptographic		set of Traffic Selectors or cryptographic parameters in response to a
	suites. If changes to the configurations are wanted, such as		configuration update. IKEv2 states this SHOULD NOT be done. Whether
	supporting a new cryptographic algorithm, the rekeying won't apply		or not optimized rekeying is used, a configuration change that
	these changes. The initiator or responder should start a new IKE SA		changes the Traffic Selectors or cryptographic parameters MUST NOT
	or Child SA to apply the new changes.		use the optimized rekey method. It SHOULD also not use a regular
			rekey method but instead start an entire new IKE and Child SA
			negotiation with the new parameters.
	7. Acknowledgments		9. Security Considerations
			The optimized rekey removes sending unnecessary new parameters that
			originally would have to be validated against the original
			parameters. In that sense, this optimization enhances the security
			of the rekey process.
			10. Acknowledgments
	Special thanks go to Paul Wouters, Valery Smyslov, and Antony Antony.		Special thanks go to Paul Wouters, Valery Smyslov, and Antony Antony.
	8. Normative References		11. 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>.
	Authors' Addresses		Authors' Addresses
	Sandeep Kampati		Sandeep Kampati
	Huawei Technologies		Huawei Technologies
	Divyashree Techno Park, Whitefield		Divyashree Techno Park, Whitefield
	Bangalore, Karnataka 560066		Bangalore 560066
			Karnataka
	India		India
	Email: sandeepkampati@huawei.com		Email: sandeepkampati@huawei.com
	Wei Pan		Wei Pan
	Huawei Technologies		Huawei Technologies
	101 Software Avenue, Yuhuatai District		101 Software Avenue, Yuhuatai District
	Nanjing, Jiangsu		Nanjing
			Jiangsu,
	China		China
	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		China
	Email: chenmeiling@chinamobile.com		Email: chenmeiling@chinamobile.com
End of changes. 56 change blocks.
	226 lines changed or deleted		167 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/