Network Working Group S. Brim Internet Draft M. Linsner Intended status: Informational B. McLaughlin Expires: September 15, 2011 K. Wierenga Cisco March 14, 2011 Mobility and Privacy draft-brim-mobility-and-privacy-01.txt Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on September 15, 2011. Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Brim, et al. Expires September 10, 2011 [Page 1] Internet-Draft Mobility and Privacy March 2011 Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Abstract Choices in Internet mobility architectures may have profound effects on privacy. This draft revisits this issue, stresses its increasing importance, and makes recommendations. Table of Contents 1. Introduction...................................................2 2. The risks of Being Traceable...................................3 3. Current Guidance on Privacy....................................4 4. Basic Mobility Requirements....................................6 5. Avoid Making a Mobile Node Traceable...........................7 6. Recommendations................................................9 7. Security Considerations.......................................10 8. IANA Considerations...........................................10 9. Acknowledgements..............................................10 10. Normative References.........................................10 1. Introduction Significant steps are being taken right now to make the Internet's architecture more scalable and robust in routing, addressing, multihoming, mobility, including work on locator/identifier separation. However, since the Internet infrastructure is rapidly becoming an essential part of daily life for people around the world, our architectural changes need to take fundamental social issues and rights into account as a primary consideration. One of those is privacy, and in this case particularly privacy of end-user personal data. If we do not, we run the risk of colliding with established IETF principles (see for example [RFC3693]) as well as legal policy in many countries around the world. When the Internet was designed, IP addresses were associated with timesharing machines and not with particular users. In the 1980s it began to be likely that a device and thus an IP address would be associated with a single user. Now a single IP address is very likely to be associated with a specific human being. Meanwhile, at the top of the stack, there has been a convergence of life functions using single devices using specific addresses. A person now uses his mor her personal device and associated IP address for any activities: work, shopping, talking, exchanging mail and files, reading, listening to music, etc. Brim, et al. Expires September 15, 2011 [Page 2] Internet-Draft Mobility and Privacy March 2011 It is this convergence at both the top and bottom of the stack - to a single person per device and to many applications on that device - - that makes the social issues more and more significant in IETF work. People use the Internet for many, more personal, activities than before. The Internet needs to fulfill the obligations expected of a communications system essential to modern human society. Our lower layer protocol designs have privacy implications beyond their intended scope. 2. The risks of Being Traceable Issues with revealing geographic location are well-established elsewhere. For example the RAND review of the European Data Directive [RAND-EDPD] points out that "the interpretation of location data (e.g. which locations are visited, suggesting which shops are frequented, and which products and services are bought), may in the future permit the identification of the health, social, sexual or religious characteristics of the data subject" (section 3.3.1). The less well-known problem that this document focuses on is tracing the movement of mobile devices. Because mobile devices are used for so many things, any possibility of tracing them has significant, probably unpredictable, social implications, perhaps more so than revealing a single location. If an association can be made between a mobile device and a person at any location, if that device can be traced to a different geographic location then the association with the person can be inferred, usually correctly, even if the person believes they are anonymous at the new location. Consider scenarios such as: - You are looking for a job, interviewing at other companies over your lunch hour, but you don't want your current management to know. - You are planning a surprise gift or party for your spouse and are visiting specialty stores. - You are a journalist gathering information on a corrupt politician from sources who wish to hide that they are dealing with you. - You are infiltrating an organized crime ring and don't want them to know when you sneak in the back door of police headquarters. - You are a very famous person trying to avoid paparazzi and assassins who are able to find you sporadically. Mobility mechanisms need to take this issue into account. Obviously a mobile node must be reachable somehow, but a mobile node must be able to hide its actual movement from public view if it wishes. Brim, et al. Expires September 15, 2011 [Page 3] Internet-Draft Mobility and Privacy March 2011 3. Current Guidance on Privacy In an attempt to define what privacy means to an end-user and the Internet, we have to start narrowing down the broad definition of "the state or condition of being free from being observed or disturbed by other people." In this section we will examine a sampling of policies in various geographies to gain a sense of regulatory guidance around privacy. The data extracted from these policies will offer guidance in evaluating solution architectures and what pieces of data might be deemed a privacy risk. The Internet exists within the remit of telecommunications legislation. It beholds the Internet community to be aware of and be able to adapt to the requirements of the legislative ecosystem to which our protocols and Architectures are to be deployed. Here we will outline The European Union position as an example as it has existed for many years and has been well debated and understood globally. To be clear this is not a endorsement of specific legislation but is used merely an example of the requirements our combined work will need operate within. In October 1995 the EU introduced Directive 95/46/EC for the protection of individuals with regard to the processing of personal data. Included in Objective 1 of this directive is "fundamental rights and freedoms of natural persons, and in particular their right to privacy with respect to the processing of 'personal data'. Personal data was defined as: 'personal data' shall mean any information relating to an identified or identifiable natural person ('data subject'); an identifiable person is one who can be identified, directly or indirectly, in particular by reference to an identification number or to one or more factors specific to his physical, physiological, mental, economic, cultural or social identity; Directive 2002/58/EC included the following explicit mention of the Internet: The Internet is overturning traditional market structures by providing a common, global infrastructure for the delivery of a wide range of electronic communications services. Publicly available electronic communications services over the Internet open new Brim, et al. Expires September 15, 2011 [Page 4] Internet-Draft Mobility and Privacy March 2011 possibilities for users but also new risks for their personal data and privacy. Also explicitly mentioned is requirement for consent for a valued added service beyond the contracted communications service. "(30) Systems for the provision of electronic communications networks and services should be designed to limit the amount of personal data necessary to a strict minimum. Any activities related to the provision of the electronic communications service that go beyond the transmission of a communication and the billing thereof should be based on aggregated, traffic data that cannot be related to subscribers or users. Where such activities cannot be based on aggregated data, they should be considered as value added services for which the consent of the subscriber is required." DIRECTIVE 2009/136/EC includes in section 56 explicit mention of location "To achieve this aim, it is necessary to ensure that all fundamental rights of individuals, including the right to privacy and data protection, are safeguarded. When such devices are connected to publicly available electronic communications networks or make use of electronic communications services as a basic infrastructure, the relevant provisions of Directive 2002/58/EC (Directive on privacy and electronic communications), including those on security, traffic and location data and on confidentiality, should apply." It should be noted that the legislative framework is evolving just as society and technology is evolving. A new principle is now proposed that rather than retrofitting privacy systems should be designed with privacy in mind. In 2009 a consultative document for the EU was published which discussed the technological requirements for Privacy by Design "Technological standards should be developed and taken into consideration in the phase of system analysis by hardware and software engineers, so that difficulties in defining and specifying requirements deriving from the principle of 'privacy by design' are Brim, et al. Expires September 15, 2011 [Page 5] Internet-Draft Mobility and Privacy March 2011 minimized. Such standards may be general or specific with regard to various processing purposes and technologies. 4. Basic Mobility Requirements A mobile node may need to be reachable by others, or it may act purely as a client of Internet-based services. Even if it is purely a client, it still needs at least two things: - An authentication and authorization identifier that it can use with each access network it connects to. (Not required for open access networks.) - A Layer 3 way for its correspondents to get packets back to it. This may no longer be simple due to potential innovations in routing architecture. In addition, if the mobile node wants to be reachable as a peer or to offer services, it needs a few more things: - An identifier (or identifiers) by which the node may be found by others, and a mechanism by which this identifier can be mapped to IP addresses/locators. Examples are domain names, SIP URIs, and the corresponding services. - An IP address/locator for initially contacting the mobile node. This does not have to be associated with the mobile node's actual topological location. It can instead be associated with a rendezvous point or agent. - A mechanism for "route optimization", whereby such an agent can be eliminated from a data path between the mobile node and a correspondent. - An identifier or identifiers by which the mobile node can authenticate itself to its correspondents during initial contact, route optimization, and/or change of topological location. These identifiers can be at any layer, from 2 to 7. They can be associated with the mobile device's whole IP stack, individual transport sessions, or individual application instances. - Identifiers by which the mobile node can be referred to by third parties. If all mobile nodes are reduced to being clients only -- if they are Brim, et al. Expires September 15, 2011 [Page 6] Internet-Draft Mobility and Privacy March 2011 willing to register with servers in order to use the Internet and have others be able to reach them -- then there are fewer requirements. However, over the evolution of the Internet we have seen several times that it is not good to give up the symmetry of Internet communication and "permission-free" networking, i.e. the ability for anyone anywhere to communicate as a peer with other nodes on the Internet. For the rest of this document we assume that the IETF still wants to retain this model. Every identifier listed above has a scope in which it needs to be known, but it is only required to be known in that scope. For example, an access authentication identifier only needs to be known to the mobile node, the access network, and a trusted third party (a mobile node's home network administration, or a bank, etc.). A session identifier only needs to be known among the parties using it, but not by the access network. 5. Avoid Making a Mobile Node Traceable As a mobile node moves, if L3 or higher layer mobility mechanisms are used it will change its IP addresses/locators. The Internet already has sophisticated publicly available services for determining where a node is based on IP address alone. These mechanisms are not always precise or accurate, but they are in very many cases and even imprecise information is information. Protocol designers must assume that whatever IP address or locator a node has, it is likely that there is a service to turn that into a geographic location. The tracing problem occurs when it is possible for a third party to correlate IP addresses/locators and something unique about the mobile node. Data can be gathered either through monitoring traffic or by accessing public information. It does not have to be done continuously -- periodic snapshots can make the mobile node just as vulnerable. Once the data is gathered, the third party can search for correlations. Using identifiers for multiple purposes makes leakage of tracing information more likely. Different entities in different scopes may know different things about a mobile node or a person. Using overlapping identifiers mixes scopes and may make new, perhaps unexpected, correlations easier. For example if an access identifier such as a mobile phone's IMEI (hard-coded and not changeable, primarily used for access authentication) is also used for session continuity, or is registered in an Internet database service that is publicly accessible, changes in that device's IP addresses (and thus geographic location) can be traced. Brim, et al. Expires September 15, 2011 [Page 7] Internet-Draft Mobility and Privacy March 2011 Long-lasting identifiers make correlation easier as a device moves. They should not be used in scopes where they are not necessary. The biggest concern is if information that makes a mobile node traceable is required to be publicly available in order for the Internet to function. If it is, it can be accessed not only without the mobile node's consent but even without its knowledge, perhaps without any audit trail of who is accessing the information that could be looked at after the fact. Some architecture for mobility and/or routing and addressing described in [I-D.irtf-rrg- recommendation] assume the use of DNS or other public mapping systems. In these, the mobile node is required to publish a mapping between its identifier and its current IP addresses/locators in order to be reachable, even if a mobile node is acting purely as a client (because otherwise packets would not get back to it). This architectural assumption removes all of the mobile node's freedom of choice about how much confidentiality to preserve -- either it exposes all of its movement to all of the world or it is simply not reachable. Public information systems like DNS are not designed to support confidentiality. MIPv6's "home agent" [I-D.ietf-mext-rfc3775bis] is an example of how to avoid this problem: Contact with a mobile node is initially through a home agent, a rendezvous point for both data and control traffic. The home agent acts on behalf of the mobile node and encapsulates traffic to it. After an exchange of packets, the mobile node may decide, on its own, if it wants to reveal its topological location, and thus probably its geographic location, to the correspondent node. It controls its own location information. The decision to reveal it can be based on anything, including local policy. The principle of hiding information that can expose geographic location in both data and control planes, and deferring revealing more until the mobile node or its agent decides what it wants to do, is essential. This can be included in any mobility architecture that is designed to allow it and does not insist on exposing location to a wide audience in order to gain efficiency. The obvious way to do it is an indirection mechanism such as a home agent, but this is just one way to do it. Any way will do. Monitoring is a more subtle issue than exposure in public services, but still real, even if the mobile node is client-only. If packets contain an identifier that uniquely identifies the mobile node for some period of time, someone able to gather data on packet traffic can easily trace the mobile node's movements as the IP address/locator changes. It is not necessary for the watcher to be Brim, et al. Expires September 15, 2011 [Page 8] Internet-Draft Mobility and Privacy March 2011 able to gather this information in real time if it can access logs gathered by others. Here, approaches to the problem are more difficult to define because there is a conflict between three goals: to avoid overhead, to preserve session continuity with low delay, and to keep control over location information. Some designs such already try to find their balance. All protocol work should consider the tradeoffs with privacy and explicitly find a balance point. 6. Recommendations Members of the Internet community who are creating or reviewing proposed architectural changes, particularly in mobility but also in other areas that impinge on mobility such as routing and addressing, should consider the following points: - Architectural changes MUST avoid requiring the exposer of a mapping between any of a node's identifiers and IP addresses/locators to unknown observers. If they require exposure, they will experience a head-on collision with basic principles of the IETF and with privacy policies around the world. It will simply not be acceptable to require the loss of this much individual privacy. - An architectural proposal MAY make it possible to use public information systems to optimize traffic flow, but ideally it should do so without sacrificing privacy. If it cannot do so without sacrificing privacy, the default case built into the architecture SHOULD be to preserve privacy instead of optimizing. The reason is that most users will not change defaults, and the default be one of privacy, only moving away from it by customer choice. - If possible, information about who is gathering data about a user SHOULD be available to that user. Everyone deserves to know who is watching them. - Proposals SHOULD address the issue of loss of geographic location privacy due to monitoring of packets crossing the Internet, and find an explicit balance between conflicting goals. - Protocols SHOULD avoid using identifiers for multiple purposes. Different identifier scopes do not need to overlap. Confidentiality boundaries can be established by clearly defining limited interfaces. - Protocols SHOULD avoid using long-lasting identifiers in scopes Brim, et al. Expires September 15, 2011 [Page 9] Internet-Draft Mobility and Privacy March 2011 where they are not necessary. 7. Security Considerations In a sense this entire document is about security. 8. IANA Considerations This document makes no request of IANA Note to RFC Editor: this section may be removed on publication as an RFC. 9. Acknowledgements Thanks to many with whom we have discussed this issue in recent months. This document was prepared using 2-Word-v2.0.template.dot. 10. Normative References [I-D.ietf-mext-rfc3775bis] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support in IPv6", draft-ietf-mext-rfc3775bis-08 (work in progress), October 2010. [I-D.irtf-rrg-recommendation] Li, T., "Recommendation for a Routing Architecture", draft-irtf-rrg- recommendation-14 (work in progress), September 2010. [RAND-EDPD] Robinson, N., Graux, H., Botterman, M., and L. Valeri, "Review of the European Data Protection Directive", May 2009. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J. Polk, Brim, et al. Expires September 15, 2011 [Page 10] Internet-Draft Mobility and Privacy March 2011 "Geopriv Requirements", RFC 3693, February 2004. Authors' Addresses Scott Brim Cisco Email: scott.brim@gmail.com Marc Linsner Cisco Email: mlinsner@cisco.com Bryan McLaughlin Cisco Email: brmclaug@cisco.com KlaasWierenga Cisco Email: kwiereng@cisco.com Brim, et al. Expires September 15, 2011 [Page 11]