draft-gustafsson-mobileip-imt-2000
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]