NEMO Working Group Souhwan Jung Internet-Draft Soongsil University Expires: January 19, 2005 Fan Zhao S. Felix Wu UC Davis HyunGon Kim SungWon Sohn ETRI July 19, 2004 Threat Analysis on NEMO Basic Operations draft-jung-nemo-threat-analysis-02 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 August, 2004. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract This document describes potential security threats to NEMO basic operations. The threats are mostly related to the integral use of IPsec and IP-in-IP tunnel between MR and HA. Other threats related to the operations of multiple MRs, and potential DoS attacks on MR and HA are also investigated. S. Jung et. al. Expires January, 2005 [Page 1] Internet-Draft Threat Analysis on NEMO basic operations July 2004 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. Table of Contents 1. Introduction 2. Assumptions 3. Threats to interactions between MR and HA 3.1 Attacks to the MR-HA IPsec Transport SA 3.1.1 BU spoofing attack without ingress filtering at MR 3.1.2 BU spoofing attack with ingress filtering at MR 3.2 Attacks to MR-HA tunnel 3.2.1 Attack from inside 3.2.2 Attack from outside 3.3 Attacks to the signaling messages 4. Threats to interaction among MRs 4.1 Attacks to multihomed MRs 5. DoS attacks to MR or HA Changes from previous version References Authors' Addresses Intellectual Property and Copyright Statements 1. Introduction NEwork MObility (NEMO) introduces a network entity called Mobile Router(MR)[2]. MR has different features from mobile host that operates 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. The MIP/NEMO community has spent quite a lot of efforts in designing security mechanisms to protect critical control messages exchanged among protocol entities such as HA (Home Agent), MN (Mobile Node), or MR (Mobile Router in NEMO). In particular, the authenticity and integrity of the Binding Update (BU) messages SHOULD be protected very well. S. Jung et. al. Expires January, 2005 [Page 2] Internet-Draft Threat Analysis on NEMO basic operations July 2004 Otherwise, many malicious attacks such as traffic hijacking or denial of service are possible by intentionally injecting incorrect BU messages. Under both MIP6 and NEMO, IPsec Transport ESP (Encapsulating Security Payload) [8] is used to protect the binding update messages between HA and MN/MR. IPsec itself provides a network layer security service between two network entities, and it nicely integrates a number of strong cryptographic components under its architecture. Due to this strong fact of IPsec security, many Internet protocols, especially in the network layer, have been built on top of the security strength of IPsec. The list is currently growing, but at least, we can include OSPFv6, TRIP (Telephony Routing over IP, under the IP Telephony working group), RSVP/NSIS (Next Step in Signaling), L3VPN, PANA (Protocol for Authentication and Network Access), MobileIP and NEMO. While IPsec itself is indeed quite secure, the security of the protocols using IPsec might still be very questionable. In fact, through our security analysis toward NEMO, we realize that the IPsec architecture itself does NOT specify/mandate its relationship with other functional components (such as packet forwarding, ingress filtering, IP-in-IP tunnel, or application interface) in the same router. Therefore, as will be shown later, most of the IPsec implementers have not considered how to properly glue the IPsec engine with the rest of the system such that the whole system (such as the MR in NEMO) can be easily broken in. In short, IPsec by itself is indeed doing its job securely, but the component putting packets into the IPsec module might not. This draft describes vulnerabilities to the basic operations of NEMO, and discussed its potential security problems, especially, related to IPsec and other tunneling functions. 2. Assumptions Many different types of threats to NEMO were described by [11] and [12]. But most of the threats can be easily protected by using existing IPsec AH/ESP through the bi-directional tunnel between MR and HA. Some of threats are not specific to NEMO basic operations, but generic to Mobile IP or host security. The generic threats to NEMO basic operations can be classified into three different categories: threats on the tunnel between MR and HA, threats on the path among multiple MRs, and threats to the MR and HA themselves. S. Jung et. al. Expires January, 2005 [Page 3] Internet-Draft Threat Analysis on NEMO basic operations July 2004 Since many serious attacks are possible with a compromised MR/HA, we get rid of the threats derived from a compromised MR/HA. Therefore, we assume the following conditions for further discussion of generic threats to basic NEMO operations. 2.1 The IPsec AH/ESP security mechanisms are activated on MR-HA tunnels. 2.2 No compromise of the prefix and binding cache tables in HA. 2.3 No compromise of critical information like MNP and HoA on MR. 2.4 Multiple HAs have their own trust relationships provided by ISP. 2.5 No current security mechanisms are applied among multiple MRs. 3. Threats to interactions between MR and HA The major threats to the basic operations of mobile network are from the tunneling operations. Tunneled packet can disguise itself using fake source and destination addresses. The MR or HA should be responsible to verify the validity of those packets. Since the basic operation of mobile network is based on the IPsec tunnel and IP-in-IP tunnel between MR and HA, the threats to those tunneling operations will be investigated in this section. 3.1 Attacks to the MR-HA IPsec Transport SA Two different potential attack scenarios are presented in this section. 3.1.1 BU spoofing attack: no ingress filtering at MR The first case assumes that there is no ingress filtering activated at MR. Figure 1 shows the attack scenario. In the Figure 1, a malicious MNN generates a spoofed packet by setting source address to the HoA of the MR and destination address to the address of HA, and also includes the BU of MR as a payload. The format and contents of the BU message look exactly like a BU from the MR. When the MR received the packet from the attacker, it first saves the packet to the buffer, and checks the security policy database (SPD) of the packet. Since the MR cannot tell the fake packet from the packet from itself at this point, it finds that the packet requires the IPsec processing, and forwards it to the security interface for IPsec processing. Then the IPsec module encapsulates the packet using the ESP transport mode and the associated SA. When the HA received the packet, it verifies the packet by checking the IPsec ESP SA that will be valid because it is encapsulated by a valid MR. Finally, the HA is fooled to believe that the BU is from the MR, and updates the binding cache of itself. S. Jung et. al. Expires January, 2005 [Page 4] Internet-Draft Threat Analysis on NEMO basic operations July 2004 MNN MR HA |--------| |----------------| |-----------| | | | |-------|| ESP | |-------| | |Attacker|---------->|-------| IPSec ||====================| | IPSec | | | | | | ^ |-------|| Transport | |-------| | |--------| | |-|--------------| | |-----------| | At this point, MR | checks the packet | cannot tell the fake | using ESP and |-----------| BU from a BU from |-----------| updates Binding |Src=HoA | itself, and applies |Src=CoA | Cache (corrupts |Dst=HA | IPSec ESP. |Dst=HA | binding cache) |... | |ESP | |BU(MNP,CoA)| |... | |-----------| |BU(MNP,CoA)| Attacker |-----------| generates Packet is a fake BU encapsulated with ESP Figure 1. MNN spoofs the BU of the MR without ingress filtering This attack is possible due to two reasons. The first one is that the MR is not using ingress filtering to check the topological correctness of the source address. If the MR checks the source address of the packet, and finds that the source address is set to itself, then it will drop the packet. Another reason is that the MR forgets where the packet came from, once it gets the packets and saves to a buffer. If the MR can distinct the packet stream generated by other nodes (Layer2) from those by itself (Layer4), then the fake packet will not be processed by IPsec, and will be forwarded to HA encapsulated in an IP-in-IP tunnel. Then the attack will fail to modify the binding cache of the HA. 3.1.2 BU spoofing attack: with ingress filtering at MR This attack scenario is similar to the first scenario, but assumes the ingress filtering at the MR. Figure 2 shows the attack scenario. In this scenario, the attacker generates a spoofed BU message using IP-in-IP encapsulation as shown in the figure. Now, the outer source address is set to the address MNN and the destination address is set to the address of the MR. The inner source address is set to the HoA of MR and the inner destination address is set to the address of HA. This attack is possible due to the order of packet processing at the MR as shown in the figure. If the MR performs the ingress filtering at first, and then do the tunnel decapsulation, then the fake packet can get through the ingress filtering of the MR. The rest of the story S. Jung et. al. Expires January, 2005 [Page 5] Internet-Draft Threat Analysis on NEMO basic operations July 2004 is the same as the first scenario. If the MR do perform the ingress filtering after the tunnel decapsulation, the fake packet can be dropped at the MR in this scenario. Therefore, it is very important to implement multiple functions of the MR in the right order. In real world, the ingress filtering function of the routers are not activated in many cases, and then those routers are exposed to this type of attacks. MNN IP_in_IP MR HA |--------| packet is |----------------------------| |-----------| | | generated ||-------| |------| |-----|| ESP | |-------| | |Attacker|---------->||Ingress|-|tunnel|---|IPSec||===============| | IPSec | | | | | ||filter | |decap | ^ | || Transport | | | | | | | ||-------| |------| | |-----|| | | |-------| | |--------| | |-------------------|--------| | |-----------| | | | checks the |-------------| |-----------| |-----------| packet |Outer Src=MNN| |Src=HoA | |Src=CoA | using ESP |Outer Dst=MR | |Dst=HA | |Dst=HA | and updates |Src=HoA | |... | |ESP | binding |Dst=HA | |BU(MNP,CoA)| |... | cache |... | |-----------| |BU(MNP,CoA)| |BU(MNP,CoA) | At this point, MR cannot |-----------| |-------------| tell the fake BU from a BU Packet is Attacker generates from itself, and applies encapsulated a fake BU using IPSec ESP. with ESP IP-in-IP tunnel Figure 2. MNN spoofs a BU of MR with ingress filtering 3.2 Attacks to MR-HA tunnel Processing IP-in-IP packets in a mobile router requires encapsulation and decapsulation module with a dedicated protocol number. Securing IP-in-IP tunneled packets requires a specific security mechanism like IPsec tunnel mode encapsulation. The attacks to the IP-in-IP tunnel can initiate from inside of the mobile network to MR or from outside directly to HA. We will investigate two attack scenarios using MR and HA as stepping stones. 3.2.1 Attack from inside Figure 3 shows an attack scenario from inside nodes. In the scenario, an attacker generates a fake IP-in-IP packet setting the external source address to the address of another MNN inside the mobile network and the external destination address to the address of MR. Inside the encapsulation, the internal source address is set to a spoofed IP address and the internal destination address is set to the address of S. Jung et. al. Expires January, 2005 [Page 6] Internet-Draft Threat Analysis on NEMO basic operations July 2004 victim machine. Once the MR receives the packets, the MR decapsulates the packets, and recognizes to process the packets using IP-in-IP encapsulation and forward to the HA. Therefore, the MR encapsulates the inside payload in IP-in-IP format (external source address = CoA of MR, external destination address = address of HA), and sends it to HA. HA forwards the packet to the victim machine. The possible attacks from this scenario are IP spoofing or DoS attack to the victim machine. Similar attacks have been known to mobile network communities for a while, but the main point here is that MR can prevent this attack by checking ingress filtering after the GRE decapsulation. |--------| |--------| IP-in-IP |--------| |--------| | | | | tunnel | | | | | MNN |---------->| MR |==============| HA |-------->| Victim | | | | | | | | | | | | |--------| | |--------| | |--------| | |--------| inside | | | attacker | | |--------------| |--------------| |--------------| |Src=spoofed IP| |Ext. Src=MNN | |Ext. Src=CoA | |Dst=victim | |Ext. Dst=MR | |Ext. Dst=HA | |payload | |Src=spoofed IP| |Src=spoofed IP| |--------------| |Dst=victim | |Dst=victim | |payload | |payload | |--------------| |--------------| generates a spoofed IP packet Figure 3. Inside attack using MR and HA as stepping stone 3.2.2 Attack from outside In this scenario, similar attacks can be initiated from outside of a mobile network. Figure 4 shows the attack scenario. In the Figure 4, an attacker from outside can generate a spoofed IP-in-IP packet with setting the external source address to the CoA of MR and the external destination address to the address of HA, which includes a spoofed IP address as the internal source address, and the address of the victim machine as the internal destination address. If the access router of the outside attacker activates ingress filtering, this packet can be dropped at the access router. But many routers without ingress filtering will pass through this packet, and then HA may forward the packet to the victim machine. Due to this security problem, most routers do not process the IP-in-IP packets, but MR and HA in mobile networks should process IP-in-IP packets for S. Jung et. al. Expires January, 2005 [Page 7] Internet-Draft Threat Analysis on NEMO basic operations July 2004 forwarding the packets from MNN or CN. |--------| IP-in-IP |--------| |--------| | | tunnel | | | | | MR |==============| HA |--------------->| Victim | | | | | | | | |--------| |--------| | |--------| ^ | | |---------------| | |Src=spoofed IP | |---------------| | |Dst=victim | |Ext. Src=CoA | | |payload | |Ext. Dst=HA | | |---------------| |Src=spoofed IP |-------| |Dst=victim | | |payload | |---|outside |---------------| | |attacker generates a spoofed |---| IP-in-IP packet Figure 4. Outside attack using HA as a stepping stone 3.3 Modifications of the signaling messages Some part of the signaling messages between MR and HA are delivered in clear text. Therefore, this type of attacks are mostly related to the modification of the signaling messages between MR and HA. For example, the attacker on the path between MR and HA can modify the destination of BU/BA messages to a wrong destination. The mis-destined messages shall be dropped at the destination. Another type of attacks are possible by modifying the flag option bit (e.g. R bit) of the signaling messages. The modified signaling message can be ignored or processed incorrectly at the destination. 4. Threats to interactions among multiple MRs 4.1 Attacks to multi-homed MRs In case that two or more MR exists on a mobile subnet for multihoming, there may be multiple bi-directional paths to forward packet to a HA or multiple HAs respectively. S. Jung et. al. Expires January, 2005 [Page 8] Internet-Draft Threat Analysis on NEMO basic operations July 2004 If one of the tunnel paths is broken for any reason, the MR(MR1) associated with the faulty path loses Internet connection, and should find an alternative bi-directional tunnel path through another MR2. In this case, MR1 becomes a nested MR of MR2. NEMO basic draft[3] describes that MR SHOULD not respond to the unsolicited RA messages to its egress interface, but according to the MR operations by multihoming draft B.2.2 [6], the MR1 SHOULD listen the RA from alternative MR2 on its ingress interface. At this point, a malicious MR may advertise a RA with a fake CoA to MR1. Then the MR1 will get a wrong CoA information. This threat is not directly related to the NEMO basic operation, but to the inter-MR operations. There is no explicit security mechanism for inter-MR operations for multihoming cases, threats related to inter-MR operations SHOULD be considered. 5. DoS attack to MR or HA Attackers can initiate packet flooding attack to MR or HA using the MR-HA tunnel. For example, outside attackers can generate a flood of IP-in-IP packets using topologically correct external source address to avoid ingress filtering at their access routers, and make them delivered to the MR via the MR-HA tunnel. HA (or MR) have no way of filtering this type of packet flooding. This type of attack is also possible from inside of mobile networks, but It is not supposed to be common to initiate flooding attack from inside of the mobile network. References [1] Ernst, T., et al, "Network Mobility Support Goals and Requirements", Internet Draft: draft-ietf-nemo-requirements-02.txt (work in progress), February 2004. [2] Ernst, T. and H. Lach, "Network Mobility Support Terminology", Internet Draft: draft-ietf-nemo-terminology-01.txt (work in Progress), February 2004. [3] Devarapalli V., et al, "NEMO Basic Support Protocol", Internet Draft: draft-ietf-nemo-basic-support-03.txt (work in progress), June 2004. [4] Johnson, D. B., Perkins, C. E. and Arkko, J., "Mobility Support in IPv6", RFC 3775, June 2004. [5] Petrescu, A., et al, "Issues in Designing Mobile IPv6 Network Mobility with the MR-HA Bidirectional Tunnel (MRHA)", Internet Draft: draft-petrescu-nemo-mrha-03.txt (work in progress), October 2003. S. Jung et. al. Expires January, 2005 [Page 9] Internet-Draft Threat Analysis on NEMO basic operations July 2004 [6] Ng, C. W. and Tanaka, T., "Analysis of Multihoming in Network Mobility Support", Internet Draft: draft-ietf-nemo-multihoming-issues-00.txt (work in progress), July 2004. [7] Arkko, J. et. al. ,"Using IPsec to Protect Mobile IPv6 Signaling between Mobile Nodes and Home Agents," RFC 3776, June 2004. [8] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998. [9] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998. [10] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998. [11] A. Petrescu, et. al.,ôThreats for Basic Network Mobility Support.ö Internet Draft: draft-petrescu-nemo-thretas-01.txt (work in progress), January 2004. [12] S. Cho et. al, ôThreat for Multi-homed Mobile Networks,ö Internet-Draft: draft-cho-nemo-threat-multihoming-00.txt (work in progress), February 2004. Changes from the previous version 1. Added assumptions 2. Deleted threats from binding errors 3. Added DoS attacks 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 S. Jung et. al. Expires January, 2005 [Page 10] Internet-Draft Threat Analysis on NEMO basic operations July 2004 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 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 S. Jung et. al. Expires January, 2005 [Page 11] Internet-Draft Threat Analysis on NEMO basic operations July 2004 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 January, 2005 [Page 12]