Mobopts Working Group F. Zhao Internet-Draft S F. Wu Expires: January 12, 2006 UC Davis J. Zhou Institute for Infocomm Research S. Jung Soongsil University July 11, 2005 Improvement on Security and Performance of MIP6 Return Routability Test draft-zhao-mobopts-rr-ext-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on January 12, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract In this draft, we propose several extensions to improve the security and performance of MIP6 Return Routability test. Our proposal enables CN and MN to promptly and reliably detect the on-path attack and reduce the signaling overhead in a secure, efficient and back- Zhao, et al. Expires January 12, 2006 [Page 1] Internet-Draft MIP6 RR Extensions July 2005 compatible way. The core idea is to use hash chain to replace home test procedure in some circumstances and we carefully integrate hash chain into original MIP6 RR test without introducing new vulnerabilities. Although it does slightly increase the management cost of CN, we show that the extended RR test is more secure and more efficient than other approaches. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Analysis of MIP6 Return Routability Test . . . . . . . . . . . 5 2.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.2 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.2.1 Statelessness . . . . . . . . . . . . . . . . . . . . 6 2.2.2 Longer routing path of home test message . . . . . . . 6 2.2.3 High susceptibility to home network failure . . . . . 6 3. Idea, contributions, notations and acronyms . . . . . . . . . 7 3.1 One-way hash chain . . . . . . . . . . . . . . . . . . . . 7 3.2 Motivations and contributions . . . . . . . . . . . . . . 8 3.2.1 Security improvement . . . . . . . . . . . . . . . . . 8 3.2.2 Reducing the signaling overhead . . . . . . . . . . . 8 3.3 Notations and acronyms . . . . . . . . . . . . . . . . . . 9 4. Hash-chain based detection mechanism . . . . . . . . . . . . . 10 4.1 Proposal . . . . . . . . . . . . . . . . . . . . . . . . . 10 4.2 CN operations . . . . . . . . . . . . . . . . . . . . . . 11 4.3 MN operations . . . . . . . . . . . . . . . . . . . . . . 12 4.4 Hash chains for both MN and CN . . . . . . . . . . . . . . 12 4.5 Hash Chain Management . . . . . . . . . . . . . . . . . . 13 4.6 Security analysis . . . . . . . . . . . . . . . . . . . . 13 4.7 Summary and future works . . . . . . . . . . . . . . . . . 15 5. Reducing signaling overhead . . . . . . . . . . . . . . . . . 17 5.1 With CoTi/CoT message . . . . . . . . . . . . . . . . . . 17 5.2 With Binding Refresh message . . . . . . . . . . . . . . . 18 5.3 Security analysis . . . . . . . . . . . . . . . . . . . . 19 5.3.1 Partial control on the MN-CN path . . . . . . . . . . 19 5.3.2 Full control on the MN-CN path . . . . . . . . . . . . 20 5.3.3 Future address stealing attack . . . . . . . . . . . . 20 5.4 Summary . . . . . . . . . . . . . . . . . . . . . . . . . 20 6. Related works . . . . . . . . . . . . . . . . . . . . . . . . 22 7. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 23 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 24 Intellectual Property and Copyright Statements . . . . . . . . 26 Zhao, et al. Expires January 12, 2006 [Page 2] Internet-Draft MIP6 RR Extensions July 2005 1. Introduction The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted as described in RFC2119 [1]. With the proliferation of mobile networking devices, the Internet is undergoing the most dramatic change ever since it was born. Mobility provides the convenience, improves the productivity and changes our life fundamentally. It is desired that communication sessions seamlessly continue during the movement. However, under the original TCP/IP protocol suite, IP address serves as both locator and identity, which inevitably causes the existing upper layer connections to be disrupted when the node changes its point of attachment to the Internet. IETF MIP6 working group has developed RFC 3775 to support mobility in IPv6 network by identifying each mobile node with a relatively permanent home address and addressing the same node with a care-of address acquired during its movement. The former allows a mobile node to be always reachable, however, through a longer routing path when it is away from the home network while the latter allows a mobile node to be reachable at its current location without passing through home network, which is referred to as Route Optimization mode in MIP6 protocol. However without the careful design, MIP6 Route Optimization support could introduce various forms of new vulnerabilities, e.g. stealing attack and flooding attack etc [4]. RFC 3775 designs the Return Routability (RR) Test, a lightweight and infrastructure-less authentication mechanism, to resist most attacks without requiring the existence of security association between Mobile Node (MN) and Correspondent Node (CN), which ensures the universal deployment of route optimization. The RR test still leaves a lot to be desired. Firstly, it is vulnerable to on-path attackers and the current standard does not protect MN and CN further from the incurred attacks. Secondly, the signaling overhead poses challenges to resource-constrained mobile node and bandwidth-scarce wireless network given the short lifetime of Binding Cache Entry (at most seven minutes) even though MN does not change its location since the last Binding Update with CN. Thirdly the signaling delay caused by the RR test increases the handover delay, which may degrade the performance of delay-sensitive applications, such as VoIP. This draft focuses on the first two issues currently. We propose Zhao, et al. Expires January 12, 2006 [Page 3] Internet-Draft MIP6 RR Extensions July 2005 several extensions to enable CN and MN to promptly detect the on-path attack and reduce the signaling overhead. The RR test related signaling latency during handover will be addressed in a future version. The rest of the draft is organized as follows. In Section 2, we analyze the MIP6 RR test with emphasis on the disadvantages of the current approach. Section 3 summarizes our idea, motivations, contributions and notations as well as acronyms. We present a hash chain based detection mechanism to improve the security of MIP6 RR test and another approach to reduce the signaling overhead in Section 4 and Section 5, respectively. The related works are summarized in Section 6 and finally the whole draft is concluded in Section 7. Zhao, et al. Expires January 12, 2006 [Page 4] Internet-Draft MIP6 RR Extensions July 2005 2. Analysis of MIP6 Return Routability Test In this section, we briefly review and analyze the MIP6 RR test. The detailed specification of MIP6 RR test can be found in RFC 3775. 2.1 Overview Route Optimization in MIP6 requires that MN inform the binding between its identity and its location to CN and CN verify the correctness of the binding information received in a secure and efficient way. All must be achieved without the pre-existing security association between MN and CN. This poses two questions to CN when it receives the binding information: 1) How can CN ensure that MN is at the location it currently claims? 2) How can CN ensure that the information is from a legitimate MN rather than a malicious third party? MIP6 RR test addresses the first question by care-of address test. By sending a care-of keygen token to MN's care-of address and verifying whether MN receives it successfully later, CN can ensure that either MN is really at the care-of address it claims, or there is another entity communicating with CN on the path between CN and the care-of address MN claims. The second question requires MN authenticate itself to CN during the Correspondent Binding Update procedure. Given the unavailability of pre-existing security association between MN and CN (or any other form of global trust relationship, e.g. PKI), MIP6 RR test adopts home address test for CN to verify whether MN is reachable at its home address by sending a home keygen token to MN's home address and verifying whether MN receives it successfully later. Because home address serves as an identity of MN, by presenting the proof that MN can be reachable at home address, MN can authenticate itself to CN. Please note that the signaling messages during home address test are protected by the pre-existing security association between MN and its HA, but are not protected when on the path between HA and CN. Thus given a successful home address test, CN can ensure it is communicating with either MN or another entity on the path between CN and MN's home network. As a stateless and lightweight approach, address test leaves the MIP6 Route Optimization mechanism vulnerable to those launched by on-path attacker. The design goal of MIP6 Route Optimization is to achieve the same security level in MIP6 network as the normal IPv6 network. Zhao, et al. Expires January 12, 2006 [Page 5] Internet-Draft MIP6 RR Extensions July 2005 2.2 Analysis 2.2.1 Statelessness MIP6 RR test is designed to be stateless in that each round of RR test is independent from each other. While the statelessness feature enables CN to have minimal management of Binding Cache entry, MN has to re-run the complete MIP6 RR test procedure once the Binding Cache expires every several minutes (at most seven minutes). There are two consequences: 1) Since MN keeps repeating the same message exchanges with CN every time without utilizing the states previously successfully established at CN even a little bit, the signaling overhead caused may prove to be a significant cost to resource- constrained mobile devices and bandwidth-limited wireless network. 2) The stateless feature makes CN unable to detect the on-path attack as CN just simply verifies the received Binding Update message without comparing with the previously established state, which makes MIP6 network slightly less secure than the normal IPv6 network. Please note less statelessness does not necessarily cause the vulnerability to state-exhaustion attack. Actually they are two different issues. To avoid the state-exhaustion attack we should postpone the establishment of new states until the correct point during the message exchanges while to make MIP6 RR test less stateless means to explore the previously successfully established states and the risk of state-exhaustion attack is expected to be taken care of during each round of RR test. 2.2.2 Longer routing path of home test message In MIP6 RR test, home address test involves forwarding the message between MN and CN via MN's home network (in short, HA in the following) always, which results in a longer route taken by the home address test message than that by the care-of test message. The longer delay caused by home address test procedure may degrade the application performance when MN starts the Route Optimization with CN. 2.2.3 High susceptibility to home network failure Another side effect of home address test is that NEMO Route Optimization is highly susceptible to home network failure. Thus when the home network is down or just congested, MN may have difficulty to communicate with CN even though there is an available route path between MN and CN. Zhao, et al. Expires January 12, 2006 [Page 6] Internet-Draft MIP6 RR Extensions July 2005 3. Idea, contributions, notations and acronyms In order to address the limitations of MIP6 RR test analyzed in the previous section, one has to turn to an alternative approach for CN to verify that MN actually legitimately owns the claimed home address securely, efficiently and reliably. To this end, we propose to use hash chain to replace the need of home address test in some circumstances. This section firstly describes the hash chain, the core mechanism we use in this draft, and then summarizes our motivations and contributions of this draft. Finally we introduce the notations and acronyms used in this draft for the ease of description. 3.1 One-way hash chain Hash chain is a widely used security primitive, for example, one-time password protocol, multicast authentication mechanism [8] and secure routing protocols. Assume that one wants to generate a hash chain of length k+1. It generates a random number h_k firstly and then repeatedly applies the one-way hash function, H, for example, h_k- 1=H(h_k), h_k-2=H(h_k-1), ... , h_0=H(h_1). When needed, the elements in the chain are revealed in the order of h_0, h_1, ... , h_k. One-way hash chain has the following properties: 1) Due to the irreversibility of one-way hash function, even though the attacker eavesdrops h_i, it is still cryptographically impossible for it to derive h_j from h_i where j>i. This property guarantees that once the initial hash element h_0 is committed, no one other than the original generator can provide a valid and fresh hash chain element unless by eavesdropping or interception. Thus it provides a certain level of identity authentication. 2) On the contrary, anyone can easily confirm that h_j is part of the chain if h_i=H(h_j)^(j-i) where j>i. Compared with other cryptography primitive, hash operation is much cheaper and faster, which reduces the risk of being Denial-of-Service attacked. 3) One can create the chain all at once and store each element of the chain, or just store h_k together with the sequence number of the next element in the chain and generate the element on demand (Thanks to the fast hash operation). There exist other approaches that can help reduce storage cost with a small computation penalty. (It is possible to use log(k) storage and log(k) computation to access an element.) The development of technology is also expected to meet the increasing requirement of battery and memory for MN to maintain such kind of one-way hash chain. Zhao, et al. Expires January 12, 2006 [Page 7] Internet-Draft MIP6 RR Extensions July 2005 3.2 Motivations and contributions 3.2.1 Security improvement Although MIP6 RR test effectively limits the successful attackers to those that are able to access the critical path, MIP6 network is still a little bit less secure than IPv6 network. For example, an attacker that is able to only eavesdrop on the HA-CN path can eventually intercept thus completely control the traffic between MN and CN. MIP6 RR test does not provide any further protection against those "powerful" attackers, thus MN and CN cannot take any prompt and appropriate response to recover from the attacks if possible or reduce the damage as much as possible. For example, MN/CN can detect the disruption of the communication only by observing the traffic characteristics. (The disruption/redirection attack may be indicated by the time-out signal; however, MN/CN has to wait the timer to expire.) Moreover, since MN/CN does not know the root-cause of the anomaly, MN/CN may have to retry for several times before deciding whether there is an attack or link failure and what response to take, switching to bidirectional tunneling mode or just giving up. In summary, this kind of heuristic method is slow. Another important issue is that a detection method must avoid "false positive" and "false negative" even with various types of attack symptoms and dynamic traffic characteristics observed especially when MN moves around. Here we call a "false positive" if it is reported as an attack but actually not; Similarly, we call a "false negative" if there is an attack but not detected. In this draft, we propose an efficient and effective detection mechanism for both CN and MN to promptly, accurately and reliably detect attacks that could compromise the security of MIP6 RR test and thus let CN and MN take the appropriate response to mitigate and recover from attacks. For example, CN may send the packets to the home address, and thus MN can receive the traffic forwarded by HA, which follows a non-optimal route but is still better than the disruption of communication (100% packet loss). 3.2.2 Reducing the signaling overhead In RFC 3775 the lifetime of Binding Cache Entry (and nonce, token etc.) is limited to a few minutes, which requires MN to repeat MIP6 RR test procedure every several minutes even if MN does not change its location since last successful Binding Update with CN. While it is necessary to mitigate some kinds of attacks, such as future address stealing attack and time shifting attack, it does cause a lot Zhao, et al. Expires January 12, 2006 [Page 8] Internet-Draft MIP6 RR Extensions July 2005 of signaling overheads, which could become a big burden to resource- constrained mobile nodes and the bandwidth-scarce wireless network. There could be two different ways to reduce the signaling overhead, one is to extend the lifetime of Binding Cache entry; the other is to reduce the number of signaling messages needed. The first method is not acceptable, as it will increase the security risks. In this draft, we focus on the latter method especially when MN does not change its location since the last Binding Update to CN. Our approach is to use hash chain to eliminate the necessity of Home Test procedure but still provides the same security protection as before. 3.3 Notations and acronyms Throughout this draft, the following notations and acronyms are used: CoA: the care-of IP address of MN HoA: the home address of MN CNA: the IP address of CN BU: Binding Update message BA: Binding Acknowledgement message Kbm: the Binding Management key S_MN: the sequence number of the current element in MN's one-way hash chain H_MN(S_MN): the current element in MN's one-way hash chain S_CN: the sequence number of the current element in CN's one-way hash chain H_CN(S_CN): the current element in CN's one-way hash chain N: the largest number of retries if MN or CN does not receive the reply within a certain time period M: the largest number of hash functions that MN or CN is willing to perform, usually M > N Zhao, et al. Expires January 12, 2006 [Page 9] Internet-Draft MIP6 RR Extensions July 2005 4. Hash-chain based detection mechanism MIP6 RR test is vulnerable to the attackers that are able to access certain critical paths. Although it is difficult to completely resist those powerful attackers (The inter-domain coordination might be needed eventually.), we propose a simple but effective detection mechanism to enable CN and MN to detect the attack promptly and then take the appropriate response. The rationale is as follows: CN is in the best position to detect the attack attempts because in order for the attacks (e.g. DoS flooding attack and redirection attack) to succeed, the attacker must change the state stored in CN. Therefore the idea is that in order for CN to accept a new Binding Update, either a valid MN or an attacker must provide the cryptographically sound proof of the previous successful Binding Update to CN if any. If the correctness of this proof cannot be verified by CN, CN may disable the relevant Binding Cache entry and forward the data packet to its home address instead. 4.1 Proposal MN generates a hash chain for each pair of so that MN can use multiple HoAs to communicate with different CNs. The primary differences from the original MIP6 RR test are that the current hash chain element generated by MN is included in the BU message and CN extends the Binding Cache entry with two fields to store the current element in MN's hash chain and the corresponding sequence number. MN generates the BU message as follows and sends it to CN. BU: o Source IP address: CoA o Destination IP address: CNA o {HoA | S_MN | home_nonce_index | careof_nonce_index | H_MN(S_MN) | MAC} o MAC = HMACSHA1(Kbm, (CoA | CNA | BU)) If MN requests the Binding Acknowledgement, CN generates the BA message based on the verification result. BA: o Source IP address: CNA Zhao, et al. Expires January 12, 2006 [Page 10] Internet-Draft MIP6 RR Extensions July 2005 o Destination IP address: CoA o {S_MN | MAC} o MAC = HMACSHA1(Kbm, (CoA | CNA | BA)) 4.2 CN operations When CN receives the BU message, CN firstly generates Kbm and then verifies the MAC. If the result is positive, CN performs the following procedure to verify the newly received hash chain element, H_MN(S_MN): 1. CN searches the Binding Cache by using MN's HoA as the primary key. 2. If it does not exist, CN accepts the BU message and creates a new Binding Cache entry and forwards the data packets destined to this HoA based on MIP6 RO protocol. 3. If it does exist, CN verifies H_MN(S_MN) received in the BU message with the old hash chain element, H_MN(S_MN') stored in the Binding Cache as follows: * If S_MN' >= S_MN, CN discards this BU message because it is a replayed message. * If S_MN' < S_MN <= S_MN'+M and H_MN(S_MN') == H_MN(S_MN)^(S_MN-S_MN'), CN believes this BU message is valid, thus it updates the Binding Cache Entry with S_MN and H_MN(S_MN) and then sends the BA message if requested. * If S_MN' < S_MN <= S_MN'+M and H_MN(S_MN') <> H_MN(S_MN)^(S_MN-S_MN'), CN realizes that there is an attacker that can successfully finish the RR test; however, CN is not sure whether the currently received BU message is from the attacker or a valid MN. Thus CN disables this entry, indicates the reason in the BA message if requested and forwards the data packets to the home address. CN's local policy may decide to accept the new BU message for this HoA later again or not, for example, after either the current session is ended or a certain time period. * If S_MN'+M < S_MN, CN realizes that the number of hash computation needed is too large, in order to avoid the DoS attack, CN disables this entry, indicates the reason in the BA message if requested and forwards the data packets to the home Zhao, et al. Expires January 12, 2006 [Page 11] Internet-Draft MIP6 RR Extensions July 2005 address. CN's local policy may regulate whether to refuse accepting the Route Optimization operation from this HoA forever or to freeze for a certain time period after which it may start to accept the new BU message for this HoA again. 4.3 MN operations When MN does not receive the BA message within a certain time period, MN may retry to send the BU message in case that the previous BU message is dropped due to the network congestion. However, MN must use a new hash chain element in this new BU message in order to invalidate the old hash chain element because an attacker could intercept it for the future attack. BU: o Source IP address: CoA o Destination IP address: CNA o {HoA | S_MN+1| home_nonce_index | careof_nonce_index | H_MN(S_MN+1) | MAC} o MAC = HMACSHA1(Kbm, (CoA | CNA | BU)) Please note that if MN cannot receive the BA message after retrying for N times, MN should switch to the Bidirectional tunneling mode. 4.4 Hash chains for both MN and CN CN may also use hash chain for MN to authenticate the origin and freshness of BA message. CN may generate a pool of hash chains proactively, and then randomly select one for the signaling between MN and CN after successfully verifying the BU message from MN. MN or CN may communicate with multiple nodes and thus simultaneously maintain multiple hash chains, each of which can be uniquely identified by a pair of home address of MN and IP address of CN, i.e. . Except that the BU and BA messages are extended to include the first hash chain elements, H_MN(S_MN) and H_CN(S_CN), other messages are still as same as in RFC 3775. MN sends the BU message as follows: BU: o Source IP address: CoA Zhao, et al. Expires January 12, 2006 [Page 12] Internet-Draft MIP6 RR Extensions July 2005 o Destination IP address: CNA o {HoA | S_MN | home_nonce_index | careof_nonce_index | H_MN(S_MN) | MAC} o MAC = HMACSHA1(Kbm, (CoA | CNA | BU)) When CN receives and verifies the BU message successfully, CN will record S_MN as well as H_MN(S_MN) and reply with the following BA message if requested. BA: o Source IP address: CNA o Destination IP address: CoA o {S_CN | H_CN(S_CN) | MAC} o MAC = HMACSHA1(Kbm, (CoA | CNA | BA)) When MN receives and verifies the BA message successfully, MN will record S_CN and H_CN(S_CN). 4.5 Hash Chain Management The hash chain can be depleted after a long time use. MN can start a new hash chain with CN by sending the last element in the old hash chain together with the first element in the new hash chain in the BU message. Hash chain should not be lost due to the reboot of CN or MN. While it is not a big problem for CN as it is just a fresh start, it is better for MN to store the hash chain in the safe hardware so that the synchronization between MN and CN can be restored. CN must verify the hash chain element in the BU message even if S_MN is not consecutive in order to recover from the BU packet loss due to the network congestion. However in order to prevent DoS attack the difference between the new S_MN and the old S_MN should not be more than M. 4.6 Security analysis Our approach inherits all the underlying assumptions of the original MIP6 RR test, for example, no infrastructure support, pre-existing SA between MN and HA but no pre-existing SA between MN and CN or between HA and CN, no ingress filtering and compliant HA and CN. Zhao, et al. Expires January 12, 2006 [Page 13] Internet-Draft MIP6 RR Extensions July 2005 The successful detection of attack depends on the successful commitment of the first hash element. The security of the first time Binding Update procedure still depends on the diverse routing paths and IP address test, however the use of hash chain still provides an additional level of protection. In the following we compare the security strength of the original RR test and the extended RR test given the different powers of attacker. We categorize the power of attackers into two categories: Full control: the attacker can intercept, drop and of course eavesdrop the traffic passing by. For example, the attacker controls a router in the Internet. Partial control: the attacker can only eavesdrop the traffic that can finally arrive at the intended destination successfully. The attacker could have different powers on the different paths. Moreover, the attacker could move from one path to the other; or it could have a conspirator on the other path; or these two paths are kind of overlapping with each other and the attacker is attached to the common part of these two paths. o Partial control on HA-CN path only: * Orignal RR test: The attacker can have full control of the traffic. * Extended RR test: Detected. The attacker still has the partial control only. o Partial control on MN-CN path only: * Orignal RR test: The attacker cannot have full control of the traffic. * Extended RR test: The attacker cannot have full control of the traffic. o Partial control on both HA-CN and MN-CN: * Orignal RR test: The attacker can have full control of the traffic. * Extended RR test: Detected, The attacker still has the partial control only. (The spoofed BA message can be detected if CN's hash chain is used.) Zhao, et al. Expires January 12, 2006 [Page 14] Internet-Draft MIP6 RR Extensions July 2005 o Full control on HA-CN path only: * Orignal RR test: The attacker can have full control of the traffic. * Extended RR test: Detected. But the attacker still has full control of traffic if CN sends to MN's home address. o Full control on MN-CN path only: * Orignal RR test: The attacker already has full control of the traffic as long as MN runs in the RO mode. * Extended RR test: The attacker already has full control of the traffic as long as MN runs in the RO mode. But any modification can be detected. o Full control on both HA-CN and MN-CN path: * Orignal RR test: The security of MIP6 RR test cannot be held due to the power of attacker. * Extended RR test: The security of MIP6 extended RR test cannot be held due to the power of attacker. o Partial control on the HA-CN path and full control on the MN-CN path: * Orignal RR test: The attacker can have full control of the traffic. * Extended RR test: The spoofed BA message cannot be detected. The attacker can have full control of the traffic temporally. MN may recover from the attack after retries. o Partial control on the MN-CN path and full control on the HA-CN path: * Orignal RR test: The attacker can have full control of the traffic. * Extended RR test: Detected. The attacker has full control of traffic if CN sends to HoA. 4.7 Summary and future works This hash chain based detection mechanism can be combined with other Zhao, et al. Expires January 12, 2006 [Page 15] Internet-Draft MIP6 RR Extensions July 2005 network diagnosis mechanisms to further discover the location of attacker, and then other kind of mechanisms, e.g. source routing, can be triggered to bypass that path. Moreover the state machine of MN and CN operations will be made later. While Section 5 presents an approach for MN to promptly renew its Binding Cache entry when it does not change its location, the extended RR test introduced in this section can be used in any situation, especially when MN changes its location since the last Binding Update with CN. Zhao, et al. Expires January 12, 2006 [Page 16] Internet-Draft MIP6 RR Extensions July 2005 5. Reducing signaling overhead In this section, we propose some extensions to improve the performance of the MIP6 RR test by reducing the signaling overhead when MN renews its Binding Cache entry at the same location. Our idea is to use hash chain to remove the necessity of Home Test procedure. 5.1 With CoTi/CoT message When the Binding Cache entry is close to expiration, MN uses the following simplified RR test if it does not change its location since last Binding Update to CN. MN HA CN | | | | CoTi | |-------------------------------------------------------->| | CoT | |<--------------------------------------------------------| | BU | |-------------------------------------------------------->| | BA | |<--------------------------------------------------------| Figure 1: With CoTi/CoT message The CoTi and CoT messages are the same as those in the original MIP6 RR test and are used to test whether MN is at the claimed location. Assume that the current sequence number and hash chain element are S_MN and H_MN(S_MN) in MN's hash chain and S_CN and H_CN(S_CN) in CN's hash chain respectively. MN generates the BU message as follows: BU: o Source IP address: CoA o Destination IP address: CNA o {HoA | S_MN | H_MN(S_MN) | careof_nonce_index | care-of token} We include careof_nonce_index and care-of token in the BU message in order to verify whether MN can really receive the CoT message at the claimed location. When CN receives the BU message, CN firstly verifies that care-of Zhao, et al. Expires January 12, 2006 [Page 17] Internet-Draft MIP6 RR Extensions July 2005 token is valid. If successful, CN looks up Binding Cache by HoA. If found, CN verifies whether the current CoA in the Binding Cache entry is the same as the source IP address of BU message. If not, CN replies with a negative reply. Otherwise, CN verifies H_MN(S_MN) and updates the corresponding Binding Cache entry if successful and then generates the following BA message to MN. BA: o Source IP address: CNA o Destination IP address: CoA o {S_CN | H_CN(S_CN) | MAC} o MAC = HMACSHA1(H_MN(S_MN), H_CN(S_CN)) MN now verifies whether MAC is indeed generated from H_MN(S_MN) and H_CN(S_CN). If correct, MN verifies H_CN(S_CN) by comparing with the old hash chain element from CN. If successful, MN updates its records with a new H_CN(S_CN) and S_CN. The integrity of BA message is weakly protected by H_CN(S_CN), which provides the limited protection against that kind of attacker that just moves onto the MN-CN path after MN sends the BU message. However it does not resist the attacker on the MN-CN path generally. 5.2 With Binding Refresh message MN HA CN | | | | Binding Refresh Request message | |<--------------------------------------------------------| | BU | |-------------------------------------------------------->| | BA | |<--------------------------------------------------------| Figure 2: With Binding Refresh message The Binding Refresh Request message could serve as the same purpose as CoT message. We extend the Binding Refresh Request message with the mobility options of careof_nonce_index | care-of token. Binding Refresh Request message: o Source IP address: CNA Zhao, et al. Expires January 12, 2006 [Page 18] Internet-Draft MIP6 RR Extensions July 2005 o Destination IP address: CoA o {careof_nonce_index | care-of token} o care-of token = HMACSHA1 (Kcn, (CoA | HoA | nonce | 1))) BU: o Source IP address: CoA o Destination IP address: CNA o {HoA | S_MN | H_MN(S_MN) | careof_nonce_index | care-of token} CN first verifies care-of token is valid, then verifies H_MN(S_MN). If MN requests the BA message, CN will generate the following BA message and send it to MN. BA: o Source IP address: CNA o Destination IP address: CoA o {S_CN | H_CN(S_CN) | MAC } o MAC = HMACSHA1( H_CN(S_CN), (CoA | CNA | H_MN(S_MN) | BA))) 5.3 Security analysis 5.3.1 Partial control on the MN-CN path If the BU message arrives at CN successfully, the attacker cannot replay the eavesdropped hash chain element later. If the BU message does not arrive at CN successfully, e.g. due to the network congestion, MN will resend the BU message with the current hash chain element after timeout. Please note that the attacker cannot make CN redirect the traffic to another location by presenting the eavesdropped hash chain element because source IP address must be the same as before. The attacker cannot forge the BA message from CN without providing a valid CN's hash chain element. Zhao, et al. Expires January 12, 2006 [Page 19] Internet-Draft MIP6 RR Extensions July 2005 5.3.2 Full control on the MN-CN path If the attacker modifies CoA in the BU message, CN can detect that CoA is different from before and thus drops the modified BU message. If the attacker modifies the hash chain element, CN cannot verify the modified hash chain element successfully and thus drops it. If the attacker drops the BU message, MN will retry with the same hash chain element for several times if the BA message is not received. It does not increase the knowledge of the attacker about the hash chain. The attacker can only reuse the intercepted hash chain element with the same CoA, however, it is exactly what MN wants to do. Thus the only meaningful attack happens when MN moves out from CoA after sending the BU message and before the current Binding Cache entry expires, which opens an extremely short window for the attacker. (Otherwise CN will disable the Binding Cache entry and the complete RR test has to be rerun, thus the intercepted hash chain element becomes invalid due to the new received hash chain element.) And it is only meaningful to the attacker that will move out from the MN-CN path as well because otherwise the flooding attack traffic goes through the attacker firstly and the attacker can always flood the location represented by CoA directly. If MN fails to renew the BCE after several retries, MN will send the traffic through HA and since CN receives the traffic through HA, CN may use it as a signal to redirect the traffic through HA. In summary the attacker does not get any little benefit from this. 5.3.3 Future address stealing attack Similar with that in RFC 3775, a malicious MN can still launch DoS flooding attack against its current location. For example, MN requests a long stream from CN and then moves to another location. This attack is mitigated by the lifetime of Binding Cache entry. Please note that MN cannot continue flooding the previous CoA because of the periodical CoA address test. 5.4 Summary Please note that the hash chain used here may be different from the one used in Section 4. MN may exchange the first element of this hash chain together with that of other hash chain in the Binding Update message with CN. Zhao, et al. Expires January 12, 2006 [Page 20] Internet-Draft MIP6 RR Extensions July 2005 Our approach reduces the signaling overhead and shortens the time of Binding Update procedure with CN by avoiding home address test message that usually passes through a longer route. Zhao, et al. Expires January 12, 2006 [Page 21] Internet-Draft MIP6 RR Extensions July 2005 6. Related works RFC 3775 [2] defines RR test in details. The rationale and background of this design are documented in [4] and a taxonomy and analysis of enhancements to Mobile IPv6 Route Optimization is presented in [5]. R. Deng, J. Zhou and F. Bao proposed a secure Binding Update protocol with strong security and good scalability in [7]. W. Haddad et al proposed to use Cryptographically Generated Addresses (CGA) to reduce signaling load and handoff delay in [11]. Another proposal of improvement of RR protocol can be found in [6]. C. Vogt proposed Early Binding Update (EBU) in [12] to reduce the handover latency related to the RR test and credit-based authorization in [13] with J. Arkko to mitigate the misuse of Early Binding Update. However EBU requires more signaling messages, e.g. proactive home address test message, and extra processing in CN, e.g. the credit calculation. C. Vogt and J. Arkko also proposed a credit- based mechanism to extend the lifetime of binding update in [14] as well. Part of our work is originally published in [15]. Probably the most similar works are [9][10]. In [9] J. Ylitalo et al proposed to use one-way hash chain and secret splitting to establish the trust between mobile nodes and middle boxes in micro-mobility while our proposal addresses the security and performance issues in a macro-mobility protocol, Mobile IPv6 protocol. In [10] V. Torvinen and J. Ylitalo independently proposed a security context establishment procedure by using reverse one-way hash chain and delayed authentication in mobility and multi-homing management while our work focuses on improving the security and performance of Mobile IPv6 RR test procedure in all scenarios and provides the comprehensive analysis of security and performance. Zhao, et al. Expires January 12, 2006 [Page 22] Internet-Draft MIP6 RR Extensions July 2005 7. Conclusion In this draft, we extended original MIP6 RR test by applying hash chain. Through the thorough analysis, we show it is a very promising approach to provide the stronger security and reduce signaling overhead. 8. References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [2] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [3] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to Protect Mobile IPv6 Signaling between Mobile Nodes and Home Agents", RFC 3776, June 2004. [4] Nikander, P., Arkko, J., Aura, T., Montenegro, G., and E. Nordmark, "Mobile IP version 6 Route Optimization Security Design Background", draft-ietf-mip6-ro-sec-02 (work in progress), October 2004. [5] Arkko, J. and C. Vogt, "A Taxonomy and Analysis of Enhancements to Mobile IPv6 Route Optimization", draft-arkko-mip6-ro-enhancements-00 (work in progress), October 2004. [6] Bao, F., Deng, R., and J. Zhou, "Improvement of Return Routability Protocol", draft-qiu-mip6-rr-improvement-00 (work in progress), August 2004. [7] Deng, R., Zhou, J., and F. Bao, "Defending against Redirect Attacks in Mobile IP", Proceedings of the 9th ACM Conference on Computer and Communications Security, pages 59--67, Washington, DC, November 2002. [8] Perrig, A., Canetti, R., Tygar, J D., and D. Song, "Efficient Authentication and Signing of Multicast Streams Over Lossy Channels", Proceedings of IEEE Symposium on Security and Privacy, 2000. [9] Ylitalo, J., Melen, J., Nikander, P., and V. Torvinen, "Re- thinking Security in IP based Micro-Mobility", Proceedings of the 7th Information Security Conference, Palo Alto, CA, USA, September 2004. Zhao, et al. Expires January 12, 2006 [Page 23] Internet-Draft MIP6 RR Extensions July 2005 [10] Torvinen, V. and J. Ylitalo, "Weak Context Establishment Procedure for Mobility Management and Multi-Homing", Proceedings of the 8th IFIP TC-6 TC-11 Conference on Communications and Multimedia Security, Windermere, GB, September 2004. [11] Haddad, W., Madour, L., Arkko, J., and F. Dupont, "Applying Cryptographically Generated Addresses to Optimize MIPv6 (CGA- OMIPv6)", draft-haddad-mip6-cga-omipv6-03 (work in progress), October 2004. [12] Vogt, C., "Early Binding Updates for Mobile IPv6", draft-vogt-mobopts-early-binding-updates-00 (work in progress), February 2005. [13] Vogt, C. and J. Arkko, "Credit-Based Authorization for Mobile IPv6 Early Binding Updates", draft-vogt-mobopts-credit-based-authorization-00 (work in progress), February 2005. [14] Arkko, J. and C. Vogt, "Credit-Based Authorization for Binding Lifetime Extension", draft-arkko-mipv6-binding-lifetime-extension (work in progress), May 2004. [15] Zhao, F., Wu, S F., and S. Jung, "Extensions on Return Routability Test in MIP6", draft-zhao-mip6-rr-ext-01 (work in progress), February 2005. Authors' Addresses Fan Zhao University of California, Davis One Shield Avenue Davis, CA 95616 US Phone: +1 530 752 3128 Email: fanzhao@ucdavis.edu Zhao, et al. Expires January 12, 2006 [Page 24] Internet-Draft MIP6 RR Extensions July 2005 S. Felix Wu University of California, Davis One Shield Avenue Davis, CA 95616 US Phone: +1 530 754 7070 Email: sfwu@ucdavis.edu Jianying Zhou Institute for Infocomm Research 21 Heng Mui Keng Terrace Singapore 119613 SG Phone: +65 6874 8543 Email: jyzhou@i2r.a-star.edu.sg Souhwan Jung Soongsil University 1-1, Sangdo-dong, Dongjak-ku Seoul 156-743 KOREA Phone: +82 2 820 0714 Email: souhwanj@ssu.ac.kr Zhao, et al. Expires January 12, 2006 [Page 25] Internet-Draft MIP6 RR Extensions July 2005 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Zhao, et al. Expires January 12, 2006 [Page 26]