idnits 2.17.1 draft-ietf-mip6-location-privacy-ps-04.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 378. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 355. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 362. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 368. ** 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 7 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 6388 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 301 looks like a reference -- Missing reference section? '2' on line 337 looks like a reference -- Missing reference section? 'Geopriv' on line 337 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-04.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. This mapping may reveal 180 the "home location" of a user, but a correspondent cannot ascertain 181 whether the user has actually roamed or not. Assessing the physical 182 location based on IP addresses has some similarities to assessing the 183 geographical location based on the area-code of a telephone number. 184 The granularity of the physical area corresponding to an IP address 185 can vary depending on how sophisticated the available tools are, how 186 often an ISP conducts its network re-numbering, etc. And, an IP 187 address cannot also guarantee that a peer is at a certain geographic 188 area due to technologies such as VPN and tunneling. 190 When the MN roams to another network, the location privacy problem 191 consists of two parts: revealing information to its correspondents 192 and to on-lookers. 194 With its correspondents, the MN can either communicate directly or 195 reverse tunnel its packets through the Home Agent. Using reverse 196 tunneling does not reveal the new IP address of the MN, although 197 end-to-end delay may vary depending on the particular scenario. With 198 those correspondents with which it can disclose its new IP address 199 ``on the wire'', the MN has the option of using route-optimized 200 communication. The transport protocol still sees the Home Address 201 with route optimization. Unless the correspondent runs some 202 packet capturing utility, the user cannot see which mode (reverse 203 tunneling or route optimization) is being used, but knows that it is 204 communicating with the same peer whose URI it knows. This is similar 205 to conversing with a roaming cellphone user whose phone number, like 206 the URI, remains unchanged. 208 Regardless of whether the MN uses route optimization or reverse 209 tunneling (without ESP encryption), its Home Address is revealed in 210 data packets. When equipped with an ability to inspect packets ``on 211 the wire'', an on-looker on the MN - HA path can determine that the 212 MN has roamed and could possibly also determine that the user has 213 roamed. This could compromise the location privacy even if the MN 214 took steps to hide its roaming information from a correspondent. 216 The above description is valid regardless of whether a Home Address 217 is statically allocated or is dynamically allocated. In either 218 case, the mapping of IP address to geo-location will most likely 219 yield results with the same level of granularity. With the freely 220 available tools on the Internet, this granularity is the physical 221 address of the ISP or the organization which registers ownership of 222 a prefix chunk. Since an ISP or an organization is not, rightly, 223 required to provide a blue-print of its subnets, the granularity 224 remains fairly coarse for a mobile wireless network. However, 225 sophisticated attackers might be able to conduct site mapping and 226 obtain more fine-grained subnet information. 228 A compromise in location privacy could lead to more targetted 229 profiling of user data. An eavesdropper may specifically track the 230 traffic containing the Home Address, and monitor the movement of the 231 Mobile Node with changing Care of Address. The profiling problem is 232 not specific to Mobile IPv6, but could be triggered by a compromise 233 in location privacy due to revealing the Home Address. 234 A correspondent may take advantage of the knowledge that a user 235 has roamed when Care of Address is revealed, and modulate actions 236 based on such a knowledge. Such an information could cause concern 237 to a mobile user especially when the correspondent turns out be 238 untrustworthy. 240 Applying existing techniques to thwart profiling may have 241 implications to Mobile IPv6 signaling performance. For instance, 242 changing the Care of Address often would cause additional Return 243 Routability and binding management signaling. And, changing the 244 Home Address often has implications on IPsec security association 245 management. Solutions should be careful in considering the cost of 246 change of either CoA or HoA on signaling. For instance, changing the 247 Care of Address often would cause additional Return Routability and 248 binding management signaling. And, changing the Home Address often 249 has implications on IPsec security association management. These 250 issues need to be addressed in the solutions These issues should be 251 addressed in the solutions. 253 When roaming, a MN may treat its home network nodes as any other 254 correspondents. Reverse tunneling is perhaps sufficient for home 255 network communication, since route-optimized communication will 256 traverse the identical path. Hence, a MN can avoid revealing its 257 Care of Address to its home network correspondents simply by using 258 reverse tunneling. The Proxy Neighbor Advertisements from the Home 259 Agent could serve as hints to the home network nodes that the Mobile 260 Node is away. However, they won't be able to know the Mobile Node's 261 current point of attachment unless the MN uses route optimization 262 with them. 264 4. Conclusion 266 In this document, we have discussed the location privacy problem 267 as applicable to Mobile IPv6. The problem can be summarized as 268 follows: disclosing Care of Address to a correspondent and revealing 269 Home Address to an on-looker can compromise the location privacy 270 of a Mobile Node, and hence that of a user. We have seen that 271 bidirectional tunneling allows a MN to protect its CoA to the CN. 272 And, ESP encryption of inner IP packet allows the MN to protect its 273 HoA from the on-lookers on the MN - HA path. 275 However, with route optimization, the MN will reveal its CoA to the 276 CN. Moreover, route optimization causes the HoA to be revealed to 277 on-lookers in the data packets as well as in Mobile IPv6 signaling 278 messages. The solutions to this problem are expected to be protocol 279 specifications assuming the existing Mobile IPv6 functional entities, 280 namely, the Mobile Node, its Home Agent and the Correspondent Node. 282 5. IANA Considerations 284 There are no IANA considerations introduced by this draft. 286 6. Security Considerations 288 This document discusses location privacy because of IP mobility. 289 Solutions to provide location privacy, especially any signaling over 290 the Internet, must be secure in order to be effective. Individual 291 solutions must describe the security implications. 293 7. Acknowledgment 295 Thanks to James Kempf, Qiu Ying and Sam Xia for the review and 296 feedback. Thanks to Jari Arkko and Kilian Weniger for the last call 297 review and for suggesting improvements and text. 299 Informative References 301 [1] W. Haddad and et al. Privacy for Mobile and Multi-homed Nodes: 302 MoMiPriv Problem Statement (work in progress). Internet Draft, 303 Internet Engineering Task Force, October 2004. 305 [2] J. Polk, J. Schnizlein, and M. Linsner. DHCP Option for 306 Coordinate-based Location Configuration Information. Request for 307 Comments 3825, Internet Engineering Task Force, July 2004. 309 8. Author's Address 311 Rajeev Koodli 312 Nokia Research Center 313 313 Fairchild Drive 314 Mountain View, CA 94043 USA 315 Phone: +1 650 625 2359 316 Fax: +1 650 625 2502 317 E-Mail: Rajeev.Koodli@nokia.com 319 A. Background 321 The location privacy topic is broad and often has different 322 connotations. It also spans multiple layers in the OSI reference 323 model. Besides, there are attributes beyond an IP address alone 324 that can reveal hints about location. For instance, even if a 325 correspondent is communicating with the same end-point it is used 326 to, the ``time of the day'' attribute can reveal a hint to the 327 user. Some roaming cellphone users may have noticed that their SMS 328 messages carry a timestamp of their ``home network'' timezone (for 329 location privacy or otherwise) which can reveal that the user is in 330 a different timezone when messages are sent during ``normal'' time 331 of the day. Furthermore, tools exist on the Internet which can map 332 an IP address to the physical address of an ISP or the organization 333 which owns the prefix chunk. Taking this to another step, with 334 in-built GPS receivers on IP hosts, applications can be devised 335 to map geo-locations to IP network information. Even without GPS 336 receivers, geo-location can also be obtained in environments where 337 [Geopriv] is supported, for instance as a DHCP option [2]. 339 In summary, a user's physical location can be determined or guessed 340 with some certainty and with varying levels of granularity by 341 different means even though IP addresses themselves do not inherently 342 provide any geo-location information. It is perhaps useful to bear 343 this broad scope in mind as the problem of IP address location 344 privacy in the presence of IP Mobility is addressed. 346 Intellectual Property Statement 348 The IETF takes no position regarding the validity or scope of any 349 Intellectual Property Rights or other rights that might be claimed to 350 pertain to the implementation or use of the technology described in 351 this document or the extent to which any license under such rights 352 might or might not be available; nor does it represent that it has 353 made any independent effort to identify any such rights. Information 354 on the procedures with respect to rights in RFC documents can be 355 found in BCP 78 and BCP 79. 357 Copies of IPR disclosures made to the IETF Secretariat and any 358 assurances of licenses to be made available, or the result of an 359 attempt made to obtain a general license or permission for the 360 use of such proprietary rights by implementers or users of this 361 specification can be obtained from the IETF on-line IPR repository at 362 http://www.ietf.org/ipr. 364 The IETF invites any interested party to bring to its attention any 365 copyrights, patents or patent applications, or other proprietary 366 rights that may cover technology that may be required to implement 367 this standard. Please address the information to the IETF at 368 ietf-ipr@ietf.org. 370 Disclaimer of Validity 372 This document and the information contained herein are provided 373 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 374 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 375 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 376 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 377 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 378 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 380 Copyright Statement 382 Copyright (C) The Internet Society (2006). This document is subject 383 to the rights, licenses and restrictions contained in BCP 78, and 384 except as set forth therein, the authors retain all their rights. 386 Acknowledgment 388 Funding for the RFC Editor function is currently provided by the 389 Internet Society.