Case Study on Mobile Routing

Mehul Doshi

• 
  Abstract:
  

The availability of powerful mobile computing devices, wireless networking products and services is increasing dramatically. However internetworking protocols such as IP used in the Internet do not currently support host movement. Mobile Internet Protocol is a new recommended Internet Protocol designed to support the mobility of a user host. This paper describes and summarizes the characteristics of the current Internet draft for Mobile IP. In addition it also discusses alternative Mobile IP and it’s routing proposals so that the reader may understand the different design issues associated with it. It also points to some problems that may arise if the current draft were to be implemented and looks and suggests at solutions, which may solve them.

• 
  Introduction:
  

Mobility can be both with wireless and wired and conversely also. In all the four combinations we notice that wired or wireless are Data Link Layer issues while Mobility is a Network layer issue or in general a higher layer issue. Hence ‘mobility’ doesn’t require wired or wireless hosts. Hence there is a need for introducing newer protocols that can be used for internetworking with such mobile hosts. However this would require a monumental task of upgrading and configuring a large number of routers and hosts. Hence the designed protocols should be able to support incremental upgrades. This means that it should be able to talk to both hosts that aren’t yet configured with it along with the hosts, which are already upgraded. Mobile IP is most likely to be implemented in some form or other in the future.

• 
  Why Mobile IP?
  

IP version 4 (IPv4) assumes that a node’s IP address uniquely identifies the node’s point of attachment to the internet. In order to provide a scalable routing support, internetworking protocols use hierarchical addressing and routing schemes. Hence routers within the internet need to know only how to route packets based on network number and destination address in each packet and once the packet reaches that network, it is delivered to the correct individual host on that network. Hence a node must be located on the network indicated by its IP address in order to receive datagrams destined to it; otherwise they would be lost. This sort of aggregation oat each level of hierarchy also reduces the size of the routing tables that each of the routers maintain. However this hierarchy in addressing and routing prevents packets from being routed correctly to the mobile host when it is away from its home network. For a host to change its point of attachment without losing its ability to communicate, currently one of the two following mechanisms must typically be employed:

• 
  Node must change its IP address whenever it changes its point of attachment.
  
• 
  Host-specific routes must be propagated throughout the Internet routing fabric.
  

We can see clearly that both of these alternatives are unacceptable. The first makes it impossible for a node to maintain transport and higher-layer connections when the node changes location. The second has obvious and severe scaling problems. Hence a new, scalable, mechanism is required for accommodating node mobility within the Internet.

Mobile IP would have several features associated with it like:

• 
  No geographical limitations: A user can take a palmtop or laptop computer anywhere without losing the connection to the home network.
  
• 
  No physical connection required: Mobile IP finds local IP routers and connects automatically.
  
• 
  Modifications to other routers and hosts are not required: Other than mobile nodes/routers, the remaining routers and hosts will still use current IP. Mobile IP leaves transport and higher protocols unaffected.
  
• 
  No modifications to the current IP address and IP address format: The current IP address and address format remains the same.
  
• 
  Supports security: Authentication is performed to ensure that rights are being protected.
  

• 
  How does Mobile IP work?
  

Mobile IP is the cooperation of three separable mechanisms:

• 
  Discovering the care-of address
  
• 
  Registering the care-of address
  
• 
  Tunneling to the care-of address
  

• 
  Discovering the Care of Address (COA)
  

Either Agent Advertising or Solicitation methods can find out the COA. Mobile IP discovery does not modify the original fields of existing router advertisements but simply extends them to associate mobility functions. Thus, router advertisements can carry information about default routers, just as before, and in addition carry further information about one or more care-of addresses. When the router advertisements are extended to also contain the needed care-of address, they are known as agent advertisements. Home agents (HA) and foreign agents (FA) typically broadcast agent advertisements at regular intervals. If a mobile node needs to get a care-of address and does not wish to wait for the periodic advertisement, the mobile node can broadcast or multicast a solicitation that will be answered by any foreign agent or home agent that receives it. Home agents use agent advertisements to make themselves known, even if they do not offer any care-of addresses. However, it is not allowed to associate preferences to the various care-of addresses in the router advertisement, as is the case with default routers. Thus, an agent advertisement performs the following functions:

• 
  Allows for the detection of mobility agents
  
• 
  Lists one or more available care-of addresses
  
• 
  Informs the mobile nodes bout special features provided by foreign agents, for example, alternative encapsulation techniques.
  
• 
  Lets mobile nodes determine the network number and status of their link to the Internet and
  
• 
  Lets the mobile node know whether the agent is a home agent, a foreign agent, or both, and therefore whether it is on its home network or a foreign network.
  

Mobile nodes use router solicitations to detect any change in the set of mobility agents available at the current point of attachment. (In Mobile IP this is termed as agent solicitation.) If advertisements are no longer detectable from a foreign agent that previously had offered a care-of address to the mobile node, the mobile node should presume that foreign agent is no longer within range of the mobile node’s network interface. In this situation, the mobile node should begin to hunt for a new care-of address, or possibly use a care-of address known from advertisements it is still receiving. The mobile node may choose to wait for another advertisement if it has not received any recently advertised care-of address, or it may send an agent solicitation.

• 
  Registering Care of Address
  

Once a mobile node has a care-of address, its home agent must find out about it. The process begins when the mobile node, possibly with the assistance of a foreign agent, sends a registration request with the care-of address information. When the home agent receives this request, it adds the necessary information to its routing table, approves the request, and sends a registration reply back to the mobile node. Registration requests contain parameters and flags that characterize the tunnel through which the home agent will deliver packets to the care-of address. When a home agent accepts the request, it begins to associate the home address of the mobile node with the care-of address and maintains this association until the registration lifetime expires. The triplet that contains the home address, care-of address and registration lifetime is called a binding for the mobile node. A registration request can be considered a binding update sent by the mobile node.

The home agent must be certain registration was originated by the mobile node and not by some other malicious node pretending to be the mobile node. A malicious node could cause the home agent to alter its routing table with erroneous care-of address information, and mobile node would be unreachable to all incoming communications from the Internet. Hence there arose a need to authenticate registration information. To secure the registration request, each request must contain unique data so that two different registrations will in practical terms never have the same tokens. Otherwise, the protocol would be susceptible to replay attacks, in which a malicious node could record valid registrations for later replay, effectively disrupting the ability of the home agent to tunnel to the current care-of address of the mobile node at that later time. To ensure this does not happen, Mobile IP includes within the registration message a special identification field that changes with every new registration. There are two main ways to make the identification field unique.

One is to use a timestamp; then each new registration will have a later timestamp and thus differ from previous registrations. The other is to cause the identification to be a pseudorandom number; with enough bits of randomness, it is highly unlikely that two independently chosen values for the identification field will be the same.

In Mobile IP foreign agents are mostly passive, relaying registration requests and replies back and forth between the home agent and the mobile node, doing mostly what they are told. The foreign agent also de-capsulate traffic from the home agent and forwards it to the mobile node. It should be noted that the mobile node will have a layer 2 address and not an IP address otherwise the foreign agent may again resend it to the home agent i.e. the foreign would strip off the IP headers and then put it on say the Ethernet connected to it and the mobile node would simply pick it up. It is quite possible for a bad foreign agent to impersonate a real one and simply by following protocol and offering agent advertisements to the mobile host. It could then refuse to de-capsulate the packets to the mobile host after they are received. This is possible since foreign agents don’t have to authenticate themselves to the mobile node.

Automatic home agent discovery – When the mobile node cannot contact its home agent, Mobile IP has a mechanism that lets the mobile node try to register with another unknown home agent on its home network. This method of automatic home agent discovery works by using a broadcast IP address, instead of the home agents IP address as the target for the registration request. When the broadcast packets gets to the home network, other home agents on the network will send a rejection to the mobile node; however, their rejection notice will contain their address for the mobile node to use in a freshly attempted registration message. It is a directed broadcast that reaches only IP nodes on the home network.

• 
  Tunneling to the Care of Address:
  

The default encapsulation mechanism that must be supported by all mobility agents using Mobile IP is IP-within-IP. Using IP-within-IP, the home agent (tunnel source), inserts a new IP header, or tunnel header, in front of the IP header of any datagram addressed to the mobile node’s home address. The new tunnel header uses the mobile node’s care-of address as the destination IP address, or tunnel destination. The tunnel source IP address is the home agent, and the tunnel header uses 4 as the higher-level protocol number, indicating that the next protocol header is again an IP header. In IP-within-IP the entire original IP header is preserved as the first part of the payload of the tunnel header. Therefore to recover the original packet, the foreign agent merely has to eliminate the tunnel header and deliver the rest to the mobile node. Such routing tunnels need to be implemented with care because advertising explicit host routes into the wide area routing tables destroys routing scalability.

Sometimes the tunnel header uses protocol number 55 as the inner header. This happens when the home agent uses minimal encapsulation instead of IP-within-IP. Processing for the minimal encapsulation header is slightly more complicated than that for IP-within-IP, because some of the information from the tunnel header is combined with the information in the inner minimal encapsulation header to reconstitute the original IP header. On the other hand, header overhead is reduced.
Mobile IP uses a home agent physically attached to the mobile host’s home network to intercept and tunnel packets to the mobile host. Hence, packets undergo triangle routing, which is often longer than the optimal unicast path. Moreover adding to this problem is the widespread deployment of ingress filters (Border routers at the periphery of an administrative domain carefully discarded datagrams that seem to emanate from an address external to the administrative domain. This is known as Ingress Filtering) as a “Best Current Practice” to combat denial of service attacks. With this mechanism, a router does not forward packets with a source address foreign to the local network, which implies that a packet sent by a mobile host in a foreign network with its source address set to its home address will not be forwarded. The solution to this is to use reverse tunneling, which tunnels packets originating at the mobile host first to the host’s home agent (using the host’s care of address as a source address), then from there on to the destination using the home address as the source address. Thus, routing anomalies occur in both directions.

• 
  Enhancements and Proposals
  

Some recent and efficient proposals have suggested the design and implementation of an end to end architecture for Internet host mobility using dynamic updates to the Domain Name System (DNS) to track host location. In this the name updates are effected via the secure DNS update protocol, while the TCP connection migration uses a novel set of Migrate Options and provides a pure end system alternative to routing based approaches such as Mobile IP.

We know that delivering data to a mobile host across a network address change without disrupting existing connections can be tackled by introducing a level of indirection in the routing system. This approach when taken deploys a home agent that intercepts packets destined for a host currently away from its home network, and delivers it to the mobile host via a foreign agent in the foreign network. It does not require any changes to the fixed (correspondent) hosts in the Internet, but does require changing the underlying IP substrate to affect this triangle routing, and an authentication protocol to ensure that a malicious party does not hijack connections.

However there are many other applications wherein other hosts originate connections to a mobile host and can benefit from both host location and hand-off support or where the mobile host originates all connections which do not require host locations services but can benefit from the handoff support and those where an application level retry suffices if the network address changes unexpectedly during a short transaction, which need neither to work well. In all of the above situations an end-to-end system can meet the goals, Moreover in an end-to-end architecture the mobile host exercises explicit control over its mobility node and hence the need for an additional third party viz. the home agent in the packet routing is removed.

• 
  Addressing:
  

The key to the scalability of the Internet architecture is that the IP address serves as a routing locator, reflecting the addressee’s point of attachment in the network topology. This enables aggregation based on address prefixes and allows routing to scale well. Using Migrate TCP, the mobility architecture preserves this crucial property of Internet addressing.

• 
  TCP connection migration:
  

A new proposal is to have a Migrate TCP option, included in SYN segments, that identifies a SYN packet as part of a previously established connection, rather than a request for a new connection. This Migrate option contains a token that identifies a previously established connection on the same destination address-port pair. The token is negotiated during initial connection establishment through the use of Migrate Permitted Option. After a successful token negotiation, TCP connections may be uniquely identified by either their traditional source address, source port, destination address, destination port tuple, or a new source address, token triple on each host.

• 
  Routing Issues:
  

Source Routing: As opposed to the way in which router optimization is specified in IPv4, in IPv6 correspondent nodes do not tunnel packets to mobile nodes. Instead, they use IPv6 routing headers, which implement a variation of IPv4’s source routing option. A number of early proposals for supporting mobility in IPv4 specified a similar use of source routing options, but two main problems precluded their use:

• 
  IPv4 source routing options require the receiver of source-routed packets to follow the reversed path to the sender back along the indicated intermediate nodes. This means that malicious nodes using source routes from remote locations within the Internet could impersonate other nodes, a problem exacerbated by the lack of authentication protocols.
  
• 
  Existing routers exhibit terrible performance when handling source routes. Consequently, the results of deploying other protocols that use source routes have not been favorable.
  

However the objections to the use of source routes do not apply to IPv6, because IPv6’s specifications eliminate the need for source-route reversal and lets routers ignore options. Consequently, correspondent nodes can use routing headers without penalty. This allows the mobile node to easily determine when a correspondent node can use routing headers without penalty. This allows the mobile node to easily determine when a correspondent node does not have the right care-of address. Correspondent nodes that need to receive binding updates from the mobile node must have sent packets delivered by encapsulation instead of by source routes in a routing header. It is a further point of contrast to route optimization in IPv4 that, in IPv6 mobility support, the mobile node delivers binding updates to correspondent nodes instead of to the home agent. There is a distinct possibility in IPv6 of the availability of key management between the mobile node and correspondent node will be implemented. Other features supported by IPv6 mobility include

• 
  Coexistence with Internet Ingress filtering
  
• 
  Smooth handoff, which in Mobile IPv4 is specified for foreign agents as part of route optimization.
  
• 
  Renumbering of home networks and
  
• 
  Automatic home agent discovery.
  

Another way of routing for a mobile network that has been discussed is using a different hierarchy, which can be dynamically configured as compared to the cluster hierarchy in existence today. This is being termed as the ‘Landmark Hierarchy’. This has been shown by the author to have similar path lengths and routing tables as compared to the conventional area hierarchy. In this the routing known as ‘landmark routing’, a distributed set of algorithms is used for the purpose. It has been shown to optimize routing in very large networks as it dynamically configures the hierarchy on the fly allowing for very large and highly dynamic networks. In this type of routing each router has in its tables only those routers who are a certain number of hops away as compared to a cluster hierarchy wherein all routers in one area have routing entries of all other routers. This implies that each router has all information of local routes and information decreases as we move away from it. A full description of the same is in [4].

• 
  Security Issues:
  

As put in by Perkins and Johnson [2] “One of the most difficult aspects of Route Optimization for Mobile IP in the Internet today is that of providing authentication for all messages that affect the routing of datagrams to a mobile node.”

The issues are:

• 
  Data Confidentiality: Is it possible for the attacker to monitor the confidential traffic of other users of the system?
  
• 
  Data Authenticity: Traffic/Identity hijacking: Is it possible for the attacker to masquerade as a user? That is, to bypass the authentication and steal the identity of another user.
  
• 
  Service Availability: Denial of Service: Is it possible for the attacker to prevent other users to use the services of the system?
  
• 
  Signaling and Location Confidentiality: Is it possible for the attacker to monitor the movements of the mobile host and/or collect user data about the behavior of the user?
  

In each case the level of security depends on the algorithms and keys used for countering the threat. The roles considered during the analysis were:

• 
  Hostile mobile host or a host masquerading as a mobile host
  
• 
  Hostile nodes in the serving network
  
• 
  Hostile FA or a host masquerading as an FA.
  
• 
  Hostile nodes in the home network
  
• 
  Hostile HA or a host masquerading as an HA.
  
• 
  Hostile nodes outside the home and serving networks.
  

• 
  Data Confidentiality: The likelihood that the confidentiality of the transmitted packets will be compromised depends strongly on the route of the packets. Mobile IP does not encrypt the packets, and thus the whole route of the packets has to be trusted or IPSec should be used on these parts of the route. Another possibility as discussed by authors would be to use token systems as shown in [2].
  
• 
  Inside visited network: It is very demanding to make IP based network secure at the times of faulty TCP/IP protocols/applications. The need for additional encryption depends on the level of trust the roaming user has for the visited network’s ability and motivation to secure the network.
  
• 
  Between the visited and home network: The level of security on this part of the route is very difficult to define. In practice IPSec tunneling should be used.
  
• 
  Inside the home network: In client-server applications and when the reverse tunneling is used the route of the packets goes to the home network of the roaming user.
  

In the scenario the mobile IP is an attractive target for a malicious host outside of firewalls as it could allow connection hijacking. After successful registration Mobile IP can be used to get around IP address based packet filters used in the firewalls. This requires that the attackers can fool the mobility agents to accept the registration either passing the mandatory authentication or finding a way to avoid it.

A malicious host might try to register to the HA as a roaming mobile host. This is protected by the mandatory authentication of the register message (IPv4) and Binding update (IPv6). The scenario where a HA in a secure network accepts mobile-IP registrations originating outside the secure IP-network places very strict requirements on the authentication algorithm and the key management. The authentication of the mobile node by the FA is not mandatory in IPv4 Mobile-IP. A malicious host might try to register to the FA as a roaming mobile host. This could allow traffic stealing if the real host is roaming the same visited network. This could also be used for bypassing the charging if the access is charged.

Malicious FA’s might try to attack the HA. Possible attack types against mobile-IP could be replay attacks and attacks that lead to false authentication. The mobile-IP protocol offers sufficient protection against these in the form of identification and authentication extensions.

Reverse tunneling introduces additional threats: when using reverse tunneling the traffic seems to originate from the safe side of the firewall i.e. from the home agent. The legitimate use of Mobile IP can introduce problems with firewalls and IPSec Security Gateways; reverse tunneling can be used to avoid these problems (with a price of un-optimized routing). Reverse tunneling can also be used for enforcing location confidentiality.

• 
  Service availability: Service availability is difficult for both IP-based network and wireless communications. The IP network can be flooded with techniques like SYN-flooding with a non-existing source address, Domain Name Servers. TCP/IP stack of the host can be crippled with an illegal IP packet received from the network. The limited capacity of the system can be saturated.
  
• 
  Signaling and location confidentiality: Also the signaling information should be tunneled when possible to prevent behavior information about the user to be collected. The optimized routing can compromise location confidentiality.
  
• 
  The header information of the IP-packets can be used for tracking the mobile host, unless IPSec is used in tunneling mode. This is another good reason for IPSec tunneling all data through unsecured parts of the communication path.
  

• 
  Other Changes in IPv6:
  

Features like Stateless Address Auto configuration and Neighbor discovery that are missing in IPv4 are added in IPv6. It also attempts to simplify the process of renumbering, which could be critical to the future routing ability of the Internet. Mobility support in IPv6, as proposed by the Mobile IP working group, follows the design for Mobile IPv4. It retains the ideas of a home network, home agent, and the use of encapsulation to deliver packets from the home network to the mobile node’s current point of attachment. While discovery of a care-of address is still required, a mobile node can configure its care-of address by using Stateless Address Auto Configuration and Neighbor Discovery. Thus, foreign agents are not required to support mobility in IPv6. Moreover IPv6-within-IPv6 tunneling is also already specified.

• 
  Complications and Possible Solutions:
  

• 
  Zigzag routing: If a mobile node happens to move to the same sub-network as its correspondent node that wants to send it datagrams then what happens is that for the datagram to be received by the mobile node, based on the Mobile IP protocol, the correspondent node will send the datagram all the way to the mobile node’s home agent which can be anywhere. Then its home agent will then forward the datagram to its care-of address, which wastes time and network resources since the datagram could have been sent directly from the correspondent node. This kind of “indirect-routing” is inefficient and undesirable.
  

A solution that can be done is to have some sort of binding between the mobile node and the correspondent node wherein an effective way is maintained by the correspondent node as to where the mobile node is. This would remove this indirect routing as the correspondent node would then optimize the path and send it directly to the foreign agent.

• 
  Frequent reporting incase mobile node moves very fast and frequently: If a mobile host is in a moving vehicle and roaming around into neighboring communities, then, the mobile IP will have to constantly report to the home agent to change it’s address. This leads to degradation of the performance and delays the datagram transmission.
  

A solution maybe similar to what is being used in GSM wherein only when the cell crosses cell boundaries and handoffs take place that it’s reported back to the home agent. However for this to work in case of mobile hosts, it would require dividing the whole area into a number of cell clusters. That would require quite a different amount of routing protocols also.

• 
  Too many unwanted fields in “IP within IP”: We know that when the packets (datagrams) are encapsulated the original datagram is put inside another IP datagram where the whole packet is basically the IP header containing the care-of address and the original datagram. The fields in the outer IP header add too much overhead to the final datagram as several fields are duplicated from the inner IP header. This waste of unnecessary space is uneconomical.
  

A solution proposed by IETF called the Minimal Encapsulation scheme is defined, and becomes another way to encapsulate the datagram. The approach to the encapsulation method is as follows: The original header is itself modified to point to the care-of address rather than inserting another IP header. Now instead of de-capsulating the datagram, the foreign agent will do a fair amount of computation before it can be sent to the mobile host. This is the tradeoff with utilizing network resources versus fast delivery of messages to the mobile host.

• 
  Ingress Filtering: Many border routers discard packets coming from within the enterprise if the packets do not contain a source IP address configured for one of the enterprise’s internal networks. Because mobile nodes would otherwise use their home address as the source IP address of the packets they transmit, this presents difficulty.
  

A solution to this problem in Mobile IPv4 would be tunnel outgoing packets from the care-of address. However, then the difficulty is how to find a suitable target for the tunneled packet from the mobile node. The only universally agreed routing possibility is the home agent, but that target introduces yet another anomaly for communications between the mobile node and the rest of the internet. The use of reverse tunneling to the home agent to counter the restriction imposed by ingress filtering can help. Mobile IPv6 also offers a solution in the home address destination option.

• 
  Security Issues: Mobile IP has to co-exist with the security features that are in use within the Internet like Firewalls. Firewalls cause difficulty for Mobile IP because they block all incoming packets that do not meet specified criteria. Many firewalls are typically configured to block packets from entering via the Internet, which appear to emanate from internal computers. It presents difficulties for mobile nodes wishing to communicate with other nodes within their home enterprise networks. Such communications, originating from the mobile node, carry the mobile node’s home address, and would thus be blocked by the firewall. A number of solutions are being developed which could allow traversal of firewalls without lowering security.
  

• 
  Conclusions:
  

Mobile IP is definitely going to be implemented sooner than later in spite of competing tunneling protocols like the PPP based PPTP and L2TP. These protocols though offer portability in operations and at best may be a short term solution to inter-network routing of mobile hosts. However in the long run Mobile IP would be definitely required in some form or the other with variety of solutions and fixes to the foreseen problems. It would in all probability have to include incremental upgrades so as to allow time for the entire protocol system to be upgraded. Moreover some sort of glitch less handoff from one agent to the another should also be deployed so as to make sure that erroneous data is not received or for that matter retransmissions don’t occur because of them since the amount of mobile hosts is slated to increase exponentially creating an unprecedented situation of number of retransmissions caused on account of handoffs. Ad-hoc routing schemes as proposed can be implemented alongside so as to increase efficiency and scalability.

• 
  Bibliography:
  

1. 
   D. Johnson, Scalable Support for Transparent Mobile Host Internetworking, in Mobile Computing, edited by T. Imielinski and H.Korth.
   

2. 
   A.Snoeren and H. Balakrishnan, An End-to-End Approach to Host Mobility, Proc. MOBICOM 2000.
   

3. 
   J. Broch, D. Maltz, D. Johnson, Y-C. Hu, J. Jetcheva, A Performance Comparison of Multi-Hop Wireless Ad Hoc Routing Protocols, Proc. ACM/IEEE MOBICOM, Dallas, TX, August 1998.
   

4. 
   P. Tsuchiya, The Landmark Hierarchy: A New Hierarchy for Routing in Very Large Networks, Proc. SIGCOMM’88, pp. 35-42, Stanford, CA, August 1988.
   

5. 
   RFC-2002 – IP Mobility Support.
   

6. 
   C.E. Perkins, “Mobile IP: Design Principles and Practises.”
   

7. 
   IETF Working Group on Mobile IP.