idnits 2.17.1 draft-cho-nemo-threat-multihoming-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: ---------------------------------------------------------------------------- ** Missing revision: the document name given in the document, 'draft-cho-nemo-threat-', does not give the document revision number ~~ Missing draftname component: the document name given in the document, 'draft-cho-nemo-threat-', does not seem to contain all the document name components required ('draft' prefix, document source, document name, and revision) -- see https://www.ietf.org/id-info/guidelines#naming for more information. == Mismatching filename: the document gives the document name as 'draft-cho-nemo-threat-', but the file name used is 'draft-cho-nemo-threat-multihoming-00' == There is 1 instance of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack a Security Considerations 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.) ** There are 4 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (February 4, 2004) is 7380 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) -- Missing reference section? '1' on line 287 looks like a reference -- Missing reference section? '2' on line 290 looks like a reference -- Missing reference section? '5' on line 302 looks like a reference -- Missing reference section? '6' on line 306 looks like a reference -- Missing reference section? '7' on line 310 looks like a reference -- Missing reference section? '3' on line 294 looks like a reference -- Missing reference section? '4' on line 298 looks like a reference Summary: 6 errors (**), 1 flaw (~~), 5 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NEMO Working Group Seongho Cho 3 Internet Draft Jongkeun Na 4 Document: draft-cho-nemo-threat- Chongkwon Kim 5 multihoming-00.txt Seoul National University 6 Expires: August 4, 2004 Sungjin Lee 7 Hyunjung Kang 8 Changhoi Koo 9 Samsung Electronics 10 February 4, 2004 12 Threat for Multi-homed Mobile Networks 13 draft-cho-nemo-threat-multihoming-00 15 Status of this Memo 17 This document is an Internet-Draft and is in full conformance with 18 all provisions of Section 10 of RFC2026. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that other 22 groups may also distribute working documents as Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on August 4, 2004. 37 Abstract 39 In mobile networks, the Mobile Router (MR) is an operational main 40 entity. With multiple MRs, mobile networks can provide the stability 41 of service. And, there already exist various multi-homing scenarios. 42 However, because of mobility and MR-HA relations, there are several 43 security problems in multi-homed mobile networks. In this draft, we 44 identify threats to multi-homed mobile networks. And we will 45 illustrate several scenarios of Denial-of-Service (DoS) attacks, 46 Redirection attacks, and Replay attacks. 48 Conventions used in this document 50 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 51 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 52 document are to be interpreted as described in RFC-2119. 54 Table of Contents 56 1. Multi-homing in Mobile Networks................................2 57 2. Related Multi-homing Scenarios.................................3 58 3. Denial-of-Service (DoS) Attacks................................3 59 4. Redirection Attack.............................................4 60 4.1 Redirection for Cryptographic Analysis.....................4 61 4.2 Redirection for DoS Attack Stream..........................5 62 4.3 Stream Redirection from the Attacker Node..................5 63 5. Replay Attack..................................................5 64 6. Another Kinds of Attacks.......................................6 65 References........................................................7 66 Acknowledgments...................................................7 67 Author's Addresses................................................7 69 1. Multi-homing in Mobile Networks 71 NEMO Basic Support Protocol [1] has been proposed to support 72 transparent mobility to mobile network nodes (MNNs) with same 73 mobility in mobile networks. Using MR-HA bi-directional tunneling, 74 the MR provides the session mobility, continuity, and connectivity 75 for all nodes in the mobile network as the network moves. Because the 76 MR manages every session to the mobile network, the availability of 77 MR affects all sessions to the mobile network. 79 However, there exist fault tolerance problem. The operational 80 concentration on the single MR has failure problems. Because the 81 egress MR has a responsibility on the operation of the whole mobile 82 nodes inside the subnet, single failure of MR can cause network 83 service suspension. Especially, egress channel or MR node 84 availability affect the session continuity and quality-of service. 85 Therefore, multiple MRs are required to the big-size networks, such 86 as train, bus, or airplane. And the other benefit of the multi-homing 87 is traffic load sharing through multiple MRs. Static and dynamic load 88 sharing mechanisms are possible at the HA level and MR level. 90 To support fault tolerance and load sharing, various type of multi- 91 homed mobile networks have been considered in several drafts [2, 3, 92 4]. This Multi-homing concept can improve the performance of the 93 mobile network. And multi-homing can help to get several operational 94 advantages, like load balancing, network access cost optimization and 95 optimal handover decision. Specific benefits of the multi-homing are 96 described in the multi-homing issue draft [2]. 98 In NEMO threat analysis drafts [5, 6], threat for the NEMO basic 99 support protocols has been treated. In this draft, we introduce 100 several threats in multi-homed mobile networks. And we illustrate 101 some scenarios of attacks to multi-homed mobile networks. 103 2. Related Multi-homing Scenarios 105 In multi-homing issue draft [2], various scenarios have been treated. 106 However, our concern is NEMO specific scenarios which can be 107 different from site multi-homing of multiple ISPs model. Based on the 108 above draft, we will describe our specific scope of multi-homed 109 mobile networks by the configuration. 111 Our main focus of multi-homed mobile networks is multiple Home Agent 112 (HA) existence scenarios. In multi-homing draft [2], (1, N, 1), (N, N, 113 1), (1, N, N) and (N, N, N) can be these cases. In current NEMO basic 114 support protocol, no additional messages are added to the Mobile IPv6. 115 However, in the presence of multiple HA, the multi-homed mobile 116 network can be insecure without the neighbor MR-HA information. 117 Especially in (N, N, 1) and (N, N, N) cases, multiple MR-HA relations 118 can lead severe security problem. Especially in S/mP-(N, N, 1) case, 119 different ISPs control each HA and each HA can't share the neighbor 120 information. In this case, the tunnel recovery through the other MR 121 is difficult. For load balancing or fault recovery, the binding 122 update by the neighbor MR can be false without neighbor MR-HA 123 information. 125 In this draft, we focus on threats on the multi-homed mobile networks 126 with multiple HA. 128 3. Denial-of-Service (DoS) Attacks 130 In this section, we will describe the possible attacks by Denial-of- 131 Service (DoS) attacks. Even though some kinds of attacks are not NEMO 132 specific, these DoS attacks can be a preparation for another attack 133 to the mobile network. Therefore, we will briefly describe possible 134 DoS attacks. 136 In mobile networks, the MR can be exposed to various DoS attacks. 137 Because the MR has mobility, the access links are usually wireless 138 channel. Therefore, simple channel jamming can cause the service 139 unavailability. And, the packet flooding to the MR can lead the 140 normal service unavailable to mobile networks. Except the packet 141 flooding, the MR maintains binding update list and home agent list. 142 If some malicious nodes keep updating binding information, or sending 143 the route optimization [7] request to the correspondent node (CN), 144 the MR can experience the overflow for this data structure. These DoS 145 attacks can be classified as a DoS attack to the binding related data 146 structure of the MR. To prevent this kind of attack, data structure 147 should be updated after verification of the requested node. And stale 148 binding update information in the binding update list should be 149 managed efficiently. Finally A black hole attack can be described as 150 a DoS attack. If the egress MR doesn't forward packets to the 151 destination, the flow can't be served at all. This attack is very 152 simple, but significant. 154 This service unavailability of the MR from the DoS attack and MR 155 failure requires tunnel recovery to an alternative tunnel in multi- 156 homed mobile networks. 158 4. Redirection Attack 160 Various types of redirection attacks can be possible in multi-homed 161 mobile networks. Types of redirection attacks are a redirection for 162 cryptographic analysis, redirection for DoS attack stream, and stream 163 redirection from the attacker node. Each attack is described as 164 follows. 166 MR3 167 HA1 AR MR1 _ | 168 _ | | _ | _ |-|_|-| _ 169 -|_|-| _____ |-|_|-|-|_|-| |-|_| 170 |||-| |-| |------------>MNN1 171 recoverd || |Inter| original flow 172 tunnel || | net | MNN2 173 _|||-|_____|-| _ | _ | _ 174 -|_|-|=========|-|_|-|-|_|-| _ |-|_| 175 |recovered| | |-|_|-| _ 176 HA2 tunnel AR Fake |-|_| 177 MR MR4 178 ------------>MNN3 179 redirection 181 Figure 1. Redirection Attack by Fake MR 183 4.1 Redirection for Cryptographic Analysis 185 For the redirection for cryptographic analysis, the fake MR can 186 compromise as an alternative MR to multi-homed mobile networks. After 187 the fake MR receives the previous tunnel to the primary MR, the fake 188 MR can cause packets to be sent to the attacker. The attacker might 189 receive packets to inspect or modify the payload or apply the 190 cryptographic analysis to find the secret key or decrypt the original 191 data. In Figure 1, the Fake MR can forward the original flow to the 192 MNN3 which is an attacker. And the attacker node can analysis packet 193 flows to break the security association between HA1-MR1 or HA_MNN1- 194 MNN1. 196 4.2 Redirection for DoS Attack Stream 198 Redirected packets can be used as attack flows to other MR or MNN. 199 From this attack, packets can cause overload on the unrelated link. 200 And in this case, the attack might be able to hide the location and 201 identity. In Figure 1, the Fake MR can forward the original flow to 202 the MNN3 which is a victim node. MNN3 can suffer from DoS attack 203 stream which is identified as the attack stream from the CN of the 204 MNN1. 206 4.3 Stream Redirection from the Attacker Node 208 Similarly, the Fake MR can lead a MNN to accept attacker's packets. 209 Unexpected packets can be delivered to the MNN by the redirection 210 attack. In Figure 1, MNN3 can receive the attack stream through the 211 Fake MR. Or MNN1 can receive the attack stream which is not from the 212 original CN, but from the attacker. Of course, this case would not be 213 the specific case of multi-homed mobile networks. 215 To prevent this kind of redirection attack, the neighbor egress MR 216 existence should be identified and the MR should be authenticated. 217 From this authentication, non-repudiation can be obtained. To support 218 authentication, the alternative MR registration mechanism is required. 219 To provide the alternative MR registration, the MR-HA communication 220 and HA-HA communication is required. From the MR and HA communication, 221 HA can register neighbor MR information. And from the HA-HA 222 communication, the validity of binding update information of the 223 neighbor MR toward its own HA can be obtained. 225 5. Replay Attack 227 In mobile networks, the MR has mobility. Therefore, the neighbor 228 information can be stale after the neighbor moves away. Using 229 previous neighbor information, a malicious MR can send binding update 230 to false CoA. The malicious MR can move to the other place or already 231 moved MR can compromise to the replay attack. And this attack can be 232 used as another redirection attack. In Figure 2, after the Fake MR 233 changes the point of attachment, it can send the Binding Update 234 message to the wrong place using previous neighbor information. In 235 this case, similar redirection attacks in Section 4 are possible. 237 To prevent the replay attack, the HA should keep the neighbor MR 238 information. And registration information should be updated whenever 239 the MR moves or disappears. To keep registration information safely, 240 expiration by the TTL and explicit removal after the neighbor MR 241 movement detection can be used. The neighbor MR movement detection 242 can be done after the periodic ICMP Mobile Prefix Advertisement 243 expiration. 245 MR3 MNN1 246 HA1 AR1 MR1 _ | 247 _ | | _ | _ |-|_|-| _ 248 -|_|-| _____ |-|_|-|-|_|-| |-|_| 249 |-| |-| | | 250 | | | MNN2 251 |Inter|-| _ | _ | _ 252 | net | |-|_|-|-|_|-| _ |-|_| 253 | | | AR2 |Fake |-|_|-| _ 254 _ |-| | MR MR4 |-|_| 255 -|_|-| |_____|-| _ MNN3 256 | |-|_|- 257 HA2 | AR3 259 || 260 \||/ 261 \/ 263 MR3 MNN1 264 HA1 AR1 MR1 _ | 265 _ | | _ | _ |-|_|-| _ 266 -|_|-| _____ |-|_|-|-|_|-| |-|_| 267 |||-| |-| | | 268 || | | | 269 False || |Inter|-| _ 270 BU || | net | |-|_|- 271 || | | | AR2 272 _|||-| | MNN2 273 -|_|-| |_____|-| _ | _ | _ 274 |=========|-|_|-|-|_|-| _ |-|_| 275 HA2 False BU | AR3 |Fake |-|_|-| _ 276 MR MR4 |-|_| 277 MNN3 278 Figure 2. Replay Attack after Moving 280 6. Another Kinds of Attacks 282 There can be other kinds of attacks to the multi-homed mobile 283 networks. 285 References 287 [1] Ernst, T. and H. Lach, "Network Mobility Support Terminology," 288 draft-ietf-nemo-terminology-00 (work in progress), May 2003. 290 [2] C. Ng, J. Charbon, and E. Paik, "Multihoming Issues in Network 291 Mobility Support,?draft-ng-nemo-multihoming-issues-02.txt (work in 292 progress), Oct 2003. 294 [3] J. Charbon, C-W. Ng, K. Mitsuya, and T. Ernst, "Evaluating 295 Multi-homing Support in NEMO Basic Solution.?draft-charbon-nemo- 296 multihoming-evaluation-00.txt (work in progress), Jul 2003. 298 [4] E. K. Paik, H. S. Cho, and T. Ernst, "Multihomed Mobile Networks 299 Problem Statements," draft-paik-nemo-multihoming-problem-00.txt 300 (work in progress), Oct 2003. 302 [5] S. Jung, F. Zhao, F. Wu, H. Kim and S. Sohn, "Threat Analysis for 303 NEMO" (work in progress). Internet Draft, IETF draft-jung-nemo- 304 threat-analysis-01.txt, Oct 2003 306 [6] A. Petrescu, A. Olivereau, C. Janreteau, H.-Y. Lach, Threats for 307 Basic Network Mobility Support (NEMO threats),� draft-petrescu- 308 nemo-threats-01.txt, (work in progress) Jan 2004. 310 [7] P. Thubert, M. Molteni, and C. Ng, "Taxonomy of Route 311 Optimization models in the Nemo Context," draft-thubert-nemo-ro- 312 taxonomy-01 (work in progress) Jun 2003. 314 Acknowledgments 316 Author's Addresses 318 Seongho Cho 319 Seoul National University 320 School of CSE, Seoul National University, 321 San 56-1, Shillim dong, Gwanak gu, Seoul, 151-744, Korea. 322 Phone: +82-2-884-3936 323 Email: shcho@popeye.snu.ac.kr 325 Jongkeun Na 326 Seoul National University 327 School of CSE, Seoul National University, 328 San 56-1, Shillim dong, Gwanak gu, Seoul, 151-744, Korea. 329 Phone: +82-2-884-3936 330 Email: jkna@popeye.snu.ac.kr 332 Chongkwon Kim 333 Seoul National University 334 School of CSE, Seoul National University, 335 San 56-1, Shillim dong, Gwanak gu, Seoul, 151-744, Korea. 336 Phone: +82-2-884-3936 337 Email: ckim@popeye.snu.ac.kr 339 Sungjin Lee 340 Telecommunication R&D Center, 341 Samsung Electronics 342 Dong Suwon P.O. BOX 105 343 416, Maetan-3Dong, Paldal-Gu 344 Suwon-City, Gyunggi-Do, 442-600, KOREA 345 EMail : steve.lee@samsung.com 347 Hyunjeong Kang 348 Telecommunication R&D Center, 349 Samsung Electronics 350 Dong Suwon P.O. BOX 105 351 416, Maetan-3Dong, Paldal-Gu 352 Suwon-City, Gyunggi-Do, 442-600, KOREA 353 EMail : hyunjeong.kang@samsung.com 355 Changhoi Koo 356 Telecommunication R&D Center, 357 Samsung Electronics 358 Dong Suwon P.O. BOX 105 359 416, Maetan-3Dong, Paldal-Gu 360 Suwon-City, Gyunggi-Do, 442-600, KOREA 361 EMail : chkoo@samsung.com