MIP6 Working Group F. Zhao Internet-Draft S F. Wu Expires: August 25, 2005 UC Davis S. Jung Soongsil University February 21, 2005 Extensions on Return Routability Test in MIP6 draft-zhao-mip6-rr-ext-01 Status of this Memo This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. 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 become aware will be disclosed, in accordance with RFC 3668. 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 August 25, 2005. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This draft proposes some extensions to the Return Routability Test in MIP6 to address the location privacy issue and enable CN as well as MN to promptly detect the attack that could compromise the security of MIP6 RO mechanism. Zhao, et al. Expires August 25, 2005 [Page 1] Internet-Draft MIP6 RR Extensions February 2005 Table of Contents 1. Motivations . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Related Works . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.1 No infrastructure support . . . . . . . . . . . . . . . . 7 3.2 Pre-existing SA between MN and HA . . . . . . . . . . . . 7 3.3 No pre-existing SA between MN and CN or between HA and CN . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.4 No ingress filtering . . . . . . . . . . . . . . . . . . . 7 3.5 Unmalicious HA and CN . . . . . . . . . . . . . . . . . . 7 3.6 The power of the attacker . . . . . . . . . . . . . . . . 8 4. Proposal . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.1 Notations . . . . . . . . . . . . . . . . . . . . . . . . 9 4.2 Protecting the privacy of HoA in MIP6 RR test message without encryption . . . . . . . . . . . . . . . . . . . . 9 4.3 Protection of the HoA privacy in the BU message . . . . . 13 4.4 Extending the RR test with a detection mechanism . . . . . 14 4.5 Lengthening the lifetime of BCE . . . . . . . . . . . . . 16 4.6 Fast BU refreshment . . . . . . . . . . . . . . . . . . . 17 4.7 Non-repudiation . . . . . . . . . . . . . . . . . . . . . 18 5. Security consideration . . . . . . . . . . . . . . . . . . . . 19 5.1 The privacy of HoA . . . . . . . . . . . . . . . . . . . . 19 5.2 Denial-of-Service attack . . . . . . . . . . . . . . . . . 19 5.2.1 Decryption . . . . . . . . . . . . . . . . . . . . . . 19 5.2.2 Hash chain verification . . . . . . . . . . . . . . . 19 5.3 Prevention of traffic interception . . . . . . . . . . . . 19 5.4 Other attacks described in [7] . . . . . . . . . . . . . . 20 6. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 21 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 22 A. Return Routability Test on Network Prefix (RRNP) in NEMO . . . 23 Intellectual Property and Copyright Statements . . . . . . . . 24 Zhao, et al. Expires August 25, 2005 [Page 2] Internet-Draft MIP6 RR Extensions February 2005 1. Motivations 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]. MIP6 adopts Return Routability Test as a lightweight and infrastructure-less authentication mechanism to achieve a reasonable level of authentication between MN and CN even without pre-existing security association. Our motivations to propose some extensions to the original MIP6 RR test are as follows: 1) Location privacy Recently location privacy, especially in the mobile environment, attaches more and more attentions. Moreover, the core idea of MIP6 RR test can be used to enhance the security of NEMO Route Optimization protocol. Although NEMO RO solution is still under discussion, a potential approach is to enable MR to register its MNP(s) with CN/CR to achieve the optimal route just like the procedure of Binding Updates to correspondent nodes in MIP6. The privacy issue in NEMO, such as the privacy of MNP (Mobile Network Prefix), becomes even more serious. In this draft, we propose to postpone the disclosure of HoA as late as possible by using hash function and even make HoA invisible to the eavesdropper in the BU message to CN by using encryption. In MIP6 RR test, HoA is in the cleartext in the HoTi decapsulated and forwarded by HA, HoT and BU messages to CN, thus an eavesdropper can learn that MN is away from the home network and even MNÆs current location when combining with CoA. The location privacy can be protected by making either CoA (location) or HoA (identity) invisible to eavesdropper. In this draft we use the latter. However, we focus on the privacy issues only in the RR test related messages (thus in the IP layer), so the privacy issues of other messages, such as home BU message, prefix discovery message and data message, are out of scope of this draft. 2) Detection of attack The goal of the original MIP6 RR test is to make the MIP6 network as secure as the IPv6 network. However, in MIP6, an attacker that is able to only eavesdrop the traffic in the IPv6 network can effectively intercept the traffic between MN and CN, which makes the MIP6 network a little bit less secure than the IPv6 network. For example, if an attacker adjacent to a unmalicious router on the path between HA and CN can only eavesdrop the traffic but not intercept Zhao, et al. Expires August 25, 2005 [Page 3] Internet-Draft MIP6 RR Extensions February 2005 the traffic passing by in the IPv6 network, he can successfully intercept thus take the complete control of the communication between MN and CN by launching the MIP6 RR test. In this draft we propose an efficient and effective detection mechanism for both CN and MN to promptly detect any attack that could compromise the security of MIP6 RO mechanism and thus take the appropriate response. In the original MIP6 RR test, MN may detect the disruption of the communication by observing the traffic characteristics (The disruption/redirection attack is indicated by the time-out signal, however, MN has to wait the timer to expire.). Moreover, since MN does not know the root-cause of the anomaly, MN may have to retry for several times (for example, by re-sending the Binding Updates to CN) before concluding that there is either an attack or link failure. In order to discover the root-cause, MN may also try to compare the results by using the reverse tunneling to HA. Thus the whole procedure is very lengthy. On the other hand, the original MIP6 RR test does not provide any means for CN to detect the attack, thus the performance of the communication between MN and CN suffers since the moment when CN accepts the BU from an attacker. We believe that CN is in the best position to detect the attack and the most effective mechanism to resist a large range of attacks and minimize the effects of attack has to be done on the CN side. By detecting the attack promptly and taking the appropriate actions, for example, CN sends the packets to the home address, MN can detect the attack directly by observing the traffic being forwarded by HA, which follows a non-optimal route but is still better than the disruption of communication (100% packet loss). 3) Performance improvement Besides the security enhancement, this detection mechanism also helps improve the performance by reducing the signaling overhead. In MIP6 RO protocol, the lifetime of Binding Cache Entry (and nonce, token etc.) is limited to a few minutes in order to mitigate some attacks, which causes a lot of signaling overheads. With the detection mechanism, it is possible to lengthen the lifetime of Binding Cache Entry when some attacks, such as Future Address Stealing, are considered as the low severity. Another observation is that it is unnecessary to keep repeating the complete RR procedure if there is no attacker around, especially when MN still stays at the same location as before. The by-product of this detection mechanism is to reduce the complete RR procedure to just one round trip of message exchange when the lifetime of BCE is about to expire and MN does not change its location, which thus greatly improves the performance. Zhao, et al. Expires August 25, 2005 [Page 4] Internet-Draft MIP6 RR Extensions February 2005 4) RR test on network prefix It is also our motivation to propose a MIP6 RR test mechanism that could be easily extended to ôRR-testö Mobile Network Prefix in NEMO efficiently and securely once NEMO working group is re-chartered to work on the NEMO RO problem. This draft is organized as follows: in Section 2 we briefly review the related works and then describe the assumptions and the details of our proposal in Section 3 and Section 4 respectively. In Section 5 we present the security consideration and conclude the whole draft in Section 6. Finally, we briefly discuss the applicability of these ideas to NEMO RR test on MNP in Appendix 1. Zhao, et al. Expires August 25, 2005 [Page 5] Internet-Draft MIP6 RR Extensions February 2005 2. Related Works MIP6 protocol [2] adopts the RR test to enable CN to authenticate the binding between CoA and HoA of MN in a reasonable security level when there is no pre-exisitng security association between CN and MN. The rationale and background of this design are documented in [5]. Later on, a lot of enhancements of MIP6 RO and improvement of the original RR test are proposed in [6][7]. Those proposals are based on MIP6 RO; however, NEMO [4] RO [10] has its own security issues. [8] proposed the idea of using NPT message to verify the correctness of MNP; however, it not only generates the amplication effect but also leaves a hole for an attacker to successfully steal the traffic [9]. Zhao, et al. Expires August 25, 2005 [Page 6] Internet-Draft MIP6 RR Extensions February 2005 3. Assumptions Our draft inherits all the underlying assumptions of the original MIP6 RR test. Besides, we emphasis and restate the following assumptions: 3.1 No infrastructure support The extended RR test does not require PKI or AAA infrastructure to assist the authentication procedure and thus avoids the expensive public key calculation and signaling overhead due to extra message exchanges. 3.2 Pre-existing SA between MN and HA We assume that there exists a security association between MN and HA and the integrity and confidentiality of the messages between MN and HA are protected by this SA [3]. 3.3 No pre-existing SA between MN and CN or between HA and CN We assume that there is no pre-existing SA between MN and CN or between HA and CN. 3.4 No ingress filtering Our proposal does not rely on the ingress filtering, thus we assume that there is no ingress filtering enforced and the attacker can even spoof the packets. 3.5 Unmalicious HA and CN We assume that HA and CN do not have any malicious intention. If HA is malicious, the security of MIP6 RR test is compromised. For example, a malicious HA can redirect the HoT message to an attacker so that the attacker can successfully finish the RR procedure with CN and intercept the traffic to other MN; a malicious HA can also drop the HoTi or HoT message from or to any MN. In [8], the same assumption is also held implicitly because otherwise a malicious HA can forward the NPT messages to the attacker or respond on behalf of the attacker. Also a malicious HA can fully control the communication in MIP6 when MN performs the reverse tunneling. This is similar with the case that the attacker has full control (interception) over the path between CN and HA. The same analyses also apply if CN is malicious. Thus we believe this is a valid assumption. Zhao, et al. Expires August 25, 2005 [Page 7] Internet-Draft MIP6 RR Extensions February 2005 3.6 The power of the attacker We use the following two terms to describe the power of the attacker: 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 original MIP6 RR test limits the attack to be successful only when the attacker is in certain locations. In other words, the security is compromised when the attacker has the following powers: The attacker is able to access (intercept or eavesdrop) the message exchanges on both MN-CN path and HA-CN path. To do so, 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. We assume that the attacker has no full control on either MN-CN path or HA-CN path, but the attacker may have the partial control over both paths to eavesdrop the traffic passing by at the same time. Zhao, et al. Expires August 25, 2005 [Page 8] Internet-Draft MIP6 RR Extensions February 2005 4. Proposal Our discussions are based on the following simplified MIP6 scenario: CN is a fixed node in the Internet. It is possible to use the reverse tunneling when CN is also a mobile node just like in [5], but we will address this case in details in the later version of this draft due to the constrained time frame. Each extension can be applied to the original MIP6 RR test as an independent add-on module. Thus based on the security policy, MN and CN can negotiate to use one or a combination of several extensions. 4.1 Notations Besides those used in [2], we also defines the following notations: RN: a random number generated by MN with the fixed length. In other words, the length of RN is pre-configured and well known by MN, HA, CN and/or any other node. HV: the output of a secure hash function, such as SHA1. Kha: a secret node key of HA. 4.2 Protecting the privacy of HoA in MIP6 RR test message without encryption MN HA CN | | | | CoTi | |-------------------------------------------------------->| | CoT | |<--------------------------------------------------------| | HoTi | HoTi_HA | |-------------------------->|---------------------------->| | HoT_HA | HoT | |<--------------------------|<----------------------------| | BU | |-------------------------------------------------------->| | BA | |<--------------------------------------------------------| Figure 1: The RR test procedure Please note that MN should send HoTi and CoTi as soon as possible, even at the same time. The figure shows that HoTi is after CoTi just because of the convenience of drawing. Zhao, et al. Expires August 25, 2005 [Page 9] Internet-Draft MIP6 RR Extensions February 2005 When MN moves to a new location other than its home network, MN may decide to start the RR procedure with remote node, CN, as follows. HoTi: o Source IP address: HoA o Destination IP address: CN o {home_init_cookie | RN} MN generates the HoTi message and forwards it into the reverse MN-HA tunnel, thus the confidentiality and the secrecy of HoTi are protected by SA between MN and HA. After HA receives and verifies the HoTi message successfully, HA will generate the following HoTi_HA message and forward it to CN. Note that HoTi_HA message can use the same MH type value for HoTi message because this transformation is transparent to CN. We give a different name to the HoTi_HA message in order to highlight their differences. HoTi_HA: o Source IP address: HA o Destination IP address: CN o {home_init_ha_cookie | HV} where HV = SHA1 (HoA | RN) Please note that HA replaces the source IP address, HoA, with its own IP address, HA and replaces home_init_cookie with home_init_ha_cookie. While there are several ways to generate home_init_ha_cookie, we simply generate it by a Random Number Generator (RNG). Then HA establishes a table where home_init_ha_cookie, HoA and home_init_cookie are stored in one entry and home_init_ha_cookie is a primary key. Please note that HA creates the table entry only after it verifies the received packet from MN, thus it does not risk the Denial-of-Service attack at this stage. Later, when HA receives the HoT packet that seems like from CN, HA just needs to perform the table lookup operation to verify the cookie. The management of this table does not result in too much extra cost because HA needs to remember the recent home_init_cookie in the original MIP6 RR test anyway. However if HA still concerns about the memory cost, HA can generate home_init_ha_cookie by AES(Kha, HoA | home_init_cookie) and only need to remember 1) home_init_ha_cookie or 2) the output of a hash function over home_init_ha_cookie or 3) even nothing. In 1) and 2) memory cost is Zhao, et al. Expires August 25, 2005 [Page 10] Internet-Draft MIP6 RR Extensions February 2005 reduced at a cost of decryption and/or hash computation and the Denial-of-Service attack for HA is mitigated by firstly verifying the received home_init_ha_cookie in the HoT message that seems from CN. However, in 3) Denial-of-Service attack may become a serious threat when HA later decrypts the payload to restore HoA and home_init_cookie. Although the time spent on the decryption may not be as much as one thought because AES is done over a short payload (the concatenation of HoA and home_init_cookie), HA should take all these factors in considerations and balance the cost between memory and computation to minimize the threats. After CN receives HoTi_HA message, CN generates the HoT message. Note that the formula to generate home_token takes HV as input as well. HoT: o Source IP address: CN o Destination IP address: HA o {home_init_ha_cookie | home_token | home_nonce_index} o home_token = First (128, HMAC_SHA1(Kcn, (HV | home_nonce | 0))) After HA receives HoT message, HA looks up the table with home_init_ha_cookie as the primary key or decrypts the home_init_ha_cookie. After successfully achieving HoA and home_init_cookie, HA generates the following HoT_HA message and forwards it to MN through the MN-HA tunnel. HoT_HA: o Source IP address: CN o Destination IP address: HoA o {home_init_cookie | home_token | home_nonce_index} o home_token = First (128, HMAC_SHA1(Kcn, (HV | home_nonce | 0))) Please note that HoT_HA message can use the same MH type value for HoT message because this transformation is transparent to MN. We give a different name to the HoT_HA message in order to highlight their differences. MN generates the CoTi message and sends it directly to CN. Note that CoTi carries HV instead of HoA in the cleartext in [7]. Zhao, et al. Expires August 25, 2005 [Page 11] Internet-Draft MIP6 RR Extensions February 2005 CoTi: o Source IP address: CoA o Destination IP address: CN o {careof_init_cookie | HV} o HV = SHA1 (HoA | RN) where RN is the same random number used in the HoTi message. After CN receives CoTi message, CN generates the CoT message. Note that the formula to generate careof_token takes HV as input as well. CoT: o Source IP address: CN o Destination IP address: CoA o {careof_init_cookie | careof_token | careof_nonce_index} o careof_token = First (128, HMAC_SHA1(Kcn, (CoA | HV | careof_nonce | 1))) The binding management key, Kbm, is generated by taking the concatenation of home_token and careof_token as input of SHA1. Kbm = SHA1(home_token | careof_token) MN generates the BU message as follows and sends it to CN. BU: o Source IP address: CoA o Destination IP address: CN o {HoA | seq | home_nonce_index | careof_nonce_index | RN | MAC} o MAC = First (128, HMAC_SHA1(Kbm, (CoA | CN | BU))) Please note that the privacy of HoA is protected by encryption as shown in Section 4.3. Other kinds of privacy protection mechanisms than encryption could be used as well. When CN receives the BU message, CN firstly calculates HV based on HoA and RN, then generates Kbm and verifies the MAC. If MN requests Zhao, et al. Expires August 25, 2005 [Page 12] Internet-Draft MIP6 RR Extensions February 2005 the Binding Acknowledgement, CN generates the BA message based on the verification result. BA: o Source IP address: CN o Destination IP address: CoA o {seq | HV | MAC} o MAC = First (128, HMAC_SHA1(Kbm, (CoA | CN | BA))) 4.3 Protection of the HoA privacy in the BU message The binding management key, Kbm, and the encryption key, Ken, are generated as follows. Kbm = SHA1(home_token | careof_token | 0) Ken = SHA1(home_token | careof_token | 1) BU: o Source IP address: CoA o Destination IP address: CN o {seq | home_nonce_index | careof_nonce_index | HV | ENC | MAC} o ENC = AES (Ken, HoA | RN) o MAC = First (128, HMAC_SHA1(Kbm, (CoA | CN | BU))) After CN receives the BU message, CN firstly generates Kbm and Ken, then verifies MAC and decrypts ENC. Assume that what CN gets is HoAÆ and RNÆ, CN will verify whether HV is equal to SHA1 (HoAÆ | RNÆ). If the BA message is requested, CN generates the following one based on the verification result. BA: o Source IP address: CN o Destination IP address: CoA o {seq | HV | MAC} Zhao, et al. Expires August 25, 2005 [Page 13] Internet-Draft MIP6 RR Extensions February 2005 o MAC = First (128, HMAC_SHA1(Kbm, (CoA | CN | BA))) Please note that the decryption operation is after the verification succeeds, which is necessary to reduce the risk of Denial-of-Service attack. Please note that the time spent on the decryption might be not as much as one thought because AES is done over a short payload (the concatenation of HoA and RN). Although an attacker on the HA-CN path can still pass the MAC verification and make CN spend resources on the decryption operation, a detection mechanism can be used to detect this kind of attack as shown below. 4.4 Extending the RR test with a detection mechanism The original MIP6 RR test allows an attacker to intercept the traffic even though this attacker is only able to eavesdrop the traffic in the IPv6 network, which makes the MIP6 network slightly less secure than the IPv6 network. In order to provide better security together with other performance benefits, we propose a simple but effective detection mechanism to enable CN to detect the attack promptly and take the appropriate response when the power of attacker can compromise the security of the original MIP6 RR test. The core idea is that either a valid MN or an attacker must provide the cryptographically sound proof of the previous successful Binding Update to CN if any, before a new Binding Update is accepted by CN. If the correctness of this proof cannot be verified by CN, CN disables the relevant Binding Update Cache entry and forwards the data packet to its home address instead. We adopt one-way hash chain to accomplish that. While we have considered using other kinds of one-way hash chain (or tree) as well, in this draft we focus our discussions on the following one: MN wants to a chain of length k. Firstly, it generates a random number h_k 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). This one-way hash chain has the following properties: MN reveals the elements of the chain in the order of h_0, h_1, à, h_k to CN. Even though the attacker eavesdrops h_i in this chain, it is still cryptographically impossible for him to derive h_j from h_i where j>i. On the contrary, any one can easily confirm that h_j is part of the chain if h_i=H(h_j)^(j-i) where j>i. MN 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. There exist other approaches that can help reduce storage cost with a small recomputation 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 Zhao, et al. Expires August 25, 2005 [Page 14] Internet-Draft MIP6 RR Extensions February 2005 maintain such kind of one-way hash chain. Please note that MN maintains a hash chain for each pair of so that MN can use multiple HoAs to communicate with different CN. Notations: h_seq: the current element in the one-way hash chain. seq: the sequence number of this element in the one-way hash chain. MN generates the BU message as follows and sends it to CN. BU: o Source IP address: CoA o Destination IP address: CN o {HoA | seq | home_nonce_index | careof_nonce_index | RN | h_seq | MAC} o MAC = First (128, HMAC_SHA1(Kbm, (CoA | CN | BU))) When CN receives the BU message, CN firstly calculates HV based on HoA and RN, then generates Kbm and verifies the MAC. If the result is positive, CN performs the following procedure to verify h_seq: 1. Search the Binding Update Cache by using MNÆs HoA as the primary key. 2. If it does exist, CN verifies h_seq in the BU message with the old hash chain element, h_seqÆ stored in the Binding Updates Cache as follows: 1. If seqÆ >= seq, discard the BU message because it is a replayed message. 2. If seqÆ < seq and h_seqÆ=H(h_seq)^(seq-seqÆ), CN believes this BU message is correct, thus it updates the Binding Cache Entry with h_seq and then sends the Binding Acknowledgement message if requested. 3. If seqÆ < seq and h_seqÆ <> H(h_seq)^(seq-seqÆ), CN realizes that there is an attacker that can successfully finish the extended RR test; however, CN is not sure whether this BU message is from the attacker or a valid MN based on its current knowledge. Thus CN disables this entry, indicates Zhao, et al. Expires August 25, 2005 [Page 15] Internet-Draft MIP6 RR Extensions February 2005 the reason in the BA message and forwards the data packets to the home address. CNÆs policy may decide to accept the new BU message for this HoA when the current session with this HoA is ended or after a certain amount of time. 3. If it does not exist, CN accepts the BU message and creates a new Binding Update Cache Entry and forwards the data packets destined to this HoA based on MIP6 RO protocol. The hash chain can be depleted after a long time use. MN can update the hash chain information in CN by starting a complete RR test and sending the last element in the old hash chain together with the first element in the new hash chain in the BU message. The hash chain information should not be lost due to the reboot in CN and 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 information in the hard disk so that the synchronization between MN and CN can be restored. CN must verify the hash chain element in the BU message even if seq is not consecutive in order to recover from the BU packet loss due to the network congestion. However the difference between the new seq and the old seq should not be more than the number of retries when MN experiences the packet loss. If MN requests the Binding Acknowledgement, CN generates the BA message based on the verification result. BA: o Source IP address: CN o Destination IP address: CoA o {seq | HV | MAC} o MAC = First (128, HMAC_SHA1(Kbm, (CoA | CN | BA))) Please note that this detection mechanism is independent from the location privacy mechanism, thus the privacy of HoA can be also protected by encryption just like in the previous section. CN needs to verify the hash chain element after the decryption. 4.5 Lengthening the lifetime of BCE Given the strong detection mechanism, it is possible to lengthen the lifetime of BCE in order to reduce the frequency of RR test. One of Zhao, et al. Expires August 25, 2005 [Page 16] Internet-Draft MIP6 RR Extensions February 2005 dangers to do so is the future address stealing attack, which is similar with the reflector-based flooding attack and can be easily detected by MN. Thus if there is no such attack detected by MN, MN can benefit from the lengthened BCE lifetime; otherwise, MN needs the help from the upstream router to filter the unwanted traffic, maybe in a way similar with pushback, which is out of the scope of this draft. More examinations on the Pros and Cons of lengthening the lifetime of BCE are still needed. 4.6 Fast BU refreshment When the lifetime of one binding cache entry is about to expire or MN receives the Binding Refresh Request message from CN, if MN does not change its location, MN can send the following BU message to CN: BU: o Source IP address: CoA o Destination IP address: CN o {seq | HV | h_seq} o where HV = SHA1(HoA) When CN receives it, it uses HV to looks up the Binding Cache that is extended to include HV as a field in each entry. If there exists an entry, CN compares the received CoA with that in the entry. If it matches, CN verifies h_seq as described before. If everything is correct, CN generates the following BA message if requested: BA: o Source IP address: CN o Destination IP address: CoA o {seq | HV} o where where HV = SHA1(HoA | h_seq) When MN receives the BA message, MN generates SHA1(HoA | h_seq) and then compares it with HV. If HoA is not disclosed, then it is cryptographically impossible for an eavesdropper to generate SHA1(HoA | h_seq) based on SHA1(HoA) and h_seq, thus MN can believe this BA message is really from CN that gains the knowledge about HoA from the complete RR procedure that MN did with CN before. Zhao, et al. Expires August 25, 2005 [Page 17] Internet-Draft MIP6 RR Extensions February 2005 Please note that if using the method above it is required to protect the privacy of HoA in the data message as well. It is possible to use SHA1(HoA) instead of HoA in the data packet; however, the details will be discussed in the future version. If MN does not worry about the location privacy, it can just use HoA in the BU message rather than HV. Please note that the Binding Acknowledgement message is optional in the original MIP6 RR test anyway, the forged Binding Acknowledgement message may result in a non-optimal route in the worst case but not disruption. 4.7 Non-repudiation It seems that the only way to provide the non-repudiation of HA or CN is to use the public key. Our RR test can be extended to achieve the repudiation if the public keys of HA and/or CN are available. The details of this extension are skipped because it is equivalent to say that there exists the trust relationship between HA and CN. Moreover, instead of using public key every time when launching the RR test, we can use public key authentication only at the first time and then use the hash chain in the following RR test session to reduce the computation cost. Zhao, et al. Expires August 25, 2005 [Page 18] Internet-Draft MIP6 RR Extensions February 2005 5. Security consideration 5.1 The privacy of HoA The privacy of HoA is protected as much as possible. Using the hash value of HoA instead of HoA in the cleartext not only makes the leakage of HoA cryptographically impossible but also help shorten the length of message, simplify the task to design and parse message format as the length of a hash function output is fixed. Moreover, we append a random number to HoA before performing the hash function in order to make it difficult for the attacker to derive HoA because HAÆs address shares the same network prefix with HoA mostly. Without this random number, the attacker may need less computation to acquire HoA. Please note that privacy is secondary compared with authentication because if an attacker can break the authentication of the RR test, the privacy of HoA is also compromised. 5.2 Denial-of-Service attack Security comes with costs. We carefully design the protocol in order to minimize the risk of Denial-of-Service attack against MN, CN or HA. 5.2.1 Decryption It is possible that the attacker can launch the DoS attack by making CN/HA busy with decryption, however it requires the attacker to forge the BU message with the correct MAC and hash chain element or to provide the correct cookie. Because AES is done over a short payload (For example, the total length of HoA and RN is only 32 bytes.), the time to encrypt/decrypt by AES may not be as much as one thought. 5.2.2 Hash chain verification The attacker may want to launch the DoS attack by making CN spend a lot of time on the verification of hash chain element. For example, if the current hash chain element is h_i, the attacker sends one BU message with h_j where j>>i. CN may set the upper bound of the difference between j and i, which is also the number of retries when the BU message is lost during the transmission. If j is too large, CN may refuse the BU message according to its policy. 5.3 Prevention of traffic interception The attacker only being able to eavesdrop on both MN-CN and HA-CN path cannot intercept the traffic that is intended to a specific MN Zhao, et al. Expires August 25, 2005 [Page 19] Internet-Draft MIP6 RR Extensions February 2005 when the detection mechanism is in use. 5.4 Other attacks described in [7] The attacks described in [7] do not succeed in our RR test. For the session hijacking attacks in section 3.1, although the attacker can learn the home_token, however, it does not know HoA, so the attacker cannot generate the correct BU message. If the attacker has its conspirator on the MN-CN path, since its conspirator cannot intercept the message, it cannot stop MN from finishing the RR test with CN. Together with the detection mechanism, the traffic cannot be hijacked. For the Movement Halting attacks in section 3.2, when the attacker is able to know home_token and careof_token in the different sessions but from one single MN, the attacker must have to learn HoA from the BU message. If the BU message is encrypted, the attack fails if the attacker cannot monitor both paths simultaneously. If the BU message is not encrypted, the attack still fails when the detection mechanism is used. For the traffic permutation attacks in section 3.3, the attacker is able to know multiple home_tokens and multiple careof_tokens in the different sessions from multiple different MNs. However, since both home_token and careof_token are generated from the hash output of HoA, CN can detect the forged BU message using mixed home_token and careof_token. Again the detection mechanism can detect this attack as well. Using the hash output of HoA only prevents the attack targeting at a specific MN and the attacker has no knowledge of HoA associated with this MN. But the attacker on the HA-CN path is free to launch the RR test for any HoA it chooses as long as it is on the path from CN to this home network. Again, this attack can be detected by the detection mechanism. The extended RR test supports the fast Binding Updates procedure in CN, which is especially useful when MN moves from one location to another frequently. When MN moves to a new location, MN can reuse the home_token received at the previous location as long as home_token is still valid, thus MN saves the home test procedure that is usually longer than the careof test since HoTi and HoT messages have to go through HA firstly. Zhao, et al. Expires August 25, 2005 [Page 20] Internet-Draft MIP6 RR Extensions February 2005 6. Conclusions In this draft, we propose several extensions to the original MIP6 RR test. Our proposal protects the location privacy and enables CN and MN to promptly detect the attack, thus it achieves better security and performance. 7. 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] Devarapalli, V., Wakikawa, R., Petrescu, A. and P. Thubertet, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, January 2005. [5] 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. [6] 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. [7] Bao, F., Deng, R. and J. Zhou, "Improvement of Return Routability Protocol", draft-qiu-mip6-rr-improvement-00 (work in progress), August 2004. [8] Ng, C. and J. Hirano, "Extending Return Routability Procedure for Network Prefix (RRNP)", draft-ng-nemo-rrnp-00 (work in progress), October 2004. [9] Nordmark, E., "Re: [nemo] [Fwd: I-D ACTION:draft-ng-nemo-rrnp-00.txt]", NEMO WG mailing list archive, http://www1.ietf.org/mail-archive/web/nemo/current/msg 01809.html, October 2004. [10] Zhao, F., Wu, S F. and S. Jung, "NEMO Route Optimization Problem Statement and Analysis", draft-zhao-nemo-ro-ps-01 (work Zhao, et al. Expires August 25, 2005 [Page 21] Internet-Draft MIP6 RR Extensions February 2005 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 S. Felix Wu University of California, Davis One Shield Avenue Davis, CA 95616 US Phone: +1 530 754 7070 Email: sfwu@ucdavis.edu 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 August 25, 2005 [Page 22] Internet-Draft MIP6 RR Extensions February 2005 Appendix A. Return Routability Test on Network Prefix (RRNP) in NEMO We limit our discussion in this draft in such a simplified NEMO scenario: 1) CN/CR is a fixed node in the Internet. 2) MR is not in the nested NEMO network, instead it attaches to the Internet directly. Generally speaking, we expect that the RR test on network prefix (RRNP) in NEMO makes the NEMO network as secure as the MIP6/IPv6 network. Especially, the leakage of MNP information in NEMO does not affect just one simple host as in MIP6 but a whole network, thus we expect to protect the privacy of MNP during the RRNP procedure, which is accomplished by applying hash function and encryption over the MNP information. There are following advantages by using hash function over MNP information alone: 1) The privacy of MNP is protected and the disclosure of MNP is postponed as late as possible. 2) It does not limit the number or source of MNP(s) owned by MR. Instead, MR could own arbitrary number of MNPs from one or even multiple different home networks while the length of message is shortened and the task to design and parse message format is simplified as the length of a hash function output is fixed. 3) The attacks described in [7] are defeated while still making the fast Binding Update possible. We also avoid using multiple NPT messages to test the correctness of MNP. Instead, we depend on HA to actively verify the MNP information in the HoTi message. The reasons are as follows: 1) HA knows the MNP(s) associated with MR implicitly or explicitly before the RRNP test. This is similar with implicit mode and explicit mode in NEMO Basic Support Protocol. For example, there is manual configuration at HA mapping the MNP to MRÆs HoA, so HA knows the MNP associated with MR implicitly. On the other hand, MR may inform HA about the MNP information explicitly by the Home Binding Update procedure and then start the RRNP test. Either way, HA can verify the MNP information in the RRNP message correctly. (Note that in the explicit mode, the MNP information in the RRNP message must match that in the Home Binding Update message.) 2) HA should not have any malicious intention to CN/CR and MR as we discuss before. Hash chain can also be integrated into the RRNP test to detect the attack. Zhao, et al. Expires August 25, 2005 [Page 23] Internet-Draft MIP6 RR Extensions February 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 August 25, 2005 [Page 24]