idnits 2.17.1 draft-henry-madinas-framework-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 has text resembling RFC 2119 boilerplate text. -- The document date (10 April 2021) is 1111 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 4941 (Obsoleted by RFC 8981) Summary: 0 errors (**), 0 flaws (~~), 2 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: 12 October 2021 Comcast 6 10 April 2021 8 Randomized and Changing MAC Address Framework 9 draft-henry-madinas-framework-01 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 docuemnt 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 12 October 2021. 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 Adress 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. Problem Statment Formulation . . . . . . . . . . . . . . 14 71 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 72 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 73 6. Normative References . . . . . . . . . . . . . . . . . . . . 14 74 7. Informative References . . . . . . . . . . . . . . . . . . . 15 75 Appendix A. Existing Solutions Directions . . . . . . . . . . . 16 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 78 1. Introduction 80 It has become easier for attackers to track the activity of a 81 personal device, particularly when traffic is sent over a wireless 82 link. Once the association between a device and its user is made, 83 identifying the device and its activity is sufficient to deduce 84 information about what the user is doing, without the user consent. 86 To reduce the risks of correlation between a device activity and its 87 owner, multiple vendors have started to implement Randomized and 88 Changing MAC addresses (RCM). With this scheme, an end-device 89 implements a different RCM over time when exchanging traffic over a 90 wireless network. By randomizing the MAC address, the association 91 between a given traffic flow and a single device is made more 92 difficult, assuming no other visible unique identifiers are in use. 94 However, such address change may affect the user experience and the 95 efficiency of legitimate network operations. For a long time, the 96 unicity of the association between a device and a MAC address was 97 assumed, despite the emergence of tools to flush out the MAC address 98 to bypass some network policies. When this association is broken, 99 elements of network communication may also break. For example, 100 sessions established between the end-device and network services may 101 be lost and packets in translation may suddenly be without clear 102 source or destination. As multiple clients implements fast-paced RCM 103 rotations, network services may be over-solicited by a small number 104 of stations that appear as many clients. 106 At the same time, some network services rely on the client station 107 providing an identifier, which can be the MAC address or another 108 value. If the client implements MAC rotation but continues sending 109 the same static identifier, then the association between a stable 110 identifier identifier and the station continues despite the RCM 111 scheme. There may be environements where such continued association 112 is desirable, but others where the user privacy has more value than 113 any continuity of network service state. 115 There is a need to enumerate services that may be affected by RCM, 116 and evaluate possible solutions to maintain both the quality of user 117 experience and network efficiency while RCM happens and user privacy 118 is reinforced. This document presents such assessment and 119 recommendations. 121 1.1. Requirements Language 123 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 124 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 125 "OPTIONAL" in this document are to be interpreted as described in BCP 126 14 RFC 2119 [RFC2119] RFC 8174 [RFC8174] when, and only when, they 127 appear in all capitals, as shown here. 129 2. MAC Adress as an Identity: User vs. Device 131 Any device member of an IEEE 802 network [IEEE.802-1D.1993] includes 132 several operating layers. Among them, the Media Access Control (MAC) 133 layer defines rules to control how the device accesses the shared 134 medium. In a network where a machine can communicate with one or 135 more other machines, one such rule is that each machine needs to be 136 identified, either as the target destination of a message, or as the 137 source of a message (and thus the target destination of the answer). 138 Initially intended as a 48-bit (6 octets) value, later versions of 139 the Standard [IEEE.802.15.4P_2014] allowed this address to take an 140 extended format of 64 bits (8 octets), thus enabling a larger number 141 of MAC addresses to coexist as the 802 technologies became widely 142 adopted. 144 Regardless of the address length, different networks have different 145 needs, and several bits of the first octet are reserved for specific 146 purposes. In particular, the first bit is used to identify the 147 destination address either as an individual (bit set to 0) or a group 148 address (bit set to 1). The second bit, called the Universally or 149 Locally Administered (U/L) Address Bit, indicates whether the address 150 has been assigned by a local or universal administrator. Universally 151 administered addresses have this bit set to 0. If this bit is set to 152 1, the entire address (i.e., 48 bits) has been locally administered 153 [IEEE.802-1Y.1990] Section 5.2.1. 155 The intent of this provision is important for the present document. 156 The 802 Standard recognized that some devices may never travel and 157 thus, always attaching to the same network, would not need a globally 158 unique MAC address. To accommodate for this relaxed requirement, the 159 second bit of the MAC address first octet the MAC address format was 160 designed to express whether the address was intended to be globally 161 unique, or if significance was only local. The address allocation 162 method was not defined in the Standard in this later case, but the 163 mechanism was defined in the same clause that defined that an address 164 should be unique so as to avoid collision. 166 It is also important to note that the purpose of the Universal 167 version of the address was to avoid collisions and confusion, as any 168 machine could connect to any network, and each machine needs to 169 determine if it is the intended destination of a message or its 170 response. The same clause 5.2.1 reminds network designers and 171 operators that all potential members of a network need to have a 172 unique identifier (if they are going to coexist in the network). The 173 advantage of a universal address is that a node with such an address 174 can be attached to any Local Area Network (LAN) in the world with an 175 assurance that its address is unique. 177 With the rapid development of wireless technologies and mobile 178 devices, this scenario became very common. With a vast majority of 179 802 networks implementing radio technologies at the access, the MAC 180 address of a wireless device can appear anywhere on the planet and 181 collisions should still be avoided. However, the same evolution 182 brought the distinction between two types of devices that the 802 183 Standard generally referred to as 'nodes in a network'. Their 184 definition is found in the 802E Recommended Practice (clause 6.2). 185 One type is a shared service device, which functions are used by a 186 number of people large enough that the device itself, its functions 187 or its traffic cannot be associated with a single or small group of 188 people. Examples of such devices include switches in a dense 189 network, 802.11 (WLAN) access points in a crowded airport, task- 190 specific (e.g. barcode scanners) devices, etc. Another type is a 191 personal device, which is a machine, a node, primarily used by a 192 single person or small group of people, and so that any 193 identification of the device or its traffic can also be associated to 194 the identification of the primary user or their traffic. Quite 195 naturally, the unique identification of the device is trivial if the 196 device expresses a universally unique MAC address. Then, the 197 detection of elements directly or indirectly identifying the user of 198 the device (Personally Identifiable Information, or PII) is 199 sufficient to tie the universal MAC address to a user. Then, any 200 detection of traffic that can be associated to the device becomes 201 also associated with the known user of that device (Personally 202 Correlated Information, or PCI). 204 This possible identification or association presents a serious 205 privacy issue, especially with wireless technologies. For most of 206 them, and in particular for 802.11, the source and destination MAC 207 addresses are not encrypted even in networks that implement 208 encryption (so that each machine can easily detect if it is the 209 intended target of the message before attempting to decrypt its 210 content, and also identify the transmitter, so as to use the right 211 key when multiple unicast keys are in effect). 213 This unique identification of the user associated to a node was 214 clearly not the intent of the 802 MAC address. A logical solution to 215 remove this association is to use a locally administered address 216 instead, and change the address in a fashion that prevents a temporal 217 association between one MAC address and some PII to be maintained 218 fruitfully. However, other network devices on the same LAN 219 implementing a MAC layer also expect the unicity of the MAC address. 220 When a device changes its MAC address, other devices on the same LAN 221 may fail to recognize that the same machine is attempting to 222 communicate with them. Additionally, multiple layers implemented at 223 upper OSI layers have been designed with the assumption that each 224 node on the LAN, using these services, would have a unique MAC 225 address. This assumption sometimes adds to the PII confusion, for 226 example in the case of Authentication, Association and Accounting 227 (AAA) services authenticating the user of a machine and associating 228 the authenticated user to the device MAC address. Other services 229 solely focus on the machine (e.g. DHCP), but still expect each 230 device to use a single MAC address. Changing the MAC address may 231 disrupt these services. 233 3. The Actors: Network Functional Entities and Human Entities 235 The risk of service disruption is thus weighted against the privacy 236 benefits. However, the plurality of actors involved in the exchanges 237 tends to blurry the boundaries of what privacy should be protected 238 against. It might therefore be useful to list the actors to the 239 network exchanges. Some actors are functional entities, some others 240 are humans (or related) entities. 242 3.1. Network Functional Entities 244 Wireless access network infrastructure devices (e.g. WLAN access 245 points or controllers): these devices participate in 802 LAN 246 operations. As such, they need to uniquely identify machines as a 247 source or destination so as to successfully continue exchanging 248 frames. Part of the identification includes recording, and adapting 249 to, devices communication capabilities (e.g. support for specific 250 protocols). As a device changes its network attachment (roams) from 251 one access point to another, the access points can exchange 252 contextual information (e.g. device MAC, keying material) allowing 253 the device session to continue seamlessly. These access points can 254 also inform devices further in the wired network about the roam, to 255 ensure that OSI model Layer 2 frames are redirected to the new device 256 access point. 258 Other network devices operating at the MAC layer: many wireless 259 network access devices (e.g., 802.11 access points) are conceived as 260 Layer 2 devices, and as such they bridge a frame from one medium 261 (e.g., 802.11 or Wi-Fi) to another (e.g., 802.3 or Ethernet). This 262 means that a wireless device MAC address often exists on the wire 263 beyond the wireless access device. Devices connected to this wire 264 also implement 802 technologies, and as such operate on the 265 expectation that each device is associated to a unique MAC address 266 for the duration of continuous exchanges. For example, switches and 267 bridges associate MAC addresses to individual ports (so as to know 268 which port to send a frame intended for a particular MAC address). 269 Similarly, authentication, authorization and accounting (AAA) 270 services can validate the identity of a device and use the device MAC 271 address as a first pointer to the device identity (before operating 272 further verification). Similarly, some networking devices offer 273 Layer-2 filtering policies that may rely on the connected MAC 274 addresses. 802.1X-enabled devices may also selectively block the data 275 portion of a port until a connecting device is authenticated. These 276 services then use the MAC address as a first pointer to the device 277 identity to allow or block data traffic. This list is not 278 exhaustive. Multiple services are defined for 802.3 networks, and 279 multiple services defined by the IEEE 802.1 working group are also 280 applicable to 802.3 networks. Wireless access points may also 281 connect to other mediums than 802.3, which also implements mechanism 282 under the umbrella of the general 802 Standard, and therefore expect 283 the unique association of a MAC address to a device. 285 Network devices operating at upper layers: some network devices 286 provide functions and services above the MAC layer. Some of them 287 also operate a MAC layer function: for example, routers provide IP 288 forwarding services, but rely on the device MAC address to create the 289 appropriate frame structure. Other devices and services operate at 290 upper layers, but also rely upon the 802 principle of unique MAC-to- 291 device mapping. For example, DHCPv4 services commonly provide a 292 single IP address per MAC address (they do not assign more than one 293 IPv4 address per MAC address, and assign a new IPv4 address to each 294 new requesting MAC address). ARP and reverse-ARP services commonly 295 expect that, once an IP-to-MAC mapping has been established, this 296 mapping is valid and unlikely to change for the cache lifetime. 297 DHCPv6 services commonly do not assign the same IPv6 address to two 298 different requesting MAC addresses. Hybrid services, such as EoIP, 299 also assume stability of the device-to-MAC-and-IP mapping for the 300 duration of a given session. 302 3.2. Human-related Entities 304 Over the air (OTA) observers: as the transmitting or receiving MAC 305 address is usually not encrypted in wireless 802-technologies 306 exchanges, and as any protocol-compatible device in range of the 307 signal can read the frame header, OTA observers are able to read 308 individual transmissions MAC addresses. Some wireless technologies 309 also support techniques to establish distances or positions, allowing 310 the observer, in some cases, to uniquely associate the MAC address to 311 a physical device and it associated location. It can happen that an 312 OTA observer has a legitimate reason to monitor a particular device, 313 for example for IT support operations. However, it is difficult to 314 control if another actor also monitors the same station with the goal 315 of obtaining PII or PCI. 317 Wireless access network operators: some wireless access networks are 318 only offered to users or devices matching specific requirements, such 319 as device type (e.g., IoT-only networks, factory operational 320 networks). Therefore, operators can attempt to identify the devices 321 (or the users) connecting to the networks under their care. They can 322 use the MAC address to represent an identified device. 324 Network access providers: wireless access networks are often 325 considered beyond the first 2 layers of the OSI model. For example, 326 several regulatory or legislative bodies can group all OSI layers 327 into their functional effect of allowing network communication 328 between machines. In this context, entities operating access 329 networks can see their liability associated to the activity of 330 devices communicating through the networks that these entities 331 operate. In other contexts, operators assign network resources based 332 on contractual conditions (e.g., fee, bandwidth fair share). In 333 these scenarios, these operators may attempt to identify the devices 334 and the users of their networks. They can use the MAC address to 335 represent an identified device. 337 Over the wire internal (OTWi) observers: because the device wireless 338 MAC address continues to be present over the wire if the 339 infrastructure connection device (e.g. access point) functions as a 340 Layer 2 bridge, observers may be positioned over the wire and read 341 transmission MAC addresses. Such capability supposes that the 342 observer has access to the wired segment of the broadcast domain 343 where the frames are exchanged. In most networks, such capability 344 requires physical access to an infrastructure wired device in the 345 broadcast domain (e.g. switch closet), and is therefore not 346 accessible to all. 348 Over the wired external (OTWe) observers: beyond the broadcast 349 domain, frames headers are removed by a routing device, and a new 350 Layer 2 header is added before the frame is transmitted to the next 351 segment. The personal device MAC address is not visible anymore, 352 unless a mechanism copies the MAC address into a field that can be 353 read while the packet travels onto the next segment (e.g. pre- 354 [RFC4941] and pre- [RFC7217] IPv6 addresses built from the MAC 355 address). Therefore, unless this last condition exists, OTWe 356 observers are not able to see the device MAC address. 358 3.3. The Trust and the Environments 360 The surface of PII exposures that can drive MAC address randomization 361 depends on the environment where the device operates. Therefore, a 362 device can express an identity (such as a MAC address) that can be 363 stable over time if trust is established, or that can be temporal if 364 an identity is required for a service in an environment where trust 365 has not been established. Trust is not a binary currency. Thus it 366 is useful to distinguish what trust a personal device may establish 367 with the different entities at play in a L2 domain: 369 1. Full trust: there are environments where a personal device 370 establishes a trust relationship and can share a stable device 371 identity with the access network devices (e.g., access point and 372 WLC), the services beyond the access point in the L2 broadcast 373 domain (e.g. DHCP, AAA). The personal device (or its user) has 374 confidence that its identity is not shared beyond the L2 375 broadcast domain boundary. 377 2. Selective trust: in other environments, the device may not be 378 willing to share a stable identity with some elements of the 379 Layer 2 broadcast domain, but may be willing to share a stable 380 identity with other elements. For example, a device may want to 381 change the MAC address it uses to communicate with the access 382 point while maintaining the same IP address across the MAC 383 address rotation (thus expressing a stable identity to the DHCP 384 server). That stable identity may or may not be the same for 385 different services. 387 3. Zero trust: in other environments, the device may not be willing 388 to share any stable identity with any entity reachable through 389 the Layer 2 broadcast domain, and may express a temporal identity 390 to each of them. That temporal identity may or not be the same 391 for different services. 393 This trust relationship naturally depends on the relationship between 394 the user of the personal device and the operator of the service. 395 Thus, it is useful to observe the typical trust structure of common 396 environments: 398 A. Residential settings under the control of the user: this is 399 typical of a home network with Wi-Fi in the LAN and Internet 400 connection. In this environment, the MAC address activity may be 401 detectable beyond the home walls. However, if traffic is 402 encrypted (e.g. WPA3), some protection for OTA eavesdropping can 403 be assumed. The wire segment within the broadcast domain is 404 under the control of the user, and is therefore usually not at 405 risk of hosting an eavesdropper. Full trust is typically 406 established at this level. The device trusts the access point 407 and all L2 domain entities beyond the access point. Traffic over 408 the Internet does not expose the MAC address if it is not copied 409 to another field before routing happens. 411 B. Managed residential settings: examples of this type of 412 environment include shared living facilities and other collective 413 environments where an operator manages the network for the 414 residents. The OTA exposure is similar to that of a home. A 415 number of devices larger than in a standard home may be present, 416 and the operator may be requested to provide IT support to the 417 residents. Therefore, the operator may need to identify a device 418 activity in real time, but may also need to analyze logs so as to 419 understand a past reported issue. For both activities, a device 420 identification associated to the session is needed. Full trust 421 is often established in this environment, at the scale of a 422 series of a few sessions. 424 C. Public guest networks: public hotspots, such as in shopping 425 malls, hotels, stores, trains stations and airports are typical 426 of this environment. The guest network operator may be legally 427 mandated to identify devices or users or may have the option to 428 leave all devices and users untracked. In this environment, 429 trust is commonly not established with any element of the L2 430 broadcast domain (Zero trust model by default). 432 D. Enterprises (with BYOD): users may be provided corporate devices 433 or may bring their own devices. The devices are not directly 434 under the control of a corporate IT team. Trust may be 435 established as the device joins the network. Some enterprise 436 models will mandate full trust, others, considering the BYOD 437 nature of the device, will allow selective trust. 439 E. Managed enterprises: in this environment, users are typically 440 provided with corporate devices, and all connected devices are 441 managed, for example through a Mobile Device Management (MDM) 442 profile installed on the device. Full trust is created as the 443 MDM profile is installed. 445 3.4. The Purpose of Device Identification and Associated Problems 447 Many network functional devices offering a service to a personal 448 device use the device MAC address to maintain service continuity. 450 Wireless access points and controllers use the MAC address to 451 validate the device connection context, including protocol 452 capabilities, confirmation that authentication was completed, QoS or 453 security profiles, encryption key material. Some advanced access 454 points and controllers also include upper layer functions which 455 purpose is covered below. A device changing its MAC address, without 456 another recorded device identity, would cause the access point and 457 the controller to lose these parameters. As such, the Layer 2 458 infrastructure does not know that the device (with its new MAC 459 address) is authorized to communicate through the network. The 460 encryption keying material is not identified anymore (causing the 461 access point to fail decrypting the device traffic, and fail 462 selecting the right key to send encrypted traffic to the device). In 463 short, the entire context needs to be rebuilt, and a new session 464 restarted. The time consumed by this procedure breaks any flow that 465 needs continuity or short delay between packets on the device (e.g. 466 real-time audio, video, AR/VR etc.) The 802.11i Standard recognizes 467 that a device may leave the network and come back after a short time 468 window. As such, the standard suggests that the infrastructure 469 should keep the context for a device up to one hour after the device 470 was last seen. MAC address rotation in this context can cause 471 resource exhaustion on the wireless infrastructure and the flush of 472 contexts, including for devices that are simply in temporal sleep 473 mode. 475 Other devices in the Layer 2 broadcast domain also use the MAC 476 address to know whether and where to forward frames. MAC rotation 477 can cause these devices to exhaust their resources, holding in memory 478 traffic for a device which port location can no longer be found. As 479 these infrastructure devices also implement a cache (to remember the 480 port position of each known device), too frequent MAC rotation can 481 cause resources exhaustion and the flush of older MAC addresses, 482 including for devices that did not rotate their MAC. For the RCM 483 device, these effects translate into session discontinuity and return 484 traffic losses. 486 In wireless contexts, 802.1X authenticators rely on the device and 487 user identity validation provided by a AAA server to open their port 488 to data transmission. The MAC address is used to verify that the 489 device is in the authorized list, and the associated key used to 490 decrypt the device traffic. A change in MAC address causes the port 491 to be closed to the device data traffic until the AAA server confirms 492 the validity of the new MAC address. Therefore, MAC rotation can 493 interrupt the device traffic, and cause a strain on the AAA server. 495 DHCP servers, without a unique identification of the device, lose 496 track of which IP address is validly assigned. Unless the RCM device 497 releases the IP address before the rotation occurs, DHCP servers are 498 at risk of scope exhaustion, causing new devices (and RCM devices) to 499 fail to obtain a new IP address. Even if the RCM device releases the 500 IP address before the rotation occurs, the DHCP server typically 501 holds the released IP address for a certain duration, in case the 502 leaving MAC would return. As the DHCP server cannot know if the 503 release is due to a temporal disconnection or a MAC rotation, the 504 risk of scope address exhaustion exists even in cases where the IP 505 address is released. 507 Routers keep track of which MAC address is on which interface. MAC 508 rotation can cause MAC address cache exhaustion, but also the need 509 for frequent ARP and inverse ARP exchanges. 511 In residential settings (environments type A), policies can be in 512 place to control the traffic of some devices (e.g. parental control, 513 block-list devices). These policies are often based on the device 514 MAC address. Rotation of the MAC address removes the possibility for 515 such control. 517 In residential settings (environments type A) and in enterprises 518 (environments types D and E), device recognition and ranging may be 519 used for IoT-related functionalities (door unlock, preferred light 520 and temperature configuration, etc.) These functions often rely on 521 the detection of the device wireless MAC address. MAC address 522 rotation breaks the services based on such model. 524 In managed residential settings (environments types B) and in 525 enterprises (environments types D and E), the network operator is 526 often requested to provide IT support. With MAC address rotation, 527 real time support is only possible if the user is able to provide the 528 current MAC address. Service improvement support is not possible if 529 the MAC address that the device had at the (past) time of the 530 reported issue is not known at the time the issue is reported. 532 3.5. Scenario Mapping Table 534 Section 3.4 discusses different environments, different settings, and 535 the expectations of users and network operators. Table 1 summarizes 536 the expected degree of trust, network adim responsbilitly, complexity 537 of supported network services and network support expectation from 538 the user 539 +==================+========+=========+==========+=================+ 540 | Network Location | Trust | Network | Network | Network Support | 541 | | Degree | Admin | Services | Expectation | 542 +==================+========+=========+==========+=================+ 543 | Home | High | User | Medium | Low | 544 +------------------+--------+---------+----------+-----------------+ 545 | Campus (BYOD) | Medium | IT | Complex | Medium | 546 +------------------+--------+---------+----------+-----------------+ 547 | Enterprise (MDM) | High | IT | Complex | High | 548 +------------------+--------+---------+----------+-----------------+ 549 | Hospitality | Low | IT | Simple | Medium | 550 +------------------+--------+---------+----------+-----------------+ 551 | Public WiFi | Low | ISP | Simple | Low | 552 +------------------+--------+---------+----------+-----------------+ 554 Table 1: Scenario Mapping Table 556 Not surprising, Table 1 shows that users have different experience 557 and expectations for each environment. For exaxmple: Home network is 558 considered to be trusted and safe. The home user expects simple 559 procedures to setup and connect devices to the home networks. Once 560 onboard, devices in the home network should be able to communicate 561 (e.g., play music from a mobile device to a wireless speaker over 562 WiFi) without further action. In other words, the device should be 563 able to use the network continuously with minimal overhead. Privacy 564 within the Layer 2 domain in the home network is not a major concern. 565 The Home network can also include many IoT devices, which need to be 566 simple to onboard and manage. The home user usually expects the 567 network operator to protect the home network from external threats 568 (attacks from the Internet). The home user also usually expects 569 simple policy features (e.g., Parental Control). Sometimes, the home 570 user may want to onboard certain devices temporarily (e.g., guest 571 network). The setup is similar to Hospitality network but not as 572 heavily adminstrated as Hospitality network. Most home users do not 573 have deep networking skill to manage the network. 575 On the other end of the spectrum, Public WiFi is often considered to 576 be untrusted. Privacy is the number one concern for the user. Most 577 users connect to Public WiFi only require simple Internet 578 connectivity service, and expect only limited to no technical 579 support. 581 There are legitimate reasons for the network to identify devices in 582 order to provide serivces. Likewise, the user may want to 583 authenticate the network before giving an identity. 585 3.6. Problem Statment Formulation 587 The section describes the problem statement for Randomized MAC 588 address Changes: 590 PS1 The network must not make any assumption about client MAC 591 address persistence. MAC address change must happen while 592 allowing for service continuity. If a service is interrupted 593 during the RCM process, there must be a formal mechanism for the 594 client and the network to exchange about the interruption. 596 PS2 During duration of the services, the device shoud not change the 597 identity. Any change of identity may result re-authentication 598 and interrupt of the current network services. 600 PS3 Survey the current standards that use MAC address as a device 601 identifier in the protocol. Make recommendation to the working 602 groups to remove the dependency 604 PS4 Work as liaison with external standard bodies such as IEEE, BBF 605 and WBA to align with use cases and requirements. 607 PS5 Define a secure mechanism to authenticate and exchange network 608 identity to the device. 610 PS6 Define a secure mechanism to inform the device about the type of 611 network the device is connecting to (e.g. public Wi-Fi, 612 enterprise, home), allowing the user to select the device 613 identity (or identities) accordingly. 615 PS7 Define a secure mechanism for the network to request device 616 identity. Upon successful authenticatoin, the network may 617 provide the device a temporary network-based marker to use the 618 network services. 620 PS8 Define a secure mechanism for the device to notify the network 621 prior to update the MAC address. 623 4. IANA Considerations 625 This memo includes no request to IANA. 627 5. Security Considerations 629 Privacy considerations are discussed throughout this document. 631 6. Normative References 633 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 634 Requirement Levels", BCP 14, RFC 2119, 635 DOI 10.17487/RFC2119, March 1997, 636 . 638 7. Informative References 640 [IEEE.802-1D.1993] 641 Institute of Electrical and Electronics Engineers, 642 "Information technology - Telecommunications and 643 information exchange between systems - Local area networks 644 - Media access control (MAC) bridges", IEEE Standard 645 802.1D, July 1993. 647 [IEEE.802-1Y.1990] 648 Institute of Electrical and Electronics Engineers, "Source 649 Routing Tutorial for End System Operation", IEEE Standard 650 802.1Y, September 1990. 652 [IEEE.802.15.4P_2014] 653 IEEE, "IEEE Standard for local and metropolitan area 654 networks - Part 15.4: Low-Rate Wireless Personal Area 655 Networks (LR-WPANs) - Amendment 7: Physical Layer for Rail 656 Communications and Control (RCC)", IEEE 802.15.4p-2014, 657 DOI 10.1109/ieeestd.2014.6809836, 2 May 2014, 658 . 661 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 662 Extensions for Stateless Address Autoconfiguration in 663 IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, 664 . 666 [RFC5176] Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B. 667 Aboba, "Dynamic Authorization Extensions to Remote 668 Authentication Dial In User Service (RADIUS)", RFC 5176, 669 DOI 10.17487/RFC5176, January 2008, 670 . 672 [RFC7217] Gont, F., "A Method for Generating Semantically Opaque 673 Interface Identifiers with IPv6 Stateless Address 674 Autoconfiguration (SLAAC)", RFC 7217, 675 DOI 10.17487/RFC7217, April 2014, 676 . 678 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 679 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 680 May 2017, . 682 Appendix A. Existing Solutions Directions 684 Because the possible network disruptions related to frequent RCM have 685 been envisioned in the past, several directions have been suggested 686 to alleviate these disruptions. None of them are formal enough to 687 form a complete solution set. However, it may be useful to list them 688 to provide a general suggested-solutions context. 690 In full trust environments (settings of type a, b, d and/or e), the 691 device or its user may have confidence that over the air 692 eavesdropping does not present a threat. In that case, usage of a 693 fixed MAC address per SSID is a possibility. Of coruse, devices that 694 intelligently control the power of their WLAN signals also lower the 695 risk that neighboring devices (not part of the trusted network) track 696 the device activity. 698 In other cases in the same environments, over the air eavesdropping 699 may be a concern. In that case, the device may be able to express, 700 in a protected frame, a stable identity to the wireless 701 infrastructure. The format of the container of this identity, 702 encapsulated into a Layer 2 element, is protocol-specific and can be 703 defined by the associated protocol standard designers. In that case, 704 the device expresses a randomized and changing MAC address (RCM) over 705 the air, but a stable identity to the wireless infrastructure. 707 In networks implementing 802.1X/EAP, a AAA server may be informed 708 that a device presenting a new MAC address expresses the same device 709 identity as the same device with a previous MAC address. That AAA 710 server may then inform the access network, for example with a RADIUS 711 [RFC5176] CoA message, of the unique identity of the device across 712 RCMs. 714 In the cases where the unicity of the station identity is expressed 715 through a protected mean to the trusted access infrastructure, the 716 infrastructure could also express a single MAC address for the device 717 toward the wired part of the network. In such setting, the device 718 first connects to the wireless infrastructure and expresses a stable 719 identity. The wireless infrastructure, acting as a proxy, generates 720 a locally-administered MAC address for the device. That MAC address 721 is used to represent the device toward services in the other elements 722 of the wired network. Next, when the device rotates its over-the-air 723 MAC address and informs the wireless infrastructure of its stable 724 identity, the wireless infrastructure identifies that the new MAC 725 address matches the same device as the previous MAC address, and 726 continues using the previously generated locally-administered MAC 727 address to represent the device to wired infrastructure services. 729 In environments of type 2, the device may share different identities 730 with different services. For example, the device may express an 731 over-the-air RCM, a stable encapsulated identity to the wireless 732 infrastructure, a device identity to a AAA server, and a different 733 client identity to a DHCP server. In a multi-link scenario, it may 734 also happen that the device expresses more than one identity to the 735 DHCP server, with connections going through the same wireless 736 infrastructure. Because the device may express a stable identity to 737 one or more network services, because this identity may be shareable 738 with the wireless infrastructure, the wireless infrastructure may use 739 a single MAC to represent the device, using one of the stable 740 identities expressed by that device. Because different identities 741 can be expressed, and because the role of the wireless infrastructure 742 is not to monitor closely all activities from the device, the 743 wireless infrastructure could use, as the device stable identity, the 744 stable identity expressed to the wireless infrastructure, if it is 745 available. If such identity is not available, the infrastructure 746 could use the stable identity expressed to the AAA server, if it is 747 available and shared back with the wireless infrastructure. If such 748 identity is not available, the wireless infrastructure could use a 749 stable identity expressed to the DHCP server, if such identity is 750 available and visible to the wireless infrastructure. These 751 possibilities recognize the fact that the wireless infrastructure has 752 visibility into all traversing non-protected traffic. As such, the 753 wireless infrastructure may be able to read identifiers sent in 754 unprotected DHCP requests. Additionally, the wireless infrastructure 755 would also see, for example, a device with a new MAC address 756 expressing the same DHCP identity, or requesting the same IP address, 757 as another device previously connected through the same wireless 758 system. Therefore, the device may not be able to obfuscate its DHCP 759 identity from the wireless infrastructure if DHCP exchanges are not 760 encrypted. Additionally, and because the wireless infrastructure may 761 not be able to distinguish a device rotating its MAC and attempting 762 to obtain the same DHCP address as with its previous MAC address, 763 from a malicious device attempting to steal the DHCP identity from 764 another device, mechanisms on the infrastructure may prevent such 765 requests for already assigned resources from being forwarded 766 successfully. 768 In all environments where a device uses a rotating and changing 769 locally-administered MAC address, rotation from one address to the 770 next could be preceded by a release of network resources, such as 771 open connections closure and DHCP address releases. 773 Authors' Addresses 774 Jerome Henry 775 Cisco Systems 776 United States of America 778 Email: jerhenry@cisco.com 780 Yiu L. Lee 781 Comcast 782 1800 Arch Street 783 Philadelphia, PA 19103 784 United States of America 786 Email: yiu_lee@comcast.com