Internet Engineering Task Force Eva Gustafsson INTERNET DRAFT Anders Herlitz Date: November 1998 Annika Jonsson Martin Korling Ericsson UMTS/IMT-2000 and Mobile IP/DIAMETER Harmonization draft-gustafsson-mobileip-imt-2000-00.txt Status of this Memo This document is an Internet-Draft. 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." To view the entire list of current Internet-Drafts, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), ftp.nic.it (Southern Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). Abstract The purpose of this document is to form a basis for discussion about the development of the Mobile IP standard. It is foreseen that cellular mobile systems will give rise to a widespread global use of IP mobility tunnels. We describe scenarios and identify important issues for the Mobile IP specification and the proposed DIAMETER extensions for Mobile IP. Gustafsson, Herlitz, Jonsson, Korling Expires May 1998 [Page 1] INTERNET DRAFT November 1998 Table of contents 1. Introduction...................................................2 1.1. Terminology..................................................3 2. Mobile IP for IMT-2000: scenarios and general description......3 2.1. Initial registration for public Internet access..............4 2.2. Initial registration for access to private network/ISP...... 5 2.3. Subsequent registration (handover)...........................6 3. Issues for consideration.......................................7 3.1. Authentication...............................................7 3.2. Dynamic address assignment...................................8 3.3. Surrogate registrations......................................8 3.4. Home agent in visited network................................8 3.5. VPN Identifier Extension.....................................8 3.6. Smooth handover..............................................9 4. Conclusions....................................................9 5. References.....................................................9 1. Introduction The General Packet Radio System (GPRS) will be deployed in GSM cellular mobile systems starting 1999 and give IP mobility service to potentially hundreds of millions of users. The GPRS Tunnelling Protocol (GTP) will introduce global scale IP mobility tunnels. Now, the GPRS standard is evolving into the Universal Mobile Telecommunication System (UMTS) which fulfills the ITU requirements for third generation mobile systems, IMT-2000. In the Mobile IP working group, many extensions and enhancements of the base specification have been proposed. However, there has been a lack of discussion on applicability and requirements for an evolution towards a commercial Internet-wide deployment of Mobile IP. The first phase of UMTS/IMT-2000 is being standardized and is foreseen to be based on GPRS mobility mechanisms. With the subsequent evolution of UMTS/IMT-2000 there is an opportunity to harmonize the developments of GTP and Mobile IP. The goal would be to create one standard for IP mobility, common to cellular systems and the Internet as a whole. Gustafsson, Herlitz, Jonsson, Korling Expires May 1998 [Page 2] INTERNET DRAFT November 1998 The purpose of this document is to stimulate discussion about the evolution of the Mobile IP standard. In Section 2, we describe scenarios that are important from a cellular perspective and extract requirements on functionality and interfaces. The scenarios are general enough to be applicable also to non cellular situations. In Section 3, we list important issues for consideration in the future development of Mobile IP and the proposed DIAMETER extensions. 1.1 Terminology AAA server Server for Authentication, Authorization and Accounting. The home AAA server (HAAA) of a mobile node is located in the mobile node's home network. The foreign AAA server (FAAA) of a mobile node is located in the mobile node's visited network. Foreign agent (FA) The foreign agent, which is located in the visited network of a mobile node, provides routing services to the mobile node while it is registered [5]. Home agent (HA) As specified in [5], the home agent maintains information of the current location of the mobile node and tunnels datagrams to it. Home network The home network is where the mobile user gets its Network Access Identifier (NAI) [1]. This is in contrast to [5], which defines the home network as the IP network which contains the mobile node's IP address. Mobile node A host or a router which changes its point of attachment from one network or sub-network to another [5]. Private network/ISP We use the term private network/ISP to describe for instance a corporate network or an ISP that the mobile node wants to access. Visited network The visited network of a mobile node is where the mobile node is located, when not in its home network. Gustafsson, Herlitz, Jonsson, Korling Expires May 1998 [Page 3] INTERNET DRAFT November 1998 2. Mobile IP for IMT-2000: scenarios and general description Considering Mobile IP as part of the IMT-2000 evolution puts requirements on its specification. This section gives a few examples on network scenarios, and emphasizes the need for additional functionality in Mobile IP. The discussion is based on Mobile IP and DIAMETER as specified in [5] and [2] respectively. We generally assume that an AAA server is a DIAMETER server, as specified in [4][2]. In our discussions, we assume secure communication among agents (home and foreign agents) within an operator's network. We also assume secure communication among different AAA servers, possibly based on existing roaming agreements among cellular system operators. We assume that authentication performed for the radio link access is handled by functions specific to the cellular operator for the radio access network. Similarly, we assume that radio link encryption, and the required key distribution, is handled separately in the radio access network. That is, we specify the IP mobility functions independently of the radio-specific functionality. The scenarios focus on the registration of a mobile node, and we distinguish three major registration cases: (i) initial registration for public Internet access; (ii) initial registration for access to a private network/ISP; and (iii) subsequent registration when a mobile node changes foreign agent within the same operator's network. 2.1 Initial registration for public Internet access This section discusses initial registration for public Internet access when the mobile node is located in a visited network. In the first scenario, the home agent is located in the home network (Fig. 1). This is essentially the scenario described in [2] and [5]. Visited network Home network +-------+ +-------+ | FAAA | ----------------- | HAAA | +-------+ +-------+ | | +---+ +-----+ +-----+ |MN |----| FA | | HA | +---+ +-----+ +-----+ Fig. 1. Public Internet access for a mobile node in a visited network. The home agent is located in the home network. Gustafsson, Herlitz, Jonsson, Korling Expires May 1998 [Page 4] INTERNET DRAFT November 1998 For registration, the mobile node sends a Registration Request to the foreign agent, which relays the request in a DIAMETER message to the FAAA server. The FAAA server relays the message to the HAAA server. As described in [2], the HAAA server may perform authentication based on a challenge-response procedure. The HAAA server also generates session keys for the mobile node. Then the HAAA relays the Registration Request in a DIAMETER message to the home agent. The home agent authenticates the mobile node and generates a Registration Reply, which is relayed back to the mobile node via the HAAA server, the FAAA server and the foreign agent. This short description opens a general question for Mobile IP in combination with DIAMETER: where shall the authentication be performed? As specified in [5], the mobile node is authenticated by its home agent through the Mobile-Home Authentication Extension in the Registration Request. Similarly, the home agent is authenticated by the mobile node in the Registration Reply. According to the DIAMETER extensions for Mobile IP, the mobile node may also be authenticated by the HAAA server, based on a challenge-response procedure [2]. There is an apparent duplication of functionality. Next, we consider a second scenario for public Internet access. Here, the home agent is located in the visited network (Fig. 2). This means that the mobile node may dynamically obtain a mobility tunnel whose end-point is within the visited network. The scenario is motivated by a need for route optimization without the requirement on security associations between the mobile nodes and all their correspondent nodes. This is especially important for delay-sensitive traffic. Visited network Home network +-------+ +-------+ | FAAA | ----------------- | HAAA | +-------+ +-------+ | | +---+ +-----+ +-----+ |MN |----| FA | | HA | +---+ +-----+ +-----+ Fig. 2. Public Internet access for a mobile node in a visited network. The home agent is located in the visited network. As in the first scenario, the mobile node sends a Registration Request to its home agent via the foreign agent and the FAAA server. This scenario emphasizes the question of where to perform authentication. A possible solution is to let the HAAA server perform initial Gustafsson, Herlitz, Jonsson, Korling Expires May 1998 [Page 5] INTERNET DRAFT November 1998 authentication and key distribution. Subsequent authentications could be performed by the home agent in the visited network, without involving DIAMETER signalling. Such an authentication procedure would require changes to the Mobile IP as well as to the DIAMETER specifications. 2.2 Initial registration for access to private network/ISP This section gives examples of access to a private network/ISP when the mobile node is located in a visited network. In general, scenarios which contain private address spaces with gateways are supported by the compound tunnels defined in [3]. Thereby, segmented mobility tunnels can be established between surrogate agents by surrogate registrations. There are two scenarios: one where the home network and the private network/ISP is the same, and one where the home network and the private network/ISP are separated. The first scenario maps on the first scenario described in Section 2.1. The latter scenario is illustrated in Fig. 3. Visited network Home network Private network/ISP +-------+ +-------+ | FAAA |------------| HAAA | +-------+ +-------+ | | +---+ +-----+ +-----+ +-----+ |MN |--| FA | | HA |---------| GW | +---+ +-----+ +-----+ +-----+ Fig. 3. Access to a private network/ISP for a mobile node in a visited network. As in earlier scenarios, the mobile node sends a Registration Request to the home agent via the foreign agent, the FAAA server and the HAAA server. The mobile node is authenticated, as discussed earlier. Then, the home agent locates the private network/ISP, and an IPSec tunnel is established between the home agent and the gateway (GW). Once the tunnel is established, the home agent generates a Registration Reply, which is relayed back to the mobile node via the HAAA server, the FAAA server and the foreign agent. The mobile node has now got its point of presence behind the gateway in the private network/ISP. Note that this scenario is useful only in situations where hop by-hop security is sufficient. In other cases, MN-to-GW security must be used. Gustafsson, Herlitz, Jonsson, Korling Expires May 1998 [Page 6] INTERNET DRAFT November 1998 2.3 Subsequent registration (handover) When the mobile node changes its point of attachment, there is a need to control the delay and packet loss properties of the registration procedure, especially for delay-sensitive traffic. The handover procedure may be divided into two parts: 1. Securing the traffic delivery path to the mobile node. This part is time-critical. 2. Optimize the traffic delivery path. This part is not time-critical. The solution we advocate is based on the mobile node sending information about its former foreign agent in the Registration Request to the new foreign agent. The new foreign agent contacts the former foreign agent, which authenticates the mobile user. A temporary tunnel for traffic forwarding is established between the former and the new foreign agent. This approach has earlier been introduced in [7][6]. In addition, we see a need for a transfer of context between the former and the new foreign agent. The context transfer includes session keys, traffic tunnel information and QoS parameters. With that, the time-critical part of the handover is completed. When the home agent receives the Registration Request, it generates a Registration Reply, and redirects the traffic tunnel from the former to the new foreign agent. After that, the temporary tunnel may be deleted. 3. Issues for consideration Based on the scenarios presented, we find the following issues to be the most important ones to discuss in the development of the Mobile IP specification. Some issues are straightforward employment of already suggested extensions. Others point out inconsistencies between proposed solutions. Gustafsson, Herlitz, Jonsson, Korling Expires May 1998 [Page 7] INTERNET DRAFT November 1998 3.1 Authentication The authentication of a mobile user or node can be performed at different locations and be based upon different parameters. In our opinion, there are two alternatives for where to perform authentication: in the home agent or in the home AAA server. Similarly, there are two alternatives for the identification parameter on which the authentication is based: the IP address of the mobile node or the NAI of the user. We may also consider two phases of the authentication procedure: initial authentication and subsequent authentications. Initial authentication is performed at initial registration, or when a mobile node receives a (new) home agent. Subsequent authentications are performed at handover or to renew bindings before they are timed out. As specified in [5] and [2] respectively, the home agent performs authentication based on the IP address while the DIAMETER server performs authentication based on the NAI. Basing the authentication on the IP address means that it is the host, not the user currently in control of that host, that is authenticated. Authentication based on the NAI results in authentication of the mobile user. The latter alternative would release the hard ties between a specific user and a specific host, and provide a secure way for dynamic allocation of IP addresses. Therefore, we advocate the initial authentication to be based on the NAI. This implies changes to the Mobile IP protocol as it is specified in [5], for instance inclusion of the NAI in the Registration Request, as proposed in [3]. A possible solution would be to perform initial authentication, based on the NAI, at the home AAA server. Subsequent authentications could then be performed by the home agent, or a foreign agent, based on the IP address of the mobile node. 3.2 Dynamic address assignment In [2], the need for a dynamic allocation of the home address is identified. This is in conflict with the use of the home address as the mobile node identifier in [5], and requires other means for authentication, for example the NAI. In addition, there is a need for dynamic allocation of the home agent address. Gustafsson, Herlitz, Jonsson, Korling Expires May 1998 [Page 8] INTERNET DRAFT November 1998 3.3 Surrogate registrations In access networks that have sufficient lower-level signalling, Mobile IP registrations between the mobile node and the foreign agent is unnecessary. Such situations are supported by surrogate registrations as described in [3]. They also support scenarios where the foreign agent and the home agent are positioned in private address spaces protected by firewalls. 3.4 Home agent in visited network In our scenarios, we introduce the possibility for a mobile node to be assigned a home agent in the visited network. Implementing this as a service generates requirements on existing Mobile IP and DIAMETER protocols. First, there is a need for a mechanism to let a mobile node or a surrogate agent to request the service. Second, there is a need for support of this service in the DIAMETER protocol. 3.5 VPN Identifier Extension In one of our scenarios, we describe the case where a mobile node wants access to a private network/ISP. In the case where this private network/ISP is not the home network, we recognize a need for the VPN Identifier Extension in the Registration Request [3]. The NAI of a mobile user points out the home network of the user and the VPN Identifier Extension points out the final destination of the tunnel. 3.6 Smooth handover The approach described in Section 2.3 aims at minimizing the delay and packet loss at handover. This solution puts requirements on the FA-FA interface, and on the information transferred from the mobile node to the foreign agent and between foreign agents. It also assumes that a foreign agent can perform (subsequent) authentication. 4. Conclusions Deployment of cellular packet data services will introduce global scale IP mobility tunnels in the IP infrastructure. There is an opportunity to evolve the Mobile IP specification to support widespread commercial use, achieving a harmonized standard. Starting from scenarios of importance to cellular mobile networks, we have identified a list of issues for consideration in the development of the Mobile IP standard. For some issues, there is a possibility to include suggested extensions in the standard specification. In other cases conflicts between the current base specification and proposed extensions need to be resolved. Gustafsson, Herlitz, Jonsson, Korling Expires May 1998 [Page 9] INTERNET DRAFT November 1998 There is also a question of the formal structure of the Mobile IP standard. A possibility is to have a framework document together with a base document and a set of extension documents. 5. References [1] Aboba, B., Beadles, M.A., Editors: "The Network Access Identifier", Internet draft, draft-ietf-roamops-nai-10.txt, February 1998. Work in progress. [2] Calhoun, P.R., Perkins, C.E., Editors: "DIAMETER Mobile IP Extensions", Internet draft, draft-calhoun-diameter-mobileip-00.txt, July 1998. Work in progress. [3] Calhoun, P., Perkins, C., Editors: "Tunnel Establishment Protocol", Internet draft, draft-ietf-mobileip-calhoun-tep-01.txt, March 1998. Work in progress. [4] Calhoun, Rubens: "DIAMETER", Internet draft, draft-calhoun- diameter-06.txt, October 1998. Work in progress. [5] Perkins, C., Editor: "IP Mobility Support", RFC 2002, October 1996. [6] Perkins, C., Johnson, D.B., Editors: "Registration Keys for Route Optimization", Internet draft, draft-ietf-mobileip-regkey-00.txt, November 1997. Work in progress. [7] Perkins, C., Johnson, D.B., Editors: "Route optimization in Mobile IP", Internet draft, draft-ietf-mobileip-optim-07.txt, November 1997. Work in progress. Author's address: Eva Gustafsson, Anders Herlitz, Annika Jonsson, Martin Korling Ericsson Radio Systems AB Mobile Network and Systems Research SE-164 80 Stockholm SWEDEN {eva.m.gustafsson | anders.herlitz | martin.korling | annika.jonsson}@ era.ericsson.se Gustafsson, Herlitz, Jonsson, Korling Expires May 1998 [Page 10]