idnits 2.17.1 draft-henry-madinas-framework-03.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 has text resembling RFC 2119 boilerplate text. -- The document date (24 October 2021) is 907 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC3552' is defined on line 629, but no explicit reference was found in the text == Unused Reference: 'RFC5226' is defined on line 634, but no explicit reference was found in the text == Unused Reference: 'RFC5176' is defined on line 667, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) -- Obsolete informational reference (is this intentional?): RFC 4941 (Obsoleted by RFC 8981) Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force J. Henry 3 Internet-Draft Cisco Systems 4 Intended status: Informational Y. Lee 5 Expires: 27 April 2022 Comcast 6 24 October 2021 8 Randomized and Changing MAC Address Use Cases 9 draft-henry-madinas-framework-03 11 Abstract 13 To limit the association between a device traffic and its user, 14 client vendors have started implementing MAC address rotation. When 15 such rotation happens, some in-network states may break, which may 16 affect network efficiency and the user experience. At the same time, 17 devices may continue sending other stable identifiers, defeating the 18 MAC rotation purposes. This document lists various network 19 environements and a set of network services that may be affected by 20 such rotation. This document then examines settings where the user 21 experience may be affected by in-network state disruption, and 22 settings where other machine identifiers may expose the user privacy. 23 Last, this document examines solutions to maintain user privacy while 24 preserving user quality of experience and network operation 25 efficiency. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at https://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on 27 April 2022. 44 Copyright Notice 46 Copyright (c) 2021 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 51 license-info) in effect on the date of publication of this document. 52 Please review these documents carefully, as they describe your rights 53 and restrictions with respect to this document. Code Components 54 extracted from this document must include Simplified BSD License text 55 as described in Section 4.e of the Trust Legal Provisions and are 56 provided without warranty as described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 62 2. MAC Address as an Identity: User vs. Device . . . . . . . . . 3 63 3. The Actors: Network Functional Entities and Human Entities . 6 64 3.1. Network Functional Entities . . . . . . . . . . . . . . . 6 65 3.2. Human-related Entities . . . . . . . . . . . . . . . . . 7 66 3.3. The Trust and the Environments . . . . . . . . . . . . . 8 67 3.4. The Purpose of Device Identification and Associated 68 Problems . . . . . . . . . . . . . . . . . . . . . . . . 10 69 3.5. Scenario Mapping Table . . . . . . . . . . . . . . . . . 12 70 3.6. Requirements Formulation . . . . . . . . . . . . . . . . 13 71 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 72 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 73 6. Normative References . . . . . . . . . . . . . . . . . . . . 14 74 7. Informative References . . . . . . . . . . . . . . . . . . . 14 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 77 1. Introduction 79 It has become easier for attackers to track the activity of a 80 personal device, particularly when traffic is sent over a wireless 81 link. Once the association between a device and its user is made, 82 identifying the device and its activity is sufficient to deduce 83 information about what the user is doing, without the user consent. 85 To reduce the risks of correlation between a device activity and its 86 owner, multiple vendors have started to implement Randomized and 87 Changing MAC addresses (RCM). With this scheme, an end-device 88 implements a different RCM over time when exchanging traffic over a 89 wireless network. By randomizing the MAC address, the association 90 between a given traffic flow and a single device is made more 91 difficult, assuming no other visible unique identifiers are in use. 93 However, such address change may affect the user experience and the 94 efficiency of legitimate network operations. For a long time, the 95 unicity of the association between a device and a MAC address was 96 assumed, despite the emergence of tools to flush out the MAC address 97 to bypass some network policies. When this association is broken, 98 elements of network communication may also break. For example, 99 sessions established between the end-device and network services may 100 be lost and packets in translation may suddenly be without clear 101 source or destination. As multiple clients implements fast-paced RCM 102 rotations, network services may be over-solicited by a small number 103 of stations that appear as many clients. 105 At the same time, some network services rely on the client station 106 providing an identifier, which can be the MAC address or another 107 value. If the client implements MAC rotation but continues sending 108 the same static identifier, then the association between a stable 109 identifier identifier and the station continues despite the RCM 110 scheme. There may be environements where such continued association 111 is desirable, but others where the user privacy has more value than 112 any continuity of network service state. 114 There is a need to enumerate services that may be affected by RCM, 115 and evaluate possible solutions to maintain both the quality of user 116 experience and network efficiency while RCM happens and user privacy 117 is reinforced. This document presents such assessment and 118 recommendations. 120 1.1. Requirements Language 122 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 123 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 124 "OPTIONAL" in this document are to be interpreted as described in BCP 125 14 RFC 2119 [RFC2119] RFC 8174 [RFC8174] when, and only when, they 126 appear in all capitals, as shown here. 128 2. MAC Address as an Identity: User vs. Device 130 Any device member of an IEEE 802 network [IEEE.802-1D.1993] includes 131 several operating layers. Among them, the Media Access Control (MAC) 132 layer defines rules to control how the device accesses the shared 133 medium. In a network where a machine can communicate with one or 134 more other machines, one such rule is that each machine needs to be 135 identified, either as the target destination of a message, or as the 136 source of a message (and thus the target destination of the answer). 137 Initially intended as a 48-bit (6 octets) value, later versions of 138 the Standard [IEEE.802.15.4P_2014] allowed this address to take an 139 extended format of 64 bits (8 octets), thus enabling a larger number 140 of MAC addresses to coexist as the 802 technologies became widely 141 adopted. 143 Regardless of the address length, different networks have different 144 needs, and several bits of the first octet are reserved for specific 145 purposes. In particular, the first bit is used to identify the 146 destination address either as an individual (bit set to 0) or a group 147 address (bit set to 1). The second bit, called the Universally or 148 Locally Administered (U/L) Address Bit, indicates whether the address 149 has been assigned by a local or universal administrator. Universally 150 administered addresses have this bit set to 0. If this bit is set to 151 1, the entire address (i.e., 48 bits) has been locally administered 152 [IEEE.802-1Y.1990] Section 5.2.1. 154 The intent of this provision is important for the present document. 155 The 802 Standard recognized that some devices may never travel and 156 thus, always attaching to the same network, would not need a globally 157 unique MAC address. To accommodate for this relaxed requirement, the 158 second bit of the MAC address first octet the MAC address format was 159 designed to express whether the address was intended to be globally 160 unique, or if significance was only local. The address allocation 161 method was not defined in the Standard in this later case, but the 162 mechanism was defined in the same clause that defined that an address 163 should be unique so as to avoid collision. 165 It is also important to note that the purpose of the Universal 166 version of the address was to avoid collisions and confusion, as any 167 machine could connect to any network, and each machine needs to 168 determine if it is the intended destination of a message or its 169 response. The same clause 5.2.1 reminds network designers and 170 operators that all potential members of a network need to have a 171 unique identifier (if they are going to coexist in the network). The 172 advantage of a universal address is that a node with such an address 173 can be attached to any Local Area Network (LAN) in the world with an 174 assurance that its address is unique. 176 With the rapid development of wireless technologies and mobile 177 devices, this scenario became very common. With a vast majority of 178 802 networks implementing radio technologies at the access, the MAC 179 address of a wireless device can appear anywhere on the planet and 180 collisions should still be avoided. However, the same evolution 181 brought the distinction between two types of devices that the 802 182 Standard generally referred to as 'nodes in a network'. Their 183 definition is found in the 802E Recommended Practice (clause 6.2). 184 One type is a shared service device, which functions are used by a 185 number of people large enough that the device itself, its functions 186 or its traffic cannot be associated with a single or small group of 187 people. Examples of such devices include switches in a dense 188 network, 802.11 (WLAN) access points in a crowded airport, task- 189 specific (e.g. barcode scanners) devices, etc. Another type is a 190 personal device, which is a machine, a node, primarily used by a 191 single person or small group of people, and so that any 192 identification of the device or its traffic can also be associated to 193 the identification of the primary user or their traffic. Quite 194 naturally, the unique identification of the device is trivial if the 195 device expresses a universally unique MAC address. Then, the 196 detection of elements directly or indirectly identifying the user of 197 the device (Personally Identifiable Information, or PII) is 198 sufficient to tie the universal MAC address to a user. Then, any 199 detection of traffic that can be associated to the device becomes 200 also associated with the known user of that device (Personally 201 Correlated Information, or PCI). 203 This possible identification or association presents a serious 204 privacy issue, especially with wireless technologies. For most of 205 them, and in particular for 802.11, the source and destination MAC 206 addresses are not encrypted even in networks that implement 207 encryption (so that each machine can easily detect if it is the 208 intended target of the message before attempting to decrypt its 209 content, and also identify the transmitter, so as to use the right 210 key when multiple unicast keys are in effect). 212 This unique identification of the user associated to a node was 213 clearly not the intent of the 802 MAC address. A logical solution to 214 remove this association is to use a locally administered address 215 instead, and change the address in a fashion that prevents a temporal 216 association between one MAC address and some PII to be maintained 217 fruitfully. However, other network devices on the same LAN 218 implementing a MAC layer also expect the unicity of the MAC address. 219 When a device changes its MAC address, other devices on the same LAN 220 may fail to recognize that the same machine is attempting to 221 communicate with them. Additionally, multiple layers implemented at 222 upper OSI layers have been designed with the assumption that each 223 node on the LAN, using these services, would have a unique MAC 224 address. This assumption sometimes adds to the PII confusion, for 225 example in the case of Authentication, Association and Accounting 226 (AAA) services authenticating the user of a machine and associating 227 the authenticated user to the device MAC address. Other services 228 solely focus on the machine (e.g. DHCP), but still expect each 229 device to use a single MAC address. Changing the MAC address may 230 disrupt these services. 232 3. The Actors: Network Functional Entities and Human Entities 234 The risk of service disruption is thus weighted against the privacy 235 benefits. However, the plurality of actors involved in the exchanges 236 tends to blurry the boundaries of what privacy should be protected 237 against. It might therefore be useful to list the actors to the 238 network exchanges. Some actors are functional entities, some others 239 are humans (or related) entities. 241 3.1. Network Functional Entities 243 Wireless access network infrastructure devices (e.g. WLAN access 244 points or controllers): these devices participate in 802 LAN 245 operations. As such, they need to uniquely identify machines as a 246 source or destination so as to successfully continue exchanging 247 frames. Part of the identification includes recording, and adapting 248 to, devices communication capabilities (e.g. support for specific 249 protocols). As a device changes its network attachment (roams) from 250 one access point to another, the access points can exchange 251 contextual information (e.g. device MAC, keying material) allowing 252 the device session to continue seamlessly. These access points can 253 also inform devices further in the wired network about the roam, to 254 ensure that OSI model Layer 2 frames are redirected to the new device 255 access point. 257 Other network devices operating at the MAC layer: many wireless 258 network access devices (e.g., 802.11 access points) are conceived as 259 Layer 2 devices, and as such they bridge a frame from one medium 260 (e.g., 802.11 or Wi-Fi) to another (e.g., 802.3 or Ethernet). This 261 means that a wireless device MAC address often exists on the wire 262 beyond the wireless access device. Devices connected to this wire 263 also implement 802 technologies, and as such operate on the 264 expectation that each device is associated to a unique MAC address 265 for the duration of continuous exchanges. For example, switches and 266 bridges associate MAC addresses to individual ports (so as to know 267 which port to send a frame intended for a particular MAC address). 268 Similarly, authentication, authorization and accounting (AAA) 269 services can validate the identity of a device and use the device MAC 270 address as a first pointer to the device identity (before operating 271 further verification). Similarly, some networking devices offer 272 Layer-2 filtering policies that may rely on the connected MAC 273 addresses. 802.1X-enabled devices may also selectively block the data 274 portion of a port until a connecting device is authenticated. These 275 services then use the MAC address as a first pointer to the device 276 identity to allow or block data traffic. This list is not 277 exhaustive. Multiple services are defined for 802.3 networks, and 278 multiple services defined by the IEEE 802.1 working group are also 279 applicable to 802.3 networks. Wireless access points may also 280 connect to other mediums than 802.3, which also implements mechanism 281 under the umbrella of the general 802 Standard, and therefore expect 282 the unique association of a MAC address to a device. 284 Network devices operating at upper layers: some network devices 285 provide functions and services above the MAC layer. Some of them 286 also operate a MAC layer function: for example, routers provide IP 287 forwarding services, but rely on the device MAC address to create the 288 appropriate frame structure. Other devices and services operate at 289 upper layers, but also rely upon the 802 principle of unique MAC-to- 290 device mapping. For example, DHCPv4 services commonly provide a 291 single IP address per MAC address (they do not assign more than one 292 IPv4 address per MAC address, and assign a new IPv4 address to each 293 new requesting MAC address). ARP and reverse-ARP services commonly 294 expect that, once an IP-to-MAC mapping has been established, this 295 mapping is valid and unlikely to change for the cache lifetime. 296 DHCPv6 services commonly do not assign the same IPv6 address to two 297 different requesting MAC addresses. Hybrid services, such as EoIP, 298 also assume stability of the device-to-MAC-and-IP mapping for the 299 duration of a given session. 301 3.2. Human-related Entities 303 Over the air (OTA) observers: as the transmitting or receiving MAC 304 address is usually not encrypted in wireless 802-technologies 305 exchanges, and as any protocol-compatible device in range of the 306 signal can read the frame header, OTA observers are able to read 307 individual transmissions MAC addresses. Some wireless technologies 308 also support techniques to establish distances or positions, allowing 309 the observer, in some cases, to uniquely associate the MAC address to 310 a physical device and it associated location. It can happen that an 311 OTA observer has a legitimate reason to monitor a particular device, 312 for example for IT support operations. However, it is difficult to 313 control if another actor also monitors the same station with the goal 314 of obtaining PII or PCI. 316 Wireless access network operators: some wireless access networks are 317 only offered to users or devices matching specific requirements, such 318 as device type (e.g., IoT-only networks, factory operational 319 networks). Therefore, operators can attempt to identify the devices 320 (or the users) connecting to the networks under their care. They can 321 use the MAC address to represent an identified device. 323 Network access providers: wireless access networks are often 324 considered beyond the first 2 layers of the OSI model. For example, 325 several regulatory or legislative bodies can group all OSI layers 326 into their functional effect of allowing network communication 327 between machines. In this context, entities operating access 328 networks can see their liability associated to the activity of 329 devices communicating through the networks that these entities 330 operate. In other contexts, operators assign network resources based 331 on contractual conditions (e.g., fee, bandwidth fair share). In 332 these scenarios, these operators may attempt to identify the devices 333 and the users of their networks. They can use the MAC address to 334 represent an identified device. 336 Over the wire internal (OTWi) observers: because the device wireless 337 MAC address continues to be present over the wire if the 338 infrastructure connection device (e.g. access point) functions as a 339 Layer 2 bridge, observers may be positioned over the wire and read 340 transmission MAC addresses. Such capability supposes that the 341 observer has access to the wired segment of the broadcast domain 342 where the frames are exchanged. In most networks, such capability 343 requires physical access to an infrastructure wired device in the 344 broadcast domain (e.g. switch closet), and is therefore not 345 accessible to all. 347 Over the wired external (OTWe) observers: beyond the broadcast 348 domain, frames headers are removed by a routing device, and a new 349 Layer 2 header is added before the frame is transmitted to the next 350 segment. The personal device MAC address is not visible anymore, 351 unless a mechanism copies the MAC address into a field that can be 352 read while the packet travels onto the next segment (e.g. pre- 353 [RFC4941] and pre- [RFC7217] IPv6 addresses built from the MAC 354 address). Therefore, unless this last condition exists, OTWe 355 observers are not able to see the device MAC address. 357 3.3. The Trust and the Environments 359 The surface of PII exposures that can drive MAC address randomization 360 depends on the environment where the device operates, on the presence 361 and nature of other devices in the environment, and on the type of 362 network the device is communicating through. Therefore, a device can 363 express an identity (such as a MAC address) that can be stable over 364 time if trust with the environment is established, or that can be 365 temporal if an identity is required for a service in an environment 366 where trust has not been established. Trust is not a binary 367 currency. Thus it is useful to distinguish what trust a personal 368 device may establish with the different entities at play in a L2 369 domain: 371 1. Full trust: there are environments where a personal device 372 establishes a trust relationship and can share a stable device 373 identity with the access network devices (e.g., access point and 374 WLC), the services beyond the access point in the L2 broadcast 375 domain (e.g. DHCP, AAA). The personal device (or its user) has 376 confidence that its identity is not shared beyond the L2 377 broadcast domain boundary. 379 2. Selective trust: in other environments, the device may not be 380 willing to share a stable identity with some elements of the 381 Layer 2 broadcast domain, but may be willing to share a stable 382 identity with other elements. For example, a device may want to 383 change the MAC address it uses to communicate with the access 384 point while maintaining the same IP address across the MAC 385 address rotation (thus expressing a stable identity to the DHCP 386 server). That stable identity may or may not be the same for 387 different services. 389 3. Zero trust: in other environments, the device may not be willing 390 to share any stable identity with any entity reachable through 391 the Layer 2 broadcast domain, and may express a temporal identity 392 to each of them. That temporal identity may or not be the same 393 for different services. 395 This trust relationship naturally depends on the relationship between 396 the user of the personal device and the operator of the service. 397 Thus, it is useful to observe the typical trust structure of common 398 environments: 400 A. Residential settings under the control of the user: this is 401 typical of a home network with Wi-Fi in the LAN and Internet 402 connection. In this environment, the MAC address activity may be 403 detectable beyond the home walls. However, if traffic is 404 encrypted (e.g. WPA3), some protection for OTA eavesdropping can 405 be assumed. The wire segment within the broadcast domain is 406 under the control of the user, and is therefore usually not at 407 risk of hosting an eavesdropper. Full trust is typically 408 established at this level. The device trusts the access point 409 and all L2 domain entities beyond the access point. Traffic over 410 the Internet does not expose the MAC address if it is not copied 411 to another field before routing happens. 413 B. Managed residential settings: examples of this type of 414 environment include shared living facilities and other collective 415 environments where an operator manages the network for the 416 residents. The OTA exposure is similar to that of a home. A 417 number of devices larger than in a standard home may be present, 418 and the operator may be requested to provide IT support to the 419 residents. Therefore, the operator may need to identify a device 420 activity in real time, but may also need to analyze logs so as to 421 understand a past reported issue. For both activities, a device 422 identification associated to the session is needed. Full trust 423 is often established in this environment, at the scale of a 424 series of a few sessions. 426 C. Public guest networks: public hotspots, such as in shopping 427 malls, hotels, stores, trains stations and airports are typical 428 of this environment. The guest network operator may be legally 429 mandated to identify devices or users or may have the option to 430 leave all devices and users untracked. In this environment, 431 trust is commonly not established with any element of the L2 432 broadcast domain (Zero trust model by default). 434 D. Enterprises (with BYOD): users may be provided corporate devices 435 or may bring their own devices. The devices are not directly 436 under the control of a corporate IT team. Trust may be 437 established as the device joins the network. Some enterprise 438 models will mandate full trust, others, considering the BYOD 439 nature of the device, will allow selective trust. 441 E. Managed enterprises: in this environment, users are typically 442 provided with corporate devices, and all connected devices are 443 managed, for example through a Mobile Device Management (MDM) 444 profile installed on the device. Full trust is created as the 445 MDM profile is installed. 447 3.4. The Purpose of Device Identification and Associated Problems 449 Many network functional devices offering a service to a personal 450 device use the device MAC address to maintain service continuity. 452 Wireless access points and controllers use the MAC address to 453 validate the device connection context, including protocol 454 capabilities, confirmation that authentication was completed, QoS or 455 security profiles, encryption key material. Some advanced access 456 points and controllers also include upper layer functions which 457 purpose is covered below. A device changing its MAC address, without 458 another recorded device identity, would cause the access point and 459 the controller to lose these parameters. As such, the Layer 2 460 infrastructure does not know that the device (with its new MAC 461 address) is authorized to communicate through the network. The 462 encryption keying material is not identified anymore (causing the 463 access point to fail decrypting the device traffic, and fail 464 selecting the right key to send encrypted traffic to the device). In 465 short, the entire context needs to be rebuilt, and a new session 466 restarted. The time consumed by this procedure breaks any flow that 467 needs continuity or short delay between packets on the device (e.g. 468 real-time audio, video, AR/VR etc.) The 802.11i Standard recognizes 469 that a device may leave the network and come back after a short time 470 window. As such, the standard suggests that the infrastructure 471 should keep the context for a device up to one hour after the device 472 was last seen. MAC address rotation in this context can cause 473 resource exhaustion on the wireless infrastructure and the flush of 474 contexts, including for devices that are simply in temporal sleep 475 mode. 477 Other devices in the Layer 2 broadcast domain also use the MAC 478 address to know whether and where to forward frames. MAC rotation 479 can cause these devices to exhaust their resources, holding in memory 480 traffic for a device which port location can no longer be found. As 481 these infrastructure devices also implement a cache (to remember the 482 port position of each known device), too frequent MAC rotation can 483 cause resources exhaustion and the flush of older MAC addresses, 484 including for devices that did not rotate their MAC. For the RCM 485 device, these effects translate into session discontinuity and return 486 traffic losses. 488 In wireless contexts, 802.1X authenticators rely on the device and 489 user identity validation provided by a AAA server to open their port 490 to data transmission. The MAC address is used to verify that the 491 device is in the authorized list, and the associated key used to 492 decrypt the device traffic. A change in MAC address causes the port 493 to be closed to the device data traffic until the AAA server confirms 494 the validity of the new MAC address. Therefore, MAC rotation can 495 interrupt the device traffic, and cause a strain on the AAA server. 497 DHCP servers, without a unique identification of the device, lose 498 track of which IP address is validly assigned. Unless the RCM device 499 releases the IP address before the rotation occurs, DHCP servers are 500 at risk of scope exhaustion, causing new devices (and RCM devices) to 501 fail to obtain a new IP address. Even if the RCM device releases the 502 IP address before the rotation occurs, the DHCP server typically 503 holds the released IP address for a certain duration, in case the 504 leaving MAC would return. As the DHCP server cannot know if the 505 release is due to a temporal disconnection or a MAC rotation, the 506 risk of scope address exhaustion exists even in cases where the IP 507 address is released. 509 Routers keep track of which MAC address is on which interface. MAC 510 rotation can cause MAC address cache exhaustion, but also the need 511 for frequent ARP and inverse ARP exchanges. 513 In residential settings (environments type A), policies can be in 514 place to control the traffic of some devices (e.g. parental control, 515 block-list devices). These policies are often based on the device 516 MAC address. Rotation of the MAC address removes the possibility for 517 such control. 519 In residential settings (environments type A) and in enterprises 520 (environments types D and E), device recognition and ranging may be 521 used for IoT-related functionalities (door unlock, preferred light 522 and temperature configuration, etc.) These functions often rely on 523 the detection of the device wireless MAC address. MAC address 524 rotation breaks the services based on such model. 526 In managed residential settings (environments types B) and in 527 enterprises (environments types D and E), the network operator is 528 often requested to provide IT support. With MAC address rotation, 529 real time support is only possible if the user is able to provide the 530 current MAC address. Service improvement support is not possible if 531 the MAC address that the device had at the (past) time of the 532 reported issue is not known at the time the issue is reported. 534 3.5. Scenario Mapping Table 536 Section 3.4discusses different environments, different settings, and 537 the expectations of users and network operators. Table 1 summarizes 538 the expected degree of trust, network adim responsbilitly, complexity 539 of supported network services and network support expectation from 540 the user 542 +==================+========+=========+==========+=================+ 543 | Network Location | Trust | Network | Network | Network Support | 544 | | Degree | Admin | Services | Expectation | 545 +==================+========+=========+==========+=================+ 546 | Home | High | User | Medium | Low | 547 +------------------+--------+---------+----------+-----------------+ 548 | Campus (BYOD) | Medium | IT | Complex | Medium | 549 +------------------+--------+---------+----------+-----------------+ 550 | Enterprise (MDM) | High | IT | Complex | High | 551 +------------------+--------+---------+----------+-----------------+ 552 | Hospitality | Low | IT | Simple | Medium | 553 +------------------+--------+---------+----------+-----------------+ 554 | Public WiFi | Low | ISP | Simple | Low | 555 +------------------+--------+---------+----------+-----------------+ 557 Table 1: Scenario Mapping Table 559 For example: a Home network is considered to be trusted and safe. 560 Users expect a simple procedure to connect to their home network. 561 All devices in the home network trust each other. Privacy within the 562 Layer 2 domain is not a major concern. The Home network can also 563 include many IoT devices, which need to be simple to onboard and 564 manage. The home user commonly expects the network operator to 565 protect the home network from external threats (attacks from the 566 Internet). The home user also commonly expects simple policy 567 features (e.g., Parental Control). Most home users do not expect to 568 need networking skills to manage their home network. 570 On the other end of the spectrum, Public Wi-Fi is often considered to 571 be untrusted. Privacy is the number one concern for the user. Most 572 users connect to Public Wi-Fi only require imple Internet 573 connectivity service, and expect only limited to no technical 574 support. 576 3.6. Requirements Formulation 578 The section describes the requirements for Randomized MAC-Address 579 Changes: 581 REQ1 The network must not make any assumption about client MAC 582 address persistence. MAC address change must happen while 583 allowing for service continuity. If a service is interrupted 584 during the RCM process, there must be a formal mechanism for 585 the client and the network to exchange about the interruption. 587 REQ2 During duration of the services, the device shoud not change 588 the identity. Any change of identity may result re- 589 authentication and interrupt of the current network services. 591 REQ3 Survey the current standards that use MAC address as a device 592 identifier in the protocol. Make recommendation to the working 593 groups to remove the dependency. 595 REQ4 Work as liaison with external standard bodies such as IEEE, BBF 596 and WBA to align with use cases and requirements. 598 REQ5 Identify a secure mechanism to authenticate and exchange 599 network identity to the device. 601 REQ6 Identify a secure mechanism to inform the device about the type 602 of network the device is connecting to (e.g. public Wi-Fi, 603 enterprise, home), allowing the user to select the device 604 identity (or identities) accordingly. 606 REQ7 Identify a secure mechanism for the network to request device 607 identity. Upon successful authentication, the network may 608 provide the device a temporary network-based marker to use the 609 network services. 611 REQ8 Identify a secure mechanism for the device to notify the 612 network prior to update the MAC address. 614 4. IANA Considerations 616 This memo includes no request to IANA. 618 5. Security Considerations 620 Privacy considerations are discussed throughout this document. 622 6. Normative References 624 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 625 Requirement Levels", BCP 14, RFC 2119, 626 DOI 10.17487/RFC2119, March 1997, 627 . 629 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 630 Text on Security Considerations", BCP 72, RFC 3552, 631 DOI 10.17487/RFC3552, July 2003, 632 . 634 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 635 IANA Considerations Section in RFCs", RFC 5226, 636 DOI 10.17487/RFC5226, May 2008, 637 . 639 7. Informative References 641 [IEEE.802-1D.1993] 642 Institute of Electrical and Electronics Engineers, 643 "Information technology - Telecommunications and 644 information exchange between systems - Local area networks 645 - Media access control (MAC) bridges", IEEE Standard 646 802.1D, July 1993. 648 [IEEE.802-1Y.1990] 649 Institute of Electrical and Electronics Engineers, "Source 650 Routing Tutorial for End System Operation", IEEE Standard 651 802.1Y, September 1990. 653 [IEEE.802.15.4P_2014] 654 IEEE, "IEEE Standard for local and metropolitan area 655 networks - Part 15.4: Low-Rate Wireless Personal Area 656 Networks (LR-WPANs) - Amendment 7: Physical Layer for Rail 657 Communications and Control (RCC)", IEEE 802.15.4p-2014, 658 DOI 10.1109/ieeestd.2014.6809836, 2 May 2014, 659 . 662 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 663 Extensions for Stateless Address Autoconfiguration in 664 IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, 665 . 667 [RFC5176] Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B. 668 Aboba, "Dynamic Authorization Extensions to Remote 669 Authentication Dial In User Service (RADIUS)", RFC 5176, 670 DOI 10.17487/RFC5176, January 2008, 671 . 673 [RFC7217] Gont, F., "A Method for Generating Semantically Opaque 674 Interface Identifiers with IPv6 Stateless Address 675 Autoconfiguration (SLAAC)", RFC 7217, 676 DOI 10.17487/RFC7217, April 2014, 677 . 679 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 680 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 681 May 2017, . 683 Authors' Addresses 685 Jerome Henry 686 Cisco Systems 687 United States of America 689 Email: jerhenry@cisco.com 691 Yiu L. Lee 692 Comcast 693 1800 Arch Street 694 Philadelphia, PA 19103 695 United States of America 697 Email: yiu_lee@comcast.com