Request for Comments: 4093 Intel
Category: Informational H. Levkowetz, Ed.
Ericsson
August 2005
Problem Statement: Mobile IPv4 Traversal of
Virtual Private Network (VPN) Gateways
Status of This Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
Deploying Mobile-IP v4 in networks that are connected to the Internet
through a Virtual Private Network (VPN) gateway presents some
problems that do not currently have well-described solutions. This
document aims to describe and illustrate these problems, and to
propose some guidelines for possible solutions.
Table of Contents
1. Introduction ....................................................2
1.1. Overview of the Problem ....................................3
1.2. Specification of Requirements ..............................3
1.3. Terminology ................................................3
2. MIP and VPN Deployment Scenarios ................................4
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 .......6
2.3. Combined VPN Gateway and MIPv4 HA ..........................7
2.4. MIPv4 HA(s) Outside the VPN Domain .........................8
2.5. Combined VPN Gateway and MIPv4 HA(s) on the Local Link .....9
3. Deployment Scenarios Selection ..................................9
4. Problem Statement ..............................................10
4.1. Registering in Co-Located Mode ............................11
4.2. Registering via an FA .....................................12
4.3. Summary: MIP Incompatibilities with IPsec-Based
VPN Gateways ..............................................13
5. Solution Guidelines ............................................14
5.1. Preservation of Existing VPN Infrastructure ...............14
5.2. Software Upgrades to Existing VPN Client and Gateways .....14
5.3. IPsec Protocol ............................................14
5.4. Multi-Vendor Interoperability .............................14
5.5. MIPv4 Protocol ............................................15
5.6. Handoff Overhead ..........................................15
5.7. Scalability, Availability, Reliability, and Performance ...15
5.8. Functional Entities .......................................15
5.9. Implications of Intervening NAT Gateways ..................15
5.10. Security Requirements ....................................16
6. Security Considerations ........................................16
7. Acknowledgements ...............................................16
8. References .....................................................17
8.1. Normative References ......................................17
8.2. Informative References ....................................17
1. Introduction
Mobile IP [RFC3344] agents are being deployed in enterprise networks
to enable mobility across wired and wireless LANs while roaming
inside the enterprise Intranet. With the growing deployment of IEEE
802.11 access points ("hot spots") in public places such as hotels,
airports, and convention centers, and with wireless WAN data networks
such as General Packet Radio Service (GPRS), the need is increasing
for enabling mobile users to maintain their transport connections and
constant reachability while connecting back to their target "home"
networks protected by Virtual Private Network (VPN) technology. This
implies that Mobile IP and VPN technologies have to coexist and
function together in order to provide mobility and security to the
enterprise mobile users.
The goal of this document is to:
o Identify and describe practical deployment scenarios for Mobile IP
and VPN in enterprise and operator environments.
o Identify example usage scenarios for remote users roaming outside
the "home" network protected by a VPN gateway.
o Articulate the problems resulting from Mobile IP and VPN
coexistence.
o Specify a set of framework guidelines to evaluate proposed
solutions for supporting multi-vendor seamless IPv4 mobility
across IPsec-based VPN gateways.
1.1. Overview of the Problem
Access to the Intranet is typically guarded by both a firewall and a
VPN device. The Intranet can only be accessed by respecting the
security policies in the firewall and the VPN device.
When MIP is deployed in a corporate Intranet (also referred to as a
VPN domain), roaming between the Intranet (i.e., trusted domain) and
the Internet (i.e., untrusted domain) becomes problematic. It would
be desirable to have seamless session mobility between the two
domains, because MIP was designed for session mobility regardless of
the network point of attachment. Unfortunately, the current MIP
standards fall short of this promise for an important customer
segment: corporate users (using VPN for remote access) who desire to
add mobility support because of a need to have continuous access to
Intranet resources while roaming outside the Intranet from one subnet
to another, or between the VPN domain and the Internet.
From the beginning, one explicitly stated restriction was that it was
assumed that installed firewalls and VPN gateways had to be kept
unchanged, rather than replaced or upgraded, because they have much
wider deployments than MIP at the time of writing. Therefore, any
solutions would need to minimize the impact on existing VPN and
firewall deployments, related standards, and "de facto" standards.
1.2. Specification of Requirements
In this document, several words are used to signify the requirements
of the specification. These words are often capitalized. The key
words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
"SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document
are to be interpreted as described in [RFC2119].
1.3. Terminology
MIPv4 Mobile IP for IPv4 [RFC3344]
MIPv6 Mobile IP for IPv6
VPN Virtual Private Network
GW Gateway
VPN Domain An Intranet protected by a VPN gateway.
DMZ (Demilitarized Zone) A small network inserted as a
"neutral zone" between a company’s private network and
the outside public network to prevent outside users
from getting direct access to the company’s private
network.
Home Network A network, possibly virtual, having a network prefix
matching that of a mobile node’s home address.
Home Agent A router on a mobile node’s home network which tunnels
datagrams for delivery to the mobile node when it is
away from home, and maintains current location
information for the mobile node.
MN Refers to a mobile node that runs both MIP and IPsec-
based VPN client software.
MIPv4 inside IPsec-ESP tunnel
MIPv4 packets are encapsulated in an IPsec-ESP tunnel
established between the Mobile Node and the VPN
gateway.
IPsec-ESP inside MIPv4 tunnel
IPsec-ESP packets are encapsulated in a MIPv4 tunnel
established between the Mobile Node and the home agent.
2. MIP and VPN Deployment Scenarios
This section describes a set of deployment scenarios wherein MIP
agents and VPN gateways have to coexist to provide mobility and
security. The intention is to identify practical deployment
scenarios for MIP and VPNs where MIP technology might be extended to
solve problems resulting from the desire for co-existence.
The network topology in the following diagrams consists of an
Intranet connected to the public network (i.e., the Internet). Here,
the word "Intranet" refers to a private network (where private
addresses [RFC1918] are typically used) protected by a VPN gateway
and perhaps by a layer-3 transparent or non-transparent firewall.
When private addresses are used, the non-transparent firewall also
functions as a Network Address Translator (NAT) or Network Address
Port Translator (NAPT) bridging between the two address realms (i.e.,
the Intranet and the Internet).
Firewalls may be placed on either side of the VPN gateway; these are
referred to as inner and outer firewalls. The inner and outer
firewalls typically inspect outbound traffic (i.e., from the Intranet
to the Internet) and inbound traffic (i.e., from the Internet to the
Intranet), respectively. When a firewall is present, it MUST be
configured to allow Mobile IP traffic (both control and tunneled data
packets) to go through. As our focus here is the relationship
between MIP and VPN, we have purposely omitted firewalls from the
following scenarios in order to keep things simple.
It is assumed that encryption is not enforced inside the VPN domain
because: 1) the VPN domain (Intranet) is viewed as a trusted network,
and users allowed inside the Intranet are also trusted, and 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.
The following sub-sections introduce five representative combinations
of MIPv4 HA and VPN gateway placement.
In order to give a reasonably complete survey of MIPv4 and VPN co-
existence scenarios, those in Sections 2.3 and 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
Intranet.
..Foreign Network.. .....VPN Domain..(Intranet).....
. . . .
. +----+ +----+ . +----+ +-------+ +-------+ .
. |MNs | | FA | . | VPN| | Router| | HA | .
. |away| | | .<=========>| | | 1..n | | 1..n | .
. +----+ +----+ . | GW | +-------+ +-------+ .
. . +----+ .
................... . +-------+ +-------+ .
. | CN | | MNs | .
. | 1..n | | home | .
. +-------+ +-------+ .
. .
................................
Figure 1
Direct application of MIPv4 standards [RFC3344] is successfully used
to provide mobility for users inside the Intranet. However, mobile
users outside the Intranet can only access the Intranet resources
(e.g., MIP agents) through the VPN gateway, which will allow only
authenticated IPsec traffic inside. This implies that the MIPv4
traffic has to run inside IPsec, which leads to two distinct
problems:
1. When the foreign network has an FA deployed (e.g., as in CDMA
2000), MIPv4 registration becomes impossible. This is because
the MIPv4 traffic between MN and VPN gateway is encrypted, and
the FA (which is likely in a different administrative domain)
cannot inspect the MIPv4 headers needed for relaying the MIPv4
packets. Please see Section 4.2 for more details.
2. In co-located mode, successful registration is possible but the
VPN tunnel has to be re-negotiated every time the MN changes its
point of network attachment.
These problems are articulated in Section 4.
This deployment scenario may not be common yet, but it is practical
and is becoming important as there is an increasing need for
providing corporate remote users with continuous access to the
Intranet resources.
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)
together with the VPN gateway, and it is directly reachable by MNs
inside or outside the Intranet.
..Foreign Network.. .....VPN Domain..(Intranet).....
. . . .
. +----+ +----+ . +----+ +-------+ .
. |MNs | | FA | . | VPN| | Router| .
. |away| | | .<=========>| | | 1..n | .
. +----+ +----+ . /\ | GW | +-------+ .
. . || +----+ .
. . || +----+ +-------+ +-------+ .
. . ++====>| HA | | CN | | MNs | .
................... | | | 1..n | | home | .
+----+ +-------+ +-------+ .
. .
................................
Figure 2
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
likely have a virtual home network associated with the MIPv4 HA’s
private interface, so that the mobile users are always away from home
and thus registered with the MIPv4 HA. Furthermore, in deployments
where the VPN gateway and the HA are placed in a corporate DMZ, this
implies that MIPv4 traffic will always be routed through the DMZ
(regardless of whether MNs are located outside or inside the
Intranet), which may not be acceptable to IT departments in large
corporations.
This deployment can be used with two different configurations: "MIPv4
inside IPsec-ESP tunnel" and "IPsec-ESP inside MIPv4 tunnel". The
"MIPv4 inside IPsec-ESP tunnel" has the same problems as the scenario
in Section 2.1. (Namely, MIPv4 registration becomes impossible when
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 the
MN changes its point of attachment.) The "IPsec-ESP inside MIPv4
tunnel" does not have the problems described in Section 2.1; however,
it will require some modifications to the routing logic of the MIPv4
HA or the VPN gateway.
2.3. Combined VPN Gateway and MIPv4 HA
This is similar to the deployment scenario described in Section 2.2,
with the exception that the VPN gateway and MIPv4 HA are running on
the same physical machine.
..Foreign Network.. .....VPN Domain..(Intranet).....
. . . .
. +----+ +----+ . +----+ +-------+ .
. |MNs | | FA | . | VPN| | Router| .
. |away| | | .<==========| GW | | 1..n | .
. +----+ +----+ . | + | +-------+ .
. . | HA | .
................... +----+ +-------+ +-------+ .
. | CN | | MNs | .
. | 1..n | | home | .
. +-------+ +-------+ .
. .
................................
Figure 3
Running MIPv4 HA and VPN on the same machine resolves routing-related
issues that exist in Section 2.2 when a "IPsec-ESP inside MIPv4
tunnel" configuration is used. However, it does not promote multi-
vendor interoperability in environments where MIPv4 HA and VPN
technologies must be acquired from different vendors.
2.4. MIPv4 HA(s) Outside the VPN Domain
In this scenario, MIPv4 HAs are deployed outside the Intranet (e.g.,
in an operator network), as depicted in Figure 4, below.
..Foreign Network.. .....VPN Domain..(Intranet).....
. . . .
. +----+ +----+ . +----+ +-------+ .
. |MNs | | FA | . | VPN| | Router| .
. |away| | | .<==========| GW | | 1..n | .
. +----+ +----+ . /\ | | +-------+ .
. . || | | .
................... || | | +-------+ +-------+ .
|| | | | CN | | MNs | .
.....MIPv4 Home.... || | | | 1..n | | home | .
. .<===++ | | +-------+ +-------+ .
. +------+ . +----+ .
. | HAs | . . .
. | 1..n | . ................................
. +------+ .
...................
Figure 4
The IPsec tunnel endpoints will be the MN and the VPN gateway. The
’home network’ will most likely be a virtual home network, located at
the HA, through which authorized remote users (i.e., those that have
successfully established a connection to the corporate VPN) can reach
the Corporate Intranet and maintain their transport session
connectivity while roaming outside the Intranet from one subnet to
another. Please note that this deployment scenario does not support
mobility inside the Intranet.
In this case, it is most practical to run IPsec-ESP inside a MIPv4
tunnel (i.e., the MIPv4 tunnel endpoints are the MN and the HA; the
IPsec-ESP packet from the MN and to the VPN gateway is encapsulated
in the MIPv4 tunnel). This is because the MNs can register with the
HA without establishing an IPsec tunnel to the VPN gateway.
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,
with the difference that the VPN gateway/HA is sitting on the local
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.
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).....
. . . .
. +----+ +----+ . +------+ +-------+ +-------+ .