idnits 2.17.1 draft-lee-randomized-macaddr-ps-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (22 September 2020) is 1311 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'IEEE.802.11AQ' is mentioned on line 93, but not defined == Missing Reference: 'PS-01' is mentioned on line 171, but not defined == Missing Reference: 'PS-02' is mentioned on line 174, but not defined == Missing Reference: 'PS-03' is mentioned on line 177, but not defined == Missing Reference: 'PS-04' is mentioned on line 180, but not defined == Missing Reference: 'PS-05' is mentioned on line 184, but not defined ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) Summary: 1 error (**), 0 flaws (~~), 8 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Y. Lee 3 Internet-Draft J. Livingood 4 Intended status: Informational Comcast 5 Expires: 26 March 2021 J. Weil 6 Charter Communications 7 22 September 2020 9 Problem Statements for MAC Address Randomization 10 draft-lee-randomized-macaddr-ps-01 12 Abstract 14 MAC Addresses are Link Layer addresses used in IEEE Ethernet, WiFi, 15 and other link layer protocols. A MAC Address is a fixed locally 16 unique address assigned by the Network Interface Card (NIC) 17 manufacturer, though they may be modified by an operating system, and 18 they enable a device to connect to a network. Due to the static 19 nature of a MAC Address, it raises some privacy concerns that have 20 led to randomization of MAC Addresses by operating systems. This 21 draft documents the impacts of MAC Address randomization to existing 22 use cases of network and application services and proposes few next 23 steps IETF may consider working on. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on 26 March 2021. 42 Copyright Notice 44 Copyright (c) 2020 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 49 license-info) in effect on the date of publication of this document. 50 Please review these documents carefully, as they describe your rights 51 and restrictions with respect to this document. Code Components 52 extracted from this document must include Simplified BSD License text 53 as described in Section 4.e of the Trust Legal Provisions and are 54 provided without warranty as described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 60 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4 61 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 62 4. Security Considerations . . . . . . . . . . . . . . . . . . . 5 63 5. Normative References . . . . . . . . . . . . . . . . . . . . 5 64 6. Informative References . . . . . . . . . . . . . . . . . . . 5 65 Appendix A. Additional Stuff . . . . . . . . . . . . . . . . . . 6 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 68 1. Introduction 70 A Network Interface Card (NIC) needs a locally unique address in 71 order to connect to a network. The IEEE [IEEE.802-1D.1993] created 72 the Media Access Control (MAC) Address for use by any IEEE 802 link 73 layer standard protocols (e.g. Ethernet & WiFi). A MAC Address is 74 48 bits long and is usually defined in the hardware by the NIC 75 manufacturer. A device can have one or more MAC addresses; for 76 example an IoT device may have a single WiFi interface and one MAC 77 Address but a laptop may have three interfaces that encompass two 78 wired Ethernet ports and a WiFi interface, and therefore will have 79 three MAC addresses. MAC Addresses must be locally unique in order 80 for communications to be sent and received by the correct devices. 82 The device manufacturer typically assigns the MAC address to an 83 interface. Unless the user or operating system modifies the MAC 84 address, which is sometimes the case. Because of the static nature 85 of the manufacturer's MAC addresses, a MAC address is used for device 86 identification for a variety of operational and troubleshooting 87 reasons in the LAN (e.g., home network). For example, a MAC address 88 can be used to determine to which device on a LAN to permit or deny 89 access at a particular time of day (e.g. child's tablet may not 90 access Internet after 22:00 hrs until 06:00 hrs). 92 Privacy concerns have led some operating systems developers to 93 implement MAC Address randomization [IEEE.802.11AQ]. However, this 94 can pose problems for network and application services that rely upon 95 the manufacturer's MAC Addresses or assumed that MAC Addresses would 96 not be limitlessly randomized. Many network and application services 97 today rely upon a persistent MAC Address to uniquely identify a 98 device. For example: "Sticky" DHCP assignment can enable a device to 99 retain the same IP address for an extended time and this often maps 100 IP to MAC address. Broken sticky MAC address to IP assignment will 101 break some local network policies such as persistent network address 102 port translation (NAPT) port-forwarding, demilitarized zone setup 103 (DMZ, or safe zone) and LAN Quality of Service (QoS), application of 104 security policies (i.e. IoT devices have one firewall policy while 105 tablets have another), parental controls (e.g. device X belongs to 106 child 1 & access to the network is not permitted between 22:00-06:00 107 hours) are all typically based on persistent MAC Address for device 108 identification. There are also business policies that have depended 109 upon persistent MAC address such as hospitality Internet service used 110 in hotels, airplanes, and community WiFi often uses MAC address to 111 tie to Internet subscription (e.g. after initial authorization the 112 MAC Address is added to the allow list & subsequent authorization on 113 every new connection is unnecessary). 115 Thus, many network and application services have developed over many 116 years that are dependent upon persistent MAC Addresses. This could 117 be in tension with the move of major operating systems to deploy MAC 118 Address randomization. As a result, network and application services 119 on which end users have grown to depend upon will break. We are 120 interested in determining if there is sufficient interest in the IETF 121 community to define best practices and potentially a new protocol or 122 methods for service continuity in the presence of MAC Address 123 randomization and/or recommendations for how to implement that 124 randomization while not negatively impacting network and application 125 services desired by end users. 127 1.1. Requirements Language 129 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 130 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 131 document are to be interpreted as described in RFC 2119 [RFC2119]. 133 2. Problem Statement 135 Recently, privacy concerns have been raised related to persistent 136 (static) MAC Addresses. In particular, the privacy security 137 communities worry about the risks associated with being able to 138 associate a MAC Address to a particular device and/or person (refs 139 needed). While networks and application have long used MAC Addresses 140 to enable end user services, the concern that this may be abused such 141 as for data monetization purposed led to the development of 142 techniques to randomize MAC Addresses (though some research disputes 143 the efficacy of that, ref needed). 145 MAC Address randomization is a technique similar to IPv6 temporary 146 IIDs defined in [RFC7217]. Devices will auto-generate the MAC 147 Address based on the device policy and use the random generated MAC 148 Address instead of the hardware based MAC Address assigned by the 149 manufacturer when they connect to the network. Many modern Operation 150 Systems such as Apple iOS (https://support.apple.com/en-us/HT211227), 151 Google Android (https://source.android.com/devices/tech/connect/wifi- 152 mac-randomization) and Microsoft Windows 10 153 (https://support.microsoft.com/en-us/help/4027925/windows-how-and- 154 why-to-use-random-hardware-addresses) are experimenting with MAC 155 Address randomization. The randomization policy could be time based, 156 network based, a combination of both or involve other factors. MAC 157 Address randomization may be one of many tactics to protect end user 158 privacy but it can also break some network and application services 159 that make assumptions about the persistence of MAC Address when they 160 were designed and developed. 162 There are perhaps some use cases in which a balance between 163 persistence and randomization may be found. In some circumstances, 164 users may want to give a trusted network (e.g., home network) some 165 predictability of the MAC Address in order to enable some important 166 and valuable to end user services. This document defines a set of 167 problem statements to continue the existing network and application 168 services when MAC Addresses are randomized. These are defined by 169 "PS" for Problem Statement below: 171 [PS-01] An Internet Service Provider (ISP) or other network operator 172 must not make any assumption about the persistence of MAC Addresses. 174 [PS-02] An ISP or other network operator must not make any assumption 175 of the Randomization Policy for MAC Addresses. 177 [PS-03] LAN policies must not depend upon a fixed, persistent MAC 178 Address. 180 [PS-04] A mechanism must be defined to securely identify a device. 181 The mechanism can leverage existing protocols (e.g., EAP) or a newly 182 defined protocol. 184 [PS-05] ISP or other network operators, device manufacturers, and 185 operating system developers may leverage existing protocols or define 186 a new mechanism to exchange information about MAC Address 187 randomization. 189 3. IANA Considerations 191 This memo includes no request to IANA. 193 All drafts are required to have an IANA considerations section (see 194 Guidelines for Writing an IANA Considerations Section in RFCs 195 [RFC5226] for a guide). If the draft does not require IANA to do 196 anything, the section contains an explicit statement that this is the 197 case (as above). If there are no requirements for IANA, the section 198 will be removed during conversion into an RFC by the RFC Editor. 200 4. Security Considerations 202 All drafts are required to have a security considerations section. 203 See RFC 3552 [RFC3552] for a guide. 205 5. Normative References 207 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 208 Requirement Levels", BCP 14, RFC 2119, 209 DOI 10.17487/RFC2119, March 1997, 210 . 212 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 213 Text on Security Considerations", BCP 72, RFC 3552, 214 DOI 10.17487/RFC3552, July 2003, 215 . 217 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 218 IANA Considerations Section in RFCs", RFC 5226, 219 DOI 10.17487/RFC5226, May 2008, 220 . 222 6. Informative References 224 [IEEE.802-1D.1993] 225 Institute of Electrical and Electronics Engineers, 226 "Information technology - Telecommunications and 227 information exchange between systems - Local area networks 228 - Media access control (MAC) bridges", IEEE Standard 229 802.1D, July 1993. 231 [RFC7217] Gont, F., "A Method for Generating Semantically Opaque 232 Interface Identifiers with IPv6 Stateless Address 233 Autoconfiguration (SLAAC)", RFC 7217, 234 DOI 10.17487/RFC7217, April 2014, 235 . 237 Appendix A. Additional Stuff 239 This becomes an Appendix. 241 Authors' Addresses 243 Yiu L. Lee 244 Comcast 245 1800 Arch Street 246 Philadelphia, PA 19103 247 United States of America 249 Email: yiu_lee@comcast.com 251 Jason Livingood 252 Comcast 253 1800 Arch Street 254 Philadelphia, PA 19103 255 United States of America 257 Email: jason_livingood@comcast.com 259 Jason Weil 260 Charter Communications 261 Orlando, FL 262 United States of America 264 Email: Jason.Weil@charter.com