< draft-ietf-mobike-protocol-07.txt		draft-ietf-mobike-protocol-08.txt >
	MOBIKE Working Group P. Eronen, Ed.		MOBIKE Working Group P. Eronen, Ed.
	Internet-Draft Nokia		Internet-Draft Nokia
	Expires: June 23, 2006 December 20, 2005		Expires: August 26, 2006 February 22, 2006
	IKEv2 Mobility and Multihoming Protocol (MOBIKE)		IKEv2 Mobility and Multihoming Protocol (MOBIKE)
	draft-ietf-mobike-protocol-07.txt		draft-ietf-mobike-protocol-08.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 June 23, 2006.		This Internet-Draft will expire on August 26, 2006.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2005).		Copyright (C) The Internet Society (2006).
	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 the IP addresses associated with IKEv2 and tunnel mode IPsec		allows the IP addresses associated with IKEv2 and tunnel mode IPsec
	Security Associations to change. A mobile VPN client could use		Security Associations to change. A mobile VPN client could use
	MOBIKE to keep the connection with the VPN gateway active while		MOBIKE to keep the connection with the VPN gateway active while
	moving from one address to another. Similarly, a multihomed host		moving from one address to another. Similarly, a multihomed host
	could use MOBIKE to move the traffic to a different interface if, for		could use MOBIKE to move the traffic to a different interface 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 Exchanges . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . 12		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 . . . . . . . . . . . . . . . . . 18		3.7. Return Routability Check . . . . . . . . . . . . . . . . . 18
	3.8. Changes in NAT Mappings . . . . . . . . . . . . . . . . . 18		3.8. Changes in NAT Mappings . . . . . . . . . . . . . . . . . 18
	skipping to change at page 2, line 45 ¶		skipping to change at page 2, line 45 ¶
	Notify Payloads . . . . . . . . . . . . . . . . . . . 22		Notify Payloads . . . . . . . . . . . . . . . . . . . 22
	4.2.3. NO_ADDITIONAL_ADDRESSES Notify Payload . . . . . . . . 23		4.2.3. NO_ADDITIONAL_ADDRESSES Notify Payload . . . . . . . . 23
	4.2.4. UPDATE_SA_ADDRESSES Notify Payload . . . . . . . . . . 23		4.2.4. UPDATE_SA_ADDRESSES Notify Payload . . . . . . . . . . 23
	4.2.5. COOKIE2 Notify Payload . . . . . . . . . . . . . . . . 23		4.2.5. COOKIE2 Notify Payload . . . . . . . . . . . . . . . . 23
	4.2.6. NO_NATS_ALLOWED Notify Payload . . . . . . . . . . . . 23		4.2.6. NO_NATS_ALLOWED Notify Payload . . . . . . . . . . . . 23
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 25		5. Security Considerations . . . . . . . . . . . . . . . . . . . 25
	5.1. Traffic Redirection and Hijacking . . . . . . . . . . . . 25		5.1. Traffic Redirection and Hijacking . . . . . . . . . . . . 25
	5.2. IPsec Payload Protection . . . . . . . . . . . . . . . . . 25		5.2. IPsec Payload Protection . . . . . . . . . . . . . . . . . 25
	5.3. Denial-of-Service Attacks Against Third Parties . . . . . 26		5.3. Denial-of-Service Attacks Against Third Parties . . . . . 26
	5.4. Spoofing Network Connectivity Indications . . . . . . . . 27		5.4. Spoofing Network Connectivity Indications . . . . . . . . 27
	5.5. Address and Topology Disclosure . . . . . . . . . . . . . 27		5.5. Address and Topology Disclosure . . . . . . . . . . . . . 28
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
	7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29		7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 30
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29		8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30
	8.1. Normative References . . . . . . . . . . . . . . . . . . . 29		8.1. Normative References . . . . . . . . . . . . . . . . . . . 30
	8.2. Informative References . . . . . . . . . . . . . . . . . . 30		8.2. Informative References . . . . . . . . . . . . . . . . . . 30
	Appendix A. Implementation Considerations . . . . . . . . . . . . 31		Appendix A. Implementation Considerations . . . . . . . . . . . . 32
	A.1. Links from SPD Cache to Outbound SAD Entries . . . . . . . 31		A.1. Links from SPD Cache to Outbound SAD Entries . . . . . . . 32
	A.2. Creating Outbound SAs . . . . . . . . . . . . . . . . . . 32		A.2. Creating Outbound SAs . . . . . . . . . . . . . . . . . . 32
	Appendix B. Changelog . . . . . . . . . . . . . . . . . . . . . . 33		Appendix B. Changelog . . . . . . . . . . . . . . . . . . . . . . 33
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 36		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 37
	Intellectual Property and Copyright Statements . . . . . . . . . . 37		Intellectual Property and Copyright Statements . . . . . . . . . . 38
	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 [IKEv2], the IKE SAs and tunnel mode IPsec
	between the IP addresses that are used when the IKE_SA is		SAs are created implicitly between the IP addresses that are used
	established. These IP addresses are then used as the outer (tunnel		when the IKE_SA is established. These IP addresses are then used as
	header) addresses for tunnel mode IPsec packets. Currently, it is		the outer (tunnel header) addresses for tunnel mode IPsec packets
	not possible to change these addresses after the IKE_SA has been		(transport mode IPsec SAs are beyond the scope of this document).
	created.		Currently, it is not possible to change 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 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 involves expensive calculations		token card. Creating new SAs often involves expensive calculations
	and possibly a large number of round-trips. For these reasons, a		and possibly a large number of round-trips. For these reasons, a
	mechanism for updating the IP addresses of existing IKE and IPsec SAs		mechanism for updating the IP addresses of existing IKE and IPsec SAs
	is needed. The MOBIKE protocol described in this document provides		is needed. The MOBIKE protocol described in this 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 to the home wireless LAN. MOBIKE updates only the outer
	outer (tunnel header) addresses of IPsec SAs, and the addresses and		(tunnel header) addresses of IPsec SAs, and the addresses and other
	other traffic selectors used inside the tunnel stay unchanged. Thus,		traffic selectors used inside the tunnel stay unchanged. Thus,
	mobility can be (mostly) invisible to applications and their		mobility can be (mostly) invisible to applications and their
	connections using the VPN.		connections using the VPN.
	MOBIKE also supports more complex scenarios where the VPN gateway		MOBIKE also supports more complex scenarios where the VPN gateway
	also has several network interfaces: these interfaces could be		also has several network interfaces: these interfaces could be
	connected to different networks or ISPs, they may be a mix of IPv4		connected to different networks or ISPs, they may be a mix of IPv4
	and IPv6 addresses, and the addresses may change over time.		and IPv6 addresses, and the addresses may change over time.
	Furthermore, both parties could be VPN gateways relaying traffic for		Furthermore, both parties could be VPN gateways relaying traffic for
	other parties.		other parties.
	skipping to change at page 7, line 35 ¶		skipping to change at page 7, line 35 ¶
	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 Exchanges
	A simple MOBIKE exchange in a mobile scenario is illustrated below:		A simple MOBIKE exchange in a mobile scenario is illustrated below.
			The notation is based on [IKEv2] Section 1.2. In addition, the
			source/destination IP addresses and ports are shown for each packet:
			here IP_I1, IP_I2, IP_R1, and IP_R2 represent IP addresses used by
			the initiator and the responder.
	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_SOURCE_IP),		N(NAT_DETECTION_SOURCE_IP),
	N(NAT_DETECTION_DESTINATION_IP) -->		N(NAT_DETECTION_DESTINATION_IP) -->
	<-- (IP_R1:500 -> IP_I1:500)		<-- (IP_R1:500 -> IP_I1:500)
	HDR, SAr1, KEr, Nr,		HDR, SAr1, KEr, Nr,
	skipping to change at page 12, line 27 ¶		skipping to change at page 12, line 27 ¶
	and NAT Traversal MUST change to port 4500 if the correspondent also		and NAT Traversal MUST change to port 4500 if the correspondent also
	supports both, even if no NAT was detected between them (this way,		supports both, even if no NAT was detected between them (this way,
	there is no need to change the ports later if a a NAT is detected on		there is no need to change the ports later if a a NAT is detected on
	some other path).		some other path).
	3.4. Additional Addresses		3.4. Additional Addresses
	Both the initiator and responder MAY include one or more		Both the initiator and responder MAY include one or more
	ADDITIONAL_IP4_ADDRESS and/or ADDITIONAL_IP6_ADDRESS notifications in		ADDITIONAL_IP4_ADDRESS and/or ADDITIONAL_IP6_ADDRESS notifications in
	the IKE_AUTH exchange (in case of multiple IKE_AUTH exchanges, in the		the IKE_AUTH exchange (in case of multiple IKE_AUTH exchanges, in the
	message containing the SA payload).		message containing the SA payload). Here "ADDITIONAL_*_ADDRESS"
			means either an ADDITIONAL_IP4_ADDRESS or an ADDITIONAL_IP6_ADDRESS
			notification.
	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(MOBIKE_SUPPORTED),		N(MOBIKE_SUPPORTED),
	[N(ADDITIONAL_*_ADDRESS)+] } -->		[N(ADDITIONAL_*_ADDRESS)+] } -->
	<-- HDR, SK { IDr, [CERT], AUTH,		<-- HDR, SK { IDr, [CERT], AUTH,
	skipping to change at page 20, line 32 ¶		skipping to change at page 20, line 32 ¶
	from, not to the address contained in the NO_NATS_ALLOWED		from, not to the address contained in the NO_NATS_ALLOWED
	notification.		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. The exact number of
			retries is not specified in this document because it does not affect
			interoperability. However, because the IKE message will also be
			rejected if the attacker modifies the integrity checksum field, a
			reasonable number here would be the number of retries that is being
			used for normal retransmissions.
	If an UNEXPECTED_NAT_DETECTED notification is sent, the exchange		If an UNEXPECTED_NAT_DETECTED notification is sent, the exchange
	responder MUST NOT use the contents of the NO_NATS_ALLOWED		responder MUST NOT use the contents of the NO_NATS_ALLOWED
	notification for any other purpose than possibly logging the		notification for any other purpose than possibly logging the
	information for troubleshooting purposes.		information for troubleshooting purposes.
	3.10. Path Testing		3.10. 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
	skipping to change at page 25, line 50 ¶		skipping to change at page 25, line 50 ¶
	When this notification is used, communication through NATs and other		When this notification is used, communication through NATs and other
	address translators is impossible, so it is sent only when not doing		address translators is impossible, so it is sent only when not doing
	NAT Traversal. This feature is mainly intended for IPv6 and site-to-		NAT Traversal. This feature is mainly intended for IPv6 and site-to-
	site VPN cases, where the administrators may know beforehand that		site VPN cases, where the administrators may know beforehand that
	NATs are not present.		NATs are not present.
	5.2. IPsec Payload Protection		5.2. IPsec Payload 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 or be		should the traffic end up in an incorrect destination or be subject
	eavesdropped along the way.		to eavesdropping.
	However, security associations originally created for the protection		However, security associations originally created for the protection
	of a specific flow between specific addresses may be updated by		of a specific flow between specific addresses may be updated by
	MOBIKE later on. This has to be taken into account if the level of		MOBIKE later on. This has to be taken into account if the (outer) IP
	required protection depends on, for instance, the current location of		address of the peer was used when deciding what kind of IPsec SAs the
	the VPN client.		peer is allowed to create.
			For instance, the level of required protection might depend on the
			current location of the VPN client, or access might be allowed only
			from certain IP addresses.
	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.
			This is especially critical for traffic selector authorization. The
			(logical) Peer Authorization Database (PAD) contains the information
			used by IKEv2 when determining what kind of IPsec SAs a peer is
			allowed to create. This process is described in [IPsecArch] Section
			4.4.3. When a peer requests the creation of an IPsec SA with some
			traffic selectors, the PAD must contain "Child SA Authorization Data"
			linking the identity authenticated by IKEv2 and the addresses
			permitted for traffic selectors. See also [Clarifications] for a
			more extensive discussion.
			It is important to note that simply sending IKEv2 packets using some
			particular address does not automatically imply a permission to
			create IPsec SAs with that address in the traffic selectors.
			However, some implementations are known to use policies where simply
			being reachable at some address X implies a temporary permission to
			create IPsec SAs for address X. Here "being reachable" usually means
			the ability to send (or spoof) IP packets with source address X and
			receive (or eavesdrop) packets sent to X.
			Using this kind of policies or extensions with MOBIKE may need
			special care to enforce the temporary nature of the permission. For
			example, when the peer moves to some other address Y (and is no
			longer reachable at X), it might be necessary to close IPsec SAs with
			traffic selectors matching X. However, these interactions are beyond
			the scope of this document.
	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 or to deny service to the peers, but also to cause a denial-		traffic or to deny service to the peers, but also to cause a denial-
	of-service attack for a third party. For instance, a high-speed TCP		of-service attack for a third party. For instance, a high-speed TCP
	session or a multimedia stream may be redirected towards a victim		session or a multimedia stream may be redirected towards a victim
	host, causing its communications capabilities to suffer.		host, causing 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
	skipping to change at page 29, line 29 ¶		skipping to change at page 30, line 9 ¶
	UPDATE_SA_ADDRESSES TBD-BY-IANA5 (16396..40959)		UPDATE_SA_ADDRESSES TBD-BY-IANA5 (16396..40959)
	COOKIE2 TBD-BY-IANA7 (16396..40959)		COOKIE2 TBD-BY-IANA7 (16396..40959)
	NO_NATS_ALLOWED TBD-BY-IANA8 (16396..40959)		NO_NATS_ALLOWED TBD-BY-IANA8 (16396..40959)
	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, Elwyn Davies, Lakshminath Dondeti,
	Hoffman, James Kempf, Tero Kivinen, Pete McCann, Mohan Parthasarathy,		Francis Dupont, Paul Hoffman, James Kempf, Tero Kivinen, Pete McCann,
	Pekka Savola, Bill Sommerfeld, Maureen Stillman, Shinta Sugimoto,		Erik Nordmark, Mohan Parthasarathy, Pekka Savola, Bill Sommerfeld,
	Sami Vaarala, and Hannes Tschofenig. This document also incorporates		Maureen Stillman, Shinta Sugimoto, Sami Vaarala, and Hannes
	ideas and text from earlier MOBIKE-like protocol proposals, including		Tschofenig. This document also incorporates ideas and text from
	[AddrMgmt], [Kivinen], [MOPO], and [SMOBIKE], and the MOBIKE design		earlier MOBIKE-like protocol proposals, including [AddrMgmt],
	document [Design].		[Kivinen], [MOPO], and [SMOBIKE], and the MOBIKE 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),		RFC 4306, December 2005.
	October 2004.
	[IPsecArch]		[IPsecArch]
	Kent, S. and K. Seo, "Security Architecture for the		Kent, S. and K. Seo, "Security Architecture for the
	Internet Protocol", draft-ietf-ipsec-rfc2401bis-06 (work		Internet Protocol", RFC 4301, December 2005.
	in progress), March 2005.
	[KEYWORDS]		[KEYWORDS]
	Bradner, S., "Key words for use in RFCs to Indicate		Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", RFC 2119, March 1997.		Requirement Levels", RFC 2119, March 1997.
	8.2. Informative References		8.2. Informative References
	[AddrMgmt]		[AddrMgmt]
	Dupont, F., "Address Management for IKE version 2",		Dupont, F., "Address Management for IKE version 2",
	draft-dupont-ikev2-addrmgmt-07 (work in progress),		draft-dupont-ikev2-addrmgmt-08 (work in progress),
	May 2005.		November 2005.
	[Aura02] Aura, T., Roe, M., and J. Arkko, "Security of Internet		[Aura02] Aura, T., Roe, M., and J. Arkko, "Security of Internet
	Location Management", Proc. 18th Annual Computer Security		Location Management", Proc. 18th Annual Computer Security
	Applications Conference (ACSAC), December 2002.		Applications Conference (ACSAC), December 2002.
	[Bombing] Dupont, F., "A note about 3rd party bombing in Mobile		[Bombing] Dupont, F., "A note about 3rd party bombing in Mobile
	IPv6", draft-dupont-mipv6-3bombing-02 (work in progress),		IPv6", draft-dupont-mipv6-3bombing-03 (work in progress),
	June 2005.		December 2005.
			[Clarifications]
			Eronen, P. and P. Hoffman, "IKEv2 Clarifications and
			Implementation Guidelines",
			draft-eronen-ipsec-ikev2-clarifications-07 (work in
			progress), February 2006.
	[DNA4] Aboba, B., Carlson, J., and S. Cheshire, "Detecting		[DNA4] Aboba, B., Carlson, J., and S. Cheshire, "Detecting
	Network Attachment (DNA) in IPv4",		Network Attachment (DNA) in IPv4",
	draft-ietf-dhc-dna-ipv4-17 (work in progress),		draft-ietf-dhc-dna-ipv4-18 (work in progress),
	October 2005.		December 2005.
	[DNA6] Narayanan, S., Daley, G., and N. Montavont, "Detecting		[DNA6] Narayanan, S., Daley, G., and N. Montavont, "Detecting
	Network Attachment in IPv6 - Best Current Practices for		Network Attachment in IPv6 - Best Current Practices for
	hosts", draft-ietf-dna-hosts-02 (work in progress),		hosts", draft-ietf-dna-hosts-02 (work in progress),
	October 2005.		October 2005.
	[Design] Kivinen, T. and H. Tschofenig, "Design of the MOBIKE		[Design] Kivinen, T. and H. Tschofenig, "Design of the MOBIKE
	protocol", draft-ietf-mobike-design-04 (work in progress),		protocol", draft-ietf-mobike-design-07 (work in progress),
	October 2005.		January 2006.
	[ICMPAttacks]		[ICMPAttacks]
	Gont, F., "ICMP attacks against TCP",		Gont, F., "ICMP attacks against TCP",
	draft-gont-tcpm-icmp-attacks-05 (work in progress),		draft-gont-tcpm-icmp-attacks-05 (work in progress),
	October 2005.		October 2005.
	[Kivinen] Kivinen, T., "MOBIKE protocol",		[Kivinen] Kivinen, T., "MOBIKE protocol",
	draft-kivinen-mobike-protocol-00 (work in progress),		draft-kivinen-mobike-protocol-00 (work in progress),
	February 2004.		February 2004.
	skipping to change at page 32, line 26 ¶		skipping to change at page 33, line 10 ¶
	When an outbound packet requires IPsec processing but no suitable SA		When an outbound packet requires IPsec processing but no suitable SA
	exists, a new SA will be created. In this case, the host has to		exists, a new SA will be created. In this case, the host has to
	determine (1) who is the right peer for this SA, (2) whether the host		determine (1) who is the right peer for this SA, (2) whether the host
	already has an IKE_SA with this peer, and (3) if no IKE_SA exists,		already has an IKE_SA with this peer, and (3) if no IKE_SA exists,
	the IP address(es) of the peer for contacting it.		the IP address(es) of the peer for contacting it.
	Neither [IPsecArch] nor MOBIKE specifies how exactly these three		Neither [IPsecArch] nor MOBIKE specifies how exactly these three
	steps are carried out. [IPsecArch] Section 4.4.3.4 says:		steps are carried out. [IPsecArch] Section 4.4.3.4 says:
	For example, assume that IKE A receives an outbound packet		For example, assume that IKE A receives an outbound packet
	destined for IP address X, a host served by a security		destined for IP address X, a host served by a security gateway.
	gateway. RFC 2401 and 2401bis do not specify how A determines		RFC 2401 [RFC2401] and this document do not specify how A
	the address of the IKE peer serving X. However, any peer		determines the address of the IKE peer serving X. However, any
	contacted by A as the presumed representative for X must be		peer contacted by A as the presumed representative for X must be
	registered in the PAD in order to allow the IKE exchange to be		registered in the PAD in order to allow the IKE exchange to be
	authenticated. Moreover, when the authenticated peer asserts		authenticated. Moreover, when the authenticated peer asserts that
	that it represents X in its traffic selector exchange, the PAD		it represents X in its traffic selector exchange, the PAD will be
	will be consulted to determine if the peer in question is		consulted to determine if the peer in question is authorized to
	authorized to represent X.		represent X.
	In step 1, there may be more than one possible peer (e.g., several		In step 1, there may be more than one possible peer (e.g., several
	security gateways that are allowed to represent X). In step 3, the		security gateways that are allowed to represent X). In step 3, the
	host may need to consult a directory such as DNS to determine the		host may need to consult a directory such as DNS to determine the
	peer IP address(es).		peer IP address(es).
	When performing these steps, implementations may use information		When performing these steps, implementations may use information
	contained in the SPD, the PAD, and possibly some other		contained in the SPD, the PAD, and possibly some other
	implementation-specific databases. Regardless of how exactly the		implementation-specific databases. Regardless of how exactly the
	steps are implemented, it is important to remember that IP addresses		steps are implemented, it is important to remember that IP addresses
	skipping to change at page 33, line 10 ¶		skipping to change at page 33, line 42 ¶
	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 -07 to -08:
			o Clarified meaning of ADDITIONAL_*_ADDRESS and other notations.
			o Clarified number of retries and UNEXPECTED_NAT_DETECTED.
			o Added text about traffic selector authorization to security
			considerations.
			o Updated quotations to match RFC 4301.
			o Updated acknowledgements and references.
			o Small editorial fixes for IESG evaluation and IETF last call.
	Changes from -06 to -07:		Changes from -06 to -07:
	o Editorial fixes from AD evaluation.		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).
	skipping to change at page 37, line 41 ¶		skipping to change at page 38, line 41 ¶
	This document and the information contained herein are provided on an		This document and the information contained herein are provided on an
	"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS		"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
	OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET		OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
	ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,		ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
	INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE		INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
	INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED		INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
	WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.		WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
	Copyright Statement		Copyright Statement
	Copyright (C) The Internet Society (2005). This document is subject		Copyright (C) The Internet Society (2006). This document is subject
	to the rights, licenses and restrictions contained in BCP 78, and		to the rights, licenses and restrictions contained in BCP 78, and
	except as set forth therein, the authors retain all their rights.		except as set forth therein, the authors retain all their rights.
	Acknowledgment		Acknowledgment
	Funding for the RFC Editor function is currently provided by the		Funding for the RFC Editor function is currently provided by the
	Internet Society.		Internet Society.
End of changes. 29 change blocks.
	61 lines changed or deleted		123 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/