[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01

Internet Engineering Task Force                                   Y. Lee
Internet-Draft                                              J. Livingood
Intended status: Informational                                   Comcast
Expires: 26 March 2021                                           J. Weil
                                                  Charter Communications
                                                       22 September 2020

            Problem Statements for MAC Address Randomization


   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.

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 https://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 26 March 2021.

Copyright Notice

   Copyright (c) 2020 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

Lee, et al.               Expires 26 March 2021                 [Page 1]

Internet-Draft              Abbreviated Title             September 2020

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3
   2.  Problem Statement . . . . . . . . . . . . . . . . . . . . . .   4
   3.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
   5.  Normative References  . . . . . . . . . . . . . . . . . . . .   5
   6.  Informative References  . . . . . . . . . . . . . . . . . . .   5
   Appendix A.  Additional Stuff . . . . . . . . . . . . . . . . . .   6
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   6

1.  Introduction

   A Network Interface Card (NIC) needs a locally unique address in
   order to connect to a network.  The IEEE [IEEE.802-1D.1993] created
   the Media Access Control (MAC) Address for use by any IEEE 802 link
   layer standard protocols (e.g.  Ethernet & 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.

   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).

   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

Lee, et al.               Expires 26 March 2021                 [Page 2]

Internet-Draft              Abbreviated Title             September 2020

   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 & 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 & subsequent authorization on
   every new connection is unnecessary).

   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.

1.1.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in RFC 2119 [RFC2119].

Lee, et al.               Expires 26 March 2021                 [Page 3]

Internet-Draft              Abbreviated Title             September 2020

2.  Problem Statement

   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).

   MAC Address randomization is a technique similar to IPv6 temporary
   IIDs defined in [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
   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.

   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:

   [PS-01] An Internet Service Provider (ISP) or other network operator
   must not make any assumption about the persistence of MAC Addresses.

   [PS-02] An ISP or other network operator must not make any assumption
   of the Randomization Policy for MAC Addresses.

   [PS-03] LAN policies must not depend upon a fixed, persistent MAC

Lee, et al.               Expires 26 March 2021                 [Page 4]

Internet-Draft              Abbreviated Title             September 2020

   [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.

   [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

3.  IANA Considerations

   This memo includes no request to IANA.

   All drafts are required to have an IANA considerations section (see
   Guidelines for Writing an IANA Considerations Section in RFCs
   [RFC5226] 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.

4.  Security Considerations

   All drafts are required to have a security considerations section.
   See RFC 3552 [RFC3552] for a guide.

5.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,

   [RFC3552]  Rescorla, E. and B. Korver, "Guidelines for Writing RFC
              Text on Security Considerations", BCP 72, RFC 3552,
              DOI 10.17487/RFC3552, July 2003,

   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", RFC 5226,
              DOI 10.17487/RFC5226, May 2008,

6.  Informative References

Lee, et al.               Expires 26 March 2021                 [Page 5]

Internet-Draft              Abbreviated Title             September 2020

              Institute of Electrical and Electronics Engineers,
              "Information technology - Telecommunications and
              information exchange between systems - Local area networks
              - Media access control (MAC) bridges", IEEE Standard
              802.1D, July 1993.

   [RFC7217]  Gont, F., "A Method for Generating Semantically Opaque
              Interface Identifiers with IPv6 Stateless Address
              Autoconfiguration (SLAAC)", RFC 7217,
              DOI 10.17487/RFC7217, April 2014,

Appendix A.  Additional Stuff

   This becomes an Appendix.

Authors' Addresses

   Yiu L. Lee
   1800 Arch Street
   Philadelphia, PA 19103
   United States of America

   Email: yiu_lee@comcast.com

   Jason Livingood
   1800 Arch Street
   Philadelphia, PA 19103
   United States of America

   Email: jason_livingood@comcast.com

   Jason Weil
   Charter Communications
   Orlando, FL
   United States of America

   Email: Jason.Weil@charter.com

Lee, et al.               Expires 26 March 2021                 [Page 6]

Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/