idnits 2.17.1 draft-ietf-mip6-location-privacy-ps-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 12. -- Found old boilerplate from RFC 3978, Section 5.5 on line 376. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 353. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 360. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 366. ** 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 == The page length should not exceed 58 lines per page, but there was 7 longer pages, the longest (page 1) being 70 lines 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. ** There are 40 instances of too long lines in the document, the longest one being 8 characters in excess of 72. ** 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 (23 October 2006) is 6366 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 299 looks like a reference -- Missing reference section? '2' on line 335 looks like a reference -- Missing reference section? 'Geopriv' on line 335 looks like a reference Summary: 9 errors (**), 0 flaws (~~), 3 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 23 October 2006 6 IP Address Location Privacy and Mobile IPv6: Problem Statement 7 draft-ietf-mip6-location-privacy-ps-03.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 49 2.3. Problem Scope . . . . . . . . . . . . . . . . . . . . . . 3 51 3. Problem Illustration 3 53 4. Conclusion 5 55 5. IANA Considerations 6 57 6. Security Considerations 6 59 7. Acknowledgment 6 61 8. Author's Address 6 63 A. Background 7 65 Intellectual Property Statement 7 67 Disclaimer of Validity 8 69 Copyright Statement 8 71 Acknowledgment 8 73 1. Introduction 75 The problems of location privacy, and privacy when using IP for 76 communication have become important. IP privacy is broadly concerned 77 with protecting user communication from unwittingly revealing 78 information that could be used to analyze and gather sensitive user 79 data. Examples include gathering data at certain vantage points, 80 collecting information related to specific traffic, and monitoring 81 (perhaps) certain populations of users for activity during specific 82 times of the day, etc. In this document, we refer to this as the 83 "profiling" problem. 85 Location privacy is concerned with the problem of revealing roaming, 86 which we define here as the process of a Mobile Node moving from one 87 network to another with or without on-going sessions. A constant 88 identifier with global scope can reveal roaming. Such a global scope 89 identifier could be a device identifier or a user identifier. Often, 90 a binding between these two identifiers is also available, e.g., 91 through DNS. The location privacy problem is particularly applicable 92 to Mobile IP where the Home Address on a visited network can reveal 93 device roaming and, together with a user identifier (such as a SIP 94 URI), can reveal user roaming. Even when the binding between a user 95 identifier and the Home Address is unavailable, freely available 96 tools on the Internet can map the Home Address to the owner of the 97 Home Prefix, which can reveal that a user from a particular ISP 98 has roamed. So, the location privacy problem is a subset of the 99 profiling problem in which revealing a globally visible identifier 100 compromises a user's location privacy. When location privacy is 101 compromised, it could lead to more targetted profiling. 103 Furthermore, a user may not wish to reveal roaming to 104 correspondent(s). In Mobile IP, this translates to the use 105 of Care of Address. As with Home Address, the Care of Address can 106 also reveal the topological location of the Mobile Node. 108 In this document, the concerns arising from the use of a globally 109 visible identifier, such as a Home Address, when roaming are 110 described. Similarly, the concerns from revealing a Care of Address 111 to a correspondent are also outlined. The solutions to these 112 problems are meant to be specified in a separate document. 114 This document is only concerned with IP Address Location Privacy in 115 the context of Mobile IPv6. It does not address the overall privacy 116 problem. For instance, it does not address privacy issues related to 117 MAC addresses or the relationship of IP and MAC addresses [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 2.3. Problem Scope 150 With existing Mobile IPv6 solutions, there is some protection against 151 location privacy. If a Mobile Node uses reverse tunneling with ESP 152 encryption, then the HoA is not revealed on the MN - HA path. So, 153 eavesdroppers on the MN - HA path cannot determine roaming. They 154 could, however, still profile fields in the ESP header; however, this 155 problem is not specific to Mobile IPv6 location privacy. 157 When a MN uses reverse tunneling (regardless of ESP encryption), 158 the correspondent does not have access to the CoA. Hence, it cannot 159 determine that the MN has roamed. 161 Hence, the location privacy problem is particularly applicable when 162 Mobile IPv6 route optimization is used or when reverse tunneling is 163 used without protecting the inner IP packet containing the HoA. 165 3. Problem Illustration 167 This section is intended to provide an illustration of the problem 168 defined in the previous section. 170 Consider a Mobile Node at its home network. Whenever it is involved 171 in IP communication, its correspondents can see an IP address valid 172 on the home network. Elaborating further, the users involved in peer 173 - peer communication are likely to see a user-friendly identifier 174 such as a SIP URI, and the communication end-points in the IP 175 stack will see IP addresses. Users uninterested in or unaware of 176 IP communication details will not see any difference when the MN 177 acquires a new IP address. Of course any user can ``tcpdump'' or 178 ``ethereal'' a session, capture IP packets and map the MN's IP 179 address to an approximate geo-location. When this mapping reveals a 180 ``home location'' of the user, the correspondent can conclude that 181 the user has not roamed. Assessing the physical location based on IP 182 addresses is similar, although there are differences, to assessing 183 the geographical location based on the area-code of a telephone 184 number. The granularity of the physical area corresponding to an IP 185 address can vary depending on how sophisticated the available tools 186 are, how often an ISP conducts its network re-numbering, etc. 188 When the MN roams to another network, the location privacy problem 189 consists of two parts: revealing information to its correspondents 190 and to on-lookers. 192 With its correspondents, the MN can either communicate directly or 193 reverse tunnel its packets through the Home Agent. Using reverse 194 tunneling does not reveal the new IP address of the MN, although 195 end-to-end delay may vary depending on the particular scenario. With 196 those correspondents with which it can disclose its new IP address 197 ``on the wire'', the MN has the option of using route-optimized 198 communication. The transport protocol still sees the Home Address 199 with route optimization. Unless the correspondent runs some 200 packet capturing utility, the user cannot see which mode (reverse 201 tunneling or route optimization) is being used, but knows that it is 202 communicating with the same peer whose URI it knows. This is similar 203 to conversing with a roaming cellphone user whose phone number, like 204 the URI, remains unchanged. 206 Regardless of whether the MN uses route optimization or reverse 207 tunneling (without ESP encryption), its Home Address is revealed in 208 data packets. When equipped with an ability to inspect packets ``on 209 the wire'', an on-looker on the MN - HA path can determine that the 210 MN has roamed and could possibly also determine that the user has 211 roamed. This could compromise the location privacy even if the MN 212 took steps to hide its roaming information from a correspondent. 214 The above description is valid regardless of whether a Home Address 215 is statically allocated or is dynamically allocated. In either 216 case, the mapping of IP address to geo-location will most likely 217 yield results with the same level of granularity. With the freely 218 available tools on the Internet, this granularity is the physical 219 address of the ISP or the organization which registers ownership of 220 a prefix chunk. Since an ISP or an organization is not, rightly, 221 required to provide a blue-print of its subnets, the granularity 222 remains fairly coarse for a mobile wireless network. However, 223 sophisticated attackers might be able to conduct site mapping and 224 obtain more fine-grained subnet information. 226 A compromise in location privacy could lead to more targetted 227 profiling of user data. An eavesdropper may specifically track the 228 traffic containing the Home Address, and monitor the movement of the 229 Mobile Node with changing Care of Address. The profiling problem is 230 not specific to Mobile IPv6, but could be triggered by a compromise 231 in location privacy due to revealing the Home Address. 232 A correspondent may take advantage of the knowledge that a user 233 has roamed when Care of Address is revealed, and modulate actions 234 based on such a knowledge. Such an information could cause concern 235 to a mobile user especially when the correspondent turns out be 236 untrustworthy. 238 Applying existing techniques to thwart profiling may have 239 implications to Mobile IPv6 signaling performance. For instance, 240 changing the Care of Address often would cause additional Return 241 Routability and binding management signaling. And, changing the 242 Home Address often has implications on IPsec security association 243 management. Solutions should be careful in considering the cost of 244 change of either CoA or HoA on signaling. For instance, changing the 245 Care of Address often would cause additional Return Routability and 246 binding management signaling. And, changing the Home Address often 247 has implications on IPsec security association management. These 248 issues need to be addressed in the solutions These issues should be 249 addressed in the solutions. 251 When roaming, a MN may treat its home network nodes as any other 252 correspondents. Reverse tunneling is perhaps sufficient for home 253 network communication, since route-optimized communication will 254 traverse the identical path. Hence, a MN can avoid revealing its 255 Care of Address to its home network correspondents simply by using 256 reverse tunneling. The Proxy Neighbor Advertisements from the Home 257 Agent could serve as hints to the home network nodes that the Mobile 258 Node is away. However, they won't be able to know the Mobile Node's 259 current point of attachment unless the MN uses route optimization 260 with them. 262 4. Conclusion 264 In this document, we have discussed the location privacy problem 265 as applicable to Mobile IPv6. The problem can be summarized as 266 follows: disclosing Care of Address to a correspondent and revealing 267 Home Address to an on-looker can compromise the location privacy 268 of a Mobile Node, and hence that of a user. We have seen that 269 bidirectional tunneling allows a MN to protect its CoA to the CN, and 270 together with ESP encryption allows the MN to protect its HoA from 271 the on-lookers on the MN - HA path. 273 However, with route optimization, the MN will reveal its CoA to the 274 CN. Moreover, the HoA is revealed to on-lookers in the data packets 275 as well as in Mobile IPv6 signaling messages. The solutions to this 276 problem are expected to be protocol specifications assuming the 277 existing Mobile IPv6 functional entities, namely, the Mobile Node, 278 its Home Agent and the Correspondent Node. 280 5. IANA Considerations 282 There are no IANA considerations introduced by this draft. 284 6. Security Considerations 286 This document discusses location privacy because of IP mobility. 287 Solutions to provide location privacy, especially any signaling over 288 the Internet, must be secure in order to be effective. Individual 289 solutions must describe the security implications. 291 7. Acknowledgment 293 Thanks to James Kempf, Qiu Ying and Sam Xia for the review and 294 feedback. Thanks to Jari Arkko and Kilian Weniger for the last call 295 review and for suggesting improvements and text. 297 References 299 [1] W. Haddad and et al. Privacy for Mobile and Multi-homed Nodes: 300 MoMiPriv Problem Statement (work in progress). Internet Draft, 301 Internet Engineering Task Force, October 2004. 303 [2] J. Polk, J. Schnizlein, and M. Linsner. DHCP Option for 304 Coordinate-based Location Configuration Information. Request for 305 Comments 3825, Internet Engineering Task Force, July 2004. 307 8. Author's Address 309 Rajeev Koodli 310 Nokia Research Center 311 313 Fairchild Drive 312 Mountain View, CA 94043 USA 313 Phone: +1 650 625 2359 314 Fax: +1 650 625 2502 315 E-Mail: Rajeev.Koodli@nokia.com 317 A. Background 319 The location privacy topic is broad and often has different 320 connotations. It also spans multiple layers in the OSI reference 321 model. Besides, there are attributes beyond an IP address alone 322 that can reveal hints about location. For instance, even if a 323 correspondent is communicating with the same end-point it is used 324 to, the ``time of the day'' attribute can reveal a hint to the 325 user. Some roaming cellphone users may have noticed that their SMS 326 messages carry a timestamp of their ``home network'' timezone (for 327 location privacy or otherwise) which can reveal that the user is in 328 a different timezone when messages are sent during ``normal'' time 329 of the day. Furthermore, tools exist on the Internet which can map 330 an IP address to the physical address of an ISP or the organization 331 which owns the prefix chunk. Taking this to another step, with 332 in-built GPS receivers on IP hosts, applications can be devised 333 to map geo-locations to IP network information. Even without GPS 334 receivers, geo-location can also be obtained in environments where 335 [Geopriv] is supported, for instance as a DHCP option [2]. 337 In summary, a user's physical location can be determined or guessed 338 with some certainty and with varying levels of granularity by 339 different means even though IP addresses themselves do not inherently 340 provide any geo-location information. It is perhaps useful to bear 341 this broad scope in mind as the problem of IP address location 342 privacy in the presence of IP Mobility is addressed. 344 Intellectual Property Statement 346 The IETF takes no position regarding the validity or scope of any 347 Intellectual Property Rights or other rights that might be claimed to 348 pertain to the implementation or use of the technology described in 349 this document or the extent to which any license under such rights 350 might or might not be available; nor does it represent that it has 351 made any independent effort to identify any such rights. Information 352 on the procedures with respect to rights in RFC documents can be 353 found in BCP 78 and BCP 79. 355 Copies of IPR disclosures made to the IETF Secretariat and any 356 assurances of licenses to be made available, or the result of an 357 attempt made to obtain a general license or permission for the 358 use of such proprietary rights by implementers or users of this 359 specification can be obtained from the IETF on-line IPR repository at 360 http://www.ietf.org/ipr. 362 The IETF invites any interested party to bring to its attention any 363 copyrights, patents or patent applications, or other proprietary 364 rights that may cover technology that may be required to implement 365 this standard. Please address the information to the IETF at 366 ietf-ipr@ietf.org. 368 Disclaimer of Validity 370 This document and the information contained herein are provided 371 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 372 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 373 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 374 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 375 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 376 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 378 Copyright Statement 380 Copyright (C) The Internet Society (2006). This document is subject 381 to the rights, licenses and restrictions contained in BCP 78, and 382 except as set forth therein, the authors retain all their rights. 384 Acknowledgment 386 Funding for the RFC Editor function is currently provided by the 387 Internet Society.