< draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt-03.txt		draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt-04.txt >
	IPSECME Working Group S. Kampati		IPSECME Working Group S. Kampati
	Internet-Draft M. Bharath		Internet-Draft W. Pan
	Intended status: Standards Track W. Pan		Intended status: Standards Track Huawei
	Expires: September 8, 2021 Huawei		Expires: October 22, 2021 M. Bharath
	March 07, 2021		Mavenir
			M. Chen
			CMCC
			April 20, 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-03		draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt-04
	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 36 ¶		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 September 8, 2021.		This Internet-Draft will expire on October 22, 2021.
	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 34 ¶		skipping to change at page 2, line 37 ¶
	3.3.2. Rekeying Child SAs When Responder's Cryptographic		3.3.2. Rekeying Child SAs When Responder's Cryptographic
	Suites or ACL Configuration Changed . . . . . . . . . 8		Suites or ACL Configuration Changed . . . . . . . . . 8
	4. Payload Formats . . . . . . . . . . . . . . . . . . . . . . . 9		4. Payload Formats . . . . . . . . . . . . . . . . . . . . . . . 9
	4.1. MINIMAL_REKEY_SUPPORTED Notification . . . . . . . . . . 9		4.1. MINIMAL_REKEY_SUPPORTED Notification . . . . . . . . . . 9
	4.2. SA_UNCHANGED Notification . . . . . . . . . . . . . . . . 10		4.2. SA_UNCHANGED Notification . . . . . . . . . . . . . . . . 10
	4.3. SA_TS_UNCHANGED Notification . . . . . . . . . . . . . . 10		4.3. SA_TS_UNCHANGED Notification . . . . . . . . . . . . . . 10
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 11		6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
	7. References . . . . . . . . . . . . . . . . . . . . . . . . . 11		7. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
	7.1. Normative References . . . . . . . . . . . . . . . . . . 11		7.1. Normative References . . . . . . . . . . . . . . . . . . 11
	7.2. Informative References . . . . . . . . . . . . . . . . . 11		7.2. Informative References . . . . . . . . . . . . . . . . . 12
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 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.
	skipping to change at page 3, line 50 ¶		skipping to change at page 4, line 4 ¶
	capitals, as shown here.		capitals, as shown here.
	3. Protocol Details		3. Protocol Details
	This section provides protocol details and contains the normative		This section provides protocol details and contains the normative
	parts.		parts.
	Before using this new optimization, the IPSec implementation who		Before using this new optimization, the IPSec implementation who
	supports it has to know that the peer also supports it. Without the		supports it has to know that the peer also supports it. Without the
	support on both sides, the optimized rekeying messages sent by one		support on both sides, the optimized rekeying messages sent by one
	peer may be unrecognizable for the other peer. To stop this failure		peer may be unrecognizable for the other peer. To prevent this
	from happening, the first step is to negotiate the support of this		failure from happening, the first step is to negotiate the support of
	optimization between the two peers. There are two specific rekeying		this optimization between the two peers. There are two specific
	SAs cases: rekeying IKE SAs and rekeying Child SAs. After the		rekeying SAs cases: rekeying IKE SAs and rekeying Child SAs. After
	negotiation, it's up to the initiator to decide at which case to		the negotiation, the initiator can optimize the rekeying message
	optimize the rekeying messages. The initiator can optimize the		payloads in both cases. In other words, once the negotiation of
	rekeying message payloads in both cases, or just in one case. The		support for optimizing payloads at rekeying IKE SAs and Child SAs is
	responder can react based on the received rekeying message.		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 Optional Payload at Rekeying		3.1. Negotiation of Support for Optimizing Optional Payload at Rekeying
	IKE SAs and Child SAs		IKE SAs and Child SAs
	The initiator indicates its support for optimizing optional payloads		The initiator indicates its support for optimizing optional payloads
	at rekeying IKE SAs and Child SAs by including a Notify payload of		at rekeying IKE SAs and Child SAs by including a Notify payload of
	type MINIMAL_REKEY_SUPPORTED in the IKE_AUTH request message. By		type 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
	skipping to change at page 5, line 14 ¶		skipping to change at page 5, line 22 ¶
	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. If the initiator
	decides to optimize the payloads at the time of rekeying IKE SAs,		decides to optimize the payloads at the time of rekeying IKE SAs,
	then it includes the SA_UNCHANGED notification in its CREATE_CHILD_SA		then it includes the SA_UNCHANGED notification in its CREATE_CHILD_SA
	exchange message. If the initiator decides not to do the		exchange message. If the initiator decides not to do the
	optimization, then it just sends the rekeying request message as the		optimization, then it just sends the rekeying request message as the
	original way, the rekeying is conducted as [RFC7296] defined.		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		3.2.1. Rekeying IKE SAs When No Change of Initiator and Responder's
	Cryptographic Suites		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 MAY send the SA_UNCHANGED notification
	payload instead of the SA payloads in the rekeying request message.		payload instead of the SA payloads in the rekeying request message.
	In this SA_UNCHANGED notification, it contains the initiator's new		In this SA_UNCHANGED notification, it contains the initiator's new
	Security Parameter Index (SPI) used for creating the new IKE SA.		Security Parameter Index (SPI) used for creating the new IKE SA.
	skipping to change at page 5, line 48 ¶		skipping to change at page 6, line 13 ¶
	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(SA_UNCHANGED), Ni, KEi} -->
	<-- HDR, SK {N(SA_UNCHANGED), Nr, KEr}		<-- HDR, SK {N(SA_UNCHANGED), Nr, KEr}
	The initiator sends a SA_UNCHANGED notification payload, a Nonce		The initiator sends a SA_UNCHANGED 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 SA_UNCHANGED
	notification payload.		notification payload. These messages also follow the original 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-		SA_UNCHANGED 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 SA_UNCHANGED notification payload.
	This SA_UNCHANGED notification MUST be included in a CREATE_CHILD_SA		This SA_UNCHANGED notification MUST be included in a CREATE_CHILD_SA
	exchange message when there is no SA payloads included. When the		exchange message when there is no SA payloads included. When the
	SA_UNCHANGED notification payload is included, the SA payload MUST		SA_UNCHANGED notification payload is included, the SA payload MUST
	NOT be included.		NOT be included.
	skipping to change at page 10, line 37 ¶		skipping to change at page 10, line 43 ¶
	IANA>, the value assigned for the SA_UNCHANGED notification.		IANA>, the value assigned for the SA_UNCHANGED notification.
	o SPI (8 octets) - Security Parameter Index. The initiator sends		o SPI (8 octets) - Security Parameter Index. The initiator sends
	initiator SPI. The responder sends responder SPI.		initiator SPI. The responder sends responder SPI.
	4.3. SA_TS_UNCHANGED Notification		4.3. SA_TS_UNCHANGED Notification
	The SA_TS_UNCHANGED notification is used to replace the SA payloads		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		and TS payloads at the time of rekeying Child SAs when there is no
	change of cryptographic suites and ACL configuration in initiator or		change of cryptographic suites and ACL configuration in initiator or
	responder. It is formatted as follows:		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
	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 (=4) | Notify Message Type |		|Protocol ID | SPI Size (=4) | Notify Message Type |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Security Parameter Index (SPI) |		| Security Parameter Index (SPI) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	skipping to change at page 12, line 15 ¶		skipping to change at page 12, line 32 ¶
	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
	Meduri S S Bharath
	Huawei Technologies
	Divyashree Techno Park, Whitefield
	Bangalore, Karnataka 560066
	India
	Email: MeduriS.Bharath@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
			Mavenir Systems Pvt Ltd
			Manyata Tech Park
			Bangalore, Karnataka
			India
			Email: bharath.meduri@mavenir.com
			Meiling Chen
			China Mobile
			32 Xuanwumen West Street, West District
			Beijing, Beijing 100053
			Email: chenmeiling@chinamobile.com
End of changes. 10 change blocks.
	26 lines changed or deleted		28 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/