draft-ietf-mobike-protocol-06.txt		draft-ietf-mobike-protocol-07.txt
	MOBIKE Working Group P. Eronen, Ed.		MOBIKE Working Group P. Eronen, Ed.
	Internet-Draft Nokia		Internet-Draft Nokia
	Expires: May 20, 2006 November 16, 2005		Expires: June 23, 2006 December 20, 2005
	IKEv2 Mobility and Multihoming Protocol (MOBIKE)		IKEv2 Mobility and Multihoming Protocol (MOBIKE)
	draft-ietf-mobike-protocol-06.txt		draft-ietf-mobike-protocol-07.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 May 20, 2006.		This Internet-Draft will expire on June 23, 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 Internet Key Exchange (IKEv2). MOBIKE		multihoming extension to Internet Key Exchange (IKEv2). MOBIKE
	allows hosts to update the (outer) IP addresses associated with IKEv2		allows the IP addresses associated with IKEv2 and tunnel mode IPsec
	and tunnel mode IPsec Security Associations. A mobile VPN client		Security Associations to change. A mobile VPN client could use
	could use MOBIKE to keep the connection with the VPN gateway active		MOBIKE to keep the connection with the VPN gateway active while
	while moving from one address to another. Similarly, a multihomed		moving from one address to another. Similarly, a multihomed host
	host could use MOBIKE to move the traffic to a different interface		could use MOBIKE to move the traffic to a different interface if, for
	if, for instance, the one currently being used stops working.		instance, the one currently being used stops working.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
	1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 4		1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 4
	1.2. Scope and Limitations . . . . . . . . . . . . . . . . . . 5		1.2. Scope and Limitations . . . . . . . . . . . . . . . . . . 5
	1.3. Terminology and Notation . . . . . . . . . . . . . . . . . 5		1.3. Terminology and Notation . . . . . . . . . . . . . . . . . 5
	2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 6		2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 6
	2.1. Basic Operation . . . . . . . . . . . . . . . . . . . . . 6		2.1. Basic Operation . . . . . . . . . . . . . . . . . . . . . 6
	2.2. Example Protocol Runs . . . . . . . . . . . . . . . . . . 7		2.2. Example Protocol Runs . . . . . . . . . . . . . . . . . . 7
	2.3. MOBIKE and Network Address Translation (NAT) . . . . . . . 10		2.3. MOBIKE and Network Address Translation (NAT) . . . . . . . 10
	3. Protocol Exchanges . . . . . . . . . . . . . . . . . . . . . . 11		3. Protocol Exchanges . . . . . . . . . . . . . . . . . . . . . . 11
	3.1. Initial IKE Exchange . . . . . . . . . . . . . . . . . . . 11		3.1. Initial IKE Exchange . . . . . . . . . . . . . . . . . . . 11
	3.2. Signaling Support for MOBIKE . . . . . . . . . . . . . . . 11		3.2. Signaling Support for MOBIKE . . . . . . . . . . . . . . . 11
	3.3. Initial Tunnel Header Addresses . . . . . . . . . . . . . 11		3.3. Initial Tunnel Header Addresses . . . . . . . . . . . . . 12
	3.4. Additional Addresses . . . . . . . . . . . . . . . . . . . 12		3.4. Additional Addresses . . . . . . . . . . . . . . . . . . . 12
	3.5. Changing Addresses in IPsec SAs . . . . . . . . . . . . . 13		3.5. Changing Addresses in IPsec SAs . . . . . . . . . . . . . 13
	3.6. Updating Additional Addresses . . . . . . . . . . . . . . 16		3.6. Updating Additional Addresses . . . . . . . . . . . . . . 16
	3.7. Return Routability Check . . . . . . . . . . . . . . . . . 17		3.7. Return Routability Check . . . . . . . . . . . . . . . . . 18
	3.8. Changes in NAT Mappings . . . . . . . . . . . . . . . . . 18		3.8. Changes in NAT Mappings . . . . . . . . . . . . . . . . . 18
	3.9. NAT Prohibition . . . . . . . . . . . . . . . . . . . . . 19		3.9. NAT Prohibition . . . . . . . . . . . . . . . . . . . . . 19
	3.10. Path Testing . . . . . . . . . . . . . . . . . . . . . . . 20		3.10. Path Testing . . . . . . . . . . . . . . . . . . . . . . . 20
	3.11. Failure Recovery and Timeouts . . . . . . . . . . . . . . 20		3.11. Failure Recovery and Timeouts . . . . . . . . . . . . . . 21
	3.12. Dead Peer Detection . . . . . . . . . . . . . . . . . . . 20		3.12. Dead Peer Detection . . . . . . . . . . . . . . . . . . . 21
	4. Payload Formats . . . . . . . . . . . . . . . . . . . . . . . 21		4. Payload Formats . . . . . . . . . . . . . . . . . . . . . . . 22
	4.1. Notify Messages - Error Types . . . . . . . . . . . . . . 21		4.1. Notify Messages - Error Types . . . . . . . . . . . . . . 22
	4.1.1. UNACCEPTABLE_ADDRESSES Notify Payload . . . . . . . . 21		4.1.1. UNACCEPTABLE_ADDRESSES Notify Payload . . . . . . . . 22
	4.1.2. UNEXPECTED_NAT_DETECTED Notify Payload . . . . . . . . 21		4.1.2. UNEXPECTED_NAT_DETECTED Notify Payload . . . . . . . . 22
	4.2. Notify Messages - Status Types . . . . . . . . . . . . . . 21		4.2. Notify Messages - Status Types . . . . . . . . . . . . . . 22
	4.2.1. MOBIKE_SUPPORTED Notify Payload . . . . . . . . . . . 21		4.2.1. MOBIKE_SUPPORTED Notify Payload . . . . . . . . . . . 22
	4.2.2. ADDITIONAL_IP4/6_ADDRESS Notify Payloads . . . . . . . 21		4.2.2. ADDITIONAL_IP4_ADDRESS and ADDITIONAL_IP6_ADDRESS
	4.2.3. NO_ADDITIONAL_ADDRESSES Notify Payload . . . . . . . . 22		Notify Payloads . . . . . . . . . . . . . . . . . . . 22
	4.2.4. UPDATE_SA_ADDRESSES Notify Payload . . . . . . . . . . 22		4.2.3. NO_ADDITIONAL_ADDRESSES Notify Payload . . . . . . . . 23
	4.2.5. COOKIE2 Notify Payload . . . . . . . . . . . . . . . . 22		4.2.4. UPDATE_SA_ADDRESSES Notify Payload . . . . . . . . . . 23
	4.2.6. NO_NATS_ALLOWED Notify Payload . . . . . . . . . . . . 22		4.2.5. COOKIE2 Notify Payload . . . . . . . . . . . . . . . . 23
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 24		4.2.6. NO_NATS_ALLOWED Notify Payload . . . . . . . . . . . . 23
	5.1. Traffic Redirection and Hijacking . . . . . . . . . . . . 24		5. Security Considerations . . . . . . . . . . . . . . . . . . . 25
	5.2. IPsec Payload Protection . . . . . . . . . . . . . . . . . 24		5.1. Traffic Redirection and Hijacking . . . . . . . . . . . . 25
	5.3. Denial-of-Service Attacks Against Third Parties . . . . . 25		5.2. IPsec Payload Protection . . . . . . . . . . . . . . . . . 25
	5.4. Spoofing Network Connectivity Indications . . . . . . . . 26		5.3. Denial-of-Service Attacks Against Third Parties . . . . . 26
	5.5. Address and Topology Disclosure . . . . . . . . . . . . . 26		5.4. Spoofing Network Connectivity Indications . . . . . . . . 27
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27		5.5. Address and Topology Disclosure . . . . . . . . . . . . . 27
	7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28		7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29
	8.1. Normative References . . . . . . . . . . . . . . . . . . . 28		8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
	8.2. Informative References . . . . . . . . . . . . . . . . . . 29		8.1. Normative References . . . . . . . . . . . . . . . . . . . 29
	Appendix A. Implementation Considerations . . . . . . . . . . . . 30		8.2. Informative References . . . . . . . . . . . . . . . . . . 30
	A.1. Links from SPD Cache to Outbound SAD Entries . . . . . . . 30		Appendix A. Implementation Considerations . . . . . . . . . . . . 31
	A.2. Creating Outbound SAs . . . . . . . . . . . . . . . . . . 31		A.1. Links from SPD Cache to Outbound SAD Entries . . . . . . . 31
	Appendix B. Changelog . . . . . . . . . . . . . . . . . . . . . . 32		A.2. Creating Outbound SAs . . . . . . . . . . . . . . . . . . 32
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 35		Appendix B. Changelog . . . . . . . . . . . . . . . . . . . . . . 33
	Intellectual Property and Copyright Statements . . . . . . . . . . 36		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 36
			Intellectual Property and Copyright Statements . . . . . . . . . . 37
	1. Introduction		1. Introduction
	1.1. Motivation		1.1. Motivation
	IKEv2 is used for performing mutual authentication, as well as		IKEv2 is used for performing mutual authentication, as well as
	establishing and maintaining IPsec Security Associations (SAs). In		establishing and maintaining IPsec Security Associations (SAs). In
	the base IKEv2 protocol, the IPsec and IKE SAs are created implicitly		the base IKEv2 protocol, the IPsec and IKE SAs are created implicitly
	between the IP addresses that are used when the IKE_SA is		between the IP addresses that are used when the IKE_SA is
	established. These IP addresses are then used as the outer (tunnel		established. These IP addresses are then used as the outer (tunnel
	skipping to change at page 4, line 28		skipping to change at page 4, line 28
	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 interface stops working for some reason.		the currently used interface stops working for some reason.
	Although the problem can be solved by creating new IKE and IPsec SAs		Although the problem can be solved by creating new IKE and IPsec SAs
	when the addresses need to be changed, this may not be optimal for		when the addresses need to be changed, this may not be optimal for
	several reasons. In some cases, creating a new IKE_SA may require		several reasons. In some cases, creating a new IKE_SA may require
	user interaction for authentication, such as entering a code from a		user interaction for authentication, such as entering a code from a
	token card. Creating new SAs often also involves expensive		token card. Creating new SAs often involves expensive calculations
	calculations and possibly a large number of round-trips. For these		and possibly a large number of round-trips. For these reasons, a
	reasons, a mechanism for updating the IP addresses of existing IKE		mechanism for updating the IP addresses of existing IKE and IPsec SAs
	and IPsec SAs is needed. The MOBIKE protocol described in this		is needed. The MOBIKE protocol described in this document provides
	document provides such a mechanism.		such a mechanism.
	The main scenario for MOBIKE is enabling a remote access VPN user to		The main scenario for MOBIKE is enabling a remote access VPN user to
	move from one address to another without re-establishing all security		move from one address to another without re-establishing all security
	associations with the VPN gateway. For instance, a user could start		associations with the VPN gateway. For instance, a user could start
	from fixed Ethernet in the office and then disconnect the laptop and		from fixed Ethernet in the office and then disconnect the laptop and
	move to the office's wireless LAN. When leaving the office the		move to the office's wireless LAN. When leaving the office the
	laptop could start using GPRS; when the user arrives home, the laptop		laptop could start using GPRS; when the user arrives home, the laptop
	could switch the the home wireless LAN. MOBIKE updates only the		could switch the the home wireless LAN. MOBIKE updates only the
	outer (tunnel header) addresses of IPsec SAs, and the addresses and		outer (tunnel header) addresses of IPsec SAs, and the addresses and
	other traffic selectors used inside the tunnel stay unchanged. Thus,		other traffic selectors used inside the tunnel stay unchanged. Thus,
	skipping to change at page 5, line 13		skipping to change at page 5, line 13
	other parties.		other parties.
	1.2. Scope and Limitations		1.2. Scope and Limitations
	This document focuses on the main scenario outlined above, and		This document focuses on the main scenario outlined above, and
	supports only tunnel mode IPsec SAs.		supports only tunnel mode IPsec SAs.
	The mobility support in MOBIKE allows both parties to move, but does		The mobility support in MOBIKE allows both parties to move, but does
	not provide a "rendezvous" mechanism that would allow simultaneous		not provide a "rendezvous" mechanism that would allow simultaneous
	movement of both parties, or discovering the addresses when the		movement of both parties, or discovering the addresses when the
	IKE_SA is first established. This implies that MOBIKE is best suited		IKE_SA is first established. Therefore, MOBIKE is best suited for
	for situations where the address of at least one endpoint is		situations where the address of at least one endpoint is relatively
	relatively stable, and can be discovered using existing mechanisms		stable, and can be discovered using existing mechanisms such as DNS
	such as DNS (see Section 3.1).		(see Section 3.1).
	MOBIKE allows both parties to be multihomed; however, only one pair		MOBIKE allows both parties to be multihomed; however, only one pair
	of addresses is used for an SA at a time. In particular, load		of addresses is used for an SA at a time. In particular, load
	balancing is beyond the scope of this specification.		balancing is beyond the scope of this specification.
	MOBIKE follows the IKEv2 practice where a response message is sent to		MOBIKE follows the IKEv2 practice where a response message is sent to
	the same address and port from which the request was received. This		the same address and port from which the request was received. This
	implies that MOBIKE does not work over address pairs that provide		implies that MOBIKE does not work over address pairs that provide
	only unidirectional connectivity.		only unidirectional connectivity.
	NATs introduce additional limitations beyond those listed above. For		NATs introduce additional limitations beyond those listed above. For
	details, refer to Section 2.3.		details, refer to Section 2.3.
	The base version of the MOBIKE protocol does not cover all potential		The base version of the MOBIKE protocol does not cover all potential
	future use scenarios, such as transport mode, application to securing		future use scenarios, such as transport mode, application to securing
	SCTP, or optimizations desirable in specific circumstances. Future		SCTP, or optimizations desirable in specific circumstances. Future
	extensions may be defined later to support additional requirements.		extensions may be defined later to support additional requirements.
			Please consult the MOBIKE design document [Design] for further
	Readers are encouraged to consult the MOBIKE design document [Design]		information and rationale behind these limitations.
	for further information and rationale behind these limitations.
	1.3. Terminology and Notation		1.3. Terminology and Notation
	When messages containing IKEv2 payloads are described, optional		When messages containing IKEv2 payloads are described, optional
	payloads are shown in brackets (for instance, "[FOO]"), and a plus		payloads are shown in brackets (for instance, "[FOO]"), and a plus
	sign indicates that a payload can be repeated one or more times (for		sign indicates that a payload can be repeated one or more times (for
	instance, "FOO+"). To provide context, some diagrams also show what		instance, "FOO+"). To provide context, some diagrams also show what
	existing IKEv2 payloads would typically be included in the exchanges.		existing IKEv2 payloads would typically be included in the exchanges.
	These payloads are shown for illustrative purposes only; see [IKEv2]		These payloads are shown for illustrative purposes only; see [IKEv2]
	for an authoritative description.		for an authoritative description.
	skipping to change at page 7, line 17		skipping to change at page 7, line 16
	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
	messages exchanged between the peers (and thus need to be		messages exchanged between the peers (and thus need to be
	standardized to ensure interoperability).		standardized to ensure interoperability).
	Also, many of these issues are not specific to MOBIKE, but are common		Many of these issues are not specific to MOBIKE, but are common with
	with the use of existing hosts in dynamic environments or with		the use of existing hosts in dynamic environments or with mobility
	mobility protocols such as Mobile IP [MIP4] [MIP6]. A number of		protocols such as Mobile IP [MIP4] [MIP6]. A number of mechanisms
	mechanisms already exist or are being developed to deal with these		already exist or are being developed to deal with these issues. For
	issues. For instance, link layer and IP layer mechanisms can be used		instance, link layer and IP layer mechanisms can be used to track the
	to track the status of connectivity within the local link [RFC2461];		status of connectivity within the local link [RFC2461]; movement
	movement detection is being specified for both IPv4 and IPv6 in		detection is being specified for both IPv4 and IPv6 in [DNA4],
	[DNA4], [DNA6], and so on.		[DNA6], and so on.
	Naturally, updating the addresses of IPsec SAs has to take into		Naturally, updating the addresses of IPsec SAs has to take into
	account several security considerations. MOBIKE includes two		account several security considerations. MOBIKE includes two
	features designed 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 to flood third parties with		the peer. This makes it more difficult to flood third parties with
	large amounts of traffic. Second, a "NAT prohibition" feature		large amounts of traffic. Second, a "NAT prohibition" feature
	ensures that IP addresses have not been modified by NATs, IPv4/IPv6		ensures that IP addresses have not been modified by NATs, IPv4/IPv6
	translation agents, or other similar devices. This feature is		translation agents, or other similar devices. This feature is
	enabled only when NAT Traversal is not used.		enabled only when NAT Traversal is not used.
	2.2. Example Protocol Runs		2.2. Example Protocol Runs
	A simple MOBIKE exchange in a mobile scenario is illustrated below:		A simple MOBIKE exchange in a mobile scenario is illustrated below:
	Initiator Responder		Initiator Responder
	----------- -----------		----------- -----------
	1) (IP_I1:500 -> IP_R1:500)		1) (IP_I1:500 -> IP_R1:500)
	HDR, SAi1, KEi, Ni,		HDR, SAi1, KEi, Ni,
	N(NAT_DETECTION_*_IP) -->		N(NAT_DETECTION_SOURCE_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_*_IP)		N(NAT_DETECTION_SOURCE_IP),
			N(NAT_DETECTION_DESTINATION_IP)
	2) (IP_I1:4500 -> IP_R1:4500)		2) (IP_I1:4500 -> IP_R1:4500)
	HDR, SK { IDi, CERT, AUTH,		HDR, SK { IDi, CERT, AUTH,
	CP(CFG_REQUEST),		CP(CFG_REQUEST),
	SAi2, TSi, TSr,		SAi2, TSi, TSr,
	N(MOBIKE_SUPPORTED) } -->		N(MOBIKE_SUPPORTED) } -->
	<-- (IP_R1:4500 -> IP_I1:4500)		<-- (IP_R1:4500 -> IP_I1:4500)
	HDR, SK { IDr, CERT, AUTH,		HDR, SK { IDr, CERT, AUTH,
	CP(CFG_REPLY),		CP(CFG_REPLY),
	SAr2, TSi, TSr,		SAr2, TSi, TSr,
	N(MOBIKE_SUPPORTED) }		N(MOBIKE_SUPPORTED) }
	(Initiator gets information from lower layers that its attachment		(Initiator gets information from lower layers that its attachment
	point and address have changed.)		point and address have changed.)
	3) (IP_I2:4500 -> IP_R1:4500)		3) (IP_I2:4500 -> IP_R1:4500)
	HDR, SK { N(UPDATE_SA_ADDRESSES),		HDR, SK { N(UPDATE_SA_ADDRESSES),
	N(NAT_DETECTION_*_IP) } -->		N(NAT_DETECTION_SOURCE_IP),
			N(NAT_DETECTION_DESTINATION_IP) } -->
	<-- (IP_R1:4500 -> IP_I2:4500)		<-- (IP_R1:4500 -> IP_I2:4500)
	HDR, SK { N(NAT_DETECTION_*_IP) }		HDR, SK { N(NAT_DETECTION_SOURCE_IP),
			N(NAT_DETECTION_DESTINATION_IP) }
	(Responder verifies that the initiator has given it		(Responder verifies that the initiator has given it
	a correct IP address.)		a correct IP address.)
	4) <-- (IP_R1:4500 -> IP_I2:4500)		4) <-- (IP_R1:4500 -> IP_I2:4500)
	HDR, SK { N(COOKIE2) }		HDR, SK { N(COOKIE2) }
	(IP_I2:4500 -> IP_R1:4500)		(IP_I2:4500 -> IP_R1:4500)
	HDR, SK { N(COOKIE2) } -->		HDR, SK { N(COOKIE2) } -->
	skipping to change at page 9, line 18		skipping to change at page 9, line 22
	outgoing ESP traffic.		outgoing ESP traffic.
	Another protocol run in a multihoming scenario is illustrated below.		Another protocol run in a multihoming scenario is illustrated below.
	In this scenario, the initiator has one address but the responder has		In this scenario, the initiator has one address but the responder has
	two.		two.
	Initiator Responder		Initiator Responder
	----------- -----------		----------- -----------
	1) (IP_I1:500 -> IP_R1:500)		1) (IP_I1:500 -> IP_R1:500)
	HDR, SAi1, KEi, Ni,		HDR, SAi1, KEi, Ni,
	N(NAT_DETECTION_*_IP) -->		N(NAT_DETECTION_SOURCE_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_*_IP)		N(NAT_DETECTION_SOURCE_IP),
			N(NAT_DETECTION_DESTINATION_IP)
	2) (IP_I1:4500 -> IP_R1:4500)		2) (IP_I1:4500 -> IP_R1:4500)
	HDR, SK { IDi, CERT, AUTH,		HDR, SK { IDi, CERT, AUTH,
	CP(CFG_REQUEST),		CP(CFG_REQUEST),
	SAi2, TSi, TSr,		SAi2, TSi, TSr,
	N(MOBIKE_SUPPORTED) } -->		N(MOBIKE_SUPPORTED) } -->
	<-- (IP_R1:4500 -> IP_I1:4500)		<-- (IP_R1:4500 -> IP_I1:4500)
	HDR, SK { IDr, CERT, AUTH,		HDR, SK { IDr, CERT, AUTH,
	CP(CFG_REPLY),		CP(CFG_REPLY),
	SAr2, TSi, TSr,		SAr2, TSi, TSr,
	N(MOBIKE_SUPPORTED),		N(MOBIKE_SUPPORTED),
	N(ADDITIONAL_IPV4_ADDRESS) }		N(ADDITIONAL_IP4_ADDRESS) }
	(The initiator suspects a problem in the currently used address pair,		(The initiator suspects a problem in the currently used address pair,
	and probes its liveness.)		and probes its liveness.)
	3) (IP_I1:4500 -> IP_R1:4500)		3) (IP_I1:4500 -> IP_R1:4500)
	HDR, SK { N(NAT_DETECTION_*_IP) } -->		HDR, SK { N(NAT_DETECTION_SOURCE_IP),
			N(NAT_DETECTION_DESTINATION_IP) } -->
	(IP_I1:4500 -> IP_R1:4500)		(IP_I1:4500 -> IP_R1:4500)
	HDR, SK { N(NAT_DETECTION_*_IP) } -->		HDR, SK { N(NAT_DETECTION_SOURCE_IP),
			N(NAT_DETECTION_DESTINATION_IP) } -->
	...		...
	(Eventually, the initiator gives up on the current address pair, and		(Eventually, the initiator gives up on the current address pair, and
	tests the other available address pair.)		tests the other available address pair.)
	4) (IP_I1:4500 -> IP_R2:4500)		4) (IP_I1:4500 -> IP_R2:4500)
	HDR, SK { N(NAT_DETECTION_*_IP) }		HDR, SK { N(NAT_DETECTION_SOURCE_IP),
			N(NAT_DETECTION_DESTINATION_IP) }
	<-- (IP_R2:4500 -> IP_I1:4500)		<-- (IP_R2:4500 -> IP_I1:4500)
	HDR, SK { N(NAT_DETECTION_*_IP) }		HDR, SK { N(NAT_DETECTION_SOURCE_IP),
			N(NAT_DETECTION_DESTINATION_IP) }
	(This worked, and the initiator requests the peer to switch to new		(This worked, and the initiator requests the peer to switch to new
	addresses.)		addresses.)
	5) (IP_I1:4500 -> IP_R2:4500)		5) (IP_I1:4500 -> IP_R2:4500)
	HDR, SK { N(UPDATE_SA_ADDRESSES),		HDR, SK { N(UPDATE_SA_ADDRESSES),
	N(NAT_DETECTION_*_IP),		N(NAT_DETECTION_SOURCE_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_*_IP),		HDR, SK { N(NAT_DETECTION_SOURCE_IP),
			N(NAT_DETECTION_DESTINATION_IP),
	N(COOKIE2) }		N(COOKIE2) }
	2.3. MOBIKE and Network Address Translation (NAT)		2.3. MOBIKE and Network Address Translation (NAT)
	In some MOBIKE scenarios the network may contain NATs or stateful		In some MOBIKE scenarios the network may contain NATs or stateful
	packet filters (for brevity, the rest of this document talks simply		packet filters (for brevity, the rest of this document talks simply
	about NATs). The NAT Traversal feature specified in [IKEv2] allows		about NATs). The NAT Traversal feature specified in [IKEv2] allows
	IKEv2 to work through NATs in many cases, and MOBIKE can leverage		IKEv2 to work through NATs in many cases, and MOBIKE can leverage
	this functionality: when the addresses used for IPsec SAs are		this functionality: when the addresses used for IPsec SAs are
	changed, MOBIKE can enable or disable IKEv2 NAT Traversal as needed.		changed, MOBIKE can enable or disable IKEv2 NAT Traversal as needed.
	skipping to change at page 10, line 47		skipping to change at page 11, line 16
	changes, it needs to send a packet to the initiator using its new		changes, it needs to send a packet to the initiator using its new
	address. However, if the NAT is, for instance, of the common		address. However, if the NAT is, for instance, of the common
	"restricted cone" type (see [STUN] for one description of different		"restricted cone" type (see [STUN] for one description of different
	NAT types), this is not possible: the NAT will drop packets sent from		NAT types), this is not possible: the NAT will drop packets sent from
	the new address (unless the initiator has previously sent a packet to		the new address (unless the initiator has previously sent a packet to
	that address -- which it cannot do until it knows the address).		that address -- which it cannot do until it knows the address).
	For simplicity, MOBIKE does not attempt to handle all possible NAT-		For simplicity, MOBIKE does not attempt to handle all possible NAT-
	related scenarios. Instead, MOBIKE assumes that if NATs are present,		related scenarios. Instead, MOBIKE assumes that if NATs are present,
	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.		support the case where the responder's addresses change, meaning that
			no special effort is made to support this functionality. Responders
	"Does not fully support" means that no special effort is made to		may also be unaware of NATs or specific types of NATs they are
	support this functionality. Responders may also be unaware of NATs		behind. However, when a change has occurred that will cause a loss
	or specific types of NATs they are behind. However, when a change		of connectivity, MOBIKE responders will still attempt to inform the
	has occurred that will cause a loss of connectivity, MOBIKE		initiator of the change. Depending on, for instance, the exact type
	responders will still attempt to inform the initiator of the change.		of NAT, it may or may not succeed. However, analyzing the exact
	Depending on, for instance, the exact type of NAT, it may or may not		circumstances when this will or will not work is not done in this
	succeed. However, analyzing the exact circumstances when this will		document.
	or will not work is not done in this document.
	3. Protocol Exchanges		3. Protocol Exchanges
	3.1. Initial IKE Exchange		3.1. Initial IKE Exchange
	The initiator is responsible for finding a working pair of addresses		The initiator is responsible for finding a working pair of addresses
	so that the initial IKE exchange can be carried out. Any information		so that the initial IKE exchange can be carried out. Any information
	from MOBIKE extensions will only be available later, when the		from MOBIKE extensions will only be available later, when the
	exchange has progressed far enough. Exactly how the addresses used		exchange has progressed far enough. Exactly how the addresses used
	for the initial exchange are discovered is beyond the scope of this		for the initial exchange are discovered is beyond the scope of this
	skipping to change at page 13, line 9		skipping to change at page 13, line 25
	responder will be incorrect. This means the procedure for changing		responder will be incorrect. This means the procedure for changing
	responder addresses described in Section 3.6 does not fully work when		responder addresses described in Section 3.6 does not fully work when
	the initiator is behind a NAT. For the same reason, the peers also		the initiator is behind a NAT. For the same reason, the peers also
	SHOULD NOT use this information for any other purpose than what is		SHOULD NOT use this information for any other purpose than what is
	explicitly described either in this document or a future		explicitly described either in this document or a future
	specification updating it.		specification updating it.
	3.5. Changing Addresses in IPsec SAs		3.5. Changing Addresses in IPsec SAs
	In MOBIKE, the initiator decides what addresses are used in the IPsec		In MOBIKE, the initiator decides what addresses are used in the IPsec
	SAs. That is, the responder usually never updates any IPsec SAs		SAs. That is, the responder does not normally update any IPsec SAs
	without receiving an explicit UPDATE_SA_ADDRESSES request from the		without receiving an explicit UPDATE_SA_ADDRESSES request from the
	initiator. (As described below, the responder can, however, update		initiator. (As described below, the responder can, however, update
	the IKE_SA in some circumstances.)		the IKE_SA in some circumstances.)
	The reasons why the initiator wishes to change the addresses are		The reasons why the initiator wishes to change the addresses are
	largely beyond the scope of MOBIKE. Typically, triggers include		largely beyond the scope of MOBIKE. Typically, triggers include
	information received from lower layers, such as changes in IP		information received from lower layers, such as changes in IP
	addresses or link-down indications. Some of this information can be		addresses or link-down indications. Some of this information can be
	unreliable: for instance, ICMP messages could be spoofed by an		unreliable: for instance, ICMP messages could be spoofed by an
	attacker. Unreliable information SHOULD be treated only as a hint		attacker. Unreliable information SHOULD be treated only as a hint
	skipping to change at page 13, line 33		skipping to change at page 13, line 49
	Changing addresses can also be triggered by events within IKEv2. At		Changing addresses can also be triggered by events within IKEv2. At
	least the following events can cause the initiator to re-evaluate its		least the following events can cause the initiator to re-evaluate its
	local address selection policy, possibly leading to changing the		local address selection policy, possibly leading to changing the
	addresses.		addresses.
	o An IKEv2 request has been re-transmitted several times, but no		o An IKEv2 request has been re-transmitted several times, but no
	valid reply has been received. This suggests the current path is		valid reply has been received. This suggests the current path is
	no longer working.		no longer working.
	o An INFORMATIONAL request containing ADDITIONAL_IP4/6_ADDRESS or		o An INFORMATIONAL request containing an ADDITIONAL_IP4_ADDRESS,
	NO_ADDITIONAL_ADDRESS notifications is received. This means the		ADDITIONAL_IP6_ADDRESS, or NO_ADDITIONAL_ADDRESSES notification is
	peer's addresses may have changed. This is particularly important		received. This means the peer's addresses may have changed. This
	if the announced set of address no longer contains the currently		is particularly important if the announced set of address no
	used address.		longer contains the currently used address.
	o An UNACCEPTABLE_ADDRESSES notification is received as a response		o An UNACCEPTABLE_ADDRESSES notification is received as a response
	to address update request (described below).		to address update request (described below).
	o The initiator receives a NAT_DETECTION_DESTINATION_IP notification		o The initiator receives a NAT_DETECTION_DESTINATION_IP notification
	that does not match the previous UPDATE_SA_ADDRESSES response (see		that does not match the previous UPDATE_SA_ADDRESSES response (see
	Section 3.8 for a more detailed description).		Section 3.8 for a more detailed description).
	The description in the rest of this section assumes that the		The description in the rest of this section assumes that the
	initiator has already decided what the new addresses should be. When		initiator has already decided what the new addresses should be. When
	skipping to change at page 14, line 33		skipping to change at page 14, line 46
	them using the addresses in the IKE_SA (the new addresses).		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 UPDATE_SA_ADDRESSES notification (which does not		containing the UPDATE_SA_ADDRESSES notification (which does not
	contain any data), and clears the "pending_update" flag. The		contain any data), and clears the "pending_update" flag. The
	request will be as follows:		request will be as follows:
	Initiator Responder		Initiator Responder
	----------- -----------		----------- -----------
	HDR, SK { N(UPDATE_SA_ADDRESSES),		HDR, SK { N(UPDATE_SA_ADDRESSES),
	[N(NAT_DETECTION_*_IP)],		[N(NAT_DETECTION_SOURCE_IP),
			N(NAT_DETECTION_DESTINATION_IP)],
	[N(NO_NATS_ALLOWED)],		[N(NO_NATS_ALLOWED)],
	[N(COOKIE2)] } -->		[N(COOKIE2)] } -->
	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
	UPDATE_SA_ADDRESSES request).		UPDATE_SA_ADDRESSES request).
	When processing an INFORMATIONAL request containing the		When processing an INFORMATIONAL request containing the
	UPDATE_SA_ADDRESSES notification, the responder:		UPDATE_SA_ADDRESSES notification, the responder:
	o Determines whether it has already received a newer		o Determines whether it has already received a newer
	UPDATE_SA_ADDRESSES request than this one (if the responder uses a		UPDATE_SA_ADDRESSES request than this one (if the responder uses a
	window size greater than one, it is possible that requests are		window size greater than one, it is possible that requests are
	skipping to change at page 15, line 19		skipping to change at page 15, line 34
	o Updates the IP addresses in the IKE_SA with the values from the IP		o Updates the IP addresses in the IKE_SA with the values from the IP
	header. (Using the address from the IP header is consistent with		header. (Using the address from the IP header is consistent with
	normal IKEv2, and allows IKEv2 to work with NATs without needing		normal IKEv2, and allows IKEv2 to work with NATs without needing
	unilateral self-address fixing [UNSAF].)		unilateral self-address fixing [UNSAF].)
	o Replies with an INFORMATIONAL response:		o Replies with an INFORMATIONAL response:
	Initiator Responder		Initiator Responder
	----------- -----------		----------- -----------
	<-- HDR, SK { [N(NAT_DETECTION_*_IP)],		<-- HDR, SK { [N(NAT_DETECTION_SOURCE_IP),
			N(NAT_DETECTION_DESTINATION_IP)],
	[N(COOKIE2)] }		[N(COOKIE2)] }
	o If necessary, initiates a return routability check for the new		o If necessary, initiates a return routability check for the new
	initiator address (see Section 3.7) and waits until the check is		initiator address (see Section 3.7) and waits until the check is
	completed.		completed.
	o Updates the IPsec SAs associated with this IKE_SA with the new		o Updates the IPsec SAs associated with this IKE_SA with the new
	addresses.		addresses.
	o If NAT Traversal is supported and NAT detection payloads were		o If NAT Traversal is supported and NAT detection payloads were
	skipping to change at page 16, line 18		skipping to change at page 16, line 38
	unavailable (i.e., sending packets using that source address is no		unavailable (i.e., sending packets using that source address is no
	longer possible), the responder is allowed to update the IPsec SAs to		longer possible), the responder is allowed to update the IPsec SAs to
	use some other address (in addition to initiating the procedure		use some other address (in addition to initiating the procedure
	described in the next section).		described in the next section).
	3.6. Updating Additional Addresses		3.6. Updating Additional Addresses
	As described in Section 3.4, both the initiator and responder can		As described in Section 3.4, both the initiator and responder can
	send a list of additional addresses in the IKE_AUTH exchange. This		send a list of additional addresses in the IKE_AUTH exchange. This
	information can be updated by sending an INFORMATIONAL exchange		information can be updated by sending an INFORMATIONAL exchange
	request message that contains either one or more ADDITIONAL_IP4/		request message that contains either one or more
	6_ADDRESS notifications or the NO_ADDITIONAL_ADDRESSES notification.		ADDITIONAL_IP4_ADDRESS/ADDITIONAL_IP6_ADDRESS notifications or the
			NO_ADDITIONAL_ADDRESSES notification.
	If the exchange initiator has only a single IP address, it is placed		If the exchange initiator has only a single IP address, it is placed
	in the IP header, and the message contains the		in the IP header, and the message contains the
	NO_ADDITIONAL_ADDRESSES notification. If the exchange initiator has		NO_ADDITIONAL_ADDRESSES notification. If the exchange initiator has
	several addresses, one of them is placed in the IP header, and the		several addresses, one of them is placed in the IP header, and the
	rest in ADDITIONAL_IP4/6_ADDRESS notifications. The new list of		rest in ADDITIONAL_IP4_ADDRESS/ADDITIONAL_IP6_ADDRESS notifications.
	addresses replaces the old information (in other words, there are no		The new list of addresses replaces the old information (in other
	separate add/delete operations; instead, the complete list is sent		words, there are no separate add/delete operations; instead, the
	every time these notifications are used).		complete list is sent every time these notifications are used).
	The message exchange will look as follows:		The message exchange will look as follows:
	Initiator Responder		Initiator Responder
	----------- -----------		----------- -----------
	HDR, SK { [N(ADDITIONAL_*_ADDRESS)+],		HDR, SK { [N(ADDITIONAL_*_ADDRESS)+],
	[N(NO_ADDITIONAL_ADDRESSES)],		[N(NO_ADDITIONAL_ADDRESSES)],
	[N(NO_NATS_ALLOWED)],		[N(NO_NATS_ALLOWED)],
	[N(COOKIE2)] } -->		[N(COOKIE2)] } -->
	<-- HDR, SK { [N(COOKIE2)] }		<-- HDR, SK { [N(COOKIE2)] }
	When a request containing ADDITIONAL_IP4/6_ADDRESS or		When a request containing an ADDITIONAL_IP4_ADDRESS,
	NO_ADDITIONAL_ADDRESSES notification is received, the exchange		ADDITIONAL_IP6_ADDRESS, or NO_ADDITIONAL_ADDRESSES notification is
	responder:		received, the exchange responder:
	o Determines whether it has already received a newer request to		o Determines whether it has already received a newer request to
	update the addresses (if a window size greater than one is used,		update the addresses (if a window size greater than one is used,
	it is possible that the requests are received out of order). If		it is possible that the requests are received out of order). If
	it has, a response message is sent, but the address set is not		it has, a response message is sent, but the address set is not
	updated.		updated.
	o If the NO_NATS_ALLOWED notification is present, processes it as		o If the NO_NATS_ALLOWED notification is present, processes it as
	described in Section 3.9.		described in Section 3.9.
	o Updates the set of peer addresses based on the IP header and		o Updates the set of peer addresses based on the IP header and the
	ADDITIONAL_IP4/6_ADDRESS or NO_ADDITIONAL_ADDRESS notifications.		ADDITIONAL_IP4_ADDRESS, ADDITIONAL_IP6_ADDRESS and
			NO_ADDITIONAL_ADDRESSES notifications.
	o Sends a response.		o Sends a response.
	The initiator MAY include these notifications in the same request as		The initiator MAY include these notifications in the same request as
	UPDATE_SA_ADDRESSES.		UPDATE_SA_ADDRESSES.
	If the request to update the addresses is retransmitted using several		If the request to update the addresses is retransmitted using several
	different source addresses, a new INFORMATIONAL request MUST be sent.		different source addresses, a new INFORMATIONAL request MUST be sent.
	There is one additional complication: when the responder wants to		There is one additional complication: when the responder wants to
	update the address set, the currently used addresses may no longer		update the address set, the currently used addresses may no longer
	work. In this case, the responder uses the additional address list		work. In this case, the responder uses the additional address list
	received from the initiator, and the list of its own addresses, to		received from the initiator, and the list of its own addresses, to
	determine which addresses to use for sending the INFORMATIONAL		determine which addresses to use for sending the INFORMATIONAL
	request. This is the only time the responder uses the additional		request. This is the only time the responder uses the additional
	address list received from the 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
	are acceptable to use, and certain types of policies may simplify		are acceptable to use, and certain types of policies may simplify
	implementation. For instance, if the responder has a single fixed		implementation. For instance, if the responder has a single fixed
	address, it does need to process ADDITIONAL_*_ADDRESS notifications		address, it does not need to process the ADDITIONAL_IP4_ADDRESS and
	it receives (beyond ignoring unrecognized status notifications as		ADDITIONAL_IP6_ADDRESS notifications it receives (beyond ignoring
	already required in [IKEv2]). Furthermore, if the initiator has a		unrecognized status notifications as already required in [IKEv2]).
	policy saying that only the responder address specified in local
	configuration is acceptable, it does not have to send its own		Furthermore, if the initiator has a policy saying that only the
	additional addresses to the responder (since the responder does not		responder address specified in local configuration is acceptable, it
	need them except when changing its own address).		does not have to send its own additional addresses to the responder
			(since the responder does not need them except when changing its own
			address).
	3.7. Return Routability Check		3.7. Return Routability Check
	Both parties can optionally verify that the other party can actually		Both parties can optionally verify that the other party can actually
	receive packets at the claimed address. By default, this "return		receive packets at the claimed address. By default, this "return
	routability check" SHOULD be performed. In environments where the		routability check" SHOULD be performed. In environments where the
	peer is expected to be well-behaved (many corporate VPNs, for		peer is expected to be well-behaved (many corporate VPNs, for
	instance), or the address can be verified by some other means (e.g.,		instance), or the address can be verified by some other means (e.g.,
	a certificate issued by an authority trusted for this purpose), the		a certificate issued by an authority trusted for this purpose), the
	return routability check MAY be omitted.		return routability check MAY be omitted.
	skipping to change at page 18, line 32		skipping to change at page 19, line 8
	INFORMATIONAL request needs to be sent to check return routability.		INFORMATIONAL request needs to be sent to check return routability.
	3.8. Changes in NAT Mappings		3.8. Changes in NAT Mappings
	IKEv2 performs Dead Peer Detection (DPD) if there has recently been		IKEv2 performs Dead Peer Detection (DPD) if there has recently been
	only outgoing traffic on all of the SAs associated with the IKE_SA.		only outgoing traffic on all of the SAs associated with the IKE_SA.
	In MOBIKE, these messages can also be used to detect if NAT mappings		In MOBIKE, these messages can also be used to detect if NAT mappings
	have changed (for example, if the keepalive interval is too long, or		have changed (for example, if the keepalive interval is too long, or
	the NAT box is rebooted). More specifically, if both peers support		the NAT box is rebooted). More specifically, if both peers support
	both this specification and NAT Traversal, NAT_DETECTION_*_IP		both this specification and NAT Traversal, the
			NAT_DETECTION_SOURCE_IP and NAT_DETECTION_DESTINATION_IP
	notifications MAY be included in any INFORMATIONAL request; if the		notifications MAY be included in any INFORMATIONAL request; if the
	request includes them, the responder MUST also include them in the		request includes them, the responder MUST also include them in the
	response (but no other action is taken, unless otherwise specified).		response (but no other action is taken, unless otherwise specified).
	When the initiator is behind a NAT (as detected earlier using		When the initiator is behind a NAT (as detected earlier using the
	NAT_DETECTION_*_IP notifications), it SHOULD include these		NAT_DETECTION_SOURCE_IP and NAT_DETECTION_DESTINATION_IP
	notifications in DPD messages, and compare the received		notifications), it SHOULD include these notifications in DPD
	NAT_DETECTION_DESTINATION_IP notifications with the value from the		messages, and compare the received NAT_DETECTION_DESTINATION_IP
	previous UPDATE_SA_ADDRESSES response (or the IKE_SA_INIT response).		notifications with the value from the previous UPDATE_SA_ADDRESSES
	If the values do not match, the IP address and/or port seen by the		response (or the IKE_SA_INIT response). If the values do not match,
	responder has changed, and the initiator SHOULD send		the IP address and/or port seen by the responder has changed, and the
	UPDATE_SA_ADDRESSES as described in Section 3.5. If the initiator		initiator SHOULD send UPDATE_SA_ADDRESSES as described in
	suspects that the NAT mapping has changed, it MAY also skip the		Section 3.5. If the initiator suspects that the NAT mapping has
	detection step and send UPDATE_SA_ADDRESSES immediately. This saves		changed, it MAY also skip the detection step and send
	one roundtrip if the NAT mapping has indeed changed.		UPDATE_SA_ADDRESSES immediately. This saves one roundtrip if the NAT
			mapping has indeed changed.
	Note that this approach to detecting NAT mapping changes may cause an		Note that this approach to detecting NAT mapping changes may cause an
	extra address update when the IKE_SA is rekeyed. This is because the		extra address update when the IKE_SA is rekeyed. This is because the
	NAT_DETECTION_DESTINATION_IP hash also includes the IKE SPIs, which		NAT_DETECTION_DESTINATION_IP hash also includes the IKE SPIs, which
	change when performing rekeying. This unnecessary update is		change when performing rekeying. This unnecessary update is
	harmless, however.		harmless, however.
	When MOBIKE is in use, the dynamic updates specified in [IKEv2]		When MOBIKE is in use, the dynamic updates specified in [IKEv2]
	Section 2.23 (where the peer address and port are updated from the		Section 2.23 (where the peer address and port are updated from the
	last valid authenticated packet) work in a slightly different		last valid authenticated packet) work in a slightly different
	skipping to change at page 19, line 38		skipping to change at page 20, line 15
	contain NATs, IPv4/IPv6 translation agents, or other nodes that		contain NATs, IPv4/IPv6 translation agents, or other nodes that
	modify the addresses in the IP header. This feature is mainly		modify the addresses in the IP header. This feature is mainly
	intended for IPv6 and site-to-site VPN cases, where the		intended for IPv6 and site-to-site VPN cases, where the
	administrators may know beforehand that NATs are not present, and		administrators may know beforehand that NATs are not present, and
	thus any modification to the packet can be considered an attack.		thus any modification to the packet can be considered an attack.
	More specifically, when NAT Traversal is not enabled, all messages		More specifically, when NAT Traversal is not enabled, all messages
	that can update the addresses associated with the IKE_SA and/or IPsec		that can update the addresses associated with the IKE_SA and/or IPsec
	SAs (the first IKE_AUTH request and all INFORMATIONAL requests that		SAs (the first IKE_AUTH request and all INFORMATIONAL requests that
	contain any of the following notifications: UPDATE_SA_ADDRESSES,		contain any of the following notifications: UPDATE_SA_ADDRESSES,
	ADDITIONAL_IP4/6_ADDRESS, NO_ADDITIONAL_ADDRESSES) MUST also include		ADDITIONAL_IP4_ADDRESS, ADDITIONAL_IP6_ADDRESS,
	a NO_NATS_ALLOWED notification. The exchange responder MUST verify		NO_ADDITIONAL_ADDRESSES) MUST also include a NO_NATS_ALLOWED
	that the contents of the NO_NATS_ALLOWED notification match the		notification. The exchange responder MUST verify that the contents
	addresses in the IP header. If they do not match, a response		of the NO_NATS_ALLOWED notification match the addresses in the IP
	containing an UNEXPECTED_NAT_DETECTED notification is sent. The		header. If they do not match, a response containing an
	response message is sent to the address and port that the		UNEXPECTED_NAT_DETECTED notification is sent. The response message
	corresponding request came from, not to the address contained in the		is sent to the address and port that the corresponding request came
	NO_NATS_ALLOWED notification.		from, not to the address contained in the NO_NATS_ALLOWED
			notification.
	If the exchange initiator receives an UNEXPECTED_NAT_DETECTED		If the exchange initiator receives an UNEXPECTED_NAT_DETECTED
	notification in response to its INFORMATIONAL request, it SHOULD		notification in response to its INFORMATIONAL request, it SHOULD
	retry the operation several times using new INFORMATIONAL requests.		retry the operation several times using new INFORMATIONAL requests.
	Similarly, if the initiator receives UNEXPECTED_NAT_DETECTED in the		Similarly, if the initiator receives UNEXPECTED_NAT_DETECTED in the
	IKE_AUTH exchange, it SHOULD retry IKE_SA establishment several		IKE_AUTH exchange, it SHOULD retry IKE_SA establishment several
	times, starting from a new IKE_SA_INIT request. This ensures that an		times, starting from a new IKE_SA_INIT request. This ensures that an
	attacker who is able to modify only a single packet does not		attacker who is able to modify only a single packet does not
	unnecessarily cause a path to remain unused.		unnecessarily cause a path to remain unused.
	skipping to change at page 21, line 46		skipping to change at page 22, line 46
	The MOBIKE_SUPPORTED notification is included in the IKE_AUTH		The MOBIKE_SUPPORTED notification is included in the IKE_AUTH
	exchange to indicate that the implementation supports this		exchange to indicate that the implementation supports this
	specification.		specification.
	The Notify Message Type for MOBIKE_SUPPORTED is TBD-BY-IANA1. The		The Notify Message Type for MOBIKE_SUPPORTED is TBD-BY-IANA1. The
	Protocol ID and SPI Size fields are set to zero. The notification		Protocol ID and SPI Size fields are set to zero. The notification
	data field MUST be left empty (zero-length) when sending, and its		data field MUST be left empty (zero-length) when sending, and its
	contents (if any) MUST be ignored when this notification is received.		contents (if any) MUST be ignored when this notification is received.
	This allows the field to be used by future versions of this protocol.		This allows the field to be used by future versions of this protocol.
	4.2.2. ADDITIONAL_IP4/6_ADDRESS Notify Payloads		4.2.2. ADDITIONAL_IP4_ADDRESS and ADDITIONAL_IP6_ADDRESS Notify
			Payloads
	Both parties can include ADDITIONAL_IP4_ADDRESS and/or		Both parties can include ADDITIONAL_IP4_ADDRESS and/or
	ADDITIONAL_IP6_ADDRESS notifications in the IKE_AUTH exchange and		ADDITIONAL_IP6_ADDRESS notifications in the IKE_AUTH exchange and
	INFORMATIONAL exchange request messages; see Section 3.4 and		INFORMATIONAL exchange request messages; see Section 3.4 and
	Section 3.6 for more detailed description.		Section 3.6 for more detailed description.
	The Notify Message Types for ADDITIONAL_IP4_ADDRESS and		The Notify Message Types for ADDITIONAL_IP4_ADDRESS and
	ADDITIONAL_IP6_ADDRESS are TBD-BY-IANA2 and TBD-BY-IANA3,		ADDITIONAL_IP6_ADDRESS are TBD-BY-IANA2 and TBD-BY-IANA3,
	respectively. The Protocol ID and SPI Size fields are set to zero.		respectively. The Protocol ID and SPI Size fields are set to zero.
	The data associated with these Notify types is either a four-octet		The data associated with these Notify types is either a four-octet
	skipping to change at page 25, line 19		skipping to change at page 26, line 19
	the VPN client.		the VPN client.
	It is recommended that security policies, for peers that are allowed		It is recommended that security policies, for peers that are allowed
	to use MOBIKE, are configured in a manner that takes into account		to use MOBIKE, are configured in a manner that takes into account
	that a single security association can be used at different times		that a single security association can be used at different times
	through paths of varying security properties.		through paths of varying security properties.
	5.3. Denial-of-Service Attacks Against Third Parties		5.3. Denial-of-Service Attacks Against Third Parties
	Traffic redirection may be performed not just to gain access to the		Traffic redirection may be performed not just to gain access to the
	traffic (not very interesting because it is encrypted) or to deny		traffic or to deny service to the peers, but also to cause a denial-
	service to the peers, but also to cause a denial-of-service attack		of-service attack for a third party. For instance, a high-speed TCP
	for a third party. For instance, a high-speed TCP session or a		session or a multimedia stream may be redirected towards a victim
	multimedia stream may be redirected towards a victim host, causing		host, causing its communications capabilities to suffer.
	its communications capabilities to suffer.
	The attackers in this threat can be either outsiders or even one of		The attackers in this threat can be either outsiders or even one of
	the IKEv2 peers. In usual VPN usage scenarios, attacks by the peers		the IKEv2 peers. In usual VPN usage scenarios, attacks by the peers
	can be easily dealt with if the authentication performed in the		can be easily dealt with if the authentication performed in the
	initial IKEv2 negotiation can be traced to persons who can be held		initial IKEv2 negotiation can be traced to persons who can be held
	responsible for the attack. This may not be the case in all		responsible for the attack. This may not be the case in all
	scenarios, particularly with opportunistic approaches to security.		scenarios, particularly with opportunistic approaches to security.
	If the attack is launched by an outsider, the traffic flow would		If the attack is launched by an outsider, the traffic flow would
	normally stop soon due to the lack of responses (such as transport		normally stop soon due to the lack of responses (such as transport
	skipping to change at page 26, line 49		skipping to change at page 27, line 48
	determine which paths can be used. If IKEv2 messages sent using a		determine which paths can be used. If IKEv2 messages sent using a
	particular source and destination addresses reach the recipient and a		particular source and destination addresses reach the recipient and a
	reply is received, MOBIKE will usually consider the path working; if		reply is received, MOBIKE will usually consider the path working; if
	no reply is received even after retransmissions, MOBIKE will suspect		no reply is received even after retransmissions, MOBIKE will suspect
	the path is broken. An attacker who can consistently control the		the path is broken. An attacker who can consistently control the
	delivery or non-delivery of the IKEv2 messages in the network can		delivery or non-delivery of the IKEv2 messages in the network can
	thus influence which addresses actually get used.		thus influence which addresses actually get used.
	5.5. Address and Topology Disclosure		5.5. Address and Topology Disclosure
	MOBIKE address updates and ADDITIONAL_IP4/6_ADDRESS notifications		MOBIKE address updates and the ADDITIONAL_IP4_ADDRESS/
	reveal information about which networks the peers are connected to.		ADDITIONAL_IP6_ADDRESS notifications reveal information about which
			networks the peers are connected to.
	For example, consider a host A with two network interfaces: a		For example, consider a host A with two network interfaces: a
	cellular connection and a wired Ethernet connection to a company LAN.		cellular connection and a wired Ethernet connection to a company LAN.
	If host A now contacts host B using IKEv2/MOBIKE and sends		If host A now contacts host B using IKEv2 and sends
	ADDITIONAL_IP4/6_ADDRESS notifications, host B receives additional		ADDITIONAL_IP4_ADDRESS/ADDITIONAL_IP6_ADDRESS notifications, host B
	information it might not otherwise know. If host A used the cellular		receives additional information it might not otherwise know. If host
	connection for the IKEv2/MOBIKE traffic, host B can also see the		A used the cellular connection for the IKEv2 traffic, host B can also
	company LAN address (and perhaps further guess that host A is used by		see the company LAN address (and perhaps further guess that host A is
	an employee of that company). If host A used the company LAN to make		used by an employee of that company). If host A used the company LAN
	the connection, host B can see that host A has a subscription from		to make the connection, host B can see that host A has a subscription
	this particular cellular operator.		from this particular cellular operator.
	These additional addresses can also disclose more accurate location		These additional addresses can also disclose more accurate location
	information than just a single address. Suppose that host A uses its		information than just a single address. Suppose that host A uses its
	cellular connection for IKEv2/MOBIKE traffic, but also sends an		cellular connection for IKEv2 traffic, but also sends an
	ADDITIONAL_IP4_ADDRESS notification containing an IP address		ADDITIONAL_IP4_ADDRESS notification containing an IP address
	corresponding to, say, a wireless LAN at a particular coffee shop		corresponding to, say, a wireless LAN at a particular coffee shop
	location. It is likely that host B can now make a much better guess		location. It is likely that host B can now make a much better guess
	at A's location than would be possible based on the cellular IP		at A's location than would be possible based on the cellular IP
	address alone.		address alone.
	Furthermore, as described in Section 3.4, some of the addresses could		Furthermore, as described in Section 3.4, some of the addresses could
	also be private addresses behind a NAT.		also be private addresses behind a NAT.
	In many environments, disclosing address information is not a problem		In many environments, disclosing address information is not a problem
	(and indeed it cannot be avoided if the hosts wish to use those		(and indeed it cannot be avoided if the hosts wish to use those
	addresses for IPsec traffic). For instance, a remote access VPN		addresses for IPsec traffic). For instance, a remote access VPN
	client could consider the corporate VPN gateway sufficiently		client could consider the corporate VPN gateway sufficiently
	trustworthy for this purpose. Furthermore, the ADDITIONAL_IP4/		trustworthy for this purpose. Furthermore, the
	6_ADDRESS notifications are sent encrypted, so the addresses are not		ADDITIONAL_IP4_ADDRESS and ADDITIONAL_IP6_ADDRESS notifications are
	visible to eavesdroppers (unless, of course, they are later used for		sent encrypted, so the addresses are not visible to eavesdroppers
	sending IKEv2/IPsec traffic).		(unless, of course, they are later used for sending IKEv2/IPsec
			traffic).
	However, if MOBIKE is used in some more opportunistic approach, it		However, if MOBIKE is used in some more opportunistic approach, it
	can be desirable to limit the information that is sent. Naturally,		can be desirable to limit the information that is sent. Naturally,
	the peers do not have to disclose any addresses they do not want to		the peers do not have to disclose any addresses they do not want to
	use for IPsec traffic. Also, as noted in Section 3.6, an initiator		use for IPsec traffic. Also, as noted in Section 3.6, an initiator
	whose policy is to always use the locally configured responder		whose policy is to always use the locally configured responder
	address does not have to send any ADDITIONAL_IP4/6_ADDRESS payloads.		address does not have to send any ADDITIONAL_IP4_ADDRESS/
			ADDITIONAL_IP6_ADDRESS payloads.
	6. IANA Considerations		6. IANA Considerations
	This document does not create any new namespaces to be maintained by		This document does not create any new namespaces to be maintained by
	IANA, but it requires new values in namespaces that have been defined		IANA, but it requires new values in namespaces that have been defined
	in the IKEv2 base specification [IKEv2].		in the IKEv2 base specification [IKEv2].
	This document defines several new IKEv2 notifications whose values		This document defines several new IKEv2 notifications whose values
	are to be allocated from the "IKEv2 Notify Message Types" namespace.		are to be allocated from the "IKEv2 Notify Message Types" namespace.
	skipping to change at page 28, line 30		skipping to change at page 29, line 33
	These notifications are described in Section 4.		These notifications are described in Section 4.
	7. Acknowledgements		7. Acknowledgements
	This document is a collaborative effort of the entire MOBIKE WG. We		This document is a collaborative effort of the entire MOBIKE WG. We
	would particularly like to thank Jari Arkko, Tuomas Aura, Marcelo		would particularly like to thank Jari Arkko, Tuomas Aura, Marcelo
	Bagnulo, Stephane Beaulieu, Lakshminath Dondeti, Francis Dupont, Paul		Bagnulo, Stephane Beaulieu, Lakshminath Dondeti, Francis Dupont, Paul
	Hoffman, James Kempf, Tero Kivinen, Pete McCann, Mohan Parthasarathy,		Hoffman, James Kempf, Tero Kivinen, Pete McCann, Mohan Parthasarathy,
	Pekka Savola, Bill Sommerfeld, Maureen Stillman, Shinta Sugimoto,		Pekka Savola, Bill Sommerfeld, Maureen Stillman, Shinta Sugimoto,
	Sami Vaarala, and Hannes Tschofenig. This document also incorporates		Sami Vaarala, and Hannes Tschofenig. This document also incorporates
	ideas and text from earlier MOBIKE protocol proposals, including		ideas and text from earlier MOBIKE-like protocol proposals, including
	[AddrMgmt], [Kivinen], [MOPO], and [SMOBIKE], and the MOBIKE design		[AddrMgmt], [Kivinen], [MOPO], and [SMOBIKE], and the MOBIKE design
	document [Design].		document [Design].
	8. References		8. References
	8.1. Normative References		8.1. Normative References
	[IKEv2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",		[IKEv2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
	draft-ietf-ipsec-ikev2-17 (work in progress),		draft-ietf-ipsec-ikev2-17 (work in progress),
	October 2004.		October 2004.
	skipping to change at page 32, line 9		skipping to change at page 33, line 10
	identify an outbound IPsec SA; see Appendix A.1). Thus, in steps 1		identify an outbound IPsec SA; see Appendix A.1). Thus, in steps 1
	and 2 it may be easier to identify the "right peer" using its		and 2 it may be easier to identify the "right peer" using its
	authenticated identity instead of its current IP address. However,		authenticated identity instead of its current IP address. However,
	these implementation details are beyond the scope of this		these implementation details are beyond the scope of this
	specification.		specification.
	Appendix B. Changelog		Appendix B. Changelog
	(This section should be removed by the RFC editor.)		(This section should be removed by the RFC editor.)
			Changes from -06 to -07:
			o Editorial fixes from AD evaluation.
	Changes from -06.a to -06:		Changes from -06.a to -06:
	o Clarified text about certificates and omitting RR (issue 54).		o Clarified text about certificates and omitting RR (issue 54).
	o Take initial addresses from IKE_AUTH even when not doing NAT-T		o Take initial addresses from IKE_AUTH even when not doing NAT-T
	(issue 60).		(issue 60).
	o Added text about dead peer detection (issue 71).		o Added text about dead peer detection (issue 71).
	o Fixed port numbers in examples (issue 73).		o Fixed port numbers in examples (issue 73).
End of changes. 49 change blocks.
	155 lines changed or deleted		181 lines changed or added
This html diff was produced by rfcdiff 1.28, available from http://www.levkowetz.com/ietf/tools/rfcdiff/