idnits 2.17.1 draft-ietf-mip6-location-privacy-ps-06.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 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 456. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 467. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 474. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 480. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == Mismatching filename: the document gives the document name as 'draft-ietf-mip6-location-privacy-06', but the file name used is 'draft-ietf-mip6-location-privacy-ps-06' Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (February 19, 2007) is 6275 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MIP6 Working Group Rajeev Koodli 3 Internet-Draft Nokia Research Center 4 Intended status: Informational February 19, 2007 5 Expires: August 23, 2007 7 IP Address Location Privacy and Mobile IPv6: Problem Statement 8 draft-ietf-mip6-location-privacy-06.txt 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on August 23, 2007. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2007). 39 Abstract 41 In this document, we discuss Location Privacy as applicable to Mobile 42 IPv6. We document the concerns arising from revealing Home Address 43 to an on-looker and from disclosing Care of Address to a 44 correspondent. 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 50 3. Problem Definition . . . . . . . . . . . . . . . . . . . . . . 5 51 3.1. Disclosing the Care-of Address to the Correspondent 52 Node . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 53 3.2. Revealing the Home Address to On-lookers . . . . . . . . . 5 54 3.3. Problem Scope . . . . . . . . . . . . . . . . . . . . . . 5 55 4. Problem Illustration . . . . . . . . . . . . . . . . . . . . . 6 56 5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 8 57 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 58 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 59 8. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . 9 60 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 61 9.1. Normative References . . . . . . . . . . . . . . . . . . . 9 62 9.2. Informative References . . . . . . . . . . . . . . . . . . 9 63 Appendix A. Background . . . . . . . . . . . . . . . . . . . . . 10 64 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10 65 Intellectual Property and Copyright Statements . . . . . . . . . . 11 67 1. Introduction 69 The problems of location privacy, and privacy when using IP for 70 communication have become important. IP privacy is broadly concerned 71 with protecting user communication from unwittingly revealing 72 information that could be used to analyze and gather sensitive user 73 data. Examples include gathering data at certain vantage points, 74 collecting information related to specific traffic, and monitoring 75 (perhaps) certain populations of users for activity during specific 76 times of the day, etc. In this document, we refer to this as the 77 "profiling" problem. 79 Location privacy is concerned with the problem of revealing roaming, 80 which we define here as the process of a Mobile Node (MN) moving from 81 one network to another with or without on-going sessions. A constant 82 identifier with global scope can reveal roaming. Examples are a 83 device identifier such as an IP address, and a user identifier such 84 as a SIP [rfc3261] URI[rfc2396]. Often, a binding between these two 85 identifiers is available, e.g., through DNS [rfc1035]. Traffic 86 analysis of such IP and Upper Layer Protocol identifiers on single 87 network can indicate device and user roaming. Roaming could also be 88 inferred by means of profiling constant fields in IP communication 89 across multiple network movements. For example, an Interface 90 Identifier (IID) [rfc2462] in the IPv6 address that remains unchanged 91 across networks could suggest roaming. The SPI in the IPsec 92 [rfc4301] header is another field that may be subject to such 93 profiling and inference. Inferring roaming in this way typically 94 requires traffic analysis across multiple networks, or colluding 95 attackers, or both. When location privacy is compromised, it could 96 lead to more targetted profiling of user communication. 98 As can be seen, the location privacy problem spans multiple protocol 99 layers. Nevertheless, we can examine problems encountered by nodes 100 using a particular protocol layer. Roaming is particularly important 101 to Mobile IP, which defines a global identifier (Home Address) that 102 can reveal device roaming, and in conjunction with a corresponding 103 user identifier (such as a SIP URI), can also reveal user roaming. 104 Furthermore, a user may not wish to reveal roaming to 105 correspondent(s), which translates to the use of Care-of Address. As 106 with Home Address, the Care-of Address can also reveal the 107 topological location of the Mobile Node. 109 This document scopes the problem of location privacy for the Mobile 110 IP protocol. The primary goal is to prevent attackers on the path 111 between the Mobile Node (MN) and the Correspondent Node (CN) from 112 detecting roaming due to the disclosure of the Home Address. The 113 attackers are assumed to be able to observe, modify and inject 114 traffic at one point between the MN and the CN. The attackers are 115 assumed not to be able to observe at multiple points and correlate 116 observations to detect roaming. For this reason, MAC addresses, IIDs 117 and other fields which can be profiled to detect roaming are only in 118 scope to the extent that they can be used by an attacker at one 119 point. Upper layer protocol identifiers that expose roaming are out 120 of scope except that a solution to the problem described here needs 121 to be usable as a building block in solutions to those problems. 123 This document also considers the problem from the exposure of Care-of 124 Address to the CN. 126 This document is only concerned with IP Address Location Privacy in 127 the context of Mobile IPv6. It does not address the overall privacy 128 problem. For instance, it does not address privacy issues related to 129 MAC addresses or the relationship of IP and MAC addresses 130 [draft-haddad], or the Upper Layer Protocol addresses. Solution to 131 the problem specified here should provide protection against roaming 132 disclosure due to using Mobile IPv6 addresses from a visited network. 134 This document assumes that the reader is familiar with the basic 135 operation of Mobile IPv6 [rfc3775] and the associated terminology 136 defined therein. For convenience, we provide some definitions below. 138 2. Definitions 140 o Mobile Node (MN): A Mobile IPv6 Mobile Node that freely roams 141 around networks 142 o Correspondent Node (CN): A Mobile IPv6 that node corresponds with 143 a MN 144 o Home Network: The network where the MN is normally present when it 145 is not roaming 146 o Visited Network: A network which a MN uses to access Internet when 147 it is roaming 148 o Home Agent: A router on the MN's home network which provides 149 forwarding support when the MN is roaming 150 o Home Address (HoA): The MN's unicast IP address valid on its home 151 network 152 o Care-of Address (CoA): The MN's unicast IP address valid on the 153 visited network 154 o Reverse Tunneling or Bidirectional Tunneling: A mechanism used for 155 packet forwarding between the MN and its Home Agent 156 o Route Optimization: A mechanism which allows direct routing of 157 packets between a roaming MN and its CN, without having to 158 traverse the home network. 160 3. Problem Definition 162 3.1. Disclosing the Care-of Address to the Correspondent Node 164 When a Mobile IP MN roams from its home network to a visited network 165 or from one visited network to another, use of Care-of Address in 166 communication with a correspondent reveals that the MN has roamed. 167 This assumes that the correspondent is able to associate the Care-of 168 Address to Home Address, for instance by inspecting the Binding Cache 169 Entry. The Home Address itself is assumed to have been obtained by 170 whatever means (e.g., through DNS lookup). 172 3.2. Revealing the Home Address to On-lookers 174 When a Mobile IP MN roams from its home network to a visited network 175 or from one visited network to another, use of Home Address in 176 communication reveals to an on-looker that the MN has roamed. When a 177 binding of Home Address to a user identifier (such as a SIP URI) is 178 available, the Home Address can be used to also determine that the 179 user has roamed. This problem is independent of whether the MN uses 180 Care-of Address to communicate directly with the correspondent (i.e., 181 uses route optimization), or the MN communicates via the Home Agent 182 (i.e., uses reverse tunneling). Location privacy can be compromised 183 when an on-looker is present on the MN - CN path (when route 184 optimization is used). It may also be compromised when the on-looker 185 is present on the MN - HA path (when bidirectional tunneling without 186 encryption is used. See below). 188 3.3. Problem Scope 190 With existing Mobile IPv6 solutions, there is some protection against 191 location privacy. If a Mobile Node uses reverse tunneling with ESP 192 encryption, then the Home Address is not revealed on the MN - HA 193 path. So, eavesdroppers on the MN - HA path cannot determine 194 roaming. They could, however, still profile fields in the ESP 195 header; however, this problem is not specific to Mobile IPv6 location 196 privacy. 198 When a MN uses reverse tunneling (regardless of ESP encryption), the 199 correspondent does not have access to the Care-of Address. Hence, it 200 cannot determine that the MN has roamed. 202 Hence, the location privacy problem is particularly applicable when 203 Mobile IPv6 route optimization is used or when reverse tunneling is 204 used without protecting the inner IP packet containing the Home 205 Address. 207 4. Problem Illustration 209 This section is intended to provide an illustration of the problem 210 defined in the previous section. 212 Consider a Mobile Node at its home network. Whenever it is involved 213 in IP communication, its correspondents can see an IP address valid 214 on the home network. Elaborating further, the users involved in peer 215 - peer communication are likely to see a user-friendly identifier 216 such as a SIP URI, and the communication end-points in the IP stack 217 will see IP addresses. Users uninterested in or unaware of IP 218 communication details will not see any difference when the MN 219 acquires a new IP address. Of course any user can ``tcpdump'' or 220 ``ethereal'' a session, capture IP packets and map the MN's IP 221 address to an approximate geo-location. This mapping may reveal the 222 home location of a user, but a correspondent cannot ascertain whether 223 the user has actually roamed or not. Assessing the physical location 224 based on IP addresses has some similarities to assessing the 225 geographical location based on the area-code of a telephone number. 226 The granularity of the physical area corresponding to an IP address 227 can vary depending on how sophisticated the available tools are, how 228 often an ISP conducts its network re-numbering, etc. And, an IP 229 address cannot also guarantee that a peer is at a certain geographic 230 area due to technologies such as VPN and tunneling. 232 When the MN roams to another network, the location privacy problem 233 consists of two parts: revealing information to its correspondents 234 and to on-lookers. 236 With its correspondents, the MN can either communicate directly or 237 reverse tunnel its packets through the Home Agent. Using reverse 238 tunneling does not reveal Care-of Address of the MN, although end-to- 239 end delay may vary depending on the particular scenario. With those 240 correspondents with which it can disclose its Care-of Address ``on 241 the wire'', the MN has the option of using route-optimized 242 communication. The transport protocol still sees the Home Address 243 with route optimization. Unless the correspondent runs some packet 244 capturing utility, the user cannot see which mode (reverse tunneling 245 or route optimization) is being used, but knows that it is 246 communicating with the same peer whose URI it knows. This is similar 247 to conversing with a roaming cellphone user whose phone number, like 248 the URI, remains unchanged. 250 Regardless of whether the MN uses route optimization or reverse 251 tunneling (without ESP encryption), its Home Address is revealed in 252 data packets. When equipped with an ability to inspect packets ``on 253 the wire'', an on-looker on the MN - HA path can determine that the 254 MN has roamed and could possibly also determine that the user has 255 roamed. This could compromise the location privacy even if the MN 256 took steps to hide its roaming information from a correspondent. 258 The above description is valid regardless of whether a Home Address 259 is statically allocated or is dynamically allocated. In either case, 260 the mapping of IP address to geo-location will most likely yield 261 results with the same level of granularity. With the freely 262 available tools on the Internet, this granularity is the physical 263 address of the ISP or the organization which registers ownership of a 264 prefix chunk. Since an ISP or an organization is not, rightly, 265 required to provide a blue-print of its subnets, the granularity 266 remains fairly coarse for a mobile wireless network. However, 267 sophisticated attackers might be able to conduct site mapping and 268 obtain more fine-grained subnet information. 270 A compromise in location privacy could lead to more targetted 271 profiling of user data. An eavesdropper may specifically track the 272 traffic containing the Home Address, and monitor the movement of the 273 Mobile Node with changing Care-of Address. The profiling problem is 274 not specific to Mobile IPv6, but could be triggered by a compromise 275 in location privacy due to revealing the Home Address. A 276 correspondent may take advantage of the knowledge that a user has 277 roamed when Care-of Address is revealed, and modulate actions based 278 on such a knowledge. Such an information could cause concern to a 279 mobile user especially when the correspondent turns out be 280 untrustworthy. For these reasons, appropriate security measures on 281 the management interfaces on the MN to guard against the disclosure 282 or misuse of location information should be considered. 284 Applying existing techniques to thwart profiling may have 285 implications to Mobile IPv6 signaling performance. For instance, 286 changing the Care-of Address often would cause additional Return 287 Routability [rfc3775] and binding management signaling. And, 288 changing the Home Address often has implications on IPsec security 289 association management. Solutions should be careful in considering 290 the cost of change of either Care-of Address or Home Address on 291 signaling. 293 When roaming, a MN may treat its home network nodes as any other 294 correspondents. Reverse tunneling is perhaps sufficient for home 295 network communication, since route-optimized communication will 296 traverse the identical path. Hence, a MN can avoid revealing its 297 Care-of Address to its home network correspondents simply by using 298 reverse tunneling. The Proxy Neighbor Advertisements [rfc2461] from 299 the Home Agent could serve as hints to the home network nodes that 300 the Mobile Node is away. However, they will not be able to know the 301 Mobile Node's current point of attachment unless the MN uses route 302 optimization with them. 304 5. Conclusion 306 In this document, we have discussed the location privacy problem as 307 applicable to Mobile IPv6. The problem can be summarized as follows: 308 disclosing Care-of Address to a correspondent and revealing Home 309 Address to an on-looker can compromise the location privacy of a 310 Mobile Node, and hence that of a user. We have seen that 311 bidirectional tunneling allows a MN to protect its Care-of Address to 312 the CN. And, ESP encryption of inner IP packet allows the MN to 313 protect its Home Address from the on-lookers on the MN - HA path. 314 However, with route optimization, the MN will reveal its Care-of 315 Address to the CN. Moreover, route optimization causes the Home 316 Address to be revealed to on-lookers in the data packets as well as 317 in Mobile IPv6 signaling messages. The solutions to this problem are 318 expected to be protocol specifications assuming the existing Mobile 319 IPv6 functional entities, namely, the Mobile Node, its Home Agent and 320 the Correspondent Node. 322 6. IANA Considerations 324 There are no IANA considerations introduced by this draft. 326 7. Security Considerations 328 This document discusses the location privacy problem specific to 329 Mobile IPv6. Any solution must be able to protect (e.g., using 330 encryption) the Home Address from disclosure to on-lookers in data 331 packets when using route optimization or reverse tunneling. In 332 addition, solutions must consider protecting the Mobile IPv6 333 signaling messages from disclosing the Home Address along the MN - HA 334 and MN - CN paths. 336 Disclosing the Care-of Address is inevitable if a MN wishes to use 337 route optimization. Regardless of whether Care-of Address is an on- 338 link address of the MN on the visited link or that of a co-operating 339 proxy, mere presence of Binding Cache entry is sufficient for a CN to 340 ascertain roaming. Hence, a MN concerned with location privacy 341 should exercise prudence in determining whether to use route 342 optimization with, especially previously unacquainted, 343 correspondents. 345 The solutions should also consider the use of temporary addresses and 346 their implications on Mobile IPv6 signaling as discussed in Problem 347 Illustration. Use of IP addresses with privacy extensions [rfc3041] 348 could be especially useful for Care-of Addresses if appropriate 349 tradeoffs with Return Routability signaling are taken into account. 351 8. Acknowledgment 353 James Kempf, Qiu Ying, Sam Xia and Lakshminath Dondeti are 354 acknowledged for their review and feedback. Thanks to Jari Arkko and 355 Kilian Weniger for the last call review and for suggesting 356 improvements and text. Thanks to Sam Hartman for providing text to 357 improve the problem scope. 359 9. References 361 9.1. Normative References 363 [rfc3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 364 in IPv6", RFC 3775, June 2004, 365 . 367 9.2. Informative References 369 [draft-haddad] 370 Haddad, W. et al., "Privacy for Mobile and Multi-homed 371 Nodes: MoMiPriv Problem Statement (work in progress)", 372 October 2004. 374 [rfc1035] Mockapetris, P., "Domain names - implementation and 375 specification", RFC 1035, November 1987, 376 . 378 [rfc2396] Berners-Lee, T., Fielding, R., and L. Manister, "Uniform 379 Resource Identifiers (URI): Generic Syntax", RFC 2396, 380 August 1998, . 382 [rfc2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor 383 Discovery for IP Version 6 (IPv6)", RFC 2461, 384 December 1998, . 386 [rfc2462] Thomson, S. and T. Narten, "IPv6 Stateless Address 387 Autoconfiguration", RFC 2462, December 1998, 388 . 390 [rfc3041] Narten, T. and R. Draves, "Privacy Extensions for 391 Stateless Address Autoconfiguration in IPv6", RFC 3041, 392 January 2001, . 394 [rfc3261] Rosenberg, J. et al., "SIP: Session Initiation 395 Protocol", RFC 3261, July 2004, 396 . 398 [rfc3825] Polk, J. and J. Schnizlein, "DHCP Option for Coordinate- 399 based Location Configuration Information", RFC 3825, 400 July 2004, . 402 [rfc4301] Kent, S. and K. Seo, "Security Architecture for the 403 Internet Protocol", RFC 4301, December 2005, 404 . 406 Appendix A. Background 408 The location privacy topic is broad and often has different 409 connotations. It also spans multiple layers in the OSI reference 410 model. Besides, there are attributes beyond an IP address alone that 411 can reveal hints about location. For instance, even if a 412 correspondent is communicating with the same end-point it is used to, 413 the ``time of the day'' attribute can reveal a hint to the user. 414 Some roaming cellphone users may have noticed that their SMS messages 415 carry a timestamp of their ``home network'' timezone (for location 416 privacy or otherwise) which can reveal that the user is in a 417 different timezone when messages are sent during ``normal'' time of 418 the day. Furthermore, tools exist on the Internet which can map an 419 IP address to the physical address of an ISP or the organization 420 which owns the prefix chunk. Taking this to another step, with in- 421 built GPS receivers on IP hosts, applications can be devised to map 422 geo-locations to IP network information. Even without GPS receivers, 423 geo-location can also be obtained in environments where "Geopriv" is 424 supported, for instance as a DHCP option [rfc3825]. In summary, a 425 user's physical location can be determined or guessed with some 426 certainty and with varying levels of granularity by different means 427 even though IP addresses themselves do not inherently provide any 428 geo-location information. It is perhaps useful to bear this broad 429 scope in mind as the problem of IP address location privacy in the 430 presence of IP Mobility is addressed. 432 Author's Address 434 Rajeev Koodli 435 Nokia Research Center 436 975 Page Mill Road, 200 437 Palo Alto, CA 94304 438 USA 440 Email: rajeev.koodli@nokia.com 442 Full Copyright Statement 444 Copyright (C) The IETF Trust (2007). 446 This document is subject to the rights, licenses and restrictions 447 contained in BCP 78, and except as set forth therein, the authors 448 retain all their rights. 450 This document and the information contained herein are provided on an 451 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 452 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 453 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 454 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 455 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 456 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 458 Intellectual Property 460 The IETF takes no position regarding the validity or scope of any 461 Intellectual Property Rights or other rights that might be claimed to 462 pertain to the implementation or use of the technology described in 463 this document or the extent to which any license under such rights 464 might or might not be available; nor does it represent that it has 465 made any independent effort to identify any such rights. Information 466 on the procedures with respect to rights in RFC documents can be 467 found in BCP 78 and BCP 79. 469 Copies of IPR disclosures made to the IETF Secretariat and any 470 assurances of licenses to be made available, or the result of an 471 attempt made to obtain a general license or permission for the use of 472 such proprietary rights by implementers or users of this 473 specification can be obtained from the IETF on-line IPR repository at 474 http://www.ietf.org/ipr. 476 The IETF invites any interested party to bring to its attention any 477 copyrights, patents or patent applications, or other proprietary 478 rights that may cover technology that may be required to implement 479 this standard. Please address the information to the IETF at 480 ietf-ipr@ietf.org. 482 Acknowledgment 484 Funding for the RFC Editor function is provided by the IETF 485 Administrative Support Activity (IASA).