idnits 2.17.1 draft-ietf-mip6-location-privacy-ps-05.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 12. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 477. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 484. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 490. ** The document seems to lack an RFC 3978 Section 5.5 (updated by RFC 4748) Disclaimer -- however, there's a paragraph with a matching beginning. Boilerplate error? 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 Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' 1. Introduction' ) ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 7. Security Considerations' ) ** 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.) (A line matching the expected section header was found, but with an unexpected indentation: ' 6. IANA Considerations' ) ** There are 23 instances of too long lines in the document, the longest one being 7 characters in excess of 72. 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 (2 February 2007) is 6292 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) -- Missing reference section? '9' on line 422 looks like a reference -- Missing reference section? '2' on line 394 looks like a reference -- Missing reference section? '5' on line 406 looks like a reference -- Missing reference section? '4' on line 402 looks like a reference -- Missing reference section? '3' on line 398 looks like a reference -- Missing reference section? '1' on line 388 looks like a reference -- Missing reference section? '7' on line 414 looks like a reference -- Missing reference section? '6' on line 410 looks like a reference -- Missing reference section? '8' on line 458 looks like a reference -- Missing reference section? '10' on line 426 looks like a reference -- Missing reference section? 'Geopriv' on line 458 looks like a reference Summary: 6 errors (**), 0 flaws (~~), 2 warnings (==), 17 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 MIP6 Working Group Rajeev Koodli 2 INTERNET DRAFT Nokia Research Center 3 Informational 4 2 February 2007 6 IP Address Location Privacy and Mobile IPv6: Problem Statement 7 draft-ietf-mip6-location-privacy-ps-05.txt 9 By submitting this Internet-Draft, each author represents that any 10 applicable patent or other IPR claims of which he or she is aware 11 have been or will be disclosed, and any of which he or she becomes 12 aware will be disclosed, in accordance with Section 6 of BCP 79. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note 16 that other groups may also distribute working documents as 17 Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of 20 six months and may be updated, replaced, or obsoleted by other 21 documents at any time. It is inappropriate to use Internet-Drafts 22 as reference material or to cite them other than as "work in 23 progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This document is a submission of the IETF MIP6 WG. Comments should 32 be directed to the MIP6 WG mailing list, mip6@ietf.org. 34 Abstract 36 In this document, we discuss Location Privacy as applicable to 37 Mobile IPv6. We document the concerns arising from revealing Home 38 Address to an on-looker and from disclosing Care of Address to a 39 correspondent. 41 Contents 43 Abstract i 45 1. Introduction 1 47 2. Definitions 3 49 3. Problem Definition 4 50 3.1. Disclosing the Care-of Address to the Correspondent Node 4 51 3.2. Revealing the Home Address to On-lookers . . . . . . . 4 52 3.3. Problem Scope . . . . . . . . . . . . . . . . . 4 54 4. Problem Illustration 5 56 5. Conclusion 8 58 6. IANA Considerations 8 60 7. Security Considerations 8 62 8. Acknowledgment 9 64 9. References 9 65 9.1. Normative References . . . . . . . . . . . . . . 9 66 9.2. Informative References . . . . . . . . . . . . . 9 68 10. Author's Address 10 70 A. Background 11 72 Intellectual Property Statement 12 74 Disclaimer of Validity 12 75 Copyright Statement 13 77 Acknowledgment 13 79 1. Introduction 81 The problems of location privacy, and privacy when using IP 82 for communication have become important. IP privacy is broadly 83 concerned with protecting user communication from unwittingly 84 revealing information that could be used to analyze and gather 85 sensitive user data. Examples include gathering data at certain 86 vantage points, collecting information related to specific traffic, 87 and monitoring (perhaps) certain populations of users for activity 88 during specific times of the day, etc. In this document, we refer 89 to this as the "profiling" problem. 91 Location privacy is concerned with the problem of revealing 92 roaming, which we define here as the process of a Mobile Node 93 (MN) moving from one network to another with or without on-going 94 sessions. A constant identifier with global scope can reveal 95 roaming. Examples are a device identifier such as an IP address, 96 and a user identifier such as a SIP [9] URI [2]. Often, a binding 97 between these two identifiers is available, e.g., through DNS [5]. 98 Traffic analysis of such IP and Upper Layer Protocol identifiers 99 on single network can indicate device and user roaming. Roaming 100 could also be inferred by means of profiling constant fields in IP 101 communication across multiple network movements. For example, an 102 Interface Identifier (IID) [10 ] in the IPv6 address that remains 103 unchanged across networks could suggest roaming. The SPI in the 104 IPsec [4] header is another field that may be subject to such 105 profiling and inference. Inferring roaming in this way typically 106 requires traffic analysis across multiple networks, or colluding 107 attackers, or both. When location privacy is compromised, it could 108 lead to more targetted profiling of user communication. 110 As can be seen, the location privacy problem spans multiple 111 protocol layers. Nevertheless, it is important to understand and 112 specify the problem as applicable to concerned protocols in order 113 to at least mitigate the effects of the problem. In this context, 114 it is particularly important to Mobile IP, which defines a global 115 identifier (Home Address) that can reveal device roaming, and in 116 conjunction with a corresponding user identifier (such as a SIP 117 URI), can also reveal user roaming. Furthermore, a user may not 118 wish to reveal roaming to correspondent(s), which translates to the 119 use of Care-of Address. As with Home Address, the Care-of Address 120 can also reveal the topological location of the Mobile Node. 122 This document describes the concerns arising from the use of Home 123 Address from a visited network. This document also outlines the 124 considerations in disclosing a Care-of Address. This document 125 is primarily concerned with the vulnerabilities arising from 126 possible traffic analysis along the MN - CN path and the MN - HA 127 path, where the disclosure of Mobile IP addresses is sufficient to 128 reveal roaming. This document does not consider inferring roaming 129 from profiling fields such as an IID or an SPI for the following 130 reasons: First, such inference could be done independently, so the 131 problem is not specific to Mobile IP. Second, with Mobile IP, it 132 is sufficient to simply monitor the usage of Home Address from a 133 single visited network in order to deduce roaming. In other words, 134 the attackers need not conduct traffic profiling across multiple 135 networks, or collude with each other, or do both in order to infer 136 roaming when Mobile IP is used. Hence, we limit the scope of this 137 document to revealing the Mobile IP addresses. 139 This document is only concerned with IP Address Location Privacy 140 in the context of Mobile IPv6. It does not address the overall 141 privacy problem. For instance, it does not address privacy 142 issues related to MAC addresses or the relationship of IP and MAC 143 addresses [3], or the Upper Layer Protocol addresses. Solution 144 to the problem specified here should provide protection against 145 roaming disclosure due to using Mobile IPv6 addresses from a 146 visited network. 148 This document assumes that the reader is familiar with the basic 149 operation of Mobile IPv6 [1] and the associated terminology defined 150 therein. For convenience, we provide some definitions below. 152 2. Definitions 154 - Mobile Node (MN): A Mobile IPv6 Mobile Node that freely roams 155 around networks 157 - Correspondent Node (CN): A Mobile IPv6 that node corresponds 158 with a MN 160 - Home Network: The network where the MN is normally present 161 when it is not roaming 163 - Visited Network: A network which a MN uses to access Internet 164 when it is roaming 166 - Home Agent: A router on the MN's home network which provides 167 forwarding support when the MN is roaming 169 - Home Address (HoA): The MN's unicast IP address valid on its 170 home network 172 - Care-of Address (CoA): The MN's unicast IP address valid on the 173 visited network 175 - Reverse Tunneling or Bidirectional Tunneling: A mechanism used 176 for packet forwarding between the MN and its Home Agent 178 - Route Optimization: A mechanism which allows direct routing 179 of packets between a roaming MN and its CN, without having to 180 traverse the home network. 182 3. Problem Definition 184 3.1. Disclosing the Care-of Address to the Correspondent Node 186 When a Mobile IP MN roams from its home network to a visited 187 network or from one visited network to another, use of Care-of 188 Address in communication with a correspondent reveals that the 189 MN has roamed. This assumes that the correspondent is able to 190 associate the Care-of Address to Home Address, for instance by 191 inspecting the Binding Cache Entry. The Home Address itself is 192 assumed to have been obtained by whatever means (e.g., through DNS 193 lookup). 195 3.2. Revealing the Home Address to On-lookers 197 When a Mobile IP MN roams from its home network to a visited 198 network or from one visited network to another, use of Home Address 199 in communication reveals to an on-looker that the MN has roamed. 200 When a binding of Home Address to a user identifier (such as 201 a SIP URI) is available, the Home Address can be used to also 202 determine that the user has roamed. This problem is independent 203 of whether the MN uses Care-of Address to communicate directly 204 with the correspondent (i.e., uses route optimization), or the MN 205 communicates via the Home Agent (i.e., uses reverse tunneling). 207 Location privacy may be compromised if an on-looker is present 208 on the MN - HA path (when bidirectional tunneling is used), or 209 when the on-looker is present on the MN and CN path (when route 210 optimization is used). 212 3.3. Problem Scope 214 With existing Mobile IPv6 solutions, there is some protection 215 against location privacy. If a Mobile Node uses reverse tunneling 216 with ESP encryption, then the Home Address is not revealed on 217 the MN - HA path. So, eavesdroppers on the MN - HA path cannot 218 determine roaming. They could, however, still profile fields in 219 the ESP header; however, this problem is not specific to Mobile 220 IPv6 location privacy. 222 When a MN uses reverse tunneling (regardless of ESP encryption), 223 the correspondent does not have access to the Care-of Address. 224 Hence, it cannot determine that the MN has roamed. 226 Hence, the location privacy problem is particularly applicable when 227 Mobile IPv6 route optimization is used or when reverse tunneling 228 is used without protecting the inner IP packet containing the Home 229 Address. 231 4. Problem Illustration 233 This section is intended to provide an illustration of the problem 234 defined in the previous section. 236 Consider a Mobile Node at its home network. Whenever it is 237 involved in IP communication, its correspondents can see an 238 IP address valid on the home network. Elaborating further, 239 the users involved in peer - peer communication are likely 240 to see a user-friendly identifier such as a SIP URI, and the 241 communication end-points in the IP stack will see IP addresses. 242 Users uninterested in or unaware of IP communication details will 243 not see any difference when the MN acquires a new IP address. 244 Of course any user can ``tcpdump'' or ``ethereal'' a session, 245 capture IP packets and map the MN's IP address to an approximate 246 geo-location. This mapping may reveal the home location of a 247 user, but a correspondent cannot ascertain whether the user has 248 actually roamed or not. Assessing the physical location based on 249 IP addresses has some similarities to assessing the geographical 250 location based on the area-code of a telephone number. The 251 granularity of the physical area corresponding to an IP address 252 can vary depending on how sophisticated the available tools are, 253 how often an ISP conducts its network re-numbering, etc. And, 254 an IP address cannot also guarantee that a peer is at a certain 255 geographic area due to technologies such as VPN and tunneling. 257 When the MN roams to another network, the location privacy problem 258 consists of two parts: revealing information to its correspondents 259 and to on-lookers. 261 With its correspondents, the MN can either communicate directly 262 or reverse tunnel its packets through the Home Agent. Using 263 reverse tunneling does not reveal Care-of Address of the MN, 264 although end-to-end delay may vary depending on the particular 265 scenario. With those correspondents with which it can disclose its 266 Care-of Address ``on the wire'', the MN has the option of using 267 route-optimized communication. The transport protocol still sees 268 the Home Address with route optimization. Unless the correspondent 269 runs some packet capturing utility, the user cannot see which mode 270 (reverse tunneling or route optimization) is being used, but knows 271 that it is communicating with the same peer whose URI it knows. 272 This is similar to conversing with a roaming cellphone user whose 273 phone number, like the URI, remains unchanged. 275 Regardless of whether the MN uses route optimization or reverse 276 tunneling (without ESP encryption), its Home Address is revealed 277 in data packets. When equipped with an ability to inspect packets 278 ``on the wire'', an on-looker on the MN - HA path can determine 279 that the MN has roamed and could possibly also determine that 280 the user has roamed. This could compromise the location privacy 281 even if the MN took steps to hide its roaming information from a 282 correspondent. 284 The above description is valid regardless of whether a Home Address 285 is statically allocated or is dynamically allocated. In either 286 case, the mapping of IP address to geo-location will most likely 287 yield results with the same level of granularity. With the freely 288 available tools on the Internet, this granularity is the physical 289 address of the ISP or the organization which registers ownership of 290 a prefix chunk. Since an ISP or an organization is not, rightly, 291 required to provide a blue-print of its subnets, the granularity 292 remains fairly coarse for a mobile wireless network. However, 293 sophisticated attackers might be able to conduct site mapping and 294 obtain more fine-grained subnet information. 296 A compromise in location privacy could lead to more targetted 297 profiling of user data. An eavesdropper may specifically track 298 the traffic containing the Home Address, and monitor the movement 299 of the Mobile Node with changing Care-of Address. The profiling 300 problem is not specific to Mobile IPv6, but could be triggered 301 by a compromise in location privacy due to revealing the Home 302 Address. A correspondent may take advantage of the knowledge that 303 a user has roamed when Care-of Address is revealed, and modulate 304 actions based on such a knowledge. Such an information could cause 305 concern to a mobile user especially when the correspondent turns 306 out be untrustworthy. For these reasons, appropriate management 307 interfaces on the MN to guard against the misuse of location 308 information should be considered. 310 Applying existing techniques to thwart profiling may have 311 implications to Mobile IPv6 signaling performance. For instance, 312 changing the Care-of Address often would cause additional Return 313 Routability [1] and binding management signaling. And, changing 314 the Home Address often has implications on IPsec security 315 association management. Solutions should be careful in considering 316 the cost of change of either Care-of Address or Home Address on 317 signaling. 319 When roaming, a MN may treat its home network nodes as any other 320 correspondents. Reverse tunneling is perhaps sufficient for home 321 network communication, since route-optimized communication will 322 traverse the identical path. Hence, a MN can avoid revealing its 323 Care-of Address to its home network correspondents simply by using 324 reverse tunneling. The Proxy Neighbor Advertisements [7] from the 325 Home Agent could serve as hints to the home network nodes that the 326 Mobile Node is away. However, they will not be able to know the 327 Mobile Node's current point of attachment unless the MN uses route 328 optimization with them. 330 5. Conclusion 332 In this document, we have discussed the location privacy problem 333 as applicable to Mobile IPv6. The problem can be summarized 334 as follows: disclosing Care-of Address to a correspondent and 335 revealing Home Address to an on-looker can compromise the location 336 privacy of a Mobile Node, and hence that of a user. We have seen 337 that bidirectional tunneling allows a MN to protect its Care-of 338 Address to the CN. And, ESP encryption of inner IP packet allows 339 the MN to protect its Home Address from the on-lookers on the MN - 340 HA path. However, with route optimization, the MN will reveal its 341 Care-of Address to the CN. Moreover, route optimization causes the 342 Home Address to be revealed to on-lookers in the data packets as 343 well as in Mobile IPv6 signaling messages. The solutions to this 344 problem are expected to be protocol specifications assuming the 345 existing Mobile IPv6 functional entities, namely, the Mobile Node, 346 its Home Agent and the Correspondent Node. 348 6. IANA Considerations 350 There are no IANA considerations introduced by this draft. 352 7. Security Considerations 354 This document discusses the location privacy problem specific to 355 Mobile IPv6. Any solution must be able to protect (e.g., using 356 encryption) the Home Address from disclosure to on-lookers in 357 data packets when using route optimization or reverse tunneling. 358 In addition, solutions must consider protecting the Mobile IPv6 359 signaling messages from disclosing the Home Address along the MN - 360 HA and MN - CN paths. 362 Disclosing the Care-of Address is inevitable if a MN wishes to 363 use route optimization. Regardless of whether Care-of Address 364 is an on-link address of the MN on the visited link or that of 365 a co-operating proxy, mere presence of Binding Cache entry is 366 sufficient for a CN to ascertain roaming. Hence, a MN concerned 367 with location privacy should exercise prudence in determining 368 whether to use route optimization with, especially previously 369 unacquainted, correspondents. 371 The solutions should also consider the use of temporary addresses 372 and their implications on Mobile IPv6 signaling as discussed in 373 Section 4. Use of IP addresses with privacy extensions [6] could 374 be especially useful for Care-of Addresses if appropriate tradeoffs 375 with Return Routability signaling are taken into account. 377 8. Acknowledgment 379 Thanks to James Kempf, Qiu Ying, Sam Xia and Lakshminath Dondeti 380 for the review and feedback. Thanks to Jari Arkko and Kilian 381 Weniger for the last call review and for suggesting improvements 382 and text. 384 9. References 386 9.1. Normative References 388 [1] D. Johnson, C. Perkins, and J. Arkko. Mobility Support in 389 IPv6. Request for Comments 3775, Internet Engineering Task 390 Force, June 2004. 392 9.2. Informative References 394 [2] T. Berners-Lee, R. Fielding, and L. Masinter. Uniform Resource 395 Identifiers (URI): Generic Syntax. Request for Comments (Draft 396 Standard) 2396, Internet Engineering Task Force, August 1998. 398 [3] W. Haddad and et al., Privacy for Mobile and Multi-homed 399 Nodes: MoMiPriv Problem Statement (work in progress). 400 Internet Draft, Internet Engineering Task Force, October 2004. 402 [4] S. Kent and K. Seo. Security Architecture for the Internet 403 Protocol. Request for Comments (Proposed Standard) 4301, 404 Internet Engineering Task Force, December 2005. 406 [5] P. V. Mockapetris. Domain names - implementation and 407 specification. Request for Comments (Standard) 1035, Internet 408 Engineering Task Force, November 1987. 410 [6] T. Narten and R. Draves. Privacy Extensions for Stateless 411 Address Autoconfiguration in IPv6. Request for Comments 3041, 412 Internet Engineering Task Force, January 2001. 414 [7] T. Narten, E. Nordmark, and W. Simpson. Neighbor Discovery for 415 IP Version 6 (IPv6). Request for Comments (Draft Standard) 416 2461, Internet Engineering Task Force, December 1998. 418 [8] J. Polk, J. Schnizlein, and M. Linsner. DHCP Option for 419 Coordinate-based Location Configuration Information. Request 420 for Comments 3825, Internet Engineering Task Force, July 2004. 422 [9] J. Rosenberg and et al. SIP: Session Initiation Protocol. 423 Request for Comments (Proposed Standard) 3261, Internet 424 Engineering Task Force, June 2002. 426 [10] S. Thomson and T. Narten. IPv6 Stateless Address 427 Autoconfiguration. Request for Comments (Draft Standard) 2462, 428 Internet Engineering Task Force, December 1998. 430 10. Author's Address 432 Rajeev Koodli 433 Nokia Research Center 434 975 Page Mill Road, 200 435 Palo Alto, CA 94034 USA 436 Phone: +1 408 425 6684 437 Fax: +1 650 625 2502 438 E-Mail: Rajeev.Koodli@nokia.com 440 A. Background 442 The location privacy topic is broad and often has different 443 connotations. It also spans multiple layers in the OSI reference 444 model. Besides, there are attributes beyond an IP address alone 445 that can reveal hints about location. For instance, even if a 446 correspondent is communicating with the same end-point it is used 447 to, the ``time of the day'' attribute can reveal a hint to the 448 user. Some roaming cellphone users may have noticed that their SMS 449 messages carry a timestamp of their ``home network'' timezone (for 450 location privacy or otherwise) which can reveal that the user is in 451 a different timezone when messages are sent during ``normal'' time 452 of the day. Furthermore, tools exist on the Internet which can map 453 an IP address to the physical address of an ISP or the organization 454 which owns the prefix chunk. Taking this to another step, with 455 in-built GPS receivers on IP hosts, applications can be devised 456 to map geo-locations to IP network information. Even without GPS 457 receivers, geo-location can also be obtained in environments where 458 [Geopriv] is supported, for instance as a DHCP option [8]. 460 In summary, a user's physical location can be determined or 461 guessed with some certainty and with varying levels of granularity 462 by different means even though IP addresses themselves do not 463 inherently provide any geo-location information. It is perhaps 464 useful to bear this broad scope in mind as the problem of IP 465 address location privacy in the presence of IP Mobility is 466 addressed. 468 Intellectual Property Statement 470 The IETF takes no position regarding the validity or scope of 471 any Intellectual Property Rights or other rights that might be 472 claimed to pertain to the implementation or use of the technology 473 described in this document or the extent to which any license 474 under such rights might or might not be available; nor does it 475 represent that it has made any independent effort to identify any 476 such rights. Information on the procedures with respect to rights 477 in RFC documents can be found in BCP 78 and BCP 79. 479 Copies of IPR disclosures made to the IETF Secretariat and any 480 assurances of licenses to be made available, or the result of an 481 attempt made to obtain a general license or permission for the 482 use of such proprietary rights by implementers or users of this 483 specification can be obtained from the IETF on-line IPR repository 484 at http://www.ietf.org/ipr. 486 The IETF invites any interested party to bring to its attention any 487 copyrights, patents or patent applications, or other proprietary 488 rights that may cover technology that may be required to implement 489 this standard. Please address the information to the IETF at 490 ietf-ipr@ietf.org. 492 Disclaimer of Validity 494 This document and the information contained herein are provided 495 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 496 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 497 IETF TRUST, AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 498 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 499 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 500 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 501 FOR A PARTICULAR PURPOSE. 503 Copyright Statement 505 Copyright (C) The IETF Trust (2007). 507 This document is subject to the rights, licenses and restrictions 508 contained in BCP 78, and except as set forth therein, the authors 509 retain all their rights. 511 Acknowledgment 513 Funding for the RFC Editor function is currently provided by the 514 Internet Society.