< draft-smyslov-ipsecme-ikev2-r-mobike-00.txt		draft-smyslov-ipsecme-ikev2-r-mobike-01.txt >
	Network Working Group V. Smyslov		Network Working Group V. Smyslov
	Internet-Draft ELVIS-PLUS		Internet-Draft ELVIS-PLUS
	Updates: 4555, 6311 (if approved) May 30, 2017		Updates: 4555, 6311 (if approved) November 30, 2017
	Intended status: Standards Track		Intended status: Standards Track
	Expires: December 1, 2017		Expires: June 3, 2018
	Responder Initiated IP Addresses Update in MOBIKE		Responder Initiated IP Addresses Update in MOBIKE
	draft-smyslov-ipsecme-ikev2-r-mobike-00		draft-smyslov-ipsecme-ikev2-r-mobike-01
	Abstract		Abstract
	IKEv2 Mobility and Multihoming Protocol (MOBIKE) allows peers to		IKEv2 Mobility and Multihoming Protocol (MOBIKE) allows peers to
	update their IP addresses without re-establishing IKE and IPsec		update their IP addresses without re-establishing IKE and IPsec
	Security Associations (SAs). In the MOBIKE protocol it is the		Security Associations (SAs). In the MOBIKE protocol it is the
	Initiator of the IKE SA, who is responsible for selecting new SA		Initiator of the IKE SA, who is responsible for selecting new SA
	addresses and for initiating the IP addresses update procedure. This		addresses and for initiating the IP addresses update procedure. This
	document presents an extension to the MOBIKE protocol that allows the		document presents an extension to the MOBIKE protocol that allows the
	Responder to initiate the update.		Responder to initiate the update.
	skipping to change at page 1, line 37 ¶		skipping to change at page 1, line 37 ¶
	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 http://datatracker.ietf.org/drafts/current/.		Drafts is at http://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 December 1, 2017.		This Internet-Draft will expire on June 3, 2018.
	Copyright Notice		Copyright Notice
	Copyright (c) 2017 IETF Trust and the persons identified as the		Copyright (c) 2017 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
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://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 5, line 41 ¶		skipping to change at page 5, line 41 ¶
	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 take no action if it receives such a request (apart		Responder MUST take no action if it receives such a request (apart
	from sending an empty response message to complete the exchange).		from sending an empty response message to complete the 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		request and what new address to include into it. Some of the
	possible reasons are:		possible reasons are:
	o Responder's IP address is changed due to Network Interface Card
	(NIC) reconfiguration
	o Responder is multihomed and wishes to switch SA to a different IP		o Responder is multihomed and wishes to switch SA to a different IP
	address		address
	o Responder is a cluster and wishes to move SA to a different node		o Responder is a cluster and wishes to move SA to a different node
	having its own IP address		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. The notification data of this		notification SWITCH_TO_IP_ADDRESS. The notification data of this
	notification contains a new IP address the Responder requests the		notification contains a new IP address the Responder requests the
	skipping to change at page 7, line 44 ¶		skipping to change at page 7, line 44 ¶
	available.		available.
	If old SA address is unavailable and no alternative addresses were		If old SA address is unavailable and no alternative addresses were
	advertised before, then the IKE SA and all associated Child SAs MUST		advertised before, then the IKE SA and all associated Child SAs MUST
	be torn down. Otherwise the SA MAY be kept in an anticipation that		be torn down. Otherwise the SA MAY be kept in an anticipation that
	the Initiator after some time detects the old IP address failure		the Initiator after some time detects the old IP address failure
	itself and performs IP addresses update.		itself and performs IP addresses update.
	4.2.1. High Availability Cluster Scenario		4.2.1. High Availability Cluster Scenario
	In case the VPN gateway is a cluster consisting of several nodes each		In case a VPN gateway is a cluster consisting of several nodes each
	having its own IP address, both Load Sharing (LS) and High		having its own IP address, both Load Sharing (LS) and High
	Availability (HA) goals may be achieved. For the purposes of HA the		Availability (HA) goals may be achieved. For the purposes of HA all
	nodes share an IKE SA state while only one of them communicate with		the nodes share an IKE SA state while only one of them communicate
	the IKE SA peer at any given time. Of the active node fails, the		with an IKE SA peer at any given time. If an active node fails, the
	other nodes detect this fact and select a new active node for the SAs		other nodes detect this fact and select a new active node for the SAs
	the failed node served. The selected node must then instruct the		the failed node served. The selected node must then instruct the
	failed node peers to switch their SAs to a new IP address using this		failed node peers to switch their SAs to a new IP address using this
	specification.		specification.
	Since some exchanges might be in progress when the active node fails,		Since some exchanges might be in progress when the active node fails,
	some special measures must be taken to ensure that the IKE SA state		special measures must be taken to ensure that the IKE SA state is
	is synchronised between the new active cluster node and the client.		synchronised between the new active cluster node and the client.
	Protocol Support for High Availability of IKEv2/IPsec [RFC6311]		Protocol Support for High Availability of IKEv2/IPsec [RFC6311]
	describes the necessary measures. In particular, the new active node		describes the necessary measures. In particular, the new active node
	initiates the INFORMATIONAL exchange containing the		initiates the INFORMATIONAL exchange containing the
	IKEV2_MESSAGE_ID_SYNC notification and optionally the		IKEV2_MESSAGE_ID_SYNC notification and optionally the
	IPSEC_REPLAY_COUNTER_SYNC notification. [RFC6311] states that no		IPSEC_REPLAY_COUNTER_SYNC notification. [RFC6311] states that no
	other payload must be included in this exchange. However, in case		other payload must be included in this exchange. However, in case
	the IP address of the new active node differs from the IP address of		the IP address of the new active node differs from the IP address of
	the failed active node it is necessary to combine the		the failed active node it is necessary to combine the
	IKEV2_MESSAGE_ID_SYNC and the SWITCH_TO_IP_ADDRESS notifications in		IKEV2_MESSAGE_ID_SYNC and the SWITCH_TO_IP_ADDRESS notifications in
	one exchange. So, this specification updates [RFC6311] in this		one exchange. So, this specification updates [RFC6311] in this
	skipping to change at page 9, line 51 ¶		skipping to change at page 9, line 51 ¶
	Message Types - Status Types" registry:		Message Types - Status Types" registry:
	<TBA> SWITCH_TO_IP_ADDRESS		<TBA> SWITCH_TO_IP_ADDRESS
	8. References		8. References
	8.1. Normative References		8.1. 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-
	<http://www.rfc-editor.org/info/rfc2119>.		editor.org/info/rfc2119>.
	[RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol		[RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol
	(MOBIKE)", RFC 4555, DOI 10.17487/RFC4555, June 2006,		(MOBIKE)", RFC 4555, DOI 10.17487/RFC4555, June 2006,
	<http://www.rfc-editor.org/info/rfc4555>.		<https://www.rfc-editor.org/info/rfc4555>.
	[RFC6311] Singh, R., Ed., Kalyani, G., Nir, Y., Sheffer, Y., and D.		[RFC6311] Singh, R., Ed., Kalyani, G., Nir, Y., Sheffer, Y., and D.
	Zhang, "Protocol Support for High Availability of IKEv2/		Zhang, "Protocol Support for High Availability of IKEv2/
	IPsec", RFC 6311, DOI 10.17487/RFC6311, July 2011,		IPsec", RFC 6311, DOI 10.17487/RFC6311, July 2011,
	<http://www.rfc-editor.org/info/rfc6311>.		<https://www.rfc-editor.org/info/rfc6311>.
	[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, <http://www.rfc-editor.org/info/rfc7296>.		2014, <https://www.rfc-editor.org/info/rfc7296>.
	8.2. Informative References		8.2. Informative References
	[RFC5685] Devarapalli, V. and K. Weniger, "Redirect Mechanism for		[RFC5685] Devarapalli, V. and K. Weniger, "Redirect Mechanism for
	the Internet Key Exchange Protocol Version 2 (IKEv2)",		the Internet Key Exchange Protocol Version 2 (IKEv2)",
	RFC 5685, DOI 10.17487/RFC5685, November 2009,		RFC 5685, DOI 10.17487/RFC5685, November 2009,
	<http://www.rfc-editor.org/info/rfc5685>.		<https://www.rfc-editor.org/info/rfc5685>.
	[RFC7791] Migault, D., Ed. and V. Smyslov, "Cloning the IKE Security		[RFC7791] Migault, D., Ed. and V. Smyslov, "Cloning the IKE Security
	Association in the Internet Key Exchange Protocol Version		Association in the Internet Key Exchange Protocol Version
	2 (IKEv2)", RFC 7791, DOI 10.17487/RFC7791, March 2016,		2 (IKEv2)", RFC 7791, DOI 10.17487/RFC7791, March 2016,
	<http://www.rfc-editor.org/info/rfc7791>.		<https://www.rfc-editor.org/info/rfc7791>.
	Author's Address		Author's Address
	Valery Smyslov		Valery Smyslov
	ELVIS-PLUS		ELVIS-PLUS
	PO Box 81		PO Box 81
	Moscow (Zelenograd) 124460		Moscow (Zelenograd) 124460
	RU		Russian Federation
	Phone: +7 495 276 0211		Phone: +7 495 276 0211
	Email: svan@elvis.ru		Email: svan@elvis.ru
End of changes. 15 change blocks.
	21 lines changed or deleted		18 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/