idnits 2.17.1 draft-ietf-mobileip-mipv6-scrty-reqts-02.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 Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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.) ** The document seems to lack an Authors' Addresses Section. ** There are 17 instances of too long lines in the document, the longest one being 5 characters in excess of 72. == There are 17 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 176: '...t basically any IPv6 node MAY function...' RFC 2119 keyword, line 178: '...owever, any node MAY alternatively ign...' RFC 2119 keyword, line 466: '...rrespondent node MUST not update its b...' RFC 2119 keyword, line 557: '... binding updates SHOULD NOT create sta...' RFC 2119 keyword, line 560: '... b) An IPv6 node SHOULD have the capab...' (43 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 26 has weird spacing: '... It is inapp...' == Line 137 has weird spacing: '... [Page iv]...' == Line 801 has weird spacing: '...ing BUs to CN...' == Line 1132 has weird spacing: '...ity for bindi...' -- The exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: A correspondent node MUST not update its binding cache on receiving a binding update from any IPv6 node without verifying that the packet was sent by a node authorized to create binding cache entries for the home address carried in the home address option of the BU. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: Any requirements to address this threat is outside the scope of Mobile IPv6 as the threat described above is a generic one. However MIPv6 itself SHOULD not cause further grief in establishing end-to-end security either using IPsec or other mechanisms. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: CNs SHOULD NOT/MAY NOT process any packet (BU or not) containing a Home Address option unless they have verified that that the node sending the packets is authorized to use the home address in the destination option. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: C Identity verification MUST not rely on the existence of a gloabl PKI. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: 5 If IPsec is used as part of the solution it SHOULD not place additional requirements on the set of IPsec SPD selectors beyond what is in common implementations. (Note: This is however debatable. A soon to be published I-D will identify the issues of using IPsec in conjunction with Mobile IPv6.) == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: 6.1.1.1_Requirement A correspondent node MUST not update its binding cache on receiving a binding update from any IPv6 node without verifying that the packet was sent by a node authorized to create binding cache entries for the home address carried in the home address option of the BU. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: 6.5.1_Requirement Any requirements to address this threat is outside the scope of Mobile IPv6 as the threat described above is a generic one. However MIPv6 itself SHOULD not cause further grief in establishing end-to-end security either using IPsec or other mechanisms. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: 6.8.3_Requirement CNs SHOULD NOT/MAY NOT process any packet (BU or not) containing a Home Address option unless they have verified that that the node sending the packets is authorized to use the home address in the destination option. -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. 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 353 looks like a reference -- Missing reference section? 'Ref1' on line 1262 looks like a reference -- Missing reference section? '10' on line 988 looks like a reference -- Missing reference section? 'Ref2' on line 1335 looks like a reference Summary: 6 errors (**), 0 flaws (~~), 14 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IP Routing for Wireless/Mobile Hosts (mobileip) WG Allison Mankin 3 INTERNET-DRAFT Basavaraj Patil 4 Date: 05 November 2001 Dan Harkins 5 Expires: May 2001 Erik Nordmark 6 Pekka Nikander 7 Phil Roberts 8 Thomas Narten 10 Threat Models introduced by Mobile IPv6 and Requirements for Security 11 in Mobile IPv6 12 14 Status of This Memo 16 This document is an Internet-Draft and is in full conformance with 17 all provisions of Section 10 of RFC2026. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 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 Abstract 37 The IESG returned the Mobile IPv6 (MIPv6) draft to the working group 38 due to concerns about the security and scalability of binding updates 39 (BUs) sent to correspondent nodes and the associated IPsec processing 40 that is specified in the draft. Since that time discussions have 41 continued to attempt to define what is really needed to make binding 42 updates secure while taking into consideration the aspect of 43 scalability as well as the fact that IPsec may not be the most 44 suitable security mechanism for securing BUs between MNs and CNs. In 45 the course of discussing the requirements it became apparent that a 46 threat model is needed in order to adequately specify the security 47 requirements. Mobile IPv6 mandates that all binding updates be 48 authenticated. The current approach taken to securing these BUs is 49 via the use of IPsec. This approach for securing BUs has various 50 problems, one of which is scalability. The I-D from a specification 51 perspective does not have security vulnerabilities, but as specified, 52 has serious limitations in its capability to be deployed on an 53 Internet wide basis. 55 The purpose of this I-D is to identify the scenarios and threats that 56 Mobile IPv6 can possibly bring to the Internet. From these scenarios 57 and threats are derived a set of requirements that Mobile IPv6 needs 58 to address as part of the specification. 60 Table of Contents 62 Status of This Memo . . . . . . . . . . . . . . . . . . . . . . . i 64 Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . i 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 1 67 1.1. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 1 69 2. Terminology/Definitions . . . . . . . . . . . . . . . . . . . 2 71 3. Threats on a broad scope introduced by Mobile IPv6 . . . . . . 3 73 4. Classification of Threats . . . . . . . . . . . . . . . . . . 4 75 5. Classification of Attackers . . . . . . . . . . . . . . . . . 5 77 6. Detailed threat scenarios . . . . . . . . . . . . . . . . . . 6 78 6.1. Threats related to attackers located anywhere in the 79 internet . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 80 6.1.1. Tampering with the CN binding cache . . . . . . . . 7 81 6.1.1.1. Scenario 1 - Attacker knows MNs home adress . . . 7 82 6.1.1.2. Scenario 2 - ICMP unreachable sent to CN . . . . . 8 83 6.1.2. Tampering with the MNs binding cache . . . . . . . . 9 84 6.1.2.1. Scenario 3 - Both end-points of a session as MNs 85 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 86 6.1.3. BU flooding . . . . . . . . . . . . . . . . . . . . 10 87 6.1.3.1. Scenario 4 - Flooding a CN with BUs . . . . . . . 10 88 6.2. Threats related to attacks originating from the same 89 subnet/link as the MN . . . . . . . . . . . . . . . . . . . . 10 90 6.2.1. Scenario 5 - MITM via a spoofed BU . . . . . . . . . 10 91 6.2.2. Scenario 6 - Man-in-the-middle attack via the 92 default router . . . . . . . . . . . . . . . . . . . . . . 11 93 6.2.3. Scenario 7 - Moving to an untrusted access point . . 12 94 6.2.4. Scenario 8 - Passive monitoring of traffic . . . . . 13 95 6.3. Threats related to attacks originating from the same 96 subnet/link as the CN . . . . . . . . . . . . . . . . . . . . 13 97 6.4. Attacker located on the same subnet/link as the HA . . . 14 98 6.4.1. Scenario 9 - Spoofed BUs sent on behalf of an MN 99 which is at home . . . . . . . . . . . . . . . . . . . . . 14 100 6.4.2. Scenario 10 - Intercepting BUs sent to HA . . . . . 15 101 6.4.3. Scenario 11 - BU cancellation at HA by malicious 102 node . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 103 6.5. Attacker on the path between the CN and HA . . . . . . . 16 104 6.5.1. Scenario 12 - Masquarade/DoS attack . . . . . . . . 16 105 6.5.2. Scenario 13 - CN challenge to a BU sent by the MN 106 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 108 6.6. Attacker on the path between the MN and CN . . . . . . . 17 109 6.6.1. Scenario 14 - Non MIPv6 Specific . . . . . . . . . . . . . 18 110 6.6.2. Scenario 15 . . . . . . . . . . . . . . . . . . . . . . . 18 111 6.7. Threat model for the case where the MN sends a binding 112 update to the previous router asking it to take on the role 113 of an HA temporarily . . . . . . . . . . . . . . . . . . . . . 18 114 6.7.1. Scenario 16 . . . . . . . . . . . . . . . . . . . . . . . 19 115 6.8. Other threats, including those that target the Home 116 Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 117 6.8.1. Scenario 17 . . . . . . . . . . . . . . . . . . . . . . . 19 118 6.8.2. Scenario 18 - HA used as a Packet reflector . . . . . . . 20 119 6.8.3. Scenario 19 - CN as a packet reflector . . . . . . . . . . 21 120 6.8.4. Threat model specifically in wireless networks . . . 21 122 7. Requirements for MIPv6 Security . . . . . . . . . . . . . . . 21 123 7.1. General Requirements . . . . . . . . . . . . . . . . . . 22 124 7.2. Specific to Mobile IPv6 . . . . . . . . . . . . . . . . . 23 125 7.3. Requirements from Threats . . . . . . . . . . . . . . . . 24 127 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25 129 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 131 10. Authors's Addresses . . . . . . . . . . . . . . . . . . . . . 26 133 Appendix A. Background . . . . . . . . . . . . . . . . . . . . . 26 135 Appendix B: Question and Discussions . . . . . . . . . . . . . . 28 137 Multi-Author [Page iv] 139 1. Introduction 141 The IESG returned the MIPv6 draft to the working group due to 142 concerns about the security and scalability of binding updates (BUs) 143 sent to correspondent nodes and the associated IPsec processing that 144 is specified in the draft. Since that time discussions have 145 continued to attempt to define what is really needed to make binding 146 updates secure while taking into consideration the aspect of 147 scalability as well as the fact that IPsec may not be the most 148 suitable security mechanism for securing BUs between MNs and CNs. In 149 the course of discussing the requirements it became apparent that a 150 threat model is needed in order to adequately specify the security 151 requirements. 153 The purpose of this I-D is to identify the scenarios and threats that 154 Mobile IPv6 can possibly bring to the Internet. From these scenarios 155 and threats are derived a set of requirements that Mobile IPv6 needs 156 to address as part of the specification. 158 The goal is to determine which of those threats are of concern and 159 should be defended against. While the basic goal is "no worse than 160 IPv4," the prevalence of wireless and the likely deployment of MIPv6 161 in that space means the basic goal should aim at being "no worse than 162 IPv4 with switched Ethernets", although the intent is not to try to 163 solve the security problems of shared/broadcast wireless mediums. 164 The threat model is used to generate a list of requirements to make 165 the MIPv6 protocol secure against likely threats. These requirements, 166 interspersed with the threats and also listed at the end of this 167 document are aimed at providing guidelines in developing a solution 168 for MIPv6 security. 170 For the readers that are new to computer and communications security, 171 we recommend consulting Appendix A, "Background", for some 172 introductory material. 174 1.1. Assumptions 176 The Mobile IPv6 specifies that basically any IPv6 node MAY function 177 as a Correspondent Node (CN), receiving Binding Updates and creating 178 Binding Cache Entries. However, any node MAY alternatively ignore, 179 either selectively or altogether, Binding Updates, and continue 180 sending packets to the Home Address. Additionally, a Corresponding 181 Node may itself be a Mobile Node. It should be noted that most 182 threats if not all arise from the BU that is sent by the MN to the 183 CN, and that too only when the CN processes the BU itself, thereby 184 creating a binding cache or, when it processes the home address 185 option in an IPv6 packet without authorization to do so. 187 Furthermore, the following assumptions are made in the threat 188 analysis below: 190 1 The mobile node and the HA have setup a pre-established 191 bidirectional security association before the mobile node begins 192 to roam and connects to the network from a location that is not 193 its home. This does not imply that the MN has to always boot up at 194 home before roaming onto other networks. The reason for a 195 bidirectional SA is to authenticate the BU as well as the BAck. 197 The nature of this security association is not elaborated in this 198 document. But it is anticipated that it is quite feasible to assign 199 keys or certificates between a MN and an HA. This assumption is due 200 to the likelihood that an MN and Home Agent belong to the same 201 administrative domain, or else are in a business relationship of some 202 sort. The unusual cases in which this is not true ("homeless" MN) 203 will have additional security issues, which will need to be 204 separately considered in the future. 206 This security association may be established by configuring the keys 207 or certificates etc. on the MN and the home network at the time of 208 subscription. 210 2 In most cases there are no existing, established security 211 associations or other security relationships between the mobile 212 node and the correspondent node. In addition no Certificate 213 authorities nor a PKI exist that would enable the establishment of 214 such SAs dynamically. The reason for requiring a SA between the MN 215 and a CN is because the BU sent by the MN to the CN needs to be 216 secured in order to avoid possible threats identified in this I-D. 218 2. Terminology/Definitions 220 1 Passive Attacks In a passive attack, the attacker reads packets 221 off the network but does not write them. Eg: For instance, 222 password sniffing attacks can be mounted by an attacker who can 223 only read arbitrary packets. This is generally referred to as a 224 PASSIVE ATTACK. 226 2 Active Attacks When an attack involves writing data to the 227 network, we refer to this as an ACTIVE ATTACK. 229 3. Threats on a broad scope introduced by Mobile IPv6 231 An intrinsic feature of any mobility scheme is, obviously, mobility. 232 Thus, node mobility accomplished via Mobile IPv6 raises a number of 233 security issues. The most damaging threat that MIPv6 introduces is 234 the ability to redirect packets from communicating IPv6 peers. A 235 redirect attack can be defined as an attack in which mobility 236 signaling causes the route that packets take between two 237 communicating peers to be altered such that the packets are routed to 238 a destination determined by the attacker. The ability to redirect 239 packets can allow an attacker to insert himself in the middle of a 240 session (MITM) quite easily. Redirect attacks can also be launched 241 from remote locations and attackers do not have to be on the same 242 link as the communicating peers. 244 Other mobility introduced threats are denial-of-service (DoS) 245 threats, basically meaning that a hostile node may be able to block 246 all traffic on an unprotected link, or a dishonest (wireless) link 247 operator may cause DoS or other harm to a mobile node. 249 Another class of threats is created by the Mobile IPv6 route 250 optimization mechanism. A Mobile Node (MN) has the capability to 251 send a Binding Update to a Correspondent Node (CN) in order to 252 achieve route optimization of the packet stream from the CN to the 253 MN. Normal packet routing without Binding Updates sent to CNs works 254 as follows: 256 Packet stream from MN to CN: 258 ---------------------> 259 |--------| 260 [MN]----|Internet|----[CN] 261 |--------| 263 SRC Addr: MNs CoA 265 Dst Addr: CNs Global IPv6 address 267 Dest opt: MNs Home Address in Home Address option 269 Packet stream from CN to MN: 271 |--------| 272 [MN]----|Internet|----[CN] 273 ^ |--------| / 274 | | / 275 \ | / 276 \------[HA]<----/ 278 CN to HA: 280 SRC Addr: CNs Address 282 Dst Addr: MNs Global IPv6 home address 284 HA to MN: 286 Tunnelled 288 A Binding Update can be sent by the MN to a CN, which results in a 289 Binding Cache Entry for the MN being created in the CN (See Section 290 8.3 of [1]). However it should be noted that a CN will create the 291 entry in the Binding Cache iff the rules specified in Sec 8.2 of [1] 292 are satisfied. Subsequent packets from the CN to the MN will include 293 a routing header which contains the MNs home address and the 294 destination address in the IP header is the MNs CoA (thereby 295 achieving route optimization and bypassing the HA from the packet 296 stream). 298 4. Classification of Threats 300 In the absence of a security association between most MN-CN pairs, 301 there are multiple vulnerabilities that the MN, the CN, or the HA or 302 home network, become exposed to. Basically, the threats can be 303 classified as follows. 305 1 Tampering with the Binding Cache Entries 307 - creating an unauthorized Binding Cache Entry at a Home Agent 309 (Note that this threat is mostly covered by the assumption of having 310 a security association between the MN and the HA. However, we do 311 include some discussion in order to clarify some of the authorization 312 and security policy issues involved.) 313 - creating an unauthorized Binding Cache Entry at a Correspondent 314 Node 316 - creating an unauthorized Binding Cache Entry at the previous 317 access router, acting as a temporary packet forwarding Home Agent 319 2 Denial-of-Service 321 - preventing a MN from communicating with some or all nodes 323 - preventing a CN from communicating with some or all nodes 325 - preventing a HA from serving legitimite MNs 327 3 Disclosure of sensitive information 329 - Disclosure of nodes serving as home agents in a network 331 5. Classification of Attackers 333 The following classes of attackers, and threats caused by them, are 334 considered: 336 - an arbitrary node, anywhere in the Internet, launching an attack 337 gainst a MN, a CN, or a HA 339 - an attacker located on the same (wireless) link as the MN 341 - an attacker located on the same link as the CN 343 - an attacker located on the same link as the HA 345 - an attacker on the path between the CN and the HA 347 - an attacker on the path between the MN and the CN 349 Please note that we do not consider the case where an attacker is on 350 the path between the MN and HA, since we assume that their 351 communication is secured or can be secured via the existence of the 352 MN-HA security association. Note, however that the current Mobile 353 IPv6 specification (version -14 of [1]) makes no assumptions about 354 the MN-HA path traffic being secured. 356 Furthermore, we consider the following threats separately: 358 - using a previous router as a temporary HA 360 - DoS attacks against a CN 362 - DoS attacks against a MN 364 - DoS attacks against a HA 366 6. Detailed threat scenarios 368 In this section, we present a number of specific threat scenarios. 369 The scenarios are arranged by the capabilities of an attacker, using 370 the same order as the classification above. Some of the threats are 371 specific to Mobile IPv6 while other's are not. The inclusion of the 372 non-related threats serves as a background to evaluate the related 373 threats. 375 To make cross referencing easier, the scenarios can be classified as 376 follows: 378 Attack | Attacker location | Effect | Remarks 379 ----------+-------------------+------------+------------------------------ 380 A. 1 | Anywhere | MITM/DoS | Needs to know Home Address 381 2 | Anywhere | MITM/DoS | Needs to know Home Address 382 3 | Anywhere | DoS | No prior knowledge needed 383 ----------+-------------------+------------+------------------------------ 384 B. 1 | MN's link | MITM/DoS | Using only BUs 385 2 | MN's link | MITM/DoS | Using non-MIPv6 mechanisms 386 3 | Close to MN | MITM/DoS | Tamper with radio interface 387 4 | MN's link | MITM/DoS | Tampering Binding Acks 388 ----------+-------------------+------------+------------------------------ 389 C. 1 | CN's link | MITM/DoS | Using non-MIPv6 mechanisms 390 ----------+-------------------+------------+------------------------------ 391 D. 1 | HA's link | MITM/DoS | 392 2 | HA's link | Multiple | Acting as a Home Agent 393 ----------+-------------------+------------+------------------------------ 394 E. 1 | CN->HA link | Masq/DoS | Attack without BUs 395 2 | CN->HA link | MITM/DoS | Defeat Home Address check 396 ----------+-------------------+------------+------------------------------ 397 F. 1 | MN->CN link | DoS | Attack without BUs 398 2 | MN->CN link | MITM/DoS | Immune to ingress filtering 399 ----------+-------------------+------------+------------------------------ 400 G. 1 | MN's (past) link | MITM/DoS | Fool temporary HA 401 ----------+-------------------+------------+------------------------------ 402 H. 1 | Anywhere | Disclosure | Topology information exposed 403 2 | Anywhere | DDoS | Use HA as a reflector 404 3 | Anywhere | DDoS | Use CN as a reflector 406 6.1. Threats related to attackers located anywhere in the internet 408 6.1.1. Tampering with the CN binding cache 410 The following section describes scenarios, threats, effects and 411 requirements that deal with manipulating the binding cache in the CN. 413 6.1.1.1. Scenario 1 - Attacker knows MNs home adress 415 A MN and a CN have an ongoing session. A malicious node/attacker 416 knows the MNs home address. 418 6.1.1.1_Threat: 420 The attacker can send a binding update to the CN. The CN believes 421 that the MN has moved and hence has a new CoA. It updates the entry 422 for the MN in its binding cache. 424 6.1.1.1_Effect: 426 The packet stream for the ongoing session from the CN to the MN now 427 is diverted to the malicious node. 429 The MN in this case may be on its home network and not have any CoA 430 or it may be on another network and have a CoA. The attacker in this 431 case only needs to know about the MNs home address and possibly any 432 CNs that the user may communicate with. The attacker could be 433 anywhere on the Internet and does not have to be on the same link or 434 network as the MN. 436 6.1.1.1_Reaction: 438 In the above case the MN may realize that it is no longer receiving 439 any further packets from the CN and may take appropriate actions, 440 which may include sending another binding update to the CN. 442 The attacker has the ability to redirect the traffic to another 443 location via this attack. If not for any gains, this kind of an 444 attack can be classified as a DoS attack. Such an intruder could also 445 send a BU to the MN supposedly from the CN and insert himself as a 446 MITM for traffic between the two. 448 The attack described here is an active binding cache update attack. 449 The CNs binding cache has been changed by an entity that does not own 450 the home address sent in the BU. So the issue is, how does a CN 451 determine if the sender of the BU actually is authorized to create 452 cache entries for the home address carried in the BU, before updating 453 his binding cache. 455 A DoS attack or MITM attack on an IPv6 node can be mounted even if 456 the node never goes mobile. Since it is possible to create an entry 457 in the binding cache for an IPv6 node in another IPv6 node, it is not 458 required that a node be mobile or have mobile IP client software on 459 it to be able to do it. In the absence of verifiability of the 460 authority over the IPv6 home address of a node, another IPv6 node can 461 send a BU to any other IPv6 node on behalf of someone else and cause 462 disruptions in communications between legitimate IPv6 nodes. 464 6.1.1.1_Requirement: 466 A correspondent node MUST not update its binding cache on receiving a 467 binding update from any IPv6 node without verifying that the packet 468 was sent by a node authorized to create binding cache entries for the 469 home address carried in the home address option of the BU. 471 6.1.1.2. Scenario 2 - ICMP unreachable sent to CN 473 An ICMP unreachable message can be originated as a result of packets 474 from the CN not being able to be delivered to the MN at it's COA (or 475 its Home Address). The ICMP unreachable message would normally be 476 sent by the last hop router serving a MN if the MN has moved and is 477 no longer attached to the network via that router. 479 6.1.1.2_Threat: 481 An attacker could send an ICMP unreachable for an MNs COA to a CN 482 which has created a binding cache entry for that MN. 484 6.1.1.2_Effect: 486 The CN deletes the binding cache entry for that MN. The result is 487 that the traffic stream from the CN to the MN are now routed through 488 the HA. Route optimization fails, but the traffic stream between the 489 MN and CN is still maintained. 491 6.1.1.2_Requirement: 493 No Mobile IPv6 specific requirements can be generated from this 494 threat. 496 6.1.2. Tampering with the MNs binding cache 498 In the previous section we looked at changing the binding cache entry 499 for an IPv6 MN in the CN. However an MN can also be considered as a 500 CN from the perspective of being an end-point in a session that is 501 being terminated at the MN and originated from another MN. In such a 502 case the MN (now in the role of a CN) also has a binding cache entry 503 for the other MN. The same threats discussed above are now opened up 504 on the MN. 506 6.1.2.1. Scenario 3 - Both end-points of a session as MNs 508 If a MN originates a VoIP call to a CN which is also mobile, the MN 509 sends the CN a binding update to achieve route optimization. The CN 510 will also in this case send a BU to the MN (originator) and update 511 the binding cache. An attacker could possibly determine the end- 512 points of this session by various means. For example, it may learn 513 about the call/session by eavesdropping on the local link of either 514 party, or possibly by eavesdropping on the SIP signalling elsewhere 515 in the internet. 517 6.1.2.1_Threat: 519 An attacker can send a BU to either the MN or the CN or both and 520 disrupt the communication. So, a passive attacker could be just 521 sitting and learning about the VoIP call, and possibly launch the 522 malicious BU to the MN and the CN from another network. 524 6.1.2.1_Effect: 526 Cause packets to be routed to the incorrect destination, leading to 527 either denial-of-service or snooping (privacy violation) or worse 528 modifying the content of the traffic by MITM. 530 6.1.2.1_Requirement: 532 Same as Req 6.1.1.1_Requirement 534 536 6.1.3. BU flooding 538 This section deals with threats that are related to nodes involved in 539 mobility being flooded by BUs. 541 6.1.3.1. Scenario 4 - BU flooding 543 Malicious nodes could flood a CN with fake BUs affecting the binding 544 cache. 546 6.1.3.1_Threat: 548 A malicious node or virus could keep sending fake BUs to other IPv6 549 nodes at a very rapid rate and thereby create unnecessary state in an 550 IPv6 node. It could also possibly cause the binding cache memory to 551 become inundated with entries for nodes that have no real meaning and 552 thereby preventing a valid node's entry being created in the binding 553 cache. 555 6.1.3.1_Requirement: 557 a) An IPv6 node that receives binding updates SHOULD NOT create state 558 until it has verified the authenticity of the sender. 560 b) An IPv6 node SHOULD have the capability to reject binding updates. 562 6.2. Threats related to attacks originating from the same subnet/link 563 as the MN 565 There are multiple possibilities here depending on the type of access 566 medium. If the access medium is a shared multiple access network such 567 as a wireless network (802.11, wide-area cellular) or an Ethernet 568 LAN, the attacker could do passive monitoring of the packets. The 569 attacker could possibly not intercept the packets and forward them 570 unless he takes on the role of the default router and cause packets 571 from the MN to be delivered to him instead of the actual default 572 router. However this threat can be classified as a general threat and 573 one that is not specific to Mobile IPv6. 575 6.2.1. Scenario 5 - MITM via a spoofed BU 577 A man-in-the-middle attack can be mounted on an ongoing session by 578 sending a spoofed to the CN or the MN. 580 6.2.1_Threat: 582 By being able to passively monitor the traffic, the attacker could 583 learn about the CNs that the MN is communicating with and also 584 determine to which CNs the MN is sending BUs. The attacker could in 585 such a case send a spoofed BU packet to the same CN. Furthermore, it 586 can very easily send a spoofed BU to the MN, claiming that the CN is 587 currently on the same link as the MN (i.e. co-located with the 588 attacker). 590 6.2.1_Effect: 592 This will cause the traffic from the CN to the MN be routed 593 elsewhere. Changing the route of packets from CN to MN is a serious 594 threat. It can be classified as a DoS attack on the MN or the CN. 595 The latter case where the attacker also sends a BU to the MN results 596 in a MITM, where the attacker could possibly alter the contents of 597 the traffic. 599 6.2.1_Requirement: 601 Same as verifying if the sender is authorized to send BUs for the 602 home address contained in the BU. 604 6.2.2. Scenario 6 - Man-in-the-middle attack via the default router 606 A man-in-the-middle attack could be launched on hosts attached to a 607 link by having them change their default router 609 6.2.2_Threat: 611 If the attacker takes on a more active role, it can insert itself as 612 a MITM between the MN and the CN, by pretending to be the default 613 router to the MN and the MN to the CN. 615 6.2.2_Effect: 617 The attacker could possibly modify/change the contents of the 618 traffic. On a wired or wireless LAN or wireless network, the attacker 619 cannot prevent the router advertisements from the default router (DR) 620 reaching the MN. So it would probably be difficult for the attacker 621 to intercept packets to/from the MN by pretending to be the DR. 622 However the attacker who is on the link and monitoring the router 623 advertisements can in effect send a new router advt. (proclaiming 624 himself as the DR) immediately after the actual routers advt and 625 thereby overriding the true routers advt. from the MNs perspective. 626 If an attacker can take on the role of the default router there are 627 other more significant threats than the ones that Mobile IP 628 introduces and it goes for both v4 and v6. 630 6.2.2_Requirement: 632 This is not specific to Mobile IPv6 and hence no requirement is 633 generated as a result. 635 6.2.3. Scenario 7 - Moving to an untrusted access point 637 The MN could attach itself to an access point that has not been 638 authenticated. 640 6.2.3_Threat: 642 The attacker could easily have a WLAN access point and cause the MN 643 to switch to the new AP and a different network (maybe) on which the 644 attacker could be at the DR and thereby able to intercept and modify 645 packets on the uplink and downlink. 647 In this attack, the attacker uses the original base station as its 648 uplink, and pretends to be a single node to the original base 649 station. 651 6.2.3_Effect: 653 In this type of an active attack, the MN continues its session with 654 the CN, but in the case where the attacker uses the original base 655 station the binding cache entry for the MN in the CN is that of the 656 attacker's address. The attacker continues to forward doctored 657 packets (received from the CN) to the MN. The attacker essentially 658 changes the destination address from it's own (CoA) address to the 659 MNs CoA before forwarding the packets and the MN as such is unaware 660 of the MITM. 662 The CN is unaware that the packets to the MN are now being sent to 663 another node as there is no way that the CN could verify the 664 ownership of the home address in the BU. 666 In the case of a wide area wireless network (CDMA/TDMA) it is 667 possible to mount a passive attack on the traffic between the MN and 668 the CN on the air-interface. However it would be much more difficult 669 (cost-perspective) in having a MN change the AP/BTS that it is 670 currently using. The attacker can learn the details of the MN and 671 it's communicating partners and mount an attack from elsewhere. 673 The CN which continues to receive packets from the MN (with src 674 address, MNs CoA) has also received a BU from the attacker and has 675 changed the entry for the MN in it's binding cache. As a result the 676 CN's packet stream to the MN will flow to the attacker at the address 677 specified. The CN may tend to believe that the CoA sent in the BU is 678 an alternative CoA which MIPv6 allows. 680 6.2.3_Requirement: 682 The Mobile Node SHOULD be capable of ascertaining the identity of the 683 access point to which it is attaching and authenticate it. 685 6.2.4. Scenario 8 - Passive monitoring of traffic 687 An attacker who is able to passively monitor the traffic could send a 688 fake Binding Ack to the MN as a response to a BU sent by the MN. 690 6.2.4_Threat: 692 By being able to passively monitor the traffic, the attacker could 693 learn about the CNs or HA that the MN is communicating with and also 694 determine to which CNs or HA the MN is sending BUs. The attacker 695 could thus synchronize with the MN such that when MN sends a BU then 696 attacker replies to MN with a fake Binding Acknowledgment different 697 than the true Binding Acknowledgment (Status, Lifetime or Refresh 698 fields). 700 6.2.4_Effect: 702 This can lead to (1) MN sends unnecessary BU's (subject to rate 703 limiting of sending BU's) or (2) MN doesn't send a BU that is 704 necessary. As further effects of (2) unnecessary triangular routing 705 takes place or MN is not reachable at all. 707 6.2.4_Requirement: 709 Upon receiving a packet carrying a Binding Acknowledgement, a mobile 710 node SHOULD ensure it trusts the sender of that Binding 711 Acknowledgment. 713 715 6.3. Threats related to attacks originating from the same subnet/link 716 as the CN 718 The fact that the attacker can be on the same link as the CN has 719 other implications as well. When considering this possibility most of 720 the same issues already outlined apply. In many cases the CN may 721 also be an MN to a different CN and in that case all the attacks 722 listed above apply here as well. 724 6.3_Threat: 726 It should be pointed out that in the absence of MIPv6 today an 727 attacker on this link is able to accomplish quite a lot of mischief, 728 such as spoofing neighbor discovery or inserting itself as an MITM 729 using link level techniques. 731 It is also easier for the attacker to now insert himself as a MITM 732 and intercept and modify packets sent between the MN and the CN. So 733 an attacker on the CNs link can mount an active attack more 734 effectively than if he is on the MNs link. 736 6.4. Attacker located on the same subnet/link as the HA 738 If a mobile node is on its home network, it does not need to send any 739 binding updates to CNs and as such Mobile IP is not required. 741 6.4.1. Scenario 9 - Spoofed BUs sent on behalf of an MN which is at 742 home 744 An attacker on the same subnet as the MN (on its home subnet) could 745 send BUs to CNs that the node is communicating with and disrupt the 746 traffic. 748 6.4.1_Threat: 750 An attacker on the same subnet as the MN (on its home subnet) could 751 send BUs to CNs that the node is communicating with and disrupt the 752 traffic. Since the attacker is on the same subnet as the MN, i.e. at 753 home, it may be aware of the CNs that the MN is communicating with. 754 Therefore it can easily send a BU to these CNs and inform them that 755 the MN is now reachable at some COA. 757 6.4.1_Effect: 759 Traffic disruption by diverting the packets to an unwanted COA; DoS 760 attack agains the MN, or Man-in-the-Middle attack with some more 761 effort. 763 6.4.1_Requirement: 765 Same as verifying if the sender is authorized to send BUs for the 766 home address contained in the BU. 768 With some more effort, the attacker can insert himself between the MN 769 and the CN, even when the MN is at home. That is, the attacker sends 770 a BU on the behalf of the CN to the MN, telling that the CN is a 771 mobile node and currently co-located at the same network as the MN 772 is. Simultaneously, it sends a BU to the CN telling the CN that the 773 MN is currently at the attacker's address. Since the CN is not 774 assumed to check that the Home Address and the COA are at different 775 subnets, there is no reason why the latter wouldn't work either. 777 6.4.2. Scenario 10 - Intercepting BUs sent to HA 779 If the attacker is on the same subnet as the HA of an MN, the 780 attacker could possibly intercept the BU packet the MN sends to the 781 HA (while the MN is roaming). The attacker could spoof the HA and 782 send a Binding request to the MN even when it is not required. 784 6.4.2_Threat: 786 If the attacker is on the same subnet as the HA of an MN, the 787 attacker could possibly intercept the BU packet the MN sends to the 788 HA (while the MN is roaming). The attacker could spoof the HA and 789 send a Binding request to the MN even when it is not required. 790 Binding requests can also be sent by other malicious nodes to the MN 791 or in the worst case scenario, the MN could be flooded by binding 792 requests from an attacker with spoofed source IP addresses. 794 6.4.2_Effect: 796 1 DoS for the MN as the Binding update could be rejected. 798 2 The attacker himself pretends to be the HA and begins to intercept 799 traffic destined for the MN originating from the CNs. 801 3 The MN may not be sending BUs to CNs in order to maintain 802 location confidentiality. However Since the attacker is aware of 803 the COA of the MN at all times, the location privacy of the MN is 804 lost. 806 4 Flood the MN with a large number of binding requests. 808 6.4.2_Requirement: 810 The MN SHOULD be capable of authenticating binding requests. The MN 811 SHOULD/MAY only process binding requests which are originated by 812 nodes that are in the binding update list of the MN. 814 6.4.3. Scenario 11 - BU cancellation at HA by malicious node 816 A malicious node on the home subnet can send a binding update to the 817 HA for an MN with lifetime set to zero and thereby cause the binding 818 cache entry to be deleted. 820 6.4.3_Threat: 822 A malicious node on the home subnet can send a binding update to the 823 HA for an MN with lifetime set to zero and thereby cause the binding 824 cache entry to be deleted. The malicious node could cause the HA to 825 believe that the MN has returned to its home network and hence does 826 not need a binding to some COA. 828 6.4.3_Requirement: 830 The HA MUST authenticate any binding update received by it before 831 making any changes to the binding cache entries. 833 835 6.5. Attacker on the path between the CN and HA 837 If an attacker is able to insert himself on the path between the CN 838 and the HA, it may open up the following security gaps. 840 6.5.1. Scenario 12 - Masquarade/DoS attack 842 6.5.1_Threat: 844 If the MN and CN are communicating via Mobile IPv6 but the MN is not 845 sending Binding Updates to the CN, all packets originated by the CN 846 are first sent to the Home Address. The packets are then received by 847 the HA, and tunneled to the MN. Now, if the attacker is on the CN-HA 848 link, including CN's local link and the HA link, it is able to 849 eavesdrop on all traffic flowing from the CN to the MN. Thus, if the 850 MN is not on-line, the attacker can easily play the MN's part, and 851 masquerade as an MN. On the other hand, if the MN is on-line, the 852 attacker can easily disrupt communications e.g. by sending TCP RSTs. 854 6.5.1_Effect: 856 Masquarade when the MN is off-line, DoS otherwise. 858 6.5.1_Requirement: 860 Any requirements to address this threat is outside the scope of 861 Mobile IPv6 as the threat described above is a generic one. However 862 MIPv6 itself SHOULD not cause further grief in establishing end-to- 863 end security either using IPsec or other mechanisms. 865 6.5.2. Scenario 13 - CN challenge to a BU sent by the MN 867 6.5.2_Threat: 869 If the MN sends a binding update to the CN and the CN rather than 870 updating the cache decides to challenge the MN to verify if in fact 871 the MN was the one that originated the BU, it can send a 872 challenge/cookie/foobar to the MNs home address instead of the CoA. 873 If the routing infrastructure is intact, the home agent of the MN 874 will receive this packet containing the challenge and will 875 forward/tunnel the packet to the MN (maybe over a secure tunnel). The 876 MN on receiving the challenge/cookie may act on it and send it back 877 to the CN. The CN on receiving the challenge it sent out originally 878 to the MNs home address has reason to believe that the MN was indeed 879 the one that originated the BU and can go ahead and create an entry 880 in the binding cache. 882 However if the attacker is on the CN-HA path, including CN's local 883 link and the HA link, s/he can intercept this packet containing the 884 challenge and send a spoofed response to the CN and cause it to 885 create an invalid entry for the MN in it's binding cache. The 886 attacker on the CN-HA path and an attacker on the MNs link could be 887 co-conspirators and be able to insert themselves in the communication 888 path. 890 6.5.2_Effect: 892 Ability to insert onself as a MITM. 894 6.5.2_Requirement: 896 Same as verifying if the sender is authorized to send BUs for the 897 home address contained in the BU. 899 6.6. Attacker on the path between the MN and CN 901 If the MN is not at home, and the attacker is on the path between the 902 MN and the CN (including the MN's and CN's local link), it can 903 eavesdrop on packets sent by the MN to the CN. Therefore it can 904 easily learn the Home Address of the MN. 906 6.6.1. Scenario 14 - Non MIPv6 Specific 908 6.6.1_Threat: 910 Since the attacker can eavesdrop on the traffic flowing from the MN 911 to the CN, it can easily cause DoS e.g. by sending TCP RSTs. 913 6.6.1_Effect: 915 Selective DoS. 917 6.6.1_Requirement: 919 This threat is also non Mobile-IPv6 specific and hence no requirement 920 is generated. 922 6.6.2. Scenario 15 924 6.6.2_Threat: 926 Taking advantage of its topological location, the attacker can send 927 BUs to the CN, giving the MN's Home Address. This threat is 928 different from threat 6.6.1.1_Threat in the sense that this attack 929 works even in the presence of fully functioning ingress filtering and 930 even if Alternate CoAs were disallowed. 932 6.6.2_Effect: 934 MITM/DoS. 936 6.6.2_Requirement: 938 Same as verifying if the sender is authorized to send BUs for the 939 home address contained in the BU. 941 6.7. Threat model for the case where the MN sends a binding update to 942 the previous router asking it to take on the role of an HA temporarily 944 Section 10.9 of the Mobile IP specification allows a MN to send a 945 binding update to a router (that can act as a Home Agent) on the 946 previous subnet that the MN was attached to, and request it to 947 forward packets destined to the MNs previous COA to the new COA. The 948 specification also states : "As with any packet containing a Binding 949 Update (see section 5.1), the Binding Update packet to this home 950 agent MUST meet the IPsec requirements for Binding Updates, defined 951 in Section 4.4." However it is not clear how the MN could have 952 established a security association with that router on the previous 953 subnet. 955 6.7.1. Scenario 16 957 6.7.1_Threat: 959 An attacker who is aware of a MN being currently attached to a subnet 960 could send a binding update to a router on that subnet (which is 961 willing to act as an HA) with the H bit set. 963 6.7.1_Effect: 965 This binding update which is spoofed causes the HA router on that 966 subnet to create a binding entry for the legitimate MN to some other 967 COA. It will start intercepting the packets destined to the MN (which 968 is still on the same subnet) and forward(tunnel) it to the COA 969 specified in the binding update. Traffic destined to a MN is now 970 redirected elsewhere causing a DoS attack. 972 6.7.1_Requirement: 974 A router on a subnet willing to take on the role of an HA for a MN 975 (even on a temporary basis) MUST establish a security association 976 before the router will accept BUs for a MN with the H bit set. 978 980 6.8. Other threats, including those that target the Home Agent 982 6.8.1. Scenario 17 - Home Agent discovery via the ICMP anycast Home 983 Agent discovery message 985 Section 9.2 of the specification [Ref1]: "As described in Section 986 10.7, a mobile node attempts dynamic home agent address discovery 987 by sending an ICMP Home Agent Address Discovery Request message to 988 the "Mobile IPv6 Home-Agents" anycast address [10] for its home IP 989 subnet prefix, using its care-of address as the Source Address of 990 the packet. A home agent receiving such a Home Agent Address 991 Discovery Request message that is serving this subnet (the home 992 agent is configured with this anycast address on one of its 993 network interfaces) SHOULD return an ICMP Home Agent Address 994 Discovery Reply message to the mobile node (at its care-of address 995 that was used as the Source Address of the Request message), with 996 the Source Address of the Reply packet set to one of the global 997 unicast addresses of the home agent." 998 The reply message MAY contain a list of all possible home agents 999 on that subnet. 1001 6.8.1_Threat: 1003 An attacker who knows the home address of a MN can possibly send a 1004 home-agent discovery message to the MN's home subnet and receive a 1005 list of all home agent routers on that subnet. 1007 6.8.1_Effect: 1009 This would expose the structure of the operator's network (to some 1010 extent) which is not desirable. It would also allow an atacker to 1011 determine the routers acting as home agents and mount DoS attacks 1012 or other types of attacks on these routers and thereby cause these 1013 routers to be unable to forward packets to MNs that they are 1014 intended to serve. 1016 6.8.1_Result: 1018 One of the things that operators might do is to make sure their 1019 firewalls do not allow any ICMP home agent discovery messages to 1020 be let in. This would defeat the whole purpose of having the 1021 ability to do home agent discovery. 2 Use the Home Agent as a 1022 packet reflector 1024 6.8.1_Requirement: 1026 An HA which responds to an ICMP home agent discovery message 1027 SHOULD only do so after authenticating the MN's identity. 1029 6.8.2. Scenario 18 - HA used as a Packet reflector 1031 6.8.2_Threat: 1033 If an attacker can make a Home Agent to believe that a Mobile Node 1034 is at a given CoA, the attacker can then use the Home Agent as a 1035 packet reflector when launching a distributed DoS attack against 1036 the node at the CoA. That is, by simply sending packets to the 1037 Home Address, the Home Agent will tunnel them and send them to the 1038 DDoS target. An HA will create a binding entry for an MN if the 1039 authentication in the BU is valid. Using the HA as a packet 1040 reflector makes it easier for the DDoS attacker to hide itself, 1041 making it harder to succesfully shut down the DDoS attack. 1043 6.8.2_Requirement: 1045 The MN and HA MUST have a strong security association and the HA 1046 MUST verify the BUs sent by any IPv6 node requesting the HA to 1047 intercept packets destined for it and tunnel them to it's COA. 1049 6.8.3. Scenario 19 - CN as a packet reflector 1051 According to the Mobile IPv6 spec: "A node receiving a packet that 1052 includes a Home Address option MAY 1053 implement the processing of this option by physically exchanging 1054 the 1055 Home Address option field with the source IPv6 address in the 1056 IPv6 1057 header." 1059 An attacker can simply spoof the home address option in packets 1060 sent to a CN causing the CN to swap the source address with the 1061 address contained in the home address option. This causes the CN 1062 to become a packet reflector in attacks on nodes whose addresses 1063 may be known. Using the CN as a packet reflector may make it 1064 easier for the DDoS attacker to hide itself, making it harder to 1065 successfully shut down the DDoS attack. 1067 6.8.3_Requirement: 1069 CNs SHOULD NOT/MAY NOT process any packet (BU or not) containing a 1070 Home Address option unless they have verified that that the node 1071 sending the packets is authorized to use the home address in the 1072 destination option. 1074 6.8.4. Threat model specifically in wireless networks 1076 Wireless network technology typically enables security features 1077 through its own technology specific techniques. To a greater 1078 (GSM) or lesser (802.11) degree these techniques offer some level 1079 of security. The network provider must in any case enable these 1080 features and it is sometimes the case that this is not done. 1081 There are well-known deficiencies in the security schemes of some 1082 of the technologies. In general the wireless link may easily 1083 become the weakest link in terms of system and network security. 1085 7. Requirements for MIPv6 Security 1086 7.1. General Requirements 1088 A Should be no worse than IPv4 as it is today. 1090 B Should be as secure as if the mobile node was on the home link 1091 without using Mobile IP. 1093 C Identity verification MUST not rely on the existence of a 1094 gloabl PKI. 1096 D Any solution that is developed for securing the binding updates 1097 (MN-HA and MN-CN) should be able to use whatever security 1098 associations may already exist to minimize the threats created 1099 by on-axis attackers. In particular: 1101 D.1 1102 It is assumed that in all schemes there will be some form of 1103 pre-established security association between a mobile node and 1104 its home agent. Such a security association should be used to 1105 minimize the threats. In this context it makes sense exploring 1106 the complexity of handling mobile-to-mobile communication 1107 differently than mobile-to-nonmobile communication. As an 1108 example, if two MNs are communicating while visiting fairly 1109 untrusted visited links, it may make sense to take advantage of 1110 the fact that each mobile has a security association with its 1111 home agent when exchanging the messages needed to establish the 1112 binding. Thus these messages might travel MN1->HA1->HA2->MN2 1113 (and in the reverse direction) so that the risks for a MITM 1114 attack are limited to the HA1<->HA2 path. 1116 D.2 1117 In some deployments a PKI may exist (encompassing for e.g some 1118 home "domain" which includes a set of MNs, their HAs and some 1119 CNs). In that case it should be possible to use the local PKI 1120 to prevent MITM attacks when the CN is covered by that PKI. 1121 (For instance, if both MN and CN share a trust chain in the PKI 1122 sense it should be possible to take advantage of that.) 1124 D.3 1125 If a method to validate public keys (without the existence of 1126 CAs and PKI) is created or exists, then it should be possible 1127 to take advantage of that mechanism for improved security of 1128 the BUs. 1130 7.2. Specific to Mobile IPv6: 1132 0 Security for binding updates is MANDATORY. This is already the 1133 case for MIPv6 and as such is not a new requirement. However 1134 the mechanism used for securing binding updates MUST be one 1135 that is scalable and does not rely on existence of PKIs. 1137 1 It SHOULD be extremely difficult for an attacker "off-axis" 1138 i.e. an attacker that cannot snoop packets on either of the 1139 three legs of the paths, to divert traffic. This difficulty 1140 should be on the order of correctly guessing a very large 1141 random number. 1143 2 It SHOULD be possible to leverage the only security association 1144 that can be preconfigured (the MN-HA SA) to secure BUs to CNs. 1146 3 It MUST be possible for a mobile node to be anonymous while 1147 still taking advantage of route optimization. Thus if a Mobile 1148 Node is using RFC 3041 temporary addresses for its home and/or 1149 COA it must be able to use a different visible identity when it 1150 uses a different temporary address. 1152 4 It SHOULD be possible to negotiate alternative cypher 1153 suites/algorithms. It SHOULD be possible to negotiate 1154 alternative mechanisms. All implementations MUST implement one 1155 designated mechanism and algorithm for interoperability 1156 reasons. 1158 5 If IPsec is used as part of the solution it SHOULD not place 1159 additional requirements on the set of IPsec SPD selectors 1160 beyond what is in common implementations. (Note: This is 1161 however debatable. A soon to be published I-D will identify the 1162 issues of using IPsec in conjunction with Mobile IPv6.) 1164 6 Router Advertisements sent by the HA to the MN MUST be secured. 1166 7 Scalability of mechanisms using symmetric or asymmetric keys 1167 MUST be considered in any solution. 1169 8 SHOULD optimize the number of message exchanges and bytes sent 1170 between the participating entities (MN, CN, HA). This is an 1171 important consideration for some MNs which may operate over 1172 bandwidth constrained wireless links. 1174 9 A CN SHOULD be capable of rejecting BUs sent by a MN. If a CN 1175 rejects a BU, the MN SHOULD refrain from sending further BUs to 1176 that CN (for a period of time). 1178 10 Any approach MUST consider the scalability issues and 1179 computational capabilities of the entities in a mobile 1180 environment, especially MNs and CNs. The expense associated 1181 with generating keys or public key operations or Diffie Hellman 1182 computations SHOULD be accounted for. 1184 7.3. Requirements from Threats 1186 6.1.1.1_Requirement 1187 A correspondent node MUST not update its binding cache on 1188 receiving a binding update from any IPv6 node without verifying 1189 that the packet was sent by a node authorized to create binding 1190 cache entries for the home address carried in the home address 1191 option of the BU. 1193 6.1.1.2_Requirement 1194 No Mobile IPv6 specific requirements can be generated from this 1195 threat. 1197 6.1.1.4_Requirement 1198 a) An IPv6 node that receives binding updates SHOULD NOT create 1199 state 1200 until it has verified the authenticity of the sender. 1202 b) An IPv6 node SHOULD have the capability to reject binding 1203 updates. 1205 6.2.3_Requirement 1206 The Mobile Node SHOULD be capable of ascertaining the identity 1207 of the access point to which is is attaching and authenticate 1208 it. 1210 6.2.4_Requirement 1211 Upon receiving a packet carrying a Binding Acknowledgement, a 1212 mobile node SHOULD ensure it trusts the sender of that Binding 1213 Acknowledgment. 1215 6.4.2_Requirement 1216 The MN SHOULD be capable of authenticating binding requests. 1217 The MN SHOULD/MAY only process binding requests which are 1218 originated by nodes that are in the binding update list of the 1219 MN. 1221 6.4.3_Requirement 1222 The HA MUST authenticate any binding update received by it 1223 before making any changes to the binding cache entries. 1225 6.5.1_Requirement 1226 Any requirements to address this threat is outside the scope of 1227 Mobile IPv6 as the threat described above is a generic one. 1228 However MIPv6 itself SHOULD not cause further grief in 1229 establishing end-to-end security either using IPsec or other 1230 mechanisms. 1232 6.7.1_Requirement 1233 A router on a subnet willing to take on the role of an HA for a 1234 MN (even on a temporary basis) MUST establish a security 1235 association before the router will accept BUs for a MN with the 1236 H bit set. 1238 6.8.1_Requirement 1239 An HA which responds to an ICMP home agent discovery message 1240 MUST only do so after authenticating the MN's identity. 1242 6.8.2_Requirement 1243 The MN and HA MUST have a strong security association and the 1244 HA MUST verify the BUs sent by any IPv6 node requesting the HA 1245 to intercept packets destined for it and tunnel them to it's 1246 COA. 1248 6.8.3_Requirement 1249 CNs SHOULD NOT/MAY NOT process any packet (BU or not) 1250 containing a Home Address option unless they have verified that 1251 that the node sending the packets is authorized to use the home 1252 address in the destination option. 1254 8. Acknowledgments 1255 We would like to thank feedback from many WG members especially 1256 Claude Castellucia, Alexandru Petrescu, Gabriel Montenegro and 1257 Francis Dupont for their comments and suggestions to make this 1258 document better. 1260 9. References 1262 [Ref1] draft-ietf-mobileip-ipv6-13.txt - Work in progress 1264 [Ref2] draft-nikander-ipng-address-ownership-00.txt - Work in 1265 progress 1267 10. Authors's Addresses 1269 Pekka Nikander 1270 Pekka.Nikander@nomadiclab.com 1272 Dan Harkins 1273 dharkins@lounge.org 1275 Basavaraj Patil 1276 Basavaraj.Patil@nokia.com 1278 Phil Roberts 1279 Proberts@megisto.com 1281 Allison Mankin 1282 mankin@isi.edu 1284 Erik Nordmark 1285 Erik.Nordmark@eng.sun.com 1287 Thomas Narten 1288 narten@raleigh.ibm.com 1290 Appendix A. Background 1292 There are two basic ways of securing communications and data. One 1293 is to use cryptography. The second one is to protect the 1294 communications or data using physical and programmatic means, 1295 basically making it infeasible to tamper with the data without the 1296 required privileges. In the case of communication, the latter 1297 approach means that the actual networking equipment must be 1298 physically protected, e.g., through pressurising the cables. 1300 When new functionality is added to a networking architecture, the 1301 functionality usually means opening up new possibilities for 1302 tampering with some (management) data or communications. That is, 1303 some of the physical and/or progammatic means of protection are 1304 lowered, thereby creating new security vulnerabilities. In the 1305 case of Mobile IPv6, there are two new major issues: the Binding 1306 Cache, and node mobility. Basically, in order for Mobile IPv6 to 1307 be as secure as the system would be without it, there must be 1308 means to protect the Binding Cache against unauthorized 1309 modification, and to provide reasonable protection for the Mobile 1310 Nodes against malicious networks and for the networks against 1311 malicious Mobile Nodes. 1313 Furthermore, the use of wireless link layers creates new threats. 1314 For example, unless care is taken at the link layer, it may be 1315 hard for a Mobile Node to make sure that it is actually 1316 communicating with the very access router that it thinks it is 1317 communicating with. However, these threats are mostly independent 1318 of Mobile IPv6, and it is not expected that Mobile IPv6 security 1319 would necessarily bring any remedy to them. 1321 When cryptography is used to secure communications, there must be 1322 a way of creating a session key. The session key may then be used 1323 to protect (some of) the communicated data against eavesdropping 1324 and/or unauthorized modification. However, if the communicating 1325 parties do not have any direct nor indirect security relationship 1326 between them, there are no known methods for creating such session 1327 keys in a manner that would be secure against all attackers. (One 1328 example of an indirect security relationship is one created with 1329 the help of a trusted third party.) 1331 In the case of Mobile IPv6, the main threat we want to protect 1332 against is unauthorized creation or alteration of Binding Cache 1333 Entries. One way to define who is authorized in this case is to 1334 define that whoever "owns" the Home Address is authorized to 1335 create Binding Cache Entries for it [Ref2]. 1337 Unless the IPv6 addresses are themselves used as some kind of pre- 1338 established security relationships, the only other way of 1339 providing security relationships between an arbitrary pair of a 1340 Mobile Node (MN) and a Corresponding Node (CN) is to create a 1341 global trusted third party based security infrastructure. 1342 Experience has shown that building such an infrastructure is 1343 extremely hard, and not likely to succeed any time in the near 1344 term future. 1346 Thus, it seems like it is, in practice, impossible to build a 1347 deployable Mobile IPv6 security solution that is secure against 1348 all possible classes of attackers. Thus, this document goes into 1349 some length and detail in describing threats caused by various 1350 classes of attackers, keeping in mind the goal of "no worse than 1351 IP v4 with switched Ethernets." 1353 Generic attack descriptions 1354 Here we give a brief overview of the possible attacks. 1356 - In a Masquarade attack a node plays the role of another node 1357 towards a third node. That is, if Mallory is able to convince 1358 Bob that he is Alice, he is masquarading as Alice. Basically, 1359 even in the current IPv4 internet, if Alice is switched off or 1360 off-line, it is fairly easy to masquarade as Alice if Mallory 1361 are able to eavesdrop or anticipate the traffic flowing back 1362 from Bob to Alice. 1364 - In a Man-in-the-Middle (MITM) attack a node plays a double 1365 masquarede. That is, Mallory plays Bob to Alice and Alice to 1366 Bob. In the current IPv4 internet, if the attacker is on the 1367 path between two nodes, or at the same physical link with 1368 either of them, there are a number of mechanisms that can be 1369 emploeyd to launch MITM attacks. The mechanisms include, for 1370 example, tampering with the routing tables and ARP spoofing. 1372 - In a Denial-of-Service (DoS) attack, an attacker prevents a 1373 node from communicating with one or more other nodes. For 1374 example, Mallory may be able prevent Alice from communicating 1375 with Bob, even though they could communicate without the 1376 presense and acts of Mallory. A Denial-of-Service attack can 1377 either be selective, e.g. disrupting communications between 1378 Alice and Bob, generic, e.g. disrupting all communications of 1379 Alice, or random, e.g. disrupting some communications of Alice. 1381 In the current IPv4 internet, it is fairly easy to launch a large 1382 number of different kinds of Denial-of-Service attacks. Thus, the 1383 aim of this draft is to point out some new DoS threats so that 1384 they can be potentially addressed. 1386 Appendix B: Question and Discussions 1388 - Comment1: 1390 If the MN is moving in a rapid manner and changing it's CoA 1391 quite frequently as a result, it makes it difficult for the 1392 attacker to stay as a MITM. The MN on changing it's CoA will send 1393 a new BU to the CN and update the binding cache. Unless the 1394 attacker is aware of the MN's movement and changes to CoA, it will 1395 be hard to continue to be a MITM (but I guess it depends on what 1396 point in the network structure the attacker sits). On the other 1397 hand, at least in theory an attacker could just send a continuous 1398 stream of Binding Updates, and unless the CN had checks for this 1399 specific condition, most packets would still flow through the 1400 attacker. 1402 - Question1: 1404 Does the fact that a BU can contain alternative CoAs open up 1405 further security problems? 1407 IMHO, no. It is 1408 foolish to rely on the source address not being spoofed. 1409 Personally, I don't believe that it will be ever possible to 1410 mandate ingress PRF filtering everywhere. Thus, from the security 1411 point of view, the source address and the Alt CoA should be 1412 considered equally trustworthy: both can be spoofed. 1413 I agree. We should just capture the ability 1414 of the MN to send an alternative COA to be used in the creation of 1415 the binding entry in the cache of the CN, but note that the same 1416 issues that exist for the source address exist for the alternate 1417 COA. 1419 - Question2: 1421 (Question: What does an IPv6 node do when it has all these entries 1422 in its binding cache that have some lifetime associated with them 1423 and it is not possible to add further entries in this cache 1424 without eliminating some. I guess it would be upto the 1425 implementation to figure out ways to delete entries that are not 1426 being used or FIFO type of mechanisms). 1428 - Comment 2: 1430 An attacker on the same subnet as the HA can 1431 do a lot of harm. However it is expected that the home subnet is 1432 protected quite effectively and such attacks as described above 1433 can only be launched by an insider. 1435 In the case of wireless (Cellular) networks 1436 it is expected that the HA is on a virtual subnet and a mobile 1437 node as such is never really on it's home subnet ever. A Mobile 1438 node performs deregistration when it is back on it's home subnet, 1439 but in a cellular network that home subnet as such does not really 1440 exist. A MN may be in it's home administrative domain network but 1441 not on it's home subnet. Hence there is always a binding for the 1442 MN to some COA. Such HAs will be well protected and an attacker 1443 being on the same subnet as the HA would be quite difficult. 1445 1447 - Comment 3: 1449 It is not necessary that the default router that the MN 1450 is using be the router that acts as the temporary home agent to 1451 forward the packets. The attacker could be on the same subnet as 1452 the MN and listen to the router advertisements ad determine the 1453 one that has the capability to act as an HA for that subnet. The 1454 attack could be launched from the same subnet or from elsewhere. 1455