One document matched: draft-perkins-dmm-privacy-00.xml

<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space 
     (using these PIs as follows is recommended by the RFC Editor) -->
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="yes" ?>
<!--  ?rfc subcompact="no" ?  -->
<!-- keep one blank line between list items -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!--
==================================== 80 ========================================
==================================== 72 ================================
 -->

<rfc ipr="trust200902" docName='draft-perkins-dmm-privacy-00.txt' >
  <front>
<title abbrev="DMM Privacy">
	Privacy considerations for DMM</title>

   <author fullname="Charles E. Perkins" initials="C.E." surname="Perkins">
      <organization abbrev="Futurewei">Futurewei Inc. </organization>
      <address>
        <postal>
          <street>2330 Central Expressway</street>
          <city>Santa Clara</city>
          <code>95050</code>
          <region>CA</region>
          <country>USA</country>
        </postal>
        <phone>+1-408-330-4586</phone>
        <email>charliep@computer.org</email>
      </address>
    </author>

    <author initials="S." surname="Gundavelli" fullname="Sri Gundavelli">
       <organization>Cisco Networks</organization>
      <address>
        <postal>
	  <street>170 West Tasman Drive</street>
          <city>San Jose</city>
          <code>95134</code>
          <region>CA</region>
          <country>USA</country>
        </postal>
        <email>sgundave@cisco.com</email>
      </address>
    </author>

    <date/>  <!-- day="25" month="October" year="2010" /> -->

  <area>Internet</area>
  <workgroup>Distributed Mobility Management [dmm]</workgroup>
<keyword>Mobility</keyword>
<keyword>IPv6</keyword>
<keyword>Authentication</keyword>


<abstract>

<t>
	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.
</t>
</abstract>

</front>
<middle>
<section anchor='intro' title='Introduction'>

<t>
	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 <xref target="RFC6462"/>.
</t>

<t>
	Within the IETF, there has been a greatly increased awareness of
	how to mitigate these threats by improved protocol design
	<xref target="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.
</t>

<t>
	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 <xref target="RFC4882"/>.
</t>

<t>
	The following mechanisms are discussed.
   <list style="symbols">

    <t> Recommend implementation of pseudo-home address feature
	    <xref target="RFC5726"/>.  </t>

    <t> Source IPv6 address for data packets could be used only for the
	    lifetime of the application used for that address </t>

    <t> MPTCP may be useful for additional protection against traffic analysis
    </t>

    <t> MNID may contain confidential information.  Packets in which the MNID
	    extension contains a confidential identifer should be encrypted.</t>

    <t> MAC randomization, recent Apple announcement </t>

   </list>
</t>

</section>

<section anchor='pseudo'
	title='Pseudo-home Address'>

<t>
	Recommend consideration of using
	the pseudo-home address feature from RFC 5726<xref target="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.
</t>

</section>

<section anchor='src' title='Source IPv6 Address Utilization'>

<t>
	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 <xref target="RFC4941"/>.
</t>


</section>

<section anchor='MPTCP' title='MPTCP'>

<t>
	MPTCP <xref target="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.
</t>

</section>

<section anchor='MNID' title='MNID'>

<t>
	MNID <xref target="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.
</t>

</section>

<section anchor='MAC-rand' title='MAC Randomization'>

<t>
	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
   <xref target="apple-privacy"/>.
</t>

<t>
	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:

   <list style="symbols">

    <t> Require the MN to present a new MAC address in each access attach.  </t>

    <t> Allow MN to present multiple MAC addresses during a single attach. </t>

    <t> Handover keys and other key material should be able to deal with
	    MAC address changes. </t>

   </list>

</t>

</section>

<section anchor='non-issue' title='Non-issues'>

<t>
	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 <xref target="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.
</t>

</section>

<section anchor='sec' title='Security Considerations'>

<t>
	This document is entirely concerned with raising important
	security considerations, but does not specify any new
	protocol that may affect existing security designs.
</t>

</section>

<section anchor='iana' title='IANA Considerations'>

<t>
	This document does not suggest any IANA actions.
</t>

</section>

</middle>

<back>


<references title='Normative References'>
<?rfc include='reference.RFC.3315.xml'?>
<?rfc include='reference.RFC.4283.xml'?>
<?rfc include='reference.RFC.4285.xml'?>
<?rfc include='reference.RFC.4882.xml'?>
<?rfc include='reference.RFC.4941.xml'?>
<?rfc include='reference.RFC.5726.xml'?>
<?rfc include='reference.RFC.6275.xml'?>
<?rfc include='reference.RFC.6462.xml'?>
<?rfc include='reference.RFC.6824.xml'?>
<?rfc include='reference.RFC.6973.xml'?>
</references>

<references title="Informative References">

<reference anchor="apple-privacy"
	target="https://www.apple.com/privacy/privacy-built-in/">
  <front>
    <title> Randomized Wi-Fi Addresses </title>
    <author surname="Apple Computer">
    <organization>
    </organization>
    </author>
    <date year="2014"/>
  </front>
</reference>
</references>


</back>

</rfc>