idnits 2.17.1 draft-ietf-mip6-location-privacy-ps-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 12. -- Found old boilerplate from RFC 3978, Section 5.5 on line 355. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 332. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 339. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 345. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. 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: ' 6. 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: ' 5. IANA Considerations' ) ** The document seems to lack an Authors' Addresses Section. ** The abstract seems to contain references ([2], [Geopriv], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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 (25 June 2006) is 6515 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? '1' on line 278 looks like a reference -- Missing reference section? '2' on line 314 looks like a reference -- Missing reference section? 'Geopriv' on line 314 looks like a reference Summary: 8 errors (**), 0 flaws (~~), 2 warnings (==), 10 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 25 June 2006 6 IP Address Location Privacy and Mobile IPv6: Problem Statement 7 draft-ietf-mip6-location-privacy-ps-02.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 six months 20 and may be updated, replaced, or obsoleted by other documents at 21 any time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt. 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 This document is a submission of the IETF MIP6 WG. Comments should be 31 directed to the MIP6 WG mailing list, mip6@ietf.org. 33 Abstract 35 In this document, we discuss Location Privacy as applicable to 36 Mobile IPv6. We document the concerns arising from revealing Home 37 Address to an on-looker and from disclosing Care of Address to a 38 correspondent. 40 Contents 42 Abstract i 44 1. Introduction 1 46 2. Problem Definition 2 47 2.1. Disclosing the Care of Address to the Correspondent Node 2 48 2.2. Revealing the Home Address to On-lookers . . . . . . . . 3 50 3. Problem Illustration 3 52 4. Conclusion 5 54 5. IANA Considerations 5 56 6. Security Considerations 5 58 7. Acknowledgment 6 60 8. Author's Address 6 62 A. Background 6 64 Intellectual Property Statement 7 66 Disclaimer of Validity 7 68 Copyright Statement 7 70 Acknowledgment 8 72 1. Introduction 74 The problems of location privacy, and privacy when using IP for 75 communication have become important. IP privacy is broadly concerned 76 with protecting user communication from unwittingly revealing 77 information that could be used to analyze and gather sensitive user 78 data. Examples include gathering data at certain vantage points, 79 collecting information related to specific traffic, and monitoring 80 (perhaps) certain populations of users for activity during specific 81 times of the day, etc. In this document, we refer to this as the 82 "profiling" problem. 84 Location privacy is concerned with the problem of revealing roaming, 85 which we define here as the process of a Mobile Node moving from one 86 network to another with or without on-going sessions. A constant 87 identifier with global scope can reveal roaming. Such a global scope 88 identifier could be a device identifier or a user identifier. Often, 89 a binding between these two identifiers is also available, e.g., 90 through DNS. The location privacy problem is particularly applicable 91 to Mobile IP where the Home Address on a visited network can reveal 92 device roaming and, together with a user identifier (such as a SIP 93 URI), can reveal user roaming. Even when the binding between a user 94 identifier and the Home Address is unavailable, freely available 95 tools on the Internet can map the Home Address to the owner of the 96 Home Prefix, which can reveal that a user from a particular ISP 97 has roamed. So, the location privacy problem is a subset of the 98 profiling problem in which revealing a globally visible identifier 99 compromises a user's location privacy. When location privacy is 100 compromised, it could lead to more targetted profiling. 102 Furthermore, a user may not wish to reveal roaming to 103 correspondent(s). In Mobile IP, this translates to the use 104 of Care of Address. As with Home Address, the Care of Address can 105 also reveal the topological location of the Mobile Node. 107 In this document, the concerns arising from the use of a globally 108 visible identifier, such as a Home Address, when roaming are 109 described. Similarly, the concerns from revealing a Care of Address 110 to a correspondent are also outlined. The solutions to these 111 problems are meant to be specified in a separate document. 113 This document is only concerned with IP Address Location Privacy in 114 the presence of IP Mobility, as applied to Mobile IPv6. It does not 115 address the overall profiling problem. Specifically, it does not 116 concern itself with MAC addresses. Some other work may address the 117 problem of profiling IP and MAC identifiers (see for instance [1]). 119 2. Problem Definition 121 2.1. Disclosing the Care of Address to the Correspondent Node 123 When a Mobile IP MN roams from its home network to a visited network 124 or from one visited network to another, use of Care of Address in 125 communication with a correspondent reveals that the MN has roamed. 126 This assumes that the correspondent is able to associate the CoA to 127 HoA, for instance by inspecting the Binding Cache Entry. The HoA 128 itself is assumed to have been obtained by whatever means (e.g., 129 through DNS lookup). 131 2.2. Revealing the Home Address to On-lookers 133 When a Mobile IP MN roams from its home network to a visited network 134 or from one visited network to another, use of Home Address in 135 communication reveals to an on-looker that the MN has roamed. When 136 a binding of Home Address to a user identifier (such as a SIP 137 URI or NAI) is available, the Home Address can be used to also 138 determine that the user has roamed. This problem is independent of 139 whether the MN uses Care of Address to communicate directly with the 140 correspondent (i.e., uses route optimization), or the MN communicates 141 via the Home Agent (i.e., uses reverse tunneling). 143 Location privacy may be compromised if an on-looker is present on 144 the MN - HA path (when bidirectional tunneling is used), or when the 145 on-looker is present on the MN and CN path (when route optimization 146 is used). 148 3. Problem Illustration 150 This section is intended to provide the overall scope under which the 151 above problems are applicable. 153 Consider a Mobile Node at its home network. Whenever it is involved 154 in IP communication, its correspondents can see an IP address valid 155 on the home network. Elaborating further, the users involved in peer 156 - peer communication are likely to see a user-friendly identifier 157 such as a SIP URI, and the communication end-points in the IP 158 stack will see IP addresses. Users uninterested in or unaware of 159 IP communication details will not see any difference when the MN 160 acquires a new IP address. Of course any user can ``tcpdump'' or 161 ``ethereal'' a session, capture IP packets and map the MN's IP 162 address to an approximate geo-location. When this mapping reveals a 163 ``home location'' of the user, the correspondent can conclude that 164 the user has not roamed. Assessing the physical location based on 165 IP addresses is similar to assessing the geographical location based 166 on the area-code of a telephone number. The granularity of the 167 physical area corresponding to an IP address can vary depending on 168 how sophisticated the available tools are, how often an ISP conducts 169 its network re-numbering, etc. 171 When the MN roams to another network, the location privacy problem 172 consists of two parts: revealing information to its correspondents 173 and to on-lookers. 175 With its correspondents, the MN can either communicate directly or 176 reverse tunnel its packets through the Home Agent. Using reverse 177 tunneling does not reveal the new IP address of the MN, although 178 end-to-end delay may vary depending on the particular scenario. The 179 difference in delay may be noticeable enough to serve as a hint to 180 the correspondent, but such a hint cannot always be used to infer 181 that the MN has roamed. With those correspondents with which it can 182 disclose its new IP address ``on the wire'', the MN has the option 183 of using route-optimized communication. The transport protocol 184 still sees the Home Address with route optimization. Unless the 185 correspondent runs some packet capturing utility, the user cannot see 186 which mode (reverse tunneling or route optimization) is being used, 187 but knows that it is communicating with the same peer whose URI it 188 knows. This is similar to conversing with a roaming cellphone user 189 whose phone number, like the URI, remains unchanged. 191 Regardless of whether the MN uses route optimization or reverse 192 tunneling, its Home Address is revealed in data packets. When 193 equipped with an ability to inspect packets ``on the wire'', an 194 on-looker can determine that the MN has roamed and could possibly 195 also determine that the user has roamed. This could compromise 196 the location privacy even if the MN took steps to hide its roaming 197 information from a correspondent. 199 The above description is valid regardless of whether a Home Address 200 is static or is dynamically allocated. In either case, the mapping 201 of IP address to geo-location will most likely yield results with 202 the same level of granularity. With the freely available tools on 203 the Internet, this granularity is the physical address of the ISP or 204 the organization which registers ownership of a prefix chunk. Since 205 an ISP or an organization is not, rightly, required to provide a 206 blue-print of its subnets, the granularity remains fairly coarse for 207 a mobile wireless network. However, sophisticated attackers might 208 be able to conduct site mapping and obtain more fine-grained subnet 209 information. 211 A compromise in location privacy could lead to more targetted 212 profiling of user data. An eavesdropper may specifically track the 213 traffic containing the Home Address, and monitor the movement of the 214 Mobile Node with changing Care of Address. The profiling problem is 215 not specific to Mobile IPv6, but could be triggered by a compromise 216 in location privacy due to revealing the Home Address. 217 A correspondent may take advantage of the knowledge that a user 218 has roamed when Care of Address is revealed, and modulate actions 219 based on such a knowledge. Such an information could cause concern 220 to a mobile user especially when the correspondent turns out be 221 untrustworthy. 223 When roaming, a MN may treat its home network nodes as any other 224 correspondents. Reverse tunneling is perhaps sufficient for home 225 network communication, since route-optimized communication will 226 traverse the identical path. Hence, a MN can avoid revealing its 227 Care of Address to its home network correspondents simply by using 228 reverse tunneling. The Proxy Neighbor Advertisements from the Home 229 Agent could serve as hints to the home network nodes that the Mobile 230 Node is away. However, they won't be able to know the Mobile Node's 231 current point of attachment unless the MN uses route optimization 232 with them. 234 Finally, it is also worthwhile to note that both the Home Address 235 and the Care of Address could be subject to profiling, just as 236 any other user traffic. However, applying existing techniques to 237 thwart profiling may have implications to Mobile IPv6 signaling 238 performance. For instance, changing the Care of Address often would 239 cause additional Return Routability and binding management signaling. 240 And, changing the Home Address often has implications on IPSec 241 security association management. These issues need to be addressed 242 in the solutions. 244 4. Conclusion 246 In this document, we have formulated the IP Location Privacy problem 247 in the presence of Mobile IPv6. The problem can be summarized as 248 follows: disclosing Care of Address to a correspondent and revealing 249 Home Address to an on-looker can compromise the location privacy of a 250 Mobile Node, and hence that of a user. Solutions to this problem are 251 expected to specifically address the use of Mobile IPv6 addresses, 252 and not other identifiers (such as MAC addresses). 254 The solutions to the location privacy problem described in this 255 document are expected to be protocol specifications assuming the 256 existing Mobile IPv6 functional entities, namely, the Mobile Node, 257 its Home Agent and the Correspondent Node. 259 5. IANA Considerations 261 There are no IANA considerations introduced by this draft. 263 6. Security Considerations 265 This document discusses location privacy because of IP mobility. 266 Solutions to provide location privacy, especially any signaling over 267 the Internet, must be secure in order to be effective. Individual 268 solutions must describe the security implications. 270 7. Acknowledgment 272 Thanks to Jari Arkko, James Kempf, Qiu Ying and Sam Xia for the 273 review and feedback. Thanks to Kilian Weniger for the last call 274 review and for suggesting improvements. 276 References 278 [1] W. Haddad and et al. Privacy for Mobile and Multi-homed Nodes: 279 MoMiPriv Problem Statement (work in progress). Internet Draft, 280 Internet Engineering Task Force, October 2004. 282 [2] J. Polk, J. Schnizlein, and M. Linsner. DHCP Option for 283 Coordinate-based Location Configuration Information. Request for 284 Comments 3825, Internet Engineering Task Force, July 2004. 286 8. Author's Address 288 Rajeev Koodli 289 Nokia Research Center 290 313 Fairchild Drive 291 Mountain View, CA 94043 USA 292 Phone: +1 650 625 2359 293 Fax: +1 650 625 2502 294 E-Mail: Rajeev.Koodli@nokia.com 296 A. Background 298 The location privacy topic is broad and often has different 299 connotations. It also spans multiple layers in the OSI reference 300 model. Besides, there are attributes beyond an IP address alone 301 that can reveal hints about location. For instance, even if a 302 correspondent is communicating with the same end-point it is used 303 to, the ``time of the day'' attribute can reveal a hint to the 304 user. Some roaming cellphone users may have noticed that their SMS 305 messages carry a timestamp of their ``home network'' timezone (for 306 location privacy or otherwise) which can reveal that the user is in 307 a different timezone when messages are sent during ``normal'' time 308 of the day. Furthermore, tools exist on the Internet which can map 309 an IP address to the physical address of an ISP or the organization 310 which owns the prefix chunk. Taking this to another step, with 311 in-built GPS receivers on IP hosts, applications can be devised 312 to map geo-locations to IP network information. Even without GPS 313 receivers, geo-location can also be obtained in environments where 314 [Geopriv] is supported, for instance as a DHCP option [2]. 316 In summary, a user's physical location can be determined or guessed 317 with some certainty and with varying levels of granularity by 318 different means even though IP addresses themselves do not inherently 319 provide any geo-location information. It is perhaps useful to bear 320 this broad scope in mind as the problem of IP address location 321 privacy in the presence of IP Mobility is addressed. 323 Intellectual Property Statement 325 The IETF takes no position regarding the validity or scope of any 326 Intellectual Property Rights or other rights that might be claimed to 327 pertain to the implementation or use of the technology described in 328 this document or the extent to which any license under such rights 329 might or might not be available; nor does it represent that it has 330 made any independent effort to identify any such rights. Information 331 on the procedures with respect to rights in RFC documents can be 332 found in BCP 78 and BCP 79. 334 Copies of IPR disclosures made to the IETF Secretariat and any 335 assurances of licenses to be made available, or the result of an 336 attempt made to obtain a general license or permission for the 337 use of such proprietary rights by implementers or users of this 338 specification can be obtained from the IETF on-line IPR repository at 339 http://www.ietf.org/ipr. 341 The IETF invites any interested party to bring to its attention any 342 copyrights, patents or patent applications, or other proprietary 343 rights that may cover technology that may be required to implement 344 this standard. Please address the information to the IETF at 345 ietf-ipr@ietf.org. 347 Disclaimer of Validity 349 This document and the information contained herein are provided 350 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 351 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 352 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 353 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 354 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 355 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 357 Copyright Statement 359 Copyright (C) The Internet Society (2006). This document is subject 360 to the rights, licenses and restrictions contained in BCP 78, and 361 except as set forth therein, the authors retain all their rights. 363 Acknowledgment 365 Funding for the RFC Editor function is currently provided by the 366 Internet Society.