idnits 2.17.1 draft-brim-mobility-and-privacy-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 7. 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: ' 8. IANA Considerations' ) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 300 has weird spacing: '... or by acc...' == Line 313 has weird spacing: '...that is pub...' == Line 344 has weird spacing: '... the corre...' == Line 352 has weird spacing: '... that is ...' == Line 365 has weird spacing: '...cult to def...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (March 14, 2011) is 4793 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.irtf-rrg-recommendation' is defined on line 437, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 447, but no explicit reference was found in the text Summary: 2 errors (**), 0 flaws (~~), 9 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group S. Brim 2 Internet Draft M. Linsner 3 Intended status: Informational B. McLaughlin 4 Expires: September 15, 2011 K. Wierenga 5 Cisco 6 March 14, 2011 8 Mobility and Privacy 9 draft-brim-mobility-and-privacy-01.txt 11 Status of this Memo 13 This Internet-Draft is submitted in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six 22 months and may be updated, replaced, or obsoleted by other documents 23 at any time. It is inappropriate to use Internet-Drafts as 24 reference material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html 32 This Internet-Draft will expire on September 15, 2011. 34 Copyright Notice 36 Copyright (c) 2011 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with 44 respect to this document. Code Components extracted from this 45 document must include Simplified BSD License text as described in 46 Section 4.e of the Trust Legal Provisions and are provided without 47 warranty as described in the Simplified BSD License. 49 Abstract 51 Choices in Internet mobility architectures may have profound effects 52 on privacy. This draft revisits this issue, stresses its increasing 53 importance, and makes recommendations. 55 Table of Contents 57 1. Introduction...................................................2 58 2. The risks of Being Traceable...................................3 59 3. Current Guidance on Privacy....................................4 60 4. Basic Mobility Requirements....................................6 61 5. Avoid Making a Mobile Node Traceable...........................7 62 6. Recommendations................................................9 63 7. Security Considerations.......................................10 64 8. IANA Considerations...........................................10 65 9. Acknowledgements..............................................10 66 10. Normative References.........................................10 68 1. Introduction 70 Significant steps are being taken right now to make the Internet's 71 architecture more scalable and robust in routing, addressing, 72 multihoming, mobility, including work on locator/identifier 73 separation. However, since the Internet infrastructure is rapidly 74 becoming an essential part of daily life for people around the 75 world, our architectural changes need to take fundamental social 76 issues and rights into account as a primary consideration. One of 77 those is privacy, and in this case particularly privacy of end-user 78 personal data. If we do not, we run the risk of colliding with 79 established IETF principles (see for example [RFC3693]) as well as 80 legal policy in many countries around the world. 82 When the Internet was designed, IP addresses were associated with 83 timesharing machines and not with particular users. In the 1980s it 84 began to be likely that a device and thus an IP address would be 85 associated with a single user. Now a single IP address is very 86 likely to be associated with a specific human being. Meanwhile, at 87 the top of the stack, there has been a convergence of life functions 88 using single devices using specific addresses. A person now uses 89 his mor her personal device and associated IP address for any 90 activities: work, shopping, talking, exchanging mail and files, 91 reading, listening to music, etc. 93 It is this convergence at both the top and bottom of the stack - to 94 a single person per device and to many applications on that device - 95 - that makes the social issues more and more significant in IETF 96 work. People use the Internet for many, more personal, activities 97 than before. The Internet needs to fulfill the obligations expected 98 of a communications system essential to modern human society. Our 99 lower layer protocol designs have privacy implications beyond their 100 intended scope. 102 2. The risks of Being Traceable 104 Issues with revealing geographic location are well-established 105 elsewhere. For example the RAND review of the European Data 106 Directive [RAND-EDPD] points out that "the interpretation of 107 location data (e.g. which locations are visited, suggesting which 108 shops are frequented, and which products and services are bought), 109 may in the future permit the identification of the health, social, 110 sexual or religious characteristics of the data subject" (section 111 3.3.1). The less well-known problem that this document focuses on 112 is tracing the movement of mobile devices. Because mobile devices 113 are used for so many things, any possibility of tracing them has 114 significant, probably unpredictable, social implications, perhaps 115 more so than revealing a single location. If an association can be 116 made between a mobile device and a person at any location, if that 117 device can be traced to a different geographic location then the 118 association with the person can be inferred, usually correctly, even 119 if the person believes they are anonymous at the new location. 120 Consider scenarios such as: 122 - You are looking for a job, interviewing at other companies over 123 your lunch hour, but you don't want your current management to know. 125 - You are planning a surprise gift or party for your spouse and are 126 visiting specialty stores. 128 - You are a journalist gathering information on a corrupt politician 129 from sources who wish to hide that they are dealing with you. 131 - You are infiltrating an organized crime ring and don't want them 132 to know when you sneak in the back door of police headquarters. 134 - You are a very famous person trying to avoid paparazzi and 135 assassins who are able to find you sporadically. 137 Mobility mechanisms need to take this issue into account. Obviously 138 a mobile node must be reachable somehow, but a mobile node must be 139 able to hide its actual movement from public view if it wishes. 141 3. Current Guidance on Privacy 143 In an attempt to define what privacy means to an end-user and the 144 Internet, we have to start narrowing down the broad definition of 145 "the state or condition of being free from being observed or 146 disturbed by other people." 148 In this section we will examine a sampling of policies in various 149 geographies to gain a sense of regulatory guidance around privacy. 150 The data extracted from these policies will offer guidance in 151 evaluating solution architectures and what pieces of data might be 152 deemed a privacy risk. 154 The Internet exists within the remit of telecommunications 155 legislation. It beholds the Internet community to be aware of and 156 be able to adapt to the requirements of the legislative ecosystem to 157 which our protocols and Architectures are to be deployed. 159 Here we will outline The European Union position as an example as it 160 has existed for many years and has been well debated and understood 161 globally. To be clear this is not a endorsement of specific 162 legislation but is used merely an example of the requirements our 163 combined work will need operate within. 165 In October 1995 the EU introduced Directive 95/46/EC for the 166 protection of individuals with regard to the processing of personal 167 data. Included in Objective 1 of this directive is "fundamental 168 rights and freedoms of natural persons, and in particular their 169 right to privacy with respect to the processing of 'personal data'. 171 Personal data was defined as: 'personal data' shall mean any 172 information relating to an identified or identifiable natural person 173 ('data subject'); an identifiable person is one who can be 174 identified, directly or indirectly, in particular by reference to an 175 identification number or to one or more factors specific to his 176 physical, physiological, mental, economic, cultural or social 177 identity; 179 Directive 2002/58/EC included the following explicit mention of the 180 Internet: The Internet is overturning traditional market structures 181 by providing a common, global infrastructure for the delivery of a 182 wide range of electronic communications services. Publicly available 183 electronic communications services over the Internet open new 184 possibilities for users but also new risks for their personal data 185 and privacy. 187 Also explicitly mentioned is requirement for consent for a valued 188 added service beyond the contracted communications service. 190 "(30) Systems for the provision of electronic communications 191 networks and services should be designed to limit the amount of 192 personal data necessary to a strict minimum. Any activities related 193 to the provision of the electronic communications service that go 194 beyond the transmission of a communication and the billing thereof 195 should be based on aggregated, traffic data that cannot be related 196 to subscribers or users. Where such activities cannot be based on 197 aggregated data, they should be considered as value added services 198 for which the consent of the subscriber is required." 200 DIRECTIVE 2009/136/EC includes in section 56 explicit mention of 201 location 203 "To achieve this aim, it is necessary to ensure that all fundamental 204 rights of individuals, including the right to privacy and data 205 protection, are safeguarded. When such devices are connected to 206 publicly available electronic communications networks or make use of 207 electronic communications services as a basic infrastructure, the 208 relevant provisions of Directive 2002/58/EC (Directive on privacy 209 and electronic communications), including those on security, traffic 210 and location data and on confidentiality, should apply." 212 It should be noted that the legislative framework is evolving just 213 as society and technology is evolving. A new principle is now 214 proposed that rather than retrofitting privacy systems should be 215 designed with privacy in mind. In 2009 a consultative document for 216 the EU was published which discussed the technological requirements 217 for Privacy by Design 219 "Technological standards should be developed and taken into 220 consideration in the phase of system analysis by hardware and 221 software engineers, so that difficulties in defining and specifying 222 requirements deriving from the principle of 'privacy by design' are 223 minimized. Such standards may be general or specific with regard to 224 various processing purposes and technologies. 226 4. Basic Mobility Requirements 228 A mobile node may need to be reachable by others, or it may act 229 purely as a client of Internet-based services. Even if it is purely 230 a client, it still needs at least two things: 232 - An authentication and authorization identifier that it can use 233 with each access network it connects to. (Not required for open 234 access networks.) 236 - A Layer 3 way for its correspondents to get packets back to it. 237 This may no longer be simple due to potential innovations in routing 238 architecture. 240 In addition, if the mobile node wants to be reachable as a peer or 241 to offer services, it needs a few more things: 243 - An identifier (or identifiers) by which the node may be found by 244 others, and a mechanism by which this identifier can be mapped to IP 245 addresses/locators. Examples are domain names, SIP URIs, and the 246 corresponding services. 248 - An IP address/locator for initially contacting the mobile node. 249 This does not have to be associated with the mobile node's actual 250 topological location. It can instead be associated with a 251 rendezvous point or agent. 253 - A mechanism for "route optimization", whereby such an agent can be 254 eliminated from a data path between the mobile node and a 255 correspondent. 257 - An identifier or identifiers by which the mobile node can 258 authenticate itself to its correspondents during initial contact, 259 route optimization, and/or change of topological location. These 260 identifiers can be at any layer, from 2 to 7. They can be 261 associated with the mobile device's whole IP stack, individual 262 transport sessions, or individual application instances. 264 - Identifiers by which the mobile node can be referred to by third 265 parties. 267 If all mobile nodes are reduced to being clients only -- if they are 268 willing to register with servers in order to use the Internet and 269 have others be able to reach them -- then there are fewer 270 requirements. However, over the evolution of the Internet we have 271 seen several times that it is not good to give up the symmetry of 272 Internet communication and "permission-free" networking, i.e. the 273 ability for anyone anywhere to communicate as a peer with other 274 nodes on the Internet. For the rest of this document we assume that 275 the IETF still wants to retain this model. 277 Every identifier listed above has a scope in which it needs to be 278 known, but it is only required to be known in that scope. For 279 example, an access authentication identifier only needs to be known 280 to the mobile node, the access network, and a trusted third party (a 281 mobile node's home network administration, or a bank, etc.). A 282 session identifier only needs to be known among the parties using 283 it, but not by the access network. 285 5. Avoid Making a Mobile Node Traceable 287 As a mobile node moves, if L3 or higher layer mobility mechanisms 288 are used it will change its IP addresses/locators. The Internet 289 already has sophisticated publicly available services for 290 determining where a node is based on IP address alone. These 291 mechanisms are not always precise or accurate, but they are in very 292 many cases and even imprecise information is information. Protocol 293 designers must assume that whatever IP address or locator a node 294 has, it is likely that there is a service to turn that into a 295 geographic location. 297 The tracing problem occurs when it is possible for a third party to 298 correlate IP addresses/locators and something unique about the 299 mobile node. Data can be gathered either through monitoring traffic 300 or by accessing public information. It does not have to be done 301 continuously -- periodic snapshots can make the mobile node just as 302 vulnerable. Once the data is gathered, the third party can search 303 for correlations. 305 Using identifiers for multiple purposes makes leakage of tracing 306 information more likely. Different entities in different scopes may 307 know different things about a mobile node or a person. Using 308 overlapping identifiers mixes scopes and may make new, perhaps 309 unexpected, correlations easier. For example if an access 310 identifier such as a mobile phone's IMEI (hard-coded and not 311 changeable, primarily used for access authentication) is also used 312 for session continuity, or is registered in an Internet database 313 service that is publicly accessible, changes in that device's IP 314 addresses (and thus geographic location) can be traced. 316 Long-lasting identifiers make correlation easier as a device moves. 317 They should not be used in scopes where they are not necessary. 319 The biggest concern is if information that makes a mobile node 320 traceable is required to be publicly available in order for the 321 Internet to function. If it is, it can be accessed not only without 322 the mobile node's consent but even without its knowledge, perhaps 323 without any audit trail of who is accessing the information that 324 could be looked at after the fact. Some architecture for mobility 325 and/or routing and addressing described in [I-D.irtf-rrg- 326 recommendation] assume the use of DNS or other public mapping 327 systems. In these, the mobile node is required to publish a 328 mapping between its identifier and its current IP addresses/locators 329 in order to be reachable, even if a mobile node is acting purely as 330 a client (because otherwise packets would not get back to it). This 331 architectural assumption removes all of the mobile node's freedom of 332 choice about how much confidentiality to preserve -- either it 333 exposes all of its movement to all of the world or it is simply not 334 reachable. Public information systems like DNS are not designed to 335 support confidentiality. 337 MIPv6's "home agent" [I-D.ietf-mext-rfc3775bis] is an example of how 338 to avoid this problem: Contact with a mobile node is initially 339 through a home agent, a rendezvous point for both data and control 340 traffic. The home agent acts on behalf of the mobile node and 341 encapsulates traffic to it. After an exchange of packets, the 342 mobile node may decide, on its own, if it wants to reveal its 343 topological location, and thus probably its geographic location, to 344 the correspondent node. It controls its own location information. 345 The decision to reveal it can be based on anything, including local 346 policy. 348 The principle of hiding information that can expose geographic 349 location in both data and control planes, and deferring revealing 350 more until the mobile node or its agent decides what it wants to do, 351 is essential. This can be included in any mobility architecture 352 that is designed to allow it and does not insist on exposing 353 location to a wide audience in order to gain efficiency. The 354 obvious way to do it is an indirection mechanism such as a home 355 agent, but this is just one way to do it. Any way will do. 357 Monitoring is a more subtle issue than exposure in public services, 358 but still real, even if the mobile node is client-only. If packets 359 contain an identifier that uniquely identifies the mobile node for 360 some period of time, someone able to gather data on packet traffic 361 can easily trace the mobile node's movements as the IP 362 address/locator changes. It is not necessary for the watcher to be 363 able to gather this information in real time if it can access logs 364 gathered by others. Here, approaches to the problem are more 365 difficult to define because there is a conflict between three 366 goals: to avoid overhead, to preserve session continuity with low 367 delay, and to keep control over location information. Some designs 368 such already try to find their balance. All protocol work should 369 consider the tradeoffs with privacy and explicitly find a balance 370 point. 372 6. Recommendations 374 Members of the Internet community who are creating or reviewing 375 proposed architectural changes, particularly in mobility but also in 376 other areas that impinge on mobility such as routing and addressing, 377 should consider the following points: 379 - Architectural changes MUST avoid requiring the exposer of a 380 mapping between any of a node's identifiers and IP 381 addresses/locators to unknown observers. If they require exposure, 382 they will experience a head-on collision with basic principles of 383 the IETF and with privacy policies around the world. It will 384 simply not be acceptable to require the loss of this much individual 385 privacy. 387 - An architectural proposal MAY make it possible to use public 388 information systems to optimize traffic flow, but ideally it should 389 do so without sacrificing privacy. If it cannot do so without 390 sacrificing privacy, the default case built into the 391 architecture SHOULD be to preserve privacy instead of optimizing. 392 The reason is that most users will not change defaults, and the 393 default be one of privacy, only moving away from it by customer 394 choice. 396 - If possible, information about who is gathering data about a user 397 SHOULD be available to that user. Everyone deserves to know who is 398 watching them. 400 - Proposals SHOULD address the issue of loss of geographic location 401 privacy due to monitoring of packets crossing the Internet, and find 402 an explicit balance between conflicting goals. 404 - Protocols SHOULD avoid using identifiers for multiple purposes. 405 Different identifier scopes do not need to overlap. Confidentiality 406 boundaries can be established by clearly defining limited 407 interfaces. 409 - Protocols SHOULD avoid using long-lasting identifiers in scopes 410 where they are not necessary. 412 7. Security Considerations 414 In a sense this entire document is about security. 416 8. IANA Considerations 418 This document makes no request of IANA 420 Note to RFC Editor: this section may be removed on publication as an 421 RFC. 423 9. Acknowledgements 425 Thanks to many with whom we have discussed this issue in recent 426 months. 428 This document was prepared using 2-Word-v2.0.template.dot. 430 10. Normative References 432 [I-D.ietf-mext-rfc3775bis] 434 Perkins, C., Johnson, D., and J. Arkko, "Mobility Support in IPv6", 435 draft-ietf-mext-rfc3775bis-08 (work in progress), October 2010. 437 [I-D.irtf-rrg-recommendation] 439 Li, T., "Recommendation for a Routing Architecture", draft-irtf-rrg- 440 recommendation-14 (work in progress), September 2010. 442 [RAND-EDPD] 444 Robinson, N., Graux, H., Botterman, M., and L. Valeri, "Review of 445 the European Data Protection Directive", May 2009. 447 [RFC2119] 449 Bradner, S., "Key words for use in RFCs to Indicate Requirement 450 Levels", BCP 14, RFC 2119, March 1997. 452 [RFC3693] 454 Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J. Polk, 455 "Geopriv Requirements", RFC 3693, February 2004. 457 Authors' Addresses 459 Scott Brim 460 Cisco 462 Email: scott.brim@gmail.com 464 Marc Linsner 465 Cisco 467 Email: mlinsner@cisco.com 469 Bryan McLaughlin 470 Cisco 472 Email: brmclaug@cisco.com 474 KlaasWierenga 475 Cisco 477 Email: kwiereng@cisco.com