Network Working Group Feng BAO INTERNET-DRAFT Robert DENG Expires: February 28, 2005 Ying QIU Network Working Group Jianying ZHOU August 30, 2004 Improvement of Return Routability Protocol Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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 February 28, 2005. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract This document proposes an improved security solution for Return Routability (RR) protocol without changing the architecture. With the improvement, three types of redirect attacks can be prevented. Expires: February 28, 2005 [Page 1] Internet Draft Improved RR August 30, 2004 Table of Contents 1. Introduction ................................................. 2 2. Brief Review of RR Protocol .................................. 2 3. Discussion of Redirect Attacks in MIPv6 ...................... 4 3.1 Session Hijacking Attacks ................................. 5 3.2 Movement Halting Attacks .................................. 6 3.3 Traffic Permutation Attacks ............................... 6 4. Improvement of RR Protocol ................................... 7 5. Security Considerations ...................................... 8 6. Conclusion ................................................... 8 7. Acknowledgements ............................................. 8 8. References ................................................... 8 9. Authors' Addresses ............................................ 8 Intellectual Property and Copyright Statements ................... 9 1. INTRODUCTION In the base specification of Mobile IPv6 (MIPv6) [1], the Return Routability protocol (RR) is employed to secure binding updates from mobile nodes to corresponding nodes. In the draft, we will discuss three attacks to the RR protocol and then give a solution without changing the RR architecture. 2. BRIEF REVIEW OF RR PROTOCOL In Return Routability (RR) protocol, each correspondent node CN keeps a secret key Kcn and generates nonces at regular intervals, say every few minutes. CN uses the same secret key Kcn and nonce with all the mobile nodes it is in communication with, so that it does not need to generate and store a new nonce when a new mobile node contacts it. Each nonce is identified by a nonce index. When a new nonce is generated, it must be associated with a new nonce index, e.g., j. CN keeps both the current nonce of Nj and a small set of previous nonce values, Nj-1, Nj-2, ... . Older values are discarded, and messages using them will be rejected as replays. Message exchanges in the RR protocol are shown in the figure below, where the HoTI (Home Test Init) and CoTI (Care-of Test Init) messages are sent to CN by a mobile node MN simultaneously. The HoT (Home Test) and CoT (Care-of Test) are replies from CN. All RR protocol messages are sent as IPv6 "Mobility Header" in IPv6 packets. Expires: February 28, 2005 [Page 2] Internet Draft Improved RR August 30, 2004 Mobile node Home agent Correspondent node | | | Home Test Init (HoTI) | | |------------------------->|------------------------->| | | | | Care-of Test Init (CoTI) | |---------------------------------------------------->| | | | | Home Test (HoT) | |<-------------------------|<-------------------------| | | | | Care-of Test (CoT) | |<----------------------------------------------------| | | In the brief review of a protocol message, we will use the first two fields to denote source IP address and destination IP address, respectively. We will use CNA to denote the IP address of the correspondent node CN. When MN wants to perform route optimization, it sends HoTI = {HoA, CNA, CKh} and CoTI = {CoA, CNA, CKc} to CN, where CKh and CKc are the initial cookies used to match responses with requests. HoTI tells MN??s home address HoA to CN. It is reverse tunneled through the home agent HA, while CoTI informs MN??s care-of address CoA and is sent directly to CN. When CN receives HoTI, it takes the source IP address of HoTI as input and generates a home keygen token KTh = HMAC_SHA1(Kcn, (HoA|Nj|0)) and replies MN with HoT = {CNA, HoA, CKh, KTh, j}, where | denotes concatenation and the final "0" inside the pseudo random function is a single zero octet, used to distinguish home and care-of cookies from each other. The index j is carried along to allow CN later efficiently finding the nonce value Nj that it used in creating the home keygen token KTh. Similarly, when CN receives CoTI, it takes the source IP address of CoTI as input and generates a care-of keygen token KTc = HMAC_SHA1(Kcn, (CoA|Ni|1)) Expires: February 28, 2005 [Page 3] Internet Draft Improved RR August 30, 2004 and sends CoT ={CNA, CoA, CKc, KTc, i} to MN, where the final "1" inside the pseudo random function is a single octet "0x01". Note that HoT is sent via MN??s home agent HA while CoT is delivered directly to MN. When MN receives both HoT and CoT, it hashes together the two keygen tokens to form a binding key Kbm = SHA1(KTh|KTc), which is then used to authenticate the corresponding binding update message to CN: BU = {CoA, CNA, HoA, Seq#, i, j, MACbu}, ???? where Seq# is a sequence number used to detect replay attack and MACbu = HMAC_SHA1(Kbm, CoA|CNA|HoA|Seq#|i|j) is a message authentication code (MAC) protected by the binding key Kbm. MACbu is used to ensure that BU was sent by the same node which received both HoT and CoT. The message BU contains j and i, so that CN knows which nonce values Nj and Ni to use to first re-compute KTh and KTc and then the binding key Kbm. Note that CN is stateless until it receives BU and verifies MACbu. 3. REDIRECT ATTACKS TO RR PROTOCOL In the RR protocol, the two keygen token exchanges verify that a mobile node MN is alive at its addresses, i. e., is at least able to transmit and receive traffic at both its home address HoA and care- of address CoA, respectively. The eventual binding update is cryptographically protected with the binding key Kbm obtained by hashing the concatenation of the two keygen tokens KTh and KTc. Obviously, the RR protocol protects binding updates against intruders who are unable to monitor the HA-CN path and the MN-CN path simultaneously. However, one has no reason to assume that an intruder will monitor one link and not the other, especially when the intruder knows that monitoring a given link is particularly effective to expedite its attack. Even worse, we demonstrate that the RR protocol can be attacked under its original assumption of no simultaneous monitor of both the HA-CN path and the MN-CN path. Expires: February 28, 2005 [Page 4] Internet Draft Improved RR August 30, 2004 3.1 Session Hijacking Attacks In the session hijacking redirect attack shown in the figure below, assume that a mobile node MN1 is communicating with a correspondent node CN. An intruder sends a forged binding update message (or replays an old binding update message) to CN, claiming that MN1 has moved to a new care-of address belonging to a node MN2. If CN accepts the fake binding update, it will redirect to MN2 all packets that are intended to MN1. This attack allows the intruder to hijack ongoing connections between MN1 and CN or start new connections with CN pretending to be MN1. This is an "outsider" attack since the intruder tries to redirect other nodes?? traffic. Such an attack may result in information leakage, impersonation of the mobile node MN1 or flooding of MN2. This attack is serious because MN1, MN2, CN and the intruder can be any nodes anywhere on the Internet. All the intruder needs to know is the IP addresses of MN1 and CN. Since there is no structural difference between a mobile node home address and a stationary IP address, the attack works as well against stationary Internet nodes as against mobile nodes. +-----+ | MN2 |<------------+ +-----+ | v +-----+ +----+ | MN1 |<----- XX ------->| CN | +-----+ +----+ ^ +----------+ | | Intruder | -------+ +----------+ In the case of the static IPv6 without mobility (which is equivalent to the mobile node MN at its home subnet in MIPv6), to succeed in the attack, the intruder must be constantly present on the CN-HA path. In order to redirect CN??s traffic intended for MN to a malicious node, the intruder most likely has to get control of a router or a switch along the CN-HA path. Furthermore, after taking over the session from MN, if the malicious node wants to continue the session with CN while pretending to be MN, the malicious node and the router need to collaborate throughout the session. For example, the router tunnels CN??s traffic to the malicious node and vise versa. In the case of MIPv6, the effort committed to break the RR protocol to launch a session hijacking attack could be considerably lesser. Assume that MN1 and CN in the figure above are having an on-going communication session and the intruder wants to redirect CN??s Expires: February 28, 2005 [Page 5] Internet Draft Improved RR August 30, 2004 traffic to his collaborator MN2. The intruder monitors the CN-HA path (i.e., anywhere from MN1??s home network to CN??s network) to obtain HoT, extracts the home keygen token KTh and sends it to MN2. Upon receiving KTh, MN2 sends a CoTI to CN and CN will reply with a care-of keygen token KTc. MN2 simply hashes the two keygen tokens to obtain a valid binding key, and uses the key to send a binding update message to CN on behalf of MN1. The binding update will be accepted by CN which will in turn direct its traffic to MN2. 3.2 Movement Halting Attacks Another related attack is when a mobile node MN rapidly moves from one care-of address CoA to another CoA??. Since MN runs the RR protocol whenever it moves to a new location, an intruder can intercept the care-of keygen token KTc in the current RR session and the home keygen token KTh in the next RR session, hash the two keygen tokens to a valid binding key, and then send a binding update message with the CoA in the current session to the correspondent node. The correspondent node will still send its traffic back to CoA. Hence, MN, which has moved to CoA??, will not receive data from the correspondent node. Note that in this attack the attacker does not have to intercept the two keygen tokens at the "same time". 3.3 Traffic Permutation Attacks +-----+ : | MN1 |===========:======\\ +-----+ : \\ : \\ +-----+ : +--------------+ | MN2 |===========:===| CN or Server | +-----+ : +--------------+ : // +-----+ : // | MN3 |===========:======// +-----+ : : +----------+ | Intruder | +----------+ The RR protocol is also subject to a "traffic permutation" attack. Consider the figure above where a correspondent node provides on-line services to many mobile clients. An intruder can simply eavesdrop on the RR protocol messages to collect keygen tokens on the border between the correspondent node and the Internet. The intruder then hashes random pairs of keygen tokens to form binding keys, and sends binding update messages to the correspondent node. Expires: February 28, 2005 [Page 6] Internet Draft Improved RR August 30, 2004 Such a forged binding update message will be accepted by the correspondent node with probability 1/4. This will cause redirection of traffic to randomly selected mobile clients and eventually bring down the services of the correspondent node. 4. IMPROVEMENT OF RR PROTOCOL The attacks outlined in the above section are due to the decoupling of HoA and CoA in RR messages. In the original RR protocol, the home keygen token KTh = HMAC_SHA1(Kcn, (HoA|Nj|0)) and the care-of keygen token KTc = HMAC_SHA1(Kcn, (CoA|Ni|1))) are delivered without any stated relationship. Any pair of home keygen token and care-of keygen token can generate a valid binding key as long as the indexes, i and j, are still valid. However, the attacks described in the above section can be prevented by modifying the RR protocol to include both CoA and HoA in the generation of home keygen token and care-of keygen token, respectively. In the improved RR protocol, HoA and CoA are bound together. A mobile node MN sends HoTI = {HoA, CNA, CoA, CKh} and CoTI = {CoA, CNA, HoA, CKc} to a correspondent node CN, which replies with the home keygen token KTh = HMAC_SHA1(Kcn, (HoA|Nj|CoA|0)) and the care-of keygen token KTc = HMAC_SHA1(Kcn, (CoA|Ni|HoA|1)). Expires: February 28, 2005 [Page 7] Internet Draft Improved RR August 30, 2004 5. SECURITY CONSIDERATIONS The draft proposes an improvement of RR protocol so that three kinds of redirect attacks can be prevented. 6. CONCLUSION After analysis of RR protocol and three redirect attacks, we proposed an improved solution for RR protocol. The improvement can provide much stronger security than the original RR protocol without changing its architecture. 7. ACKNOWLEDGEMENTS 8. REFERENCES [1] D. B. Johson and C. Perkins, "Mobility Support in IPv6", RFC 3775, June 2004. 9. AUTHORS' ADDRESSES Feng BAO Institute for Infocomm Research 21 Heng Mui Keng Terrace Singapore 119613 Phone: +65-6874-8456 EMail: baofeng@i2r.a-star.edu.sg Robert DENG Singapore Management University 469 Bukit Timah Road Singapore 259756 Phone: +65-6822-0920 EMail: robertdeng@smu.edu.sg Ying QIU Institute for Infocomm Research 21 Heng Mui Keng Terrace Singapore 119613 Phone: +65-6874-6742 EMail: qiuying@i2r.a-star.edu.sg Jianying ZHOU Institute for Infocomm Research 21 Heng Mui Keng Terrace Singapore 119613 Phone: +65-6874-6668 EMail: jyzhou@i2r.a-star.edu.sg Expires: February 28, 2005 [Page 8] Internet Draft Improved RR August 30, 2004 INTELLECTUAL PROPERTY STATEMENT The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2004). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. Expires: February 28, 2005 [Page 9] Internet Draft Improved RR August 30, 2004 Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Expires: February 28, 2005 [Page 10]