idnits 2.17.1 draft-jung-nemo-threat-analysis-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 364 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 2 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 7 instances of too long lines in the document, the longest one being 10 characters in excess of 72. ** There are 9 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 198 has weird spacing: '...assign a fals...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 23, 2003) is 7613 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '1' is defined on line 296, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 300, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 304, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 308, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 312, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 315, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 319, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 324, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 329, but no explicit reference was found in the text == Outdated reference: A later version (-06) exists of draft-ietf-nemo-requirements-01 ** Downref: Normative reference to an Informational draft: draft-ietf-nemo-requirements (ref. '1') == Outdated reference: A later version (-06) exists of draft-ietf-nemo-terminology-00 ** Downref: Normative reference to an Informational draft: draft-ietf-nemo-terminology (ref. '2') -- Possible downref: Normative reference to a draft: ref. '3' == Outdated reference: A later version (-24) exists of draft-ietf-mobileip-ipv6-21 == Outdated reference: A later version (-07) exists of draft-ietf-rpsec-routing-threats-01 ** Downref: Normative reference to an Informational draft: draft-ietf-rpsec-routing-threats (ref. '5') -- Possible downref: Normative reference to a draft: ref. '6' == Outdated reference: A later version (-03) exists of draft-petrescu-nemo-mrha-00 -- Possible downref: Normative reference to a draft: ref. '7' == Outdated reference: A later version (-01) exists of draft-ng-nemo-access-router-option-00 -- Possible downref: Normative reference to a draft: ref. '8' == Outdated reference: A later version (-06) exists of draft-ietf-mobileip-mipv6-ha-ipsec-04 Summary: 9 errors (**), 0 flaws (~~), 21 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 NEMO Working Group Souhwan Jung 2 Internet-Draft Soongsil University 3 Expires: December 22, 2003 Felix Wu 4 University of California at Davis 5 Hyungon Kim 6 Seungwon Sohn 7 Electronics and Telecommunications Research Institute 8 June 23, 2003 10 Threat Analysis for NEMO 11 draft-jung-nemo-threat-analysis-00 13 Status of this Memo 15 This document is an Internet-Draft and is in full conformance with 16 all provisions of Section 10 of RFC2026. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six 24 months and may be updated, replaced, or obsoleted by other documents 25 at any time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at http:// 29 www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on December 22, 2003. 36 Copyright Notice 38 Copyright (C) The Internet Society (2003). All Rights Reserved. 40 Abstract 42 This document describes possible security threats on mobile networks 43 that include multi-homing. Many different kinds of security threats 44 exist on signaling and communication paths including mobile routers 45 and home agents. It is also the goal of this draft to explain a 46 three-layer threat model and to investigate vulnerabilities of the 47 network entities in NEMO. 49 Table of Contents 51 1. Motivations 53 2. Three-Layer Threat model 55 3. Threats to Target Protocols/Services 56 3.1 Threats to Signaling Plane 57 3.2 Threats to Communication Plane 59 4. Threats to Target Entities/Entry Points 60 4.1 Compromise of MR 61 4.2 Compromise of HA 62 4.3 Compromise of FA 63 4.4 Denial of Service 64 4.5 Threats to Location Privacy 66 5. Security Considerations 68 6. Conclusions 70 References 72 Authors' Addresses 74 Intellectual Property and Copyright Statements 76 1. Motivations 78 Networks in motion (NEMO) introduces a new network entity called 79 Mobile Router(MR). MR has different features from Mobile Hosts that is 80 operated based on Mobile IP technologies. Since MR functions both as a 81 mobile node and a gateway to provide a mobile network with Internet 82 access in outside world, it needs specific treatment for managing 83 operations and securities. 85 In real world, many different types of NEMO configurations are 86 possible including multi-homing, which means that new kind of threats 87 specific to NEMO should be taken care of. For example, MR can 88 advertise its IP prefix to the access routers in foreign domain, and 89 this message can be intercepted and modified to advertise different 90 prefix of malicious attacker. This makes address stealing attack 91 possible: the packets that should be delivered to the mobile router 92 are destined to the attack router. Therefore, those messages like 93 address advertisement should be protected using authentication. 95 This draft proposes a three-layer threat model for analyzing 96 vulnerabilities of NEMO protocols and entities. Based on the model, we 97 describe and classify all possible threats to NEMO, and analyze those 98 threats according to their properties and scopes. 100 2. Three-Layer Threat Model 102 A huge number of different threats to network entities in NEMO are 103 possible and hard to describe all of them in a row. Some of the 104 threats can have multiple paths to achieve their goals, which means 105 that many different types of attacks are possible to obtain the same 106 objective that the attacker tries to achieve. Therefore, it requires a 107 hierarchical threat model to describe and classify all different 108 threats to NEMO. 110 This draft proposes a three-layer threat model to describe all 111 possible threats to NEMO according to their objectives/properties, 112 target protocols/services, and target entities/entry points. This 113 model is composed of a three-layer stack; objectives/properties on the 114 top layer, target protocols/services for attack on the second layer, 115 and finally target entities or entry points for attack at the bottom 116 layer. 118 The objectives of threats are usually a limited number of goals that 119 attackers try to achieve in abstract level. They could be like 120 eavesdropping of data, impersonation, data corruption or modification, 121 unauthorized use of resources, repudiation, and blocking services to 122 clients. The generic goals of security mechanisms therefore are such 123 as confidentiality, integrity, authentication, authorization, non- 124 repudiation, and service availability against those attacks, which are 125 common to all the security frameworks. 127 The second layer of the stack is composed of target protocols or 128 services for attack. Attackers always try to find vulnerabilities to 129 network protocols or services by monitoring protocol or service data 130 specific to the target. In NEMO, for example, binding update (BU) 131 message or address advertisement messages by MRs could be target data 132 for attack. Most of NEMO signaling protocols could be the target at 133 the second layer. Therefore, the vulnerabilities to the basic NEMO 134 mechanism should be scrutinized for the analysis. In the next section, 135 this draft will describe those vulnerabilities and possible threats 136 related to them. 138 The bottom layer of the threat model is comprised of target entities 139 or entry points for attacks. NEMO includes many network entities 140 called MR, HA, FA, and CN etc. Any of these entities could be a victim 141 for attack and be compromised. All the possibilities of different 142 types of attacks should be investigated based on the assumption of 143 these compromises. For example, the compromise of MR can lead all the 144 MNNs and FNs inside the mobile network with a compromised MR to 145 interception of their data or deception of their connection to a fake 146 HA or FA. The MNNs or FNs inside the mobile network have no knowledge 147 of the compromised MR since the NEMO protocols are transparent to 148 their connections. In section 4, those threats will be analyzed and 149 described. 151 3. Threats to Target Protocols and Services 153 This section describes threats to NEMO protocols and services. NEMO 154 operations are composed of two different planes; one is the signaling 155 plane for changing control or routing information, and the other is 156 the communication plane for data transmission between nodes. The 157 threats specific to each plane will be investigated. 159 3.1 Threats to Signaling Plane 160 The basic NEMO operations have three different signaling paths 161 between entities; the first path is the signaling between MR and FA, 162 the second one is the signaling between MR and HA, and the final is 163 the signaling between MR and CN. Each signaling messages can be 164 interrupted and modified by attackers on the way of the signaling 165 paths. The following threats exist over signaling paths. 167 - Man-in-the-middle between MR and HA 168 This threat means that an attacker resides between MR and HA, and 169 intercepts the signaling messages such as CoA(Care-of-Address) or BU 170 messages. The messages could be modified and transferred to the HA 171 with corrupted information. For example, the attacker compromises the 172 access router, and intercepts and modifies all the messages that goes 173 through the access router. One of the attack results will be the 174 registration of MR to HA with wrong binding information. Security 175 mechanism for bi-directional tunneling like IPsec could prevent this 176 threat. 178 - Discard registration messages from MR to FA 179 This threat is a sort of DoS attack to block network connectivity 180 service to MR. The attacker compromises the FA, and keep discarding 181 the registration message from MR. The result of the attack is no 182 availability of network connection service to the mobile networks. 184 - fake MR 185 Mobile network could have multiple MRs for the case of multi- 186 homing. Assume that there is a mobile network with a single MR. The 187 fake MR claims to be the second MR for multi-homing the victim mobile 188 network, and register to FA with another spoofed IP prefix. The fake 189 MR advertises its spoofed IP prefix to the new MNNs that comes into 190 play. Then the victim MNN gets the wrong IP address from the fake MR, 191 and starts to communicate via the fake MR. 193 - fake FA 194 When a mobile network enters into a new region, the MR of the 195 network tries to find an access router for network connection. The MR 196 will advertise its IP prefix and wait for the advertisement of CoA 197 from the FA. At this time, the fake FA can intercept the message and 198 assign a false CoA to the victim MR. The result of this attack will be 199 that the entire mobile network will be connected to a wrong Internet 200 access. 202 - corrupted routing information 203 Attacker may send corrupted routing information to MR and cause 204 network instability such as network congestion or looping. 206 3.2 Threats to Communication Plane 207 - eavesdropping/replay of messages between MR and HA 208 All the data packets between MR and HA have to go through the 209 bi-directional tunnel. This tunnel should be secured by IPsec. But 210 some of the routing information that may not go through this tunnel 211 should be secured. 213 - eavesdropping/replay of messages between MNN and CN 214 The messages between MNN and CN are going through the bi- 215 directional tunnel, but there is no protection against sniffing data 216 between MR and FA or between HA and CN. So security mechanisms should 217 be applied on the part of the path uncovered. 219 - traffic analysis 220 Monitoring and analyzing the characteristics of data traffic 221 along the communication paths reveals some information on routing and 222 location privacy. 224 4. Threats to Target Entities 226 The basic network entities in NEMO are MR, HA, FA, CN on the main 227 network, and FN and MNN in the mobile network. Any of these entities 228 could be the target for attack, but this draft does concern only on 229 threats to entire mobile network rather than the individual nodes 230 inside the subnet. We will investigate possible threats by 231 compromising the network entities. The compromise of an entity means 232 that attacker can access the entity, and change or modify data inside 233 the system. The following attacks are possible with the compromise of 234 each entity. The authentication mechanism for each entity therefore 235 should be applied. 237 4.1 Compromise of MR 238 - MR-A spoofing 239 MR-A is the permanent address assigned statically or 240 dynamically to the MR by HA. MR-A should be used for identification of 241 MR while it is in the visited domain. The compromised MR can register 242 to FA with a spoofed MR-A, and try to collect data destinated to the 243 victim address. 245 - MR-CoA spoofing 246 MR-CoA is the Care-of-Address assigned to the egress 247 interface of MR by FA. The compromised MR can send a BU message to HA 248 with a spoofed CoA, and collect the data that were destinated to the 249 victim FA. 251 - Cache poisoning 252 The cache data for routing table in MR can be corrupted to 253 subvert routing path. The data packet could be redirected or looped 254 causing network instability. 256 4.2 Compromise of HA 257 - sniffing of tunneled packet 258 The IPsec transport mode should be used for securing the 259 tunneled packets between MR and HA. With the compromise of the HA, the 260 attacker can sniff the decrypted data packet in HA. 262 - corruption of binding cache 263 HA keeps managing the BU information on binding cache. With 264 the corruption of binding information, the attacker can redirects 265 packets to where he want to deliver them. 267 4.3 Compromise of FA 268 - DoS to MNN and FN 269 The compromised FA can reject registration message from MR, 270 thus blocking the network access to the MNN and FN within the victim 271 subnet. 273 4.4 Denial of Service 274 Denial of Service attack is possible against MR and HA by 275 flooding BU messages and bogus tunneled packets. The attack can be 276 more effective with distributed fake MRs or HAs. 278 4.5 Threats to Location Privacy 279 The location of MR or MNN inside the subnet may be the privacy 280 of the client, so the location information while network is in motion 281 should be secured. Attacker can analyze the header information MR-CoA 282 in the tunneled data packet and identify the location of the MR. Since 283 all the data packets between MNN and CN are also tunneled using MR-CoA 284 as new source address, the location of the MNN can also be disclosed. 286 5. Security Considerations 288 This document is all about information on threats and security for 289 mobile networks. There should be a separate draft produced by the 290 working group to design a security mechanism for NEMO. 292 6. Conclusions 294 References 296 [1] Ernst, T., et al, "Network Mobility Support Goals and 297 Requirements", Internet Draft: draft-ietf-nemo-requirements- 298 01.txt, Work In Progress, May 2003. 300 [2] Ernst, T. and H. Lach, "Network Mobility Support Terminology", 301 Internet Draft: draft-ietf-nemo-terminology-00.txt, Work In 302 Progress, May 2003. 304 [3] Wakikawa, R., et al, "Basic Network Mobility Support", Internet 305 Draft: draft-wakikawa-nemo-basic-00.txt, Work In Progress, 306 February 2003. 308 [4] Johnson, D. B., Perkins, C. E. and Arkko, J., "Mobility Support 309 in IPv6", Internet Draft: draft-ietf-mobileip-ipv6-21.txt, Work 310 In Progress, February 2003. 312 [5] Barbir, A. and et. Al, "Generic Threats to Routing Protocols", 313 Internet Draft: draft-ietf-rpsec-routing-threats-01, April 2003. 315 [6] Kniveton, T. J., et al, "Mobile Router Tunneling Protocol", 316 Internet Draft: draft-kniveton-mobrtr-03.txt, Work In Progress, 317 November 2002. 319 [7] Petrescu, A., et al, "Issues in Designing Mobile IPv6 Network 320 Mobility with the MR-HA Bidirectional Tunnel (MRHA)", Internet 321 Draft: draft-petrescu-nemo-mrha-00.txt, Work In Progress, 322 October 2002. 324 [8] Ng, C. W. and Tanaka, T., "Securing Nested Tunnels Optimization 325 with Access Router Option", Internet Draft: 326 draft-ng-nemo-access-router-option-00.txt, Work In Progress, 327 October 2002. 329 [9] Arkko, J. et. al. ,"Using IPsec to Protect Mobile IPv6 330 Signaling between Mobile Nodes and Home Agents," Internet 331 Draft: draft-ietf-mobileip-mipv6-ha-ipsec-04.txt, March 2003. 333 Authors' Addresses 335 Souhwan Jung 336 Soongsil University 337 1-1, Sangdo-dong, Dongjak-ku 338 Seoul 156-743 339 Korea 341 Phone: +82-2-820-0714 342 EMail: souhwanj@ssu.ac.kr 344 Felix Wu 345 Department of Computer Science 346 University of California, Davis 347 USA 349 Phone: +1-530-754-7070 350 EMail: wu@cs.ucdavis.edu 352 Hyungon Kim 353 Seungwon Sohn 354 Electronics and Telecommunications Research Institute 356 Intellectual Property Statement 358 The IETF takes no position regarding the validity or scope of any 359 intellectual property or other rights that might be claimed to 360 pertain to the implementation or use of the technology described in 361 this document or the extent to which any license under such rights 362 might or might not be available; neither does it represent that it 363 has made any effort to identify any such rights. Information on the 364 IETF's procedures with respect to rights in standards-track and 365 standards-related documentation can be found in BCP-11. Copies of 366 claims of rights made available for publication and any assurances 367 of licenses to be made available, or the result of an attempt made 368 to obtain a general license or permission for the use of such 369 proprietary rights by implementors or users of this specification 370 can be obtained from the IETF Secretariat. 372 The IETF invites any interested party to bring to its attention any 373 copyrights, patents or patent applications, or other proprietary 374 rights which may cover technology that may be required to practice 375 this standard. Please address the information to the IETF Executive 376 Director. 378 Full Copyright Statement 380 Copyright (C) The Internet Society (2003). All Rights Reserved. 382 This document and translations of it may be copied and furnished to 383 others, and derivative works that comment on or otherwise explain it 384 or assist in its implementation may be prepared, copied, published 385 and distributed, in whole or in part, without restriction of any 386 kind, provided that the above copyright notice and this paragraph 387 are included on all such copies and derivative works. However, this 388 document itself may not be modified in any way, such as by removing 389 the copyright notice or references to the Internet Society or other 390 Internet organizations, except as needed for the purpose of 391 developing Internet standards in which case the procedures for 392 copyrights defined in the Internet Standards process must be 393 followed, or as required to translate it into languages other than 394 English. 396 The limited permissions granted above are perpetual and will not be 397 revoked by the Internet Society or its successors or assignees. 399 This document and the information contained herein is provided on an 400 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 401 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 402 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 403 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 404 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.