idnits 2.17.1 draft-ietf-mip6-location-privacy-ps-01.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 334. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 311. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 318. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 324. ** 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 (6 March 2006) is 6625 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 257 looks like a reference -- Missing reference section? '2' on line 293 looks like a reference -- Missing reference section? 'Geopriv' on line 293 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 6 March 2006 6 IP Address Location Privacy and Mobile IPv6: Problem Statement 7 draft-ietf-mip6-location-privacy-ps-01.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 . . . . . . . . . . . . . 2 48 2.2. Revealing the Home Address . . . . . . . . . . . . . . . 3 50 3. Problem Illustration 3 52 4. Conclusion 5 54 5. IANA Considerations 5 56 6. Security Considerations 5 58 7. Acknowledgment 5 60 8. Author's Address 5 62 A. Background 6 64 Intellectual Property Statement 6 66 Disclaimer of Validity 7 68 Copyright Statement 7 70 Acknowledgment 7 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 A constant identifier with global scope can reveal roaming. Such 86 a global scope identifier could be a device identifier or a user 87 identifier. Often, a binding between these two identifiers is 88 also available, e.g., through DNS. The location privacy problem 89 is particularly applicable to Mobile IP where the Home Address on 90 a visited network can reveal device roaming and, together with a 91 user identifier (such as a SIP URI), can reveal user roaming. Even 92 when the binding between a user identifier and the Home Address is 93 unavailable, freely available tools on the Internet can map the 94 Home Address to the owner of the Home Prefix, which can reveal that 95 a user from a particular ISP has roamed. So, the location privacy 96 problem is a subset of the profiling problem in which revealing a 97 globally visible identifier compromises a user's location privacy. 98 When location privacy is compromised, it could lead to more targetted 99 profiling. 101 Furthermore, a user may not wish to reveal roaming to 102 correspondent(s). In Mobile IP, this translates to the use 103 of Care of Address. 105 In this document, the concerns arising from the use of a globally 106 visible identifier, such as a Home Address, when roaming are 107 described. Similarly, the concerns from revealing a Care of Address 108 to a correspondent are also outlined. The solutions to these 109 problems are meant to be specified in a separate document. 111 This document is only concerned with IP Address Location Privacy in 112 the presence of IP Mobility, as applied to Mobile IPv6. It does not 113 address the overall profiling problem. Specifically, it does not 114 concern itself with MAC addresses. Some other work may address the 115 problem of profiling IP and MAC identifiers (see for instance [1]). 117 2. Problem Definition 119 2.1. Disclosing the Care of Address 121 When a Mobile IP MN roams from its home network to a visited network, 122 use of Care of Address in communication with a correspondent reveals 123 that the MN has roamed. This assumes that the correspondent is able 124 to associate the CoA to HoA, for instance by inspecting the Binding 125 Cache Entry. The HoA itself is assumed to have been obtained by 126 whatever means (e.g., through DNS lookup). 128 2.2. Revealing the Home Address 130 When a Mobile IP MN roams from its home network to a visited network, 131 use of Home Address in communication reveals to an on-looker that the 132 MN has roamed. When a binding of Home Address to a user identifier 133 (such as a SIP URI or NAI) is available, the Home Address can be 134 used to also determine that the user has roamed. This problem is 135 independent of whether the MN uses Care of Address to communicate 136 directly with the correspondent (i.e., uses route optimization), 137 or the MN communicates via the Home Agent (i.e., uses reverse 138 tunneling). 140 3. Problem Illustration 142 This section is intended to provide the overall scope under which the 143 above problems are applicable. 145 Consider a Mobile Node at its home network. Whenever it is involved 146 in IP communication, its correspondents can see an IP address valid 147 on the home network. Elaborating further, the users involved in peer 148 - peer communication are likely to see a user-friendly identifier 149 such as a SIP URI, and the communication end-points in the IP 150 stack will see IP addresses. Users uninterested in or unaware of 151 IP communication details will not see any difference when the MN 152 acquires a new IP address. Of course any user can ``tcpdump'' or 153 ``ethereal'' a session, capture IP packets and map the MN's IP 154 address to an approximate geo-location. When this mapping reveals a 155 ``home location'' of the user, the correspondent can conclude that 156 the user has not roamed. Assessing the physical location based on 157 IP addresses is similar to assessing the geographical location based 158 on the area-code of a telephone number. The granularity of the 159 physical area corresponding to an IP address can vary depending on 160 how sophisticated the available tools are, how often an ISP conducts 161 its network re-numbering, etc. 163 When the MN roams to another network, the location privacy problem 164 consists of two parts: revealing information to its correspondents 165 and to on-lookers. 167 With its correspondents, the MN can either communicate directly or 168 reverse tunnel its packets through the Home Agent. Using reverse 169 tunneling does not reveal the new IP address of the MN, although 170 performance may vary depending on the particular scenario. In some 171 instances, the performance difference could be noticeable enough to 172 serve as a hint to the correspondent. With those correspondents with 173 which it can disclose its new IP address ``on the wire'', the MN has 174 the option of using route-optimized communication. The transport 175 protocol still sees the Home Address with route optimization. Unless 176 the correspondent runs some packet capturing utility, the user cannot 177 see which mode (reverse tunneling or route optimization) is being 178 used, but knows that it is communicating with the same peer whose URI 179 it knows. This is similar to conversing with a roaming cellphone 180 user whose phone number, like the URI, remains unchanged. 182 Regardless of whether the MN uses route optimization or reverse 183 tunneling, its Home Address is revealed in data packets. When 184 equipped with an ability to inspect packets ``on the wire'', an 185 on-looker can determine that the MN has roamed and could possibly 186 also determine that the user has roamed. This could compromise 187 the location privacy even if the MN took steps to hide its roaming 188 information from a correspondent. 190 The above description is valid regardless of whether a Home Address 191 is static or is dynamically allocated. In either case, the mapping 192 of IP address to geo-location will most likely yield results with 193 the same level of granularity. With the freely available tools on 194 the Internet, this granularity is the physical address of the ISP or 195 the organization which registers ownership of a prefix chunk. Since 196 an ISP or an organization is not, rightly, required to provide a 197 blue-print of its subnets, the granularity remains fairly coarse for 198 a mobile wireless network. However, sophisticated attackers might 199 be able to conduct site mapping and obtain more fine-grained subnet 200 information. 202 A compromise in location privacy could lead to more targetted 203 profiling of user data. An eavesdropper may specifically track the 204 traffic containing the Home Address, and monitor the movement of the 205 Mobile Node with changing Care of Address. The profiling problem is 206 not specific to Mobile IPv6, but could be triggered by a compromise 207 in location privacy due to revealing the Home Address. 208 A correspondent may take advantage of the knowledge that a user 209 has roamed when Care of Address is revealed, and modulate actions 210 based on such a knowledge. Such an information could cause concern 211 to a mobile user especially when the correspondent turns out be 212 untrustworthy. 214 Finally, it is also worthwhile to note that both the Home Address 215 and the Care of Address could be subject to profiling, just as 216 any other user traffic. However, applying existing techniques to 217 thwart profiling may have implications to Mobile IPv6 signaling 218 performance. For instance, changing the Care of Address often would 219 cause additional Return Routability and binding management signaling. 220 And, changing the Home Address often has implications on IPSec 221 security association management. These issues need to be addressed 222 in the solutions. 224 4. Conclusion 226 In this document, we have formulated the IP Location Privacy problem 227 in the presence of Mobile IPv6. The problem can be summarized as 228 follows: disclosing Care of Address to a correspondent and revealing 229 Home Address to an on-looker can compromise the location privacy of a 230 Mobile Node, and hence that of a user. Solutions to this problem are 231 expected to specifically address the use of Mobile IPv6 addresses, 232 and not other identifiers (such as MAC addresses). 234 Perhaps it is also worthwhile to consider implications of revealing 235 roaming information to the home network itself. This problem will 236 likely have much larger implications on the Mobile IPv6 operation, 237 and may be investigated in the future versions of this document. 239 5. IANA Considerations 241 There are no IANA considerations introduced by this draft. 243 6. Security Considerations 245 This document discusses location privacy because of IP mobility. 246 Solutions to provide location privacy, especially any signaling over 247 the Internet, must be secure in order to be effective. Individual 248 solutions must describe the security implications. 250 7. Acknowledgment 252 Thanks to Jari Arkko, James Kempf and Qiu Ying for the review and 253 feedback. 255 References 257 [1] W. Haddad and et al. Privacy for Mobile and Multi-homed Nodes: 258 MoMiPriv Problem Statement (work in progress). Internet Draft, 259 Internet Engineering Task Force, October 2004. 261 [2] J. Polk, J. Schnizlein, and M. Linsner. DHCP Option for 262 Coordinate-based Location Configuration Information. Request for 263 Comments 3825, Internet Engineering Task Force, July 2004. 265 8. Author's Address 267 Rajeev Koodli 268 Nokia Research Center 269 313 Fairchild Drive 270 Mountain View, CA 94043 USA 271 Phone: +1 650 625 2359 272 Fax: +1 650 625 2502 273 E-Mail: Rajeev.Koodli@nokia.com 275 A. Background 277 The location privacy topic is broad and often has different 278 connotations. It also spans multiple layers in the OSI reference 279 model. Besides, there are attributes beyond an IP address alone 280 that can reveal hints about location. For instance, even if a 281 correspondent is communicating with the same end-point it is used 282 to, the ``time of the day'' attribute can reveal a hint to the 283 user. Some roaming cellphone users may have noticed that their SMS 284 messages carry a timestamp of their ``home network'' timezone (for 285 location privacy or otherwise) which can reveal that the user is in 286 a different timezone when messages are sent during ``normal'' time 287 of the day. Furthermore, tools exist on the Internet which can map 288 an IP address to the physical address of an ISP or the organization 289 which owns the prefix chunk. Taking this to another step, with 290 in-built GPS receivers on IP hosts, applications can be devised 291 to map geo-locations to IP network information. Even without GPS 292 receivers, geo-location can also be obtained in environments where 293 [Geopriv] is supported, for instance as a DHCP option [2]. 295 In summary, a user's physical location can be determined or guessed 296 with some certainty and with varying levels of granularity by 297 different means even though IP addresses themselves do not inherently 298 provide any geo-location information. It is perhaps useful to bear 299 this broad scope in mind as the problem of IP address location 300 privacy in the presence of IP Mobility is addressed. 302 Intellectual Property Statement 304 The IETF takes no position regarding the validity or scope of any 305 Intellectual Property Rights or other rights that might be claimed to 306 pertain to the implementation or use of the technology described in 307 this document or the extent to which any license under such rights 308 might or might not be available; nor does it represent that it has 309 made any independent effort to identify any such rights. Information 310 on the procedures with respect to rights in RFC documents can be 311 found in BCP 78 and BCP 79. 313 Copies of IPR disclosures made to the IETF Secretariat and any 314 assurances of licenses to be made available, or the result of an 315 attempt made to obtain a general license or permission for the 316 use of such proprietary rights by implementers or users of this 317 specification can be obtained from the IETF on-line IPR repository at 318 http://www.ietf.org/ipr. 320 The IETF invites any interested party to bring to its attention any 321 copyrights, patents or patent applications, or other proprietary 322 rights that may cover technology that may be required to implement 323 this standard. Please address the information to the IETF at 324 ietf-ipr@ietf.org. 326 Disclaimer of Validity 328 This document and the information contained herein are provided 329 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 330 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 331 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 332 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 333 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 334 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 336 Copyright Statement 338 Copyright (C) The Internet Society (2006). This document is subject 339 to the rights, licenses and restrictions contained in BCP 78, and 340 except as set forth therein, the authors retain all their rights. 342 Acknowledgment 344 Funding for the RFC Editor function is currently provided by the 345 Internet Society.