Extended Correspondent Registration Scheme for Reducing Handover Delay in Mobile IPv6

Transcription

1 Extended Correspondent Registration Scheme for Reducing Handover Delay in Mobile IPv6 Ved P. Kafle Department of Informatics The Graduate University for Advanced Studies Tokyo, Japan Eiji Kamioka and Shigeki Yamada National Institute of Informatics Tokyo, Japan Abstract We present a new scheme for fast binding update with correspondent nodes to expedite the handover operation of mobile nodes in Mobile IPv6 protocol supporting networks. Our scheme is an extension of the Mobile IPv6 correspondent registration process that modifies some messages exchanged between a mobile node and a correspondent node. This scheme reduces the handover latency while providing the same level of security assurances for revealing the location information to the correspondent node as in the current Mobile IPv6 protocol. We also present an extension of the scheme to multihomed mobile nodes that have heterogeneous interfaces. 1. Introduction In Mobile IPv6 (MIPv6) [3], a mobile node generally performs correspondent binding updates to register its careof address with a correspondent node for route optimization under the following two cases: (1) when it receives a packet from the correspondent node tunneled via a home agent; (2) when it changes its care-of address due to a handover. The MIPv6 standard treats both cases in the same manner, i.e., performing a return routability (RR) test, and then sending a binding update message containing the new care-of address to the correspondent node. However, we argue that the urgency levels of performing a binding update in the above two cases are different. In the first case, the communication between the correspondent node and the mobile node is not disturbed even if the mobile node takes a longer time to complete a binding update with the correspondent node, because the packets originating from the correspondent node can always reach the mobile node, although through a relatively longer path, via the home agent. In contrast to the first case, the second case requires a more urgent action to perform the binding update with the correspondent node because the packets might be lost if the correspondent node is not notified of the new care-of address of the mobile node for a long time. Therefore, in this paper we address the second case by proposing a new correspondent registration mechanism for expediting handover operations. Completing a correspondent binding update together with an RR test takes at least 1.5 times the round-trip time (RTT) between the mobile node and the correspondent node. If the mobile node is required to perform an RR test on every handover, the MIPv6 protocol cannot perform well as a mobility management solution in future heterogeneous mobile networks. Taking this fact into consideration, the Internet Engineering Task Force (IETF) has extended the MIPv6 operation to access networks and has drafted two protocols: Hierarchical MIPv6 (HMIPv6) [6] and Fast MIPv6 [5]. The first protocol assumes a hierarchical structure of the access routers to localize signaling messages, whereas the second protocol assumes the cooperative access routers to provide packet-tunneling services during a handover of the mobile node. However, both of these schemes require a special configuration of the access networks, which may not be feasible in heterogeneous mobile network systems where the component networks may have no relationship or cooperation amongst them. To accelerate the correspondent binding update process during a handover, our objective is to design a new binding update method that achieves the same level of security assurances in revealing the location information to the correspondent node as in the current MIPv6 protocol. We will not use any more signaling messages than the current MIPv6. Instead, we will modify some of the existing signaling messages. In our scheme, the mobile node utilizes the recently obtained home and care-of keygen tokens to perform a binding update following a handover. Therefore, the mobile node does not have to perform an RR test on every handover; instead, it sends the binding update mes-

2 Return Routability Test MN HA CN Home Test Init (HoA, home init cookie) Care-of Test Init (CoA, care-of init cookie) Home Test (home init cookie, home keygen token, home nonce index) Care-of Test (care-of init cookie, care-of keygen token, care-of nonce index) Binding Update (MAC, seq#, nonce indices, CoA, HoA) Figure 1. Correspondent registration in MIPv6. sage through a secure tunnel via the home agent, assuring the correspondent node that the message is from the mobile node whose home address is present in the packet header. We will also present an extension of the scheme to a multihomed mobile node that has heterogeneous interfaces and many care-of addresses. This paper is organized as follows. Section 2 overviews the correspondent registration and handover operations of MIPv6. The operation of our proposed scheme is described in Section 3. Section 4 discusses the security issues related to our scheme, and Section 5 presents an extension of the scheme to multihomed mobile nodes. Section 5 concludes the paper, while outlining future work. 2. Related Work As the proposed scheme is an extension of the MIPv6 protocol [3], we start with an overview of the correspondent registration and handover operation in MIPv Correspondent Registration in MIPv6 The correspondent registration in MIPv6 comprises two tasks: a return routability (RR) test, which consists of exchanging four messages between a mobile node and a correspondent node, and a binding update. As shown in Fig. 1, the mobile node (MN) initiates the RR test by sending a home test init message via the home agent (i.e., the message is reverse tunneled through the home agent) and a care-of test init message directly to the correspondent node (CN). The home test init message includes the mobile node s home address (HoA) and a cookie. Similarly, the care-of test init message includes the mobile node s care-of address (CoA) and a cookie. In response to a home test init message, the correspondent node replies with a home test message, which contains a home keygen token and a home nonce index. Similarly, in response to the care-of test init message, the correspondent node replies with a care-of test message that contains a care-of keygen token and a care-of nonce index. Once the mobile node receives both the home and care-of test messages, the RR test is complete. The mobile node uses the home and care-of keygen tokens to generate a message authentication code (MAC), which is sent with a binding update message to assure the correspondent node that the message is from the mobile node that received both the home test and care-of test messages, i.e., the claimed care-of address and home address belong to the same mobile node. Then, the mobile node can send the binding update directly to the correspondent node (i.e., not via the home agent). Upon processing the binding update message, the correspondent node creates an entry in the Binding Update Cache to record the mobile node s information, such as the home address, care-of address, and the lifetime of the binding. The cache entry is used to process the incoming packets with the home address destination option, as well as to use a type 2 routing header to route the outgoing packets directly to the mobile node s care-of address. Similarly, the mobile node creates an entry for the correspondent node in the Binding Update List to record the tokens and other authentication data as well as the lifetime of the binding. The mobile node uses the entry while sending packets with the home address destination option to the correspondent node. From this information, it is clear that the correspondent registration, including an RR test, takes at least 1.5 times the RTT between the mobile node and the correspondent node Handover Operation in MIPv6 The MIPv6 IP-layer handover operation includes a series of tasks: movement detection, care-of address configuration, home agent binding update, and correspondent binding update. A mobile node detects that it has moved out of the coverage of an IP subnet by not getting router advertisements during an advertisement time interval from the access router of that subnet. The mobile node then searches for a new access router in the newly visited network. After getting a subnet prefix in the newly received router advertisement, the mobile node configures its new care-of address, and registers the address with the home agent and correspondent nodes. The home agent registration operation includes simply sending a binding update message containing the new care-of address to the home agent, whereas the correspondent registration requires performing an RR test prior to sending the binding update message. As the correspondent registration with an RR test takes at least 1.5 x RTT, the handover delay may exceed the tolerable limit of real time services. In this paper, we therefore present an extended correspondent registration scheme for reducing the handover latency in the MIPv6 networks.

3 0 15 A H L K M Reserved Sequence number # Lifetime Figure 2. Fast binding update message. 3. Operation of the Proposed Scheme To solve the problem of long handover latency due to the correspondent registration procedure of the MIPv6 protocol, we modified only the correspondent binding update operation performed by the mobile node during a handover. That is, this scheme leaves the home agent registration as well as the correspondent registration executed in other cases, such as when receiving tunneled packets via the home agent, untouched from the current MIPv6 standard. As the mobile node happens to be in active communication with the correspondent node before (and during) a handover, it is logical to assume that mobile node has already performed the correspondent registration using its previous care-of address, possibly when it first received the tunneled packets via its home agent. In the course of the registration, the mobile node and the correspondent node have maintained a record of each other in the Binding Update List and the Binding Update Cache, respectively. These records include the authentication information, among other fields. During handover, when the mobile node leaves the previous network and enters the realm of a new network, it configures a new care-of address using the advertised network-prefix of the new network. The mobile node then provisionally updates the correspondent node on its new care-of address by sending a fast binding update message (without performing an RR test). For this temporary update, the mobile node uses the authentication information stored in the Binding Update List created by the previous registration, thus reducing the impact of the time taken by an RR test on the handover latency. The temporary registration during a handover takes only 0.5 RTT, instead of 1.5 RTT in normal registration. However, to improve the security provisions, as soon as the handover is complete and the packets starts coming from the new access network, the mobile node validates the temporary updates of its record at the correspondent node by performing an RR test using its new care-of address and then sending a normal binding update message containing the newly received authentication information (via the RR test). The format of the fast binding update message is shown in Fig. 2. The changed portions of the message appear in bold font, i.e., a flag bit M and the mobility options. We added the new flag bit M to inform the correspondent node that the mobile node has used the previously received tokens to generate the MAC for the new binding update message. The mobility options include the following options. (1) Nonce indices option to carry the home and care-of nonce indices; (2) Message authentication data option to carry the MAC (massage authentication code); (3) Alternate care-of address option to carry the new care-of address; (4) Previous care-of address option to carry the previous care-of address. While the first three options are already available in MIPv6, the fourth option is a newly added one. The first and second options carry the information stored in the Binding Update List entry created by the previous binding update performed with the correspondent node. We added the fourth option to notify the previous care-of address to the correspondent node because we use the previous care-of address to generate the MAC, which the correspondent node uses to verify the source of the binding update message. Note that in a normal binding update, the new care-of address and the tokens received for that address from the correspondent node via the RR test are used to generate the MAC, whereas in our fast binding update, we use the previous care-of address and the corresponding tokens to generate the MAC. For the details of the MAC generating methods, we refer the reader to the RFC 3775 [3]. The binding update message is carried by the mobility header, an extension header defined for carrying MIPv6 signaling messages, of the IPv6 packet whose source address is the home address of the mobile node and destination address is the correspondent node s IPv6 address. The message is securely tunneled to the home agent using the IPSec security association existing between the mobile node and the home agent [1, 4]. The home agent decapsulates the message and forwards it to the correspondent node. When the correspondent node receives a fast binding message with an M flag bit set, it derives the care-of keygen token, and consequently the MAC, using the previous care-of address and the nonces whose indices are mentioned in the message. If the derived MAC is the same as that presented in the binding update message, the correspondent node temporarily updates the entry in the Binding Update Cache with the new care-of address. After the update, the correspondent node sends data packets to the new care-of address.

4 4. Security Consideration To ensure enough security in sending a fast binding update message, the following measures are taken. 1. The fast binding update message from a mobile node is always securely tunneled via the home agent. That is, a correspondent node accepts the fast binding update message with an M bit set only when the source address of the message is the home address of the mobile node. In case the home agent processes only the reverse tunneled packets coming from authenticated mobile nodes, the problem of fraudulent binding update messages being sent by other malicious nodes is mitigated. As in MIPv6, a node from other subnets cannot directly send a fast binding update message using the mobile node s home address as its own address because of the ingress filtering [2]. 2. The correspondent node accepts a fast binding update message only when an entry for the mobile node already exists in the Binding Update Cache. That means our scheme prevents other nodes from sending a fast binding update message before the mobile node actually performs it. 3. To improve the security level, the mobile node uses the authentication token received for the previous care-of address only once and for a very short time. That is, as soon as it completes a handover, the mobile node performs an RR test to get new tokens. It next uses these tokens in a normal binding update message to validate the temporary binding at the correspondent node created by the fast binding update message. 5. Extension to Multihomed Mobile Nodes Our scheme can easily be extended to multihomed mobile nodes by slightly modifying some messages to carry additional information. To explain the operation of the extended scheme, we use a multihomed mobile node equipped with heterogeneous interfaces, such as a Wireless LAN, WiMAX, and 3G. In an overlapped network environment, each of these interfaces may have an association with a network, which can provide the mobile node with a care-of address for the interface. Although the mobile node uses only one interface at a time to communicate with a correspondent node, it may initiate, in advance, a safe registration process for the care-of addresses associated with all the interfaces so that it can switch interfaces in a short period of time, when the network serving an ongoing communication session becomes unavailable or sub-optimal. To make a correspondent registration for multiple careof addresses feasible, we extended the RR test operation 0 15 M Reserved Care-of Init Cookie (a) Modified Care-of Test Init message (b) Other Care-of Address option Type Other Care-of Address Length Figure 3. Modified care-of test init message Care-of Nonce Index Care-of Init Cookie Care-of Keygen Token (a) Modified Care-of Test message Type Other Care-of Keygen Token (b) Other Care-of Keygen Token option Length Figure 4. Modified care-of test message. so that a care-of test init and care-of test messages could carry many care-of addresses and care-of keygen tokens in a single message. The formats of the modified messages are shown in Figs. 3 and 4. As before, the modified parts appear in bold font. In Fig. 3(a), the flag M indicates that the care-of test init message includes many care-of addresses. The default or current care-of address is indicated by the source address of the message, while the other addresses are mentioned in a new mobility option called the Other Careof Address option. The format of the new option is shown in Fig. 3(b), which is similar to the Alternate Care-of Address option of the binding update message of MIPv6. Since an Other Care-of Address option carries only one care-of address, a care-of test message can have many such options to carry many care-of addresses in a single message. Upon receiving such a care-of test init message, a correspondent node generates keygen tokens for each care-of address by using the same algorithm used in MIPv6 and forwards these tokens to the mobile node in a modified care-of test message. The modified care-of test message, as shown in Fig. 4(a), also includes a new option called the Other Care-of Keygen Token option. As shown in Fig. 4(b), this option carries a care-of keygen token corresponding to a care-of address that appeared in the Other Care-of Address

5 option of the care-of test init message. That is, there will be as many Other Keygen Token options in the care-of test message as there are Other Care-of Address options in the care-of test init message. Upon receiving such a care-of test message, the mobile node stores the care-of addresses and corresponding tokens in the Binding Update List. When the mobile node performs a vertical handover from one network to another, it uses the tokens from the list that correspond to the care-of address configured from the new network to generate an MAC. The mobile node includes the MAC in the binding update message and sends the message to the correspondent node to update the Binding Update Cache maintained by the correspondent node. In this way, the correspondent registration during a handover does not need an RR test, thus reducing the handover delay. After the registration, the correspondent node sends data packets to the mobile node via the new network. 6. Conclusion We presented a fast correspondent registration scheme to reduce the handover delay in Mobile IPv6 networks. Our scheme modified some of the signaling messages and operations of the Mobile IPv6 protocol to expedite the binding update during a handover. We also presented an extension of the scheme to multihomed mobile nodes that have heterogeneous interfaces. This work is still in progress. In future work, we will evaluate the scheme by mathematical modeling and simulations. We will analyze the scheme from different aspects, such as session arrival rate, traffic type, packet arrival rate, and node mobility rate. We will further extend the scheme to mobile routers to attain a low latency handover in network mobility (NEMO) supporting systems. References [1] J. Arkko, V. Devarapalli, and F. Dupont. Using IPsec to protect Mobile IPv6 signaling between mobile nodes and home agents. IETF RFC 3776, June [2] P. Ferguson and D. Senie. Network Ingress Filtering. IETF RFC 2267, January [3] D. Johnson, C. Perkins, and J. Arkko. Mobility support in IPv6. IETF RFC 3775, June [4] S. Kent and R. Atkinson. Security architecture for the Internet protocol. IETF RFC 2401, November [5] R. Koodli. Fast handovers for mobile IPv6. IETF RFC 4068, July [6] H. Soliman, C. Catellucia, K. Malki, and L. Bellier. Hierarchical Mobile IPv6 mobility management (HMIPv6). IETF RFC 4140, August 2005.