Internet Draft S. Tessier Document: draft-tessier-mobileip-ipsec-01.txt T-Systems Nova Expires: June 2003 December 2002 Guidelines for Mobile IP and IPSec VPN Usage Status of this Memo This document is an Internet-Draft and is subject to 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 oher 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 considered 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 (IPSec running on top of Mobile IP or the other way around), which is a subjective task left to the user and implementation developers of both protocol, it rather proposes some usage guidelines and general considerations regarding the preference of one solution over the other one. 2. Motivation Mobile IP finds an application as tunneling mechanisms for VPN usage: IP encapsulation within IP [5] is indeed a tunneling mechanisms. There is only little change to perform to turn this layer-3 tunneling mechanism into a layer-3 VPN mechanism, basically encryption. Since Tessier Expires June 2003 [Page 1] Internet Draft Guidelines for Mobile IP and IPSec Usage December 2002 IPSecÆs ESP provides encryption, many activities early started to evaluate the feasibility of a combination of both protocol [6]. More recently, an increasing demand raised from the so-called mobile VPN area to allow NAT [7] and VPN [3] [8] 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 [9]. For the sake of conciseness we restrict our discussion to ESP and confuse the term IPSec Tunnel with ESP encapsulation (In a first approximation, tunnel mode and transport mode are not distinguished). More exactly, when talking about IPSec, this document only means IKE and ESP. 3. Order of Tunneling There is only two way of co-operation 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 [10]. 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 (--) Mobile IP 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 Tessier Expires June 2003 [Page 2] Internet Draft Guidelines for Mobile IP and IPSec Usage December 2002 - Home FW has to pass through Mobile IP traffic to the HA and therefore to trust the HA, MN and CN which will be unacceptable by system administrators. 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, [11] 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 (--) Mobile IP tunnel Figure 2: IPSec VPN tunnel in Mobile IP tunnel The benefits are: - Authentication with the FA based on AAA is useful for a number of business models - NAPT is not a problem for MIP since it is supposed to be solved by the IPSec tunnel [12] - Most Hotspots, ISPs etc. provide DHCP-based (care-of) addresses --> FA are not really a problem - The home FW has full authority to apply corporate policies to the Mobile IP data traffic. While drawbacks are: - No seamless mobility - In the case where FA care-of-address is used, security association needs to be hop-by-hop established 4. Distinction between Mobile IP signaling and data messages Mobile IP control messages, namely agent advertisements, agent solicitations, registration requests and registration replies, are fundamentally different from Mobile IP tunneled packets. Though there is nothing like a signaling channel in the today Internet for this kind of message, finding a way to effectively handle them with a special treatment is a benefit since those critical control messages condition all the re-routing of Mobile IP. Considering Mobile IP as a stand alone protocol, this distinction is evident since registration messages are authorized. Concerns have also early raised about the fact that discovery messages (agent advertisement and solicitation) should be made secure i.e. trustful. But considering the global picture where Mobile IP and IPSec work together, there could be a subsidiary distinction, regarding the Tessier Expires June 2003 [Page 3] Internet Draft Guidelines for Mobile IP and IPSec Usage December 2002 IPSec policy apply to Mobile IP messages according to their nature: control plane or user plane messages. An illustrative example of that policy is the following one. For outbound packets from the Mobile Node IPSec layer: Apply IPSec to all packet except Mobile IP registration request For outbound packets from the VPN GW IPSec layer: Apply IPSec to all packet except Mobile IP registration request The discrimination rule is done according to the given nature (Transport Protocol and Port Number) of Mobile IP registration messages and IPSec SPD is configured appropriately. This procedure does not add new security threats, with the exception of location privacy, that is no more ensured, since Mobile IP registration packets are only authenticated and not cyphered. Moreover, such a distinction may be needed in some deployment scenarios: For example, encrypting Mobile IP registration messages between Mobile Node and VPN Gateway will indeed prohibit Foreign Agents, if present, to understand them (see the drawbacks of section 3.2.). 5. Cooperation between both tunneling There is no fundamental motivation for excluding one or the other way of ordering the IP in IP and the ESP tunneling mechanism in one order or the other. Section 8 illustrates that the level of security in one configuration or in the other is the same or at least comparable in its effective realization. From a purely design perspective, there is no restriction of applying IPSec to an IP in IP encapsulated packet. Touch and Eggert already considered that problematic in [13] and concluded that great attention should be put on how the IPSec policy is apply, though their work was not related to Mobile IP itself. Here is quotted a very useful statement from Annex A: ôThere are inconsistencies between the IPIP encapsulation rules specified by IPsec and those specified by Mobile IP. The latter specification is standards track, and the IP protocol number of 4 (payload of an IP packet of type 4) is assigned by IANA to RFC 2003 [5]. IPsec does not specify any limits on the types of IP packets which can be secured by transport mode, so the use of IPIP inside an IPsec transport packet can be confused with IPsec tunnel mode.ö 6. Network Topology There maybe situation where the network topology itself will dictate the way how IPSec and Mobile IP should work together. Tessier Expires June 2003 [Page 4] Internet Draft Guidelines for Mobile IP and IPSec Usage December 2002 Corporate LANs very often use NAT and therefore private addresses or non-globally routable addresses. However NA(P)T is a well-known nasty problem and it might even be impossible to find out a single unambiguous outer identifier on behalf of NATted hosts [14]. 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. 7. Mobile IPv6 Consideration 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. [15] provides some guidelines about interaction between IPSec and Mobile IPv6. 8. Security Considerations This document consider the usage of IPSec and therefore adopt the considerations of RFC2401. The fundamental requirement driving the way both protocol should work together is security: No new threat should be added in one solution with regard to the other one. Table 1 compares both way of cooperation -IPSec in Mobile IP or the other way around- in a security perspective with the indication of possible mechanisms used for ensuring given non-exhaustive security services. |----------------------------------------------------------------| | | Mobile IP in IPSec | IPSec in Mobile IP | |----------------------------------------------------------------| |Confidentiality | Absolute - ESPÆs | Relative - ESPÆs | | | cipher algorithm | cipher algorithm | |----------------------------------------------------------------| | Privacy | IKE (MM) | None | |----------------------------------------------------------------| | Integrity | Absolute û ESPÆs | Relative û ESPÆs | | | hash algorithm | hash algorithm | |----------------------------------------------------------------| | Authentication| Authentication Data | Mobile-Home | | | field of ESP header |Authentication extension | |----------------------------------------------------------------| | Anti-replay | Sequence number | Identification field of | | | field of ESP header | registration message | |----------------------------------------------------------------| Table 1: Security services provided by both solutions Tessier Expires June 2003 [Page 5] Internet Draft Guidelines for Mobile IP and IPSec Usage December 2002 Note that privacy is here to be understood in the sense of identity protection. Note that Mobile IP differentiates between control plane and user plane packets and that without IPSec, security services are only provided to control plane packets. A deeper analyze is needed before drawing any conclusion (besides the fact that the author does not consider himself as a security expert) whether one solution could be more secure than the other but it should already be clear that the mechanisms themselves are comparable in their realization e.g. in both cases ESP is used for confidentiality. Indeed, the future task could be answering the following question: Does an IP-in-IP encapsulation eliminate the security benefits provided by ESP? The following statement should be considered: Mobile IP should leverage off of the developments of IPSec rather than developing its own security framework. 9. References [1] Kent, S., and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998. [2] Perkins, C., "IP Mobility Support for IPv4", RFC 3220, January 2002. [3] 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. [4] 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. [5] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1996. [6] The Portland State University Secure Mobile Networking Project, http://www.cs.pdx.edu/research/SMN/. [7] 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. [8] 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. Tessier Expires June 2003 [Page 6] Internet Draft Guidelines for Mobile IP and IPSec Usage December 2002 [9] Kelly, S., Ramamoorthi, S., ôRequirements for IPsec Remote Access Scenariosö draft-ietf-ipsra-reqmts-05.txt (work in progress), March 2002. [10] Montenegro, G., et al., ôReverse Tunneling for Mobile IPö, revised, RFC3024, January 2001. [11] 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. [12] Aboba, B., "IPsec-NAT Compatibility Requirements", draft-ietf- ipsec-nat-reqts-02.txt (work in progress), August 2002. [13] Touch, J. and Eggert, L., ôUse of IPSec Transport Mode for Dynamic Routingö draft-touch-ipsec-vpn-04.txt (work in progress), June 2002. [14] Daigle, L. and IAB, ôIAB Considerations for UNilateral Self- Address Fixing(UNSAF)Across Network Address Translationö, RFC 3424, November 2002. [15] Arko, J., Devarapalli, V., Dupont, F., "Using IPsec to Protect Mobile IPv6 Signaling between Mobile Nodes and Home Agents", draft-ietf-mobileip-mipv6-ha-ipsec-01.txt (work in progress), October 2002. 10. 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. 11. 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 Tessier Expires June 2003 [Page 7] Internet Draft Guidelines for Mobile IP and IPSec Usage December 2002 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. Tessier Expires June 2003 [Page 8]