Internet Engineering Task Force Y. Lee Internet-Draft J. Livingood Intended status: Informational Comcast Expires: 22 March 2021 J. Weil Charter Communications 18 September 2020 Problem Statements for MAC Address Randomization draft-lee-randomized-macaddr-ps-00 Abstract MAC address is the Link Layer address used in the Ethrenet protocol. It is usually assigned by the Network Interface Card manufacturer and being used for forwording and receiving frame. Due to the static nature of the MAC address, it raises some privacy concerns and MAC address randomization is being implemented. This draft documents the impacts of MAC address randomization to existing use cases and proposes few next steps IETF may consider to work 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 22 March 2021. Copyright Notice Copyright (c) 2020 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 (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 Lee, et al. Expires 22 March 2021 [Page 1] Internet-Draft Abbreviated Title September 2020 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 . . . . . . . . . . . . . . . . . . . . . . 3 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 4. Security Considerations . . . . . . . . . . . . . . . . . . . 4 5. Normative References . . . . . . . . . . . . . . . . . . . . 4 6. Informative References . . . . . . . . . . . . . . . . . . . 5 Appendix A. Additional Stuff . . . . . . . . . . . . . . . . . . 5 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction Ethernet protocol is the implementation of data link layer defined in the Open Systems Interconnection model (OSI). Ethernet protocol is defined in IEEE 802.1 standard and MAC address is the address used in Ethernet protocol. MAC address is 48-bit long and usually defined in the hardware. Each Ethernet interface comes with a MAC address assigned by the manufacturer. Each device has one or more MAC addresses. For example, a given IoT device may only have a single WiiFi network interface and therefore a single MAC address. In contract, a laptop may have three interfaces that encompasses two wired Ethernet ports and a WiFi interface, and therefore will have three MAC addresses. MAC address is used at the Local-Area-Network (LAN) for frame forwarding. It is locally significant in the LAN and critical LAN-to-LAN communications. 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, the MAC address follows a defined format and uses 2 parts. Those are Manufacturer ID and Interface ID. In a typical MAC address, the first 3 bytes correspond to the organization that created the device, called the Organizationally Unique Identifier (OUI). This OUI portion uniquely identifies a manufacturer, vendor, or other organization, and is assigned by the IEEE from their IEEE Registration Authority. The second 3 bytes of the MAC address, the Network Interface Controller (NIC) portion, is an identifier assigned by the manufacturer (or whatever organization was assigned the OUI). Because of how MAC addresses are constructed, a MAC address may contain information from which an actor/service on a local network can infer the type and/or manufacturer of the device, which is useful for a variety of operational and troubleshooting reasons. For example, a MAC address Lee, et al. Expires 22 March 2021 [Page 2] Internet-Draft Abbreviated Title September 2020 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). Such services often rely on a database or other method to map MAC addreses to a likely device make and model, such as using a commercial service from Fingerbank, https://fingerbank.org/about/, after which the user would then label the device (e.g. Jane's iPhone). Many networks today use MAC address to uniquely identify a device. For example: Sticky DHCP assignment often maps to MAC address. In additional, many local network policies such as port-forwarding, DMZ setup and LAN QoS are all based on MAC address. There are also business policies that are making assumptions on MAC address. For example: Hospitality Internet service used in hotels, airplanes, and Community WiFi often uses MAC address to tie to Internet subscription. Major operating systems have implemented and deployed MAC address randomization to improve device and user privacy. It is common practice on many types of networks today to use the MAC address as a form of device identification. Some examples are LAN forwarding policy, sticky DHCP IP assignments, static NAT policy and MAC address ACL for blocking malicious or unwanted devices. We are interested in determining if there is sufficient support in the IETF community to define best practices and potentially a new protocol for service continuity in the presence of MAC address randomization. 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]. 2. Problem Statement Recently, more and more privacy concerns are related to the static MAC address. In particular, security community worries about people being able to tie the MAC address to a particular device. This may enable device tracking and tracing. To address the privacy concern, MAC address randomization is developed. MAC address randomization is a technique similar to IPv6 temporary IIDs defined in RFC 7217 [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 Lee, et al. Expires 22 March 2021 [Page 3] Internet-Draft Abbreviated Title September 2020 (https://support.microsoft.com/en-us/help/4027925/windows-how-and- why-to-use-random-hardware-addresses) are experimenting MAC addresses randomization. The randomization policy could be time based, network based, combination of both and more. MAC address randomization is a important step forward to protect user privacy. However, it will break some applications that make assumptions of the MAC address. In some circumstances, users may want to give the trusted network (e.g., home network) some predictability of the MAC address for some important services. For example, whitelisting MAC address for network access. This document defines a set of problem statements to continue the existing LAN services when MAC address is randomized. [PS-01] Internet Service Provider (ISP) must not make any assumption about the MAC address [PS-02] ISP must not make any assumption of the Randomization Policy [PS-03] LAN policy must not tie to a fixed MAC address [PS-04] A mechanism must be defined to securely identify a device. The mechanism can leverage existing protocols (e.g., EAP) or newly defined protocol. [PS-05] ISP and device may leverage existing protocol 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 Lee, et al. Expires 22 March 2021 [Page 4] Internet-Draft Abbreviated Title September 2020 [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 [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 Phone: +1 215 286 5894 Email: yiu_lee@comcast.com Jason Livingood Comcast 1800 Arch Street Philadelphia, PA 19103 United States of America Phone: +1 215 286 7407 Email: jason_livingood@comcast.com Lee, et al. Expires 22 March 2021 [Page 5] Internet-Draft Abbreviated Title September 2020 Jason Weil Charter Communications Orlando, FL United States of America Email: Jason.Weil@charter.com Lee, et al. Expires 22 March 2021 [Page 6]