< draft-smyslov-ipsecme-ikev2-r-mobike-07.txt		draft-smyslov-ipsecme-ikev2-r-mobike-08.txt >
	Network Working Group V. Smyslov		Network Working Group V. Smyslov
	Internet-Draft ELVIS-PLUS		Internet-Draft ELVIS-PLUS
	Updates: 4555 (if approved) November 30, 2020		Updates: 4555 (if approved) May 25, 2021
	Intended status: Standards Track		Intended status: Standards Track
	Expires: June 3, 2021		Expires: November 26, 2021
	Responder Initiated IP Addresses Update in MOBIKE		Responder Initiated IP Addresses Update in MOBIKE
	draft-smyslov-ipsecme-ikev2-r-mobike-07		draft-smyslov-ipsecme-ikev2-r-mobike-08
	Abstract		Abstract
	IKEv2 Mobility and Multihoming Protocol (MOBIKE), defined in		IKEv2 Mobility and Multihoming Protocol (MOBIKE), defined in
	[RFC4555] allows peers to update their IP addresses without re-		[RFC4555] allows peers to update their IP addresses without re-
	establishing IKE and IPsec Security Associations (SAs). In the		establishing IKE and IPsec Security Associations (SAs). In the
	MOBIKE protocol it is the Initiator of the IKE SA, who is responsible		MOBIKE protocol it is the initiator of the IKE SA, who is responsible
	for selecting new SA addresses and for initiating the IP addresses		for selecting new SA addresses and for initiating the IP addresses
	update procedure. This document presents an extension to the MOBIKE		update procedure. This document presents an extension to the MOBIKE
	protocol that allows the Responder to initiate IP address update.		protocol that allows the responder to initiate IP address update.
	The document updates [RFC4555].		The document updates [RFC4555].
	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 June 3, 2021.		This Internet-Draft will expire on November 26, 2021.
	Copyright Notice		Copyright Notice
	Copyright (c) 2020 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
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	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
	skipping to change at page 2, line 47 ¶		skipping to change at page 2, line 47 ¶
	IKEv2 functionality by allowing peers to dynamically change IP		IKEv2 functionality by allowing peers to dynamically change IP
	addresses of the established SAs without the need to re-establish		addresses of the established SAs without the need to re-establish
	these SAs.		these SAs.
	The main use case for the MOBIKE protocol is a remote access user		The main use case for the MOBIKE protocol is a remote access user
	that travels and moves from one IP address to another without re-		that travels and moves from one IP address to another without re-
	establishing existing SAs with the VPN gateway. However, the MOBIKE		establishing existing SAs with the VPN gateway. However, the MOBIKE
	also supports more complex scenarios when VPN gateway is multihomed		also supports more complex scenarios when VPN gateway is multihomed
	and its addresses may change over time.		and its addresses may change over time.
	In the MOBIKE it is the original Initiator of the IKE SA (e.g. the		In the MOBIKE it is the original initiator of the IKE SA (e.g. the
	remote access client) who is responsible for detecting the working IP		remote access client) who is responsible for detecting the working IP
	addresses pairs and for deciding which pair to use. In other words,		addresses pairs and for deciding which pair to use. In other words,
	the Responder (e.g. the VPN gateway) plays a passive role and could		the responder (e.g. the VPN gateway) plays a passive role and could
	neither initiate the IP address update process nor tell the Initiator		neither initiate the IP address update process nor tell the initiator
	which IP address is preferred to use. This limitation makes use of		which IP address is preferred to use. This limitation makes use of
	complex scenarios less efficient and decreases the value of MOBIKE		complex scenarios less efficient and decreases the value of MOBIKE
	protocol.		protocol.
	For example, if the VPN gateway is a load sharing cluster where each		For example, if the VPN gateway is a load sharing cluster where each
	node has its own IP address, then the cluster must be able to move SA		node has its own IP address, then the cluster must be able to move SA
	between nodes depending on their current load. Currently Redirect		between nodes depending on their current load. Currently Redirect
	Mechanism for IKEv2 [RFC5685] can accomplish this task, however it		Mechanism for IKEv2 [RFC5685] can accomplish this task, however it
	requires new IKE SA to be established, that is very inefficient.		requires new IKE SA to be established, that is very inefficient.
	Another possible solution is to use IKE SA Cloning along with the		Another possible solution is to use IKE SA Cloning along with the
	MOBIKE (see [RFC7791] for scenario description), but the limitation		MOBIKE (see [RFC7791] for scenario description), but the limitation
	of the MOBIKE protocol makes this problematic. Obviously, the client		of the MOBIKE protocol makes this problematic. Obviously, the client
	has insufficient information to select when and to which of cluster		has insufficient information to choose when and to which of cluster
	IP addresses to move an SA to and the VPN gateway has no means to		IP addresses to move an SA to and the VPN gateway has no means to
	provide the client with this information.		provide the client with this information.
	This specification extends the MOBIKE protocol by adding ability for		This specification extends the MOBIKE protocol by adding ability for
	the Responder to ask the Initiator for IP address update and to		the responder to ask the initiator for IP address update and to
	provide it with the new IP address to use.		provide it with the new IP address to use.
	2. Terminology and Notation		2. Terminology and 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", "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.
	In this document the term "Initiator" means the party who originally		In this document the term "initiator" means the party who originally
	initiated the first IKE SA (in a series of possibly several rekeyed		initiated the first IKE SA (in a series of possibly several rekeyed
	IKE SAs), and "Responder" means the other party. This is consistent		IKE SAs), and "responder" means the other party. This is consistent
	with a way these terms are used in [RFC4555]. Note, that in		with a way these terms are used in [RFC4555]. Note, that in
	[RFC7296] the terms "original initiator" and "original responder"		[RFC7296] the terms "original initiator" and "original responder"
	mean the party, who initiated (or responded to) the latest IKE SA in		mean the party, who initiated (or responded to) the latest IKE SA in
	a series of possibly several rekeyed IKE SAs.		a series of possibly several rekeyed IKE SAs.
	3. Protocol Overview		3. Protocol Overview
	The MOBIKE protocol is designed in such a way, that it is the IKE SA		The MOBIKE protocol is designed in such a way, that it is the IKE SA
	Initiator, who is responsible for performing the actions concerned		initiator, who is responsible for performing the actions concerned
	with the selecting of a working IP addresses pair and for initiating		with the selecting of a working IP addresses pair and for initiating
	an IP addresses update exchange. Usually the Initiator selects an IP		an IP addresses update exchange. Usually the initiator selects an IP
	addresses pair by periodically probing different pairs and choosing		addresses pair by periodically probing different pairs and choosing
	the working one. If several pairs work then the choice between them		the working one. If several pairs work then the choice between them
	is arbitrary. The Responder cannot influence the process of		is arbitrary. The responder cannot influence the process of
	selecting and cannot ask the client to immediately switch to a		selecting and cannot ask the client to immediately switch to a
	particular gateway's address. As a result the process of selection a		particular gateway's address. As a result the process of selection a
	new pair takes substantial time and may ends up with a suboptimal		new pair takes substantial time and may ends up with a suboptimal
	path.		path.
	Obviously, this limitation comes from the fact that there might be		Obviously, this limitation comes from the fact that there might be
	middleboxes on the path like Network Address Translators (NAT) or		middleboxes on the path like Network Address Translators (NAT) or
	firewalls, that might disallow IP packets to come from VPN gateway to		firewalls, that might disallow IP packets to come from VPN gateway to
	the client unless the client first contacts the VPN gateway. For		the client unless the client first contacts the VPN gateway. For
	example, the client might reside behind a dynamic NAT that creates a		example, the client might reside behind a dynamic NAT that creates a
	mapping when IP packet first come from the client to the gateway. If		mapping when IP packet first comes from the client to the gateway.
	the gateway tries to send an IP packet to the client from different		If the gateway tries to send an IP packet to the client from
	IP address, the packet would be dropped since the NAT box has no		different IP address, the packet would be dropped since the NAT box
	corresponding mapping.		has no corresponding mapping.
	This specification provides the following solution to the described		This specification provides the following solution to the described
	problem. When the Responder decides that its end of existing SA		problem. When the responder decides that its end of existing SA
	should be switched from its original IP address IP_R1 to a new		should be switched from its original IP address IP_R1 to a new IP
	address IP_R2, it initiates an INFORMATIONAL exchange containing a		address IP_R2, it initiates an INFORMATIONAL exchange containing a
	new notification SWITCH_TO_IP_ADDRESS, that contains IP_R2. Once the		new notification SWITCH_TO_IP_ADDRESS, that contains IP_R2. Once the
	Initiator completes an exchange containing SWITCH_TO_IP_ADDRESS		initiator completes an exchange containing SWITCH_TO_IP_ADDRESS
	notification, it immediately initiates standard MOBIKE procedure for		notification, it immediately initiates standard MOBIKE procedure for
	updating SA addresses by starting the INFORMATIONAL exchange		updating SA addresses by starting the INFORMATIONAL exchange
	containing UPDATE_SA_ADDRESSES notification.		containing UPDATE_SA_ADDRESSES notification.
	4. Protocol Description		4. Protocol Description
	4.1. Capability Advertising		4.1. Capability Advertising
	According to [RFC4555], the peers must exchange MOBIKE_SUPPORTED		According to [RFC4555], the peers must exchange MOBIKE_SUPPORTED
	notifications in the IKE_AUTH exchange before they can use the MOBIKE		notifications in the IKE_AUTH exchange before they can use the MOBIKE
	protocol. If the Initiator supports this specification and is		protocol. If the initiator supports this specification and is
	willing to use it, then it MUST include a single octet 0x52 ('R') in		willing to use it, then it MUST include a single octet 0x52 ('R') in
	the notification data of the MOBIKE_SUPPORTED notification sent to		the notification data of the MOBIKE_SUPPORTED notification sent to
	the Responder. There is no need for the Initiator to know whether		the responder. There is no need for the initiator to know whether
	the Responder supports this specification or not, so the		the responder supports this specification or not, so the
	MOBIKE_SUPPORTED notification sent by the Responder has an empty		MOBIKE_SUPPORTED notification sent by the responder has an empty
	notification data.		notification data.
	Note, that [RFC4555] specifies that MOBIKE_SUPPORTED notification		Note, that [RFC4555] specifies that MOBIKE_SUPPORTED notification
	must contains no data when sending and the content of the		must contains no data when sending and the content of the
	notification data must be ignored while parsing. So, if the		notification data must be ignored while parsing. So, if the
	Responder doesn't support this specification, it will just ignore the		responder doesn't support this specification, it will just ignore the
	content of the MOBIKE_SUPPORTED notification and will use MOBIKE		content of the MOBIKE_SUPPORTED notification and will use MOBIKE
	without this extension.		without this extension.
	(IP_I1:500 -> IP_R1:500)		(IP_I1:500 -> IP_R1:500) -->
	HDR, SAi1, KEi, Ni,		HDR, SAi1, KEi, Ni,
	N(NAT_DETECTION_SOURCE_IP),		N(NAT_DETECTION_SOURCE_IP),
	N(NAT_DETECTION_DESTINATION_IP) -->		N(NAT_DETECTION_DESTINATION_IP)
	<-- (IP_R1:500 -> IP_I1:500)		<-- (IP_R1:500 -> IP_I1:500)
	HDR, SAr1, KEr, Nr,		HDR, SAr1, KEr, Nr,
	N(NAT_DETECTION_SOURCE_IP),		N(NAT_DETECTION_SOURCE_IP),
	N(NAT_DETECTION_DESTINATION_IP)		N(NAT_DETECTION_DESTINATION_IP)
	(IP_I1:4500 -> IP_R1:4500)		(IP_I1:4500 -> IP_R1:4500) -->
	HDR, SK { IDi, CERT, AUTH,		HDR, SK { IDi, CERT, AUTH,
	SAi2, TSi, TSr,		SAi2, TSi, TSr,
	N(MOBIKE_SUPPORTED('R')) } -->		N(MOBIKE_SUPPORTED('R')) }
	<-- (IP_R1:4500 -> IP_I1:4500)		<-- (IP_R1:4500 -> IP_I1:4500)
	HDR, SK { IDr, CERT, AUTH,		HDR, SK { IDr, CERT, AUTH,
	SAr2, TSi, TSr,		SAr2, TSi, TSr,
	N(MOBIKE_SUPPORTED),		N(MOBIKE_SUPPORTED),
	N(ADDITIONAL_IP4_ADDRESS) }		N(ADDITIONAL_IP4_ADDRESS) }
	4.2. Responder Initiated IP Address Update		4.2. Responder Initiated IP Address Update
	If the Initiator advertised its support for this specification during		If the initiator advertised its support for this specification during
	the initial exchange as described in Section 4.1, then the Responder		the initial exchange as described in Section 4.1, then the responder
	is free to initiate IP Address Update request at any time. If the		is free to initiate IP Address Update request at any time. If the
	Initiator doesn't indicate its support for this extension, then the		initiator doesn't indicate its support for this extension, then the
	Responder MUST NOT initiate IP Address Update request. The IP		responder MUST NOT initiate IP Address Update request. The IP
	Address Update request NUST NOT be initiated by the Initiator, the		Address Update request NUST NOT be initiated by the initiator, the
	Responder MUST NOT take any action if it receives such a request		responder MUST NOT take any action if it receives such a request
	(apart from sending an empty response message to complete the		(apart from sending an empty response message to complete the
	exchange).		exchange).
	It is up to the Responder to decide when to initiate an IP Address		It is up to the responder to decide when to initiate an IP Address
	request and what new address to include into it. Some of the		Update request and what new address to include into it. Some of the
	possible reasons are:		possible reasons are:
	o Responder is multihomed and wishes to switch SA to a different IP		o the responder is multihomed and wishes to switch an SA to a
	address		different IP address
	o Responder is a cluster and wishes to move SA to a different node		o the responder is a cluster and wishes to move an SA to a different
	having its own IP address		node having its own IP address
	The Responder requests the Initiator to update SA Address by		The responder requests the initiator to update SA address by
	initiating the INFORMATIONAL exchange containing a new status type		initiating the INFORMATIONAL exchange containing a new status type
	notification SWITCH_TO_IP_ADDRESS. Its notification data contains a		notification SWITCH_TO_IP_ADDRESS. Its notification data contains a
	new IP address the Responder requests the Initiator to use for the		new IP address the responder requests the initiator to use for the
	IKE SA and its Child SAs. In the example below the SA was		IKE SA and its Child SAs. In the example below the SA was
	established using IP_I1 and IP_R1 addresses for the Initiator and		established using IP_I1 and IP_R1 addresses for the initiator and
	Responder respectively, and the Responder wishes to change the		responder respectively, and the responder wishes to change the
	address of its end of the SA to IP_R2. So, it initiates the		address of its end of the SA to IP_R2. So, it initiates the
	INFORMATIONAL exchange from IP_R1 address containing the		INFORMATIONAL exchange from IP_R1 address containing the
	SWITCH_TO_IP_ADDRESS notification with IP_R2 address.		SWITCH_TO_IP_ADDRESS notification with IP_R2 address.
	<-- (IP_R1:4500 -> IP_I1:4500)		<-- (IP_R1:4500 -> IP_I1:4500)
	HDR, SK { N(SWITCH_TO_IP_ADDRESS(IP_R2)) }		HDR, SK { N(SWITCH_TO_IP_ADDRESS(IP_R2)) }
	(IP_I1:4500 -> IP_R1:4500)		(IP_I1:4500 -> IP_R1:4500) -->
	HDR, SK {} -->		HDR, SK {}
	Upon receiving the SWITCH_TO_IP_ADDRESS notification the Initiator		Upon receiving the SWITCH_TO_IP_ADDRESS notification the initiator
	extracts its content and makes a decision whether the received IP		extracts its content and makes a decision whether the received IP
	address is appropriate for the SA. If the received IP address is		address is appropriate for the SA. If the received IP address is
	among the addresses previously received from the Responder in		among the addresses previously received from the responder in
	ADDITIONAL_IP4_ADDRESS or ADDITIONAL_IP6_ADDRESS notifications, then		ADDITIONAL_IP4_ADDRESS or ADDITIONAL_IP6_ADDRESS notifications, then
	it is definitely appropriate for the SA. Otherwise local policy must		it is appropriate for the SA. Otherwise local policy must be
	be consulted to decide whether the received IP is appropriate. If		consulted to decide whether the received IP is appropriate. If the
	the address is considered inappropriate, then the Initiator MUST		address is considered inappropriate, then the initiator MUST current
	current address. It is RECOMMENDED that the Initiator immediately		address. It is RECOMMENDED that the initiator immediately initiates
	initiates Liveness Check exchange to ensure that the Responder is		Liveness Check exchange to ensure that the responder is able to
	able to operate using its current address.		operate using its current address.
	If the Initiator makes a decision that the received address is		If the initiator makes a decision that the received address is
	appropriate the Initiator initiates an IP address update procedure		appropriate the initiator initiates an IP address update procedure
	according to the MOBIKE specification by sending an INFORMATIONAL		according to the MOBIKE specification by sending an INFORMATIONAL
	exchange request message containing the UPDATE_SA_ADDRESSES		exchange request message containing the UPDATE_SA_ADDRESSES
	notification. See [RFC4555] for details. As a result, the remote IP		notification. See [RFC4555] for details. As a result, the remote IP
	address of the SA is changed from IP_R1 to IP_R2. Note that only the		address of the SA is changed from IP_R1 to IP_R2. Note that only the
	IP address is changed, the port remains the same.		IP address is changed, the port remains the same.
	(IP_I1:4500 -> IP_R2:4500)		(IP_I1:4500 -> IP_R2:4500) -->
	HDR, SK { N(UPDATE_SA_ADDRESSES),		HDR, SK { N(UPDATE_SA_ADDRESSES),
	N(NAT_DETECTION_SOURCE_IP),		N(NAT_DETECTION_SOURCE_IP),
	N(NAT_DETECTION_DESTINATION_IP),		N(NAT_DETECTION_DESTINATION_IP),
	N(COOKIE2) } -->		N(COOKIE2) }
	<-- (IP_R2:4500 -> IP_I1:4500)		<-- (IP_R2:4500 -> IP_I1:4500)
	HDR, SK { N(NAT_DETECTION_SOURCE_IP),		HDR, SK { N(NAT_DETECTION_SOURCE_IP),
	N(NAT_DETECTION_DESTINATION_IP),		N(NAT_DETECTION_DESTINATION_IP),
	N(COOKIE2) }		N(COOKIE2) }
	The Responder MUST NOT change IP addresses of the SA until it		The responder MUST NOT change IP addresses of the SA until it
	receives the UPDATE_SA_ADDRESSES notification from the Initiator.		receives the UPDATE_SA_ADDRESSES notification from the initiator.
	5. Payload Formats		5. Payload Formats
	5.1. MOBIKE_SUPPORTED Notification		5.1. MOBIKE_SUPPORTED Notification
	The MOBIKE_SUPPORTED Notification is defined in [RFC4555],		The MOBIKE_SUPPORTED Notification is defined in [RFC4555],
	Section 4.2.1 with the Notify Message Type 16396. This definition		Section 4.2.1 with the Notify Message Type 16396. This definition
	requires the notification data to be empty while sending and to be		requires the notification data to be empty while sending and to be
	ignored when notification is received.		ignored when notification is received.
	This document updates the definition from [RFC4555]. Exchange		This document updates the definition from [RFC4555]. Exchange
	Initiator sets the notification data of the MOBIKE_SUPPORTED		initiator sets the notification data of the MOBIKE_SUPPORTED
	Notification to a single octet 0x52 ('R') to indicate that this		Notification to a single octet 0x52 ('R') to indicate that this
	specification is supported.		specification is supported.
	5.2. SWITCH_TO_IP_ADDRESS Notification		5.2. SWITCH_TO_IP_ADDRESS Notification
	The Notify Message Type for this notification is <TBA by IANA>. The		The Notify Message Type for this notification is <TBA by IANA>. The
	notification data contains new Responder's IP address.		notification data contains new responder's IP address.
	For IPv4, the notification data is 4 octets long and is defined as		For IPv4, the notification data is 4 octets long and is defined 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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| New Responder's IPv4 Address |		| New Responder's IPv4 Address |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
End of changes. 45 change blocks.
	74 lines changed or deleted		74 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/