Internet Engineering Task Force Y. Lee
Internet-Draft J. Livingood
Intended status: Informational Comcast
Expires: 22 March 2021 J. Weil
Charter Communications
18 September 2020
Problem Statements for MAC Address Randomization
draft-lee-randomized-macaddr-ps-00
Abstract
MAC address is the Link Layer address used in the Ethrenet protocol.
It is usually assigned by the Network Interface Card manufacturer and
being used for forwording and receiving frame. Due to the static
nature of the MAC address, it raises some privacy concerns and MAC
address randomization is being implemented. This draft documents the
impacts of MAC address randomization to existing use cases and
proposes few next steps IETF may consider to work on.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 22 March 2021.
Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
Lee, et al. Expires 22 March 2021 [Page 1]
Internet-Draft Abbreviated Title September 2020
extracted from this document must include Simplified BSD License text
as described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4
4. Security Considerations . . . . . . . . . . . . . . . . . . . 4
5. Normative References . . . . . . . . . . . . . . . . . . . . 4
6. Informative References . . . . . . . . . . . . . . . . . . . 5
Appendix A. Additional Stuff . . . . . . . . . . . . . . . . . . 5
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5
1. Introduction
Ethernet protocol is the implementation of data link layer defined in
the Open Systems Interconnection model (OSI). Ethernet protocol is
defined in IEEE 802.1 standard and MAC address is the address used in
Ethernet protocol. MAC address is 48-bit long and usually defined in
the hardware. Each Ethernet interface comes with a MAC address
assigned by the manufacturer. Each device has one or more MAC
addresses. For example, a given IoT device may only have a single
WiiFi network interface and therefore a single MAC address. In
contract, a laptop may have three interfaces that encompasses two
wired Ethernet ports and a WiFi interface, and therefore will have
three MAC addresses. MAC address is used at the Local-Area-Network
(LAN) for frame forwarding. It is locally significant in the LAN and
critical LAN-to-LAN communications.
The device manufacturer typically assigns the MAC address to an
interface. Unless the user or operating system modifies the MAC
address, which is sometimes the case, the MAC address follows a
defined format and uses 2 parts. Those are Manufacturer ID and
Interface ID. In a typical MAC address, the first 3 bytes correspond
to the organization that created the device, called the
Organizationally Unique Identifier (OUI). This OUI portion uniquely
identifies a manufacturer, vendor, or other organization, and is
assigned by the IEEE from their IEEE Registration Authority. The
second 3 bytes of the MAC address, the Network Interface Controller
(NIC) portion, is an identifier assigned by the manufacturer (or
whatever organization was assigned the OUI). Because of how MAC
addresses are constructed, a MAC address may contain information from
which an actor/service on a local network can infer the type and/or
manufacturer of the device, which is useful for a variety of
operational and troubleshooting reasons. For example, a MAC address
Lee, et al. Expires 22 March 2021 [Page 2]
Internet-Draft Abbreviated Title September 2020
can be used to determine to which device on a LAN to permit or deny
access at a particular time of day (e.g. child's tablet may not
access Internet after 22:00 hrs until 06:00 hrs). Such services
often rely on a database or other method to map MAC addreses to a
likely device make and model, such as using a commercial service from
Fingerbank, https://fingerbank.org/about/, after which the user would
then label the device (e.g. Jane's iPhone).
Many networks today use MAC address to uniquely identify a device.
For example: Sticky DHCP assignment often maps to MAC address. In
additional, many local network policies such as port-forwarding, DMZ
setup and LAN QoS are all based on MAC address. There are also
business policies that are making assumptions on MAC address. For
example: Hospitality Internet service used in hotels, airplanes, and
Community WiFi often uses MAC address to tie to Internet
subscription.
Major operating systems have implemented and deployed MAC address
randomization to improve device and user privacy. It is common
practice on many types of networks today to use the MAC address as a
form of device identification. Some examples are LAN forwarding
policy, sticky DHCP IP assignments, static NAT policy and MAC address
ACL for blocking malicious or unwanted devices. We are interested in
determining if there is sufficient support in the IETF community to
define best practices and potentially a new protocol for service
continuity in the presence of MAC address randomization.
1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
2. Problem Statement
Recently, more and more privacy concerns are related to the static
MAC address. In particular, security community worries about people
being able to tie the MAC address to a particular device. This may
enable device tracking and tracing. To address the privacy concern,
MAC address randomization is developed. MAC address randomization is
a technique similar to IPv6 temporary IIDs defined in RFC 7217
[RFC7217]. Devices will auto-generate the MAC address based on the
device policy and use the random generated MAC address instead of the
hardware based MAC address assigned by the manufacturer when they
connect to the network. Many modern Operation Systems such as Apple
iOS (https://support.apple.com/en-us/HT211227), Google Android
(https://source.android.com/devices/tech/connect/wifi-mac-
randomization) and Microsoft Windows 10
Lee, et al. Expires 22 March 2021 [Page 3]
Internet-Draft Abbreviated Title September 2020
(https://support.microsoft.com/en-us/help/4027925/windows-how-and-
why-to-use-random-hardware-addresses) are experimenting MAC addresses
randomization. The randomization policy could be time based, network
based, combination of both and more. MAC address randomization is a
important step forward to protect user privacy. However, it will
break some applications that make assumptions of the MAC address.
In some circumstances, users may want to give the trusted network
(e.g., home network) some predictability of the MAC address for some
important services. For example, whitelisting MAC address for
network access. This document defines a set of problem statements to
continue the existing LAN services when MAC address is randomized.
[PS-01] Internet Service Provider (ISP) must not make any assumption
about the MAC address
[PS-02] ISP must not make any assumption of the Randomization Policy
[PS-03] LAN policy must not tie to a fixed MAC address
[PS-04] A mechanism must be defined to securely identify a device.
The mechanism can leverage existing protocols (e.g., EAP) or newly
defined protocol.
[PS-05] ISP and device may leverage existing protocol or define a new
mechanism to exchange information about MAC address randomization
3. IANA Considerations
This memo includes no request to IANA.
All drafts are required to have an IANA considerations section (see
Guidelines for Writing an IANA Considerations Section in RFCs
[RFC5226] for a guide). If the draft does not require IANA to do
anything, the section contains an explicit statement that this is the
case (as above). If there are no requirements for IANA, the section
will be removed during conversion into an RFC by the RFC Editor.
4. Security Considerations
All drafts are required to have a security considerations section.
See RFC 3552 [RFC3552] for a guide.
5. Normative References
Lee, et al. Expires 22 March 2021 [Page 4]
Internet-Draft Abbreviated Title September 2020
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
Text on Security Considerations", BCP 72, RFC 3552,
DOI 10.17487/RFC3552, July 2003,
<https://www.rfc-editor.org/info/rfc3552>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", RFC 5226,
DOI 10.17487/RFC5226, May 2008,
<https://www.rfc-editor.org/info/rfc5226>.
6. Informative References
[RFC7217] Gont, F., "A Method for Generating Semantically Opaque
Interface Identifiers with IPv6 Stateless Address
Autoconfiguration (SLAAC)", RFC 7217,
DOI 10.17487/RFC7217, April 2014,
<https://www.rfc-editor.org/info/rfc7217>.
Appendix A. Additional Stuff
This becomes an Appendix.
Authors' Addresses
Yiu L. Lee
Comcast
1800 Arch Street
Philadelphia, PA 19103
United States of America
Phone: +1 215 286 5894
Email: yiu_lee@comcast.com
Jason Livingood
Comcast
1800 Arch Street
Philadelphia, PA 19103
United States of America
Phone: +1 215 286 7407
Email: jason_livingood@comcast.com
Lee, et al. Expires 22 March 2021 [Page 5]
Internet-Draft Abbreviated Title September 2020
Jason Weil
Charter Communications
Orlando, FL
United States of America
Email: Jason.Weil@charter.com
Lee, et al. Expires 22 March 2021 [Page 6]