idnits 2.17.00 (12 Aug 2021) /tmp/idnits3621/draft-irtf-mobopts-mip6-cnlocpriv-00.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 14. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 629. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 640. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 647. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 653. 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 an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- 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 (October 11, 2007) is 5336 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 3775 (ref. '2') (Obsoleted by RFC 6275) == Outdated reference: draft-ietf-mip6-bootstrapping-split has been published as RFC 5026 -- Obsolete informational reference (is this intentional?): RFC 3484 (ref. '4') (Obsoleted by RFC 6724) == Outdated reference: draft-ietf-mip6-bootstrapping-integrated-dhc has been published as RFC 6611 == Outdated reference: draft-ietf-mip6-hiopt has been published as RFC 6610 == Outdated reference: draft-irtf-mobopts-location-privacy-solutions has been published as RFC 5726 Summary: 3 errors (**), 0 flaws (~~), 7 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group K. Weniger 3 Internet-Draft Panasonic 4 Expires: April 13, 2008 October 11, 2007 6 MIPv6 Correspondent Node-Targeted Location Privacy and Optimized Routing 7 draft-irtf-mobopts-mip6-cnlocpriv-00 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on April 13, 2008. 34 Copyright Notice 36 Copyright (C) The IETF Trust (2007). 38 Abstract 40 Mobile IPv6 does not allow a mobile node to hide its location from a 41 correspondent node without compromising optimized routing. Hence, a 42 mobile node has the choice: it can either get location privacy 43 support or short packet delay, but not both at the same time. This 44 document discusses the problem of achieving both simultaneously and 45 specifies a solution. The solution utilizes the Mobile IPv6 46 bootstrapping mechanisms and does neither introduce new network 47 entities nor changes to home agent or correspondent node 48 implementations. 50 Table of Contents 52 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Introduction and Problem Definition . . . . . . . . . . . . . 4 54 3. Applicability Statement . . . . . . . . . . . . . . . . . . . 6 55 4. Related work . . . . . . . . . . . . . . . . . . . . . . . . . 7 56 5. Changes to Mobile Node Operation . . . . . . . . . . . . . . . 8 57 5.1. Route Optimization for New Sessions . . . . . . . . . . . 8 58 5.2. Route Optimization for Ongoing Sessions . . . . . . . . . 9 59 5.3. Route Optimization Mode Selection . . . . . . . . . . . . 11 60 5.4. Source Address Selection . . . . . . . . . . . . . . . . . 11 61 6. Location-dependent Home Agent Discovery . . . . . . . . . . . 12 62 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 63 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 64 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 65 9.1. Normative References . . . . . . . . . . . . . . . . . . . 16 66 9.2. Informative References . . . . . . . . . . . . . . . . . . 16 67 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17 68 Intellectual Property and Copyright Statements . . . . . . . . . . 18 70 1. Terminology 72 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 73 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 74 document are to be interpreted as described in [1]. 76 General mobility terminology can be found in [5]. Terminology 77 specific to Mobile IPv6 and Mobile IPv6 bootstrapping can be found in 78 [2] and [6]. Additionally, the following terms are introduced: 80 Correspondent node-targeted location privacy: Hiding the mobile 81 node's location from the correspondent node 83 Eavesdropper-targeted location privacy: Hiding the mobile node's 84 location from nodes eavesdropping on the path between mobile node 85 and correspondent node 87 IP Reachability Home Agent (IRHA): A Mobile IPv6 home agent as 88 specified in [2] that provides IP reachability and global session 89 continuity for the mobile node. 91 Home Address for IP Reachability (HoA_IR): A Mobile IPv6 home 92 address used for IP reachability and session continuity and that 93 is anchored at the IRHA. This home address is independent of the 94 location of the mobile node and is disclosed to potential 95 correspondent nodes (e.g., by publishing the address in DNS). 97 Optimized path: A path between mobile node and correspondent node 98 that is shorter than the path between mobile node and 99 correspondent node when the mobile node uses bi-directional 100 tunneling mode to the IRHA. Note that the optimized path may be 101 longer than the path between mobile node and correspondent node 102 when the mobile node uses route optimization mode. 104 Optimized routing: Routing data packets over the optimized path 106 Optimized Routing Home Agent (ORHA): A Mobile IPv6 home agent as 107 specified in [2] that is used for providing optimized routing and 108 correspondent node-targeted location privacy. It must support the 109 bootstrapping mechanisms specified in [3] and should be located 110 close to the correspondent node. 112 Home Address for Optimized Routing (HoA_OR): A Mobile IPv6 home 113 address used for optimized routing and session continuity that is 114 anchored at the ORHA. This home address is typically not public 115 (i.e., not published in DNS). 117 2. Introduction and Problem Definition 119 Location privacy is the ability to hide a user's location from other 120 users. This is considered to be an important feature, since 121 disclosure of the location can have serious impacts on the user's 122 life. In general, location privacy can be achieved by hiding the 123 relation between identity and location of a user. In Mobile IPv6 124 [2], the care-of address and the home address typically represent 125 topological location and identity of a mobile node, respectively. 126 Even though a dynamically assigned home address may not represent a 127 permanent identity itself, a mapping to a mobile node's permanent 128 identifiers is typically published for IP reachability reasons (e.g., 129 in DNS). Consequently, in Mobile IPv6 at least either the care-of 130 address or the home address must be hidden from anyone that is not 131 authorized to obtain the location of the mobile node. Two rather 132 orthogonal sub-problems of location privacy for Mobile IPv6 can be 133 identified: hiding the location from eavesdroppers on the path and 134 hiding the location from the correspondent node [7], which we 135 henceforth call eavesdropper-targeted and correspondent node-targeted 136 location privacy, respectively. This document is concerned with 137 correspondent node-targeted location privacy only, especially with 138 the problem of providing optimized routing at the same time. 139 Eavesdropper-targeted location privacy is out of scope of this 140 document. However, it is expected that the mechanisms defined in 141 this document can be combined with solutions for eavesdropper- 142 targeted location privacy such as the pseudo home address mechanisms 143 specified in [11]. Any location privacy issues not related to Mobile 144 IPv6 are out of the scope of this document. 146 An example scenario illustrating the problem addressed by this 147 document is the following: A mobile node wants to hide its location 148 from correspondent nodes and uses Mobile IPv6 with a public home 149 address to be reachable. The public home address is anchored at a 150 home agent, which we henceforth call IRHA. The mobile node requires 151 strong location privacy, i.e., hiding only the mobility within an 152 access network and revealing the access network prefix to the 153 correspondent node is not acceptable. An application on the 154 correspondent node initiates a delay-sensitive session with the 155 mobile node such as a VoIP call by sending packets to the mobile 156 node's public home address (HoA_IR). This requires that the 157 correspondent node has obtained the mobile node's home address 158 beforehand, e.g., from DNS. The mobile node receives the packets in 159 bi-directional tunneling mode from its home agent (IRHA) and then may 160 decide to switch to route optimization mode for the session. Let's 161 assume the mobile node is located in the United States and the 162 correspondent node is located in Canada, whereas the mobile node's 163 home agent is located in Europe. Since the mobile node is far away 164 from home, the packet delay and hence the user experience is far from 165 what could be achieved. However, if the mobile node uses route 166 optimization mode, it reveals its CoA and hence its location to the 167 correspondent node (note that the correspondent node can also be an 168 attacker that just initiates a session to find out the mobile node's 169 location). Consequently, the mobile node has the choice: it can 170 either have good VoIP call quality without location privacy or 171 location privacy with bad VoIP call quality. Currently, there is no 172 way to achieve both simultaneously with Mobile IPv6. 174 This document proposes a mechanism that can provide both 175 simultaneously, i.e., strong correspondent node-targeted location 176 privacy and optimized routing. Home agents and correspondent node 177 are unchanged and no new entities or messages are introduced. The 178 basic idea is that the mobile node bootstraps with a home agent 179 located topologically close to the correspondent node and which is 180 used for optimized communication with this correspondent node. Such 181 home agent is henceforth called ORHA. A home agent location close to 182 the correspondent node ensures that the route in bi-directional 183 tunneling mode is short and that no location information is contained 184 in the home address, as opposed to a home address anchored at a local 185 home agent. For mobile node-initiated sessions, the mobile node uses 186 the ORHA in bi-directional tunneling mode and HoA_OR on higher 187 layers. For correspondent node-initiated sessions, the public home 188 address HoA_IR is used on higher layers and the mobile node registers 189 the HoA_OR as care-of address at the correspondent node. 191 3. Applicability Statement 193 The solution described in this document relies on the assignment or 194 discovery of an home agent in the vicinity of the correspondent node 195 or at an appropriate location that is uncorrelated with the location 196 of the point of attachment of the mobile node. In deployment 197 scenarios where such a home agent does not exist or if the 198 establishment of security associations with such home agent is not 199 feasible (e.g., because the mobile node's Mobility Service Authorizer 200 does not have any relationship with the provider Mobility Service 201 Provider of the home agent), this solution is not applicable. 202 Furthermore, the mechanisms defined in this document should only be 203 used in scenarios where the number of concurrent sessions that a 204 mobile node runs and that require simultaneous optimized routing and 205 correspondent node-targeted location privacy is low. 207 The application of the HA discovery mechanisms as specified in the 208 MIP6 bootstrapping documents [3] [8] to ORHA discovery may pose 209 special requirements on deployment. If the DNS-based HA discovery 210 scheme shall be used for ORHA discovery, MSAs or MSPs should maintain 211 DNS entries that allow the MN to discover a home agent at a specific 212 location or in a specific domain. There are different ways to 213 achieve that. For instance, the mobile node's MSA may maintain DNS 214 entries per CN domain according to the scheme 215 "_mip6._ipv6.CNdomain.MSAdomain.com" and the mobile node may be 216 configured to construct the FQDN for ORHA discovery by appending the 217 string "_mip6._ipv6.", CN's domain name, and MSA's domain name. If 218 the DHCP-based HA discovery scheme [9] shall be used for ORHA 219 discovery, the mobile node should be able to request a home agent 220 using DHCP once a session with a new CN begins, i.e., potentially 221 long after completion of the network authentication. Therefore, the 222 ASP should support either storing the HA information received from 223 the mobile node's MSA for as long as the mobile node is attached to 224 the ASP or requesting HA information from the MSA for a specific 225 target domain during the mobile node session (see section 4.2 of 226 [9]). 228 4. Related work 230 Qui et. al. [11] propose a solution to the correspondent node- 231 targeted location privacy problem. The basic idea is to hide the 232 home address from the correspondent node in route optimization mode 233 by using a pseudo home address instead of the real home address. 234 Although the care-of address is revealed to the correspondent node, 235 location privacy is protected by hiding the identity (i.e., real home 236 address) of the mobile node from the correspondent node. This 237 approach has also been proposed in [10]. However, if the 238 correspondent node initiates the communication location privacy is 239 compromised, since the public home address and hence the identity of 240 the mobile node is typically already known by the correspondent node. 241 And even if the real home address can be hidden from the 242 correspondent node, location privacy is compromised if the 243 correspondent node is able to figure out the mobile node's identity 244 by any other means (e.g., during the conversation of a voice call or 245 by higher layer identifiers). 247 [3] and [8] specify the mechanisms for Mobile IPv6 bootstrapping in 248 the split and the integrated scenario, respectively. They allow a 249 mobile node to bootstrap with any home agent, for which the necessary 250 trust relationships are in place. When bootstrapping with a local 251 home agent, optimized routing can be achieved in bi-directional 252 tunneling mode by using the home address pertaining to the local home 253 agent for the session with the correspondent node. However, since 254 the home address obtained from a local home agent belongs to the 255 network the mobile node is currently visiting, it contains location 256 information. Consequently, location privacy is compromised, if the 257 correspondent node knows that the home agent is local to the mobile 258 node (see security considerations of [3]). Although in many cases 259 the correspondent node will not know, there are cases where the 260 correspondent node can find out whether the mobile node's home agent 261 is local or remote. For instance, a correspondent node may know that 262 a mobile node's home agent is local because the mobile node's 263 Mobility Service Provider (MSP) is known to always assign local home 264 agents for routing efficiency reasons. 266 5. Changes to Mobile Node Operation 268 This section describes a mechanism that allows a Mobile IPv6 mobile 269 node to achieve both correspondent node-targeted location privacy and 270 optimized routing simultaneously. The mobile node operation is split 271 in two cases: route optimization for new sessions (i.e., 272 communication sessions that have not yet started) and route 273 optimization for ongoing sessions. The first case applies, e.g., if 274 the mobile nodes wants to initiate a session with a correspondent 275 node and decides to optimized the route before sending the first data 276 packets. The second case applies, e.g., if the correspondent node 277 initiates a session with the mobile node or if the mobile node 278 decides to optimize the route of an ongoing session. A session is 279 defined by an application or transport layer context bound to the IP 280 addresses of the two endpoints, with one of the addresses being the 281 mobile node's home address to achieve session continuity. 283 5.1. Route Optimization for New Sessions 285 The mobile node first tries to discover an ORHA as described in 286 Section 6. If the discovery is successful, the mobile node 287 bootstraps with the ORHA, obtains a home address HoA_OR, and uses the 288 ORHA in bi-directional tunneling mode for communication with the 289 correspondent node. Existing registrations with other home agents 290 can be kept for communication with other correspondent nodes. Since 291 the mobile node can continue to use the public home address HoA_IR 292 for IP reachability, the HoA_OR does not need to be published, i.e., 293 no DNS update needs to be triggered for this home address. An 294 exemplary signaling flow is shown in Figure 1. 296 +--+ +-------+ +--+ 297 |MN| | ORHA | |CN| 298 +--+ +-------+ +--+ 299 | | 300 | | | 301 | MIPv6 bootstrapping | | 302 |<----------------------------------------->| | 303 | BU/BA (HoA_OR,CoA) | | 304 |<----------------------------------------->| | 305 | MIPv6 tunnel (ORHA) | data packets | 306 |===========================================|<------------------->| 308 Figure 1: Signaling flow for optimizing the route for a session that 309 has not yet started 311 Since HoA_OR is independent of the mobile node's location and since 312 HoA_OR is the only address that is revealed to the correspondent 313 node, strong correspondent node-targeted location privacy is ensured. 315 5.2. Route Optimization for Ongoing Sessions 317 After the mobile node has decided to optimize the route of a session 318 (e.g., after receiving the first data packets from the correspondent 319 node tunneled through the IRHA), the mobile node tries to discover an 320 ORHA as described in Section 6. If this is successful, it bootstraps 321 with this ORHA and obtains HoA_OR. Since the ongoing communication 322 session is bound to HoA_IR, packets sent by the correspondent node 323 are still routed through the IRHA. To optimize the route without 324 compromising location privacy, the mobile node moves the session to 325 the ORHA. Therefore, the mobile node switches to route optimization 326 mode and sends care-of test messages, binding update messages, and 327 later data packets destined for the correspondent node over the 328 reverse tunnel to the ORHA. The mobile node uses HoA_IR as home 329 address and HoA_OR as care-of address in the context of this route 330 optimization mode, i.e., headers of care-of test messages, binding 331 update messages, and data packets are as follows (IPsec for signaling 332 protection to ORHA assumed): 334 Care-of Test Init: 336 IPv6 header (source = care-of address, 337 destination = ORHA) 338 ESP header in tunnel mode 339 IPv6 header (source = HoA_OR, 340 destination = correspondent node address) 341 Any protocol 343 Data packets and binding updates: 345 IPv6 header (source = care-of address, 346 destination = ORHA) 347 ESP header in tunnel mode 348 IPv6 header (source = HoA_OR, 349 destination = correspondent node address) 350 Destination Options header 351 Home Address option (HoA_IR) 352 Any protocol 354 Since HoA_OR is the mobile node's care-of address and the HoA_IR is 355 the mobile node's home address from the correspondent node's point of 356 view, data packets sent by the correspondent node contain the HoA_IR 357 in the routing header and the HoA_OR in the destination address field 358 of the IP header. Consequently, data packets sent by the 359 correspondent node are routed to the ORHA and tunneled to the mobile 360 node. An exemplary signaling flow is shown in Figure 2. 362 +--+ +-------+ +-------+ +--+ 363 |MN| | IRHA | | ORHA | |CN| 364 +--+ +-------+ +-------+ +--+ 365 | BU/BA (HoA_IR,CoA) | | | 366 |<------------------->| | | 367 ~ ~ ~ ~ 368 | MIPv6 tunnel (IRHA) | data packets | 369 |=====================|<----------------------------------------->| 370 | | | | 371 | | | 372 | | | | 373 | MIPv6 bootstrapping | | 374 |<----------------------------------------->| | 375 | BU/BA (HoA_OR,CoA) | | 376 |<----------------------------------------->| | 377 | MIPv6 tunnel (IRHA) | HoTi | 378 |=====================|------------------------------------------>| 379 | MIPv6 tunnel (ORHA) | CoTi | 380 |===========================================|-------------------->| 381 | MIPv6 tunnel (IRHA) | HoT | 382 |=====================|<------------------------------------------| 383 | MIPv6 tunnel (ORHA) | CoT | 384 |===========================================|<--------------------| 385 | MIPv6 tunnel (ORHA) |BU/BA (HoA_IR,HoA_OR)| 386 |===========================================|<------------------->| 387 | MIPv6 tunnel (ORHA) | data packets | 388 |===========================================|<------------------->| 390 Figure 2: Signaling flow for optimization of the route for an ongoing 391 session 393 Location privacy is provided, since the correspondent node only 394 learns HoA_OR and HoA_IR, which both do not contain any information 395 about the mobile node's location. Optimized routing is provided as 396 well, since all data packets exchanged between mobile node and 397 correspondent node are routed over the ORHA, which is located close 398 to the correspondent node. 400 Note that upon changing the care-of address, the mobile node does not 401 need to send a binding update message to the correspondent node over 402 the reverse tunnel to the ORHA, because the mobile node's care-of 403 address in this context is the HoA_OR. 405 5.3. Route Optimization Mode Selection 407 The mobile node has to decide for every correspondent node, whether 408 it wants to use bi-directional tunneling mode, route optimization 409 mode or the mechanisms described in this document. How this decision 410 is made and when route optimization according to this document is 411 triggered is implementation specific and hence out of scope of this 412 document. Generally, bi-directional tunneling to the home agent 413 achieves strong correspondent node-targeted location privacy and is 414 sufficient for non-delay-sensitive services such as simple web 415 browsing. If no location privacy is required, Mobile IPv6 route 416 optimization mode can be used. 418 Since the number of simultaneous registrations at different home 419 agents has impacts on the overall signaling overhead and resource 420 consumption on the mobile node, the mobile node should try to 421 minimize the number of simultaneously used ORHAs and only apply the 422 mechanisms specified in this document for sessions that really 423 require simultaneous optimized routing and correspondent node- 424 targeted location privacy. 426 5.4. Source Address Selection 428 The mobile node may use different home addresses for communication 429 with different correspondent nodes when using the route optimization 430 mechanisms defined in this document. Hence, the mobile node must be 431 able to select the right home address as source address for packets 432 to be sent to a specific destination address. This can be achieved 433 with the source address selection mechanisms defined in [4]. If the 434 ORHA is located in the correspondent node's domain, the prefix of the 435 home address anchored at the ORHA is similar to the prefix of the 436 correspondent node and rule 9 (Use longest matching prefix) of the 437 default source address selection [4] applies. For other cases, 438 dynamically adding entries for HoA_OR and correspondent node address 439 with matching labels in the policy table [4] when route optimization 440 according to this document is triggered would prefer a home address 441 as source address for communication with a specific correspondent 442 node. However, since this is implementation specific, the details of 443 the source address selection are out of the scope of this document. 445 6. Location-dependent Home Agent Discovery 447 The mechanisms defined in Section 5.1 and Section 5.2 require the 448 discovery or assignment of a home agent (ORHA) located close to a 449 correspondent node. One option to achieve that is to pre-configure a 450 list of home agent FQDNs and distances to various prefixes on the 451 mobile node. However, since the list of available home agents and 452 the distances may change, a dynamic discovery of ORHAs is preferable. 453 There are various ways for achieving this, some of them are described 454 in the following. 456 One option is to re-use the DNS-based home agent discovery specified 457 in [3]. The mobile node would construct the FQDN based on the 458 correspondent node's address, prefix or host name. Some operator 459 (e.g., MSA, ASP or MSP) should maintain DNS entries that allow the MN 460 to discover a home agent at a specific location or in a specific 461 domain. For instance, the mobile node's MSA may maintain DNS entries 462 per CN domain according to the scheme 463 "_mip6._ipv6.CNdomain.MSAdomain.com" and the mobile node may be 464 configured to construct the FQDN for ORHA discovery by appending the 465 string "_mip6._ipv6.", CN's domain name, and MSA's domain name. 467 Another option is to re-using DHCP-based HA assignment as defined in 468 [8] and [9]. For instance, the MSA would send the home agent 469 information for all the MSPs which the mobile node is authorized to 470 use to the Network Access Server (NAS) during network authentication. 471 Once the mobile node intends to initiate route optimization according 472 to this document, it sends a DHCP Information Request and appends a 473 Home Network Identifier Option [9] containing the correspondent 474 node's domain as target domain. The id-type can be set to 2 or to a 475 new value specifically defined for ORHA discovery. The NAS would 476 then select a home agent from the set of authorized home agents that 477 is close to the target domain. How this selection is done is out of 478 scope of this document. Finally, the NAS would assign the selected 479 home agent to the mobile node in the Home Network Information Option 480 of the DHCP reply message. 482 Anycast-based home agent discovery using IKEv2 [12] or DHAAD [2] is 483 another possible solution. The mobile node would construct the 484 anycast destination address based on the correspondent node's prefix. 485 A drawback of this method is that it cannot discover ORHAs located 486 close to, but outside the correspondent node's network. 488 Finally, the mobile node could query a dedicated server using some 489 application-layer protocol like http. The server would maintain the 490 list of ORHAs and would reply with the name of an ORHA upon receiving 491 a request with a correspondent node's prefix. This server can, e.g., 492 be provided by the MSA or a third party in the public Internet. 494 7. Security Considerations 496 The solution specified in this document ensures that a correspondent 497 node at most learns the home addresses HoA_OR and HoA_IR of the 498 mobile node. HoA_IR is used for IP reachability and is independent 499 of the mobile node's movement. Hence, it doesn't contain any 500 information about the mobile node's current location. HoA_OR is 501 anchored at a home agent located close to the correspondent node and 502 thus there is no relation between HoA_OR and the mobile node's 503 current location. Consequently, the correspondent node has no way to 504 infer the mobile node's location or movement, i.e., correspondent 505 node-targeted location privacy is guaranteed. However, the 506 correspondent node may wrongly believe that mobile node has moved 507 close to himself once the mobile node bootstraps with an ORHA and 508 moves the session from IRHA to ORHA as described in Section 5.2. 509 However, since the decision to optimize an ongoing session is 510 independent of the mobile node's movement, the correspondent node 511 cannot infer anything about the mobile node's real movement patterns 512 from this. 514 An attacker could initiate many faked communication sessions with 515 spoofed source addresses in order to trigger the mobile node to 516 discover and bootstrap with many different ORHAs. This could consume 517 significant resources on the mobile node and in the network and may 518 cause a DoS. As a countermeasure, the mobile node should not start 519 bootstrapping with a new ORHA just because it receives packets from a 520 new correspondent node or it should limit the number of 521 simultaneously used ORHAs. Faked sessions should be identified as 522 such as quickly as possible and the mobile node should de-register 523 immediately from ORHAs once a session is identified as a fake 524 session. 526 The ORHA knows the location of the mobile node and could distribute 527 it to third parties without authorization from the mobile node. 528 Hence, the mobile node must be sure that the ORHA is trusted before 529 the mobile node reveals its location to the ORHA. How the trust 530 verification is done depends on the ORHA discovery mechanism in use. 531 One option is that the MSA knows which home agents are trusted with 532 respect to location privacy and only assigns such home agents to the 533 mobile node. The MSA could also deny the authorization request if 534 the MN tries to bootstrap with an untrusted home agent. Another 535 option is that the mobile node verifies the trust by itself, e.g., by 536 pre-configuring a list of trusted home agent addresses on the mobile 537 node or by using certificates. Note that the fact that the ORHA and 538 the correspondent node may be in the same administrative domain 539 doesn't imply that the ORHA reveals the mobile node's location to the 540 correspondent node. This is also true in today's cellular networks, 541 where it is ensured that users of a service provided by a particular 542 mobile operator don't know the location of other users using a 543 service provided by the same operator. 545 The return routability procedure over the reverse tunnel to the ORHA 546 is not considered less secure than the standard return routability 547 procedure as long as the ORHA is trusted and the ORHA link is not 548 vulnerable to eavesdropping. 550 8. Acknowledgements 552 Thanks to Kuntal Chowdhury, Vijay Devarapalli, Rajeev Koodli, and 553 Ahmad Muhanna for their valuable comments and suggestions to improve 554 this document. 556 9. References 558 9.1. Normative References 560 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 561 Levels", BCP 14, RFC 2119, March 1997. 563 [2] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in 564 IPv6", RFC 3775, June 2004. 566 [3] Giaretta, G., "Mobile IPv6 bootstrapping in split scenario", 567 draft-ietf-mip6-bootstrapping-split-07 (work in progress), 568 July 2007. 570 9.2. Informative References 572 [4] Draves, R., "Default Address Selection for Internet Protocol 573 version 6 (IPv6)", RFC 3484, February 2003. 575 [5] Manner, J. and M. Kojo, "Mobility Related Terminology", 576 RFC 3753, June 2004. 578 [6] Patel, A. and G. Giaretta, "Problem Statement for bootstrapping 579 Mobile IPv6 (MIPv6)", RFC 4640, September 2006. 581 [7] Koodli, R., "IP Address Location Privacy and Mobile IPv6: 582 Problem Statement", RFC 4882, May 2007. 584 [8] Chowdhury, K. and A. Yegin, "MIP6-bootstrapping for the 585 Integrated Scenario", 586 draft-ietf-mip6-bootstrapping-integrated-dhc-05 (work in 587 progress), July 2007. 589 [9] Jang, H., "DHCP Option for Home Information Discovery in 590 MIPv6", draft-ietf-mip6-hiopt-07 (work in progress), 591 September 2007. 593 [10] Dupont, F., "A Simple Privacy Extension for Mobile IPv6", 594 draft-dupont-mip6-privacyext-04 (work in progress), July 2006. 596 [11] Qiu, Y., "Mobile IPv6 Location Privacy Solutions", 597 draft-irtf-mobopts-location-privacy-solutions-05 (work in 598 progress), May 2007. 600 [12] Weniger, K. and F. Dupont, "IKEv2-based Home Agent Assignment 601 in Mobile IPv6/NEMO Bootstrapping", 602 draft-dupont-ikev2-haassign-02 (work in progress), 603 January 2007. 605 Author's Address 607 Kilian A. Weniger 608 Panasonic R&D Center Germany 609 Monzastr. 4c 610 Langen 63225 611 Germany 613 Email: kilian.weniger@eu.panasonic.com 615 Full Copyright Statement 617 Copyright (C) The IETF Trust (2007). 619 This document is subject to the rights, licenses and restrictions 620 contained in BCP 78, and except as set forth therein, the authors 621 retain all their rights. 623 This document and the information contained herein are provided on an 624 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 625 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 626 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 627 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 628 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 629 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 631 Intellectual Property 633 The IETF takes no position regarding the validity or scope of any 634 Intellectual Property Rights or other rights that might be claimed to 635 pertain to the implementation or use of the technology described in 636 this document or the extent to which any license under such rights 637 might or might not be available; nor does it represent that it has 638 made any independent effort to identify any such rights. Information 639 on the procedures with respect to rights in RFC documents can be 640 found in BCP 78 and BCP 79. 642 Copies of IPR disclosures made to the IETF Secretariat and any 643 assurances of licenses to be made available, or the result of an 644 attempt made to obtain a general license or permission for the use of 645 such proprietary rights by implementers or users of this 646 specification can be obtained from the IETF on-line IPR repository at 647 http://www.ietf.org/ipr. 649 The IETF invites any interested party to bring to its attention any 650 copyrights, patents or patent applications, or other proprietary 651 rights that may cover technology that may be required to implement 652 this standard. Please address the information to the IETF at 653 ietf-ipr@ietf.org. 655 Acknowledgment 657 Funding for the RFC Editor function is provided by the IETF 658 Administrative Support Activity (IASA).