draft-ietf-mobike-protocol-00.txt		draft-ietf-mobike-protocol-01.txt
	Network Working Group P. Eronen, Ed.		MOBIKE Working Group P. Eronen, Ed.
	Internet-Draft Nokia		Internet-Draft Nokia
	Expires: December 30, 2005 June 28, 2005		Expires: January 16, 2006 July 15, 2005
	IKEv2 Mobility and Multihoming Protocol (MOBIKE)		IKEv2 Mobility and Multihoming Protocol (MOBIKE)
	draft-ietf-mobike-protocol-00.txt		draft-ietf-mobike-protocol-01.txt
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		By submitting this Internet-Draft, each author represents that any
	applicable patent or other IPR claims of which he or she is aware		applicable patent or other IPR claims of which he or she is aware
	have been or will be disclosed, and any of which he or she becomes		have been or will be disclosed, and any of which he or she becomes
	aware will be disclosed, in accordance with Section 6 of BCP 79.		aware will be disclosed, in accordance with Section 6 of BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	skipping to change at page 1, line 33		skipping to change at page 1, line 33
	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."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on December 30, 2005.		This Internet-Draft will expire on January 16, 2006.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2005).		Copyright (C) The Internet Society (2005).
	Abstract		Abstract
	This document describes the MOBIKE protocol, a mobility and		This document describes the MOBIKE protocol, a mobility and
	multihoming extension to IKEv2. The purpose of MOBIKE is to update		multihoming extension to IKEv2. MOBIKE allows mobile and/or
	the (outer) IP addresses associated with IKE and IPsec Security		multihomed hosts to update the (outer) IP addresses associated with
	Associations (SAs). The main scenario for MOBIKE is making it		IKE and IPsec Security Associations (SAs). The main scenario for
	possible for a remote access VPN user to move from one address to		MOBIKE is making it possible for a remote access VPN user to move
	another without re-establishing all security associations with the		from one address to another while keeping the connection with the VPN
	VPN gateway.		gateway active.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . 3		1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.2 MOBIKE protocol overview . . . . . . . . . . . . . . . . . 4		1.2 MOBIKE protocol overview . . . . . . . . . . . . . . . . . 4
	1.3 Terminology . . . . . . . . . . . . . . . . . . . . . . . 5		1.3 Terminology and notations . . . . . . . . . . . . . . . . 5
	2. MOBIKE protocol exchanges . . . . . . . . . . . . . . . . . . 6		2. MOBIKE protocol exchanges . . . . . . . . . . . . . . . . . . 6
	2.1 Signaling support for MOBIKE . . . . . . . . . . . . . . . 6		2.1 Signaling support for MOBIKE . . . . . . . . . . . . . . . 6
	2.2 Additional addresses . . . . . . . . . . . . . . . . . . . 6		2.2 Additional addresses . . . . . . . . . . . . . . . . . . . 6
	2.3 Changing path of IPsec SAs . . . . . . . . . . . . . . . . 7		2.3 Changing addresses in IPsec SAs . . . . . . . . . . . . . 7
	2.4 Updating additional addresses . . . . . . . . . . . . . . 8		2.4 Updating additional addresses . . . . . . . . . . . . . . 9
	2.5 Path testing . . . . . . . . . . . . . . . . . . . . . . . 9		2.5 Path testing . . . . . . . . . . . . . . . . . . . . . . . 10
	2.6 Return routability check . . . . . . . . . . . . . . . . . 10		2.6 Return routability check . . . . . . . . . . . . . . . . . 11
	2.7 NAT prevention . . . . . . . . . . . . . . . . . . . . . . 11		2.7 NAT prevention . . . . . . . . . . . . . . . . . . . . . . 11
	3. Payload formats . . . . . . . . . . . . . . . . . . . . . . . 13		3. Payload formats . . . . . . . . . . . . . . . . . . . . . . . 13
	3.1 MOBIKE_SUPPORTED notification payload . . . . . . . . . . 13		3.1 MOBIKE_SUPPORTED notification payload . . . . . . . . . . 13
	3.2 ADDITIONAL_ADDRESS notification payload . . . . . . . . . 13		3.2 ADDITIONAL_IP4/6_ADDRESS notification payloads . . . . . . 13
	3.3 CHANGE_PATH notification payload . . . . . . . . . . . . . 13		3.3 UPDATE_SA_ADDRESSES notification payload . . . . . . . . . 13
	3.4 UNACCEPTABLE_PATH notification payload . . . . . . . . . . 13		3.4 UNACCEPTABLE_ADDRESSES notification payload . . . . . . . 13
	3.5 COOKIE2 notification payload . . . . . . . . . . . . . . . 14		3.5 COOKIE2 notification payload . . . . . . . . . . . . . . . 14
	3.6 NAT_PREVENTION notification payload . . . . . . . . . . . 14		3.6 NAT_PREVENTION notification payload . . . . . . . . . . . 14
	3.7 NAT_PREVENTED notification payload . . . . . . . . . . . . 14		3.7 NAT_PREVENTED notification payload . . . . . . . . . . . . 14
	4. Security considerations . . . . . . . . . . . . . . . . . . . 15		4. Security considerations . . . . . . . . . . . . . . . . . . . 15
	5. IANA considerations . . . . . . . . . . . . . . . . . . . . . 18		5. IANA considerations . . . . . . . . . . . . . . . . . . . . . 18
	6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18		6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18
	7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18		7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
	7.1 Normative references . . . . . . . . . . . . . . . . . . . 18		7.1 Normative references . . . . . . . . . . . . . . . . . . . 19
	7.2 Informative references . . . . . . . . . . . . . . . . . . 19		7.2 Informative references . . . . . . . . . . . . . . . . . . 19
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . 20		Author's Address . . . . . . . . . . . . . . . . . . . . . . . 20
	Intellectual Property and Copyright Statements . . . . . . . . 21		1. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 20
			Intellectual Property and Copyright Statements . . . . . . . . 22
	1. Introduction		1. Introduction
	1.1 Motivation		1.1 Motivation
	IKEv2 is used for performing mutual authentication and establishing		IKEv2 is used for performing mutual authentication and establishing
	and maintaining IPsec security associations (SAs). In the current		and maintaining IPsec security associations (SAs). In the current
	specifications, the IPsec and IKE SAs are created implicitly between		specifications, the IPsec and IKE SAs are created implicitly between
	the IP addresses that are used when the IKE_SA is established. These		the IP addresses that are used when the IKE_SA is established. These
	IP addresses are then used as the outer (tunnel header) addresses for		IP addresses are then used as the outer (tunnel header) addresses for
	tunnel mode IPsec packets. Currently, it is not possible to change		tunnel mode IPsec packets. Currently, it is not possible to change
	these addresses after the IKE_SA has been created.		these addresses after the IKE_SA has been created.
	There are scenarios where these IP addresses might change. One		There are scenarios where these IP addresses might change. One
	example is mobility: a host changes its point of network attachment,		example is mobility: a host changes its point of network attachment,
	and receives a new IP address. Another example is a multihoming host		and receives a new IP address. Another example is a multihoming host
	that would like to change to a different interface if, for instance,		that would like to change to a different interface if, for instance,
	the currently used address stops working for some reason.		the currently used address stops working for some reason.
	In some cases, the the problem can be solved by simply creating new		Although the problem can be solved by creating new IKE and IPsec SAs
	IKE and IPsec SAs after the IP address has changed. In static		when the addresses need to be changed, this may not be optimal for
	multihoming scenarios, it may even be possible to have several IKE		several reasons. In some cases, creating a new IKE_SA may require
	and IPsec SAs simultaneously, and perform some kind of dynamic		user interaction for authentication (entering a code from a token
	routing over them [RFC3884]. However, this can be problematic for		card, for instance). Creating new SAs often also involves expensive
	several reasons. Creating a new IKE_SA may require user interaction		calculations and possibly a large number of roundtrips. Due to these
	for authentication (entering a code from a token card, for instance).		reasons, a mechanism for updating the IP addresses of existing IKE
	Creating new SAs often also involves expensive calculations and		and IPsec SAs is needed. The MOBIKE protocol described in this
	possibly a large number of roundtrips. Due to these reasons, a		document provides such a mechanism.
	mechanism for updating the IP addresses of existing IKE and IPsec SAs
	is needed. The MOBIKE protocol described in this document provides
	such a mechanism.
	The main scenario for MOBIKE is making it possible for a remote		The main scenario for MOBIKE is making it possible for a remote
	access VPN user to move from one address to another without re-		access VPN user to move from one address to another without re-
	establishing all security associations with the VPN gateway. For		establishing all security associations with the VPN gateway. For
	instance, a user could start from fixed Ethernet in the office, and		instance, a user could start from fixed Ethernet in the office, and
	then disconnect the laptop and move to office wireless LAN. When		then disconnect the laptop and move to office wireless LAN. When
	leaving the office the laptop could start using GPRS, and switch to a		leaving the office the laptop could start using GPRS, and switch to a
	different wireless LAN when the user arrives home. MOBIKE updates		different wireless LAN when the user arrives home. MOBIKE updates
	only the outer (tunnel header) addresses of IPsec SAs, and the		only the outer (tunnel header) addresses of IPsec SAs, and the
	addresses and others traffic selectors used inside the tunnel stay		addresses and others traffic selectors used inside the tunnel stay
	unchanged. Thus, mobility can be (mostly) invisible to applications		unchanged. Thus, mobility can be (mostly) invisible to applications
	and their connections using the VPN.		and their connections using the VPN.
	More complex scenarios arise when the VPN gateway also has several		MOBIKE also supports more complex scenarios where the VPN gateway
	network interfaces: these interfaces could be connected to different		also has several network interfaces: these interfaces could be
	networks or ISPs, they may have may be a mix of IPv4 and IPv6		connected to different networks or ISPs, they may have may be a mix
	addresses, and the addresses may change over time. Furthermore, both		of IPv4 and IPv6 addresses, and the addresses may change over time.
	parties could be VPN gateways relaying traffic for other parties.		Furthermore, both parties could be VPN gateways relaying traffic for
			other parties.
	1.2 MOBIKE protocol overview		1.2 MOBIKE protocol overview
	Since MOBIKE allows both parties to have several addresses, this		Since MOBIKE allows both parties to have several addresses, this
	leads us to an important question: there are up to N*M pairs of IP		leads us to an important question: there are up to N*M pairs of IP
	addresses that could potentially be used. How to decide which of		addresses that could potentially be used. How to decide which of
	these pairs should be used? The decision has to take into account		these pairs should be used? The decision has to take into account
	several factors. First, the parties have may preferences about which		several factors. First, the parties have may preferences about which
	interface should be used, due to performance and cost reasons, for		interface should be used, due to performance and cost reasons, for
	instance. Second, the decision is constrained by the fact that some		instance. Second, the decision is constrained by the fact that some
	skipping to change at page 4, line 31		skipping to change at page 4, line 31
	the IPsec SAs, and collecting the information it needs to make this		the IPsec SAs, and collecting the information it needs to make this
	decision (such as determining which address pairs work or do not		decision (such as determining which address pairs work or do not
	work). The other party (the "gateway" in remote access VPN scenario)		work). The other party (the "gateway" in remote access VPN scenario)
	simply tells the initiator what addresses it has, but does not update		simply tells the initiator what addresses it has, but does not update
	the IPsec SAs until it receives a message from the initiator to do		the IPsec SAs until it receives a message from the initiator to do
	so.		so.
	Making the decision at the initiator is consistent with how normal		Making the decision at the initiator is consistent with how normal
	IKEv2 works: the initiator decides which addresses it uses when		IKEv2 works: the initiator decides which addresses it uses when
	contacting the responder. It also makes sense especially when the		contacting the responder. It also makes sense especially when the
	initiator is the mobile node: it is in better position to decide		initiator is the mobile node: it is in a better position to decide
	which of its network interfaces should be used for both upstream and		which of its network interfaces should be used for both upstream and
	downstream traffic.		downstream traffic.
	The details of exactly how the initiator makes the decision, what		The details of exactly how the initiator makes the decision, what
	information is used in making it, how the information is collected,		information is used in making it, how the information is collected,
	how preferences affect the decision, and when a decision needs to be		how preferences affect the decision, and when a decision needs to be
	changed, are largely beyond the scope of MOBIKE. This does not mean		changed, are largely beyond the scope of MOBIKE. This does not mean
	that these details are unimportant: on the contrary, they are likely		that these details are unimportant: on the contrary, they are likely
	to be crucial in any real system. However, MOBIKE is concerned with		to be crucial in any real system. However, MOBIKE is concerned with
	these details only to the extent that they are visible in IKEv2/IPsec		these details only to the extent that they are visible in IKEv2/IPsec
	skipping to change at page 5, line 22		skipping to change at page 5, line 22
	needed. However, if the party "outside" the NAT changes its IP		needed. However, if the party "outside" the NAT changes its IP
	address, it may no longer be able to send packets to the party		address, it may no longer be able to send packets to the party
	"behind" the NAT, since the packets may not (depending on the exact		"behind" the NAT, since the packets may not (depending on the exact
	type of NAT) match the NAT mapping state. Here MOBIKE assumes that		type of NAT) match the NAT mapping state. Here MOBIKE assumes that
	the initiator is the party "behind" the NAT, and does not fully		the initiator is the party "behind" the NAT, and does not fully
	support the case where the responder's addresses change when NATs are		support the case where the responder's addresses change when NATs are
	present.		present.
	Updating the addresses of IPsec SAs naturally has to take into		Updating the addresses of IPsec SAs naturally has to take into
	account several security considerations. MOBIKE includes two		account several security considerations. MOBIKE includes two
	features design to address these considerations. First, a "return		features designed to address these considerations. First, a "return
	routability" check can be used to verify the addresses provided by		routability" check can be used to verify the addresses provided by
	the peer. This makes it more difficult flood third parties with		the peer. This makes it more difficult to flood third parties with
	large amounts of traffic. Second, a "NAT prevention" feature ensures		large amounts of traffic. Second, a "NAT prevention" feature ensures
	that IP addresses have not been modified by NATs, IPv4/IPv6		that IP addresses have not been modified by NATs, IPv4/IPv6
	translation agents, or other similar devices. This feature is mainly		translation agents, or other similar devices. This feature is mainly
	intended for site-to-site VPNs where the administrators may know		intended for site-to-site VPNs where the administrators may know
	beforehand that NATs are not present, and thus any modification to		beforehand that NATs are not present, and thus any modification to
	the packet can be considered to be an attack.		the packet can be considered to be an attack.
	1.3 Terminology		1.3 Terminology and notations
			When messages containing IKEv2 payloads are shown, optional payloads
			are shown in brackets (for instance, "[FOO]"), and a plus sign
			indicates that a payload can be repeated one or more times (for
			instance, "FOO+").
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [KEYWORDS].		document are to be interpreted as described in [KEYWORDS].
	IPsec Security Association (SA)
	An ESP or AH Security Association.
	Path
	A particular combination of source IP address and destination IP
	address (note: this definition does not consider the route taken
	by the packets in the network).
	2. MOBIKE protocol exchanges		2. MOBIKE protocol exchanges
	2.1 Signaling support for MOBIKE		2.1 Signaling support for MOBIKE
	Implementations that wish to use MOBIKE for a particular IKE_SA MUST		Implementations that wish to use MOBIKE for a particular IKE_SA MUST
	include a MOBIKE_SUPPORTED notification in the IKE_SA_INIT request		include a MOBIKE_SUPPORTED notification in the IKE_SA_INIT request
	and response messages.		and response messages.
	Initiator Responder		Initiator Responder
	----------- -----------		----------- -----------
	HDR, SAi1, KEi, Ni,		HDR, SAi1, KEi, Ni,
	N(MOBIKE_SUPPORTED),		N(MOBIKE_SUPPORTED),
	[N(NAT_DETECTION_*)] -->		[N(NAT_DETECTION_SOURCE_IP)+,
			N(NAT_DETECTION_DESTINATION_IP)] -->
	<-- HDR, SAr1, KEr, Nr,		<-- HDR, SAr1, KEr, Nr,
	[N(NAT_DETECTION_*)],		[N(NAT_DETECTION_SOURCE_IP)+,
			N(NAT_DETECTION_DESTINATION_IP)]
	[CERTREQ],		[CERTREQ],
	N(MOBIKE_SUPPORTED)		N(MOBIKE_SUPPORTED)
	The MOBIKE_SUPPORTED notification payload is described in Section 3.		The MOBIKE_SUPPORTED notification payload is described in Section 3.
	2.2 Additional addresses		2.2 Additional addresses
	Both the initiator and responder MAY include one or more		Both the initiator and responder MAY include one or more
	ADDITIONAL_ADDRESS notification payloads in the IKE_AUTH exchange (in		ADDITIONAL_IP4_ADDRESS and/or ADDITIONAL_IP6_ADDRESS notification
	case of multiple IKE_AUTH exchanges, in the message containing the SA		payloads in the IKE_AUTH exchange (in case of multiple IKE_AUTH
	payload).		exchanges, in the message containing the SA payload).
	Initiator Responder		Initiator Responder
	----------- -----------		----------- -----------
	HDR, SK { IDi, [CERT], [IDr], AUTH,		HDR, SK { IDi, [CERT], [IDr], AUTH,
	[CP(CFG_REQUEST)]		[CP(CFG_REQUEST)]
	SAi2, TSi, TSr,		SAi2, TSi, TSr,
	[N(ADDITIONAL_ADDRESS)*] } -->		[N(ADDITIONAL_*_ADDRESS)+] -->
	<-- HDR, SK { IDr, [CERT], AUTH,		<-- HDR, SK { IDr, [CERT], AUTH,
	[CP(CFG_REPLY)],		[CP(CFG_REPLY)],
	SAr2, TSi, TSr,		SAr2, TSi, TSr,
	[N(ADDITIONAL_ADDRESS)*] }		[N(ADDITIONAL_*_ADDRESS)+] }
	The recipient stores this information, but no other action is taken		The recipient stores this information, but no other action is taken
	at this time.		at this time.
	2.3 Changing path of IPsec SAs		2.3 Changing addresses in IPsec SAs
	In MOBIKE, the initiator of the IKE_SA decides what addresses are		In MOBIKE, the initiator of the IKE_SA decides what addresses are
	used in the IPsec SAs. That is, the responder never updates any		used in the IPsec SAs. That is, the responder never updates any
	IPsec SAs without receiving an explicit CHANGE_PATH request from the		IPsec SAs without receiving an explicit UPDATE_SA_ADDRESSES request
	initiator. (As described below, the responder can, however, update		from the initiator. (As described below, the responder can, however,
	the IKE_SA in some circumstances.)		update the IKE_SA in some circumstances.)
	The description in this section assumes that the initiator has		The description in this section assumes that the initiator has
	already decided what the new addresses should be. How this decision		already decided what the new addresses should be. How this decision
	is made is beyond the scope of this specification. When this		is made is beyond the scope of this specification. When this
	decision has been made, the initiator		decision has been made, the initiator
	o Updates the IKE_SA and IPsec SAs with the new addresses, and sets		o Updates the IKE_SA and IPsec SAs with the new addresses, and sets
	the "pending_update" flag in the IKE_SA.		the "pending_update" flag in the IKE_SA.
	o If NAT Traversal is not enabled, and the responder supports NAT		o If NAT Traversal is not enabled, and the responder supports NAT
	Traversal (as indicated by NAT detection payloads in the		Traversal (as indicated by NAT detection payloads in the
	IKE_SA_INIT exchange), and the initiator either suspects or knows		IKE_SA_INIT exchange), and the initiator either suspects or knows
	that a NAT is likely to be present, enables NAT Traversal.		that a NAT is likely to be present, enables NAT Traversal.
			o If there are outstanding IKEv2 requests, continues retransmitting
			them using the addresses in the IKE_SA (the new addresses).
	o When the window size allows, sends an INFORMATIONAL request		o When the window size allows, sends an INFORMATIONAL request
	containing the CHANGE_PATH notification payload (which does not		containing the UPDATE_SA_ADDRESSES notification payload (which
	contain any data), and clears the "pending_update" flag.		does not contain any data), and clears the "pending_update" flag.
			(See Section 2.6 for description of the COOKIE2 notification.)
	Initiator Responder		Initiator Responder
	----------- -----------		----------- -----------
	HDR, SK { N(CHANGE_PATH),		HDR, SK { N(UPDATE_SA_ADDRESSES),
	N(COOKIE2),		N(COOKIE2),
	[N(NAT_DETECTION_*),]		[N(NAT_DETECTION_*_IP)],
	[N(NAT_PREVENTION)] } -->		[N(NAT_PREVENTION)] } -->
	o If a new address change occurs while waiting for the response,		o If a new address change occurs while waiting for the response,
	starts again from the first step (and ignores responses to this		starts again from the first step (and ignores responses to this
	CHANGE_PATH request).		UPDATE_SA_ADDRESSES request).
	Note that if the responder has NAT Traversal enabled, it can update		Note that if the responder has NAT Traversal enabled, it can update
	the addresses in both the IKE_SA and IPsec SAs as usual (if it		the addresses in both the IKE_SA and IPsec SAs as usual (if it
	implements the "SHOULD" from [IKEv2] Section 2.23.		implements the "SHOULD" from [IKEv2] Section 2.23).
	When processing an INFORMATIONAL request containing the CHANGE_PATH
	notification, the responder
	o Compares the Message ID with the latest_update_received counter in		When processing an INFORMATIONAL request containing the
	the IKE_SA. If latest_update_received is greater than the		UPDATE_SA_ADDRESSES notification, the responder
	received Message ID, the reply is sent as usual, but no other		o Determines whether it has already received a newer
	action is taken; otherwise, updates the latest_update_received		UPDATE_SA_ADDRESSES request than this one (if the responder uses a
	counter.		window size greater than one, it is possible that requests are
			received out of order). If it has, a response message is sent,
			but no other action is taken.
	o If the NAT_PREVENTION payload is present, processes it as		o If the NAT_PREVENTION payload is present, processes it as
	described in Section 2.7.		described in Section 2.7.
	o Checks that the (source IP address, destination IP address) pair		o Checks that the (source IP address, destination IP address) pair
	in the IP header is acceptable according to local policy. If it		in the IP header is acceptable according to local policy. If it
	is not, replies with "HDR, SK {N(COOKIE2), N(UNACCEPTABLE_PATH)}".		is not, replies with "HDR, SK {N(COOKIE2),
			N(UNACCEPTABLE_ADDRESSES)}".
	o Updates the IP addresses in the IKE_SA and IPsec SAs with the
	values from the IP header.
	o If NAT Traversal is supported and NAT detection payloads were		o Updates the IP addresses in the IKE_SA with the values from the IP
	included, enables or disables NAT Traversal.		header. (Using the address from the IP header is consistent with
			normal IKEv2, and allows IKEv2 to work with NATs without needing
			unilateral self-address fixing [UNSAF].)
	o Replies with an INFORMATIONAL response:		o Replies with an INFORMATIONAL response:
	Initiator Responder		Initiator Responder
	----------- -----------		----------- -----------
	<-- HDR, SK { N(COOKIE2),		<-- HDR, SK { N(COOKIE2),
	[N(NAT_DETECTION_*)] }		[N(NAT_DETECTION_*_IP)] }
			o If necessary, initiates a return routability check for the new
			initiator address (see Section 2.6) and waits for the check to
			finish..
			o Updates the IPsec SAs with the new addresses.
			o If NAT Traversal is supported and NAT detection payloads were
			included, enables or disables NAT Traversal.
	When the initiator receives the reply, it		When the initiator receives the reply, it
	o If the response contains the NAT_PREVENTED payload, processes it		o If the response contains the NAT_PREVENTED payload, processes it
	as described in Section 2.7.		as described in Section 2.7.
	o If the response contains an UNACCEPTABLE_PATH notification		o If the response contains an UNACCEPTABLE_ADDRESSES notification
	payload, the initiator MAY select another path and retry the		payload, the initiator MAY select another addresses and retry the
	exchange, keep on using the current path, or disconnect.		exchange, keep on using the current addresses, or disconnect.
	o If NAT Traversal is supported and NAT detection payloads were		o If NAT Traversal is supported and NAT detection payloads were
	included, enables or disables NAT Traversal.		included, enables or disables NAT Traversal.
	2.4 Updating additional addresses		2.4 Updating additional addresses
	As described in Section 2.2, both the initiator and responder can		As described in Section 2.2, both the initiator and responder can
	send a list of additional addresses (in addition to the one used for		send a list of additional addresses (in addition to the one used for
	IKE_SA_INIT/IKE_AUTH exchange) to the initiator in the IKE_AUTH		IKE_SA_INIT/IKE_AUTH exchange) to the initiator in the IKE_AUTH
	exchange. If this list of addresses changes, a new list can be sent		exchange. If this list of addresses changes, a new list can be sent
	in any INFORMATIONAL exchange request message.		in any INFORMATIONAL exchange request message.
	When the responder (of the original IKE_SA) receives an INFORMATIONAL		When the responder (of the original IKE_SA) receives an INFORMATIONAL
	request containing ADDITIONAL_ADDRESS payloads, it simply stores the		request containing ADDITIONAL_*_ADDRESS payloads, it simply stores
	information, but no other action is taken.		the information, but no other action is taken.
	Initiator Responder		Initiator Responder
	----------- -----------		----------- -----------
	HDR, SK { N(ADDITIONAL_ADDRESS)+,		HDR, SK { N(ADDITIONAL_*_ADDRESS)+,
	N(COOKIE2) } -->		N(COOKIE2) } -->
	<-- HDR, SK { N(COOKIE2) }		<-- HDR, SK { N(COOKIE2) }
	When the initiator receives an INFORMATIONAL request containing		When the initiator receives an INFORMATIONAL request containing
	ADDITIONAL_ADDRESS, it stores the information and also determines		ADDITIONAL_*_ADDRESS, it stores the information and also determines
	whether the currently used path needs to be changed (for instance, if		whether the currently used addresses need to be changed (for
	the currently used address is no longer included in the list); if it		instance, if the currently used address is no longer included in the
	does, the initiator proceeds as described in the previous section.		list); if it does, the initiator proceeds as described in
			Section 2.3.
	Initiator Responder		Initiator Responder
	----------- -----------		----------- -----------
	<-- HDR, SK { N(ADDITIONAL_ADDRESS)+,		<-- HDR, SK { N(ADDITIONAL_*_ADDRESS)+,
	N(COOKIE2) }		N(COOKIE2) }
	HDR, SK { N(COOKIE2) } -->		HDR, SK { N(COOKIE2) } -->
	If the implementation supports window sizes greater than one, it also		If the implementation supports window sizes greater than one, it also
	has to keep track of the Message ID of the latest update it has		has to keep track of the Message ID of the latest update it has
	received, to avoid the situation where new information is overwritten		received, to avoid the situation where new information is overwritten
	by older.		by older.
	There is one additional complication: when the responder wants to		There is one additional complication: when the responder wants to
	send a new additional address list, the currently used path may no		send a new additional address list, the currently used addresses may
	longer work. In this case, the responder uses the additional address		no longer work. In this case, the responder uses the additional
	list received from the initiator, the list of its own addresses, and,		address list received from the initiator, the list of its own
	if necessary, the path testing feature (see Section 2.5) to determine		addresses, and, if necessary, the path testing feature (see
	a path that works, updates the addresses in the IKE_SA (but not IPsec		Section 2.5) to determine a path that works, updates the addresses in
	SAs), and then sends the INFORMATIONAL request. This is the only		the IKE_SA (but not IPsec SAs), and then sends the INFORMATIONAL
	time the responder uses the additional address list received from the		request. This is the only time the responder uses the additional
	initiator.		address list received from the initiator.
	Note that both peers can have their own policies about what addresses		Note that both peers can have their own policies about what addresses
	or paths are acceptable to use. A minimal "mobile client" could have		are acceptable to use. A minimal "mobile client" could have a policy
	a policy that says that only the responder's address specified in		that says that only the responder's address specified in local
	local configuration is acceptable. This kind of client does not have		configuration is acceptable. This kind of client does not have to
	to send or process ADDITIONAL_ADDRESS notification payloads.		send or process ADDITIONAL_*_ADDRESS notification payloads.
	Similarly, a simple "VPN gateway" that has only a single address, and		Similarly, a simple "VPN gateway" that has only a single address, and
	is not going to change it, does not need to send or understand		is not going to change it, does not need to send or understand
	ADDITIONAL_ADDRESS notification payloads.		ADDITIONAL_*_ADDRESS notification payloads.
	2.5 Path testing		2.5 Path testing
	IKEv2 Dead Peer Detection allows the peers to detect if the currently		IKEv2 Dead Peer Detection allows the peers to detect if the currently
	used path has stopped working. However, if either of the peers has		used path has stopped working. However, if either of the peers has
	several addresses, DPD alone does not indicate which of the other		several addresses, DPD alone does not indicate which of the other
	paths might work. The path testing feature allows the parties to		paths might work. The path testing feature allows the parties to
	determine whether a particular path (pair of addresses) works,		determine whether a particular path (pair of addresses) works,
	without yet committing to changing over to these addresses.		without yet committing to changing over to these addresses.
	MOBIKE introduces a new IKEv2 exchange type, PATH_TEST, for testing		MOBIKE introduces a new IKEv2 exchange type, PATH_TEST, for testing
	connectivity. This exchange is not part of any IKE_SA, so it is not		connectivity. This exchange is not part of any IKE_SA, so it is not
	cryptographically protected. It also does not result in the		cryptographically protected. It also does not result in the
	responder keeping any state.		responder keeping any state.
	Initiator Responder		Initiator Responder
	----------- -----------		----------- -----------
	HDR(0,0), N(COOKIE2),		HDR(0,0), N(COOKIE2),
	[N(NAT_DETECTION_*)] -->		[N(NAT_DETECTION_*_IP)] -->
	<-- HDR(0,0), N(COOKIE2),		<-- HDR(0,0), N(COOKIE2),
	[N(NAT_DETECTION_*)]		[N(NAT_DETECTION_*_IP)]
	The reason for introducing a new exchange type, instead of using		The reason for introducing a new exchange type, instead of using
	INFORMATIONAL exchanges, is to simplify implementations by allowing		INFORMATIONAL exchanges, is to simplify implementations by allowing
	MOBIKE to work with window size 1.		MOBIKE to work with window size 1.
	Performing path testing over several different paths is not required		Performing path testing over several different paths is not required
	if the node has other information that enables it to select which		if the node has other information that enables it to select which
	path should be used. Also, responders do not perform path testing		path should be used. Also, responders do not perform path testing
	unless they update their list of additional addresses (as described		unless they update their list of additional addresses (as described
	in the previous section). Implementations MAY do path testing even		in Section 2.4). Implementations MAY do path testing even if the
	if the currently used path is working to e.g. detect when a better		currently used path is working to e.g. detect when a better but
	but previously unavailable path becomes available, or to speed up		previously unavailable path becomes available, or to speed up
	recovery in fault situations.		recovery in fault situations.
	Implementations that perform path testing MUST take steps to avoid		Implementations that perform path testing MUST take steps to avoid
	causing unnecessary congestion. TBD: add some more details here.		causing unnecessary congestion. TBD: add some more details here.
	2.6 Return routability check		2.6 Return routability check
	Both the initiator and the responder can optionally verify that the		Both the initiator and the responder can optionally verify that the
	other party can actually receive packets at the claimed address.		other party can actually receive packets at the claimed address.
	This "return routability check" can be done before updating the IPsec		This "return routability check" MAY be done before updating the IPsec
	SAs, immediately after updating them, or continuously during the		SAs, immediately after updating them, or continuously during the
	connection.		connection.
	By default, return routability check SHOULD be done before updating		By default, return routability check SHOULD be done before updating
	the IPsec SAs. In environments where the peer is expected to be		the IPsec SAs. In environments where the peer is expected to be
	well-behaving (many corporate VPNs, for instance), or the address can		well-behaving (many corporate VPNs, for instance), or the address can
	be verified by some other means (e.g., the address is included in the		be verified by some other means (e.g., the address is included in the
	peer's certificate), the return routability check MAY be skipped or		peer's certificate), the return routability check MAY be skipped or
	postponed until after the IPsec SAs have been updated.		postponed until after the IPsec SAs have been updated.
	skipping to change at page 11, line 20		skipping to change at page 11, line 35
	To ensure that the peer cannot generate the correct INFORMATIONAL		To ensure that the peer cannot generate the correct INFORMATIONAL
	response without seeing the request, a new payload is added to all		response without seeing the request, a new payload is added to all
	INFORMATIONAL messages. The sender of an INFORMATIONAL request MUST		INFORMATIONAL messages. The sender of an INFORMATIONAL request MUST
	include a COOKIE2 notification payload, and the recipient of an		include a COOKIE2 notification payload, and the recipient of an
	INFORMATIONAL request MUST copy the payload as-is to the response.		INFORMATIONAL request MUST copy the payload as-is to the response.
	When processing the response, the original sender MUST verify that		When processing the response, the original sender MUST verify that
	the value is the same one as sent. If the values do not match, the		the value is the same one as sent. If the values do not match, the
	IKE_SA MUST be closed.		IKE_SA MUST be closed.
	There is one additional issue that must be taken into account. If		There is one additional issue that must be taken into account. If
	the destination address in the IKE_SA has been updated after the		the INFORMATIONAL request has been sent to several different
	INFORMATIONAL request was sent, then it is possible that the request		addresses (i.e., the destination address in the IKE_SA has been
	has been sent to several different addresses. In this case,		updated after the request was first sent), receiving the
	receiving the INFORMATIONAL response does not tell which address is		INFORMATIONAL response does not tell which address is the working
	the working one; thus, a new INFORMATIONAL request needs to be sent.		one. In this case, a new INFORMATIONAL request needs to be sent to
			check return routability.
	2.7 NAT prevention		2.7 NAT prevention
	IKEv2/IPsec implementations that do not support NAT Traversal can, in		IKEv2/IPsec implementations that do not support NAT Traversal can, in
	fact, work across some types of one-to-one "basic" NATs and IPv4/IPv6		fact, work across some types of one-to-one "basic" NATs and IPv4/IPv6
	translation agents in tunnel mode. This may be considered a problem		translation agents in tunnel mode. This may be considered a problem
	in some circumstances, since in some sense any modification of the IP		in some circumstances, since in some sense any modification of the IP
	addresses can be considered to be an attack.		addresses can be considered to be an attack.
	The "NAT prevention" feature allows both the initiator and responder		The "NAT prevention" feature allows both the initiator and responder
	skipping to change at page 11, line 51		skipping to change at page 12, line 18
	This specification addresses the issue as follows. When an IPsec SA		This specification addresses the issue as follows. When an IPsec SA
	is created, the tunnel header IP addresses (and port if doing UDP		is created, the tunnel header IP addresses (and port if doing UDP
	encapsulation) are taken from the IKE_SA, not the message IP header.		encapsulation) are taken from the IKE_SA, not the message IP header.
	The NAT_PREVENTION payload is used to guarantee that NATs have not		The NAT_PREVENTION payload is used to guarantee that NATs have not
	modified the address used in IKE_SA. However, all response messages		modified the address used in IKE_SA. However, all response messages
	are still sent to the address and port the corresponding request came		are still sent to the address and port the corresponding request came
	from.		from.
	The initiator MAY include a NAT_PREVENTION payload in an IKE_SA_INIT		The initiator MAY include a NAT_PREVENTION payload in an IKE_SA_INIT
	request. The responder MUST compare the NAT_PREVENTION payload with		request. The responder then MUST calculate the expected value based
	the values from the IP header. If they do not match, the responder		on the values from the IP header, and compare this with the value in
			the NAT_PREVENTION payload. If they do not match, the responder
	replies with "HDR(A,0), N(NAT_PREVENTED)" and does not create any		replies with "HDR(A,0), N(NAT_PREVENTED)" and does not create any
	state.		state.
	If the values do match, the responder initializes (local_address,		If the values do match, the responder initializes (local_address,
	local_port, peer_address, peer_port) in the to-be-created IKE_SA with		local_port, peer_address, peer_port) in the to-be-created IKE_SA with
	values from the IP header. The same applies if neither		values from the IP header. The same applies if neither
	NAT_PREVENTION nor NAT_DETECTION_*_IP payloads were included, or if		NAT_PREVENTION nor NAT_DETECTION_*_IP payloads were included, or if
	the responder does not support NAT Traversal.		the responder does not support NAT Traversal.
	If the IKE_SA_INIT request included NAT_DETECTION_*_IP payloads but		If the IKE_SA_INIT request included NAT_DETECTION_*_IP payloads but
	no NAT_PREVENTION payload, the situation is different since the		no NAT_PREVENTION payload, the situation is different since the
	initiator may at this point change from port 500 to 4500. In this		initiator may at this point change from port 500 to 4500. In this
	case, the responder initializes (local_address, local_port,		case, the responder initializes (local_address, local_port,
	peer_address, peer_port) from the first IKE_AUTH request. It may		peer_address, peer_port) from the first IKE_AUTH request.
	also decide to perform a return routability check soon after the
	IKE_AUTH exchanges have been completed.
	IKEv2 requires that if an IPsec endpoint discovers a NAT between it		IKEv2 requires that if an IPsec endpoint discovers a NAT between it
	and its correspondent, it MUST send all subsequent traffic to and		and its correspondent, it MUST send all subsequent traffic to and
	from port 4500. To simplify things, implementations that support		from port 4500. To simplify things, implementations that support
	both this specification and NAT Traversal MUST change to port 4500 if		both this specification and NAT Traversal MUST change to port 4500 if
	the correspondent also supports both, even if no NAT was detected		the correspondent also supports both, even if no NAT was detected
	between them.		between them.
	NAT_PREVENTION payloads can also be included when changing the path		NAT_PREVENTION payloads can also be included when changing the
	of IPsec SAs (see Section 2.3). TBD: add better description.		addresses of IPsec SAs (see Section 2.3). TBD: add better
			description.
	3. Payload formats		3. Payload formats
	3.1 MOBIKE_SUPPORTED notification payload		3.1 MOBIKE_SUPPORTED notification payload
	The MOBIKE_SUPPORTED notification payload is included in the		The MOBIKE_SUPPORTED notification payload is included in the
	IKE_SA_INIT messages to indicate that the implementation supports		IKE_SA_INIT messages to indicate that the implementation supports
	this specification.		this specification.
	The Notify Message Type for MOBIKE_SUPPORTED is TBD-BY-IANA		The Notify Message Type for MOBIKE_SUPPORTED is TBD-BY-IANA
	(16396..40959). The Protocol ID field is set to one (1), and SPI		(16396..40959). The Protocol ID and SPI Size fields are set to zero.
	Size is set to zero. There is no data associated with this Notify		There is no data associated with this Notify type.
	type.
	3.2 ADDITIONAL_ADDRESS notification payload		3.2 ADDITIONAL_IP4/6_ADDRESS notification payloads
	Both initiator and responder can include ADDITIONAL_ADDRESS payloads		Both initiator and responder can include ADDITIONAL_IP4_ADDRESS
	in the IKE_AUTH exchange and INFORMATIONAL exchange request messages;		and/or ADDITIONAL_IP6_ADDRESS payloads in the IKE_AUTH exchange and
	see Section 2.2 and Section 2.4 for more detailed description.		INFORMATIONAL exchange request messages; see Section 2.2 and
			Section 2.4 for more detailed description.
	The Notify Message Type for ADDITIONAL_ADDRESS is TBD-BY-IANA		The Notify Message Types for ADDITIONAL_IP4_ADDRESS and
	(16396..40959). The Protocol ID field is set to one (1), and SPI		ADDITIONAL_IP6_ADDRESS are TBD-BY-IANA (16396..40959) and TBD-BY-IANA
	Size is set to zero. The data associated with this Notify type is		(16396..40959), respectively. The Protocol ID and SPI Size fields
	either an IPv4 address or an IPv6 address; the type is determined by		are set to zero. The data associated with these Notify types is
	the payload length.		either a four-octet IPv4 address or a 16-octet IPv6 address.
	3.3 CHANGE_PATH notification payload		3.3 UPDATE_SA_ADDRESSES notification payload
	This payload is included in INFORMATIONAL exchange requests sent by		This payload is included in INFORMATIONAL exchange requests sent by
	the initiator of the IKE_SA to update addresses of the IKE_SA and		the initiator of the IKE_SA to update addresses of the IKE_SA and
	IPsec SAs (see Section 2.3).		IPsec SAs (see Section 2.3).
	The Notify Message Type for CHANGE_PATH is TBD-BY-IANA		The Notify Message Type for UPDATE_SA_ADDRESSES is TBD-BY-IANA
	(16396..40959). The Protocol ID field is set to one (1), and SPI		(16396..40959). The Protocol ID and SPI Size fields are set to zero.
	Size is set to zero. There is no data associated with this Notify		There is no data associated with this Notify type.
	type.
	3.4 UNACCEPTABLE_PATH notification payload		3.4 UNACCEPTABLE_ADDRESSES notification payload
	The responder can include this notification payload in an		The responder can include this notification payload in an
	INFORMATIONAL exchange response to indicate that the address change		INFORMATIONAL exchange response to indicate that the address change
	in the corresponding request message (which contained a CHANGE_PATH		in the corresponding request message (which contained an
	notification payload) was not carried out.		UPDATE_SA_ADDRESSES notification payload) was not carried out.
	The Notify Message Type for UNACCEPTABLE_PATH is TBD-BY-IANA		The Notify Message Type for UNACCEPTABLE_ADDRESSES is TBD-BY-IANA
	(40..8191). The Protocol ID field is set to one (1), and SPI Size is		(40..8191). The Protocol ID and SPI Size fields are set to zero.
	set to zero. There is no data associated with this Notify type.		There is no data associated with this Notify type.
	3.5 COOKIE2 notification payload		3.5 COOKIE2 notification payload
	This payload is included in all INFORMATIONAL exchange messages for		This payload is included in all INFORMATIONAL exchange messages for
	return routability check purposes (see Section 2.6). It is also used		return routability check purposes (see Section 2.6). It is also used
	in PATH_TEST messages to match requests and responses (see		in PATH_TEST messages to match requests and responses (see
	Section 2.5).		Section 2.5).
	The data associated with this notification MUST be between 8 and 64		The data associated with this notification MUST be between 8 and 64
	octets in length (inclusive), and MUST be chosen in a way that is		octets in length (inclusive), and MUST be chosen in a way that is
	unpredictable to the recipient. The Notify Message Type for this		unpredictable to the recipient. The Notify Message Type for this
	message is TBD-BY-IANA (16396..40959). The Protocol ID field is set		message is TBD-BY-IANA (16396..40959). The Protocol ID and SPI Size
	to one (1), and SPI Size is set to zero.		fields are set to zero.
	3.6 NAT_PREVENTION notification payload		3.6 NAT_PREVENTION notification payload
	See Section 2.7 for a description of this payload.		See Section 2.7 for a description of this payload.
	The data associated with this notification is the SHA-1 hash		The data associated with this notification is the SHA-1 hash
	[FIPS180-2] of the following data: IKE SPIs (in the order they appear		[FIPS180-2] of the following data: IKE SPIs (in the order they appear
	in the header), the IP address and port from which the packet was		in the header), the IP address and port from which the packet was
	sent, and the IP address and port to which the packet was sent. The		sent, and the IP address and port to which the packet was sent. The
	Notify Message Type for this message is TBD-BY-IANA (16396..40959).		Notify Message Type for this message is TBD-BY-IANA (16396..40959).
	The Protocol ID field is set to one (1), and SPI Size is set to zero.		The Protocol ID and SPI Size fields are set to zero.
	3.7 NAT_PREVENTED notification payload		3.7 NAT_PREVENTED notification payload
	See Section 2.7 for a description of this payload.		See Section 2.7 for a description of this payload.
	The Notify Message Type for NAT_PREVENTED is TBD-BY-IANA (40..8191).		The Notify Message Type for NAT_PREVENTED is TBD-BY-IANA (40..8191).
	The Protocol ID field is set to one (1), and SPI Size is set to zero.		The Protocol ID and SPI Size fields are set to zero. There is no
	There is no data associated with this Notify type.		data associated with this Notify type.
	4. Security considerations		4. Security considerations
	The main goals of this specification are to not reduce the security		The main goals of this specification are to not reduce the security
	offered by usual IKEv2 procedures and to counter mobility related		offered by usual IKEv2 procedures and to counter mobility related
	threats in an appropriate manner. In some specific cases MOBIKE is		threats in an appropriate manner. In some specific cases MOBIKE is
	also capable of protecting address changes better than existing NAT		also capable of protecting address changes better than existing NAT
	Traversal procedures.		Traversal procedures.
	The threats arising in scenarios targeted by MOBIKE are:		The threats arising in scenarios targeted by MOBIKE are:
	Traffic redirection and hijacking		Traffic redirection and hijacking
	Insecure mobility management mechanisms may allow inappropriate		Insecure mobility management mechanisms may allow inappropriate
	redirection of traffic. This may allow inspection of the traffic		redirection of traffic. This may allow inspection of the
	as well as man-in-the-middle and session hijacking attacks.		traffic as well as man-in-the-middle and session hijacking
			attacks.
	The scope of these attacks in the MOBIKE case is limited, as all		The scope of these attacks in the MOBIKE case is limited, as
	traffic is protected using IPsec. However, it should be observed		all traffic is protected using IPsec. However, it should be
	that security associations originally created for the protection		observed that security associations originally created for the
	of a specific flow between specific addresses may be moved through		protection of a specific flow between specific addresses may be
	MOBIKE. The level of required protection may be different in a		moved through MOBIKE. The level of required protection may be
	new location of a VPN client, for instance.		different in a new location of a VPN client, for instance.
	Third-party denial-of-service through flooding		Third-party denial-of-service through flooding
	Traffic redirection may be performed not just to gain access to		Traffic redirection may be performed not just to gain access to
	the traffic, but also to cause a denial-of-service attack for a		the traffic, but also to cause a denial-of-service attack for a
	third party. For instance, a high-speed TCP session or a		third party. For instance, a high-speed TCP session or a
	multimedia stream may be redirected towards a victim host, causing		multimedia stream may be redirected towards a victim host,
	its communications capabilities to suffer.		causing its communications capabilities to suffer.
	The attackers in this threat can be either outsiders or even one		The attackers in this threat can be either outsiders or even
	of the participants. In usual VPN usage scenarios attacks by		one of the participants. In usual VPN usage scenarios attacks
	participants can be easily dealt with. However, this requires		by participants can be easily dealt with. However, this
	that strong authentication was performed in the initial IKEv2		requires that strong authentication was performed in the
	negotiation. This may not be the case in all scenarios,		initial IKEv2 negotiation. This may not be the case in all
	particularly with opportunistic approaches to security.		scenarios, particularly with opportunistic approaches to
			security.
	Normally such attacks would expire in a short time frame due to		Normally such attacks would expire in a short time frame due to
	the lack of responses (such as transport layer acknowledgements)		the lack of responses (such as transport layer
	from the victim. However, as described in [Aura02], malicious		acknowledgements) from the victim. However, as described in
	participants would typically be able to spoof such		[Aura02], malicious participants would typically be able to
	acknowledgements and maintain the traffic flow for an extended		spoof such acknowledgements and maintain the traffic flow for
	period of time. For instance, if the attacker opened the TCP		an extended period of time. For instance, if the attacker
	stream itself before redirecting it to the victim, the attacker		opened the TCP stream itself before redirecting it to the
	becomes aware of the sequence number space used in this particular		victim, the attacker becomes aware of the sequence number space
	session.		used in this particular session.
	It should also be noted, as shown in [Bombing], that without		It should also be noted, as shown in [Bombing], that without
	ingress filtering in the attacker's network such attacks are		ingress filtering in the attacker's network such attacks are
	already possible simply by sending spoofed packets from the		already possible simply by sending spoofed packets from the
	attacker to the victim directly. Consequently, it makes little		attacker to the victim directly. Consequently, it makes little
	sense to protect against attacks of similar nature in MOBIKE.		sense to protect against attacks of similar nature in MOBIKE.
	However, it still makes sense to limit the amplification		However, it still makes sense to limit the amplification
	capabilities provided to attackers, so that they cannot use stream		capabilities provided to attackers, so that they cannot use
	redirection to send 1000 packets to the victim by sending just a		stream redirection to send 1000 packets to the victim by
	few packets themselves.		sending just a few packets themselves.
	Note that a variant of the flooding attack exists in IKEv2 NAT		Note that a variant of the flooding attack exists in IKEv2 NAT
	Traversal functionality [PseudoNAT]. In this variant, the		Traversal functionality [PseudoNAT]. In this variant, the
	attacker has to be on the path between the participants, changing		attacker has to be on the path between the participants,
	the addresses in the packets that pass by. This attack is		changing the addresses in the packets that pass by. This
	possible because the addresses in the outer headers are not		attack is possible because the addresses in the outer headers
	protected. When the attacker leaves the path, the correct		are not protected. When the attacker leaves the path, the
	situation is restored after the exchange of the next packets		correct situation is restored after the exchange of the next
	between the participants.		packets between the participants.
	Spoofing indications related to network connectivity		Spoofing indications related to network connectivity
	Attackers may also spoof various indications from lower layers and		Attackers may also spoof various indications from lower layers
	the network in an effort to confuse the peers about which		and the network in an effort to confuse the peers about which
	addresses are or are not working. For example, attackers may		addresses are or are not working. For example, attackers may
	spoof ICMP error messages in an effort to cause the parties to		spoof ICMP error messages in an effort to cause the parties to
	move their traffic elsewhere or even to disconnect. Attackers may		move their traffic elsewhere or even to disconnect. Attackers
	also spoof information related to network attachments, router		may also spoof information related to network attachments,
	discovery, and address assignments in an effort to make the		router discovery, and address assignments in an effort to make
	parties believe they have Internet connectivity when in reality		the parties believe they have Internet connectivity when in
	they do not.		reality they do not.
	This may cause use of non-preferred addresses or even denial-of-		This may cause use of non-preferred addresses or even denial-
	service.		of-service.
	Denial-of-service of the participants through MOBIKE		Denial-of-service of the participants through MOBIKE
	Inappropriate MOBIKE protocol mechanisms might make it possible		Inappropriate MOBIKE protocol mechanisms might make it possible
	for attackers to disconnect the participants, or to move them to		for attackers to disconnect the participants, or to move them
	non-operational addresses.		to non-operational addresses.
	MOBIKE addresses these threats using the following countermeasures:		MOBIKE addresses these threats using the following countermeasures:
	Payload traffic protection		Payload traffic protection
	The use of IPsec protection on payload traffic protects the		The use of IPsec protection on payload traffic protects the
	participants against disclosure of the contents of the traffic,		participants against disclosure of the contents of the traffic,
	should the traffic end up in an incorrect destination. It is		should the traffic end up in an incorrect destination. It is
	recommended that security policies be configured in a manner that		recommended that security policies be configured in a manner
	takes into account that a single security association can be used		that takes into account that a single security association can
	through different paths at different times.		be used through different paths at different times.
	Protection of MOBIKE payloads		Protection of MOBIKE payloads
	The payloads used in MOBIKE are encrypted, integrity protected,		The payloads used in MOBIKE are encrypted, integrity protected,
	and replay protected. This assures that no one except the		and replay protected. This assures that no one except the
	participants can, for instance, give a control message to change		participants can, for instance, give a control message to
	the addresses.		change the addresses.
	Note, however, that the actual IP address communicated in these		Note, however, that the actual IP address communicated in these
	messages is in the outer IP header and not protected, just as in		messages is in the outer IP header and not protected, just as
	IKEv2 NAT Traversal. MOBIKE adds the NAT_PREVENTION payload,		in IKEv2 NAT Traversal. MOBIKE adds the NAT_PREVENTION
	however, which can be used to prevent modifications by outsiders.		payload, however, which can be used to prevent modifications by
	Where this payload is used, communication through NATs and other		outsiders. Where this payload is used, communication through
	address translators is impossible, however. This feature is		NATs and other address translators is impossible, however.
	mainly intended for site-to-site VPN cases, where the		This feature is mainly intended for site-to-site VPN cases,
	administrators may know beforehand that NATs are not present, and		where the administrators may know beforehand that NATs are not
	thus any modification to the packet can be considered to be an		present, and thus any modification to the packet can be
	attack.		considered to be an attack.
	Explicit address change		Explicit address change
	MOBIKE allows only address changes that are explicitly requested.		MOBIKE allows only address changes that are explicitly
	This provides additional security beyond to what IKEv2 NAT		requested. This provides additional security beyond to what
	Traversal has, but it should be noted that the benefits of this		IKEv2 NAT Traversal has, but it should be noted that the
	can only be realized when MOBIKE is used without intervening NATs		benefits of this can only be realized when MOBIKE is used
	and NAT Traversal.		without intervening NATs and NAT Traversal.
	When NAT Traversal is supported, the peer's address may be updated		When NAT Traversal is supported, the peer's address may be
	automatically to allow changes in NAT mappings. The "continued		updated automatically to allow changes in NAT mappings. The
	return routability" feature, implemented by the COOKIE2 payload,		"continued return routability" feature, implemented by the
	allows verification of the new address after the change. This		COOKIE2 payload, allows verification of the new address after
	limits the duration of any "third party bombing" attack by off-		the change. This limits the duration of any "third party
	path (relative to the victim) attackers.		bombing" attack by off-path (relative to the victim) attackers.
	Return routability tests		Return routability tests
	This specification requires the use of return routability tests		This specification requires the use of return routability tests
	(under certain conditions) to ensure that third party flooding		(under certain conditions) to ensure that third party flooding
	attacks are prevented. The tests are authenticated messages that		attacks are prevented. The tests are authenticated messages
	the peer has to respond to in order for the address change to be		that the peer has to respond to in order for the address change
	committed to. The tests contain unpredictable data, and can only		to be committed to. The tests contain unpredictable data, and
	be properly responded to by someone who has the keys associated		can only be properly responded to by someone who has the keys
	with the IKEv2 security association and who has seen the request		associated with the IKEv2 security association and who has seen
	packet for the test.		the request packet for the test.
	MOBIKE does not provide any protection of its own for indications		MOBIKE does not provide any protection of its own for indications
	from other parts of the protocol stack. However, MOBIKE is resistant		from other parts of the protocol stack. However, MOBIKE is resistant
	to incorrect information from these sources in the sense that it		to incorrect information from these sources in the sense that it
	provides its own security for both the signaling of addressing		provides its own security for both the signaling of addressing
	information as well as actual payload data transmission. Denial-of-		information as well as actual payload data transmission. Denial-of-
	service vulnerabilities remain, however. Some aspects of these		service vulnerabilities remain, however. Some aspects of these
	vulnerabilities can be mitigated through the use of techniques		vulnerabilities can be mitigated through the use of techniques
	specific to the other parts of the stack, such as properly dealing		specific to the other parts of the stack, such as properly dealing
	with ICMP errors [ICMPAttacks], link layer security, or the use of		with ICMP errors [ICMPAttacks], link layer security, or the use of
	skipping to change at page 20, line 6		skipping to change at page 20, line 20
	[MOPO] Eronen, P., "Mobility Protocol Options for IKEv2 (MOPO-		[MOPO] Eronen, P., "Mobility Protocol Options for IKEv2 (MOPO-
	IKE)", draft-eronen-mobike-mopo-02 (work in progress),		IKE)", draft-eronen-mobike-mopo-02 (work in progress),
	February 2005.		February 2005.
	[PseudoNAT]		[PseudoNAT]
	Dupont, F. and J-J. Bernard, "Transient pseudo-NAT attacks		Dupont, F. and J-J. Bernard, "Transient pseudo-NAT attacks
	or how NATs are even more evil than you believed",		or how NATs are even more evil than you believed",
	draft-dupont-transient-pseudonat-04 (expired) (work in		draft-dupont-transient-pseudonat-04 (expired) (work in
	progress), June 2004.		progress), June 2004.
	[RFC3884] Touch, J., Eggert, L., and Y. Wang, "Use of IPsec
	Transport Mode for Dynamic Routing", RFC 3884,
	September 2004.
	[SEND] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure		[SEND] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
	Neighbor Discovery (SEND)", RFC 3971, March 2005.		Neighbor Discovery (SEND)", RFC 3971, March 2005.
	[SMOBIKE] Eronen, P. and H. Tschofenig, "Simple Mobility and		[SMOBIKE] Eronen, P. and H. Tschofenig, "Simple Mobility and
	Multihoming Extensions for IKEv2 (SMOBIKE)",		Multihoming Extensions for IKEv2 (SMOBIKE)",
	draft-eronen-mobike-simple-00 (work in progress),		draft-eronen-mobike-simple-00 (work in progress),
	March 2004.		March 2004.
			[UNSAF] Daigle, L., "IAB Considerations for UNilateral Self-
			Address Fixing (UNSAF) Across Network Address
			Translation", RFC 3424, November 2002.
	Author's Address		Author's Address
	Pasi Eronen (editor)		Pasi Eronen (editor)
	Nokia Research Center		Nokia Research Center
	P.O. Box 407		P.O. Box 407
	FIN-00045 Nokia Group		FIN-00045 Nokia Group
	Finland		Finland
	Email: pasi.eronen@nokia.com		Email: pasi.eronen@nokia.com
			1. Changelog
			(This section should be removed by the RFC editor.)
			Changes from -00 to -01:
			o Editorial fixes and small clarifications (issues 21, 25, 26, 29).
			o Use Protocol ID zero for notifications (issue 30).
			o Separate ADDITIONAL_*_ADDRESS payloads for IPv4 and IPv6 (issue
			23).
			o Use the word "path" only in senses that include the route taken
			(issue 29).
	Intellectual Property Statement		Intellectual Property Statement
	The IETF takes no position regarding the validity or scope of any		The IETF takes no position regarding the validity or scope of any
	Intellectual Property Rights or other rights that might be claimed to		Intellectual Property Rights or other rights that might be claimed to
	pertain to the implementation or use of the technology described in		pertain to the implementation or use of the technology described in
	this document or the extent to which any license under such rights		this document or the extent to which any license under such rights
	might or might not be available; nor does it represent that it has		might or might not be available; nor does it represent that it has
	made any independent effort to identify any such rights. Information		made any independent effort to identify any such rights. Information
	on the procedures with respect to rights in RFC documents can be		on the procedures with respect to rights in RFC documents can be
	found in BCP 78 and BCP 79.		found in BCP 78 and BCP 79.
End of changes.
This html diff was produced by rfcdiff 1.25, available from http://www.levkowetz.com/ietf/tools/rfcdiff/