Internet DRAFT - draft-perkins-dmm-privacy
draft-perkins-dmm-privacy
Distributed Mobility Management [dmm] C. Perkins
Internet-Draft Futurewei
Expires: April 29, 2015 S. Gundavelli
Cisco Networks
October 26, 2014
Privacy considerations for DMM
draft-perkins-dmm-privacy-00.txt
Abstract
Recent events have emphasized the importance of privacy in protocol
design. This document describes ways in which DMM protocol designs
and DMM networks can reduce certain threats to privacy.
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). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on April 29, 2015.
Copyright Notice
Copyright (c) 2014 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 Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Perkins & Gundavelli Expires April 29, 2015 [Page 1]
Internet-Draft DMM Privacy October 2014
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Pseudo-home Address . . . . . . . . . . . . . . . . . . . . . 3
3. Source IPv6 Address Utilization . . . . . . . . . . . . . . . 3
4. MPTCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
5. MNID . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
6. MAC Randomization . . . . . . . . . . . . . . . . . . . . . . 3
7. Non-issues . . . . . . . . . . . . . . . . . . . . . . . . . 4
8. Security Considerations . . . . . . . . . . . . . . . . . . . 4
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 4
10.1. Normative References . . . . . . . . . . . . . . . . . . 4
10.2. Informative References . . . . . . . . . . . . . . . . . 5
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5
1. Introduction
There have been many recent disclosures about breaches of privacy,
and the all-too-frequent news stories about identity theft, credit
card services infiltrated, and other serious threats. An extensive
IAB discussion about the nature of such breaches is available
[RFC6462].
Within the IETF, there has been a greatly increased awareness of how
to mitigate these threats by improved protocol design [RFC6973]. One
major danger is the dissemination of long-lived identifiers as part
of protocol transactions. When a long-lived identifier can be
observed in such transactions with disparate applications and
servers, a history can be constructed about the person associated
with that long-lived identier. Remarkably accurate predications can
then be made about the future behavior of that person -- a clear
threat to privacy. Notably, such predictions are not at all illegal,
and yet most people would consider the ability to make such
predictions as an unwanted outcome of using IETF protocols.
Similarly, knowledge about the recent history of a person as inferred
by tracking a long-lived identifier can provide strong hints about
how to analyze the earlier actions (including personal interactions)
of that person.
This document details the mechanisms as currently understood within
mobility management protocols in order to better avoid perpetuating
potential threats to privacy within DMM. As a general rule,
trackable information in protocol messages should be avoided as much
as possible [RFC4882].
The following mechanisms are discussed.
Perkins & Gundavelli Expires April 29, 2015 [Page 2]
Internet-Draft DMM Privacy October 2014
o Recommend implementation of pseudo-home address feature [RFC5726].
o Source IPv6 address for data packets could be used only for the
lifetime of the application used for that address
o MPTCP may be useful for additional protection against traffic
analysis
o MNID may contain confidential information. Packets in which the
MNID extension contains a confidential identifer should be
encrypted.
o MAC randomization, recent Apple announcement
2. Pseudo-home Address
Recommend consideration of using the pseudo-home address feature from
RFC 5726[RFC5726]. This has the effect of reducing or eliminating
the ability to track the movement events related to a mobile node,
which otherwise might be visible to snooping devices located anywhere
between the mobile node and home agent.
3. Source IPv6 Address Utilization
Source IPv6 address for data packets could be used only for the
lifetime of the application used for that address. For this purpose,
each new address can be generated as detailed in [RFC4941].
4. MPTCP
MPTCP [RFC6824] can be used for additional protection against traffic
analysis. This can be done by spreading traffic over several
associated TCP endpoints, either randomly, or as chosen to emulate
traffic patterns for unrelated applications.
5. MNID
MNID [RFC4283] may contain confidential information. Control packets
in which the MNID extension contains a confidential identifer should
be encrypted. Alternatively, the MN-ID could be generated based on
CUI (Chargeable user identity), or some other temporary identifier.
In that way, the access network would never have access to the real
MN-ID.
6. MAC Randomization
While not under the jurisdiction of the IETF, MAC addresses are often
included within IETF protocols. For the purposes of better
protecting privacy, there has been much recent discussion about
randomization of MAC addresses. As one example, see the recent
announcement about Randomized Wi-Fi addresses by Apple Computers
[apple-privacy].
Perkins & Gundavelli Expires April 29, 2015 [Page 3]
Internet-Draft DMM Privacy October 2014
Various protocols derived from Mobile IP are designed using certain
assumptions related to the use of same MAC address. For example, LMA
looks up a MN session using the MN's MAC address. This breaks when
the MAC address changes. It is recommended that mobility management
protocols reduce or eliminate dependence on MAC addresses. Some
specific suggestions include the following:
o Require the MN to present a new MAC address in each access attach.
o Allow MN to present multiple MAC addresses during a single attach.
o Handover keys and other key material should be able to deal with
MAC address changes.
7. Non-issues
There are many cases where nonces or cookies are used for temporary
use during control signal sequences -- for instance nonces as used
with Mobile IP route optimization [RFC6275]. Insofar as these fields
are used only temporarily, they are not often useful for tracking
user movements. Even so, when the same value is used for a request
and returned in a response, a small bit of information is leaked
about the status of a protocol transaction. This may not be
important, but if so can be averted by encryption.
8. Security Considerations
This document is entirely concerned with raising important security
considerations, but does not specify any new protocol that may affect
existing security designs.
9. IANA Considerations
This document does not suggest any IANA actions.
10. References
10.1. Normative References
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC4283] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K.
Chowdhury, "Mobile Node Identifier Option for Mobile IPv6
(MIPv6)", RFC 4283, November 2005.
[RFC4285] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K.
Chowdhury, "Authentication Protocol for Mobile IPv6", RFC
4285, January 2006.
Perkins & Gundavelli Expires April 29, 2015 [Page 4]
Internet-Draft DMM Privacy October 2014
[RFC4882] Koodli, R., "IP Address Location Privacy and Mobile IPv6:
Problem Statement", RFC 4882, May 2007.
[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy
Extensions for Stateless Address Autoconfiguration in
IPv6", RFC 4941, September 2007.
[RFC5726] Qiu, Y., Zhao, F., and R. Koodli, "Mobile IPv6 Location
Privacy Solutions", RFC 5726, February 2010.
[RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support
in IPv6", RFC 6275, July 2011.
[RFC6462] Cooper, A., "Report from the Internet Privacy Workshop",
RFC 6462, January 2012.
[RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure,
"TCP Extensions for Multipath Operation with Multiple
Addresses", RFC 6824, January 2013.
[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
Morris, J., Hansen, M., and R. Smith, "Privacy
Considerations for Internet Protocols", RFC 6973, July
2013.
10.2. Informative References
[apple-privacy]
Apple Computer, , "Randomized Wi-Fi Addresses", 2014,
<https://www.apple.com/privacy/privacy-built-in/>.
Authors' Addresses
Charles E. Perkins
Futurewei Inc.
2330 Central Expressway
Santa Clara, CA 95050
USA
Phone: +1-408-330-4586
Email: charliep@computer.org
Perkins & Gundavelli Expires April 29, 2015 [Page 5]
Internet-Draft DMM Privacy October 2014
Sri Gundavelli
Cisco Networks
170 West Tasman Drive
San Jose, CA 95134
USA
Email: sgundave@cisco.com
Perkins & Gundavelli Expires April 29, 2015 [Page 6]
