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 draft-lee-randomized-macaddr-ps-01 Abstract 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", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 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 (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. 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 Address. 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 randomization. 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 [IEEE.802-1D.1993] 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 Comcast 1800 Arch Street Philadelphia, PA 19103 United States of America Email: yiu_lee@comcast.com Jason Livingood Comcast 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]