NEMO Working Group Souhwan Jung Internet-Draft Soongsil University Expires: April, 2004 Fan Zhao Felix Wu UC Davis HyunGon Kim SungWon Sohn ETRI October, 2003 Threat Analysis for NEMO draft-jung-nemo-threat-analysis-01 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 December 22, 2003. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract This document describes possible security threats on mobile networks. Many different kinds of security threats exist on signaling and communication paths including mobile routers and home agents. It is also the goal of this draft to explain a three-layer threat model, to investigate vulnerabilities to the network entities in NEMO, and finally to propose security requirements for NEMO. 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. S. Jung et. al. Expires April, 2004 [Page 1] Internet-Draft Threat Analysis for NEMO October 2003 Table of Contents 1. Motivations 2. Three-Layer Threat Model 3. Generic Threats to Target Protocols/Services 3.1 Threats to Signaling Paths 3.2 Threats to Communication Paths 4. Generic Threats to Target Entities/Entry Points 4.1 Misbehaviour of MR 4.2 Misbehaviour of HA 4.3 Traffic Analysis 4.4 Denial of Service 5. Threats specific to NEMO basic support protocols 5.1 Corruption of Binding Cache by inside attacker 5.2 Attack using HA as a stepping stone 5.3 Attack to Location Privacy by Traffic Analysis 6. Security Requirements References Authors' Addresses Intellectual Property and Copyright Statements S. Jung et. al. Expires April, 2004 [Page 2] Internet-Draft Threat Analysis for NEMO October 2003 1. Motivations Networks in motion (NEMO) introduces a new network entity called Mobile Router(MR)[2]. MR has different features from Mobile Host that is operated based on Mobile IP technologies[4]. Since MR functions both as a mobile node and a gateway to provide mobile network with Internet access to outside world, it needs specific treatment for managing operations and securities. In real world, many different types of NEMO configurations are possible including multi-homing, which means that new kind of threats specific to NEMO SHOULD be taken care of. For example, MR can advertise its IP prefix to the VMNs in its mobile network, and this RA message can be intercepted and modified to advertise the prefix of malicious router. This makes address spoofing attack possible: the packets that should be delivered to the destination mobile router are redirected to the attack router. Therefore, those messages like RA should be protected using authentication. This draft proposes a three-layer threat model for analyzing vulnerabilities to NEMO protocols and entities. Based on the model, we describe and classify all possible threats to NEMO, and analyze those threats according to their properties and scopes. Finally, we describe the security requirements for NEMO. 2. Three-Layer Threat Model Many different threats to network entities in NEMO are possible and hard to describe all of them in a row. Some of the threats can have multiple paths to achieve their goals, which means that many different types of attacks are possible to obtain the same objective that the attacker tries to achieve. Therefore, it requires a hierarchical threat model to describe and classify all different types of threats to NEMO. This draft proposes a three-layer threat model to describe possible threats to NEMO according to their objectives/properties, target protocols/services, and target entities/entry points. This model is composed of a three-layer stack; objectives/properties on the top layer, target protocols/services for attack on the second layer, and finally target entities or entry points for attack at the bottom layer. S. Jung et. al. Expires April, 2004 [Page 3] Internet-Draft Threat Analysis for NEMO October 2003 The objectives of threats are usually a limited number of goals that attackers try to achieve in abstract level. They could be like eavesdropping of data, impersonation, data corruption or modification, unauthorized use of resources, repudiation, and blocking services to clients. The generic goals of security mechanisms against those attacks therefore are such as confidentiality, integrity, authentication, authorization, non-repudiation, and service availability, which are common to all of the security frameworks. The second layer of the stack is composed of target protocols or services for attack. Attackers always try to find vulnerabilities to network protocols or services by monitoring protocol or service data specific to the target. In NEMO, for example, binding update(BU) message or router advertisement(RA) messages by MRs could be target data for attack. Most of NEMO signaling protocols could be the target at the second layer. Therefore, the vulnerabilities to the basic NEMO mechanism should be scrutinized for the analysis. In the next section, this draft will describe those vulnerabilities and possible threats related to them. The bottom layer of the threat model is comprised of target entities or entry points for attacks. NEMO includes many network entities called MR, HA, CN, and MNN etc. Any of these entities could be a victim for attack, and be compromised. All the possibilities of different types of attacks should be investigated based on the assumption of these compromises. For example, the compromise of MR can result in the data interception of the MNNs inside or the deception of their connection to a fake HA or FA. The MNNs have no knowledge of the compromised MR, since the NEMO protocols are transparent to the MNNs. In section 4, those threats will be analyzed and described. 3. Threats to Target Protocols and Services This section describes threats to NEMO protocols and services. NEMO operations are composed of two different planes; one is the signaling plane for exchanging control or routing information, and the other is the communication plane for exchanging data between nodes. The threats specific to each plane will be investigated. 3.1 Threats to Signaling Paths The basic NEMO operations have three different signaling paths between entities; the first path is the signaling between MR and FA, the second one is the signaling between MR and HA, and the final one is the signaling between MNN and CN. Each signaling messages can be interrupted and modified by attackers on the way of the signaling paths. The following threats exist over signaling paths. S. Jung et. al. Expires April, 2004 [Page 4] Internet-Draft Threat Analysis for NEMO October 2003 - Man-in-the-middle between MR and HA This threat means that an attacker resides between MR and HA, and intercepts the signaling messages such as CoA(Care-of-Address) in BU messages. The messages could be modified and transferred to the HA with corrupted information. For example, the attacker compromises the access router, and intercepts and modifies all the messages that goes through the access router. One of the attack results will be the registration of MR to HA with wrong binding information. Security mechanism for bi-directional tunneling like IPsec could prevent this threat. - Discard registration messages from MR to FA This threat is a sort of DoS attack to block network connectivity service to MR. The attacker compromises the FA, and keep discarding the registration message from MR. The result of the attack is no availability of network connection service to the mobile networks. - Spoofing MR Mobile network could have multiple MRs for the case of multi-homing. Assume that there is a mobile network with a single MR. The fake MR claims to be the second MR for multihoming the victim mobile network, and register to HA with another spoofed IP prefix. The fake MR advertises its spoofed IP prefix to the new VMNs that comes into play. Then the victim VMN gets the wrong IP address from the fake MR, and starts to communicate via the fake MR. - Corrupted routing information Attacker may send corrupted routing information to MR and cause network instability such as network congestion or looping. If the MR is in the visited domain, it will not respond to the unsolicited RA. But while the MR is in home domain, it still accepts the RA messages, and may get screwed up with wrong routing information. 3.2 Threats to Communication Paths - eavesdropping/replay of messages between MR and HA All the data packets between MR and HA have to go through the bi-directional tunnel. This tunnel should be secured by IPsec. But some of the routing information that may not go through this tunnel should be secured. - eavesdropping/replay of messages between MNN and CN The messages between MNN and CN are going through the bi-directional tunnel, but there is no protection against sniffing data between MR and MNN or between HA and CN. So security mechanisms should be applied on the part of the path uncovered. - location privacy Monitoring and analyzing the characteristics of data traffic along the communication paths reveals some information on routing and location privacy. S. Jung et. al. Expires April, 2004 [Page 5] Internet-Draft Threat Analysis for NEMO October 2003 4. Threats to Target Entities The basic network entities in NEMO are MR, HA, FA, CN on the main network, and LFN, LMN, and VMN in the mobile network. Any of these entities could be the target for attack. We will investigate possible threats caused by compromising the network entities like MR, HA, and FA. The compromise of an entity means that attacker can access the entity, and change or modify data inside the system. The following attacks are possible with the compromise of each entity. The authentication mechanism for each entity therefore should be applied. 4.1 Misbehavior of MR MR is the most critical network component for the successful operations in NEMO, thserfore, the correct operation of MR SHOULD be assured. Most other routers have their own security functions which MAY not enough to protect MR. The following are the security threats which MAY be caused by misbehavior of MR. HA need to check whether MR works correct. - MR-HA spoofing MR-HA is the permanent address assigned statically or dynamically to the MR by HA. MR-HA should be used for identification of MR while it is in the visited domain. The compromised MR can register to FA with a spoofed MR-HA, and try to collect data destinated to the victim address. - MR-CoA spoofing MR-CoA is the Care-of-Address assigned to the egress interface of MR by AR. The compromised MR can send a BU message to HA with a spoofed CoA, and collect the data that were destinated to the victim AR. - Cache poisoning The cache data for routing table in MR can be corrupted to subvert routing path. The data packet could be redirected or looped causing network instability. 4.2 Misbehavior of HA - sniffing of tunneled packet The IPsec transport mode should be used for securing the tunneled packets between MR and HA. With the compromise of the HA, the attacker can sniff the decrypted data packet in HA. - corruption of binding cache HA keeps managing the BU information on binding cache. With the corruption of binding information, the attacker can redirects packets to where he want to deliver them. 4.3 Traffic Analysis The location of MR or MNN inside the subnet may be the privacy of the client, so the location information while network is in motion should be secured. Attacker can analyze the header information MR-CoA in the tunneled data packet and identify the location of the MR. Since all the data packets between MNN and CN are also tunneled using MR-CoA as a new source address, the location of the MNN can also be disclosed. 4.4 Denial of Service Denial of Service attack is possible against MR and HA by flooding BU messages and bogus tunneled packets. The attack can be more effective with distributed fake MRs or HAs. S. Jung et. al. Expires April, 2004 [Page 6] Internet-Draft Threat Analysis for NEMO October 2003 5. Threats specific to the NEMO basic support protocol 5.1 Corruption of Binding Cache by inside attacker The network configuration vulnerable to this attack is as follows. A MR has the function of NAT server, and there is a malicious MNN inside the mobile network. The malicious MNN spoofs a BU message of the MR, and send it to the MR. Assumptions The following analysis assumes: 1. The BU packet from MR is requird to be protected by ESP transport SA between MR and HA. For exmaple, SA: src=CoA and dst=HA -> ESP transport HMACMD5 3DES 2. The packets from MMN are encapsulted by IP-in-IP tunnel or IPSec tunnel SA between MR and HA. For example, IP-in-IP: scr=MNP and dst=any -> IP-in-IP tunnel, outer_src=CoA and outer_dst=HA 3. We assume that IP-in-IP and IPSec tunnel SA are executed after NAT/NAPT. NAT after IPSec tunnel will violate the SA and NAPT doesn't have the port number to work with. The same thing to IP-in-IP. A list of all possible attacks and countermeasures without NAT: 1. MMN spoofs the CoA of MR; MR will drop any packets received whose source IP address is CoA. 2. MMN spoofs the CoA of nested MR; However, MMN can not forge the ESP authentication data. HA will drop it. |-----HA----| |----------MR--------| |---------MN----------| | | | | | | | |-----| | | |-----| |-----| | | |--------| | | |IPSec|<===3===|-|IPSec|<=2=| NAT |-|<===1===| MNN | | | |-----| | | |-----| |-----| | | |--------| | | | | | | | | |-----|-----| |--------------------| |---------------------| 4 | V |---------------| | Binding Cache | |---------------| |1| MR-HA CoA | |2| MR-HA CoA | | ...... | |---------------| S. Jung et. al. Expires April, 2004 [Page 7] Internet-Draft Threat Analysis for NEMO October 2003 1. Malicious MNN makes the following packet and sends it to MR. |------------------------------| | source IP address = MNN | |------------------------------| | destination IP address = HA | |------------------------------| | ...... | |------------------------------| | src port=any | dst port | |------------------------------| | ...... | |------------------------------| | BU Options (MNP, CoA) | |------------------------------| 2. Assume that NAPT is used... |------------------------------| | source IP address = CoA | |------------------------------| | destination IP address = HA | |------------------------------| | ...... | |------------------------------| | src port=any* | dst port | |------------------------------| | ...... | |------------------------------| | BU Options (MNP, CoA) | |------------------------------| Since NATP changes the source IP address into one globally routable one, in this case, the only choice is CoA address of MR. If there are multiple globally routable IP addresses associated with MR and NAT is used, it may not cause problems as long as source IP address is not changed into CoA. 3. If MR can't distinguish the NATed BU packets from those sent by itself (Assume that BU sent from MR itself uses CoA as the source IP address. It is a reasonable assumption since only ESP transport mode is used. ), MR will use ESP transport mode to process the NATed BU packets. |------------------------------| | source IP address = CoA | |------------------------------| | destination IP address = HA | |------------------------------| | ESP | |------------------------------| | ...... | |------------------------------| | src port=any* | dst port | |------------------------------| | ...... | |------------------------------| | BU Options (MNP, CoA) | |------------------------------| S. Jung et. al. Expires April, 2004 [Page 8] Internet-Draft Threat Analysis for NEMO October 2003 The solution to this attack is that MR will check the source port number in the BU packet with the NAPT mapping table where any used port number has an entry. If there is such entry, MR will know this packet is from MNN, thus MR will use IP-in-IP tunnel to encapsulate it. Otherwise MR will use ESP SA to process it. For the purpose of efficiency, it is better to resist the attack as early as possible. The list of other possible solutions: - MR will check the type of packets from MMN. However, MR can't drop BU from MMN because MNN can be a nested MR. - MR will check the type of packets from MMN and only allow BU transformed by ESP transport SA. However, MR can not verify such packets. Thus, attackers may still launch DoS attack to HA. - MR may enforce the authentication in MN in order to make any attack accountable. 4. HA will decapsulte and verify this incoming packet. If the verification is successful, HA believes that BU is from MR and updates the binding cache accordingly. Because HA can notice that it receives the BU from SA between CoA and itself but mobility option indicates a different CoA, HA will get confused. If HA accepts this BU, the binding cache will be polluted by attackers. The success of this attack depends on how the MR acts when it process the fake packet. The MR MAY just drop the packet because it has the same source address of itself, or process the packet using IPsec traport mode. We performed an experiment using Microsoft Window2000 as a NAT server configuring with IPsec transport mode, which shows that this threat is realistic. In the experiment, the fake packet from a node inside mobile network could go through the Window2000 NAT server (this could be a MR in NEMO case) to a machine in outside networks (this could be a HA in NEMO case) wrapped into the IPsec ESP encapsulation in transport mode. Since the current IPsec documents do not describe the details of specification for the case of NAT server configured with IPsec, the MR SHPULD take care of this potential vulnerability. For example, the MR SHOULD distinguish the data packet from itself or inside node. For MIP, this vulnerability doesn't exist, because there is no reason for a MN to forward a fake packet from the attacker using its own IPsec SA. Therfore, this attack is very specific to NEMO protocol. S. Jung et. al. Expires April, 2004 [Page 9] Internet-Draft Threat Analysis for NEMO October 2003 5.2 Attack using HA as a stepping stone NEMO basic support draft suggests that the data packets from MMN SHOULD be encapsulted by IP-in-IP tunnel. However, HA may become the stepping stone to attackers. The following figure shows this threat. In the figure, malicious packets from MNN encapsulated in IP-in-IP tunnel can go through MR and HA to be deivered to the victim machine. The potential threats are IP spoofing, DoS attack etc. |-----| |----| |-----| | HA |===2===| MR |===1===| MNN | |-----| |----| |-----| | 3 | |------| |victim| |------| 1. Src=spoofed IP address dst=victim data payload 2. outer_src=CoA outer_dst=HA src=spoofed IP address dst=victim data payload 3. src=spoofed IP address dst=victim data payload This threat MAY not only be specific to NEMO, but also to any routers configured with IP-in-IP tunnel without any associated security mechanisms. However, this threat could be more serious due to the heavy usage of IP-in-IP tunnel in NEMO. 5.3 Attack to Location Privacy by Traffic Analysis In the basic NEMO configurations, all the traffic from mobile network are supposed to go through the bi-directional tunnel between MR and HA. The HA can collect all the packets in IP-in-IP tunne, decapsulates them, and forwards them to the CNs. |-----| |----| IP-in-IP tunnel |----| |----| | MNN |---------| MR | ================== | HA |---------| CN | |-----| 1 |----| 2 |----| 3 |----| The outside attacker can monitor the traffic in path 2 and 3. The time variations of traffic in a specific tunnel between a specific MR and HA may have a similar pattern to the time variation of traffic on a channel between HA and a specific CN. By the statistical analysis on the time interval of peak traffic, the attacker can find a correlation between incoming and outgoing traffic pattern of HA, and finally finds the same connection to extract the CoA information from the packet on path 2 and the HA of MN from packet on path 3. This means that the particular MN is located in the region of that particular CoA. This attack is not only specific to NEMO, but due to the mandatory use of bi-directional tunnel, this attack can be more serious in NEMO. S. Jung et. al. Expires April, 2004 [Page 10] Internet-Draft Threat Analysis for NEMO October 2003 6. Security Requirements for NEMO The basic support protocol for NEMO is based on the MIPv6 operations except the bi-directional tunnel operations between MR and HA. Therefore, most of the security requirements are already addressed in MIPv6 WG documents[4], so this draft describes the security requirements only against new threats in NEMO. The following security requirements SHOULD be addressed in NEMO basic and extended documents. 6.1 MR SHOULD check the contents of the packet from MNN inside , and assure that the packet does not include fake information in the critical messages such as BU, prefix discovery, or ICMP messages. 6.2 The IP-in-IP encapsulated packet SHOULD be authenticated between MR and HA, and per-packet authentication at MR SHOULD be enforced. 6.3 The amount of traffic from MNN through the IP-in-IP tunnel SHOULD be secured to protect the location privacy against traffic analysis. The amount of traffic through IP-in-IP tunnel MAY be secured using expanded field as in IPsec ESP[10]. 6.4 HA SHOULD make sure that the MR is working correctly. To check the right operation of MR, HA need to periodically send test messages, and get the responses from MNN or CN. A scheme similar to return routability MAY be used for this purposes. 6.5 The threats to new messages related to RO for extended NEMO SHOULD be protected, but those threats will depends on what sort of RO mechanism is used. The right security mechanism for extended NEMO SHOULD be added later. S. Jung et. al. Expires April, 2004 [Page 11] Internet-Draft Threat Analysis for NEMO October 2003 References [1] Ernst, T., et al, "Network Mobility Support Goals and Requirements", Internet Draft: draft-ietf-nemo-requirements-01.txt, Work In Progress, May 2003. [2] Ernst, T. and H. Lach, "Network Mobility Support Terminology", Internet Draft: draft-ietf-nemo-terminology-00.txt, Work In Progress, May 2003. [3] Wakikawa, R., et al, "Basic Network Mobility Support", Internet Draft: draft-wakikawa-nemo-basic-00.txt, Work In Progress, February 2003. [4] Johnson, D. B., Perkins, C. E. and Arkko, J., "Mobility Support in IPv6", Internet Draft: draft-ietf-mobileip-ipv6-21.txt, Work In Progress, February 2003. [5] Barbir, A. and et. Al, "Generic Threats to Routing Protocols", Internet Draft: draft-ietf-rpsec-routing-threats-01, April 2003. [6] Kniveton, T. J., et al, "Mobile Router Tunneling Protocol", Internet Draft: draft-kniveton-mobrtr-03.txt, Work In Progress, November 2002. [7] Petrescu, A., et al, "Issues in Designing Mobile IPv6 Network Mobility with the MR-HA Bidirectional Tunnel (MRHA)", Internet Draft: draft-petrescu-nemo-mrha-00.txt, Work In Progress, October 2002. [8] Ng, C. W. and Tanaka, T., "Securing Nested Tunnels Optimization with Access Router Option", Internet Draft: draft-ng-nemo-access-router-option-00.txt, Work In Progress, October 2002. [9] Arkko, J. et. al. ,Using IPsec to Protect Mobile IPv6 Signaling between Mobile Nodes and Home Agents,í˜ Internet Draft: draft-ietf-mobileip-mipv6-ha-ipsec-04.txt, March 2003. [10] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998. [11] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998. [12] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998. S. Jung et. al. Expires April, 2004 [Page 12] Internet-Draft Threat Analysis for NEMO September 2003 Authors' Addresses Souhwan Jung Soongsil University 1-1, Sangdo-dong, Dongjak-ku Seoul 156-743 KOREA Phone: +82-2-820-0714 EMail: souhwanj@ssu.ac.kr 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 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 SungWon Sohn Network Security Department ETRI 161 Kajong-Dong, Yusong-Gu Taejon 305-600 KOREA Phone: +82-42-860-5072 Email: swsohn@etri.re.kr S. Jung et. al. Expires April, 2004 [Page 13] Internet-Draft Threat Analysis for NEMO September 2003 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. S. Jung et. al. Expires April, 2004 [Page 14]