idnits 2.17.00 (12 Aug 2021) /tmp/idnits57963/draft-haddad-mext-mip6-residual-threats-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 21. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 453. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 464. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 471. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 477. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Line 366 has weird spacing: '...s which emplo...' -- 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 (July 14, 2008) is 5052 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'HoA1' is mentioned on line 251, but not defined == Missing Reference: 'HoA2' is mentioned on line 251, but not defined ** Obsolete normative reference: RFC 3775 (ref. 'MIPv6') (Obsoleted by RFC 6275) == Outdated reference: draft-ietf-monami6-multiplecoa has been published as RFC 5648 Summary: 3 errors (**), 0 flaws (~~), 5 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Mobility Extensions W. Haddad 3 Internet-Draft G. Tsirtsis 4 Intended status: Informational Qualcomm 5 Expires: January 15, 2009 B. Lim 6 Panasonic 7 S. Krishnan 8 Ericsson 9 F. Dupont 10 ISC 11 July 14, 2008 13 Mobile IPv6 Residual Threats 14 draft-haddad-mext-mip6-residual-threats-02 16 Status of this Memo 18 By submitting this Internet-Draft, each author represents that any 19 applicable patent or other IPR claims of which he or she is aware 20 have been or will be disclosed, and any of which he or she becomes 21 aware will be disclosed, in accordance with Section 6 of BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt. 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 This Internet-Draft will expire on January 15, 2009. 41 Abstract 43 This memo aims to highlight specific "residual" threats in Mobile 44 IPv6 protocol. We call these threats "residual" simply because they 45 were rightfully deemed not urgent during the design of Mobile IPv6 46 protocol. However, these threats are somehow benefiting from new 47 mechanisms and/or extensions built on top of Mobile IPv6 protocol to 48 improve their effects and likelihood. Hence, our main goal is to 49 motivate designers to re-assess their potential taking into 50 consideration these new mechanisms. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Conventions used in this document . . . . . . . . . . . . . . 4 56 3. Residual Threats Associated with a Malicious Mobile Node . . . 5 57 3.1. Violating Trust between the Mobile Node and its Home 58 Agent . . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 3.2. Violating Trust between a Multihomed Mobile Node and 60 its Home Agents . . . . . . . . . . . . . . . . . . . . . 6 61 3.3. Creating Routing Loops Among Home Agents . . . . . . . . . 8 62 4. Exploiting Multihoming to Defeat Ingress Filtering . . . . . . 10 63 5. Exploiting Neighbor Discovery in a MIPv6 Environment . . . . . 11 64 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 65 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 66 7.1. Normative References . . . . . . . . . . . . . . . . . . . 13 67 7.2. Informative References . . . . . . . . . . . . . . . . . . 13 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 69 Intellectual Property and Copyright Statements . . . . . . . . . . 15 71 1. Introduction 73 Mobile IPv6 protocol design (described in [MIPv6]) involved extensive 74 security analysis in order to evaluate the potential of each threat 75 and suggest defensive measures when necessary or avoid adding 76 complexities in case a security weakness was deemed acceptable (i.e., 77 does not make IPv6 Internet more secure than without IP mobility). 79 However, these weaknesses have been implicitly inherited in new 80 mobility mechanisms and/or extensions built on top of MIPv6 which may 81 in turn have increased their effects and thus, made them more 82 attractive. 84 This memo aims to describe these residual threats and to motivate 85 designers to re-assess their potential in the light of what has been 86 added so far to MIPv6 protocol. 88 2. Conventions used in this document 90 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 91 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 92 document are to be interpreted as described in [TERM]. 94 3. Residual Threats Associated with a Malicious Mobile Node 96 3.1. Violating Trust between the Mobile Node and its Home Agent 98 The trust model adopted in MIPv6 protocol assumes that the mobile 99 node (MN) will always refrain from misusing the relationship it 100 forges with its home agent (HA). In return, the HA should treat any 101 legitimate information sent by the MN as being trustable. For 102 example, the HA will accept any new care-of address (CoA) claimed by 103 the MN and sent in a valid binding update (BU) message(s). 105 In fact, there are two interrelated factors for expecting a well 106 behaving MN. First, the MN is expected to be fully aware about the 107 HA tracing capabilities coupled with a strong authentication. 108 Second, there is a high probability that the victim will complain to 109 the operator in which case, the MN is quickly identified and punitive 110 actions can be taken against it. 112 However, the situation changes when the first factor is no longer 113 valid. This is the case where a user gains access to the operator 114 network without strong identification (e.g., prepaid phone card). In 115 such scenario, a malicious behavior can go unpunished since the 116 operator is unable to trace the user. The malicious behavior can 117 consist of sending to the HA a valid BU message carrying a fake CoA, 118 which triggers traffic redirection towards the victim. While the 119 target can always complain to the attacker's operator, the latter can 120 do little or nothing about it (of course, the attack will eventually 121 stop when the credit on the prepaid card is entirely consumed or the 122 prepaid card itself expires). Note that while some countries have 123 imposed some restrictions on using prepaid card, e.g, by requiring 124 additional identification and denying roaming service, other 125 countries are still allowing them without control. 127 In fact, the lack of any reachability test between the MN and its HA, 128 prior to or after sending a BU message, enables a malicious MN to 129 launch a flooding attack against any potential target by simply 130 claiming a new CoA which seems to be topologically located within the 131 targeted network. Without testing the new CoA reachability, the HA 132 will simply re-route data packets to the new CoA, i.e., targeted 133 network, and the attacker can keep sending acknowledgment (ACK) 134 messages to all its CN(s) in order to maintain the attack as long as 135 needed. 137 Note that this type of attack is not new and has been analyzed in 138 [MROD]. In fact, when the route optimization (RO) mode is used, the 139 impact of such attack is mitigated by imposing a periodic return 140 routability procedure. Another way to protect against this attack is 141 to deploy ingress filtering (described in [INGRESS]). 143 Moreover, new added extensions to MIPv6 may enhance launching 144 flooding attack through the HA. This is due to the MN's ability to 145 register multiple CoAs with the HA. Such scenario is better 146 described in [Multih_Sec] and is analyzed in the next section. 148 3.2. Violating Trust between a Multihomed Mobile Node and its Home 149 Agents 151 Multiple Care-of Address registration (MCoA) protocol (described in 152 [MCoA]) extends the MIPv6 protocol to enable a multi-interface MN to 153 register multiple CoAs at its HA. The fundamental difference between 154 MIPv6 and MCoA is that for a given home address (HoA) in MIPv6, the 155 MN is only able to bind a primary 'fake' CoA. Hence, this implies 156 that once a malicious MN binds the 'fake' CoA at HA, that MN loses 157 its ability to use that HoA for communication. However, in MCoA, 158 with the ability to bind several CoAs to a single HoA, a malicious MN 159 could bind a mixture of 'real' and 'fake' CoAs. The MN can still use 160 the HoA for communication by directing control traffic towards its 161 'real' CoA. 163 Likewise in the trust model described in [MROD] between the MN and 164 its HA, it permits the HA to always acknowledge any binding that the 165 MN requests. This trust relationship is further strengthened when 166 one assume that ingress filtering is being used such that when the HA 167 receives a BU message from the MN stating its CoA as the source 168 address, the HA trusts that the incoming packets do indeed originate 169 from the specified source address. In addition, the HA also trusts 170 the routing infrastructure, i.e., that packets forwarded by the HA 171 would be sent to the intended destination. This assumption makes it 172 possible for the HA to somewhat trust the MN if the MN sends the 173 binding of each CoA individually (e.g., one BU message per CoA). 175 Even with ingress filtering deployed worldwide in all networks, the 176 problem of the flooding attack described above could still be 177 achieved in the Multiple Care-of Address registration (MCoA) protocol 178 where the MN is able to use multiple binding identifier options in a 179 single binding update message to the home agent for registration 180 purposes. With the care-of addresses embedded inside the BU message, 181 it is not possible for ingress filtering to be used to verify these 182 CoAs. Figure 1 shows an example on how MCoA could be used to 183 initiate the redirection attack. 185 [Start of packet header] 187 Source Address : CoA 188 Destination Address : HA's address 190 [Mobility Options] 192 Binding Unique Identifier: BID1 194 Binding Unique Identifier: BID2 195 Care-of Address : V1's address 197 Binding Unique Identifier: BID3 198 Care-of Address : V2's address 200 [End of packet header] 202 Figure 1: Binding update message for MCoA 204 CoA is a valid care-of address owned by MN. MN is attempting to bind 205 addresses of two victims, V1 and V2, at HA in order to launch an 206 attack towards the victims. 208 When HA receives this BU message, it will accept it based on the 209 following. First, the BU message is deemed authorized as the correct 210 IPSec SA is used for the message. Second, the trust relationship 211 that HA has with the routing infrastructure allows it to understand 212 that this BU message is sent from MN. Finally, after the first two 213 checks have succeeded, the trust relationship that HA has with the MN 214 permits it to trust the care-of addresses that are specified in this 215 BU message. Hence, the binding cache at HA will record three 216 bindings for MN tied to MN's home address (HoA) as shown in Figure 2 217 below. 219 Binding 1 [HoA, CoA , BID1] 220 Binding 2 [HoA, V1's address, BID2] 221 Binding 2 [HoA, V2's address, BID3] 223 Figure 2: Binding Cache at Home Agent 225 The lack of any reachability test between the mobile node and its HA, 226 prior to or after sending a BU message, enables a malicious MN to 227 launch a network flooding attack against any potential target by 228 simply claiming new care-of addresses. 230 3.3. Creating Routing Loops Among Home Agents 232 In MIPv6, it is possible for a malicious MN to create a routing loop 233 amongst HAs. This can be achieved when a MN binds one home address 234 located on a first HA to another home address on a second HA. This 235 type of binding will force HAs to route the same packet among each 236 other without knowledge that a routing loop has been created. Such 237 looping problem is limited to cases where a MN has multiple HAs. For 238 the single case, MIPv6 has a policy at the HA to prevent the binding 239 of one home address to another home address hosted by the same home 240 agent. Figure 3 below shows such threat of routing loop between home 241 agents. 243 +-----+ 244 | | 245 | I | cccc +-----+ Binding cache 246 | N |------| HA1 | [HoA1, HoA2] 247 HoA1 | T | +-----+ 248 +----+ | E | 249 | MN |------| R | 250 +----+ | N | cccc +-----+ Binding cache 251 HoA2 | E |------| HA2 | [HoA2, HoA1] 252 | T | +-----+ 253 | | 254 +-----+ 256 Figure 3: Packet flooding attack scenario 258 The mobile node (MN) sends a binding update (BU) message to its first 259 home agent (HA1) to bind its home address (HoA1) to a care-of address 260 (HoA2). Since HoA2 is not a home address on HA1, HA1 accepts this 261 binding thinking that HoA2 is indeed a CoA. Likewise, on HA2, MN 262 sends a BU to bind its home address (HoA2) to a care-of address 263 (HoA1). Such bindings created among the two HAs create a routing 264 loop between them. For example, when HA1 wants to forward a packet 265 (shown as 'c') from a CN to MN, HA1 searches the binding cache to 266 find the relevant MN's CoA. In this case, HA1 tunnels the packet to 267 MN via HoA2. This will cause HA2 to intercept the packet for MN. 268 Now, at HA2, it sees that the packet is addressed to HoA2. Searching 269 the respective binding entry in its binding cache, HA2 will tunnel 270 this packet to MN via HoA1. This will cause HA1 to intercept the 271 packet for MN. This repetition will continue until one of the HA 272 discover that it can no longer encapsulate the packet (i.e., due to 273 the tunnel encapsulation limit == 0 described in [GPT6]). In this 274 case, the packet would be dropped and a flood of error message will 275 be sent between both HAs to indicate that the packet has failed to 276 reach its intended destination (the MN). Thus, it can be seen that 277 such attacks consumes the resources of the home agent and if launched 278 in full scale (e.g., multiple sets of HoAs) could 'shut down' the HA. 280 4. Exploiting Multihoming to Defeat Ingress Filtering 282 A malicious multi-homed node can also use its multiple interfaces to 283 emulate a home network and defeat ingress filtering. This is the 284 case when an attacker with two interfaces (A) and (B) starts its 285 attack by establishing sessions with a set of correspondent nodes 286 (CNs) using (A)'s IPv6 address then at some point, attaches (B) to 287 the targeted network and triggers a return routability (RR) procedure 288 with the CN. As the RR procedure involves exchanging HoTI/HoT 289 messages, the MN will use (A)'s IPv6 address for that purpose and 290 receives a home keygen token. Then the MN exchanges a CoTI/CoT 291 messages using (B)'s IPv6 address as a CoA and obtain a care-of 292 keygen token. A BU message is then sent to the CN and the data 293 traffic is redirected to (B). 295 At some point, the MN detaches itself from the targeted network and 296 start sending legitimate ACK messages via a legitimate address to 297 each CN causing a flooding attack. Such scenario is mitigated by the 298 fact that the MN MUST periodically repeat the RR procedure which 299 means that it has to exchange CoTI/CoT messages with each CN. 300 However, if the MN manages to position itself on-path with at least 301 one CN without detaching (A) then it will be able to keep the attack 302 as long as needed. Note that this attack becomes easier if the MN 303 does not have to periodically repeat the RR procedure as a result of 304 establishing a long lifetime security association with the CN, e.g., 305 when the enhanced RO mode ([ERO]) is used. 307 5. Exploiting Neighbor Discovery in a MIPv6 Environment 309 Note: It may be asserted that this attack is related to Neighbor 310 Discovery Protocol (described in [NDP]). However, our main goal is 311 to convey a description about its potential which may go well beyond 312 the local link when applied in a MIPv6 context. 314 This threat offers a malicious node two edges. It requires first 315 that the attacker be attached to the same foreign link as the MN, and 316 the discovery of the MN's home agent IP address as well as the MN's 317 IP home address (which may not pose a serious problem). After 318 learning these two information, the attacker advertises the MN's home 319 prefix on the link thus leading the MN to believe that it has 320 returned to its home network. Such information will prompt the MN to 321 send a BU message to its HA to request de-registration. However, 322 such early de-registration may not be possible as the foreign network 323 may have activated ingress filtering. But the main goal for the 324 attacker is to get a valid copy of the MN's BU message and such goal 325 is achieved. If the malicious node concludes that the MN is still 326 receiving data packets tunneled by the HA to its current CoA, then it 327 will get involved in the MN de-registeration procedure by forwarding 328 the BU message to the MN's HA on another interface where ingress 329 filtering is not activated (i.e., under the assumption that the 330 attacker is multihomed). Upon receiving the BU message, the HA will 331 de-register the MN and stops tunneling data packets to the MN's CoA. 332 In addition, the HA sends back a BA message which will never reach 333 the MN. From that moment, the data traffic sent by the CN(s) stops 334 at the MN's home network. However, the lack of ACK messages sent by 335 the MN will prompt the CN(s) at some point to halt sending data 336 traffic and eventually tear down the session(s). 338 However, the situation gets worse if the malicious node decides to 339 push further in his attack by sending fake ACK messages to the CN(s), 340 i.e., using the MN's home address. In such situation, the CN(s) will 341 keep sending data traffic to the MN's HA (where they eventually get 342 discarded) and thus, may cause severe disruption within the home 343 access network, possibly leading to a network flooding attack in some 344 specific topologies. 346 Note that as they may be more than one MN attached to the same 347 foreign link and using the same home prefix, such attack may lead to 348 collective de-registration. 350 6. Security Considerations 352 This document is about security analysis of some specific parts in 353 the MIPv6 protocol. 355 7. References 357 7.1. Normative References 359 [ERO] Vogt, C., Arkko, J., and W. Haddad, "Enhanced Route 360 Optimization for Mobile IPv6", RFC 4866, June 2006. 362 [GPT6] Conta, A. and S. Deering, "Generic Packet Tunneling in 363 IPv6", RFC 2473, December 1998. 365 [INGRESS] Ferguson, P. and D. Senie, "Network Ingress Filtering: 366 Defeating Denial of Service Attacks which employ IP 367 Source Address Spoofing", RFC 2827, May 2000. 369 [MIPv6] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 370 for IPv6", RFC 3775, June 2004. 372 [MROD] Nikander, P., Arkko, J., Aura, T., and E. Nordmark, 373 "Mobile IPv6 version 6 Route Optimization Security Design 374 Background", RFC 4225, December 2005. 376 [NDP] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 377 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 378 September 2007. 380 [TERM] Bradner, S., "Key Words for Use in RFCs to Indicate 381 Requirement Levels", RFC 2119, BCP , March 1997. 383 7.2. Informative References 385 [MCoA] Wakikawa, R., Ernst, T., Nagami, K., and V. Devarapalli, 386 "Multiple Care-of Addresses Registration", Internet 387 Draft, draft-ietf-monami6-multiplecoa-08.txt, May 2008. 389 [Multih_Sec] 390 Lim, B., Ng, C., and K. Aso, "Verification of Care-of 391 Addresses in Multiple Bindings Registration", Internet 392 Draft, draft-lim-mext-multiple-coa-verify-01.txt, 393 February 2008. 395 Authors' Addresses 397 Wassim Haddad 398 Qualcomm 399 500 Somerset Corporate Blvd 400 Bridgewater, New Jersey 08807 401 US 403 Phone: +908 938 5027 404 Email: whaddad@qualcomm.com 406 Georges Tsirtsis 407 Qualcomm 408 London 409 UK 411 Phone: +908 443 8174 412 Email: tsirtsis@qualcomm.com 414 Benjamin Lim 415 Panasonic Singapore Laboratories Pte Ltd 416 Blk 1022 Tai Seng Ave #06-3530 417 Tai Seng Industrial Estate 418 Singapore 534415 420 Phone: +65 65505478 421 Email: benjamin.limck@sg.panasonic.com 423 Suresh Krishnan 424 Ericsson 425 8400 Decarie Blvd. 426 Town of Mount Royal, QC 427 Canada 429 Phone: +1 514 345 7900 430 Email: Suresh.Krishnan@ericsson.com 432 Francis Dupont 433 ISC 434 Rennes 435 France 437 Email: Francis.Dupont@fdupont.fr 439 Full Copyright Statement 441 Copyright (C) The IETF Trust (2008). 443 This document is subject to the rights, licenses and restrictions 444 contained in BCP 78, and except as set forth therein, the authors 445 retain all their rights. 447 This document and the information contained herein are provided on an 448 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 449 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 450 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 451 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 452 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 453 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 455 Intellectual Property 457 The IETF takes no position regarding the validity or scope of any 458 Intellectual Property Rights or other rights that might be claimed to 459 pertain to the implementation or use of the technology described in 460 this document or the extent to which any license under such rights 461 might or might not be available; nor does it represent that it has 462 made any independent effort to identify any such rights. Information 463 on the procedures with respect to rights in RFC documents can be 464 found in BCP 78 and BCP 79. 466 Copies of IPR disclosures made to the IETF Secretariat and any 467 assurances of licenses to be made available, or the result of an 468 attempt made to obtain a general license or permission for the use of 469 such proprietary rights by implementers or users of this 470 specification can be obtained from the IETF on-line IPR repository at 471 http://www.ietf.org/ipr. 473 The IETF invites any interested party to bring to its attention any 474 copyrights, patents or patent applications, or other proprietary 475 rights that may cover technology that may be required to implement 476 this standard. Please address the information to the IETF at 477 ietf-ipr@ietf.org.