draft-lee-randomized-macaddr-ps-01.xml

<?xml version='1.0' encoding='utf-8'?>
<!-- This template is for creating an Internet Draft using xml2rfc,
    which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
    please see http://xml.resource.org/authoring/README.html. -->
<rfc
      xmlns:xi="http://www.w3.org/2001/XInclude"
      category="info"
      docName="draft-lee-randomized-macaddr-ps-01"
      ipr="trust200902"
      obsoletes=""
      updates=""
      submissionType="IETF"
      xml:lang="en"
      tocInclude="true"
      tocDepth="4"
      symRefs="true"
      sortRefs="true"
      version="3">
  <!-- xml2rfc v2v3 conversion 2.38.1 -->
  <!-- category values: std, bcp, info, exp, and historic
    ipr values: trust200902, noModificationTrust200902, noDerivativesTrust200902,
       or pre5378Trust200902
    you can add the attributes updates="NNNN" and obsoletes="NNNN"
    they will automatically be output with "(if approved)" -->

 <!-- ***** FRONT MATTER ***** -->

 <front>
    <!-- The abbreviated title is used in the page header - it is only necessary if the
        full title is longer than 39 characters -->

   <title abbrev="Abbreviated Title">Problem Statements for MAC Address Randomization</title>
    <seriesInfo name="Internet-Draft" value="draft-lee-randomized-macaddr-ps-01"/>
    <!-- add 'role="editor"' below for the editors if appropriate -->

   <!-- Another author who claims to be an editor -->

   <author fullname="Yiu L. Lee" initials="Y." surname="Lee">
      <organization>Comcast</organization>
      <address>
        <postal>
          <street>1800 Arch Street</street>
         <city>Philadelphia</city>
          <region>PA</region>
          <code>19103</code>
          <country>USA</country>
        </postal>
        <email>yiu_lee@comcast.com</email>
        <!-- uri and facsimile elements may also be added -->
     </address>
    </author>

    <author fullname="Jason Livingood" initials="J" surname="Livingood">
       <organization>Comcast</organization>
       <address>
         <postal>
           <street>1800 Arch Street</street>
          <city>Philadelphia</city>
           <region>PA</region>
           <code>19103</code>
           <country>USA</country>
         </postal>
         <email>jason_livingood@comcast.com</email>
         <!-- uri and facsimile elements may also be added -->
      </address>
     </author>

    <author fullname="Jason Weil" initials="J" surname="Weil">
       <organization>Charter Communications</organization>
       <address>
         <postal>
           <street/>
           <!-- Reorder these if your country does things differently -->

          <city>Orlando</city>
           <region>FL</region>
           <code/>
           <country>USA</country>
         </postal>
         <email>Jason.Weil@charter.com</email>
         <!-- uri and facsimile elements may also be added -->
      </address>
     </author>

    <date year="2020"/>
    <!-- If the month and year are both specified and are the current ones, xml2rfc will fill
        in the current day for you. If only the current year is specified, xml2rfc will fill
	 in the current day and month for you. If the year is not the current one, it is
	 necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the
	 purpose of calculating the expiry date).  With drafts it is normally sufficient to
	 specify just the year. -->

   <!-- Meta-data Declarations -->

   <area>Internet</area>
    <workgroup>Internet Engineering Task Force</workgroup>
    <!-- WG name at the upperleft corner of the doc,
        IETF is fine for individual submissions.
	 If this element is not present, the default is "Network Working Group",
        which is used by the RFC Editor as a nod to the history of the IETF. -->

   <keyword>template</keyword>
    <!-- Keywords will be incorporated into HTML output
        files in a meta tag but they have no effect on text or nroff
        output. If you submit your draft to the RFC Editor, the
        keywords will be used for the search engine. -->

   <abstract>
      <t>MAC Addresses are Link Layer addresses used in IEEE Ethernet, WiFi, and other link layer protocols.
        A MAC Address is a fixed locally unique address assigned by the Network Interface Card (NIC) 
	      manufacturer, though they may be modified by an operating system, and they enable a device to connect to a 
	      network. Due to the static nature of a MAC Address, it raises some privacy concerns that have led to 
	      randomization of MAC Addresses by operating systems. This draft documents the impacts of MAC Address 
	      randomization to existing use cases of network and application services and proposes few next steps IETF 
	      may consider working on.</t>
    </abstract>

  </front>
  <middle>
    <section numbered="true" toc="default">
      <name>Introduction</name>
      <t>A Network Interface Card (NIC) needs a locally unique address in order to connect to a network. The IEEE
      <xref target="IEEE.802-1D.1993"/> 
	      created the Media Access Control (MAC) Address for use by any IEEE 802 link layer standard protocols 
	      (e.g. Ethernet &amp; WiFi). A MAC Address is 48 bits long and is usually defined in the hardware by the 
	      NIC manufacturer. A device can have one or more MAC addresses; for example an IoT device may have a single 
	      WiFi interface and one MAC Address but a laptop may have three interfaces that encompass two wired Ethernet 
	      ports and a WiFi interface, and therefore will have three MAC addresses. MAC Addresses must be locally unique 
	    in order for communications to be sent and received by the correct devices.</t>

        <t>The device manufacturer typically assigns the MAC address to an interface.
        Unless the user or operating system modifies the MAC address, which is
        sometimes the case. Because of the static nature of the manufacturer's 
        MAC addresses, a MAC address is used for device identification 
        for a variety of operational and
        troubleshooting reasons in the LAN (e.g., home network). 
        For example, a MAC address can be used to
        determine to which device on a LAN to permit or deny access at a
        particular time of day (e.g. child's tablet may not access Internet
        after 22:00 hrs until 06:00 hrs).</t>
	    
	    <!--
        [JL suggestion - greatly simplify &amp; shorten the prior para &amp; refer mostly to IEEE specs or a summary thereof]
      -->
	    
        <t>Privacy concerns have led some operating systems developers to implement MAC Address randomization 
        [IEEE.802.11AQ]. However, this can pose problems for network and application services that rely upon 
        the manufacturer's MAC Addresses 
		or assumed that MAC Addresses would not be limitlessly randomized. Many network and application services 
		today rely upon a persistent MAC Address to uniquely identify a device. For example: "Sticky" DHCP assignment 
		can enable a device to retain the same IP address for an extended time and this often maps IP to MAC 
		address. Broken sticky MAC address to IP assignment will break some local network policies such as persistent 
    network address port translation (NAPT) 
		port-forwarding, demilitarized zone setup (DMZ, or safe zone) and LAN Quality of Service (QoS), application 
		of security policies (i.e. IoT devices have one firewall policy while tablets have another), parental controls 
		(e.g. device X belongs to child 1 &amp; access to the network is not permitted between 22:00-06:00 hours) are all 
		typically based on persistent MAC Address for device identification. There are also business policies that have depended upon 
		persistent MAC address such as hospitality Internet service used in hotels, airplanes, and community WiFi 
		often uses MAC address to tie to Internet subscription (e.g. after initial authorization the MAC Address 
		is added to the allow list &amp; subsequent authorization on every new connection is unnecessary).</t>

	<t>Thus, many network and application services have developed over many years that are dependent upon persistent 
		MAC Addresses. This could be in tension with the move of major operating systems to deploy MAC Address 
		randomization. As a result, network and application services on which end users have grown to depend upon 
		will break. We are interested in determining if there is sufficient interest in the IETF community to define 
		best practices and potentially a new protocol or methods for service continuity in the presence of 
		MAC Address randomization and/or recommendations for how to implement that randomization while not 
		negatively impacting network and application services desired by end users.</t>    
	    
	    

      <section numbered="true" toc="default">
        <name>Requirements Language</name>
        <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
       "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
       document are to be interpreted as described in <xref target="RFC2119"
       format="default">RFC 2119</xref>.</t>
      </section>
    </section>


    <!-- This PI places the pagebreak correctly (before the section title) in the text output. -->

    <section numbered="true" toc="default">
      <name>Problem Statement</name>

        <t>Recently, privacy concerns have been raised related to persistent (static) MAC Addresses. In 
		particular, the privacy security communities worry about the risks associated with being able to 
		associate a MAC Address to a particular device and/or person (refs needed). While networks and application 
		have long used MAC Addresses to enable end user services, the concern that this may be abused such as for 
		data monetization purposed led to the development of techniques to randomize MAC Addresses (though 
		some research disputes the efficacy of that, ref needed). </t>
	    
	    <t>MAC Address randomization is a technique similar to IPv6 temporary IIDs defined in <xref target="RFC7217"/>. 
      Devices will auto-generate the MAC Address based on the device policy and use 
		    the random generated MAC Address instead of the hardware based MAC Address assigned by the manufacturer 
		    when they connect to the network. Many modern Operation Systems such as Apple iOS 
		    (https://support.apple.com/en-us/HT211227), Google Android 
		    (https://source.android.com/devices/tech/connect/wifi-mac-randomization) and Microsoft Windows 10 
		    (https://support.microsoft.com/en-us/help/4027925/windows-how-and-why-to-use-random-hardware-addresses) 
		    are experimenting with MAC Address randomization. The randomization policy could be time based, network 
		    based, a combination of both or involve other factors. MAC Address randomization may be one of many 
		    tactics to protect end user privacy but it can also break some network and application services that 
		    make assumptions about the persistence of MAC Address when they were designed and developed.</t>

        <t>There are perhaps some use cases in which a balance between persistence and randomization may be found. In 
		some circumstances, users may want to give a trusted network
          (e.g., home network) some predictability of the MAC Address in order to enable some
          important and valuable to end user services. This document defines a set of problem statements to continue
          the existing network and application services when MAC Addresses are randomized. These are defined by "PS" for 
		Problem Statement below:</t>

        <t>[PS-01] An Internet Service Provider (ISP) or other network operator must not make any assumption
          about the persistence of MAC Addresses.</t>
        <t>[PS-02] An ISP or other network operator must not make any assumption of the Randomization
            Policy for MAC Addresses.</t>
        <t>[PS-03] LAN policies must not depend upon a fixed, persistent MAC Address.</t>
        <t>[PS-04] A mechanism must be defined to securely identify a device.
          The mechanism can leverage existing protocols (e.g., EAP) or a newly
          defined protocol.</t>
        <t>[PS-05] ISP or other network operators, device manufacturers, and operating system developers may 
		leverage existing protocols or define a new
          mechanism to exchange information about MAC Address randomization.</t>

    </section>

   <section anchor="IANA" numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>This memo includes no request to IANA.</t>
      <t>All drafts are required to have an IANA considerations section (see
     <xref target="RFC5226" format="default">Guidelines for Writing an IANA Considerations Section in RFCs</xref> for a guide). If the draft does not require IANA to do
     anything, the section contains an explicit statement that this is the
     case (as above). If there are no requirements for IANA, the section will
     be removed during conversion into an RFC by the RFC Editor.</t>
    </section>
    <section anchor="Security" numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>All drafts are required to have a security considerations section.
     See <xref target="RFC3552" format="default">RFC 3552</xref> for a guide.</t>
    </section>
  </middle>
  <!--  *****BACK MATTER ***** -->

 <back>
    <!-- References split into informative and normative -->

   <!-- There are 2 ways to insert reference entries from the citation libraries:
    1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (as shown)
    2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here
       (for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")

    Both are cited textually in the same manner: by using xref elements.
    If you use the PI option, xml2rfc will, by default, try to find included files in the same
    directory as the including file. You can also define the XML_LIBRARY environment variable
    with a value containing a set of directories to search.  These can be either in the local
    filing system or remote ones accessed by http (http://domain/dir/... ).-->

    <references title="Normative References">
      <?rfc include="reference.RFC.2119.xml" ?>
      <?rfc include="reference.RFC.3552.xml" ?>
      <?rfc include="reference.RFC.5226.xml" ?>
   </references>

   <references title="Informative References">
     <?rfc include="reference.RFC.7217.xml" ?>
     <?rfc include="reference.IEEE.802-1D.1993.xml" ?>
   </references>

    <section anchor="app-additional" numbered="true" toc="default">
      <name>Additional Stuff</name>
      <t>This becomes an Appendix.</t>
    </section>
    <!-- Change Log

v00 	2020-09-18	Initial version
v01	2020-09-XX	Update with edits suggested by JL
    -->
 </back>
</rfc>