Internet Engineering Task Force Hans Sjostrand INTERNET DRAFT Henrik Levkowetz Expires August 2002 ipUnplugged February 2002 Mobile IP and Virtual Private Networks Problem Statement < draft-sjostrand-mobileip-vpn-problem-stat-00.txt > Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. This document provides information for the Internet community. It does not specify an Internet standard of any kind. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Distribution of this document is unlimited. Please send comments to the Mobile IP NAT traversal and VPN mailing list, . Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract Both in enterprise and operator environments, Mobile IP and Virtual Private Network technologies are coexisting and providing mobility and security. This draft describes some scenarios how this can be achieved and also describe the problem statement for Mobile IP and Virtual Private Network deployment. Sjostrand & Levkowetz Expires August 2002 [Page 1] Internet Draft Mobile IP and VPN Problem Statement February 2002 1. Introduction As the workforce goes mobile, there is an increasing need for coorporations to offer its employees continuous access to network resources and colleagues regardless of actual location. Mobile VPNs are created to solve the problem of always being reachable as well as to reach services. In a Mobile VPN, a mobile user is constantly in touch with its network resources. There are never any need for the mobile user to terminate application sessions when moving between subnets or access networks of different types. To provide Mobile VPNs, Mobile IP is very well suited to coexist and complement Virtual Private Network Technologies such as IPsec. Mobile IP provides mobility and roaming and VPN provides authentication, integrity and confidentiality. However, in some deployment scenarios the Mobile IP technology as defined today is to restrictive. This document describes some scenarios for Mobile IP VPNs and also gives a problem statement for the scenarios where the Mobile IP technology might be extended to provide easier deployment and co-existence. 1.1 Terminology VPN Gateway (GW) A GW will typically terminate the Virtual Private Network connection. The VPN connection is in this document assumed to be an IPsec tunnel. Firewall (FW) A system designed to prevent unauthorized access to or from a private network. All messages entering or leaving the intranet pass through the firewall, which examines each message and blocks those that do not meet the specified security criteria. Network Address Translation (NAT) NAT would allow hosts within a private network to transparently access hosts in the external network. The NATs used are of the NAPT variety, also translating transport identifier (e.g., TCP and UDP port numbers, ICMP query identifiers). Mobile Node (MN) A host or router that changes its point of attachment from one network or subnetwork to another [RFC3220]. Home Agent (HA) 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 [RFC3220] Sjostrand & Levkowetz Expires August 2002 [Page 2] Internet Draft Mobile IP and VPN Problem Statement February 2002 Foreign Agent (FA) A router on a mobile node's visited network which provides routing services to the mobile node while registered [RFC3220]. Correspondent Node (CN) A peer with which a mobile node is communicating. A correspondent node may be either mobile or stationary [RFC3220]. DeMilitarized Zone (DMZ) A network added between a protected network and an external network in order to provide an additional layer of security. Please note that most of the terms defined above relates to functional entities and not physical network devices. It may very well be the case that the same network device is offering both GW, FW, NAT, HA and FA service. 2. Mobile IP VPN scenarios There are a few typical scenarios that later can be expanded and combined. These are all using plain vanilla Mobile IP [RFC3220] with reverse tunnelling [RFC3024]. 2.1 Simple flat network In the simplest case for Mobile IP and VPN interworking the network is one simple flat Local Area Network. The Mobile IP Home Agent is co-located with the VPN GW agent. The VPN client resides in the Mobile Node and originates the IPsec tunnel. In the case where the Mobile Node is registered with a Foreign Agent the foreign agent encapsulates the traffic in a MIP tunnel. The combined Home agent and VPN Gateway decapsulates and decrypts and also performs firewalling. ....Foreign.Network.... .....VPN.Domain..... . . . . . +----+ +----+ . +-------+ +----+ . . | MN | | FA +----------------------+- HA | | CN | . . | O=========( ) )==O--+----+ | . . | |IPsec +----------------------+-FW/GW | | | . . +----+ +----+ . MIP tunnel +-------+ +----+ . . . . . ....................... .................... Sjostrand & Levkowetz Expires August 2002 [Page 3] Internet Draft Mobile IP and VPN Problem Statement February 2002 +-----+ +-----+ +-----+ +-----+ | IP | | IP | | IP |<-->| IP | +-----+ +-----+ +-----+ +-----+ |IPsec|<-->|IPSec| |IPsec| +-----+ +-----+ +-----+ | MIP |<--------------------->| MIP | +-----+ +-----+ Fig 1. With a foreign agent (and protocol stacks) MIP encapsulation denotes in most cases IP-in-IP encapsulation [RFC2003]. IPsec encapsulation denotes in most cases IP Encapsulating Security Payload [RFC2406], tunnel mode. In the case where the mobile node uses co-located care-of-address the MN originates both the IPsec and Mobile IP tunnel. The corresponding node and the mobile node may very well have private addresses without requiring any NAT traversal functionality in Mobile IP. The corresponding nodes may very well lie outside the home network or the VPN domain. 2.2 Networks with internal routing There are several things that the previous scenario does not handle, one of them are larger corporate/private networks with internal routing. ..Foreign.Network.. ........VPN.Domain........... . . . . . . +------+ +------+ +-------+ . . +----+ +----+ . | | |Router| | HA/GW | . . |MN's| | FA | . | Fire | | 1..n | | 1..n | . . |away| | | .<------>| wall | +------+ +-------+ . . | | | | . | | . . +----+ +----+ . | NAT | +------+ +-------+ . . . +------+ | CN | | MN's | . . . . | 1..n | | home | . ................... . +------+ +-------+ . ............................. Fig 2. Network elements in a larger routed VPN domain There could be any number of routers, home agents and corresponding nodes in the VPN domain. The VPN domain maintains a non-routable address space. There might or might not be an foreign agent in the foreign network. The scenario will be as below (<===> signifies an IPsec in MIP tunnel ). Sjostrand & Levkowetz Expires August 2002 [Page 4] Internet Draft Mobile IP and VPN Problem Statement February 2002 MN publ.IP <===> publ.IP FW/NAT priv.IP <===> Router <===> HA/GW <--> <===> Router <===> HA/GW <--> NAT is performing 1:1 address translation between public and private addresses, with each public address being the public address of the corresponding HA. The firewall is instructed to allow Mobile IP trafic in. Both MIP and IPsec are terminated at the combined HA and VPN gateway in this case too. Only authenticated IPsec traffic will be forwarded into the internal network by the HA. There may be implementation issues in some HAs that may determine if they will accept registrations and tunnels directed to their public IP address on a private ip interface. The case where there are foreign agents in the VPN domain is also supported. The corresponding nodes may very well lie outside the VPN domain. 3. Problem Statement There are quite a few practical deployment cases where Mobile IP as defined today does not hold up. 3.1 Separate the Mobile IP home agent and the VPN agent The scenarios in the previous section all had the Mobile IP and VPN functionality placed in the same network devices. There are deployment cases when the Mobile IP and VPN functionality has to be placed on different network devices, for instance: * The product that offers the Mobile IP home agent functionality doesn't offer VPN gateway functionality but has to be complemented with another network device offering the VPN gateway functionality. * Mobile IP is being deployed in an already existing VPN infrastructure in order to add the mobility. * The enterprise or service provider wants to purchase the Mobile IP and VPN technology from two different vendors or application providers. Problem 1 : Separating the Mobile IP home agent and the VPN agent in separate network devices introduces a router hop between the home agent and the home network. Mobile IP according to [RFC3220] does not allow this. Sjostrand & Levkowetz Expires August 2002 [Page 5] Internet Draft Mobile IP and VPN Problem Statement February 2002 3.2 Mobile IP home agent in DMZ The scenarios in the previous section assumed that the Mobile IP home agent is placed in the home network. There are deployment cases when the Mobile IP home agent would be placed in the DMZ. * The Mobile IP home agent is owned by another entity, e.g. a service provider offering mobility as a managed service. * Mobile IP is being deployed in an already existing infrastructure in order to add the mobility. There are requirements that the existing DMZ traversal policies are maintained. Problem 2 : Placing the Mobile IP home agent anywhere else than in the home Network introduces at least one router hop between the home agent and the home network. 3.3 Routed home network The scenarios in the previous section assumed that the Mobile IP home network was one homogenous Layer 2 network. Many corporate networks for mid or large sized companies are routed networks. There are design guides that recommend ~50 hosts per routed segment of the network. Having more than a C-network (~250 hosts) are almost certanly causing problems. * It's not always feasible to deply one HA for each of these small groups. * It's not always feasible to have fewer (or only one) HA's with all users connecting up registered away co-located for most of the time, thus tromboning up all traffic to some central points. Problem 3 : Defining larger networks as home network may introduce router hops between the Mobile IP home agent and mobile nodes in their home network. 4. References [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, Oct 1996 [RFC3024] Montenegro, G., "Reverse Tunnelling for Mobile IP, revised", RFC 3024, January 2001. [RFC2406] S. Kent, R. Atkinson., "IP Encapsulating Security Payload (ESP)",RFC 2406, November 1998. Sjostrand & Levkowetz Expires August 2002 [Page 6] Internet Draft Mobile IP and VPN Problem Statement February 2002 [RFC3220] Perkins, C., "IP Mobility Support for IPv4", RFC 3220, January 2002. 5. Authors' Addresses Hans Sjostrand ipUnplugged P.O. Box 101 60 S-121 28 Stockholm, Sweden Email: hans@ipunplugged.com Henrik Levkowetz ipUnplugged P.O. Box 101 60 S-121 28 Stockholm, Sweden Email: henrik@ipunplugged.com 6. Full Copyright Statement Copyright (C) The Internet Society (2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing 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 revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. Sjostrand & Levkowetz Expires August 2002 [Page 7]