idnits 2.17.1 draft-lim-mext-multiple-coa-verify-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 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 868. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 879. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 886. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 892. 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- 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 10, 2008) is 5768 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 3775 (ref. '1') (Obsoleted by RFC 6275) == Outdated reference: A later version (-14) exists of draft-ietf-monami6-multiplecoa-05 == Outdated reference: A later version (-05) exists of draft-ietf-monami6-mipv6-analysis-04 == Outdated reference: A later version (-05) exists of draft-soliman-monami6-flow-binding-04 == Outdated reference: A later version (-03) exists of draft-haddad-mext-enhanced-reachability-test-00 == Outdated reference: A later version (-06) exists of draft-dupont-mipv6-rrcookie-04 Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MEXT Working Group B. Lim 3 Internet-Draft C. Ng 4 Intended status: Informational K. Aso 5 Expires: January 11, 2009 Panasonic 6 S. Krishnan 7 Ericsson 8 July 10, 2008 10 Verification of Care-of Addresses in Multiple Bindings Registration 11 draft-lim-mext-multiple-coa-verify-02 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on January 11, 2009. 38 Abstract 40 Using multiple care-of address registration, there is a possibility 41 that a malicious mobile node could create multiple care-of address 42 bindings that does not belong to the mobile node at its home agent. 43 The home agent would accept these bindings without verifying them due 44 to the trust relationship it has with the mobile node. With these 45 bindings, the mobile node can launch attacks by asking the home agent 46 to flood the victims of these care-of addresses with useless packets. 47 To mitigate such a problem, this memo introduces a few possible 48 verification mechanisms that the home agent would use in order to 49 verify the care-of addresses for the mobile node before using them 50 for packet routing. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Problem Scope . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2.1. Initiating the Attack . . . . . . . . . . . . . . . . . . 4 57 2.2. Launching the Attack . . . . . . . . . . . . . . . . . . . 6 58 3. Analysis: Possible Solution Approaches . . . . . . . . . . . . 7 59 3.1. Restrict Multiple Care-of Addresses Registration in a 60 Single Binding Update Message . . . . . . . . . . . . . . 7 61 3.2. Using Cryptographically Generated Addresses . . . . . . . 9 62 3.3. Using a Third Party Trusted Entity . . . . . . . . . . . . 10 63 3.4. Using Message Exchanges with a Mobile Node . . . . . . . . 13 64 4. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 17 65 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 66 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 67 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 68 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 69 8.1. Normative References . . . . . . . . . . . . . . . . . . . 17 70 8.2. Informative References . . . . . . . . . . . . . . . . . . 17 71 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 18 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 73 Intellectual Property and Copyright Statements . . . . . . . . . . 21 75 1. Introduction 77 IP mobility allows a mobile node to maintain an ongoing communication 78 session regardless of where the mobile node roams in the Internet. 79 To achieve this constant connectivity, [1] permits the mobile node to 80 register a transient IP address (e.g. care-of address) at an 81 anchoring point (e.g. home agent). The mobile node sends a binding 82 update (BU) message to the home agent for registering its care-of 83 address. With this registration, the home agent could then forward 84 any packets addressed to the mobile node at the mobile node's care-of 85 address. 87 Security has always been a key consideration in user communications. 88 This is especially so in IP mobility where the mobile node frequently 89 changes its point of attachment. One such attack in IP mobility is 90 the registration of an invalid care-of address at the home agent. 91 Such registration allows the attacker to direct its traffic to other 92 nodes. Such an attack is previously ignored since the attacker can 93 only use one fake care-of address, thereby losing communications with 94 its home agent once the fake address is registered. However, [2] 95 permits the registration of multiple care-of addresses by means of 96 using an identification number called Binding Unique Identification 97 (BID) number to distinguish between multiple bindings to a home 98 address. Unless proper security methodologies are implemented, the 99 use of multiple care-of address registration heightens the chances of 100 allowing an invalid care-of address to be registered at the home 101 agent. 103 In Section 2, this document first expands on the problem briefly 104 described in [2] and [3] about the security threat with the binding 105 of fake care-of addresses. Next, possible approaches to mitigate 106 such threat is analyzed in Section 3. 108 2. Problem Scope 110 For Mobile IPv6, it is assumed that the mobile node and its home 111 agent establish some form of mutual authentication such that the home 112 agent trusts the mobile node and will hence accept the registration 113 of any care-of address that the mobile node presents to the home 114 agent. This trust relationship is further strengthened when one 115 assume that ingress filtering is being used such that when the home 116 agent receives a binding update message from the mobile node stating 117 its care-of address as the source address, the home agent trusts that 118 the incoming packets do indeed originate from the specified source 119 address. In addition, the home agent also trusts the routing 120 infrastructure that packets forwarded by the home agent would be sent 121 to the intended destination. 123 However, such a trust is no longer valid when the mobile node 124 utilizes a single binding update message to register its multiple 125 care-of address at the home agent. This technique is explained in 126 [2] with the aim of introducing some optimization when registering 127 multiple care-of address for a mobile node. Such optimization 128 technique is useful in scenarios when resources (e.g. bandwidth) are 129 scarce on some of the mobile node's interfaces, since it allows the 130 mobile node to send a binding update message containing multiple 131 care-of address to the home agent from an interface that does not 132 have such resource constraint. Moreover, in Mobile IPv6, the use of 133 the alternate care-of address option permits the mobile node to 134 achieve the same effect of registering a care-of address for another 135 interface via a specific interface. This introduces the risk of 136 having fake care-of addresses registered at the home agent and 137 compromise the security of the network. One applicable sceanrio that 138 might encounter such a problem is the Long Term Evolution (LTE) 139 system that is being worked on by the Third Generation Partnership 140 Program (3GPP). 142 There is a fundenmental difference between a mobile node using Mobile 143 IPv6 to flood a victim with useless packets and a mobile node using 144 Monami6 to flood a victim with useless packets. The difference lies 145 in that using Monami6, the mobile node can bind a real care-of 146 address at the home agent and use this care-of address to control the 147 flow of attacks to the victims (e.g. to increase the packet 148 transmission rate to the vicitm). In Mobile IPv6, the mobile node 149 loses this means of control as the mobile node can only refresh the 150 binding at the home agent. The example in Section 2.2 illustrates 151 the esclated threat of Monami6 in more details. 153 2.1. Initiating the Attack 155 This problem is best understood through a specific example. Let us 156 assume that a malicious mobile node, MN, sends a binding update 157 message to its home agent, HA, to register multiple care-of 158 addresses. This is illustrated in the Figure 1 below. 160 [Start of packet header] 162 Source Address : CoA 163 Destination Address : HA's address 165 [Mobility Options] 167 Binding Unique Identifier: BID1 169 Binding Unique Identifier: BID2 170 Care-of Address : V1's address 172 Binding Unique Identifier: BID3 173 Care-of Address : V2's address 175 [End of packet header] 177 Figure 1: Binding Update Message for Multiple Care-of Addresses 178 Registration 180 CoA is a valid care-of address owned by MN. MN is attempting to bind 181 addresses of two victims, V1 and V2, at HA in order to launch an 182 attack towards the victims. The binding update message is secured 183 using an IPsec security association to protect the integrity and 184 authenticity. 186 When HA receives this binding update message, it will accept this 187 binding update message based on the following. First, the binding 188 update message is deemed authorized as the correct IPSec association 189 key is used for the message. Second, the trust relationship that HA 190 has with the routing infrastructure allows it to understand that this 191 binding update message is sent from MN. Finally, after the first two 192 checks have succeeded, the trust relationship that HA has with the MN 193 permits it to trust the care-of addresses that are specified in this 194 binding update message. Hence, the binding cache at HA will record 195 three bindings for MN tied to MN's home address (HoA) as shown in 196 Figure 2 below. 198 Binding 1 [HoA, CoA , BID1] 199 Binding 2 [HoA, V1's address, BID2] 200 Binding 3 [HoA, V2's address, BID3] 202 Figure 2: Binding Cache at Home Agent 204 2.2. Launching the Attack 206 With the bindings created at HA, the malicious mobile node can now 207 attempt to flood the victims with useless packets. This type of 208 flooding can cause disruption of services at the victims' end as 209 their devices will be busy processing these packets for meaningless 210 data. This is illustrated in Figure 3. 212 +-----+ 213 +----+ aaaa | | 214 | MN |------| I | +----+ 215 +----+ | N | | CN | 216 | T | +----+ 217 +----+ bbbb | E | a|b 218 | V1 |------| R | a|b 219 +----+ | N | aaaa +----+ 220 | E |------| HA | 221 +----+ bbbb | T | bbbb +----+ 222 | V2 |------| | 223 +----+ +-----+ 225 Figure 3: Packet flooding attack scenario 227 The binding cache at HA contains MN's care-of address along with V1's 228 and V2's addresses. MN uses real-time transport protocol (RTP) and 229 real-time transport control protocol (RTCP) to initiate a video 230 stream from a streaming server (CN). Furthermore, MN could employ 231 flow filtering techniques to assist in the forwarding of packets from 232 HA. Such techniques are described in [4], [5] and [6]. 234 Prior to starting the video flow, MN uses CoA to set filter rules at 235 HA. One of the filter rule would tell HA that the control packets 236 (shown as "a") for the video stream would be forwarded to BID1. 237 Another filter rule informs HA that the data packets (shown in "b") 238 for the video stream would be multicast to BID2 and BID3. When HA 239 receives packets from CN, it would adhere to the filter rules created 240 and forward the packets accordingly. This would cause V1 and V2 to 241 be flooded with unintended data packets. Furthermore, MN can utilize 242 care-of address1 to maintain the attack to V1 and V2 by sending 243 binding update message to constantly renew the lifetime of the 244 bindings. Likewise, MN can also use CoA1 to launch new attacks by 245 binding more victim's addresses at HA and modifying the filter rule 246 to include them in the reception of the data packets. 248 Although both the home agent and the mobile node are mutually 249 authenticated, this does not stop an authenticated mobile node from 250 acting maliciously. Given time, the home agent might be able to 251 detect that the mobile node is acting maliciously and may then deny 252 mobility services to such a mobile node. One such way is when the 253 home agent starts receiving requests from those victims to stop 254 forwarding packets to it. With a substantial amount of such 255 requests, the home agent might launch an investigation to determine 256 if the mobile node was acting maliciously. Hence, we see that a home 257 agent might not be oblivious to such an attack. 259 However, even if the home agent bars a single identity, the attacker 260 may have multiple other identities available at his/her disposal. 261 Take for example, an attacker is able to purchase multiple pre-paid 262 cards for his/her mobile device. This implies that the attacker 263 would have multiple accounts at its disposal. Using these multiple 264 accounts, the attacker can start a spamming attack by flooding 265 victims with useless data. The attacker knows that eventually his/ 266 her account would get banned, but the attacker does not care. The 267 purpose of the attacker has been achieved and that is to disrupt the 268 services of those victims. Furthermore, the attacker can continue to 269 purchase more pre-paid cards to replace those accounts that got 270 banned. Thus, in this sense, having the identity known does not 271 hinder the above problem from occurring. 273 3. Analysis: Possible Solution Approaches 275 This section will analyse possible solutions to counter the threat 276 described in the previous section. One obvious way is for the home 277 agent to stop a mobile node from sending a binding update with 278 multiple care-of addresses embedded in it. Another obvious way is 279 for the home agent to use some mechnisams to verify those care-of 280 addresses embedded in the binding update message. The foucs of such 281 verification soultions would be more towards ensuring that the 282 care-of addresses carried within the binding update message itself 283 are correct (and not the source address of the binding update 284 message). This draft assumes the ingress filtering would be deployed 285 in most networks, which allow the home agent to be sure that the 286 source address of the binding update message is correct. Such 287 assumption can be considered valid when we take in account that most 288 operators deploying the 4G cellular networks would likely run ingress 289 filtering within their networks as a security precaution to reduce 290 the chances of packet spoofing. 292 3.1. Restrict Multiple Care-of Addresses Registration in a Single 293 Binding Update Message 295 To prevent such flooding attack threat caused by allowing a mobile 296 node to bind fake care-of addresses at a home agent, it is possible 297 for the home agent to reject the use of a binding update message that 298 specify multiple care-of addresses. This type of logic is described 299 in [7] where a home agent would reject a binding update message if 300 the home agent detects that the source address of the binding update 301 message is different from the care-of address specified in the 302 binding update message. The home agent rejects the binding update 303 message as it is unsure if the care-of address actually belongs to 304 the mobile node. It could be that the mobile node is malicious and 305 spoof the care-of address to launch a flooding attack on a victim. 306 Thus, with such logic at the home agent, the threat of a mobile node 307 launching a flooding attack could be adverted. This is illustrated 308 in Figure 4. 310 +----+ 311 | HA | 312 +----+ 313 || 314 +=======+ +=======+ 315 / 3GPP \ / Non 3GPP\ 316 \ Network / \ Network / 317 +=======+ +=======+ 318 \ / 319 CoA1 \ / CoA2 320 +----+ 321 | MN | 322 +----+ 324 Figure 4: Scenario on policy at home agent 326 A mobile node (MN) attempts to bind a care-of address (CoA2) using 327 bulk registration via another care-of address (CoA1) at its home 328 agent (HA). When HA receives the binding update message from the 329 mobile node, it notices that the source address (CoA1) of the binding 330 update message is not the same as the care-of address (CoA2) 331 specified in the binding update message. HA is unsure if MN is 332 reachable at CoA2. Thus, HA rejects the binding of CoA2 as it fears 333 it might initiate a flooding attack to a victim. 335 However, by implementing such logic at a home agent, it really limits 336 the amount of optimization a person could achieve on the signaling 337 load between a mobile node and its home agent. For example, in [8], 338 it shows a savings in terms of signaling overheads when the mobile 339 node is able to use a single binding update message to register 340 multiple care-of addresses as opposed to sending them individually. 341 If the home agent restricts the mobile node from utilizing a single 342 binding update message to register multiple care-of addresses, this 343 implies that the mobile node has to send an individual binding update 344 message for each care-of address to the home agent. Hence, such 345 action removes the optimization benefit of performing the bulk 346 registration operation as described in [2]. 348 It is possible to employ such logic at a home agent to prevent the 349 flooding attack threat without losing all of the optimization benefit 350 of bulk registration. This would require the relaxation of the logic 351 at the home agent to reject the use of specifying multiple care-of 352 addresses in a single binding update message. Of course, such 353 relaxation cannot sacrifice the security requirement in preventing a 354 mobile node to launching a flooding attack. An example of such 355 relaxation could be a policy at the home agent that allows it to 356 identify if a particular care-of address is from another trusted 357 network (e.g. a trusted foreign 3GPP network). This type of trust 358 relationship could be found in 3GPP deployments where they establish 359 trust relationship for roaming purposes. Hence, when the home agent 360 identifies such care-of addresses, it would accept the care-of 361 address. Likewise, if the home agent understands that the care-of 362 address is not from a trusted foreign network, it might employ some 363 care-of address verification methods (e.g. ping the care-of address) 364 or even reject the registration of that care-of address. 366 Referring back to Figure 4, assuming that HA has establish a trust 367 relationship with non-3GPP network. When HA receives a binding 368 update from CoA1 specifying the registration of CoA2, HA would accept 369 CoA2. On the other hand, if HA does not have a trust relationship 370 with non-3GPP network, HA would inform MN of the rejection of CoA2. 371 This rejection would then force MN to send an individual binding 372 update message for CoA2. 374 Also, such knowledge of trusted networks could be made known to the 375 mobile node from the home agent. For example, MN could be pre- 376 configured with a list of trusted networks that it is connected to at 377 the moment. As and when MN roams, HA would update this list to allow 378 MN to know which access networks that it is currently connected to 379 are trusted. This action permits the mobile node to know which 380 care-of addresses could be used for bulk registration. 382 3.2. Using Cryptographically Generated Addresses 384 Another approach to prevent such flooding attack threat is to have 385 all care-of addresses to be formed using the cryptographically 386 generated addresses (CGA) technique [9]. With CGA in place, it 387 implies that a mobile node's care-of address would have to be 388 configured using its public key along with the subnet prefix. 389 Furthermore, this care-of address would need to be signed by the 390 mobile node's private key. With such system in place, the mobile 391 node would not be able to successful in binding a spoof care-of 392 address at a home agent. Even if the mobile node has successfully 393 obtain the public key of another mobile node, the mobile node would 394 not be able to get the private key of this same mobile node to sign 395 the care-of address. Without the proper signature, the home agent 396 would not accept the care-of address for the mobile node. Thus, this 397 prevents the mobile node from binding fake care-of addresses at the 398 home agent. 400 However, introducing cryptographically generated care-of addresses 401 increases the complexity of the mechanism to achieve multiple 402 bindings. It is unclear how a message can contain multiple CGA 403 signatures for each of the care-of addresses. Furthermore, 404 complexity is increased by the fact that additional addresses are not 405 found in the source address field but somewhere in the extension 406 header of the packet (i.e. mobility header). This requires 407 substantial integration between the CGA module and Mobility Support 408 module in a network stack implementation. Additionally, each CGA 409 Parameters structure which is at least 73 octets in length must be 410 added to the binding update message, further increasing its size. 411 Finally, the method of using CGA does not prevent the malicious 412 mobile node to launch a flooding attack against a subnet by 413 generating multiple non-existent care-of addresses in that subnet 414 using the mobile node's own public keys. 416 To reduce the overheads from carrying the CGA parameters data 417 structure for each care-of address that uses a CGA, it is possible to 418 use of the same hash modifier value and public key for each of the 419 care-of addresses in the binding update message. This allows the 420 receiving home agent to use the same modifier and public key to 421 verify that the mobile node (which sent the BU) is in fact the owner 422 of all the care-of addresses present in the binding update message. 423 Hence, it is possible for the home agent to just verify the 424 reachability of any one of the care-of addresses to be assured that 425 the mobile node is not faking the other care-of addresses and 426 redirecting traffic to other victims. However, there are some 427 privacy issues with using this method of generating multiple care-of 428 addresses with the same modifier since they are easily linkable. 429 Also, if there are a substantial number of nodes on one of the links 430 hosting one of the care-of addresses, the collision count may be 431 incremented and this mechanism will cease to work. 433 3.3. Using a Third Party Trusted Entity 435 Yet another approach to solve the flooding attack threat is to use a 436 trusted anchor to verify the care-of addresses of the mobile node. 437 For example, in [10], a mobile node is able to establish a symbiotic 438 relationship to an access router (which is a third party entity) in 439 order to permit the home agent to verify the care-of address of the 440 mobile node. The mobile node will tell its home agent of such 441 symbiotic relationship establishment by providing the IP address of 442 access router for the home agent to contact. This prompts the home 443 agent to contact the access router to verify the care-of address that 444 the mobile node claims to be using. This is illustrated in Figure 5. 446 +-----+ +-----+ +-----+ 447 | MN | | AR | | HA | 448 +-----+ +-----+ +-----+ 449 IF1:CoA1 | | IF2:CoA2 | | 450 | | | | 451 | |1. SR | | 452 | |<----------->| | 453 | 2. BU: CoA2, AR.Addr | 454 |---------------------------->| 455 | | | 3. BCR | 456 | | |<----------| 457 | | | 4. BC | 458 | | |---------->| 459 | 5. BA: CoA2 ok | 460 |<----------------------------| 461 | | | | 463 Figure 5: Message sequence diagram on using symbiotic relationship 465 A mobile node (MN) has two interfaces (IF1, IF2). On IF1, the MN is 466 using CoA1 for communication. Likewise, for IF2, the MN is using 467 CoA2 for communication. MN intends to use bulk registration via IF1 468 to register CoA2 at its home agent (HA). At first, MN establishes a 469 symbiotic relationship with an access router (AR) that IF2 is 470 associated with (step 1). Once the symbiotic relationship has been 471 setup, MN sends a binding update (BU) message from IF1 to register 472 CoA2 at HA (step 2). Also, in this BU message, MN tells HA regarding 473 the symbiotic relationship it has setup with AR (e.g. AR's IP 474 address). When HA receives this information, HA will send a Binding 475 Confirm Request (BCR) message to query the AR if MN is using CoA2 476 (step 3). If the AR identifies that MN is indeed using CoA2, AR will 477 reply back to HA with a Binding Confirm (BC) message (step 4). With 478 positive confirmation that MN is using CoA2, HA will response back to 479 MN indicating that the registration of CoA2 has been successful (step 480 5). Such message exchanges between the HA and the AR could be 481 secured via public keys methodology (PKI). 483 Typically, the verification of a mobile node's care-of addresses 484 usually involves only the mobile node and its home agent. However, 485 the use of a third party entity to verify care-of addresses for the 486 mobile node implies the need for an infrastructure support. The 487 purpose of using the third party entity is to offload the work of 488 verifying care-of addresses from the mobile node to the third party 489 entity. This act of testing the mobile node's reach-ability would 490 result in the reduction of signaling the mobile node has to perform 491 with its home agent. However, such shift of responsibility from the 492 mobile node to the access router means that workload for the access 493 router would increase. This is especially so if the access router 494 has a number of mobile nodes associated to it that requires such 495 validation services. This implies that the access router would have 496 to perform the message exchanges to the respective home agents on 497 behalf of all these mobile nodes. Such action might significantly 498 increase the signaling load of the access router and could be seen as 499 a tradeoff for the simplicity at the mobile node. 501 It is possible to minimize this tradeoff effect by reducing the 502 amount of signaling that an access router has to do for the mobile 503 nodes associated to it. For example, a certificate could be issued 504 to a mobile node by the foreign network that the mobile node is 505 currently connected to. This certificate would contain information 506 pertaining to the validity of the mobile node's care-of addresses 507 specified in the foreign network. When the mobile node notifies the 508 home agent regarding the symbiotic relationship established with the 509 foreign network, it would further send this certificate to the home 510 agent. If there is sufficient trust relationship between the home 511 agent and the foreign network, the home agent could use the 512 certificate as prove of the mobile node's care-of addresses. This 513 would help remove the need for the home agent to do message exchanges 514 with the foreign network, thus reducing the signaling load. On the 515 other hand, if the home agent does not feel that it has sufficient 516 trust relationship with the foreign network, it could perform the 517 message exchange sequence with the foreign network to test the reach- 518 ability of the mobile node's care-of addresses. This is illustrated 519 in Figure 6. 521 +-----+ +-----+ +-----+ 522 | MN | | AR | | HA | 523 +-----+ +-----+ +-----+ 524 IF1:CoA1 | | IF2:CoA2 | | 525 | | | | 526 | |1. Associate | | 527 | |<------------->| | 528 | | 2. Certificate| | 529 | |<--------------| | 530 | 3. BU: CoA2, Certificate | 531 |------------------------------>| 532 | 4. BA: CoA2 ok | 533 |<------------------------------| 534 | | | | 536 Figure 6: Message sequence diagram on using Certificate 538 A mobile node (MN) has two interfaces (IF1, IF2). On IF1, the MN is 539 using CoA1 for communication. MN associates with an access router 540 (AR) to obtain a care-of address (CoA2) for communication for IF2 541 (step 1). Also, AR forwards a certificate to MN to allow MN to use 542 it as proof to its home agent (HA) regarding the use CoA2 (step 2). 543 In this example, as per symbiotic relationship, we assume that AR and 544 HA has exchange the necessary PKI parameters (e.g. public keys). 545 Hence, the certificate would contain CoA2 along with a timestamp 546 signed using AR's private key. The purpose of the timestamp is to 547 prevent MN from performing a replay attack to HA by claiming to own 548 the same CoA2 at a later time. When MN decides to use bulk 549 registration to bind CoA2 at HA, MN sends a binding update (BU) 550 message from IF1 along with the token to register CoA2 at HA (step 551 3). At HA, it authenticates that the certificate is indeed from AR 552 and thus, reply to MN that the binding for CoA2 has been accepted 553 (step 4). Hence, compared to Figure 5, the certificate allows the HA 554 to skip the message exchange sequence with the AR. 556 3.4. Using Message Exchanges with a Mobile Node 558 Alternatively, the flooding attack threat may be tackled using a 559 series of message exchanges between a mobile node and its home agent 560 to verify the reach-ability of the mobile node's care-of addresses. 561 For example, the home agent send some encrypted information to the 562 mobile node to verify the reach-ability for that care-of address. If 563 the home agent is able to received the decrypted version of the 564 information from the mobile node, it would prove to the home agent 565 that the mobile node is using that particular care-of address. This 566 technique is described in [11] where the use of a cookie proves to 567 the home agent that the mobile node is addressable at the specified 568 care-of address. However, the optimization benefit of sending 569 multiple care-of address within a single binding update is greatly 570 reduced as it would require the mobile node to respond via all these 571 care-of addresses. In this case, the mobile node might as well send 572 the binding update message individually for each care-of address. 574 To optimize the inefficiency of using [11] for multiple care-of 575 addresses case, it is possible for the home agent to send a 576 notification to a mobile node via one unverified care-of address and 577 ask the mobile node to respond to the reception of the notification 578 via another care-of address. This utilizes the concept of multiple 579 care-of addresses whereby the mobile node need not respond back using 580 the same path as the reception of the request. Such a concept is 581 particularly useful in the event that the mobile node has several 582 unverified care-of addresses that needs to be tested. By asking the 583 mobile node to respond via another unverified care-of address, in one 584 round trip time, the home agent would be able to verify two care-of 585 addresses. Figure 7 illustrates this. 587 +-----+ 588 | | 589 CoA1 ______| I | 590 / | N | 591 Cellular/ | T | 592 +----+ CoA2 | E | +----+ 593 | MN |------| R |----| HA | 594 +----+ GPRS | N | +----+ 595 WLAN\ | E | 596 \_______| T | 597 CoA3 | | 598 +-----+ 600 Figure 7: Operation of Home Agent 602 In Figure 7, the mobile node MN has three interfaces. A first 603 interface associates with the cellular system and uses a care-of 604 address CoA1 for communication. A second interface connects to the 605 General Packet Radio System (GPRS) and uses a care-of address CoA2 606 for communication. A third interface associates with the 802.11 607 Wireless Local Area Network (WLAN) and uses a care-of address CoA3 608 for communication. MN sends a binding update message from CoA1 that 609 is attempting to register all its care-of addresses at its home 610 agent, HA. Thus, when HA receives the binding update message, it 611 binds CoA1 in its binding cache as a valid routing path to MN as it 612 has proven to HA that MN is using that care-of address. However, for 613 CoA2 and CoA3, HA would need to verify their addressability before 614 using them for packet routing. Hence, HA uses the notification to 615 verify both of these care-of addresses. Comparing this to the fact 616 of using two messages per care-of address, it can be seen that there 617 is at least a 50% savings for the number of messages exchanged. For 618 example, if HA needs to verify two care-of addresses using the 619 traditional method, a total of four messages would be required. On 620 the other hand, if HA would to test the care-of addresses in pairs, 621 then a total of only two messages would be required. 623 It is possible for the home agent to choose when to perform such 624 verification process for the mobile node's bindings. One way is to 625 have the home agent trigger the verification process immediately upon 626 the reception of binding update message registering multiple care-of 627 address from a mobile node. This is mostly helpful when it comes to 628 supporting the concept of registering multiple care-of addresses. 629 The purpose of having multiple care-of addresses is to allow the home 630 agent to route packets to the mobile node via any of the multiple 631 paths. Having the home agent perform the verification process 632 immediately permits the home agent to quickly utilize all of the 633 mobile node's care-of addresses for packet routing. For example, 634 when the home agent receives the binding update message on CoA1 that 635 specifies the binding of both CoA2 and CoA3, the home agent can 636 choose to immediately verify these care-of addresses in order to 637 start using them for packet routing to the mobile node. Another way 638 could be that the home agent triggers the verification process just 639 before it needs to use an unverified routing path to the mobile node. 640 This is especially so in the event that the mobile node sets a filter 641 rule at the home agent specifying the routing of certain packets via 642 the unverified routing path. When the home agent receives packets 643 that match the filter rule condition, the home agent would trigger 644 the verification process for the unverified path prior to using it. 645 An example would be that the mobile node specify in a filter rule at 646 the home agent that data packets would be routed via CoA3. When the 647 home agent receives such a packet, it notes that CoA3 has yet been 648 verified. Thus, the home agent performs the verification process to 649 verify CoA3. 651 Also, the transmission path of the notification packet from the home 652 agent can vary based on how strict the security policy is enforced. 653 Strict security policy can forbid the home agent in using an 654 unverified care-of address for any packet routing. In this sense, 655 the home agent can only send the notification to the mobile node via 656 a verified care-of address. Such policies are beneficial in 657 deterring any such flooding attacks being launch from the mobile 658 node. For example, since CoA1 is the only verified care-of address 659 to the mobile node, the home agent would send a message via CoA1 to 660 notify the mobile node to respond back via CoA2. This action will 661 cause the mobile node to understand that the home agent is trying to 662 verify CoA2. Hence, the mobile node would send a packet to the home 663 agent via CoA2, thereby proving to the home agent that it is 664 addressable at CoA2. 666 On the other hand, if the home agent employs techniques such as 667 credit-based authorization (CBA) [12], it permits the home agent to 668 route packets to the mobile node via an unverified care-of address. 669 These packets would be limited to the amount of credits associated to 670 that particular binding. The advantage of using an unverified path 671 to transmit the notification is that it allows the home agent to 672 verify at best two unverified care-of addresses. This is especially 673 useful in the event that the mobile node has several unverified 674 care-of addresses that needs to be tested. An example would be that 675 the home agent sends a message via CoA2 to notify the mobile node to 676 respond back via CoA3. This action allows the mobile node to 677 understand that the home agent is trying to verify both CoA2 and 678 CoA3. Hence, the mobile node would send a packet to the home agent 679 via CoA3, thereby proving to the home agent that it is addressable at 680 both CoA2 and CoA3. 682 Furthermore, it is possible that the home agent does not specify a 683 return unverified care-of address when it notifies the mobile node. 684 This would allow the mobile node to respond back to the home agent 685 via any of the mobile node's care-of address. By permitting the 686 mobile node to choose the respond path to the home agent, it supports 687 the situation where the uplink path maybe resource constraint (e.g. 688 limited uplink bandwidth). In the first place, this could be the 689 reason why the mobile node decides to send a single binding update 690 message to bind its multiple care-of address from a path that does 691 not limit its resources. For example, the home agent wants to verify 692 that CoA2 is addressable to the mobile node. Thus, the home agent 693 notifies the mobile node via CoA2 to verify this care-of address. 694 Since GPRS has limited uplink bandwidth, the mobile node decides to 695 send the respond via the cellular path (CoA1). Hence, upon receiving 696 the respond from the mobile node, the home agent is able to verify 697 that the mobile node is addressable at CoA2. 699 Finally, how the notification information is carried to the mobile 700 node may differ at the home agent. One possible way is that such 701 notification is carried using a dedicated message format. This makes 702 the notification packet small in size and easily recognized by the 703 mobile node. On the other hand, since the notification is specifying 704 just a care-of address that the mobile node should respond back by, 705 an optimization to this would be to have the notification to be 706 tagged to packets that are being sent to the mobile node. One 707 example could be the binding acknowledgment message that the home 708 agent replies to the mobile node. Another example could be data 709 packets that are addressed to the mobile node. By tagging it to 710 existing packets, the home agent saves on the overhead incurred from 711 the transmission the notification packet to the mobile node. 713 4. Conclusion 715 This draft explains that the use of multiple care-of address 716 registration breaks the trust relationship between a home agent and a 717 mobile node. With this relationship broken, it permits a malicious 718 mobile node to bind multiple victims' care-of addresses at the home 719 agent. With these bindings, the mobile node can launch attacks by 720 flooding the victims with useless packets. To reduce the chances of 721 having such a situation, we briefly analyse a few possible solutions 722 approaches that would be able to solve the problem. The draft list 723 each approach with their own advantages and dis-advantages to allow 724 an implementer to decide upon which approach would be best suited for 725 their deployment. Also, the draft attempts to provide some 726 recommendations to reduce the dis-advantages for each approach. 728 5. Acknowledgements 730 The authors would like to thank George Tsirtsis for suggestions to 731 improve upon this document. 733 6. Security Considerations 735 This draft mentions new security requirements when implementing 736 Multiple Care-of Address Registration [2]. 738 7. IANA Considerations 740 This document does not require any action from the IANA. 742 8. References 744 8.1. Normative References 746 [1] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in 747 IPv6", RFC 3775, June 2004. 749 [2] Wakikawa, R., "Multiple Care-of Addresses Registration", 750 draft-ietf-monami6-multiplecoa-05 (work in progress), 751 January 2008. 753 8.2. Informative References 755 [3] Montavont, N., "Analysis of Multihoming in Mobile IPv6", 756 draft-ietf-monami6-mipv6-analysis-04 (work in progress), 757 July 2007. 759 [4] Soliman, H., "Flow Bindings in Mobile IPv6 and Nemo Basic 760 Support", draft-soliman-monami6-flow-binding-04 (work in 761 progress), March 2007. 763 [5] Larsson, C., "A Filter Rule Mechanism for Multi-access Mobile 764 IPv6", draft-larsson-monami6-filter-rules-02 (work in 765 progress), March 2007. 767 [6] Mitsuya, K., "A Policy Data Set for Flow Distribution", 768 draft-mitsuya-monami6-flow-distribution-policy-04 (work in 769 progress), August 2007. 771 [7] Arkko, J., "Verifying Correctness of Alternate Care-of Address 772 Option", draft-arkko-mext-rfc3775-altcoa-check-01 (work in 773 progress), February 2008. 775 [8] Kuparinen, M., Mahkonen, H., and T. Kauppinen, "Multiple CoA 776 Performance Analysis", 777 draft-kuparinen-monami6-mcoa-performance-00 (work in progress), 778 April 2006. 780 [9] Aura, T., "Cryptographically Generated Addresses (CGA)", 781 RFC 3972, March 2005. 783 [10] Haddad, W., "Care-of Address Test for MIPv6 using a State 784 Cookie", draft-haddad-mext-enhanced-reachability-test-00 (work 785 in progress), February 2008. 787 [11] Dupont, F. and J. Combes, "Care-of Address Test for MIPv6 using 788 a State Cookie", draft-dupont-mipv6-rrcookie-04 (work in 789 progress), January 2007. 791 [12] Arkko, J., Vogt, C., and W. Haddad, "Enhanced Route 792 Optimization for Mobile IPv6", RFC 4866, May 2007. 794 Appendix A. Change Log 796 o draft-lim-mext-multiple-coa-verify-02: 798 * Revamp the analysis section Section 3 to highlight the 799 advantages and dis-advantages for each solution approach. 800 Also, recommendations are given to try and reduce dis- 801 advantages of each approach. 803 o draft-lim-mext-multiple-coa-verify-01: 805 * Reference lastest MCoA draft that specify the problem. 807 * Added two more soultions (limiting care-of address binding at 808 HA and CoA test using 'symbiotic' relationship) for analysis in 809 Section 3. 811 o draft-lim-mext-multiple-coa-verify-00: 813 * Initial version. 815 Authors' Addresses 817 Benjamin Lim 818 Panasonic Singapore Laboratories Pte Ltd 819 Block 1022 Tai Seng Ave #06-3530 820 Tai Seng Industrial Estate 821 Singapore 534415 822 SG 824 Phone: +65 65505478 825 Email: benjamin.limck@sg.panasonic.com 827 Chan-Wah Ng 828 Panasonic Singapore Laboratories Pte Ltd 829 Blk 1022 Tai Seng Ave #06-3530 830 Tai Seng Industrial Estate 831 Singapore 534415 832 SG 834 Phone: +65 65505420 835 Email: chanwah.ng@sg.panasonic.com 837 Keigo Aso 838 Matsushita Electric Industrial Co. Ltd. (Panasonic) 839 5-3 Hikarino-oka 840 Yokosuka, Kanagawa 239-0847 841 JP 843 Phone: +81 46 840 5123 844 Email: asou.keigo@jp.panasonic.com 845 Suresh Krishnan 846 Ericsson 847 8400 Decarie Blvd. 848 Town of Mount Royal, QC 849 Canada 851 Phone: +1 514 345 7900 x42871 852 Email: suresh.krishnan@ericsson.com 854 Full Copyright Statement 856 Copyright (C) The IETF Trust (2008). 858 This document is subject to the rights, licenses and restrictions 859 contained in BCP 78, and except as set forth therein, the authors 860 retain all their rights. 862 This document and the information contained herein are provided on an 863 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 864 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 865 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 866 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 867 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 868 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 870 Intellectual Property 872 The IETF takes no position regarding the validity or scope of any 873 Intellectual Property Rights or other rights that might be claimed to 874 pertain to the implementation or use of the technology described in 875 this document or the extent to which any license under such rights 876 might or might not be available; nor does it represent that it has 877 made any independent effort to identify any such rights. Information 878 on the procedures with respect to rights in RFC documents can be 879 found in BCP 78 and BCP 79. 881 Copies of IPR disclosures made to the IETF Secretariat and any 882 assurances of licenses to be made available, or the result of an 883 attempt made to obtain a general license or permission for the use of 884 such proprietary rights by implementers or users of this 885 specification can be obtained from the IETF on-line IPR repository at 886 http://www.ietf.org/ipr. 888 The IETF invites any interested party to bring to its attention any 889 copyrights, patents or patent applications, or other proprietary 890 rights that may cover technology that may be required to implement 891 this standard. Please address the information to the IETF at 892 ietf-ipr@ietf.org.