doc: Add RFC documents

1 files changed, 1067 insertions, 0 deletions

diff --git a/doc/rfc/rfc4093.txt b/doc/rfc/rfc4093.txt
new file mode 100644
index 0000000..54ad36b
--- /dev/null
+++ b/doc/rfc/rfc4093.txt
@@ -0,0 +1,1067 @@
+
+
+
+
+
+
+Network Working Group                                    F. Adrangi, Ed.
+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
+
+
+
+
+
+Adrangi & Levkowetz          Informational                      [Page 1]
+
+RFC 4093         MIPv4 VPN Traversal Problem Statement       August 2005
+
+
+   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.
+
+
+
+
+
+Adrangi & Levkowetz          Informational                      [Page 2]
+
+RFC 4093         MIPv4 VPN Traversal Problem Statement       August 2005
+
+
+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.
+
+
+
+
+
+
+
+Adrangi & Levkowetz          Informational                      [Page 3]
+
+RFC 4093         MIPv4 VPN Traversal Problem Statement       August 2005
+
+
+   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
+
+
+
+Adrangi & Levkowetz          Informational                      [Page 4]
+
+RFC 4093         MIPv4 VPN Traversal Problem Statement       August 2005
+
+
+   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
+
+
+
+Adrangi & Levkowetz          Informational                      [Page 5]
+
+RFC 4093         MIPv4 VPN Traversal Problem Statement       August 2005
+
+
+   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.
+
+
+
+Adrangi & Levkowetz          Informational                      [Page 6]
+
+RFC 4093         MIPv4 VPN Traversal Problem Statement       August 2005
+
+
+   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
+
+
+
+
+
+
+
+
+Adrangi & Levkowetz          Informational                      [Page 7]
+
+RFC 4093         MIPv4 VPN Traversal Problem Statement       August 2005
+
+
+   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.
+
+
+
+
+
+
+
+Adrangi & Levkowetz          Informational                      [Page 8]
+
+RFC 4093         MIPv4 VPN Traversal Problem Statement       August 2005
+
+
+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).....
+     .                 .             .                              .
+     .  +----+  +----+ .         +------+     +-------+  +-------+  .
+     .  |MNs |  | FA | .         | Fire |     | Router|  | VPN/HA|  .
+     .  |away|  |    | .<=======>| wall |     | 1..n  |  | 1..n  |  .
+     .  +----+  +----+ .         |      |     +-------+  +-------+  .
+     .                 .         | NAT  |                           .
+     ...................         +------+     +-------+  +-------+  .
+                                     .        |  CN   |  | MNs   |  .
+                                     .        | 1..n  |  | home  |  .
+                                     .        +-------+  +-------+  .
+                                     .                              .
+                                     ................................
+
+                                 Figure 5
+
+   This deployment works today without any technical problems with
+   IPsec-ESP running inside a MIPv4 tunnel.  If you were to run MIPv
+   inside the IPsec-ESP tunnel, it would have the same problems as in
+   Section 2.1, so it is deployed with the IPsec-ESP running inside the
+   MIPv4 tunnel.  This deployment is not practical for large deployments
+   (on the order of thousands of users) because of the large and
+   distributed security perimeter.
+
+3.  Deployment Scenarios Selection
+
+   The deployment scenarios described in Section 2 were evaluated to
+   identify those most in need of solving.  The evaluation was done
+   based on two main criteria: 1) Is the deployment scenario common and
+   practical? and 2) Does the deployment scenario reveal any problems
+   resulting from MIPv4 and VPN coexistence?
+
+   The authors believe that the scenario in Section 2.1 is the most
+   important and practical one because of a rising need for providing
+   corporate remote users with continuous access to their Intranet
+   resources.  After analyzing each scenario, one realizes that problems
+
+
+
+Adrangi & Levkowetz          Informational                      [Page 9]
+
+RFC 4093         MIPv4 VPN Traversal Problem Statement       August 2005
+
+
+   occurring in scenarios in Sections 2.2 and 2.4 are either the same as
+   those in the scenario in Section 2.1 or a subset of them.  Therefore,
+   solving the scenario in Section 2.1 will also solve the scenarios in
+   Sections 2.2 and 2.4.  The scenarios in Sections 2.3 and 2.5 do not
+   introduce functional problems resulting from MIPv4 and VPN co-
+   existence, and thus there is no need to seek a solution.  A solution
+   for the deployment scenario in Section 2.1 is therefore seen as
+   essential, and this in turn can also be applied to solve problems in
+   other scenarios.  In subsequent sections, we will articulate the
+   roaming scenarios, the problems, and the solution guidelines relevant
+   to the scenario in Section 2.1.
+
+4.  Problem Statement
+
+   This section describes roaming scenarios corresponding to the
+   deployment scenario in Section 2.1 where an MN needs to have
+   continuous access to the Intranet resources regardless of whether it
+   is roaming inside or outside the Intranet, and their associated
+   problems.  The scenarios are constructed based on a multi-subnetted,
+   MIPv4-enabled Intranet (hereafter referred to as Intranet or VPN
+   domain) protected by an IPsec-based VPN gateway as depicted in
+   Figure 6.
+
+     ....Internet.......             .....VPN Domain..(Intranet).....
+     .                 .             .                              .
+     .  +----+         .           +----+     +-------+  +-------+  .
+     .  |MNs |         .           | VPN|     | Router|  | VPN/HA|  .
+     .  |away|         .<=========>|    |     | 1..n  |  | 1..n  |  .
+     .  +----+         .           | GW |     +-------+  +-------+  .
+     .                 .           +----+                           .
+     ...................             .        +-------+  +-------+  .
+                                     .        |  CN   |  | MNs   |  .
+                                     .        | 1..n  |  | home  |  .
+                                     .        +-------+  +-------+  .
+                                     .                              .
+                                     ................................
+
+               Figure 6: Intranet protected by a VPN gateway
+
+   The Intranet, as depicted in Figure 6, may include both wired (IEEE
+   802.3) and IEEE 802.11 wireless LAN deployments.  However, it is also
+   possible to see IEEE 802.11 deployments outside the Intranet due to
+   the perceived lack of current 802.11 security, as depicted in
+   Figure 7.
+
+
+
+
+
+
+
+Adrangi & Levkowetz          Informational                     [Page 10]
+
+RFC 4093         MIPv4 VPN Traversal Problem Statement       August 2005
+
+
+     ....Internet.......             .....VPN Domain..(Intranet).....
+     .                 .             .                              .
+     .  +----+         .           +----+     +-------+  +-------+  .
+     .  |MNs |         .           | VPN|     | Router|  | VPN/HA|  .
+     .  |away|         .<=========>|    |     | 1..n  |  | 1..n  |  .
+     .  +----+         .           | GW |     +-------+  +-------+  .
+     .                 .           |    |                           .
+     ...................           |    |     +-------+  +-------+  .
+                                   |    |     |  CN   |  | MNs   |  .
+         ..802.11 Wireless.. <====>|    |     | 1..n  |  | home  |  .
+         .    Network      .       +----+     +-------+  +-------+  .
+         .                 .         .                              .
+         ...................         ................................
+
+    Figure 7: IEEE 802.11 Wireless deployment outside the home network
+
+4.1.  Registering in Co-Located Mode
+
+   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
+   Section 2.1) results in the mobile-ip tunnel from MN to HA being
+   encapsulated inside the IPsec tunnel.  See Figure 8 below.  This
+   scenario is still possible, but has some major drawbacks.
+
+     ....Internet.......             .....VPN Domain..(Intranet).....
+     .                 .             .                              .
+     .  +----+         .           +----+     +-------+  +-------+  .
+     .  |MNs |         .           | VPN|     | Router|  | VPN/HA|  .
+     .  |away|<###################>|    |-----| 1..n  |->| 1..n  |  .
+     .  +----+         .   \       | GW |     +-------+  +-------+  .
+     .                 .    \      +----+                           .
+     ...................   mip       .        +-------+  +-------+  .
+                           inside    .        |  CN   |  | MNs   |  .
+                           IPsec     .        | 1..n  |  | home  |  .
+                                     .        +-------+  +-------+  .
+                                     .                              .
+                                     ................................
+
+                                 Figure 8
+
+   The MN obtains an address at its point of attachment (via DHCP
+   [RFC2131] or some other means), and then sets up an IPsec tunnel to
+   the VPN gateway, after which it can successfully register with its HA
+   through the IPsec tunnel.  The IPsec tunnel SA (Security Association)
+   is identified by a triplet consisting of SPI (Security Parameter
+   Index), MN's IP destination address (i.e., the address obtained at
+   the point of attachment), and Security Protocol (AH or ESP)
+   Identifier as described in [RFC2401].  This means that as the MN's IP
+
+
+
+Adrangi & Levkowetz          Informational                     [Page 11]
+
+RFC 4093         MIPv4 VPN Traversal Problem Statement       August 2005
+
+
+   destination address changes on each IP subnet handoff, the IPsec
+   tunnel needs to be re-established.  This could have noticeable
+   performance implications on real-time applications and in 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
+
+   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
+   address and co-located mode is possible, we run into severe trouble.
+   This is illustrated in Figure 9 and explained below:
+
+     ..Foreign Network..             .....VPN Domain..(Intranet).....
+     .                 .             .                              .
+     . +----+   +----+ .           +----+     +-------+  +-------+  .
+     . |MNs |   | FA | .           | VPN|     | Router|  | VPN/HA|  .
+     . |away|<??|    |<###########>|    |-----| 1..n  |->| 1..n  |  .
+     . +----+ \ +----+ .   \       | GW |     +-------+  +-------+  .
+     .         \       .    \      +----+                           .
+     ...........\.......   mip       .        +-------+  +-------+  .
+                 \         inside    .        |  CN   |  | MNs   |  .
+            MN expects     IPsec     .        | 1..n  |  | home  |  .
+            IPsec traffic            .        +-------+  +-------+  .
+                                     .                              .
+                                     ................................
+
+                                 Figure 9
+
+   When arriving at the visited network on the left in this figure, the
+   MN has to reach the FA with registration requests in order to have
+   the FA send them on to the HA.  However, the MN in all likelihood
+   cannot register with the FA because the registration requests will be
+   sent encrypted, and the FA will not be able to decrypt them.  If the
+   MN would have a policy that allowed split tunneling so that it could
+   reach the FA with clear text messages, then the FA would still not be
+   able to get through the VPN gateway unless the HA is reachable from
+   outside and the Intranet security policy allows MIP registration
+   packets to bypass the VPN gateway.
+
+   Even if the HA is reachable and the MIP registration succeeds, the FA
+   (which is likely in a different administrative domain) will not be
+   able to relay packets between the MN and the VPN gateway.  Packets
+   from the MN will be encapsulated by the FA with IP-in-IP [RFC2003],
+   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).
+
+
+
+
+Adrangi & Levkowetz          Informational                     [Page 12]
+
+RFC 4093         MIPv4 VPN Traversal Problem Statement       August 2005
+
+
+   The use of a 'trusted FA' has also been suggested in this scenario,
+   meaning an FA that is actually a combined VPN GW and FA.  The
+   scenario will work fine in this case, as the tunnel end-points are at
+   the FA and the VPN gateway as shown in Figure 10 below.  However, we
+   cannot expect that the FA in access networks (e.g., wireless hot-
+   spots or CDMA 2000 networks) will have security associations with any
+   given corporate network, so this is not particularly realistic in the
+   general mobility case.
+
+     ..Foreign Network..             .....VPN Domain..(Intranet).....
+     .                 .             .                              .
+     . +----+   +----+ .           +----+     +-------+  +-------+  .
+     . | FA |   | VPN| .           | VPN|     | Router|  | VPN/HA|  .
+     . |    |<--| GW |<###########>|    |-----| 1..n  |->| 1..n  |  .
+     . +----+   +----+ .   \       | GW |     +-------+  +-------+  .
+     .    |            .    \      +----+                           .
+     . +----+          .   mip       .        +-------+  +-------+  .
+     . |MNs |          .   inside    .        |  CN   |  | MNs   |  .
+     . |away|          .   IPsec     .        | 1..n  |  | home  |  .
+     . +----+          .             .        +-------+  +-------+  .
+     ...................             .                              .
+                                     ................................
+
+                                 Figure 10
+
+   Furthermore, this solution would leave the traffic between FA and MN
+   unprotected, and as this link in particular may be a wireless link,
+   this is clearly undesirable.
+
+4.3.  Summary: MIP Incompatibilities with IPsec-Based VPN Gateways
+
+   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
+   its home agent.  This is because the MN cannot reach its HA (inside
+   the private protected network) directly from the outside.  This
+   implies that the MIPv4 traffic from the MN to a node inside the
+   Intranet is forced to run inside an IPsec tunnel, and thus that it
+   will not 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 to register with its HA.
+
+   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
+
+
+
+Adrangi & Levkowetz          Informational                     [Page 13]
+
+RFC 4093         MIPv4 VPN Traversal Problem Statement       August 2005
+
+
+   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 would 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 to 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
+   across VPN gateways.
+
+5.1.  Preservation of Existing VPN Infrastructure
+
+   o  The solution MUST work with currently deployed VPN gateways.  This
+      is the whole raison d'etre of this investigation:  Finding a way
+      to deploy Mobile-IP in cases where a VPN solution is already in
+      place.
+
+5.2.  Software Upgrades to Existing VPN Client and Gateways
+
+   o  The solution SHOULD minimize changes to existing VPN
+      client/gateway software.
+
+5.3.  IPsec Protocol
+
+   o  The solution SHOULD NOT require any changes to existing IPsec or
+      key-exchange standard protocols implemented by VPN gateways.
+
+   o  The solution SHOULD NOT require that the VPN gateway or the VPN
+      client implement any new protocols in addition to the existing
+      standard protocols.
+
+5.4.  Multi-Vendor Interoperability
+
+   o  The solution MUST provide multi-vendor interoperability, whereby
+      MIPv4 mobility agents, mobility clients (MN), VPN server, and VPN
+      client solutions may come from four different vendors.  This is
+      typical for medium and large enterprises that purchase and deploy
+      best-of-breed multi-vendor solutions for IP routing, VPNs,
+      firewalls, etc.
+
+
+
+
+
+
+Adrangi & Levkowetz          Informational                     [Page 14]
+
+RFC 4093         MIPv4 VPN Traversal Problem Statement       August 2005
+
+
+5.5.  MIPv4 Protocol
+
+   o  The solution MUST adhere to MIPv4 protocol [RFC3344].  That is,
+      the solution MUST NOT impose any changes that violate MIPv4
+      protocol.
+
+   o  The solution MAY introduce new extensions to MIPv4 nodes per
+      guidelines specified in the MIPv4 protocol [RFC3344].  However, in
+      order to overcome barriers to deployment, it is highly desirable
+      to avoid any changes to MIPv4 mobility agents such as the FA and
+      HA.
+
+   o  The solution MAY require more than one instance of MIPv4 running
+      in parallel (multiple encapsulation).
+
+5.6.  Handoff Overhead
+
+   o  It is imperative to keep the key management overhead down to a
+      minimum, in order to support fast handoffs across IP subnets.
+      Therefore, the solution MUST propose a mechanism to avoid or
+      minimize IPsec tunnel SA renegotiation and IKE renegotiation as
+      the MN changes its current point of network attachment.
+
+5.7.  Scalability, Availability, Reliability, and Performance
+
+   o  The solution complexity MUST increase at most linearly with the
+      number of MNs registered and accessing resources inside the
+      Intranet.
+
+   o  The solution MAY introduce additional header or tunneling overhead
+      if needed.
+
+5.8.  Functional Entities
+
+   o  The solution MAY introduce new MIPv4-compliant functional
+      entities.
+
+5.9.  Implications of Intervening NAT Gateways
+
+   o  The solution MUST be able to work with the existing MIPv4 and
+      IPsec NAT traversal solutions [RFC3519] [RFC3715] [RFC3947].
+
+
+
+
+
+
+
+
+
+
+Adrangi & Levkowetz          Informational                     [Page 15]
+
+RFC 4093         MIPv4 VPN Traversal Problem Statement       August 2005
+
+
+5.10.  Security Requirements
+
+   o  The solution MUST provide security that is not inferior to what 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
+
+   This document describes an existing problem and proposes guidelines
+   for possible solutions; as such, its security implications are
+   indirect, through the guidelines it proposes for the solutions.
+   Section 5.10 gives the relevant security requirements.
+
+7.  Acknowledgements
+
+   The authors who contributed text to this document were, in no
+   particular order: Farid Adrangi, Milind Kulkarni, Gopal Dommety, Eli
+   Gelasco, Qiang Zhang, Sami Vaarala, Dorothy Gellert, Nitsan Baider,
+   and Henrik Levkowetz.
+
+   The authors would like to thank other contributors, especially
+   Prakash Iyer, Mike Andrews, Ranjit Narjala, Joe Lau, Kent Leung,
+   Alpesh Patel, Phil Roberts, Hans Sjostrand, Serge Tessier, Antti
+   Nuopponen, Alan O'Neill, Gaetan Feige, and Brijesh Kumar, for their
+   feedback and help in improving this document.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Adrangi & Levkowetz          Informational                     [Page 16]
+
+RFC 4093         MIPv4 VPN Traversal Problem Statement       August 2005
+
+
+8.  References
+
+8.1.  Normative References
+
+   [RFC3344]  Perkins, C., "IP Mobility Support for IPv4", RFC 3344,
+              August 2002.
+
+8.2.  Informative References
+
+   [RFC1918]  Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.,
+              and E. Lear, "Address Allocation for Private Internets",
+              BCP 5, RFC 1918, February 1996.
+
+   [RFC2003]  Perkins, C., "IP Encapsulation within IP", RFC 2003,
+              October 1996.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2131]  Droms, R., "Dynamic Host Configuration Protocol", RFC
+              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
+              Network Address Translation (NAT) Devices", RFC 3519, May
+              2003.
+
+   [RFC3715]  Aboba, B. and W. Dixon, "IPsec-Network Address Translation
+              (NAT) Compatibility Requirements", RFC 3715, March 2004.
+
+   [RFC3947]  Kivinen, T., Swander, B., Huttunen, A., and V. Volpe,
+              "Negotiation of NAT-Traversal in the IKE", RFC 3947,
+              January 2005.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Adrangi & Levkowetz          Informational                     [Page 17]
+
+RFC 4093         MIPv4 VPN Traversal Problem Statement       August 2005
+
+
+Authors' Addresses
+
+   Farid Adrangi
+   Intel Corporation
+   2111 N.E. 25th Avenue
+   Hillsboro  OR
+   USA
+
+   Phone: +1 503-712-1791
+   EMail: farid.adrangi@intel.com
+
+
+   Henrik Levkowetz
+   Ericsson Research
+   Torshamsgatan 23
+   SE-164 80 Stockholm
+   SWEDEN
+
+   Phone: +46 7 08 32 16 08
+   EMail: henrik@levkowetz.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Adrangi & Levkowetz          Informational                     [Page 18]
+
+RFC 4093         MIPv4 VPN Traversal Problem Statement       August 2005
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2005).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING 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.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   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
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at ietf-
+   ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+Adrangi & Levkowetz          Informational                     [Page 19]
+