S.Tessier Internet Draft T-Systems Document: draft-tessier-mobileip-ipsec-00.txt June 2002 Expires: December 2002 Guidelines for Mobile IP and IPSec VPN Usage Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html 1. Abstract This document highlights some of the issues that should be consider when IPSec [2] and Mobile IP [3] inter-work with each other. This work finds some applications in the following fields: VPN traversal requirement [4], IPSec Remote access client co-located with a Mobile Node, IPSec security Gateway running in parallel with a Home Agent or a MIP Proxy [5]. The purpose of this document is informational. Rather that strictly indicating how both protocol should take advantages of each other, which is a subjective task left to the user and implementation developers of both protocol, it rather proposes some usage guidelines and general considerations. 2. Motivation of this Document Mobile IP finds an application as tunneling mechanism for VPN usage: IP encapsulation within IP [6] is indeed a tunneling mechanism. There is only little changes to perform to turn this layer-3 tunneling mechanism into a layer-3 VPN mechanism, basically encryption. Since IPSecÆs ESP provides encryption, many activities Tessier [Page 1] Internet Draft Guidelines for Mobile IP and IPSec Usage June 2002 early started to evaluate the feasibility of a combination of both protocol [7]. More recently, an increasing demand raised from the so-called mobile VPN area to allow NAT [8] and VPN [4] [9] tunneling for Mobile IP messages especially, but not only, control (registration) messages. This document describes some implication of an Mobile IP and IPSec integrating picture with regards to network topology and environment. For more information about VPN usage scenarios the reader is invited to check the above mentioned references as well as section 3 of [10]. 3. Order of Tunneling There is only two way of cooperation between the IPSec and the Mobile IP stack: Either the IPSec (ESP) tunnel takes place within the Mobile IP tunnel or the other way around, meaning that the Mobile IP tunnel is secured as payload within an ESP tunnel. The following two sections describe those modes and provides pros and cons for each method regarding a mobile VPN deployment. It is assumed that bi-directional tunneling (Mobile IP reverse tunneling) is applied as specified in [11]. 3.1. IPSec tunnel inside the Mobile IP tunnel In that case, the tunneling order of figure 1 applies between MN, HA and IPSec/VPN Gateway. Case 1 and 2 differentiate the type of care- of-address aquired by the MN, case 1 for co-located care-of-address and case 2 for FA care-of-address. <---------Internet--------> <--DMZ--> <--Intranet--> 1. MN([---------------------]VPN GW--------)HA---CN 2. MN[---------]FA([--------]VPN GW--------)HA---CN [--] IPSec tunnel (--) MIP tunnel Figure 1: Mobile IP tunnel in IPSec VPN tunnel The benefit is: - Seamless mobility due to Mobile IP that means real mobility support which is the obvious definition of mobile VPNs. While the drawbacks are: - Since local networks use usually private addresses, NAPT is a major problem. A solution like the one described in [7] needs to be applied - It prevents integration of Mobile IP in already existing IPSec- based VPN products - Home FW has to pass through Mobile IP traffic to the HA and Tessier [Page 2] Internet Draft Guidelines for Mobile IP and IPSec Usage June 2002 therefore to trust the HA, MN and CN which will be unacceptable by system administrators. - In the case where FA care-of-address is used, security association needs to be hop-by-hop established 3.2. Mobile IP tunnel inside the IPSec tunnel In that case, the tunneling order of figure 2 applies between MN, HA and IPSec Gateway. Case 1 and 2 differentiate the type of care-of- address aquired by the MN, case 1 for co-located care-of-address and case 2 for FA care-of-address. For illustrative purpose, [12] provides a concrete realization of such a procedure. <-------Internet------> <----DMZ----> <-Intranet-> 1. MN[(------------------FW---)]HA---FW---------CN 2. MN[--------FA(--------FW---)]HA---FW---------CN [--] IPSec tunnel (--) MIP tunnel Figure 2: IPSec VPN tunnel in Mobile IP tunnel The benefits are: - Authentication with the FA based on AAA is possible and useful for a number of business models - NAPT is not a problem for Mobile IP since it is solved by the IPSec tunnel - Most Hotspots, ISPs etc. provide DHCP-based (care-of) addresses, so FAs are no more a problem - The FW has full authority to apply corporate policies to the Mobile IP data traffic. While drawback is: - No seamless mobility 4. Network Topology Consideration There maybe situation where the network topology itself will dictate the way how IPSec and Mobile IP should work together. Corporate LANs very often use NAT and therefore private address. The type (private or public) of the care-of-address and the fact that this type could be predict by specific usage scenario (type of visited network, e.g. cellular link, hot-spot) is also a criteria that should influence the way the Security Association should be renew/refresh after movement of the end terminal and the subsequent IP-subnet change. 5. Mobile IPv6 Consideration Tessier [Page 3] Internet Draft Guidelines for Mobile IP and IPSec Usage June 2002 Since the problems motivating this document are inherent to IPv4 Mobile IPv4 and since a rough consensus as well as a original design intention seem both to state that Mobile IPv6 will solve these problems, no considerations is here made about Mobile IPv6. 6. Security Considerations This document consider the usage of IPSec and therefore adopt the considerations of RFC2401 7. References [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [2] Kent, S., and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998. [3] Perkins, C., "IP Mobility Support for IPv4", RFC 3220, January 2002. [4] Adrangi, F., Leung, K., Kulkarni, M., Patel, A., Zhang, Q., Lau., J. ôProblem Statement and Requirements for Mobile IPv4 Traversal Across VPN Gatewaysö draft-ietf-mobileip-vpn-problem- statement-00.txt (work in progress), March 2002 [5] Adrangi, F., Iyer, P., Leung, K., Kulkarni, M., Patel, A., Zhang, Q., Lau, J. ôMobile IPv4 Traversal Across IPsec-based VPN Gatewaysö draft-adrangi-mobileip-vpn-traversal-02.txt (work in progress), June 2002. [6] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1996. [7] The Portland State University Secure Mobile Networking Project, http://www.cs.pdx.edu/research/SMN/ [8] Levkowetz, H. and Vaarala, S., ôMobile IP NAT/NAPT Traversal using UDP Tunnellingö draft-ietf-mobileip-nat-traversal-04.txt (work in progress), May 2002 [9] Sjostrand, H. and Levkowetz, H., ôMobile IP and Virtual Private Networks Problem Statementö draft-sjostrand-mobileip-vpn-problem- stat-00.txt (work in progress), February 2002. [10] Kelly, S., Ramamoorthi, S., ôRequirements for IPsec Remote Access Scenariosö draft-ietf-ipsra-reqmts-05.txt (work in progress), March 2002. Tessier [Page 4] Internet Draft Guidelines for Mobile IP and IPSec Usage June 2002 [11] Montenegro, G., et al., ôReverse Tunneling for Mobile IPö, revised, RFC3024, January 2001 [12] M. Danzeisen, T. Braun: Access of Mobile IP Users to Firewall Protected VPNs, Mobile Communication over Wireless LAN, Workshop at Informatik 2001, Vienna, September 26-29, 2001 8. Acknowledgments The author would like to overall thank the authors of the references listed above for their help in better understanding the problematic of IPSec use in conjunction with Mobile IP. 9. Author's Addresses Serge Tessier T-Systems Nova GmbH Berkom Goslarer Ufer 35, D-10589 Berlin, Germany Phone: +49 (30) 34 97-31 14 Email: serge.tessier@t-systems.com Full Copyright Statement "Copyright (C) The Internet Society (date). 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 implmentation 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.