< draft-ietf-mip4-vpn-problem-statement-02.txt		draft-ietf-mip4-vpn-problem-statement-03.txt >
	Mobile IP Working Group F. Adrangi, Ed.		Mobile IP Working Group F. Adrangi, Ed.
	Internet-Draft intel		Internet-Draft intel
	Expires: August 14, 2004 H. Levkowetz, Ed.		Expires: April 4, 2005 H. Levkowetz, Ed.
	ipUnplugged		October 4, 2004
	February 14, 2004
	Problem Statement: Mobile IPv4 Traversal of VPN Gateways		Problem Statement: Mobile IPv4 Traversal of VPN Gateways
	<draft-ietf-mip4-vpn-problem-statement-02.txt>		draft-ietf-mip4-vpn-problem-statement-03
	Status of this Memo		Status of this Memo
	This document is an Internet-Draft and is subject to all provisions		This document is an Internet-Draft and is subject to all provisions
	of Section 10 of RFC2026.		of section 3 of RFC 3667. By submitting this Internet-Draft, each
			author represents that any 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 become aware will be disclosed, in accordance with
			RFC 3668.
	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 other		Task Force (IETF), its areas, and its working groups. Note that
	groups may also distribute working documents as Internet-Drafts.		other groups may also distribute working documents as
			Internet-Drafts.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress".		material or to cite them other than as "work in progress."
	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 August 14, 2004.		This Internet-Draft will expire on April 4, 2005.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2004). All Rights Reserved.		Copyright (C) The Internet Society (2004).
	Abstract		Abstract
	Deploying Mobile-IP v4 in networks which are connected to the		Deploying Mobile-IP v4 in networks which are connected to the
	Internet through a VPN (Virtual Private Network) gateway presents		Internet through a VPN (Virtual Private Network) gateway presents
	some problems which do not currently have well-described solutions.		some problems which do not currently have well-described solutions.
	This document aims to describe and illustrate these problems, and		This document aims to describe and illustrate these problems, and
	propose some guidelines for possible solutions.		propose some guidelines for possible solutions.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.1 Overview of the Problem . . . . . . . . . . . . . . . 3		1.1 Overview of the Problem . . . . . . . . . . . . . . . . . 3
	1.2 Specification of Requirements . . . . . . . . . . . . 4		1.2 Specification of Requirements . . . . . . . . . . . . . . 4
	1.3 Terminology . . . . . . . . . . . . . . . . . . . . . 4		1.3 Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
	2. MIP and VPN Deployment Scenarios . . . . . . . . . . . . . . 5		2. MIP and VPN Deployment Scenarios . . . . . . . . . . . . . . 4
	2.1 MIPv4 HA(s) Inside the Intranet behind a VPN Gateway . 5		2.1 MIPv4 HA(s) Inside the Intranet behind a VPN Gateway . . . 5
	2.2 VPN Gateway and MIPv4 HA(s) on the VPN domain border . 7		2.2 VPN Gateway and MIPv4 HA(s) on the VPN domain border . . . 6
	2.3 Combined VPN Gateway and MIPv4 HA . . . . . . . . . . 7		2.3 Combined VPN Gateway and MIPv4 HA . . . . . . . . . . . . 7
	2.4 MIPv4 HA(s) Outside the VPN domain . . . . . . . . . . 8		2.4 MIPv4 HA(s) Outside the VPN domain . . . . . . . . . . . . 8
	2.5 Combined VPN Gateway and MIPv4 HA(s) on the Local Link 9		2.5 Combined VPN Gateway and MIPv4 HA(s) on the Local Link . . 9
	3. Deployment Scenarios Selection . . . . . . . . . . . . . . . 10		3. Deployment Scenarios Selection . . . . . . . . . . . . . . . 10
	4. Problem statement . . . . . . . . . . . . . . . . . . . . . 11		4. Problem statement . . . . . . . . . . . . . . . . . . . . . 10
	4.1 Registering in co-located mode . . . . . . . . . . . . 12		4.1 Registering in co-located mode . . . . . . . . . . . . . . 11
	4.2 Registering via an FA . . . . . . . . . . . . . . . . 13		4.2 Registering via an FA . . . . . . . . . . . . . . . . . . 12
	4.3 Summary: MIP Incompatibilities with IPsec-VPN		4.3 Summary: MIP Incompatibilities with IPsec-based VPN
	Gateways . . . . . . . . . . . . . . . . . . . . . . . . . . 14		Gateways . . . . . . . . . . . . . . . . . . . . . . . . . 14
	5. Solution Guidelines . . . . . . . . . . . . . . . . . . . . 15		5. Solution Guidelines . . . . . . . . . . . . . . . . . . . . 15
	5.1 Preservation of Existing VPN Infrastructure . . . . . 15		5.1 Preservation of Existing VPN Infrastructure . . . . . . . 15
	5.2 Software Upgrades to Existing VPN Client and Gateways 15		5.2 Software Upgrades to Existing VPN Client and Gateways . . 15
	5.3 IPsec Protocol . . . . . . . . . . . . . . . . . . . . 15		5.3 IPsec Protocol . . . . . . . . . . . . . . . . . . . . . . 15
	5.4 Multi-Vendor Interoperability . . . . . . . . . . . . 15		5.4 Multi-Vendor Interoperability . . . . . . . . . . . . . . 15
	5.5 MIPv4 Protocol . . . . . . . . . . . . . . . . . . . . 15		5.5 MIPv4 Protocol . . . . . . . . . . . . . . . . . . . . . . 15
	5.6 Handoff Overhead . . . . . . . . . . . . . . . . . . . 16		5.6 Handoff Overhead . . . . . . . . . . . . . . . . . . . . . 16
	5.7 Scalability, Availability, Reliability, and Performance 16		5.7 Scalability, Availability, Reliability, and Performance . 16
	5.8 Functional Entities . . . . . . . . . . . . . . . . . 16		5.8 Functional Entities . . . . . . . . . . . . . . . . . . . 16
	5.9 Implications of Intervening NAT Gateways . . . . . . . 16		5.9 Implications of Intervening NAT Gateways . . . . . . . . . 16
	5.10 Security Requirements . . . . . . . . . . . . . . . . 16		5.10 Security Requirements . . . . . . . . . . . . . . . . . 16
	6. Security Considerations . . . . . . . . . . . . . . . . . . 16		6. Security Considerations . . . . . . . . . . . . . . . . . . 16
	7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16		7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16
	Normative References . . . . . . . . . . . . . . . . . . . . 17		8. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
	Informative References . . . . . . . . . . . . . . . . . . . 17		8.1 Normative References . . . . . . . . . . . . . . . . . . . . 17
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 17		8.2 Informative References . . . . . . . . . . . . . . . . . . . 17
	Intellectual Property and Copyright Statements . . . . . . . 20		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 18
			Intellectual Property and Copyright Statements . . . . . . . 19
	Adrangi, Ed., et al. Expires August 14, 2004 2]		1. Introduction
	1. Introduction
	Mobile IP [RFC3344] agents are being deployed in enterprise networks		Mobile IP [RFC3344] agents are being deployed in enterprise networks
	to enable mobility across wired and wireless LANs while roaming		to enable mobility across wired and wireless LANs while roaming
	inside the enterprise Intranet. With the growing deployment of IEEE		inside the enterprise Intranet. With the growing deployment of IEEE
	802.11 access points ("hot spots") in public places such as hotels,		802.11 access points ("hot spots") in public places such as hotels,
	airports, and convention centers, and wireless WAN data networks such		airports, and convention centers, and wireless WAN data networks such
	as GPRS, the need for enabling mobile users to maintain their		as General Packet Radio Service (GPRS), the need for enabling mobile
	transport connections and constant reachability while connecting back		users to maintain their transport connections and constant
	to their target "home" networks protected by Virtual Private		reachability while connecting back to their target "home" networks
	Network (VPN) technology is increasing. This implies that Mobile IP		protected by Virtual Private Network (VPN) technology is increasing.
	and VPN technologies have to coexist and function together in order		This implies that Mobile IP and VPN technologies have to coexist and
	to provide mobility and security to the enterprise mobile users.		function together in order to provide mobility and security to the
			enterprise mobile users.
	The goal of this draft is to:		The goal of this document is to:
	o Identify and describe practical deployment scenarios for Mobile IP		o Identify and describe practical deployment scenarios for Mobile IP
	and VPN in enterprise and operator environments.		and VPN in enterprise and operator environments.
	o Identify example usage scenarios for remote users roaming outside		o Identify example usage scenarios for remote users roaming outside
	the "home" network protected by a VPN gateway.		the "home" network protected by a VPN gateway.
	o Articulate the problems resulting from Mobile IP and VPN		o Articulate the problems resulting from Mobile IP and VPN
	coexistence. Specify a set of framework guidelines to evaluate		coexistence.
	proposed solutions, supporting multi-vendor seamless IPv4 mobility		o Specify a set of framework guidelines to evaluate proposed
	across IPsec-based VPN gateways.		solutions to supporting multi-vendor seamless IPv4 mobility across
			IPsec-based VPN gateways.
	1.1 Overview of the Problem
	Real life networks typically consist of three different domains from		1.1 Overview of the Problem
	a corporate point of view. The first domain is the Internet (i.e.,
	the untrusted external network). The second domain is the trusted
	Intranet (also referred to as VPN Domain in this document).
	The third domain is the DMZ, which is between the Internet and the
	Intranet.
	Access to the Intranet is typically guarded by both a firewall and a		Access to the Intranet is typically guarded by both a firewall and a
	VPN device. The Intranet can only be accessed by respecting the		VPN device. The Intranet can only be accessed by respecting the
	security policies in the firewall and the VPN device.		security policies in the firewall and the VPN device.
	When MIP is deployed in a corporate network behind a VPN device,		When MIP is deployed in a corporate Intranet (also referred to as VPN
	roaming between these two different domains (i.e., the untrusted		domain), roaming between the Intranet (i.e., trusted domain) and the
	Internet and the trusted Intranet) becomes problematic. It would be		internet (i.e., untrusted domain) becomes problematic. It would be
	desirable to have seamless session mobility between the two domains,		desirable to have seamless session mobility between the two domains,
	because MIP was designed for session mobility regardless of the		because MIP was designed for session mobility regardless of the
	network point of attachment. Unfortunately, the current MIP		network point of attachment. Unfortunately, the current MIP
	standards fall short of this promise for an important customer		standards fall short of this promise for an important customer
	segment, corporate users behind VPN gateways.		segment: corporate users (using VPN for remote access) who desire to
			add mobility support because of a need to have continuous access to
	Because current standards do not provide for session mobility across		Intranet resources while roaming outside the Intranet from one subnet
	these two domains the possibility of finding a solution to this		to another, or between the VPN domain and the Internet.
	problem has been investigated. The goal is to provide seamless
	session mobility when the mobile node moves between these two domains
	or between subnets in either domain.
	From the beginning it was also assumed that VPNs and		From the beginning it was also assumed that VPNs and firewalls were
	firewalls were to be taken as more or less granted because they have		to be taken as more or less granted because they have much wider
	much wider deployments than MIP at the present. Therefore any		deployments than MIP at the present. Therefore any solutions would
	solutions would need to minimize impact on existing VPN and		need to minimize impact on existing VPN and firewall deployments,
	firewall deployments, related standards and "de facto" standards.		related standards and "de facto" standards.
	1.2 Specification of Requirements		1.2 Specification of Requirements
	In this document, several words are used to signify the requirements		In this document, several words are used to signify the requirements
	of the specification. These words are often capitalized. The key		of the specification. These words are often capitalized. The key
	words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",		words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
	"SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document		"SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document
	are to be interpreted as described in [RFC2119].		are to be interpreted as described in [RFC2119].
	1.3 Terminology		1.3 Terminology
	MIPv4 Mobile IP for IPv4 [RFC3344]		MIPv4 Mobile IP for IPv4 [RFC3344]
	MIPv6 Mobile IP for IPv6		MIPv6 Mobile IP for IPv6
	VPN Virtual Private Network		VPN Virtual Private Network
	GW Gateway		GW Gateway
	VPN Domain		VPN Domain
	An Intranet protected by a VPN gateway.		An Intranet protected by a VPN gateway.
	DMZ		DMZ
	(Demilitarized Zone) A small network inserted as a "neutral		(Demilitarized Zone) A small network inserted as a "neutral
	zone" between a company's private network and the outside		zone" between a company's private network and the outside
	public network to prevent outside users from getting direct		public network to prevent outside users from getting direct
	access to the company's private network		access to the company's private network
	Home Network		Home Network
	A network, possibly virtual, having a network prefix matching		A network, possibly virtual, having a network prefix matching
	that of a mobile node's home address.		that of a mobile node's home address.
	Home Agent		Home Agent
	A router on a mobile node's home network which tunnels		A router on a mobile node's home network which tunnels
	datagrams for delivery to the mobile node when it is away		datagrams for delivery to the mobile node when it is away
	from home, and maintains current location information for the		from home, and maintains current location information for the
	mobile node.		mobile node.
			MN
			Refers to a mobile node that runs both MIP and IPsec-based
			VPN client software.
	MIPv4 inside IPsec-ESP tunnel		MIPv4 inside IPsec-ESP tunnel
	MIPv4 packet is encapsulated in an IPsec-ESP tunnel		MIPv4 packet is encapsulated in an IPsec-ESP tunnel
	established between the Mobile Node and the VPN gateway.		established between the Mobile Node and the VPN gateway.
	IPsec-ESP inside MIPv4 tunnel		IPsec-ESP inside MIPv4 tunnel
	IPsec-ESP packet is encapsulated in an MIPv4 tunnel		IPsec-ESP packet is encapsulated in an MIPv4 tunnel
	established between the Mobile Node and the home agent.		established between the Mobile Node and the home agent.
	2. MIP and VPN Deployment Scenarios		2. MIP and VPN Deployment Scenarios
	This section describes a set of deployment scenarios where MIP agents		This section describes a set of deployment scenarios where MIP agents
	and VPN gateways have to coexist to provide mobility and security.		and VPN gateways have to coexist to provide mobility and security.
	The intention is to identify practical deployment scenarios for MIP		The intention is to identify practical deployment scenarios for MIP
	and VPNs where MIP technology might be extended to solve problems		and VPNs where MIP technology might be extended to solve problems
	resulting from the desire for co-existence.		resulting from the desire for co-existence.
	In all scenarios, "MN" refers to a mobile node that runs both MIP and		The network topology in the following diagrams consists of an
	IPsec-based VPN client software. The foreign network might or		Intranet connected to the public network (i.e., Internet). Here, the
	might not employ a foreign agent. And, the term "Intranet"		word "Intranet" refers to a private network (where private addresses
	refers to a private network protected by a VPN gateway and perhaps a		[RFC1918] are typically used) protected by a VPN gateway and perhaps
	layer-3 transparent or non-transparent firewall. Please note that		a layer-3 transparent or non-transparent firewall. When private
	firewalls are purposely omitted from the following scenarios,		addresses are used, the non-transparent firewall also functions as a
	because they may be installed in a number of different ways, and the		Network Address Translator (NAT) or Network Address Port Translator
	fact that this draft's focus is the relationship between MIP and VPN.		(NAPT) bridging between the two address realms (i.e., the Intranet
			and the internet).
	Finally, the scenarios assume that encryption is not enforced inside		Firewalls may be placed on either side of the VPN gateway - referred
	the VPN domain because 1) the VPN domain (Intranet) is viewed as a		to as inner and outer firewalls. The inner and outer firewalls
	trusted network, and users allowed inside the Intranet are also		typically inspect outbound traffic (i.e., from the Intranet to the
	trusted 2) it is a common VPN deployment practice where the VPN is		Internet) and inbound traffic (i.e., from the Internet to the
	used to guard the Intranet resources from unauthorized users attached		Intranet) respectively. When a firewall is present, it MUST be
	to an untrusted network, and to provide a secure communication		configured to allow Mobile IP traffic (both control and tunneled data
	channel for authorized users to access resources inside the Intranet		packets) go through. As our focus here is the relationship between
	from outside.		MIP and VPN, we have purposely omitted firewall from the following
			scenarios in order to keep things simple.
	The following sub-sections introduce five representative		It is assumed that encryption is not enforced inside the VPN domain
	combinations of MIPv4 HA and VPN gateway placement.		because: 1) the VPN domain (Intranet) is viewed as a trusted network,
			and users allowed inside the Intranet are also trusted 2) it is a
			common VPN deployment practice where the VPN is used to guard the
			Intranet resources from unauthorized users attached to an untrusted
			network, and to provide a secure communication channel for authorized
			users to access resources inside the Intranet from outside.
	2.1 MIPv4 HA(s) Inside the Intranet behind a VPN Gateway		The following sub-sections introduce five representative combinations
			of MIPv4 HA and VPN gateway placement.
	MIPv4 HAs are deployed inside the Intranet protected by a VPN		In order to give a reasonably complete survey of MIPv4 and VPN
			co-existence scenarios, the ones in Section 2.3 and Section 2.5 are
			included even though, as covered in more detail below, there are no
			co-existence problems to be solved in these two cases.
			2.1 MIPv4 HA(s) Inside the Intranet behind a VPN Gateway
			MIPv4 HAs are deployed inside the Intranet protected by a VPN
	gateway, and are not directly reachable by the MNs outside the		gateway, and are not directly reachable by the MNs outside the
	Intranet.		Intranet.
	..Foreign Network.. .....VPN Domain..(Intranet).....		..Foreign Network.. .....VPN Domain..(Intranet).....
	. . . .		. . . .
	. +----+ +----+ . +----+ +-------+ +-------+ .		. +----+ +----+ . +----+ +-------+ +-------+ .
	. |MNs | | FA | . | VPN| | Router| | HA | .		. |MNs | | FA | . | VPN| | Router| | HA | .
	. |away| | | .<=========>| | | 1..n | | 1..n | .		. |away| | | .<=========>| | | 1..n | | 1..n | .
	. +----+ +----+ . | GW | +-------+ +-------+ .		. +----+ +----+ . | GW | +-------+ +-------+ .
	. . +----+ .		. . +----+ .
	skipping to change at page 6, line 25 ¶		skipping to change at page 6, line 25 ¶
	. +-------+ +-------+ .		. +-------+ +-------+ .
	. .		. .
	................................		................................
	Figure 1		Figure 1
	Direct application of MIPv4 standards [RFC3344] is successfully used		Direct application of MIPv4 standards [RFC3344] is successfully used
	to provide mobility for users inside the Intranet. However, mobile		to provide mobility for users inside the Intranet. However, mobile
	users outside the Intranet can only access the Intranet resources		users outside the Intranet can only access the Intranet resources
	(e.g., MIP agents) through the VPN gateway, which will allow only		(e.g., MIP agents) through the VPN gateway, which will allow only
	authenticated IPsec traffic inside. This implies that the MIPv4		authenticated IPsec traffic inside. This implies that the MIPv4
	traffic has to run inside IPsec, which leads to two distinct		traffic has to run inside IPsec, which leads to two distinct
	problems:		problems:
	1. When the foreign network has an FA deployed (as in e.g. CDMA		1. When the foreign network has an FA deployed (as in e.g. CDMA
	2000), MIPv4 registration becomes impossible. This is because		2000), MIPv4 registration becomes impossible. This is because
	the MIPv4 traffic between MN and VPN gateway is encrypted and the		the MIPv4 traffic between MN and VPN gateway is encrypted and the
	FA (which is likely in a different administrative domain) cannot		FA (which is likely in a different administrative domain) cannot
	inspect the MIPv4 headers needed for relaying the MIPv4 packets.		inspect the MIPv4 headers needed for relaying the MIPv4 packets.
	Please see Section 4.2 for more details.		Please see Section 4.2 for more details.
	2. In co-located mode, successful registration is possible but the		2. In co-located mode, successful registration is possible but the
	VPN tunnel has to be re-negotiated every time the MN changes its		VPN tunnel has to be re-negotiated every time the MN changes its
	point of network attachment.		point of network attachment.
	Please note that the VPN tunnel re-negotiation problem can be
	avoided by the work that the MOBIKE workgroup has been chartered
	to accomplish.
	These problems are articulated in Section 4.		These problems are articulated in Section 4.
	This deployment scenario may not be common yet, but it is practical		This deployment scenario may not be common yet, but it is practical
	and becoming important as there is an increasing need for providing		and becoming important as there is an increasing need for providing
	corporate remote users with continuous access to the Intranet		corporate remote users with continuous access to the Intranet
	resources.		resources.
	2.2 VPN Gateway and MIPv4 HA(s) on the VPN domain border		2.2 VPN Gateway and MIPv4 HA(s) on the VPN domain border
	A MIPv4 HA is deployed on the VPN domain border (e.g., in the DMZ)		A MIPv4 HA is deployed on the VPN domain border (e.g., in the DMZ)
	together with the VPN gateway, and it is directly reachable by MNs		together with the VPN gateway, and it is directly reachable by MNs
	inside or outside the Intranet.		inside or outside the Intranet.
	..Foreign Network.. .....VPN Domain..(Intranet).....		..Foreign Network.. .....VPN Domain..(Intranet).....
	. . . .		. . . .
	. +----+ +----+ . +----+ +-------+ .		. +----+ +----+ . +----+ +-------+ .
	. |MNs | | FA | . | VPN| | Router| .		. |MNs | | FA | . | VPN| | Router| .
	. |away| | | .<=========>| | | 1..n | .		. |away| | | .<=========>| | | 1..n | .
	skipping to change at page 7, line 27 ¶		skipping to change at page 7, line 21 ¶
	. . || +----+ .		. . || +----+ .
	. . || +----+ +-------+ +-------+ .		. . || +----+ +-------+ +-------+ .
	. . ++====>| HA | | CN | | MNs | .		. . ++====>| HA | | CN | | MNs | .
	................... | | | 1..n | | home | .		................... | | | 1..n | | home | .
	+----+ +-------+ +-------+ .		+----+ +-------+ +-------+ .
	. .		. .
	................................		................................
	Figure 2		Figure 2
	The MIPv4 HA has a public interface connected to the Internet, and a		Please note that in deployments where the security policy prohibits
			direct communication between the MN (roaming outside the Intranet)
			and outside machines, the HA can be configured to forward only
			encrypted traffic from/to the MN.
			The MIPv4 HA has a public interface connected to the Internet, and a
	private interface attached to the Intranet. Mobile users will most		private interface attached to the Intranet. Mobile users will most
	likely have a virtual home network associated with the MIPv4 HA's		likely have a virtual home network associated with the MIPv4 HA's
	private interface, so that the mobile users are always away from home		private interface, so that the mobile users are always away from home
	and hence registered with the MIPv4 HA. Furthermore, in deployments		and hence registered with the MIPv4 HA. Furthermore, in deployments
	where the VPN gateway and the HA are placed in a corporate DMZ, this		where the VPN gateway and the HA are placed in a corporate DMZ, this
	implies that MIPv4 traffic will always be routed through the		implies that MIPv4 traffic will always be routed through the DMZ
	DMZ (regardless of whether MNs are located outside or inside the		(regardless of whether MNs are located outside or inside the
	Intranet), which may not be acceptable by IT departments in large		Intranet), which may not be acceptable by IT departments in large
	corporations.		corporations.
	This deployment can be used with two different configurations: "MIPv4		This deployment can be used with two different configurations: "MIPv4
	inside IPsec-ESP tunnel" and "IPsec-ESP inside MIPv4 tunnel". The		inside IPsec-ESP tunnel" and "IPsec-ESP inside MIPv4 tunnel". The
	"MIPv4 inside IPsec-ESP tunnel" has the same problems as the scenario		"MIPv4 inside IPsec-ESP tunnel" has the same problems as the scenario
	of Section 2.1 (namely, MIPv4 registration becomes impossible when		of Section 2.1 (namely, MIPv4 registration becomes impossible when
	the registration is to be done via an FA and furthermore in		the registration is to be done via an FA and furthermore in
	co-located mode, the VPN tunnel has to be re-negotiated every time		co-located mode, the VPN tunnel has to be re-negotiated every time
	the MN changes its point of attachment). The "IPsec-ESP inside MIPv4		the MN changes its point of attachment). The "IPsec-ESP inside MIPv4
	tunnel" does not have problems described in Section 2.1, however it		tunnel" does not have problems described in Section 2.1, however it
	will require some modifications to the routing logic of the MIPv4 HA		will require some modifications to the routing logic of the MIPv4 HA
	or the VPN gateway.		or the VPN gateway.
	2.3 Combined VPN Gateway and MIPv4 HA		2.3 Combined VPN Gateway and MIPv4 HA
	This is similar to deployment scenario described in Section 2.2, with		This is similar to deployment scenario described in Section 2.2, with
	the exception that the VPN gateway and MIPv4 HA are running on the		the exception that the VPN gateway and MIPv4 HA are running on the
	same physical machine.		same physical machine.
	..Foreign Network.. .....VPN Domain..(Intranet).....		..Foreign Network.. .....VPN Domain..(Intranet).....
	. . . .		. . . .
	. +----+ +----+ . +----+ +-------+ .		. +----+ +----+ . +----+ +-------+ .
	. |MNs | | FA | . | VPN| | Router| .		. |MNs | | FA | . | VPN| | Router| .
	. |away| | | .<==========| GW | | 1..n | .		. |away| | | .<==========| GW | | 1..n | .
	skipping to change at page 8, line 24 ¶		skipping to change at page 8, line 23 ¶
	. | CN | | MNs | .		. | CN | | MNs | .
	. | 1..n | | home | .		. | 1..n | | home | .
	. +-------+ +-------+ .		. +-------+ +-------+ .
	. .		. .
	................................		................................
	Figure 3		Figure 3
	Running MIPv4 HA and VPN on the same machine resolves routing		Running MIPv4 HA and VPN on the same machine resolves routing
	related issues that exist in Section 2.2 when a "IPsec-ESP inside		related issues that exist in Section 2.2 when a "IPsec-ESP inside
	MIPv4 tunnel" configuration is used. However, it does not promote		MIPv4 tunnel" configuration is used. However, it does not promote
	multi-vendor interoperability in environments where MIPv4 HA and VPN		multi-vendor interoperability in environments where MIPv4 HA and VPN
	technologies must be acquired from different vendors.		technologies must be acquired from different vendors.
	2.4 MIPv4 HA(s) Outside the VPN domain		2.4 MIPv4 HA(s) Outside the VPN domain
	In this scenario, MIPv4 HAs are deployed outside the Intranet (e.g.,		In this scenario, MIPv4 HAs are deployed outside the Intranet (e.g.,
	in an operator network), as depicted in Figure 4 below.		in an operator network), as depicted in Figure 4 below.
	..Foreign Network.. .....VPN Domain..(Intranet).....		..Foreign Network.. .....VPN Domain..(Intranet).....
	. . . .		. . . .
	. +----+ +----+ . +----+ +-------+ .		. +----+ +----+ . +----+ +-------+ .
	. |MNs | | FA | . | VPN| | Router| .		. |MNs | | FA | . | VPN| | Router| .
	. |away| | | .<==========| GW | | 1..n | .		. |away| | | .<==========| GW | | 1..n | .
	. +----+ +----+ . /\ | | +-------+ .		. +----+ +----+ . /\ | | +-------+ .
	skipping to change at page 9, line 24 ¶		skipping to change at page 8, line 51 ¶
	.....MIPv4 Home.... || | | | 1..n | | home | .		.....MIPv4 Home.... || | | | 1..n | | home | .
	. .<===++ | | +-------+ +-------+ .		. .<===++ | | +-------+ +-------+ .
	. +------+ . +----+ .		. +------+ . +----+ .
	. | HAs | . . .		. | HAs | . . .
	. | 1..n | . ................................		. | 1..n | . ................................
	. +------+ .		. +------+ .
	...................		...................
	Figure 4		Figure 4
	In this deployment scenario the goal is to provide remote users with		The IPsec tunnel end-points will be the MN and the VPN gateway. The
	continuous access to the Intranet resources while they are roaming		'home network' will most likely be a virtual home network, located at
	outside the Intranet only (i.e., mobility is not supported inside the		the HA, through which authorized remote users (i.e., the users have
	Intranet). In this case it is most practical to run IPsec-ESP inside		successfully established a connection to the corporate VPN) can reach
	a MIPv4 tunnel (i.e., MIPv4 tunnel end-points are the MN and the HA;		the Corporate Intranet and maintain their transport session
	the IPsec-ESP packet from the MN and to the VPN gateway is		connectivity while roaming outside the Intranet from one subnet to
	encapsulated in the MIPv4 tunnel) as the MNs can register with the HA		another. Please note that this deployment scenario does not support
	without establishing an IPsec tunnel to the VPN gateway. This should		mobility inside the Intranet.
	work without any technical problems. The IPsec tunnel end-points
	will be the MN and the VPN gateway. The 'home network' will be a
	virtual home network, located at the HA, from which it is possible to
	reach the Corporate Intranet through the VPN gateway.
	2.5 Combined VPN Gateway and MIPv4 HA(s) on the Local Link		In this case it is most practical to run IPsec-ESP inside a MIPv4
			tunnel (i.e., MIPv4 tunnel end-points are the MN and the HA; the
			IPsec-ESP packet from the MN and to the VPN gateway is encapsulated
			in the MIPv4 tunnel) as the MNs can register with the HA without
			establishing an IPsec tunnel to the VPN gateway. This should work
			without any technical problems.
			2.5 Combined VPN Gateway and MIPv4 HA(s) on the Local Link
	This is similar to the deployment scenario described in Section 2.3,		This is similar to the deployment scenario described in Section 2.3,
	with the difference that the VPN gateway/HA is sitting on the local		with the difference that the VPN gateway/HA is sitting on the local
	link. In this the VPN gateway and HA would most naturally be		link. In this case the VPN gateway and HA would most naturally be
	co-located in the same box, although this is in no way a requirement.		co-located in the same box, although this is in no way a requirement.
			The VPN/HA is assumed to be reachable from the external network, i.e.
			it is assumed to have a public IP address, and the firewall is
			assumed to be configured to allow direct access to the VPN/HA from
			the external network.
	..Foreign Network.. .....VPN Domain..(Intranet).....		..Foreign Network.. .....VPN Domain..(Intranet).....
	. . . .		. . . .
	. +----+ +----+ . +------+ +-------+ +-------+ .		. +----+ +----+ . +------+ +-------+ +-------+ .
	. |MNs | | FA | . | Fire | | Router| | VPN/HA| .		. |MNs | | FA | . | Fire | | Router| | VPN/HA| .
	. |away| | | .<=======>| wall | | 1..n | | 1..n | .		. |away| | | .<=======>| wall | | 1..n | | 1..n | .
	. +----+ +----+ . | | +-------+ +-------+ .		. +----+ +----+ . | | +-------+ +-------+ .
	. . | NAT | .		. . | NAT | .
	................... +------+ +-------+ +-------+ .		................... +------+ +-------+ +-------+ .
	. | CN | | MNs | .		. | CN | | MNs | .
	. | 1..n | | home | .		. | 1..n | | home | .
	. +-------+ +-------+ .		. +-------+ +-------+ .
	. .		. .
	................................		................................
	Figure 5		Figure 5
	This deployment works today without any technical problems with		This deployment works today without any technical problems with
	IPsec-ESP running inside a MIPv4 tunnel. If however MIPv4 is run		IPsec-ESP running inside a MIPv4 tunnel. If you were to run MIPv
	inside the IPsec-ESP tunnel it has the same problems as in Section		inside the IPsec-ESP tunnel it would have the same problems as in
	2.1 (namely, MIPv4 registration becomes impossible when the		Section 2.1, so it is deployed with the IPsec-ESP running inside the
	registration is to be done via an FA and furthermore in co-located		MIPv4 tunnel. This deployment is not practical for large deployments
	mode, the VPN tunnel has to be re-negotiated every time the MN		(on the order of thousands of users) because of the large and
	changes its point of attachment). This deployment is not common or		distributed security perimeter.
	practical for large deployments (on the order of thousands of users)
	because of the large and distributed security perimeter.
	3. Deployment Scenarios Selection		3. Deployment Scenarios Selection
	The deployment scenarios described in Section 2 were evaluated to		The deployment scenarios described in Section 2 were evaluated to
	identify the ones most in need of solving. The evaluation was done		identify the ones most in need of solving. The evaluation was done
	based on two main criteria: 1) Is the deployment scenario common and		based on two main criteria: 1) Is the deployment scenario common and
	practical? and 2) Does the deployment scenario reveal any problems		practical? and 2) Does the deployment scenario reveal any problems
	resulting from MIPv4 and VPN coexistence?		resulting from MIPv4 and VPN coexistence?
	There was a consensus about importance and practicality of the		The authors believe that the scenario in Section 2.1 is the most
	scenario in Section 2.1 because of rising needs to provide corporate		important and practical one because of rising needs to provide
	remote users with continuous access to their Intranet resources.		corporate remote users with continuous access to their Intranet
	After analyzing each scenario one realizes that problems occurring in		resources. After analyzing each scenario one realizes that problems
	scenarios in Section 2.2 and Section 2.4 are either the same as or a		occurring in scenarios in Section 2.2 and Section 2.4 are either the
	subset of those in the scenario in Section 2.1. Therefore, solving		same as or a subset of those in the scenario in Section 2.1.
	the scenario in Section 2.1 will also solve the scenarios in Section		Therefore, solving the scenario in Section 2.1 will also solve the
	2.2 and Section 2.4. The scenarios in Section 2.3 and Section 2.5 do		scenarios in Section 2.2 and Section 2.4. The scenarios in Section
	not introduce functional problems resulting from MIPv4 and VPN		2.3 and Section 2.5 do not introduce functional problems resulting
	co-existence, hence there is no need to seek a solution. A solution		from MIPv4 and VPN co-existence, hence there is no need to seek a
	for the deployment scenario in Section 2.1 is therefore seen as		solution. A solution for the deployment scenario in Section 2.1 is
	essential, and this in turn can also be applied to solve problems in		therefore seen as essential, and this in turn can also be applied to
	other scenarios. For the remainder of this draft, we will articulate		solve problems in other scenarios. In subsequent sections, we will
	the roaming scenarios, the problems, and the solution guidelines		articulate the roaming scenarios, the problems, and the solution
	relevant to the scenario in Section 2.1.		guidelines relevant to the scenario in Section 2.1.
	4. Problem statement		4. Problem statement
	This section describes roaming scenarios corresponding to the		This section describes roaming scenarios corresponding to the
	deployment scenario in Section 2.1 where an MN needs to have		deployment scenario in Section 2.1 where an MN needs to have
	continuous access to the Intranet resources regardless of whether it		continuous access to the Intranet resources regardless of whether it
	is roaming inside or outside the Intranet, and their associated		is roaming inside or outside the Intranet, and their associated
	problems. The scenarios are constructed based on a multi-subnetted,		problems. The scenarios are constructed based on a multi-subnetted,
	MIPv4-enabled Intranet (hereafter, referred to as Intranet or VPN		MIPv4-enabled Intranet (hereafter, referred to as Intranet or VPN
	domain) protected by an IPsec-based VPN gateway as depicted in Figure		domain) protected by an IPsec-based VPN gateway as depicted in Figure
	6.		6.
	....Internet....... .....VPN Domain..(Intranet).....		....Internet....... .....VPN Domain..(Intranet).....
	. . . .		. . . .
	. +----+ . +----+ +-------+ +-------+ .		. +----+ . +----+ +-------+ +-------+ .
	. |MNs | . | VPN| | Router| | VPN/HA| .		. |MNs | . | VPN| | Router| | VPN/HA| .
	. |away| .<=========>| | | 1..n | | 1..n | .		. |away| .<=========>| | | 1..n | | 1..n | .
	. +----+ . | GW | +-------+ +-------+ .		. +----+ . | GW | +-------+ +-------+ .
	skipping to change at page 12, line 21 ¶		skipping to change at page 11, line 43 ¶
	. . | | .		. . | | .
	................... | | +-------+ +-------+ .		................... | | +-------+ +-------+ .
	| | | CN | | MNs | .		| | | CN | | MNs | .
	..802.11 Wireless.. <====>| | | 1..n | | home | .		..802.11 Wireless.. <====>| | | 1..n | | home | .
	. Network . +----+ +-------+ +-------+ .		. Network . +----+ +-------+ +-------+ .
	. . . .		. . . .
	................... ................................		................... ................................
	Figure 7: IEEE 802.11 Wireless deployment outside the home network		Figure 7: IEEE 802.11 Wireless deployment outside the home network
	4.1 Registering in co-located mode		4.1 Registering in co-located mode
	In co-located mode, the IPsec tunnel endpoints would be at the MN and		In co-located mode, the IPsec tunnel endpoints would be at the MN and
	the VPN gateway, which (supposing we have the scenario described in		the VPN gateway, which (supposing we have the scenario described in
	Section 2.1) results in the mobile-ip tunnel from MN to HA being		Section 2.1) results in the mobile-ip tunnel from MN to HA being
	encapsulated inside the IPsec tunnel. See Figure 8 below. This		encapsulated inside the IPsec tunnel. See Figure 8 below. This
	scenario is still possible, but has some major drawbacks.		scenario is still possible, but has some major drawbacks.
	....Internet....... .....VPN Domain..(Intranet).....		....Internet....... .....VPN Domain..(Intranet).....
	. . . .		. . . .
	. +----+ . +----+ +-------+ +-------+ .		. +----+ . +----+ +-------+ +-------+ .
	. |MNs | . | VPN| | Router| | VPN/HA| .		. |MNs | . | VPN| | Router| | VPN/HA| .
	. |away|<###################>| |-----| 1..n |->| 1..n | .		. |away|<###################>| |-----| 1..n |->| 1..n | .
	. +----+ . \ | GW | +-------+ +-------+ .		. +----+ . \ | GW | +-------+ +-------+ .
	. . \ +----+ .		. . \ +----+ .
	................... mip . +-------+ +-------+ .		................... mip . +-------+ +-------+ .
	skipping to change at page 12, line 48 ¶		skipping to change at page 12, line 24 ¶
	IPsec . | 1..n | | home | .		IPsec . | 1..n | | home | .
	. +-------+ +-------+ .		. +-------+ +-------+ .
	. .		. .
	................................		................................
	Figure 8		Figure 8
	The MN obtains an address at its point of attachment (via DHCP		The MN obtains an address at its point of attachment (via DHCP
	[RFC2131] or some other means), and then first sets up an IPsec		[RFC2131] or some other means), and then first sets up an IPsec
	tunnel to the VPN gateway, after which it can successfully register		tunnel to the VPN gateway, after which it can successfully register
	with its HA through the IPsec tunnel. The problem is that in an		with its HA through the IPsec tunnel. The IPsec tunnel SA (Security
	end-to-end security model, an IPsec tunnel that terminates at the VPN		Association) is identified by a triplet consisting of SPI (Security
	gateway must protect the IP traffic originating at the MN. As the		Parameter Index), MN's IP destination address (i.e., the address
	MN's IPsec tunnel address is the address obtained at the point of		obtained at the point of attachment), and Security Protocol (AH or
	attachment, it will change during movement, and the VPN tunnel		ESP) Identifier as described in [RFC2401]. This means that as the
	security association must be refreshed after each IP subnet handoff.		MN's IP destination address changes on each IP subnet handoff, the
	This could have noticeable performance implications on real-time		IPsec tunnel needs to be re-established. This could have noticeable
	applications. In effect, we don't have mobility support for the		performance implications on real-time applications and in
	tunnel endpoint changes associated with MN movements.		resource-constrained wireless networks. In effect, we don't have
			mobility support for the tunnel endpoint changes associated with MN
			movements.
	4.2 Registering via an FA		4.2 Registering via an FA
	In the case where a mobile node is in a network where mobility		In the case where a mobile node is in a network where mobility
	support is provided through the use of an FA, and no DHCP allocated		support is provided through the use of an FA, and no DHCP allocated
	address and co-located mode is possible, we run into severe trouble.		address and co-located mode is possible, we run into severe trouble.
	Figure 9 below illustrates this:		This is illustrated in Figure 9 and explained below:
	..Foreign Network.. .....VPN Domain..(Intranet).....		..Foreign Network.. .....VPN Domain..(Intranet).....
	. . . .		. . . .
	. +----+ +----+ . +----+ +-------+ +-------+ .		. +----+ +----+ . +----+ +-------+ +-------+ .
	. |MNs | | FA | . | VPN| | Router| | VPN/HA| .		. |MNs | | FA | . | VPN| | Router| | VPN/HA| .
	. |away|<??| |<###########>| |-----| 1..n |->| 1..n | .		. |away|<??| |<###########>| |-----| 1..n |->| 1..n | .
	. +----+ \ +----+ . \ | GW | +-------+ +-------+ .		. +----+ \ +----+ . \ | GW | +-------+ +-------+ .
	. \ . \ +----+ .		. \ . \ +----+ .
	...........\....... mip . +-------+ +-------+ .		...........\....... mip . +-------+ +-------+ .
	\ inside . | CN | | MNs | .		\ inside . | CN | | MNs | .
	MN expects IPsec . | 1..n | | home | .		MN expects IPsec . | 1..n | | home | .
	IPsec traffic . +-------+ +-------+ .		IPsec traffic . +-------+ +-------+ .
	. .		. .
	................................		................................
	Figure 9		Figure 9
	The mobile node, when arriving at this network, may have a IPsec		The MN, when arriving at the visited network on the left in this
	session going with its VPN gateway. This session will not be passed		figure, has to reach the FA with registration requests in order to
	through the FA as long as the MN has not registered and a mip tunnel		have the FA send them on to the HA. However, the MN in all
	has been set up. But the MN, which is secure inside the IPsec based		likelihood cannot register with the FA because the registration
	VPN, will not even hear the FA advertisements. And any IPsec traffic		requests will be sent encrypted, and the FA will not be able to
	from the Intranet (via the VPN gateway and IPsec tunnel) will not be		decrypt them. Now, if the MN would have a policy which allowed split
	understood by the FA. Simply put, you could say that the FA needs to		tunneling, so that it could reach the FA with clear text messages,
	see the mip tunnel outermost, while the VPN-GW needs to see the IPsec		the FA would still not be able to get through the VPN gateway unless
	tunnel outermost. Or in more details:		the HA is reachable from outside and the Intranet security policy
			allows MIP registration packets bypass the VPN gateway.
	Firstly, the MN must have a IPsec tunnel established with the VPN-GW
	in order to reach the HA, which places the IPsec tunnel outside the
	mip traffic between MN and HA. The FA (which is likely in a
	different administrative domain) cannot decrypt MIPv4 packets between
	the MN and the VPN gateway, and will consequently be not able to
	relay the MIPv4 packets. This is because the MIPv4 headers (which
	the FA should be able to interpret) will be encrypted and protected
	by IPsec.
	Secondly, when the MN is communicating with the VPN-GW, an explicit		Even if the HA is reachable and the MIP registration succeeds, the FA
	bypass policy for MIP packets is required, so that the MN can hear FA		(which is likely in a different administrative domain) will not be
	advertisements and send and receive MIP registration packets.		able to relay packets between the MN and the VPN gateway. Packets
	Although not a problem in principle, there may be practical problems		from the MN will be encapsulated by the FA with IP-in-IP (RFC 2003)
	when VPN and MIP clients from different vendors are used.		which the VPN gateway will drop, and packets from the VPN gateway
			will have ESP payloads (with IP-in-IP inside) which the FA will drop
			(as it expects IP-in-IP encapsulated traffic to the MN).
	The use of a 'trusted FA' has been suggested in this scenario;		The use of a 'trusted FA' has also been suggested in this scenario;
	meaning an FA which is actually a combined VPN GW and FA. The		meaning an FA which is actually a combined VPN GW and FA. The
	scenario will work fine in this case; effectively we are then		scenario will work fine in this case as the tunnel end-points are at
	operating within the VPN established between the two VPN gateways,		the FA and the VPN gateway as shown in Figure 10 below. However, we
	and the case is analogous to deploying mobile-ip within a corporate		cannot expect the FA in access networks (e.g., wireless hot-spots or
	Intranet which is not physically disjoint. See Figure 10 below.		CDMA 2000 networks) will have security associations with any given
	However, we cannot expect that e.g. wireless hot-spots or CDMA 2000
	FAs will have VPN gateways with security associations with any given
	corporate network, so this is not particularly realistic in the		corporate network, so this is not particularly realistic in the
	general mobility case.		general mobility case.
	..Foreign Network.. .....VPN Domain..(Intranet).....		..Foreign Network.. .....VPN Domain..(Intranet).....
	. . . .		. . . .
	. +----+ +----+ . +----+ +-------+ +-------+ .		. +----+ +----+ . +----+ +-------+ +-------+ .
	. | FA | | VPN| . | VPN| | Router| | VPN/HA| .		. | FA | | VPN| . | VPN| | Router| | VPN/HA| .
	. | |<--| GW |<###########>| |-----| 1..n |->| 1..n | .		. | |<--| GW |<###########>| |-----| 1..n |->| 1..n | .
	. +----+ +----+ . \ | GW | +-------+ +-------+ .		. +----+ +----+ . \ | GW | +-------+ +-------+ .
	. | . \ +----+ .		. | . \ +----+ .
	skipping to change at page 14, line 42 ¶		skipping to change at page 14, line 25 ¶
	. +----+ . . +-------+ +-------+ .		. +----+ . . +-------+ +-------+ .
	................... . .		................... . .
	................................		................................
	Figure 10		Figure 10
	Furthermore, this solution would leave the traffic between FA and MN		Furthermore, this solution would leave the traffic between FA and MN
	unprotected, and as this link in particular may be a wireless link,		unprotected, and as this link in particular may be a wireless link,
	this is clearly undesirable.		this is clearly undesirable.
	4.3 Summary: MIP Incompatibilities with IPsec-based VPN Gateways		4.3 Summary: MIP Incompatibilities with IPsec-based VPN Gateways
	An MN roaming outside the Intranet has to establish an IPsec tunnel		An MN roaming outside the Intranet has to establish an IPsec tunnel
	to its home VPN gateway first, in order to be able to register with		to its home VPN gateway first, in order to be able to register with
	its home agent. This is because the MN cannot reach its HA (inside		its home agent. This is because the MN cannot reach its HA (inside
	the private protected network) directly from the outside. This		the private protected network) directly from the outside. This
	implies that the MIPv4 traffic from the MN to a node inside the		implies that the MIPv4 traffic from the MN to a node inside the
	Intranet is forced to run inside an IPsec tunnel, and hence will not		Intranet is forced to run inside an IPsec tunnel, and hence will not
	be in the clear. This in turn leads to two distinct problems		be in the clear. This in turn leads to two distinct problems
	depending on whether the MN uses co-located or non co-located modes		depending on whether the MN uses co-located or non co-located modes
	to register with its HA.		to register with its HA.
	5. Solution Guidelines		In co-located mode, the IPsec tunnel needs to be re-established on
			each IP subnet handoff which will have performance implications on
			real-time applications and resource-constrained wireless networks.
			In non co-located mode (i.e., using an FA care-of address), the
			problem becomes severe as the MN may be unable to register with its
			HA through the FA, because the FA cannot understand MIPv4
			registration requests if they are encrypted in the IPsec tunnel
			(i.e., split tunneling is not supported). Even if the MN could reach
			the FA with non-encrypted registration requests (i.e., split
			tunneling is supported), and the requests going from the FA to the HA
			can pass through the VPN gateway, there will still be a problem with
			routing of data packets between the Intranet and the internet. This
			is because the VPN will not allow IP-in-IP encapsulated packets from
			the FA go through. And furthermore, ESP encapsulated packets from
			the VPN gateway to the MN will be dropped by the FA as it expects
			IP-in-IP encapsulated traffic to the MN.
			5. Solution Guidelines
	This section describes guidelines for a solution to MIPv4 traversal		This section describes guidelines for a solution to MIPv4 traversal
	across VPN gateways.		across VPN gateways.
	5.1 Preservation of Existing VPN Infrastructure		5.1 Preservation of Existing VPN Infrastructure
	o The solution MUST preserve the investment in existing VPN		o The solution MUST work with currently deployed VPN gateways. This
	gateways.		is the whole raison d'etre of this investigation: Finding a way
	o The solution MUST provide security which is not inferior to what		to deploy Mobile-IP in cases where a VPN solution is already in
	is already provided to existing "nomadic computing" remote access		place.
	users, i.e. for confidentiality, authentication, message
	integrity, protection against replay attacks and related security
	services.
	5.2 Software Upgrades to Existing VPN Client and Gateways		5.2 Software Upgrades to Existing VPN Client and Gateways
	o The solution SHOULD minimize changes to existing VPN client/		o The solution SHOULD minimize changes to existing VPN client/
	gateway software.		gateway software.
	5.3 IPsec Protocol		5.3 IPsec Protocol
	o The solution SHOULD NOT require any changes to existing IPsec or		o The solution SHOULD NOT require any changes to existing IPsec or
	key exchange standard protocols implemented by VPN gateways.		key exchange standard protocols implemented by VPN gateways.
	o The solution SHOULD NOT require that the VPN gateway or the VPN		o The solution SHOULD NOT require that the VPN gateway or the VPN
	client implement any new protocols in addition to the existing		client implement any new protocols in addition to the existing
	standard protocols.		standard protocols.
	5.4 Multi-Vendor Interoperability		5.4 Multi-Vendor Interoperability
	o The solution MUST provide multi-vendor interoperability, where		o The solution MUST provide multi-vendor interoperability, where
	MIPv4 mobility agents, mobility clients (MN), VPN server, and VPN		MIPv4 mobility agents, mobility clients (MN), VPN server, and VPN
	client solutions may come from four different vendors. This is		client solutions may come from four different vendors. This is
	typical for medium and large enterprises which purchase and deploy		typical for medium and large enterprises which purchase and deploy
	best-of-breed multi-vendor solutions for IP routing, VPNs,		best-of-breed multi-vendor solutions for IP routing, VPNs,
	firewalls etc.		firewalls etc.
	5.5 MIPv4 Protocol		5.5 MIPv4 Protocol
	o The solution MUST adhere to MIPv4 protocol [RFC3344]. That is,		o The solution MUST adhere to MIPv4 protocol [RFC3344]. That is,
	the solution MUST NOT impose any changes that violates MIPv4		the solution MUST NOT impose any changes that violates MIPv4
	protocol.		protocol.
	o The solution MAY introduce new extensions to MIPv4 nodes per		o The solution MAY introduce new extensions to MIPv4 nodes per
	guidelines specified in the MIPv4 protocol [RFC3344]. However, it		guidelines specified in the MIPv4 protocol [RFC3344]. However, it
	is highly desirable to avoid any changes to MIPv4 mobility agents		is highly desirable to avoid any changes to MIPv4 mobility agents
	such as the FA and HA in order to overcome barriers to		such as the FA and HA in order to overcome barriers to deployment.
	deployment.
	o The solution MAY require more than one instance of MIPv4 running		o The solution MAY require more than one instance of MIPv4 running
	in parallel (multiple encapsulation).		in parallel (multiple encapsulation).
	5.6 Handoff Overhead		5.6 Handoff Overhead
	o It is imperative to keep the key management overhead down to a		o It is imperative to keep the key management overhead down to a
	minimum, in order to support fast handoffs across IP subnets.		minimum, in order to support fast handoffs across IP subnets.
	Hence, the solution MUST propose a mechanism to avoid or minimize		Hence, the solution MUST propose a mechanism to avoid or minimize
	IPsec tunnel SA renegotiation and IKE renegotiation as the MN		IPsec tunnel SA renegotiation and IKE renegotiation as the MN
	changes its current point of network attachment.		changes its current point of network attachment.
	5.7 Scalability, Availability, Reliability, and Performance		5.7 Scalability, Availability, Reliability, and Performance
	o The solution complexity MUST increase at most linearly with the		o The solution complexity MUST increase at most linearly with the
	number of MNs registered and accessing resources inside the		number of MNs registered and accessing resources inside the
	Intranet.		Intranet.
	o The solution MAY introduce additional header or tunnelling		o The solution MAY introduce additional header or tunnelling
	overhead if needed.		overhead if needed.
	5.8 Functional Entities		5.8 Functional Entities
	o The solution MAY introduce new MIPv4 compliant functional		o The solution MAY introduce new MIPv4 compliant functional
	entities.		entities.
	5.9 Implications of Intervening NAT Gateways		5.9 Implications of Intervening NAT Gateways
	o The solution MUST be able to leverage the existing MIPv4 and IPsec		o The solution MUST be able to work with the existing MIPv4 and
	NAT traversal solutions [RFC3519][IPSEC-NAT][IKE-NAT].		IPsec NAT traversal solutions [RFC3519][RFC3715][IKE-NAT].
	5.10 Security Requirements		5.10 Security Requirements
	o The solution MUST NOT introduce any new vulnerabilities to the		o The solution MUST provide security which is not inferior to what
	MIPv4 or IPsec as specified in related RFCs.		is already provided to existing "nomadic computing" remote access
			users, i.e. for confidentiality, authentication, message
			integrity, protection against replay attacks and related security
			services.
	6. Security Considerations		6. Security Considerations
	This document describes an existing problem and proposes guidelines		This document describes an existing problem and proposes guidelines
	for possible solutions; as such its security implications are		for possible solutions; as such its security implications are
	indirect, through the guidelines it proposes for the solutions.		indirect, through the guidelines it proposes for the solutions.
	Section 5.10 gives the relevant security requirements.		Section 5.10 gives the relevant security requirements.
	7. Acknowledgements		7. Acknowledgements
	The authors who contributed text to this document were in no		The authors who contributed text to this document were in no
	particular order: Farid Adrangi, Milind Kulkarni, Gopal Dommety, Eli		particular order: Farid Adrangi, Milind Kulkarni, Gopal Dommety, Eli
	Gelasco, Qiang Zhang, Sami Vaarala, Dorothy Gellert, Nitsan Baider		Gelasco, Qiang Zhang, Sami Vaarala, Dorothy Gellert, Nitsan Baider
	and Henrik Levkowetz.		and Henrik Levkowetz.
	The authors would like to thank other contributors, especially		The authors would like to thank other contributors, especially
	Prakash Iyer, Mike Andrews, Ranjit Narjala, Joe Lau, Kent Leung,		Prakash Iyer, Mike Andrews, Ranjit Narjala, Joe Lau, Kent Leung,
	Alpesh Patel, Phil Roberts, Hans Sjostrand, Serge Tessier, Antti		Alpesh Patel, Phil Roberts, Hans Sjostrand, Serge Tessier, Antti
	Nuopponen, Alan O'neill, Gaetan Feige, Brijesh Kumar for their		Nuopponen, Alan O'neill, Gaetan Feige, Brijesh Kumar for their
	continuous feedback and helping us improve this draft.		continuous feedback and helping us improve this draft.
	Normative References		8. References
			8.1 Normative References
	[RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344,		[RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344,
	August 2002.		August 2002.
	Informative References		8.2 Informative References
			[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G. and
			E. Lear, "Address Allocation for Private Internets", BCP
			5, RFC 1918, February 1996.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC		[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC
	2131, March 1997.		2131, March 1997.
			[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the
			Internet Protocol", RFC 2401, November 1998.
	[RFC3519] Levkowetz, H. and S. Vaarala, "Mobile IP Traversal of		[RFC3519] Levkowetz, H. and S. Vaarala, "Mobile IP Traversal of
	Network Address Translation (NAT) Devices", RFC 3519, May		Network Address Translation (NAT) Devices", RFC 3519, May
	2003.		2003.
	[IPSEC-NAT]		[RFC3715] Aboba, B. and W. Dixon, "IPsec-Network Address Translation
	Aboba, B. and W. Dixon, "IPsec-NAT Compatibility		(NAT) Compatibility Requirements", RFC 3715, March 2004.
	Requirements", draft-ietf-ipsec-nat-reqts-06 (work in
	progress), October 2003.
	[IKE-NAT] Kivinen, T., "Negotiation of NAT-Traversal in the IKE",		[IKE-NAT] Kivinen, T., "Negotiation of NAT-Traversal in the IKE",
	draft-ietf-ipsec-nat-t-ike-07 (work in progress),		draft-ietf-ipsec-nat-t-ike-08 (work in progress), February
	September 2003.		2004.
	Authors' Addresses		Authors' Addresses
	Farid Adrangi		Farid Adrangi
	Intel Corporation		Intel Corporation
	2111 N.E. 25th Avenue		2111 N.E. 25th Avenue
	Hillsboro OR		Hillsboro OR
	USA		USA
	Phone: +1 503-712-1791		Phone: +1 503-712-1791
	skipping to change at page 18, line 4 ¶		skipping to change at page 18, line 15 ¶
	Authors' Addresses		Authors' Addresses
	Farid Adrangi		Farid Adrangi
	Intel Corporation		Intel Corporation
	2111 N.E. 25th Avenue		2111 N.E. 25th Avenue
	Hillsboro OR		Hillsboro OR
	USA		USA
	Phone: +1 503-712-1791		Phone: +1 503-712-1791
	EMail: farid.adrangi@intel.com		EMail: farid.adrangi@intel.com
	Henrik Levkowetz		Henrik Levkowetz
	ipUnplugged AB		Torsgatan 71
	Arenavagen 33		Stockholm S-113 37
	Stockholm S-121 28
	SWEDEN		SWEDEN
	Phone: +46 8 725 9513		Phone: +46 7 08 32 16 08
	EMail: henrik@levkowetz.com		EMail: henrik@levkowetz.com
	Milind Kulkarni
	Cisco Systems
	170 W. Tasman Drive
	San Jose CA 95134
	USA
	Phone: +1 408-527-8382
	EMail: mkulkarn@cisco.com
	Gopal Dommety
	Cisco Systems
	170 W. Tasman Drive
	San Jose CA 95134
	USA
	EMail: gdommety@cisco.com
	Eli Gelasco
	Cisco Systems
	170 W. Tasman Drive
	San Jose CA 95134
	USA
	EMail: egelasco@cisco.com
	Qiang Zhang
	Liqwid Networks, Inc.
	1000 Wilson Blvd, Suite 900
	Arlington VA 22209
	USA
	Phone: +1 703-224-1120 -x 203
	EMail: qzhang@liqwidnet.com
	Sami Vaarala
	Netseal
	Niittykatu 6
	Espoo 02201
	FINLAND
	Phone: +358 9 435 310
	EMail: sami.vaarala@iki.fi
	Dorothy Gellert
	Nokia Corporation
	EMail: dorothy.gellert@nokia.com
	Nitsan Baider
	Check Point Software Technologies, Inc.
	EMail: nitsan@checkpoint.com
	Intellectual Property Statement		Intellectual Property Statement
	The IETF takes no position regarding the validity or scope of any		The IETF takes no position regarding the validity or scope of any
	intellectual property or other rights that might be claimed to		Intellectual Property Rights or other rights that might be claimed to
	pertain to the implementation or use of the technology described in		pertain to the implementation or use of the technology described in
	this document or the extent to which any license under such rights		this document or the extent to which any license under such rights
	might or might not be available; neither does it represent that it		might or might not be available; nor does it represent that it has
	has made any effort to identify any such rights. Information on the		made any independent effort to identify any such rights. Information
	IETF's procedures with respect to rights in standards-track and		on the procedures with respect to rights in RFC documents can be
	standards-related documentation can be found in BCP-11. Copies of		found in BCP 78 and BCP 79.
	claims of rights made available for publication and any assurances of
	licenses to be made available, or the result of an attempt made to		Copies of IPR disclosures made to the IETF Secretariat and any
	obtain a general license or permission for the use of such		assurances of licenses to be made available, or the result of an
	proprietary rights by implementors or users of this specification can		attempt made to obtain a general license or permission for the use of
	be obtained from the IETF Secretariat.		such proprietary rights by implementers or users of this
			specification can be obtained from the IETF on-line IPR repository at
			http://www.ietf.org/ipr.
	The IETF invites any interested party to bring to its attention any		The IETF invites any interested party to bring to its attention any
	copyrights, patents or patent applications, or other proprietary		copyrights, patents or patent applications, or other proprietary
	rights which may cover technology that may be required to practice		rights that may cover technology that may be required to implement
	this standard. Please address the information to the IETF Executive		this standard. Please address the information to the IETF at
	Director.		ietf-ipr@ietf.org.
	Full Copyright Statement
	Copyright (C) The Internet Society (2004). All Rights Reserved.		Disclaimer of Validity
	This document and translations of it may be copied and furnished to		This document and the information contained herein are provided on an
	others, and derivative works that comment on or otherwise explain it		"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
	or assist in its implementation may be prepared, copied, published		OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
	and distributed, in whole or in part, without restriction of any		ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
	kind, provided that the above copyright notice and this paragraph are		INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
	included on all such copies and derivative works. However, this		INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
	document itself may not be modified in any way, such as by removing		WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
	the copyright notice or references to the Internet Society or other
	Internet organizations, except as needed for the purpose of
	developing Internet standards in which case the procedures for
	copyrights defined in the Internet Standards process must be
	followed, or as required to translate it into languages other than
	English.
	The limited permissions granted above are perpetual and will not be		Copyright Statement
	revoked by the Internet Society or its successors or assignees.
	This document and the information contained herein is provided on an		Copyright (C) The Internet Society (2004). This document is subject
	"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING		to the rights, licenses and restrictions contained in BCP 78, and
	TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING		except as set forth therein, the authors retain all their rights.
	BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
	HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
	MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
	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. 92 change blocks.
	325 lines changed or deleted		302 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/