Network design with Mobile IP

Abstract

Mobile IP is a standard developed by IETF for the purpose of providing macro mobility across a set of different radio access technologies. The paper goes through a few network design examples for the deployment of mobile IP in home, office, WLAN hotspot and/or 3G environments. In addition, some particular aspects pertinent to mobile IP are described, including co-located care-of address, NAPT traversal, Home Agent redundancy and selected Diameter/Mobile IP procedures.

 

 

Table of Contents

Abstract *

Table of Contents *

The Mobile Internet *

Networking with Mobile IP *

Diameter and Mobile IP interworking *

A Brief Note on Mobile IP Security *

NAT/Firewall traversal of Mobile IP tunnels *

NAPT between Mobile Node and Home Agent *

Firewall Traversal with Mobile IP and AAA *

Redundancy among Home Agents *

Networking solutions with Mobile IP *

Hotspot Areas *

Extranet partners *

Wide Area Solution *

Mobile IP: emerging technologies *

Abbreviations and Concepts *

References *

The Mobile Internet

While Internet technologies largely succeed in overcoming the barriers of time and distance, existing Internet technologies have yet to fully accommodate the increasing mobility of people with their computers. A promising technology used to eliminate this current barrier is Mobile IP.

The emerging 3G mobile networks are set to make a huge difference to the international business community. 3G networks will provide sufficient bandwidth to run most of the business computer applications providing a reasonable user experience. However, 3G networks are not based on only one standard, but a set of radio technology standards such as cdma2000, EDGE and WCDMA. It is easy to foresee that the user from time to time also would like to connect to fixed broadband networks, wireless LANs and, mixtures of new technologies such as Bluetooth connected to e.g. cable TV and DSL access points.

In this light, a common macro mobility management framework is required in order to allow mobile users to roam between different access networks with little or no manual intervention. (Micro mobility issues such as radio specific mobility enhancements are supposed to be handled within the specific radio technology.) IETF has created the Mobile IP standard for this purpose. Mobile IP is different compared to other efforts for doing mobility management in the sense that it is not tied to one specific access technology. In earlier mobile cellular standards, such as GSM, the radio resource and mobility management was integrated vertically into one system. The same is also true for mobile packet data standards such as CDPD, Cellular Digital Packet Data and the internal packet data mobility protocol (GTP/MAP) of GPRS/UMTS networks.

Mobile IP can be seen as the least common mobility denominator - providing seamless macro mobility solutions among the diversity of accesses. Mobile IP is defining a Home Agent as the anchor point with which the mobile client always has a relationship, and a Foreign Agent, which acts as the local tunnel-endpoint at the access network where the mobile client is visiting. Depending on which network the mobile client is currently visiting its point of attachment may change. At each point of attachment, Mobile IP either requires the availability of a standalone Foreign Agent or the usage of a Co-located care-of address in the mobile client itself.

Unfortunately the concept "Mobile IP" today has at least two different meanings. Mobile IP is sometimes used in the general meaning of a mobilized Internet - including all different technologies and methodologies. Sometimes the name refers to the protocol of Mobile IP itself, as defined within the IETF, Internet Engineering Task Force. In this paper, when referred to Mobile IP, we mean the Mobile IP protocol.

Networking with Mobile IP

While being good enough for many deployment scenarios, Mobile IP needs specific enhancements and bundling with other technologies for supporting, among other things, personal mobility in a generic way. Other features needed are the abilities for Mobile IP to support private network interworking with e.g. home networks in private network realms. Corporate networks are most often located beyond the confines of firewalls. An Home Agent beyond a firewall in a corporate network must be able to communicate with Foreign Agents in other networks i.e. the Mobile IP protocol must in certain cases be able to traverse firewalls. Another issue is charging, accounting and load-sharing. Depending of the charging policy for the access network (Visited Network) in question, the provider of the access may want to charge the mobile node. In this section we look into some specific but important additions to Mobile IP that can solve such problems.

Diameter and Mobile IP interworking

Diameter is the successor of the well-known RADIUS protocol. Diameter is currently standardized within the IETF AAA (Authentication, Authorization and Accounting) working group and the specifications are to be finalized during the year of 2001. Today a quite extensive inter industry protocol testing is taking place. The primary driver for the Diameter protocol is the cdma2000 community (3GPP2), however Diameter is not cdma2000 specific. Rather it is a flexible and extensible protocol, built to be interoperable (backwards compatible) with RADIUS. The Diameter protocol will be used for both the fixed PSTN and cellular PPP kinds of dial-up users as well as roaming Mobile IP users.

AAA and especially Diameter provide a Mobile IP based system with functionality such as:

  • Simplified mobile client/user management
  • NAI based user authentication
  • Dynamic IP address allocation for mobiles
  • Dynamic Home Agent allocation
  • Flexible mechanisms for collecting accounting information
  • Flexible mechanisms for creating business relations between owners of foreign networks and home networks.
  • Possibilities to base the IP access reply decision on authorisation information in the Home AAA server – such as e.g. time of day, weekday etc.

It is possible to envisage future evolved AAA usage in many different application areas. However, in this paper we limit ourselves to the use of Diameter within Mobile IP.

The reference model for the mobility architecture must be updated to also reflect the AAA infrastructure. The figure indicates a Foreign Agent, closely related to a foreign AAA server. In the same manner there exists a Home Agent closely related to one or many AAA servers. There may also exist a brokering AAA infrastructure. The AAA brokering infrastructure is to be seen as a trusted third party. It can be used and trusted to implement business agreements and act in a way that minimise the overall number of security associations in the network. For example, the foreign AAA and the home AAA might not have a priori knowledge, or they might not be allowed to directly talk to each other. The brokering AAA infrastructure can be deployed in a way that the foreign AAA server can "find" and set up necessary associations with the home AAA server.

Related to the figure, the important steps when it comes to the registration are as follows:

  • The Foreign Agent asks the AAAF (Foreign AAA) for help during the Mobile IP registration
  • The AAAF looks at the realm part of the Mobile Node NAI and deduce information on how to contact the AAAH (the Home AAA)
  • The AAAH authenticates and authorises the Mobile Node – based on the NAI in the Mobile IP registration message. Accounting starts.
  • The AAAH optionally allocates a Home Agent
  • The AAAH contacts and initialises the Home Agent

A further extended (but still simplified) scenario for Mobile IP interworking with Diameter, considering Mobile IP and Diameter registration signalling, is depicted in the figure below. Signalling procedures and acronyms are described below the figure. The figure is based on Diameter/Mobile IP interworking with a 3G cdma2000 packet data network. The 3GPP community (dealing with the evolution of GSM into 3G) is also looking into a similar architecture. The appropriate location for the Foreign Agent (and AAA proxy) functionality within the 3GPP architecture is the GGSN. The following example is, however, based on the proposed architecture within cdma2000. The cdma2000 (3GPP2) community is currently driving the development and deployment of Mobile IP and Diameter.

The PDSN (Packet Data Service Node) is the packet core entity that among other things implements Mobile IPv4 Foreign Agent and AAA client functionality (the AAA client of the PDSN that is able to communicate with an AAA server.)

The following figure and the subsequent description explain how this scenario works. The number preceding the description can be mapped to the number in the figure (message sequence chart) below.

  1. The mobile station roams into the access network, and registers using access network specific procedures. In a cellular environment this typically includes authentication towards a HLR functionality.
  2. The Mobile Node initiates packet data session. In a cellular environment the radio network sends an indication to the PDSN/FA to set-up a packet data session.
  3. The PDSN/FA sends Agent Advertisements to the Mobile Node. (The Mobile Node may send an agent solicitation message to the PDSN/FA.)
  4. The Mobile Node generates a Mobile IP registration request containing amongst others the NAI.
  5. The Foreign Agent creates the AA-Mobile-Node-Request (AMR) message and forwards this message to the AAAF.
  6. The AAAF uses the NAI in the received AMR to forward the message to the proper AAAH, possibly via brokers (AAAB). The message may be delivered deploying AAA security between foreign (visited) and home networks.
  7. The AAAH receives the AMR. If the AAAH is instructed to allocate a Home Agent and if the Home Agent address is known, the AAAH sends a Home-Agent-MIP-Request (HAR), which contains the Mobile IP Registration Request message to the assigned or requested Home Agent. Additionally the AAAH may allocate a Home IP Address for the Mobile Node. In this case the Home IP address will be included it in the HAR. If the AAAH has not allocated a home IP address for the mobile node, this allocation responsibility is left for the Home Agent. The home Agent processes the included MIP registration request and constructs and included a MIP registration reply in the Home Agent Answer (HAA.) Finally the Home Agent Answer (HAA) is sent to the AAAH.
  8. The AAAH forwards the AA-Mobile-Node-Answer (AMA) the AAAF that may be delivered deploying AAA security between foreign (visited) and home networks.
  9. The AAAF forwards the forwards the AA-Mobile-Node-Answer (AMA) to the PDSN/FA
  10. The PDSN/FA may optionally create an IP security association towards the Home Agent using IKE. This may involve either an IKE pre-shared key delivered by the AAA Authorisation response or via certificate exchange within IKE.
  11. Mobile IP specific operation may begin.

Note that this example is not inclusive. It is, for example, possible to dynamically allocate a Home Agent in the visited network. In such a case the registration signaling is somewhat different. The Home Agent allocation would for example be performed by the AAAF.

A Brief Note on Mobile IP Security

Security in IP networks in general and more specifically in a Mobile IP environment applies to the whole network. In this section we limit ourselves, and concentrate on describing the main security protocols applicable for Mobile IP operation. An "IP network" consists of a multitude of different networks. Most of the concerns and security mechanisms that applies for normal IP networking is also directly applicable on Mobile IP enabled networks. In Mobile IP networking, we have previously identified the following different IP networks:

  • The Foreign (visited) Network
  • The Intermediate Networks
  • The Home Network
  • The Correspondent Node Network

Mobile IP network security, as discussed here, mostly relates to the "carrier" networks. In a full-blown Mobile IP network there will be a number of different carrier networks, each with somewhat different security characteristics. The figure below is intended to identify some of these different carrier networks, where the visited network implements a wireless LAN access.

From a Mobile IP end-user perspective, most of the carrier networks (the Visited Network, the Intermediate networks and the Home Network) are to be seen as a transparent "Layer 2" network. This is independent of if the "layer two" network is realized as a tunneling IP layer or a "real" layer two technology (such as Ethernet.) or a combination thereof.

Communication security may be implemented on different protocol layers. When it comes to the carrier provided security services, these services are provided protocol-wise below the "end-user" IP level. However, security services provided below the end-user IP level can only be deployed in a hop-by-hop fashion. For example, the Visited Network may implement specific wireless LAN security services such providing confidentiality, integrity and authentication over the radio-link. In the intermediate networks another security scheme such as the IPSec protocol may be implemented over the tunneling IP layer, in order to protect the signaling and transport between the Foreign Agent and the Home Agent. Furthermore, the Home and Correspondent Node Network may rely on security based on physical network separation. However, the carrier provided security architecture and mechanisms may vary depending on the actual network layout in a specific networking scenario.

The end-user IP level is of course also an important issue. Advanced security services must be the responsibility of the end-users and should thus be implemented in the protocols used end-to-end (example end-to-end mechanisms includes IPSec, SSH, SSL and PGP.) Such protocols used end-to-end can be deployed independently of the network based hop-by-hop security model. End user specific security mechanisms adds value for advanced users that will be able to deploy Mobile IP services, even though they do not fully trust their service providers. However, the network hop-by-hop security model can provide the majority users with good enough and easy to use security.

Typical security mechanisms used in a Mobile IP environment are:

  • Mobile IP specific security (challenge-response protocols among Mobile IP enabled nodes)
  • AAA (end-user authentication and authorization bundled with Mobile IP)
  • IPSec/IKE (carrier level and end-user level)
  • Transport Level Security (Secure socket layer)
  • Application Level Security (Pretty Good Privacy)

In the context of an end-user mobile VPN, the network layout and, more specifically, the security policy enforced by the end-user and the home network provider has to clarify how much trust can be placed in the Mobile IP infrastructure. Based on the security architecture and the security policy, the involved parties should select any additional security mechanisms to be used.

Networking technologies that are increasingly used today - in order to cope with the limited amount of IP addresses - are NATs (Network Address Translators) and web proxies. If an end-user network address translation is implemented, then the end-to-end transparency on the end-user IP level will be broken. Furthermore a web proxy would break the transparency on the transport layer. Such building blocks have impacts on the end-to-end security mechanisms that can be used, and must therefore be taken into consideration. An ordinary NAT would make it impossible to deploy end-to-end IPSec while a web proxy would make it impossible to use TLS (Transport Level Security) in an end-to-end fashion.

NAT/Firewall traversal of Mobile IP tunnels

Mobile Nodes roaming throughout the general Internet constantly connected with a Home Network that is not protected by a firewall is a solution typically found in academic environments only. In Corporate networks the Home Network will often be hidden behind a firewall. The firewall imposes restrictions on packets entering or leaving the private corporate network. Packets are not allowed through the firewall unless they conform to filtering rules. Another restriction is imposed by the separation between private addresses and public Internet addresses. Private addresses are simply not routable on the Global Internet.

If the internal network topology is completely hidden by the firewall, the firewall must be explicitly targeted as the destination by packets from the outside intended for the private corporate network. The Global Internet will only be aware of the public address of the firewall and route accordingly. Once the packet arrives at the firewall, the real packet destined to a private address may be recovered. A host behind a network address translator may have an address that is not available to its correspondent node. In this case the firewall must be involved in key exchange protocol since the firewall is the logical end point for the Security Association (encryption), not the actual (intended) destination. When topology is hidden by a firewall, there must be mechanisms to map the traffic at the firewall to the intended destination.

Network Address Translators (NATs) and firewalls are common and important building blocks in IP network design of today. In this section some different scenarios of NAT and firewall traversal techniques are described. Several scenarios may be considered, but here we concentrate on a couple of specific scenario, namely: that there is a NAPT (Network Address and Port Translator) between the Mobile Node equipped with a Co-located care-of address and the Home Agent. In a latter section we also look into the problem of having a packet filtering firewall between a standalone (network based) Foreign Agent and the Home Network.

NAPT between Mobile Node and Home Agent

The figure below shows a scenario where the Mobile Node is equipped with a co-located care-of address and is hidden behind a Network Address and Port Translator (NAPT) in the visited network. The Home Agent is however equipped with a public (unique) IP address towards the Internet. Note that this scenario requires the Mobile to be equipped with a Co-located care-of address – but the scenario does require neither Mobile IP support nor AAA services in the visited network.

This scenario is expected to be very common in light of e.g. broadband access deployment to residential homes. Many broadband access providers only provide a private IP address to each house/apartment (indicated as the visited network in the figure). Mobile users are then connected to the Home Agent via Mobile IP at the office (Corporate Network in the figure) or the Internet service provider.

The Mobile Node will request a temporary care-of address from a local DHCP server in the visited network. In the figure, the care-of address is set to 10.0.0.2 – an address that is allocated from within the address realm in the visited network. In addition, the Mobile Node has a stable address set to "10.0.0.1" – an address that is allocated from within the address realm of the home network (within the Corporate Network.) The registration request will survive the traversal of the NAPT by changing the source IP address to the address of the public address of the NAPT. According to the figure this address is the public IP address "204.68.9.2". Additionally the registration request will be associated with a new UDP source port in the NAPT. The Home Agent will discover that a NAPT traversal has occurred by comparing the source IP address "204.68.9.2" and the care-of address "10.0.0.2". The Mobile IP tunnel is then modified to contain a UDP header as well, in order to facilitate traversal of the NAPT with payload datagrams between the Mobile node and the Correspondent Node. Note also, that the source IP header of the registration request as received by the Home Agent, i.e. "204.68.9.2", will be used as source IP address for the outer IP header in the Mobile IP tunnel seen from the Home Agent. As opposed to of the care-of address "10.0.0.2", that is normally applied.

In the registration process the Mobile Node sends a Mobile IP registration request towards the Home Agent. The registration request includes the care-of address as one field inside the registration message. The registration request is sent with the UDP destination port equal 434 and the UDP source port set to any chosen port number. The source IP address of the registration request is set to the care-of address and the destination IP address is set to the Home Agent public IP address "204.8.8.2".

When the registration request is traversing the NAPT, the source IP address will be modified to the public IP address of the NAPT, namely "204.68.9.2" according to the figure. In order to distinguish between datagrams sent from different nodes in the visited network, e.g. Correspondent Node and Mobile Node, the NAPT will also hold a state table with the care-of address and the UDP source port number on the inside of the NAPT. Additionally the state table includes an associated list of newly allocated UDP source port number on the outside of the NAPT. The latter UDP source port number is selected so that it is unique among the sessions traversing the NAPT at any point in time.

The Home Agent will discover the discrepancy between source IP address "204.68.9.2" and care-of address "10.0.0.2" inside the registration request message. In order to verify the sender, the Home Agent will send a registration reply reject code "failed authentication" and submit a challenge for the Mobile Node to respond to. The Mobile Node will interpret the behavior of the Home Agent in such a way that a new registration is required for it to pass a NAPT. The Mobile Node calculates the response to the challenge using its key and sends the new registration message. The Home Agent verifies the response to the challenge using the shared key or public key of the mobile node and the payload sessions may start.

There are two differences in the way payload transfer is performed when a NAPT is present in the path between the Mobile Node and Home Agent. First of all the payload packets to be sent through the Mobile IP tunnel are required to have a UDP header in between the two IP headers. This will ensure that the packet will pass through the NAPT and allow the NAPT to use the UDP source port to create a unique id for the payload session. The unique is needed in order to be able to map back to the correct IP address and source UDP port on the inside of the NAPT when traffic is coming back from the Home Agent. The second item is that the Home Agent is applying the source IP header of the registration request, i.e. the IP address of the NAPT "204.68.9.2", as the destination IP address also for packets destined for the Mobile Node. This is in contrast with the current IETF standard RFC 2002, where the Home Agent is using the care-of address as the destination IP address.

Firewall Traversal with Mobile IP and AAA

Firewall traversal in general might be arbitrary complicated. The overall complexity is depending on the target network layout. Assuming for example a Mobile IP infrastructure – it is possible to envisage a huge number of firewalls and other gateways such as NATs in between the path including the Mobile Node, the Foreign Agent, the Home Agent and the Correspondent Node.

A specific example, however, that is anticipated to be very common is a limited private addressing scenario where the Foreign Agent Care-of-addresses, The Home Agents and the AAA servers are equipped with publicly routable IP addresses. Still, the Home Agents are hidden by the Corporate Network firewall. For the purpose of clarity, in this example, we focus on an authenticated firewall traversal approach in a limited private addressing scenario as the one described above. That is, we do not cover the case where the complete Corporate Network topology is hidden behind the firewall. Instead we describe an authenticated firewall traversal – where we deploy the fact that authentication is performed by the AAA (Diameter) server at Mobile Node registration. Reverse tunneling is also anticipated. The main merit of the approach described in this example – is that it does not require any unnecessary tunneling – furthermore it does not require any changes to the Mobile IP protocol. This approach is currently under development process in the IETF.

In order to get Mobile IP to work we need to assure that the Home Agents are reachable from all possible Foreign Networks where the Mobile Nodes are expected to be roaming. On the other hand it is not a good idea to open up the firewall and let the Home Agent be globally reachable. Under the circumstances that there is a limited number of Foreign Networks where the Mobile Nodes are aloud to roam – it is possible to have static filters within the firewalls, limiting the reachability of the Home Agents. However, this is a very limited solution. In order implement dynamic reachability of the protected Home Agents, a more flexible solution is needed.

The solution described here proposes that the Home AAA server dynamically configure the firewall during the registration process of the Mobile Node. Since the mobile node already sends a MN-AAA authentication extension (AMR) to enable authorization and authentication by the AAAH, it is possible to also use this information for configuring the corporate firewall. The following figure and the subsequent description explain how this scenario works. The number preceding the description can be mapped to the number in the figure above.

  1. The Mobile Node sends the Registration Request to the Foreign Agent. The latter creates the AA-Mobile-Node-Request (AMR) message and forwards this message to the AAAH. The AMR includes the Mobile Node Care-of-address.
  2. If the AAAH is instructed to allocate a Home Agent and if the Home Agent address is known, the AAAH sends a Home-Agent-MIP-Request (HAR), which contains the Mobile IP Registration Request message to the assigned or requested Home Agent. Additionally the AAAH may allocate a Home IP Address for the Mobile Node. In this case the Home IP address will be included it in the HAR.
  3. The Home-Agent-MIP-Request (HAR) is sent to the assigned (or requested) Home Agent.
  4. If the AAAH has not allocated a home IP address for the mobile node, this allocation responsibility is left for the Home Agent. The home Agent processes the included MIP registration request and constructs and included a MIP registration reply in the Home Agent Answer (HAA.)
  5. The Home Agent Answer (HAA) is sent to the AAAH
  6. When the AAAH receives the HAA constructs the AA-Mobile-Node-Answer (AMA) and possibly forwards the AMA message to the AAAF. Before forwarding the AMA however, the AAAH has the ability to configure the firewall. In this case the AAAH constructs a Security Gateway Request (SGR) message. This message consist of among other things the Mobile Node Care-of-address, the Home Agent address and optionally the allowed protocol combination based on local policy (e.g. IP in IP, GRE, IPSec protocol (AH, ESP.)
  7. The Security Gateway Request message (SGR) is sent to the firewall from the AAAH.
  8. The firewall receives the SGR and constructs appropriate firewall rules to be applied on the ingress and egress interfaces. If the configuration is successful, a Security Gateway Answer (SGA) is constructed indicating success. Otherwise the SGA indicates failure.
  9. The Security Gateway Answer (SGA) is sent from the firewall to the AAAH.
  10. When the AAAH receives the Security Gateway Answer (SGA) and the SGA indicates successful configuration, the AAAH is allowed to forward the AMA as described in (6) above.
  11. The AAAH forwards the AA-Mobile-Node-Answer (AMA) the AAAF. Since the AAAH includes the Home Agent IP Address and Mobile Node IP address in the AMA message, it is possible for the AAAF to execute a similar firewall message exchange and configuration as described above within the Foreign Network.
  12. Mobile IP procedure including messages exchanges among Mobile Node, Foreign Agent and Home Agent may continue.

The solution described above may potentially allow security protocols such as IPSec to pass unexamined (but authenticated) through the firewall. However, based on local policy, specific auditing requirements may apply. Combining the audit trails from the firewall, the AAAH and the Home Agent can solve such potential auditing requirements. Especially under the circumstances where the firewall and the Home Agents are located and managed under the same administrative domain

One problem that is not as easily solved however is that the Diameter – Mobile IP specifications also include a mechanisms that may enhance the performance when moving between Foreign Agents within the same administrative domain. This is done by letting the Mobile Node move from one Foreign Agent to another within the same administrative domain, without having to send the request back to the Mobile Node's Home AAA Server (AAAH). However, deploying this feature means that the AAAH has no means of configuring new filtering rules in the firewall for the new Foreign Agent. Consequently packets from the new Foreign Agent will be dropped. One way of solving this problem is by disallowing the usage of previous Foreign Agent extensions under the circumstances where dynamic firewall configuration by the AAAH is required.

Redundancy among Home Agents

In a Mobile IP environment, the Home Agent is often to be seen as the "heart" of the mobility system. In basic Mobile IP (no AAA service), the Home Agent is the single point in that "owns" its associated mobile nodes. In basic Mobile IP, the Home Agent IP address is manually configured in the Mobile Node software. Without its associated Home Agent, the Mobile Node will be denied network services. It is, of course, of interest to build the Home agent in a redundant fashion – and in some cases it is also preferable to implement load sharing among multiple Home Agents. In this section a different way of implementing a network based Home Agent redundancy scheme is described. Previously in this paper a solution called "AAA - Mobile IP interworking" was described. AAA in this case is assumed to be the Diameter protocol. The concept of AAA and Mobile IP bundled together is powerful – but it still has some limitations. For once, the AAA Mobile IP bundling does not support Co-located care-of addresses and, secondly the load-sharing and redundancy achieved is limited in the sense that the selection of the Home Agent is only supported during the Mobile IP/AAA registration process.

A second way of implementing redundancy is based on the concept of a "virtual" Home Agent. A virtual Home Agent consists of redundant Home Agents hidden behind dispatcher functionality. This redundancy/load-balancing concept has the inherent advantage that it does not require a Diameter infrastructure and, furthermore it works with both network based and Co-located care-of addresses. However, this solution requires extensions to the Virtual Router Redundancy Protocol (VRRP) IETF RFC 2338.

The figure above is concerned with the redundancy (Home Agent availability) in a corporate network. The figure indicates a structure where two or more Home Agents are linked together to form a Virtual Home Agent hidden behind an Ethernet switch. The Ethernet Switch is also connected to the Global Internet where the Mobile Nodes are roaming. One physical Home Agent is designated to be the primary Home Agent for the Virtual Home Agent. The other Home Agent is assigned to be secondary (backup) Home Agent. The secondary and the primary Home Agent share the same "virtual" IP and MAC address (The physical Home Agents are multi-homed and are also equipped with a unique IP address for backend addressing.) In order to be able to take over the role of the primary Home Agent at any time and with minimal disturbance to the Mobile Nodes, the secondary Home Agent will have to be updated with all registrations that are received by the primary Home Agent. The Virtual Router Redundancy Protocol (VRRP) is for this purpose extended with three new packet types. When the secondary Home Agent boots, it will send a VRRP data dump request to the primary Home Agent with subtype = Mobile IP. This request is sent using the unique addresses of the Home Agents and may be sent across a backend network. The primary Home Agent responds with a VRRP data dump message, which contains all the currently valid mobile node registrations. After this boot sequence, the primary Home Agent forwards all Mobile IP registration messages received for the virtual IP address, using a VRRP data forward message. In case of failure to the primary Home Agent, the secondary Home Agent will take on the role as Home Agent. New Mobile Node registrations will come directly to the secondary Home Agent. In the same way as the primary Home Agent has been querying an LDAP or RADIUS server for subscriber data, the secondary Home Agent will do the same thing for current and new registrations received.

The VRRP Home Agent solution provides redundancy between two Home Agents sharing the same virtual Home Agent IP address. The most common set-up would be one Home Agent acting as primary for one Virtual Home Agent IP address and secondary for another. The effect is a redundant set-up that will survive failure of anyone of the involved Home Agents.

Networking solutions with Mobile IP

The following section covers brief descriptions on how Mobile IP enabled networks can be used to provide roaming and mobility support in some different scenarios. The first section is dedicated to a brief overview of the products from ipUnplugged AB and the latter sections consist of examples – mapping these products into possible network configurations. The first two examples deal with "mobile remote access VPN" scenarios from hot spot and wide-area cellular networks respectively. The last example is more advanced – and extends the basic concept of Mobile IP. The last example describes how extranet solutions can be provided in a Mobile IP enabled network design.

In the following; the router including Foreign and Home Agent functionality is denoted Mobility Router (MR) and the management system including among other the AAA functionality is denoted MM (Mobility Management.)

Hotspot Areas

The first example covers a scenario where e.g. a Hotel or an airport decides to provide wireless services in the vicinity of the hotel/airport for customers and other people visiting the area. The hotel/airport has the option to provide for two different equally interesting services. The first one is to provide the customers with pure Internet services – whilst the other is to provide the customer with support for corporate access. Using Mobile IP/AAA for these services means that the same infrastructure (hardware/software) can be deployed for supporting both services.

The following common assumptions are made when it comes to the protocols and infrastructure used to support the roaming and mobility services:

  • The mobile user deploys Mobile IP services (standalone FA)
  • Diameter as the AAA protocol
  • Dynamic HA assignment (assigned by AAAH)
  • Dynamic terminal IP address (assigned by HA)

We further assume that hotel or airport network is built up in a multi-layer fashion. A smaller network would be built in a more streamlined fashion. However, a multi-layer solution is preferable for a large hot spot area. Parts of the network may very well also be used for hotel/airport internal communication.

The figure below shows how a simplified network design supporting these services may look like. The multi-layer network design model consists of an access, distribution, core and core distribution layer. The access layer is typically based on Wireless LAN Access Points, each hosting a number of users based on e.g. capacity planning but also based on the impact of potential access point failure. The distribution nodes are multi-layer switches (layer 2 and 3). Each access layer Wireless AP is interconnected to two distribution nodes in order to provide redundancy in case of link failure. In addition, VRRP is applied between two neighbor distribution nodes for the purpose of network layer redundancy towards a Wireless access point.

The core network can either be based on layer 2 or layer 3 switching. The choice whether to use one or another is determined by the size of the OSPF backbone. There may also be other considerations for segmenting the backbone into several Virtual LANs, e.g. in order to separate management traffic from, best effort user traffic, real time traffic etc.

Finally, a new set of distribution nodes is typically placed in front of the server farm and the WAN firewall respectively (shown in the figure within the boxes surrounding the "server farm" and the "WAN distribution" layers. All the server-to-server traffic is then kept off the backbone and VRRP can run in-between a core distribution pair for the purpose of redundancy. The core distribution nodes may also include access control lists.

The left part of the figure indicates the hotspot area. The hot spot area is connected to the Internet via an Internet Service Provider (shown as the ISP Network in the upper right corner.) A Corporate Network is shown in the lower left corner. The Corporate Network connected to the Internet – assumable via a secondary ISP (not shown in the figure.) Importantly in this scenario, however, is that the entire mobility aware infrastructure is equipped with publicly routable Internet addresses. In other words it is assumed that the Foreign Agents and the AAAF within the hot spot area has public addresses. The Home Agent and the Home AAA server (AAAH) are also assumed to have public addresses whether these parts are located in the ISP network, the hot spot area or the corporate network.

In order to provide for Mobile IP services, the distribution layer in the hot spot access network has to be mobility aware. For this reason the distribution layer is built up by means of Mobile IP (Foreign Agent – AAAF) aware infrastructure. One important question is where to put the Home Agent and Home AAA functionality. The location of the Home Agent specifies which kind of service that will be provided (Internet Service versus Corporate Access) – while the location of the Home AAA server defines the business model. It is possible to identify at least three different models based on the figure:

  1. The hot spot area provider "owns" the wireless user
  2. The ISP providing Internet Services for the hot spot area "owns" the wireless user
  3. The external cooperation owns the wireless user – and the hotspot access owner provides access.

It is in other words possible to build up a diversity of business models based on in which network a specific functionality resides. How the business relation among the different networks really look like is more an administrative question than a technical.

Extranet partners

Online partnerships implemented by means of extranets - build up business partner networks. An extranet is a secure virtual private network created over the Internet. The extranet grants authorized users varying levels of controlled access to internal and external resources. Extranet includes two key components; the resources themselves and the infrastructure that makes those resources available. Here we focus on the infrastructure, and specifically the means for providing extranet infrastructure based on a mobility router and a management subsystem. The resources themselves may vary widely based upon the business needs and nature. Mobile IP and AAA together with a dynamic management system enable the possibility to form extranets and even more fine granular workgroups on the networking (IP) level. The workgroup filtering is implemented with distributed IP filtering in the Home Agents.

The extranet service is comprised of the user/policy management and the infrastructure itself. Managing and administering policies is the core of the extranet. User and resource policies must be determined to enable the one partner to securely delegate user management to its other partners. Policy management includes user enrolment and updates such as addition or revocation of privileges. It is immediately possible to envision three types of extranet configurations i.e. one dominant extranet partner, equal extranet partners and extranet provided as operator services. Each of the scenarios are briefly described below;

  • Extranets with one dominant partner is most likely deployed when one company ties together its suppliers or customers into a mobile workgroup system. Only the dominant partner maintains a Mobile Manager (MM.) The MM is typically made available at the DMZ of the dominant partner. The dominant partner has at least one Mobile Router (MR) at its premises. The other partners may or may not host a MR depending on what flexibility is desired when it comes to roaming into each other sites and hosting resources for the extranet workgroup locally at the customer/supplier. The customer/supplier is modeled as an organizational unit in the MM and is hosted at the top of organizational hierarchy.
  • Extranet workgroups with equal partners are based on separate MMs at each partner. From the view of a partner, the other is seen as an organization unit. The organization unit data (i.e. personnel and resources that should be made available for extranet workgroup creation) are imported using e.g. XML transport of LDAP data between MMs.
  • Extranet workgroups that are provided as an operator service fall back to the similar situation as with a dominant partner. In this case the operator is the dominant partner and all its customers are organizational units in the MM. Each customer has its organizational unit (OU) view of the MM and can open up the visibility of its resources and people to other customers (OUs) in order to create extranet workgroups.

The general requirement on a workgroup is to have users grouped according to some plan (for example, by job function or company department) for the following reasons: mobile workgroup is a community of interest based one or more of the following criteria:

  • The users in a workgroup may have the same access restrictions in the Intranet, e.g. guests and consultants,
  • They may share certain information located on a disparate set of servers, e.g. departments and projects, or
  • They may have a need to interact with each other, e.g. salesmen and controllers.

A workgroup can span enterprises, partners, customers and even public environments like airports and hotels. At the same time be absolute secure both in terms of who gets access to the workgroup and what information/services the members of the workgroup get access to. A member of a workgroup can only reach members, services or information sources belonging to the workgroup. Even if a workgroup is accessed over an arbitrary access network, it doesn’t mean the user will have any access, or possibility to reach information not belonging to the workgroup. A user, however, can belong to several workgroups at the same time.

 

Wide Area Solution

A wide area mobility solution based on Mobile IP is typically implemented by combing current access network technologies with Mobile IP Foreign Agent functionality. The figure below outlines possible locations for the Mobile Router, for the hot-spot area the MR is located close to the wireless LAN Access Points, providing the access network with Mobile IP Foreign Agent and AAA functions. In the fixed access scenario – it is possible to co-locate the NAS server with the Mobile Router. Again, the MR provides the wireline roaming users with Mobile IP and AAA functionality.

In the 3G UMTS access scenario, the Mobile IP Foreign Agent either resides inside the GGSN, or in a separate box e.g. a MR close to the GGSN. In the 3G cdma2000 network – the Foreign Agent and the AAA functionality is already implemented within the PDSN (Packet Data Service Node), and therefore additionally networking components are not needed in a cdma2000 access network. The Mobile IP client has its associated home network in a MR (Home Agent) in a corporate network accessed via an IPS network on the Internet. The IP address of the mobile will be kept during the hand-over from UMTS to the WLAN, the cdma2000 network and the wireline network. Still the relation with the home network is kept in the same manner independently wherever the mobile node is currently roaming. Mobile IP and AAA are truly the common denominator making mobility between a diversity of access systems a reality. Should the access network e.g. the 3G or 2.5G UMTS/GPRS or the wireline access network not be Mobile IP enabled –functionality of a co-located Care Of address in the mobile node itself could be offered – thus offering Mobile IP service independently of the access network topology.

Mobile IP: emerging technologies

While Mobile IP and related protocols as defined in the current standards constitutes a fully operable protocol suite, there are still problems to solve and enhancements to do. Some promising techniques and solutions that are under development and discussion today are briefly described in this section.

The present system of deploying IP network numbers was established in almost twenty years ago. This IP network numbering method is refereed to as IPv4 (or the Internet Protocol version 4.) The current scale of deployment strains some pieces of its design. The IETF has come up with specifications that define the next-generation IP protocol known as IPv6. IPv6 is a long-range strategy for network owners and service providers. IPv6 should be viewed as a new protocol that will provide a base for the continued growth of today's networks; it is intended to replace IPv4. IPv6 is designed to improve aspects of IPv4 such as scalability, mobility, configuration, security and management. It has been argued that IPv4 can be modified to perform these functions too, but many believes that the results are likely to be less functional than what would be of a full deployment of IPv6.

The real driver for IPv6 is the shortage of IPv4 addresses, threatening the globalization and evolution of the Internet. The shortage of IPv4 "addresses" mainly refers the depletion of "network" addresses. (IPv4 addresses consist of a network number part and a host number part.) Today, in the IP(v4) community the lack of network addresses is counter-measured in primarily two ways. The first one is via a mechanism called CIDR, Classless Inter-Domain Routing, and the secondly by means of network partitioning. The long-term solution of the network address depletion problem is to migrate to the new Internet protocol suite - IPv6.

Extensive industry testing are carried out at the moment. Still it will take some time before the Mobile IPv6 protocol will reach the maturity of a protocol usable in wide deployment. The introduction of Mobile IPv6 is of course related to the possible success of IPv6 per se. Other related technologies and mechanisms that will impact time of introduction of Mobile IPv6 (but are also discussed as parts of enhancing the Mobile IPv4 protocol suite.) The following areas are the ones that currently have priority and attract most interest within the IETF Mobile IP and related working groups.

  • IPSec: Mobile Ipv6 and the Interaction with the IPSec protocol are worked out on the protocol level.
  • AAA: AAA and Mobile IPv6 are still undefined. Work in this area is progressing and for the moment there exist a basic Internet draft describing this issue.
  • Fast handover: The interaction for "fast handover" and Mobile IPv6 is not fully worked out. Today there exist a new IETF working group [seamoby] that is intended to handle seamless mobility (i.e. loss-less (smooth) and fast hand-over) for IPv6. Work in this area has just started but will deal with issues such as paging, context transfer and local cache bindings (micro mobility.)
  • Header Compression: Robust header compression for IP over thin and expensive radio links. Figures indicate that the 40/60 byte IP header can be compressed down to 2-3 bytes only. This work is carried out in the IETF [rohc] group. Currently there exist profiles for Ipv4/UDP/RTP. Profiles for Ipv6/UDP/RTP but also other profiles, such as IPv6/TCP are expected.

A fact that possibly will hurry up the deployment of IPv6 in general and more specifically Mobile IPv6, is that the third generation partnership projects (3GPP and 3GPP2) are very prone on the v6 technology. These organizations are for the moment working with standardization of "All-IP" networking architectures intended for the evolution of GSM and cdmaOne cellular networks respectively. Both of 3GPP and 3GPP2 are working intensively with the cellular network impact on IPv6 and, the 3GPP organization has in fact mandated the use of IPv6 for what is denoted the multimedia sub-system in the forthcoming standard releases. Effectively this means that a third generation cellular UMTS phone is mandated to use IPv6 in order to access IP based multimedia services. Third generation all-IP enabled networks and terminal within the 3GPP2 community (cdma2000) are also required to support IPv6. It is generally believed that it will be the cellular industry that will drive the deployment of IPv6.

 

 

 

 

 

 

 

 

 

Abbreviations and Concepts

3GPP 3rd Generation Partnership project: Organization consisting of standard bodies responsible for the evolution of GSM based systems into the 3rd generation (UMTS.)

3GPP2 3rd Generation Partnership project #2: Organization consisting of standard bodies responsible for the evolution of cdmaOne based systems into the 3rd generation (cdma2000.)

AAA Authentication, Authorization and Accounting: AAA is a common name for both RADIUS and Diameter, i.e. solutions providing customer care and billing in a large IP network.

BGP Border Gateway Protocol: BGP is an inter-domain protocol defined by IETF for sharing routes between ISPs. A route is a collection of knowledge of a path to a destination (host).

cdma2000 Code Division Multiplexing Access 2000 is the US brand name for the 3rd generation cellular technology (IMT-2000). Cdma200 is based on a radio technology for access speeds up to 2 Mbit/s per Mobile Node.

Diameter A later version of RADIUS with increased security and scalability features. It is standardized by IETF.

DHCP Dynamic Host Configuration Protocol: DHCP is an Internet Engineering Task Force (IETF) standard for allocating Internet Protocol addresses to User Systems. User Systems can either be Fixed Hosts or Mobile Systems. The allocation is done when the User System is restarted. A DHCP server makes the allocation to a DHCP client. An Internet Service Provider or an IT-department controls the DHCP server. The DHCP client is a SW embedded in the User System.

DMZ De-Militarized Zone is a zone between the Internet Service Provider router and corporate firewall where access is allowed from both the Internet and the Intranet. Normally a subset of the services available on the Intranet is mirrored on the DMZ.

FA Foreign Agent: A tunnel agent establishing a tunnel on behalf of a mobile node in Mobile IP.

FW Firewall: The system (or collection of systems) that enforces access control between a private network and the Internet. It may deploy mechanisms such as application gateways, packet filtering and cryptographic techniques.

HA Home Agent: The tunnel agent which terminates the tunnel, and which encapsulates datagrams to be sent to the Mobile Node in Mobile IP.

IETF Internet Engineering Task Force: IETF is the standardization organization for the Internet community.

IP Internet Protocol. IP is a network layer protocol according to the ISO protocol layering. IP is the major end-to-end protocol between Mobile and Fixed End-Systems for Data Communications. It is also used in Radio Data communications Systems as an underlying transport technology for Tunneling Protocols.

IKE Internet Key Exchange: A Key management protocol for among others the IPSec protocol.

ISP Internet Service Provider: The ISP is a notation for the domain providing basic IP configuration services to users, i.e. servers for Domain Name System (DNS) and Dynamic Host Configuration Protocol (DHCP).

LDAP Lightweight Directory Access Protocol is a slim variant of the X.500 Directory Access Protocol for accessing data storage areas such as user databases.

MANET Mobile Ad hoc Networks is a common name for a family of protocols that provide multi-hop routing in highly mobile environments.

MIB Management Information Base: IETF defines a number of MIBs for allowing management via the SNMP (Simple Network Management Protocol) of network elements. The format of a MIB is standard. The content can either be proprietary or standardized.

MIP Mobile IP: MIP is a standard being defined by IETF on making IP networks mobility aware, i.e. having knowledge on where a Mobile Node is plugged into the network. The standard includes the definition of a Foreign Agent and a Home Agent.

MC Mobile Client: The MC comprises both the Terminal (TE) and the Mobile Termination (MT).

NAT Network Address Translation.

NAPT Network Address and Port Translation.

Private Network A protected network separated from the Internet by hosts enforcing access restrictions. A private network may or may not use a private address space.

Public Network The Internet. Hosts are able to communicate with each other throughout the public network without firewall- or NAT/NAPT imposed restrictions.

RADIUS Remote Authentication Dial-In User Service: RADIUS is a protocol for carrying authentication, authorization, configuration and accounting information between a network access server and an ISP RADIUS server.

RAN Radio Access Network: RAN is the common acronym used for various types of radio access networks in 3G networks, e.g. CDMA2000 and UMTS.

SLA Service Level Agreement: SLA is the common name for a set of terms agreed with the customer on the quality of service that the ISP shall provide. The SLA can related to availability, latency and throughput of network resources.

UMTS Universal Mobile Telecommunications System: UMTS is the European name for the 3rd generation radio technology (IMT-2000) for access speeds up to 2 Mbit/s per Mobile Node.

VLAN Virtual Local Area Network is a separation of a physical Local Area Network into a set of logical subnets.

VPN Virtual Private Network is a secure overlay network on a common public infrastructure that allows a corporation to maintain its own addressing and routing between its sites.

WCDMA Wideband CDMA.

WLAN Wireless Local Area Network: WLAN is a local area solution for radio access.

 

 

References

  1. 3GPP2 PR0001 v1.0.0/Wireless IP Network Architecture based on IETF protocols, July, 2000; http://www.3gpp2.org/docs/newsd/P.R0001.pdf
  2. 3GPP2 PS0001-A, v1.0.0/Wireless IP Network Standard, July 2000; http://www.3gpp2.org/docs/newsd/P.S0001-A.pdf
  3. Diameter Base Protocol, Calhoun, Pat et al; Internet Draft, April 2001. Work in progress.
  4. Diameter Mobile IP Extensions, Calhoun, Pat et al; http://www.ietf.org/internet-drafts/draft-calhoun-diameter-mobileip-11.txt, September 2000.
  5. Mobile IP Network Access Identifier Extension for IPv4, Calhoun, Pat et al; RFC2794; http://www.ietf.org/rfc/rfc2794.txt; March 2000
  6. Dynamic Host Configuration Protocol, Droms, R., RFC2131, http://www.ietf.org/rfc/rfc2131.txt - March 1997
  7. Reverse Tunneling for Mobile IP, Montenegro, G.; RFC2344; http://www.ietf.org/rfc/rfc2344.txt; May 1998.
  8. IP Mobility Support; RFC2002, Perkins, Charlie; http://www.ietf.org/rfc/rfc2002.txt; October 1996.
  9. IP Mobility Support for IPv4, revised, Ed. C. Perkins, Internet draft, February 2001. Work in progress.
  10. Dynamic Updates in the Domain Name System (DNS UPDATE), Ed. P. Vixie, RFC 2136, http://www.ietf.org/rfc/rfc2136.txt; April 1997.
  11. The Network Access Identifier, Ed. B. Aboba, M. Beadles, RFC 2486, http://www.ietf.org/rfc/rfc2486.txt, January 1999.
  12. Remote Authentication Dial In User Service (RADIUS), Ed. C. Rigney et al., RFC 2138, http://www.ietf.org/rfc/rfc2138.txt, April 1997.
  13. Session Initiation Protocol, Ed. M. Handley, RFC 2543, http://www.ietf.org/rfc/rfc2543.txt, March 1999.