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]