idnits 2.17.00 (12 Aug 2021) /tmp/idnits2669/draft-weniger-mobopts-mip6-cnlocpriv-03.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 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 678. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 689. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 696. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 702. 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 (November 28, 2008) is 4922 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 (Obsoleted by RFC 6275) ** Downref: Normative reference to an Informational RFC: RFC 4882 == 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 -- Obsolete informational reference (is this intentional?): RFC 3484 (Obsoleted by RFC 6724) Summary: 4 errors (**), 0 flaws (~~), 6 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 4 Expires: June 1, 2009 G. Velev (Ed.) 5 Panasonic 6 November 28, 2008 8 MIPv6 Correspondent Node-Targeted Location Privacy and Optimized Routing 9 draft-weniger-mobopts-mip6-cnlocpriv-03 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on June 1, 2009. 36 Abstract 38 This document discusses the problem of correspondent node-targeted 39 location privacy in Mobile IPv6 and proposes a mechanism to achieve 40 simultaneous optimized routing and full correspondent node-targeted 41 IP address location privacy. The mechanism utilizes the MIPv6 42 bootstrapping mechanisms and does neither require any new network 43 entities nor changes to home agent or correspondent node 44 implementations. 46 Table of Contents 48 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 2. Introduction and Problem Definition . . . . . . . . . . . . . 5 50 3. Related work . . . . . . . . . . . . . . . . . . . . . . . . . 7 51 4. Applicability Statement . . . . . . . . . . . . . . . . . . . 8 52 5. Changes to Mobile Node Operation . . . . . . . . . . . . . . . 10 53 5.1. Route Optimization for New Sessions . . . . . . . . . . . 10 54 5.2. Route Optimization for Ongoing Sessions . . . . . . . . . 11 55 5.3. Route Optimization Mode Selection . . . . . . . . . . . . 13 56 5.4. Source Address Selection . . . . . . . . . . . . . . . . . 13 57 6. Location-dependent Home Agent Discovery . . . . . . . . . . . 14 58 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 59 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 60 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 61 9.1. Normative References . . . . . . . . . . . . . . . . . . . 19 62 9.2. Informative References . . . . . . . . . . . . . . . . . . 19 63 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 64 Intellectual Property and Copyright Statements . . . . . . . . . . 22 66 1. Terminology 68 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 69 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 70 document are to be interpreted as described in [RFC2119]. 72 The terminology of [RFC3775] and [RFC5026] is used. Additionally, 73 the following terms are introduced: 75 IP Reachability Home Agent (IRHA): A home agent as specified in 76 [RFC3775] that provides IP reachability and global session 77 continuity for the mobile node. 79 Home Address for IP Reachability (HoA_IR): A home address used for 80 IP reachability and session continuity and that is registered at 81 the IRHA. This home address is independent of the location of the 82 mobile node and is disclosed to potential correspondent nodes 83 (e.g., by publishing the address in DNS). 85 Optimized path: A path between mobile node and correspondent node 86 that is shorter than the IP reachability path, but may be longer 87 than the optimal path. The IP Reachability path is the path 88 between mobile node and correspondent node if the mobile node uses 89 bi-directional tunneling mode with the IRHA. The optimal path is 90 the end-to-end path between mobile node and correspondent node, 91 e.g., the path in MIPv6 Route Optimization mode. 93 Optimized routing: Routing data packets over the optimized path 95 Optimized Routing Home Agent (ORHA): A home agent as specified in 96 [RFC3775] that is used for providing optimized routing. It must 97 support the bootstrapping mechanisms specified in [RFC5026] and 98 should be located close to the correspondent node. 100 Home Address for Optimized Routing (HoA_OR): A home address used for 101 optimized routing and session continuity and that is registered at 102 the ORHA. This home address is usually not public (i.e., not 103 published in DNS). 105 Eavesdropper-targeted location privacy: Hiding the mobile node's 106 location from nodes eavesdropping on the path between mobile node 107 and correspondent node (and home agent) 109 Correspondent node-targeted location privacy: Hiding the mobile 110 node's location from the correspondent node 112 Full IP address location privacy: Ensuring that no information about 113 a mobile node's current location can be derived from the mobile 114 node's IP address by other nodes, not even the current access 115 network or subnet of the mobile node. 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 [RFC3775], the care-of address and the home address typically 125 represent topological location and identity of a mobile node, 126 respectively. Note that a dynamically assigned home address does not 127 represent a permanent identity itself, but a mapping to one of the 128 mobile node's permanent identifiers is typically published for IP 129 reachability reasons (e.g., in DNS), so that other nodes are able to 130 find out the mobile node's current home address to initiate a session 131 with the mobile node. Consequently, in Mobile IPv6 at least either 132 the care-of address or the home address must be hidden from anyone 133 that is not authorized to obtain the location of the mobile node. 134 Two rather orthogonal sub-problems of location privacy for Mobile 135 IPv6 can be distinguished: hiding the location from eavesdroppers on 136 the path and hiding the location from the correspondent node, which 137 we henceforth call eavesdropper-targeted and correspondent node- 138 targeted location privacy, respectively (see [RFC4882] for details 139 about the Mobile IPv6 location privacy problem). This document is 140 concerned with correspondent node-targeted location privacy only, 141 especially with the problem of providing optimized routing at the 142 same time. Eavesdropper-targeted location privacy is out of scope, 143 but can be achieved by combining the mechanisms in this document with 144 pseudo home address mechanisms 145 [I-D.irtf-mobopts-location-privacy-solutions]. Any location privacy 146 issues not directly related to Mobile IPv6 are out of the scope of 147 this document. 149 An example scenario illustrating the problem is the following: A 150 mobile node uses Mobile IPv6 with a public home address and wants to 151 hide its location. The home address can be a dynamically assigned 152 home address that is linked to a mobile node's public permanent 153 identifier (e.g., FQDN in DNS). The mobile node requires full 154 correspondent node-targeted IP address location privacy, i.e., hiding 155 only the mobility within an access network and revealing the access 156 network prefix to the correspondent node is not acceptable. An 157 application on the correspondent node initiates a delay-sensitive 158 session such as VoIP by sending packets to the mobile node's public 159 home address. Initiating an IP session typically requires the 160 correspondent node to already know the mobile node's identity and 161 thus the mobile node's public home address. The mobile node receives 162 the packets in bi-directional tunneling mode from its home agent and 163 may start sending packets back to the corresponding node. Let's 164 assume the mobile node is located in the United States and the 165 correspondent node is located in Canada, whereas the mobile node's 166 home agent is located in Europe. Since the mobile node is far away 167 from home, the packet delay and hence the user experience is far from 168 what could be achieved. One approach to reduce the end-to-end packet 169 delay is to use MIPv6 route optimization. However, if the mobile 170 node uses route optimization mode, it reveals its CoA and hence its 171 location to the correspondent node. Note that the correspondent node 172 can also be an attacker that just initiates a session to find out the 173 mobile node's location. Consequently, the mobile node has the 174 choice: it can have good user experience without location privacy or 175 location privacy with bad user experience. Currently, there is no 176 way to achieve both simultaneously with Mobile IPv6. 178 This document proposes a mechanism that can provide full 179 correspondent node-targeted IP address location privacy and optimized 180 routing simultaneously. Home agent and correspondent node are 181 unchanged and no new entities or messages are introduced. The basic 182 idea is that the mobile node uses a mobility service provided close 183 to the correspondent node's domain. More specifically, the mobile 184 node bootstraps with a home agent (henceforth called the ORHA), which 185 is located topologically close to the correspondent node (in the 186 above example, e.g., in Canada) and which is used for optimized 187 communication with this correspondent node. A location close to the 188 correspondent node ensures that no location information is contained 189 in the home address HoA_OR anchored at the ORHA while ensuring that 190 the route via the ORHA is shorter (or at least not significantly 191 longer) than the route via the IRHA in bi-directional tunneling mode. 192 For mobile node-initiated sessions with a particular correspondent 193 node, the mobile node uses the ORHA located topologically close to 194 the correspondent node in bi-directional tunneling mode and HoA_OR is 195 used as IP address for the session by higher layers. For 196 correspondent node-initiated sessions, the public home address HoA_IR 197 is used as IP address by higher layers and the mobile node registers 198 the HoA_OR as care-of address at the correspondent node. 200 3. Related work 202 Qui et. al. [I-D.irtf-mobopts-location-privacy-solutions] propose a 203 solution to the correspondent node-targeted location privacy problem. 204 The basic idea is to hide the home address from the correspondent 205 node in route optimization mode by using a pseudo home address 206 instead of the real home address. Although the care-of address is 207 revealed to the correspondent node, location privacy is protected by 208 hiding the identity (i.e., real home address) of the mobile node from 209 the correspondent node. This approach has also been proposed in 210 [I-D.dupont-mip6-privacyext]. However, if the correspondent node 211 initiates the communication, location privacy is usually compromised, 212 since the real home address is already known by the correspondent 213 node. And even if the real home address can be hidden from the 214 correspondent node, location privacy is compromised if the 215 correspondent node is able to figure out the mobile node's identity 216 by any other means on higher layers (e.g., during the conversation). 218 [RFC5026] and [I-D.ietf-mip6-bootstrapping-integrated-dhc] specify 219 the mechanisms for Mobile IPv6 bootstrapping in the split and the 220 integrated scenario, respectively. They allow a mobile node to 221 bootstrap with any home agent, for which the necessary trust 222 relationships are in place. When bootstrapping with a local home 223 agent, optimized routing can be achieved in bi-directional tunneling 224 mode. However, since the home address obtained from a local home 225 agent belongs to the network the mobile node is currently visiting, 226 it contains location information. Consequently, location privacy is 227 compromised, if the correspondent node knows that the home agent is 228 local to the mobile node (see security considerations of [RFC5026]). 229 Although in many cases the correspondent node will not know, there 230 are cases where the correspondent node can find out whether the 231 mobile node's home agent is local or remote. For instance, a 232 correspondent node may know that a mobile node's home agent is local 233 because the mobile node's Mobility Service Provider (MSP) is known to 234 always assign local home agents for routing efficiency reasons. 236 4. Applicability Statement 238 The mechanisms defined in this document require that the mobile node 239 is able to utilize a mobility service, which is offered close to the 240 correspondent node's domain. To allow optimized communication with 241 many or even any correspondent node, it is required that home agent 242 services are offered to the mobile node from various topological 243 locations. This typically requires that an MSP offers mobility 244 service from many different locations or that multiple MSPs have some 245 kind of roaming relationships with the mobile node's mobility service 246 authorizer (MSA), so that a group of MSPs offers mobility service 247 from many different locations. Such roaming relationships can be 248 based on an AAA infrastructure. 250 This assumption is not particular to this document: the MIPv6 251 bootstrapping solutions for the split scenario [RFC5026] and the 252 integrated scenario [I-D.ietf-mip6-bootstrapping-integrated-dhc] also 253 require that a roaming relationship between MSP and MSA exist (see 254 also [RFC4640]). In the integrated scenario the access service 255 authorizer (ASA) is also the mobility service authorizer (MSA). An 256 important point of the integrated scenario is that the access service 257 provider (ASP) that the mobile node is currently visiting is 258 typically also an MSP, which provides local home agent service. This 259 means that roaming relationships between many MSPs and the mobile 260 node's MSA are required and, assuming global roaming, that home agent 261 services must be offered to the mobile node from various topological 262 locations. This represents the requirements mentioned in the 263 beginning of this section. So the assumptions are basically not 264 different from the assumptions for MIPv6 bootstrapping and can be met 265 by re-using the home agents, roaming relationships, and the 266 credentials that are already deployed for MIPv6 bootstrapping. 268 Note that it is not required that the ORHA is located within the 269 correspondent node's domain. A domain nearby to the correspondent 270 node's domain is sufficient to achieve location privacy and improved 271 routing efficiency. However, if the mobile node is not able to 272 discover a home agent located close to the correspondent node or if 273 no roaming relationship to the MSP of such home agent exists, 274 simultaneous optimized routing and correspondent node-targeted 275 location privacy cannot be provided by the mechanisms defined in this 276 document. 278 It is further assumed that the mobile node is authorized by the MSA 279 to use ORHAs which are located close to the correspondent node and 280 which potentially belong to an MSP different from the MSA. Since 281 location privacy can be seen as a value-added service, a user may be 282 willing to pay for this service. This may be an incentive for an MSA 283 to offer this service and delegate the mobility management to an MSP 284 located close to the correspondent node. 286 Finally, this optimization requires that the mobile node is able to 287 handle multiple simultaneous registrations with different home agents 288 and multiple home addresses. Also, the MSA/MSP must support the 289 assignment of multiple home agents and home addresses to the same 290 mobile node. 292 5. Changes to Mobile Node Operation 294 The mobile node operation is split in two cases: route optimization 295 for new sessions (i.e., communication sessions that have not yet 296 started) and route optimization for ongoing sessions. A session is 297 defined in this context by an application layer context bound to the 298 IP addresses of the two endpoints, with one of them being the mobile 299 node's home address. The first case applies, e.g., if the mobile 300 nodes wants to initiate a session with a correspondent node and 301 decides to optimized the route before sending the first data packets. 302 The second case applies, e.g., if the correspondent node initiates a 303 session with the mobile node or if the mobile node decides to 304 optimize the route of an ongoing session. 306 5.1. Route Optimization for New Sessions 308 The mobile node first tries to discover an ORHA (refer to Section 6 309 for details about the ORHA discovery). If the discovery is 310 successful, the mobile node bootstraps with the ORHA and uses it in 311 bi-directional tunneling mode for communication with the 312 correspondent node. Existing registrations with other home agents 313 are kept for communication with other correspondent nodes. The 314 HoA_OR is not made public, i.e., no DNS update should be triggered 315 for this home address. Since no correspondent node registration is 316 initiated, the care-of address is hidden and correspondent node- 317 targeted location privacy is ensured. An exemplary signaling flow is 318 shown in Figure 1. 320 +--+ +-------+ +--+ 321 |MN| | ORHA | |CN| 322 +--+ +-------+ +--+ 323 [ORHA discovery] | | 324 | | | 325 | MIPv6 bootstrapping | | 326 |<----------------------------------------->| | 327 | BU/BA (HoA_OR,CoA) | | 328 |<----------------------------------------->| | 329 | MIPv6 tunnel (ORHA) | data packets | 330 |===========================================|<------------------->| 332 Figure 1: Signaling flow for optimization of the route for a session 333 that has not yet started 335 Location privacy is provided, since the correspondent node only 336 learns the HoA_OR, which contains no information about the mobile 337 node's location. 339 5.2. Route Optimization for Ongoing Sessions 341 After the mobile node has decided to optimize the route of a session 342 (e.g., after receiving the first data packets tunneled by the IRHA 343 and originated from the correspondent node), it discovers an ORHA and 344 bootstraps with this ORHA. Since the communication session is based 345 on HoA_IR, packets are routed through the IRHA. To achieve optimized 346 routing, the mobile node uses route optimization mode over the 347 reverse tunnel to the ORHA, i.e., care-of test messages, binding 348 update messages, and later data packets destined for the 349 correspondent node are sent over the reverse tunnel to the ORHA. 350 While establishing the optimized path over the ORHA, the mobile node 351 can send and receive data packets over the IRHA. 353 To achieve location privacy, the mobile node uses HoA_IR as home 354 address and HoA_OR as care-of address in the context of the route 355 optimization mode. This results in the following headers for packets 356 sent by the mobile node for the session with the correspondent node 357 (IPsec for signaling protection to ORHA assumed): 359 Data packets and binding updates: 361 IPv6 header (source = care-of address, 362 destination = ORHA) 363 ESP header in tunnel mode 364 IPv6 header (source = HoA_OR, 365 destination = correspondent node) 366 Destination Options header 367 Home Address option (HoA_IR) 368 Any protocol 370 Care-of Test Init: 372 IPv6 header (source = care-of address, 373 destination = ORHA) 374 ESP header in tunnel mode 375 IPv6 header (source = HoA_OR, 376 destination = correspondent node) 377 Any protocol 379 Since from the correspondent node's point of view, HoA_OR is the 380 care-of address and the HoA_IR is the home address of the mobile 381 node, data packets sent by the correspondent node to the mobile node 382 contain the HoA_IR in the type 2 routing header and the HoA_OR in the 383 destination address field of the IP header. Consequently, the data 384 packets are intercepted by the ORHA and tunneled to the mobile node. 385 An exemplary signaling flow is shown in Figure 2. 387 +--+ +-------+ +-------+ +--+ 388 |MN| | IRHA | | ORHA | |CN| 389 +--+ +-------+ +-------+ +--+ 390 | BU/BA (HoA_IR,CoA) | | | 391 |<------------------->| | | 392 ~ ~ ~ ~ 393 | MIPv6 tunnel (IRHA) | data packets | 394 |=====================|<----------------------------------------->| 395 | | | | 396 [ORHA discovery] | | | 397 | | | | 398 | MIPv6 bootstrapping | | 399 |<----------------------------------------->| | 400 | BU/BA (HoA_OR,CoA) | | 401 |<----------------------------------------->| | 402 | MIPv6 tunnel (IRHA) | HoTi | 403 |=====================|------------------------------------------>| 404 | MIPv6 tunnel (ORHA) | CoTi | 405 |===========================================|-------------------->| 406 | MIPv6 tunnel (IRHA) | HoT | 407 |=====================|<------------------------------------------| 408 | MIPv6 tunnel (ORHA) | CoT | 409 |===========================================|<--------------------| 410 | MIPv6 tunnel (ORHA) |BU/BA (HoA_IR,HoA_OR)| 411 |===========================================|<------------------->| 412 | MIPv6 tunnel (ORHA) | data packets | 413 |===========================================|<------------------->| 415 Figure 2: Signaling flow for optimization of the route for an ongoing 416 session 418 Location privacy is provided, since the correspondent node only 419 learns HoA_OR and HoA_IR, which both do not contain any information 420 about the mobile node's current location. 422 Note that upon changing the care-of address, the mobile node does not 423 send binding updates to the correspondent node over the reverse 424 tunnel to the ORHA, because the care-of address in this context is 425 the HoA_OR. 427 5.3. Route Optimization Mode Selection 429 The mobile node has to decide for every correspondent node, whether 430 it wants to use bi-directional tunneling mode, route optimization 431 mode or the mechanisms described in this document. How this decision 432 is made and when the route optimization is triggered is 433 implementation specific. Generally, for non-delay-sensitive services 434 such as simple web browsing, bi-directional tunneling to the home 435 agent is sufficient and achieves full correspondent node-targeted IP 436 address location privacy. If no location privacy is required, Mobile 437 IPv6 route optimization mode can be used. 439 Since the number of simultaneously used home agents have impacts on 440 the overall signaling overhead and resource consumption on the mobile 441 node, the mobile node should try to minimize the number of 442 simultaneously used ORHAs and only use the mechanisms specified in 443 this document for sessions that require simultaneous optimized 444 routing and correspondent node-targeted location privacy. Note 445 however that we are currently not aware of any realistic scenario 446 where a mobile node would have active sessions with a large amount of 447 different correspondent nodes simultaneously and all those sessions 448 require simultaneous optimized routing and correspondent node- 449 targeted location privacy. Optimizations to improve scalability in 450 such extreme scenarios may be developed later. 452 5.4. Source Address Selection 454 Since the mobile node will typically use different home addresses for 455 communication with different correspondent nodes when using the route 456 optimization mechanisms defined in this document, the mobile node 457 must be able to select the right home address as source address for 458 packets to be sent to a specific destination address. This can be 459 achieved with the source address selection mechanisms defined in 460 [RFC3484]. If the ORHA is located in the correspondent node's 461 domain, the prefix of the home address anchored at the ORHA is 462 similar to the prefix of the correspondent node and rule 8 of the 463 default source address selection [RFC3484] applies. For other cases, 464 dynamically adding entries for HoA_OR and correspondent node address 465 with matching labels in the policy table [RFC3484] when route 466 optimization according to this document is triggered would prefer a 467 home address as source address for communication with a specific 468 correspondent node. However, since this is implementation specific, 469 the details of the source address selection are out of the scope of 470 this document. 472 6. Location-dependent Home Agent Discovery 474 The mechanisms defined in this document require the discovery or 475 assignment of an ORHA, i.e., of a home agent located close to the 476 correspondent node. One options is to pre-configure the necessary 477 information on the mobile node, e.g., a list containing home agent 478 addresses and distances to various prefixes. Two options for dynamic 479 discovery are proposed in the following. 481 The first option is to re-use the DNS-based home agent discovery 482 specified in [RFC5026]. The mobile node would construct the FQDN, 483 e.g., based on the correspondent node's address, prefix or host name. 484 The DNS entry can be maintained by the MSP of the ORHA (e.g., 485 "ORHA.CNdomain.com") or by the MN's MSA (e.g., 486 "CNdomain.ORHA.MSAdomain.com"). Anycast-based home agent discovery 487 using IKEv2 extensions [I-D.dupont-ikev2-haassign] or DHAAD [RFC3775] 488 is also possible. The mobile node would, e.g., construct the anycast 489 destination address based on the correspondent node's prefix. 491 A second option is to query a dedicated server that is able to map an 492 FQDN, prefix or address of a correspondent node to an FQDN or address 493 of a home agent that is located in or topologically close to the 494 correspondent node's domain. This server can, e.g., be provided by a 495 third party in the public Internet or by the mobile node's Mobility 496 Service Authorizer (MSA). The mobile node would query this server to 497 discover the ORHA address. 499 This option can, e.g., be realized by re-using DHCP-based HA 500 assignment with the options and mechanisms defined in 501 [I-D.ietf-mip6-bootstrapping-integrated-dhc] and 502 [I-D.ietf-mip6-hiopt]. During network authentication, the MSA would 503 send to the Network Access Server (NAS) the home agent information 504 for all the MSPs, which the mobile node is authorized to use. Once 505 the mobile node wants to request a home agent close to the 506 correspondent node, it sends a DHCP Information Request message and 507 appends a Home Network Information Option [I-D.ietf-mip6-hiopt] with 508 a home network parameter suboption containing the correspondent 509 node's domain as target domain. The id-type can be set to 1 (target 510 MSP) or to a newly defined value for this purpose. The NAS would 511 then select a home agent from the set of authorized home agents that 512 is in (id-type 1) or close (new id-type) to the target domain 513 specified in the Home Network Information Option. How this selection 514 is done may be done in an implementation and operator specific way. 515 A simple selection algorithm would be to return a home agent with the 516 domain name equal to the target domain, if such home agent is part of 517 the list of authorized home agents, and otherwise return an home 518 agent from the home MSP or an empty Home Network Information option. 519 Finally, the NAS would assign the selected home agent to the mobile 520 node by putting the corresponding information in the Home Network 521 Information Option of the DHCP reply message. 523 Since the ORHA learns the location of the mobile node, the mobile 524 node must be sure that the ORHA doesn't reveal the mobile node's 525 location to nodes not authorized to get this information, i.e., the 526 ORHA must be trusted by the mobile node. How the trust verification 527 is done depends on the ORHA discovery mechanism in use. One option 528 is that the MSA knows which home agents are trusted with respect to 529 location privacy and only assigns such home agents to the mobile node 530 (i.e., only sends addresses of trusted home agents to the NAS or only 531 maintains DNS entries for trusted home agents). The MSA could also 532 deny the authorization request if the MN tries to bootstrap with an 533 untrusted home agent. Another option is that the mobile node 534 verifies the trust by itself, e.g., by pre-configuring a list of 535 trusted home agent addresses on the mobile node or by using 536 certificates. 538 7. Security Considerations 540 With the solution described in this document, a correspondent node 541 may learn at most the mobile node's addresses HoA_OR and HoA_IR. 542 HoA_IR is a permanent address used for IP reachability and hence 543 doesn't contain any information about the mobile node's current 544 location. Since HoA_OR is anchored close to the correspondent node, 545 there is no relation between HoA_OR and the mobile node's current 546 location as well and the correspondent node cannot infer mobile 547 node's real location from HoA_OR. The correspondent node may wrongly 548 believe that mobile node is close to himself, though. If the 549 correspondent node knows both HoA_OR and HoA_IR (the latter e.g., 550 from DNS or during the return routability procedure), it may wrongly 551 think that the mobile node has roamed from HoA_IR to HoA_OR. 552 However, since the mobile node can bootstrap with a new ORHA and use 553 a new HoA_OR without moving and since the mobile node does not change 554 HoA_OR cased on movements, the correspondent node cannot infer the 555 mobile node's real movement patterns just from HoA_OR and HoA_IR. 557 An attacker could initiate many faked communication sessions by 558 spoofing the source address in order to trigger the mobile node to 559 discover and bootstrap with many home agents. This could consume 560 significant resources on the mobile node and in the network and may 561 cause a DoS. As a countermeasure, the mobile node should not start 562 bootstrapping automatically without further checks when the 563 correspondent node initiates a session (especially if active ORHA 564 sessions already exist) or it should limit the number of ORHAs it may 565 be registered with simultaneously. Faked sessions should be 566 identified as such as quickly as possible and the mobile node should 567 de-register immediately from ORHAs that only served faked sessions. 569 The ORHA knows the location of the mobile node and could distribute 570 it to third parties without authorization from the mobile node. 571 Hence, the mobile node must be sure that the ORHA is trusted before 572 the mobile node reveals its location to the ORHA. How this can be 573 done is detailed in Section 6. Note that the fact that the ORHA and 574 the correspondent node may be in the same administrative domain 575 doesn't imply that the ORHA reveals the mobile node's location to the 576 correspondent node. This is also true in today's cellular networks, 577 where it is ensured that users of a service provided by a particular 578 mobile operator don't know the location of other users using a 579 service provided by the same operator. 581 The return routability procedure over the reverse tunnel to the ORHA 582 is not considered less secure than the standard return routability 583 procedure as long as the ORHA is trusted and the ORHA link is not 584 vulnerable to eavesdropping. 586 This document is concerned with correspondent node-targeted location 587 privacy only. Eavesdropper-targeted location privacy and any 588 location privacy issue not directly related to Mobile IPv6 are out of 589 the scope of this document. 591 8. Acknowledgements 593 Thanks to Kuntal Chowdhury, Vijay Devarapalli, Rajeev Koodli, and 594 Ahmad Muhanna for their valuable comments and suggestions to improve 595 this document. 597 9. References 599 9.1. Normative References 601 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 602 Requirement Levels", BCP 14, RFC 2119, March 1997. 604 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 605 in IPv6", RFC 3775, June 2004. 607 [RFC4882] Koodli, R., "IP Address Location Privacy and Mobile IPv6: 608 Problem Statement", RFC 4882, May 2007. 610 [RFC5026] Giaretta, G., Kempf, J., and V. Devarapalli, "Mobile IPv6 611 Bootstrapping in Split Scenario", RFC 5026, October 2007. 613 9.2. Informative References 615 [I-D.dupont-ikev2-haassign] 616 Weniger, K. and F. Dupont, "IKEv2-based Home Agent 617 Assignment in Mobile IPv6/NEMO Bootstrapping", 618 draft-dupont-ikev2-haassign-02 (work in progress), 619 January 2007. 621 [I-D.dupont-mip6-privacyext] 622 Dupont, F., "A Simple Privacy Extension for Mobile IPv6", 623 draft-dupont-mip6-privacyext-04 (work in progress), 624 July 2006. 626 [I-D.ietf-mip6-bootstrapping-integrated-dhc] 627 Chowdhury, K. and A. Yegin, "MIP6-bootstrapping for the 628 Integrated Scenario", 629 draft-ietf-mip6-bootstrapping-integrated-dhc-06 (work in 630 progress), April 2008. 632 [I-D.ietf-mip6-hiopt] 633 Jang, H., Yegin, A., Chowdhury, K., and J. Choi, "DHCP 634 Options for Home Information Discovery in MIPv6", 635 draft-ietf-mip6-hiopt-17 (work in progress), May 2008. 637 [I-D.irtf-mobopts-location-privacy-solutions] 638 Ying, Q., Zhao, F., and R. Koodli, "Mobile IPv6 Location 639 Privacy Solutions", 640 draft-irtf-mobopts-location-privacy-solutions-10 (work in 641 progress), November 2008. 643 [RFC3484] Draves, R., "Default Address Selection for Internet 644 Protocol version 6 (IPv6)", RFC 3484, February 2003. 646 [RFC4640] Patel, A. and G. Giaretta, "Problem Statement for 647 bootstrapping Mobile IPv6 (MIPv6)", RFC 4640, 648 September 2006. 650 Authors' Addresses 652 Kilian A. Weniger 654 Email: kilian.weniger@googlemail.com 656 Genadi Velev 657 Panasonic R&D Center Germany 658 Monzastr. 4c 659 Langen 63225 660 Germany 662 Email: genadi.velev@eu.panasonic.com 664 Full Copyright Statement 666 Copyright (C) The IETF Trust (2008). 668 This document is subject to the rights, licenses and restrictions 669 contained in BCP 78, and except as set forth therein, the authors 670 retain all their rights. 672 This document and the information contained herein are provided on an 673 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 674 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 675 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 676 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 677 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 678 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 680 Intellectual Property 682 The IETF takes no position regarding the validity or scope of any 683 Intellectual Property Rights or other rights that might be claimed to 684 pertain to the implementation or use of the technology described in 685 this document or the extent to which any license under such rights 686 might or might not be available; nor does it represent that it has 687 made any independent effort to identify any such rights. Information 688 on the procedures with respect to rights in RFC documents can be 689 found in BCP 78 and BCP 79. 691 Copies of IPR disclosures made to the IETF Secretariat and any 692 assurances of licenses to be made available, or the result of an 693 attempt made to obtain a general license or permission for the use of 694 such proprietary rights by implementers or users of this 695 specification can be obtained from the IETF on-line IPR repository at 696 http://www.ietf.org/ipr. 698 The IETF invites any interested party to bring to its attention any 699 copyrights, patents or patent applications, or other proprietary 700 rights that may cover technology that may be required to implement 701 this standard. Please address the information to the IETF at 702 ietf-ipr@ietf.org.