NEMO Working Group Fan Zhao Internet Draft S. Felix Wu Expires: January 12, 2005 UC Davis Souhwan Jung Soongsil Univ. HyunGon Kim ETRI July 12, 2004 Secure Reverse Routing Header Solution in NEMO draft-zhao-nemo-rrh-security-00 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 January 12, 2005. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract: In this draft, we begin with an extensive security analysis on a NEMO RO proposal, RRH, and then propose an effective security mechanism to resist those new threats introduced by the RRH header in the nested mobile network. Conventions used in this document 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 RFC-2119. Zhao et. al. Expires January 2005 [page 1] Internet Draft Secure Reverse Routing Header July 2004 1. Introduction This document assumes the reader is familiar with the Reverse Routing Header protocol defined in [9] and other NEMO related documents [1-6]. Route optimization problem in NEMO has attached a lot of interests from the researchers. Please refer to a few of related Route Optimization drafts and taxonomy of Route Optimization models described in [8]. The RRH proposal tries to solve this problem by embedding the routing information in the data plane rather than building the routing state in the control plane. By doing so, mobile nodes can manage to response more quickly to the topology changes than other proposals. However, the carrier of such important routing information, RRH header, is not protected by the end-to-end security, which is also stated in the original draft [9]. This document analyzes in depth the security of RRH proposal. The results show that with unprotected RRH header the adversary can more easily launch the attack than in the NEMO basic support protocol. And we also propose the security solutions to resist such attacks. 2. Assumptions 2.1 MN/MR has pre-established security association with the HA if they belong to the same domain. 2.2 LFN/MN could have the pre-established security association with its CN. 2.3 Generally no pre-established security association exists between MN/MR and HA belonging to the different domains. 2.4 No assumption is made about the pattern of topology changes in NEMO nested mobile network, in other words, the user or device mobility model. 2.5 There exist only a relatively small number of malicious MRs in the NEMO mobile network, if any. 3. An Example Scenario and Terminology 3.1 An example scenario We make several minor changes on the following figure borrowed from the RRH draft [9] as an example topology. +---------------------+ | Internet |---CN +---------------|-----+ / Access Router MR3_HA | ======?====== MR1 | ====?=============?=========== MR5 MR2 | | =========== ===?==================?====== MR3 MR7 | | Mobile Network3 --> ==|========?===== =====|===== LFN1 MR4 LFN2 | ========= An example nested Mobile Network Zhao et. al. Expires January 2005 [page 2] Internet Draft Secure Reverse Routing Header July 2004 This example also focuses on a Mobile Network node at depth 3 (Mobile Network3) inside the tree, represented by its mobile router MR3. 3.2 Terminology - Inbound packet The packets coming into the nested mobile network. - Outbound packet The packets going out of the nested mobile network. 4. Security Analysis Based on the location of adversaries, the scope of security analysis is divided into two: in the Internet and inside the NEMO nested mobile network. 4.1 Security Analysis on the Routing Path in the Internet Generally there are more security risks in the Internet than inside the NEMO nested mobile network because the packets between MN and CN will traverse multiple domains (AS) belonging to the different ISPs, and even different countries. The adversary on the path can eavesdrop, drop, modify, delay and replay any packet passing by. However due to the limitation of space, these generic threats will not be elaborated. The integrity and confidentiality of (at least) part of the RRH header is not protected, so the adversary has no difficulty gathering and analyzing the topology information of nested mobile network to make preparation for the next stage attack. 4.1.1 Leakage of topology information We use MR3 as an example in the following description. Any adversary on the path between root-MR and HA3 can learn the binding of HoA and CoA of MR3 because both BU packet of MR3 and data packets (MR3 is the first MR to forward those data packets.) contain both HoA and CoA of MR3 in the RRH header in the clear text. Compared with NEMO basic support, if IPSec ESP is used between MR and HA, the adversary needs to be on the path between HA2 and HA3 in order to know the binding between HoA and CoA of MR3. In order to know the bindings of all the MRs, the adversary just needs to be around the root-HA while in NEMO basic support with ESP, the adversary has to be able to eavesdrop around all the HAs. Any adversary on the path between root-MR and HA3 can also easily know the path from root-MR to MR3 while in NEMO basic support with ESP, the adversary has to be able to eavesdrop around both HA1 and HA2. Zhao et. al. Expires January 2005 [page 3] Internet Draft Secure Reverse Routing Header July 2004 So RRH is more easily to leak the topology information than NEMO basic support. And in RRH the outside attacker can cooperate with the inside attacker to know the topology information more easily. 4.1.2 DoS attack Since the content of RRH header is not covered by any end-to-end security protection, the adversary could modify the RRH in order to consume the bandwidth inside the NEMO nested mobile network or resources of MRs. (The length of RRH header could be protected indirectly if the packet length field in IP header is protected by AH. However, it requires that the MR knows the exact number of slots before sending, which may not be easily achieved when the topology is changed quickly. Even worse the adversary can still modify the RRH content.) This DoS attack can achieve the same damage as the flooding attack by a lower sending rate and a lower possibility to be detected. 4.1.2.1 extend the RRH header By inserting more IP addresses into the RRH header, the attacker forces the packets to take a much longer path inside the nested mobile network. Thus the mobile routers, which are usually resource-limited, are forced to spend more resource to forward those packets and the bandwidth of link, which is usually wireless link, is easily exhausted. 4.1.2.2 form a loop in the RRH header The adversary can form a loop in the RRH header. Since the ingress filtering only checks whether the source IP address is topology correct, it does not detect or prevent the formation of loop. Since Multi-homing will be adopted widely, the loop will be more easily formed because of the rich connectivity. Given that the maximum number of slots is ten, the number of loops can be up to nine. 4.1.2.3 Comparison with the NEMO basic support It is not easy to forge the IP header with the ESP tunnel mode. Thus the DoS threat is more serious in RRH. 4.2 Security Analysis on the routing path inside the NEMO nested mobile network This looks like an insider attack. Any MR including the root MR can eavesdrop, drop, modify, delay and replay any packet in the path. In the following analysis, we assume that MR3 is a malicious MR. 4.2.1 Leakage of topology information MR3 can learn the topology information about the subtree rooted at itself, the path from the root MR to itself directly from the RRH header and the topology information from MR7 by eavesdropping since MR3 and MR7 share the LAN. Compared with in NEMO basic support, ESP can prevent the topology information of such subtree, the path to root-MR and the topology information from MR7 from being revealed. The inside malicious MR can cooperate with the outside adversary. By modifying the RRH header, the insider malicious MR forces the interesting packet to pass by the outside adversary in order to facilitate the cryptanalysis or make the topology information revealed easily. Zhao et. al. Expires January 2005 [page 4] Internet Draft Secure Reverse Routing Header July 2004 4.2.2 DoS attack Based on the topology information it knows, the malicious MR can consume the bandwidth and resource of other MR (upstream, downstream and neighbor MR) by extending or forming a loop in the RRH header. However in the NEMO basic support, the adversary can only attack the MRs in the subtree if ESP or IP-in-IP is used. The malicious MR3 can eavesdrop the RRH header in the outbound packet from MR7 and modify the RRH in order for the reply packet to attack either the upstream router or the downstream router. As it spoofs the topology-correct IP address of MR7, the ingress filtering of MR2 does not detect it. Also there is security check on the destination IP address in the reply (inbound) packet. If there are two malicious MR, MRi and MRj, they can collaborate to attack the MRs between MRi and MRj. 4.3 Other threats MR3 can intentionally fill up all the slots in the RRH header from MR4. Since the number of slots is limited, MR3 forces the upstream MR to forward the packet by the reverse tunnel between MR and HA. This attack belongs to the denial-of-service attack and greatly increases the round trip delay and other QoS performance. MR3 may also launch the redirection attack which is similar with in the NEMO basic support. 4.4 Summary Lack of similar ESP protection over IP addresses in the RRH header makes RRH more vulnerable than NEMO basic support. Some threats described above are inherently similar with those in the source routing. 5. Security Mechanism 5.1 Hop-by-hop authentication and encryption Each MRi except the first MR generates and uses a secret key, Ki, to authenticate and encrypt the RRH header it receives. In the following context, E(Ki, *) represents the encryption operation, A(Ki, *) represents the authentication operation, the content of slot i is denoted by si and "||" represents the concatenation. Note that as the first MR in the path, MR3 does not need to do the following encryption and authentication because HA3 needs MR3_HoA in the clear text and MR3_HoA can be already included in the end-to-end authentication. The order of operation is authentication after encryption. The packet is sent from the first MR, MR3 as follows. Zhao et. al. Expires January 2005 [page 5] Internet Draft Secure Reverse Routing Header July 2004 <-------------- outer IPv6 header --------------------> +-------+-------++ -- ++----+-------+-------+---------+ +------- |oSRC |oDST |: :|oRRH| slot2 | slot1 | slot0 | | |MR3_CoA|MR3_HA |:oEXT:|type| | |MR3_HoA | |iPACKET | | |: :| 4 | | | | | +-------+-------++ -- ++----+-------+-------+---------+ +------- MR2 sent the packet as follows. <-------------- outer IPv6 header ---------------------> +-------+-------++ -- ++----+-------+--------+---------+ +------- |oSRC |oDST |: :|oRRH| slot2 | slot1 | slot0 | | |MR2_CoA|MR3_HA |:oEXT:|type| |MR3_CoA |MR3_HoA | |iPACKET | | |: :| 4 | | | | | +-------+-------++ -- ++----+-------+--------+---------+ +------- | E(K2,s1) | |<- A(K2, s1||s0)->| MR1 sent the packet as follows. <-------------- outer IPv6 header ----------------------> +-------+-------++ -- ++----+--------+--------+---------+ +------- |oSRC |oDST |: :|oRRH| slot2 | slot1 | slot0 | | |MR1_CoA|MR3_HA |:oEXT:|type|MR2_CoA |MR3_CoA |MR3_HoA | |iPACKET | | |: :| 4 |E(K1,s2)|E(K2,s1)| | | +-------+-------++ -- ++----+--------+--------+---------+ +------- |E(K1,s2)|E(K2,s1)| |<- A(K2, s1||s0)->| |<- A(K1, s2||s1||s0) ->| Since HA3 only copies and pastes the RRH header without any processing, HA3 does not need to understand the content of RRH header by sharing this secret key with any MR. The reply packet should equip with the same RRH header. MR1 will verify the MAC value of RRH header. If successful, MR1 decrypts the RRH header and forward to the next MR; otherwise it drops the packet silently. Other MRs will verify and decrypt the RRH header recursively until it reaches the final destination. We can use any encryption algorithm and the cipher text can be just put in the slot to replace the IP address. A specific field is needed to store the MAC value. Nowadays for a keyed hash function to be secure, the output should be at least 80 bits. The detailed format will be designed later. Compared with IPSec ESP tunnel mode in NEMO basic support, it greatly reduces the computation overhead since the time to generate the cipher text and MAC is proportional to the length of input, just a few bytes in the RRH header here rather than the whole packet in ESP tunnel mode. Zhao et. al. Expires January 2005 [page 6] Internet Draft Secure Reverse Routing Header July 2004 We may also want to prevent the replay attack by using the timestamp or sequence number. The detailed format will be designed later. MR3 achieves more anonymity than in RRH since the adversary does not know the path to MR3. It also prevents the adversary forging any slot in the RRH header. Since the adversary does not know the private key, the forged slot will be detected and the compromised packet will be dropped. This scheme still needs a lot of cryptography operations and a lot of space to store the MAC. (In the RRH draft, the maximum number of slots allowed is 10.) In the following we propose a lightweight solution in an end-to-end fashion. 5.2 Security mechanism to address the threats in the Internet To address the threats in the Internet, we aggregate the authentication and encryption done by the intermediate MRs. So only the root MR needs to do these operations. This assumes the root-MR is trustable because we focus on the threats in the Internet which happen more likely than inside the nested mobile network. Compared with the cost and protection, we believe that this is a feasible solution. 5.2.1 RRH Authentication to provide the integrity protection The root MR will generate a secret key, K and use the keyed hash function, for example, HMacMD5 or HmacSha1, to generate the MAC code of the RRH header in the outbound packet and verify the MAC code in the inbound packet. Note that the root MR does not share this key with any other entity. Besides the IP addresses inside the RRH header, the root MR may also use the timestamp or sequence number to prevent the replay attack. 5.2.2 RRH Encryption to provide the confidentiality The root MR uses a secret key, K, to encrypt the RRH except the bottom slot in the outbound packet and decrypt the RRH in the inbound packet. Note that encryption alone is not secure, so the authentication is usually needed to protect the integrity. 5.3 Security enhancement to address the inside threats The ingress filtering is not enough to prevent the inside attack. We propose to check not only the source IP address but also the destination IP address. This check is done by each MR based on the local topology information, such as IP addresses of the adjacent upstream MR and adjacent downstream MR. Some kind of loop can be detected. 5.4 Routability probe to address both inside and outside threats Since MR does not have the path information before sending the packets, MR cannot include the RRH in the end-to-end security. We assume that there is no topology change within one round trip delay and introduce the "Routability probe" to collect the RRH before sending the packet. Zhao et. al. Expires January 2005 [page 7] Internet Draft Secure Reverse Routing Header July 2004 5.4.1 Routability probe In this test, MR probes the path between itself and root-MR. MR sends a specific probe packet to collect the IP address of MRs in the path to TLMR. The intermediate MR fills the RRH header in this probe packet just as in the RRH draft and will also check the RRH header based on its local topology information (It is reasonable to assume that MR knows the adjacent upstream and downstream MR information. If MR does not know at all, it may just let it pass. ) as in 5.3. If the RRH header fails in this check, it will be dropped. When root-MR receives the probed packet, it will generate the MAC on the RRH header using its public key, and return the probe packet and MAC to the MR. The intermediate MR will verify the MAC. If the verification is successful, the intermediate MR will do the local check. Note that the malicious router cannot modify the RRH header after root- HA signs it. Thus the RRH header becomes evidence if the malicious MR forges the RRH header. If it is detected, although the intermediate MR cannot tell exactly who is the malicious MR, it can launch an alert or invoke a stronger security protection to resist the attack or drop it to avoid the damage. 5.4.2 The rest of procedure If no attack is detected, the probe packet will arrive at the sending MR. After successfully verifying the MAC generated by the root-MR, MR includes the RRH header into the end-to-end SA with its HA. The CN verifies the received packet based on the end-to-end SA. If successful, it will generate the reply packet based using the same SA with MR. The RRH header and the MAC generated by root-MR are also included. Root-MR verifies the received RRH header before forwarding to the destination. The intermediate MR will verify the MAC. If the verification is successful, the intermediate MR will do the local check. 5.4.3 Summary This proposal only uses one cryptography operations by root-MR. We use the public key of root-HA just because there is no pre-shared key between root-HA and other MRs. Routability probe before sending the packet makes the intermediate MRs have opportunities to detect the attack as early as possible. If the first MR can receive the probe packet within one round trip delay, it means that there is no loop or this routing path taken by the probe packet really works. Note that the first MR does not have to probe every time before sending the packet. It may just do it when some problem happens. It is efficient but at the cost of one round trip delay. Zhao et. al. Expires January 2005 [page 8] Internet Draft Secure Reverse Routing Header July 2004 6. Security considerations This document comes with up some new threats that are more dangerous than in the NEMO basic support protocol. We contemplate the cause of such risks and propose the countermeasure to effectively resist the attacks. We hope this document will help understand the problem and result in a secure and efficient route optimization solution. References: [1] T. Ernst, "Network Mobility Support Goals and Requirements", draft-ietf-nemo-requirements-02, Work in Progress, February 2004. [2] T. Ernst, and H-Y. Lach, "Network Mobility Support Terminology", draft-ietf-nemo-terminology-01, Work in Progress, February 2004. [3] V. Devarapalli, R. Wakikawa, A. Petrescu, and P. Thubertet, "Network Mobility (NEMO) Basic Support Protocol", IETF proposed standard, draft-ietf-nemo-basic-support-03, June 2004. [4] D. Johnson, C. Perkins, and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2003. [5] C. Ng, J. Charbon, E. Paik, and T. Ernst, "Analysis of Multihoming in Network Mobility Support", draft-ng-nemo- multihoming-issues-03.txt, Work In Progress, February 2004. [6] J. Arkko, V. Devarapalli, and F. Dupont, "Using IPsec to Protect Mobile IPv6 Signaling between Mobile Nodes and Home Agents," RFC 3776, June 2004. [7] S. Bradner. "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [8] P. Thubert, M. Molteni, C. Ng, H. Ohnishi, and E. Paik, "Taxonomy of Route Optimization models in the Nemo Context", draft-thubert-nemo-ro-taxonomy-02, Work in Progress, February 2004. [9] P. Thubert, and M. Molteni, "IPv6 Reverse Routing Header and its application to Mobile Networks", draft-thubert-nemo- reverse-routing-header-05, Work in Progress, June 2004. [10] T. Tanaka, and C. Ng, "Securing Nested Tunnels Optimization with Access Router Option", draft-ng-nemo-access-router- option-00, Work in Progress, November 2002. Zhao et. al. Expires January 2005 [page 9] Internet Draft Secure Reverse Routing Header July 2004 Authors' Addresses Fan Zhao Department of Computer Science University of California, Davis One Shield Avenue Davis, CA 95616 USA Phone: +1-530-752-3128 EMail: fanzhao@ucdavis.edu Felix Wu Department of Computer Science University of California, Davis One Shield Avenue Davis, CA 95616 USA Phone: +1-530-754-7070 EMail: wu@cs.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 HyunGon Kim Network Security Department ETRI 161 Kajong-Dong, Yusong-Gu Taejon 305-600 KOREA Phone: +82-42-860-5428 Email: hyungon@etri.re.kr Zhao et. al. Expires January 2005 [page 10] Internet Draft Secure Reverse Routing Header July 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 (2003). 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. Zhao et. al. Expires January 2005 [page 11]