| Distributed Mobility Management [dmm] | C. Perkins |
| Internet-Draft | Futurewei |
| Expires: April 30, 2015 | S. Gundavelli |
| Cisco Networks | |
| October 27, 2014 |
Privacy considerations for DMM
draft-perkins-dmm-privacy-00.txt
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.
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 30, 2015.
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.
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.
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.
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].
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.
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.
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].
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:
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.
This document is entirely concerned with raising important security considerations, but does not specify any new protocol that may affect existing security designs.
This document does not suggest any IANA actions.
| [apple-privacy] | Apple Computer, , "Randomized Wi-Fi Addresses", 2014. |