Mobile IP: Enabling Mobility for the 3G Wireless Internet

Transcription

1 Mobile IP Paresh Jain and Rakesh Kelkar Technology Review# Mobile IP: Enabling Mobility for the 3G Wireless Internet Paresh Jain Rakesh Kelkar April 2003

2 Mobile IP Paresh Jain and Rakesh Kelkar Copyright 2003 Tata Consultancy Services. All rights reserved No part of this document may be reproduced or distributed in any form by any means without prior written authorization of Tata Consultancy Services.

3 Mobile IP Paresh Jain and Rakesh Kelkar Contents 1 INTRODUCTION LISTOF ABBREVIATIONS WHAT IS MOBILE IP THE MOBILITY PROBLEM MOBILE IPV4 ENTITIES AND BEHAVIOUR ENTITIES Behaviour Agent Discovery Registration Routing and Packet Delivery Co-located Care-of Address Mobile IPv4 Route Optimisation De-Registration Security Considerations Message Authentication Codes Privacy Replay Protection for Registration Requests Firewall Support MOBILE IP FOR IPV MIPv6 Overview Differences between MIP for IPv4 and IPv Security Considerations Mobile Node to Home Agent Mobile Node to Correspondent Node Tunnel Protection IMPLEMENTING MOBILE IP IN WIRELESS NETWORKS CDMA NETWORKS Functional Relationships Mobile Station (MS) Radio Resources Control (RRC) and Packet Control Function (PCF) Packet Data Serving Node (PDSN) UMTS/GPRS NETWORKS Functional Relationships Radio Network Subsystem (RNS) SGSN Gateway GPRS Support Node (GGSN) Mobile IP Integration with UMTS/GPRS MOBILE IP RFCS APPLICABILITY STATEMENT FOR IP MOBILITY SUPPORT ENCAPSULATION AND TUNNELLING IP Encapsulation within IP Minimal Encapsulation within IP Reverse Tunnelling for Mobile IP MOBILE IP EXTENSIONS Mobile IPv4 Challenge/Response Extensions Mobile IP Vendor/Organization-Specific Extensions Mobile IP Network Access Identifier Extension for IPv MOBILE IP MANAGED OBJECT DEFINITIONS MOBILE IP FIREWALL TRAVERSAL MOBILE IP AAA REQUIREMENTS MOBILE-IP CONFIGURATION OPTION FOR PPP IPCP... 19

4 Mobile IP Paresh Jain and Rakesh Kelkar 6 FUTURE DIRECTIONS MOBILE IP NAT/NAPT TRAVERSAL USING UDP TUNNELLING REGISTRATION REVOCATION IN MOBILE IP MOBILE IPV4 REGIONAL REGISTRATION REQUIREMENTS OF A QOS SOLUION FOR MOBILE IP MOBILE IP SERVICE THROUGH MPLS AAA NAI FOR MOBILE IPV4 EXTENSION MOBILE IPV6 DRAFTS Fast Handovers for Mobile IPv Localized Mobility Management Requirements for IPv Non-final Mobility Header for Mobile IPv Mobile IPv6 support in MPLS Network REFERENCES List of Figures FIGURE 1 THE MOBILITY PROBLEM... 5 FIGURE 2 MOBILE IPV4 ARCHITECTURE... 7 FIGURE 3 MOBILE IP AGENT DISCOVERY SIGNALLING... 7 FIGURE 4 MOBILE IP REGISTRATION SIGNALLING... 8 FIGURE 5: MOBILE IP FOR IPV FIGURE 6 CDMA NETWORK FIGURE 7 UMTS NETWORK... 16

5 Mobile IP Paresh Jain and Rakesh Kelkar Page 1 of 25 1 Introduction Today, third generation mobile networks are fast becoming a reality. Operators are developing and deploying UMTS and CDMA2000 services for their customers. These 3G networks are enabling a new generation of applications based on mobile data access. Convergence between current network technologies: the Internet and the mobile telephony is thus taking place, but the Internet s IP routing, was designed to work with conventional static nodes not mobile nodes. Efforts are therefore being made in Wireless and Internet forums to enhance IP routing to support mobility and many proposals have been made in this direction. Mobile IP is a key proposal from the Internet Engineering Task Force (IETF) that specifies protocol enhancements to enable transparent routing of IP data packets to mobile nodes in the Internet. This white paper thus consolidates and summarizes Mobile IP concepts from the base RFC, as well as numerous related RFCs. It includes:! An overview of Mobile IP for IPv4, including the mobility problem, mobility entities, signalling and security! An introduction to Mobile IP for IPv6! Integration of Mobile IP with 3G wireless networks! An overview of Mobile IP RFCs! Future directions based on IETF drafts A basic familiarity with the TCP/IP networking protocols suite, specifically IP routing, is useful to appreciate the technologies and issues discussed in this white paper. 1.1 List of Abbreviations Item 1X-CDMA 3G 3GPP Description Qualcomm s 1X-CDMA protocol standard for wireless access 3rd Generation (Refers to 3rd Generation Wireless Protocols such as UMTS) 3rd Generation Partnership Project 3GPP2 3rd Generation Partnership Project 2 AAA CDMA Authentication, Authorization, Accounting Protocol Code Division Multiple Access, a wireless access protocol developed by Qualcomm

6 Mobile IP Paresh Jain and Rakesh Kelkar Page 2 of 25 Item CDMA2000 CH COA CR-LDP DHCP DHCPv6 DNS EDGE FA GPRS GSM HA HLR Description See 1X-CDMA Correspondent Host Care-of-Address Constraint-based Routing using Label Distribution Protocol Dynamic Host Configuration Protocol Dynamic Host Configuration Protocol for IPv6 Domain Name Service Enhanced Data GSM Environment Foreign Agent General Packet Radio Services, a wireless access protocol based on GSM Global System for Mobile communication Home Agent Home Location Register ICMP Internet Control Message Protocol (defined in RFC 792) IETF Internet Engineering Task Force IMT-2000 International Mobile Telecommunications 2000 IP Internet Protocol (defined in RFC 791) IPsec LDP LER LSP IP Security Protocol Label Distribution Protocol Label Edge Router Label-Switched Paths MIPv4 Mobile IP for IPv4 (Internet Protocol version 4) MIPv6 Mobile IP for IPv6 (Internet Protocol version 6) MN Mobile Node

7 Mobile IP Paresh Jain and Rakesh Kelkar Page 3 of 25 Item MPLS NAT Description Multi-protocol Label Switching Network Address Translation PDSN Packet Data Serving Node (See [5]) PLMN Public Land Mobile Network PPP Point to Point Protocol (See [8]) QoS Quality of Service ROAMOPS Roaming Operations, an IETF Working Group (see RRP RRQ RSVP RSVP-TE Mobile IP Registration Reply Message Mobile IP Registration Request Message Resource ReSerVation Protocol Extensions to RSVP for LSP Tunnels TCP Transmission Control Protocol (defined in RFC 793) UMTS VLR Universal Mobile Telephony System, a 3G wireless access protocol developed by 3GPP Visitor Location Register

8 Mobile IP Paresh Jain and Rakesh Kelkar Page 4 of 25 2 What is Mobile IP 2.1 The Mobility Problem These days more and more people enjoy the advantages of the portability and flexibility of carrying their workstations in the form of laptops, notebooks, and PDA handsets. To meet the needs of this new set of users, existing computing environments based on fixed networks are being extended into the mobile domain. 3G and wireless networks are seen as a major revenue stream by providing an additional level of flexibility and service to the user. For data access services and multimedia communication, it is seen as desirable to adapt traditional applications and services people are accustomed to use in the fixed network, and extend them to make them available to the mobile user in a seamless manner. The most dominant services in mobility are the Internet/Intranet services, which run on top of the IP protocol. Internet host mobility poses a problem at the network layer (IP) when a mobile node moves from one sub-net to another. Routing tables have to be updated to route packets to the destination sub-net instead of the original sub-net. This procedure is highly inefficient and time consuming, in particular, if a mobile host needs to retain its network address (IP address) while changing sub-nets. But if a mobile host changes its network address, all established Transport Layer connections (TCP) are broken.

9 Mobile IP Paresh Jain and Rakesh Kelkar Page 5 of 25 Figure 1 The Mobility Problem For example, imagine a commuter downloading music while travelling by train (See Figure 1). This user is using a laptop attached to a mobile handset. The mobile handset could be connected to the Internet using data services provided by GSM or CDMA networks. When the user registers for data services, i.e. the user initiates a data call, he/she will be assigned a unique IP address. Once connected, the user starts an FTP session to download music from the Internet. This FTP session is based on a Transport Layer connection that is dependent on the connection invariant 1. But as the train moves, the mobile station moves to another cell; the point of attachment for data services and therefore the sub-net, may change (for instance, if the user moves across service providers roaming). If the mobile station is now assigned a new IP address, all the transport layer connections will break down. The FTP session will therefore be aborted. This is the problem that Mobile IP seeks to solve. Specifically, Mobile IP defines a set of entities that enable routing of packets to the Mobile Node (in this case, the mobile 1 The Connection Invariant: <source IP address, port, destination IP address, port > Must be unique and constant for each connection lifetime.

10 Mobile IP Paresh Jain and Rakesh Kelkar Page 6 of 25 handset plus laptop computer) without requiring major changes to Internet routing tables. 3 Mobile IPv4 Entities and Behaviour 3.1 Entities Mobile IPv4 consists of three components: the mobile node, a home agent and a foreign agent. A node that moves from a sub-net to another sub-net is called a Mobile Node (MN) and its IP address is called a Home Address. A Correspondent Node (CN) is the host with which the Mobile Node is trying to communicate, on the Internet. The sub-net, to which the Home Address belongs, is called the Home Network and the routing entity on this Home Network that does the job of forwarding packets to the Mobile Nodes is called the Home Agent. When the mobile node moves to another sub-net, this new sub-net is called the Foreign Network. The routing entity receiving packets on behalf of the mobile node on the Foreign Network is called the Foreign Agent. The foreign agent (or the mobile node itself under certain conditions) operates as a router on the foreign network that the mobile node is visiting. A router is a device (hardware or software), that determines the next network point, to which a network data packet should be forwarded, toward its destination. A router is connected to at least two networks and decides which way to send each information packet, based on its current understanding of the state of the networks to which it is connected. Because of the operation of these Mobile IP entities, no changes are needed in any other part of the Internet, including routers or other systems such as DNS Behaviour There are three stages in the operation of the Mobile IP: Agent Discovery: This refers to the process by which a Mobile Node discovers a Mobility Agent (Home Agent or Foreign Agent) on a Foreign Network. Registration: This refers to the process by which a Mobile Node registers itself on a Foreign Network with the Home Agent for Mobile IP Routing and Packet Delivery Services. Routing and Packet Delivery: This refers to the process by which packets are routed from a Mobile Node to a Correspondent Host and back.

11 Mobile IP Paresh Jain and Rakesh Kelkar Page 7 of 25 Figure 2 Mobile IPv4 Architecture Agent Discovery When a mobile node attaches to a network, it first determines whether it is on its home network or on a foreign network. It does so by listening for a local broadcast message from a home agent or foreign agent. This message is called an Agent Advertisement. Alternatively, it can solicit an agent advertisement by broadcasting an Agent Solicitation message. These messages are based on extensions to ICMP Router Discovery Messages [6]. Figure 3 Mobile IP Agent Discovery Signalling Registration When a Mobile Node is visiting a Foreign Network detected by the Mobile Node through the Agent Discovery procedure, the Mobile Node must Register with the Foreign Agent. Registration informs the Foreign Agent of the presence of a Mobile Node requiring routing services on its sub-net. Registration also informs the Home Agent of the current location (sub-net) and care-of address of the Mobile Node. The care-of address refers to an address local to the Foreign Network that the Mobile Node is currently visiting. This address is accessible through normal IP routing. It could be the address of the Foreign Agent or an address dynamically assigned to the Mobile Node.

12 Mobile IP Paresh Jain and Rakesh Kelkar Page 8 of 25 To register, the Mobile Node sends a Registration Request message (RRQ) to the Foreign Agent. The RRQ is a UDP message sent to port 434. The Foreign Agent processes the message and forwards it to the Home Agent (as specified in the RRQ or dynamically assigned). On receiving a valid RRQ, the Home Agent creates a mobility binding (or updates an existing binding) that pairs the Mobile Node Home Address with the current Care-of Address. The Home Agent sends a Registration Reply (RRP) with a code indicating registration success to the Foreign Agent. The Foreign Agent relays the RRP to the Mobile Node. Figure 4 Mobile IP Registration Signalling Routing and Packet Delivery On successful registration, the Home Agent then sets up an IP tunnel between itself and the Care-of Address indicated in the RRP. This is usually the address of the Foreign Agent. This tunnel is used to encapsulate and forward IP packets, destined for the Mobile Node, to the Foreign Network over the Internet. The Foreign Agent decapsulates the packets and routes them to the Mobile Node using a static route. In order to intercept packets destined for the Mobile Node, the Home Agent implements Proxy ARP (Address Resolution Protocol) procedures. Packets from the mobile node to the target host (Correspondent Node) can be routed directly bypassing the home agent as the destination IP address that of the Correspondent Node is reachable using normal IP routing. This results in a triangular routing of traffic between the Mobile Node, Correspondent Node and Home Agent. Outgoing packets from the Mobile Node to the Correspondent Node are routed directly, while incoming packets from the Correspondent Node to the Mobile Node are routed via the Home Agent. This is not necessarily efficient, but is effective. In addition, when a mobile node changes its location, it can register with a new foreign agent, though traffic directed by the home agent to the "old" foreign agent will be lost until the new mobile node has registered its location. In some cases such as routers with ingress filtering, packets whose source address does not match the source sub-net (such as a Mobile Node visiting a Foreign Network) are blocked. In this case, the Mobile Node is forced to request reverse tunnelling. Reverse tunnelling refers to the tunnelling by the Foreign Agent to the Home Agent of all outgoing packets of the Mobile Node. Outgoing packets are therefore tunnelled to the Home Network and then routed to the Correspondent Node.

13 Mobile IP Paresh Jain and Rakesh Kelkar Page 9 of Co-located Care-of Address A mobile node can obtain a care-of address in two ways:! From a foreign Agent via the Agent Discovery and Registration Features described above.! As a co-located address, such as one obtained via DHCP. A mobile node may obtain a co-located address when it is unable to find a Foreign Agent on the foreign network. The co-located address is obtained using standard mechanisms like DHCP. Once a co-located address has been obtained, the mobile node follows the Mobile IP registration procedure to register the address with the Home Agent. On successful registration, it creates the required routing and tunnelling entries. A mobile node with a co-located care-of address thus acts as a foreign agent for the purpose of registration with the home network, in addition to mobile node functionality Mobile IPv4 Route Optimisation Triangle routing under Mobile IP often causes datagrams2 to the Mobile Node to be routed along paths that are significantly longer than optimal (via the Home Agent). This indirect routing delays the delivery of the datagrams to mobile nodes, and places an unnecessary burden on the networks and routers along their paths through the Internet. Mobile IPv4 Route Optimisation (See [15]) defines extensions to the operation of the base Mobile IP protocol to allow the correspondent node to maintain a binding cache to one or more Mobile Nodes. Route Optimisation also allows for a means for the mobile node's previous foreign agent to be reliably notified of the mobile node's new mobility binding, allowing datagrams in flight to the mobile node's previous foreign agent to be forwarded to its new care-of address. This notification also allows any resources consumed by the mobile node at the previous foreign agent (such as radio channel reservations) to be released immediately De-Registration If the mobile node is on its home sub-net, as specified by its Home Address, no special routing support is required. The mobile node therefore informs the home agent of its presence on the home sub-net through de-registration. From then on, routing and datagram 3 delivery work as they would without Mobile IP Security Considerations The mobile or wireless computing or communication environment is insecure in comparison with a wire-line environment. Mostly mobile computers will be connected to the network via wireless links. Such links are actively and passively vulnerable to eavesdropping, replay attacks, and other attacks. The following sections list the security provisions in Mobile IP. 2 According to RFC 1594, a datagram is, "a self-contained, independent entity of data carrying sufficient information to be routed from the source to the destination computer without reliance on earlier exchanges between this source and destination computer and the transporting network."

14 Mobile IP Paresh Jain and Rakesh Kelkar Page 10 of Message Authentication Codes According to [14], home agents and mobile nodes should support authentication. The default algorithm for authentication is MD5 (See [7]), with a key size of 128 bits. The default mode of operation is to both precede and follow the data to be hashed, by the 128-bit key; that is, MD5 is to be used in prefix-plus-suffix mode. The foreign agent also supports authentication using keyed MD5 and key sizes of 128 bits or greater, with manual key distribution Privacy Those users who do not want others to peep into the data can use encryption mechanisms. If absolute location privacy is required, the mobile node can create a tunnel to its home agent. All datagrams destined for correspondent nodes will appear to emanate from the home network, and it will make it difficult for hackers to pinpoint the location of the mobile node. Implementing IPsec for Mobile IP is to protect the redirected packets sent from or to a mobile node against active/passive attack. In addition, this mechanism also helps packets sent by mobile nodes to traverse the firewall of the visiting or home network. The standardization of this work is still in progress in IETF and the current draft (see [12]) supports IP-in-IP encapsulation, only between the mobile node and its home agent Replay Protection for Registration Requests To protect mobile IP entities from Replay attackers, two methods have been described in the Mobile IP RFC. Replay attackers are those who record and re-play datagrams in order to get entry into the system.! Timestamps: A Node generating a message inserts the current time of day, and the node receiving the message checks that this timestamp is sufficiently close to its own time of day.! Nonces: Node A includes a new random number in every message to Node B, and checks that Node B returns that same number in its next message to Node A. Both messages use an authentication code to protect against alteration by an attacker. The timestamps option is mandatory while that for nonces is optional. Whatever method is used, the low-order 32 bits of the Identification are copied unchanged from the Registration Request to the Reply. The foreign agent uses those bits to match Registration Requests with corresponding replies. The mobile node verifies that the loworder 32 bits of any Registration Reply are identical to the bits it sent in the Registration request Firewall Support Firewalls exist between private networks and a public network. They are used to filter incoming and outgoing packets. For the delivery of packets attempting to travel into a private network, the destination address of these packets targets the firewall of the private network. Once the packets arrive at the firewall, they are forwarded if the firewall has a security association with the source.

15 Mobile IP Paresh Jain and Rakesh Kelkar Page 11 of 25 IETF RFC 2356 describes what support is required at the firewall, the Mobile IP Home Agent and the Mobile IP Mobile Node, to enable the Mobile Node to access a private network from the Internet. The most preferred mechanism as per the RFC is the Simple Key-Management for Internet Protocols (SKIP) mechanism. Using SKIP for this purpose has two main advantages:! Each SKIP packet contains an authentication header. As a result, decisions relating to packets arriving at a firewall can be taken immediately without requiring any costly roundtrips for negotiation with the mobile node.! SKIP meets the demand of mobility in that the security association can be built based on a key in the SKIP header rather than on source and destination addresses. 3.2 Mobile IP for IPv6 Figure 5: Mobile IP for IPv MIPv6 Overview The main difference between the solutions proposed for IPv4 and for IPv6 is that in IPv4, traffic forwarding to the mobile node is almost always managed through a foreign agent, whereas in IPv6, the foreign agent no longer exists and it is assumed that the

16 Mobile IP Paresh Jain and Rakesh Kelkar Page 12 of 25 mobile node is always able to acquire a co-located care-of address belonging to the visited sub-net4. The foreign agent of MIPv4 was basically conceived to reduce the demand for IP addresses by sharing the same care-of address amongst several mobile nodes. A foreign agent made it possible to avoid aggravating the problem of limited IPv4 addressing space. This is no longer an issue with IPv6, which has a virtually unlimited addressing space and efficient auto-configuration mechanisms. The mobile node can use these mechanisms (such as DHCPv6) to acquire a valid address in the visited sub-net. Movement detection that took the form of Agent Advertisements in MIPv4 is replaced by IPv6 mechanisms like neighbour discovery (see [4]) Differences between MIP for IPv4 and IPv6! Mobile IPv4 allows the use of Foreign Agents (FAs) to forward traffic, thus requiring one care-of address for multiple mobile nodes. It also supports the use of co-located care-of addresses (COA). In contrast, MIPv6 supports co-located COAs only.! Route optimisation is an add-on to MIPv4, whereas it is an integral part of the MIPv6 specification. This is because all IPv6 nodes have to support the IPv6 Destination option Home Address. This option allows an MN to set the IP source address to its Care-of Address, while requiring the Correspondent Node to substitute it with the Home Address for higher layer processing.! MIPv4 route optimisation requires traffic to be tunnelled between the correspondent host (CH) and the mobile node. In MIPv6, packets can be forwarded without tunnelling, as the source address is always the care-of address.! In MIPv4, the Home Agent (HA) must be involved in the set-up of optimised routes. In MIPv6, the mobile node can initiate an optimised route to a CH directly (without involving the HA), and therefore more quickly and efficiently.! In MIPv4, a COA is obtained from an FA or via DHCPv4. In MIPv6, a COA can be obtained via IPv6 stateless or stateful address auto-configuration mechanisms.! In MIPv4, separate Mobile IP-specific messages are required to communicate with the FA, and HA, and if employing route optimisation, with CHs. In MIPv6, Mobile IPspecific information can be piggybacked onto data packets.! In MIPv4, reverse tunnelling is required to avoid ingress filtering problems (where firewalls drop the mobile's outgoing packets as they appear to originate from an unknown sub-net), since packets are sent with the home address as the source. In MIPv6, packets may be sent with the COA as the source address, hence ingress filtering problems are avoided (see ).! MIPv4 provides its own security mechanisms, whereas MIPv6 employs the IPsec protocol suite. 4 Stateless Address Auto-configuration: New IP Address =Routing Prefix + MAC Address

17 Mobile IP Paresh Jain and Rakesh Kelkar Page 13 of Security Considerations Potential security threats in Mobile IPv6 include denial of service, potential for man-inthe-middle, hijacking, and impersonation attacks. The MIPv6 specification provides a number of security features. The main features are:! Protection of Binding Updates to home agents! Protection of Binding Updates to correspondent nodes! Protection against reflection attacks through the Home Address destination option! Protection of tunnels between the mobile node and the home agent! Preventing Routing Header vulnerabilities! Preventing Denial-of-Service attacks to the Mobile IPv6 security mechanisms themselves Mobile Node to Home Agent Mobile nodes and home agents are expected to be subject to the network administration of the home domain. Therefore, they have a strong security association to reliably authenticate exchanged messages. With such a security arrangement, IPsec Encapsulating Security Payload (ESP) can be used to implement the security features Mobile Node to Correspondent Node An "infrastructureless" approach is necessary to authenticate mobile nodes and correspondent nodes. This is because Mobile IPv6 use is expected to be global between nodes belonging to different administrative domains. Requiring that a Binding Update is cryptographically bound to exchanged cookies limits the vulnerabilities to attackers who are on the path between the home agent and the correspondent node Tunnel Protection Ensuring proper use of source addresses and optional cryptographic protection can protect tunnels between the mobile node and the home agent. For tunnelled traffic to and from the mobile node, encapsulating the traffic inside IPsec ESP offers an optional mechanism to protect the confidentiality and integrity of the traffic against on-path attackers.

18 Mobile IP Paresh Jain and Rakesh Kelkar Page 14 of 25 4 Implementing Mobile IP in Wireless Networks 4.1 CDMA Networks The Wireless IP Network Standard (See [5]) defines requirements for support of wireless packet data networking capability on a 3G wireless system based on CDMA2000. As a general philosophy behind the design, IETF protocols have been employed whenever possible to minimize the number of new protocols required. The system design objectives of Wireless IP include:! Supporting a wide range of addressing configurations (dynamic and static home address configurations, multiple simultaneous IP addresses and dynamic assignment of the Home Agent)! Providing seamless roaming (Allow IP mobility for visitors whose home network may be an IMT-2000 network, ISP, or private network)! Providing robust authentication and authorization services (AAA support services)! Providing QoS support for differentiated services! Providing accounting services Functional Relationships Figure 6 CDMA Network Mobile Station (MS) The Mobile Station is the Mobile IP Mobile Node ; it connects via a data link protocol (PPP) to the PDSN. The MS can hand off between PDSNs that do not involve the home IP network using Mobile IP and accept an HA dynamically assigned by the AAA in the

19 Mobile IP Paresh Jain and Rakesh Kelkar Page 15 of 25 service provider network or home IP network. An MS may use a static home address, or a dynamically assigned home address. In addition to this, the MS can buffer packets from the mobile applications when radio resources are not in place, or are insufficient to support the flow to the network Radio Resources Control (RRC) and Packet Control Function (PCF) The RRC (See [5]) is the entity to which the MS connects on the air-interface. The RRC is responsible for establishing, maintaining, and terminating radio resources for the exchange of packets between the mobile station and the Packet Control Function (PCF, see [5]). The RRC and the PCF are located at the Radio Network as seen in Figure 6 CDMA Network. The PCF entity relays packets to and from the PDSN. It connects at layer 2 to the PDSN and communicates with the RRC to request and manage radio resources in order to relay packets to and from the mobile station. The PCF also collects and sends air-link related accounting information to the PDSN. The PCF can buffer packets arriving from the PDSN, when radio resources are not in place or are insufficient to support the flow from the PDSN Packet Data Serving Node (PDSN) The PDSN is the entity that supports Foreign Agent functionality. It establishes, maintains, and terminates a PPP session to the mobile station. The PDSN maps the mobile station IP and HA addresses with a unique link layer identifier used to communicate with the PCF. The PDSN sends Agent Advertisement(s) (see [14]) if the PCF indicates that the mobile station has undergone a handoff. The PDSN may also optionally interact with a previous PDSN to support handoffs between PDSNs that do not involve the home IP network. The PDSN can route packets to IP networks or directly to the HA in the case of reverse tunnelling. It also monitors the source addresses of packets received from mobile stations. When packets are received, which have source addresses not assigned or registered to the mobile station, the PDSN discards the packets and restarts PPP to the mobile station. 4.2 UMTS/GPRS Networks According to [1], the requirements for the UMTS packet domain are to:! Efficiently support IP transport and access to the Internet! Enable support of Virtual Private Networks! Enable support of Remote Network Access

20 Mobile IP Paresh Jain and Rakesh Kelkar Page 16 of 25! Enable roaming procedures based on IETF ROAMOPS working group and AAA working group outcomes. This implies the support of NAI (Network Access Identifier)-based Roaming procedures and IETF standard AAA procedures. This would allow sharing of standard Internet AAA infrastructure.! Provide end-to-end QoS or service differentiation according to IETF standards for IP packet transport! Support of Mobile IP with Challenge/Response based authentication (See [13]) and NAI extension, in order to inter-operate with operators, corporations and ISPs offering Mobile IP on the core network side Functional Relationships Figure 7 UMTS Network Radio Network Subsystem (RNS) The GPRS/ UMTS network consists of two parts: the core network and the radio access network. The radio access network connects the users to the core network. It contains the base stations (Node B), the radio network controller (RNC) and the network elements MSC and SGSN, which connect the UTRAN to the core network. The Node Bs in one RNC region are called radio network subsystem (RNS); these RNSs are connected to this RNC, which is connected with the respective U-MSCs (MSC/SGSN) SGSN The serving GPRS support node (SGSN) forwards packets to and from mobile devices within its service area. The SGSN is responsible for Mobility Management and Authentication Gateway GPRS Support Node (GGSN) The GGSN is responsible for address allocation to the MS and acts as a gateway to external networks. The GGSN acts as an interface between the GPRS backbone network and inbound external packet data networks such as the Internet and corporate networks.

21 Mobile IP Paresh Jain and Rakesh Kelkar Page 17 of 25 The GGSN converts the GPRS packets coming from the SGSN into the appropriate packet data protocol (PDP) format. If the PDP type is PPP, the GGSN acts as the PPP end point, if the type is IP, then it acts as an IP end-point. The GGSN then sends the packets out on the corresponding packet data network Mobile IP Integration with UMTS/GPRS Mobile IP will be supported in UMTS/GPRS in the following manner.! Stage One: Foreign Agent functionality will be added to only one GGSN in the PLMN. This implies that there will be no change in the network architecture and no change will be required in the Mobile Station either. This stage allows for mobility across PLMNs.! Stage Two: Enhance the GGSN with Foreign Agent (FA) functionality into a GGSN/FA. This will allow a GGSN to be changed if a more suitable GGSN is available. This stage will ensure a more efficient use of PLMN backbone resources by creating mobility at the GGSN/SGSN pair level.! Stage Three: Merge the SGSN and GGSN/FA into an IGSN (Internet GPRS Support Node). This stage will provide true Mobile IP macro mobility management. 5 Mobile IP RFCs This section provides an overview of the IETF RFCs for Mobile IP, apart from the base RFC 3220 (updates RFC 2002). 5.1 Applicability Statement for IP Mobility Support RFC 2005 discusses the applicability of Mobile IP to provide host mobility in the Internet. In particular, this RFC describes the key features of Mobile IP and shows how the requirements for advancement to the Proposed Standard RFC have been satisfied. 5.2 Encapsulation and Tunnelling IP Encapsulation within IP RFC 2003 specifies a method by which an IP datagram may be encapsulated (carried as payload) within another IP datagram. Encapsulation is suggested as a means to alter the normal IP routing for datagrams. This causes the datagrams to be delivered to an intermediate destination that would otherwise not be selected by the IP Destination Address field in the original IP header. Encapsulation may serve a variety of purposes, such as delivery of a datagram to a mobile node, using Mobile IP Minimal Encapsulation within IP RFC 2004 specifies a method by which an IP datagram may be encapsulated (carried as payload) within an IP datagram, with lower overhead than "conventional" IP encapsulation that adds a second IP header to each encapsulated datagram. Encapsulation is suggested as a means to alter the normal IP routing for datagrams, by delivering them to an intermediate destination that would otherwise not be selected by the (network part of the) IP Destination Address field in the original IP header.

22 Mobile IP Paresh Jain and Rakesh Kelkar Page 18 of 25 Encapsulation may be serving a variety of purposes, such as delivery of a datagram to a mobile node using Mobile IP Reverse Tunnelling for Mobile IP Mobile Internet Protocol (IP) uses tunnelling from the home agent to the mobile node's care-of address, but rarely in the reverse direction. Usually, a mobile node sends its packets through a router on the foreign network, and assumes that routing is independent of source address. When this assumption is not true, it is convenient to establish a topologically correct reverse tunnel from the care-of address to the home agent. RFC 3024 proposes backward-compatible extensions to the Mobile IP to support topologically correct reverse tunnels. It does not attempt to solve the problems posed by firewalls located between the home agent and the mobile node's care-of address. 5.3 Mobile IP Extensions Mobile IPv4 Challenge/Response Extensions Mobile IP, as originally specified, defines an authentication extension (the Mobile- Foreign Authentication extension), by which a mobile node can authenticate itself to a foreign agent. Unfortunately, this extension does not provide ironclad replay protection for the foreign agent and does not allow for the use of existing techniques (such as CHAP) for authenticating portable computer devices. RFC 3012 defines extensions for the Mobile IP Agent Advertisements and the Registration Requests that allow a foreign agent to use a challenge/response mechanism to authenticate the mobile node Mobile IP Vendor/Organization-Specific Extensions RFC 3115 defines two new extensions to Mobile IP. These extensions will facilitate equipment vendors and organizations to make specific use of these extensions as they see fit for research or deployment purposes Mobile IP Network Access Identifier Extension for IPv4 AAA servers are in use within the Internet today to provide authentication and authorization services for dial-up computers. Such services are likely to be equally valuable for mobile nodes using Mobile IP when the nodes are attempting to connect to foreign domains with AAA servers. AAA servers today identify clients by using the Network Access Identifier (NAI). RFC 2794 defines a way for the mobile node to identify itself, by including the NAI along with the Mobile IP Registration Request. The RFC (2794) also updates RFC 2290, which specifies the Mobile-IPv4 Configuration option for IPCP, by allowing the Mobile Node's Home Address field of this option to be zero.

23 Mobile IP Paresh Jain and Rakesh Kelkar Page 19 of Mobile IP Managed Object Definitions RFC 2006 defines the Management Information Base (MIB) for use with network management protocols in TCP/IP-based Internets using SMIv2. In particular, it describes managed objects used for managing the Mobile Node, Foreign Agent and Home Agent of the Mobile IP Protocol. 5.5 Mobile IP Firewall Traversal The Mobile IP specification establishes the mechanisms that enable a mobile host to maintain and use the same IP address as it changes its point of attachment to the network. Mobility implies higher security risks than static operation, because the traffic may at times take unforeseen network paths with unknown or unpredictable security characteristics. The Mobile IP specification makes no provisions for securing data traffic. The mechanisms described in RFC 2356 allow a mobile node out on a public sector of the Internet to negotiate access past a SKIP firewall, and construct a secure channel into its home network. In addition to securing traffic, this RFC defines mechanisms to allow a mobile node to roam into regions that:! Impose ingress filtering, and! Use a different address space. 5.6 Mobile IP AAA Requirements RFC 2977 defines the requirements for Authentication, Authorization, and Accounting. This RFC contains the requirements, which are to be supported by an AAA service to aid in providing Mobile IP services. 5.7 Mobile-IP Configuration Option for PPP IPCP The Mobile IP defines media-independent procedures by which a Mobile Node can maintain existing transport and application-layer connections, despite changing its pointof-attachment to the Internet and without changing its IP address. PPP [RFC 1661] provides a standard method for transporting multi-protocol packets over point-to-point links. As currently specified, Mobile IP Foreign Agents, which support Mobile Node connections via PPP, can do so only by first assigning unique addresses to those Mobile Nodes, defeating one of the primary advantages of Foreign Agents. RFC 2290 corrects this problem by defining the Mobile-IPv4 Configuration Option to the Internet Protocol Control Protocol (IPCP) [RFC 1332]. Using this option, two peers can communicate their support for Mobile IP during the IPCP phase of PPP. Familiarity with Mobile IP [RFC 2002], IPCP [RFC 1332], and PPP [RFC 1661] is assumed. This RFC (2990) has been updated by RFC 2794, which presents the preferred method for Wireless IP (see [5]).

24 Mobile IP Paresh Jain and Rakesh Kelkar Page 20 of 25 6 Future Directions This section lists the directions that Mobile IP is taking by summarising the Internet drafts currently valid with IETF in the Mobile IP area. 6.1 Mobile IP NAT/NAPT Traversal using UDP Tunnelling Mobile IP's datagram tunnelling is incompatible with Network Address Translation (NAT). The draft by H. Levkowetz (ipunplugged), S. Vaarala (Netseal) released in April, 2002, presents extensions to the Mobile IP protocol and a tunnelling method which permits mobile nodes using Mobile IP to operate in private address networks, which are separated from the public internet by NAT devices. The NAT traversal is based on using the Mobile IP Home Agent UDP port for encapsulated data traffic. Mobile IP relies on sending traffic from the home network to the mobile node or foreign agent through IP-in-IP tunnelling. IP nodes, which communicate from behind a NAT, are reachable only through the NAT's public address(es). IP-in-IP tunnelling does not generally contain enough information to permit unique translation from the common public address(es) to the particular care-of address of a mobile node or foreign agent, which resides behind the NAT. For this reason, IP-in- IP tunnels cannot, in general, pass through a NAT, and Mobile IP will not work across a NAT. Mobile IP's Registration Request and Reply will, on the other hand, be able to pass through NATs and NAPTs on the mobile node or foreign agent side, as they are UDP datagrams originated from the inside of the NAT or NAPT. When passing out, they make the NAT set up an address/port mapping, through which the Registration Request will be able to pass in to the correct recipient. In MIP UDP tunnelling, the mobile node may use an extension (described in the draft) in its Registration Request to indicate that it is able to use Mobile IP UDP tunnelling, instead of standard Mobile IP tunnelling, if the home agent sees that the Registration Request seems to have passed through a NAT. After assent from the home agent, MIP UDP tunnelling will be available for use for both forward and reverse tunnelling. UDP tunnelled packets sent by the mobile node use the same ports as the registration request message.

25 Mobile IP Paresh Jain and Rakesh Kelkar Page 21 of Registration Revocation in Mobile IP During the original design of Mobile IP, the need for an administrative domain to be able to actively revoke a current Mobile IP registration was recognized. Due to the lack of a specific scenario requiring such a mechanism, it was decided that instead of an active revocation mechanism explicitly for the purpose of registration revocation, a passive mechanism, namely short registration lifetimes, and the denial of a subsequent registration from a mobile node, would likely be sufficient for this purpose. Investigations into requirements for an AAA protocol within the AAA working group have forced reconsideration of a more pro-active Mobile IP registration revocation feature, whereby both domains providing Mobile IP services are aware that the service is being suspended. In the ideal model, revocations must be possible from either home or foreign domains, and any registration revocation mechanism being defined must also provide a signalling mechanism between the two that the current registration has been released. Mobile IP services are no longer being provided on one side of the registration, so they need not be provided on the other. In some cases, the current registration may be terminated to simply force the mobile node to renegotiate its registration, but in other cases, where no renegotiation will be considered by the terminating side, this should be communicated. Moreover, there should also be a mechanism in place, whereby the mobile node whose registration has been terminated, can also be informed that such a revocation has occurred. This is done if only to make it clear that the mobile node is no longer being provided Mobile IP services, though the reasons for such a revocation need not necessarily be relayed. The draft by S. Glass (Sun Microsystems), and M. Chandra (Cisco Systems) released in March 2002, defines such a general use registration revocation mechanism meeting these requirements. 6.3 Mobile IPv4 Regional Registration If the distance between the visited network and the home network of the mobile node is large, the signalling delay for these registrations may be long. The draft by Eva Gustafsson (Ericsson), Annika Jonsson (Ericsson), and Charles E. Perkins (Nokia Research Center) released in March 2002, proposes a new kind of "regional" registration, i.e., registration local to the visited domain. Regional registrations reduce the number of signalling messages to the home network, and reduce the signalling delay when a mobile node moves from one foreign agent to another, within the same visited domain. When a mobile node first arrives at a visited domain, it performs a home registration that is, a registration with its home agent. At this registration, we assume that the home network generates a registration key for the mobile node. This registration key is distributed to the mobile node and to the visited domain, and can be used for authentication of regional registrations.

26 Mobile IP Paresh Jain and Rakesh Kelkar Page 22 of 25 During a home registration, the home agent registers the care-of address of the mobile node. When the visited domain supports regional tunnel management, the care-of address that is registered by the home agent is the publicly routable address of a Gateway Foreign Agent (GFA). This care-of address will not change when the mobile node changes the foreign agent under the same GFA. When changing the GFA, a mobile node MUST perform a home registration; when changing the foreign agent under the same GFA, the mobile node MAY instead perform a regional registration within the visited domain. 6.4 Requirements of a QoS Soluion for Mobile IP Mobile IP needs to provide proper Quality of Service (QoS) forwarding treatment to a mobile node's packet stream at the intermediate nodes in the network. This will ensure support for QoS-sensitive IP services over Mobile IP. The draft released by Hemant Chaskar (Nokia Research Center) in February 2002, describes requirements for an IP QoS mechanism for its satisfactory operation with Mobile IP. There are four important steps involved in solving the QoS problem for Mobile IP. They are as follows: (1) List the requirements that Mobile IP places on the QoS mechanism. (2) Evaluate current IP QoS solutions against these requirements. (3) Decide if current solutions need to be extended, or if new ones need to be defined. (4) Depending on the result of step 3, define new solutions or fix the old ones. The draft addresses only the requirements step i.e., (1). 6.5 Mobile IP service through MPLS Multi-Protocol Label Switching is a technology that combines the simplicity of IP routing with the high-speed switching of ATM. The draft by Jun Kyun Choi (ICU), Tai Won Um (ICU), Yoo Kyoung Lee (ETRI), and Sun Hee Yang (ETRI) released in November 2001, discusses how to build the large-scale Mobile IP network through the MPLS network. One small-scale Mobile IP network could be connected to other networks through the MPLS backbone network. It proposes the MPLS network architecture to provide the large-scale Mobile IP network. Specifically, it proposes that the label distribution protocols CR-LDP and RSVP-TE can be applied to set up the label switched path (LSP) tunnels between the mobile agents (that is, Foreign Agents and Home Agents). This means that one or more Label Switched Paths (LSPs) on an MPLS network could replace the IP-in-IP tunnels. 6.6 AAA NAI for Mobile IPv4 Extension When a mobile node moves between two foreign networks, it has to be reauthenticated. If the home network has multiple AAA servers, the re-authentication request may not be received by the same AAA server as previous authentication requests.

27 Mobile IP Paresh Jain and Rakesh Kelkar Page 23 of 25 In order for the new AAA server to be able to forward the request to the correct HA, it has to know the identity of the HA. The draft released by F. Johansson (ipunplugged), and T. Johansson (Ericsson) in March 2002, defines an extension that enables the HA to pass its identity to the mobile node, which can in turn pass it to the AAA server when changing the point of attachment. 6.7 Mobile IPv6 Drafts Fast Handovers for Mobile IPv6 Mobile IPv6 describes how a Mobile Node can change its point of attachment from one Access Router to another, a process referred to as handover. During this process, there is a time period during which the Mobile Node is unable to send or receive IPv6 packets. This time period is referred to as handover latency. In certain scenarios, the handover latency resulting from standard Mobile IPv6 handover procedures could be greater than what is acceptable to support real-time or delaysensitive traffic. The intent of the draft by G. Dommety, A. Yegin, C. Perkins, G. Tsirtsis, K. El-Malki, and M. Khalil released in March 2002, is to describe protocol enhancements that can be used to minimize handover latency, thereby making Mobile IPv6 better equipped to support real-time traffic. The following handover mechanisms are described:! Anticipated Handover: Layer 3 initiates handover to the new Access Router while the Mobile Node still has Layer 2 connectivity to the current Access Router. In this scenario, either the Mobile Node or the current Access Router have predictive information in advance of the actual Layer 2 handover about where the Mobile Node will be moving, or the Mobile Node or current Access Router can actually force handover to a particular new Access Router.! Tunnel-based Handover: The Mobile Node defers Layer 3 handover until it is on the new Access Router, or possibly later. The current Access Router tunnels packets to the Mobile Node under its old care-of address until the Mobile Node performs Layer 3 handover. If the Mobile Node moves again without performing Layer 3 handover, the tunnel is moved by the old and new Access Routers to accommodate the Mobile Node's movement Localized Mobility Management Requirements for IPv6 The draft by Carl Williams (DoCoMo USA Labs) released in March 2002, describes requirements for Localized Mobility Management (LMM) for Mobile IPv6. Localized Mobility Management, in general, introduces Local Mobility Agent functionality (LMA). LMA proxies a Regional care-of address that remains the same, while the mobile node moves within a Local Mobility Domain. This reduces the binding update signalling latency and the signalling load outside the Local Mobility Domain. LMM also serves as a mechanism to hide the Mobile Node's location from observers outside the administration domain (Local Mobility Domain) Non-final Mobility Header for Mobile IPv6