Skip to main content

Liaison statement
Liaison statement on Randomized and Changing MAC Address

Additional information about IETF liaison relationships is available on the IETF webpage and the Internet Architecture Board liaison webpage.
State Posted
Submitted Date 2023-12-01
From Group IEEE-802-1
From Contact Glenn Parsons
To Group madinas
To Contacts Carlos Jesús Bernardos <cjbc@it.uc3m.es>
Juan-Carlos Zúñiga <juzuniga@cisco.com>
Cc Carlos Jesús Bernardos <cjbc@it.uc3m.es>
Erik Kline <ek.ietf@gmail.com>
Éric Vyncke <evyncke@cisco.com>
Juan-Carlos Zúñiga <juzuniga@cisco.com>
MAC Address Device Identification for Network and Application Services Discussion List <madinas@ietf.org>
János Farkas <janos.farkas@ericsson.com>
Response Contact Paul Nikolich <p.nikolich@ieee.org>
Glenn Parsons <glenn.parsons@ericsson.com>
John Messenger <JMessenger@advaoptical.com>
Purpose For action
Deadline 2024-01-31 Action Needed
Attachments
Body
The IEEE 802.1 Working Group has reviewed the draft "Liaison on Randomized and
Changing MAC Address" (draft-ietf-madinas-mac-address-randomization-09) and has
the following comments:

(1) Regarding the paragraph beginning “The IEEE 802.1 working group …” we
propose replacement with a version that more accurately summarizes the SLAP:

IEEE Std 802 [IEEE_802], as of the amendment IEEE 802c-2017 [IEEE_802c],
specifies a local MAC address space structure known as the Structured Local
Address Plan (SLAP). The SLAP designates a range of Extended Local Identifiers
(ELIs) for subassignment within a block of addresses assigned by the IEEE
Registration Authority via a Company ID (CID). A range of local MAC addresses
is designated for Standard Assigned Identifiers (SAI) to be specified by IEEE
802 standards. Another range of local MAC addresses is designated for
Administratively Assigned Identifiers (AAI) subject to assignment by a network
administrator.

(2) Regarding (1), we suggest adding to [12] the reference:

[IEEE_802] "IEEE Std 802 - IEEE Standard for Local and Metropolitan Area
Networks: Overview and Architecture", IEEE 802, 2014.

(3) We propose deleting unintelligible information from some of the referenced
IEEE standards; namely, "architecture, 8. W. -. 8. L., " from IEEE_802c,
"architecture, 8. W. -. 8. L., " from IEEE_802E, and "Group, 8. W. -. W. L. W.,
" from IEEE_802_11_aq.

(4) A major conclusion of the work in IEEE Std 802E concerned the difficulty of
defending privacy against adversaries of any sophistication. In particular it
has been shown that individuals can be successfully tracked by fingerprinting
using aspects of their communication other than MAC Addresses or other
permanent identifiers. Machine learning techniques facilitate fingerprinting
without the adversary needing to understand the technical reasons for the
correlation. There is a danger in the short reference currently in the MADINAS
draft that the reader might conclude that replacing a permanent identifier with
a temporary identifier *will improve* privacy, as opposed to avoiding making
things worse if the other contributions to fingerprinting have been addressed -
"reaching the conclusions" can overstate the expected privacy gain. The issue
of identifiers relates not just to service quality in any narrow sense, but
more broadly to providing service. The recently completed IEEE Std
802.1AEdk-2023: MAC Privacy protection includes an Informative Annex responding
to the IEEE Std 802E call for privacy study.

(5) Regarding the paragraph beginning with “Work within the IEEE 802.1 Security
task group… “ we propose a replacement that is more accurate:

IEEE Std 802E-2020: Recommended Practice for Privacy Considerations for IEEE
802 Technologies [IEEE_802E] recommends the use of temporary and transient
identifiers if there are no compelling reasons for a newly introduced
identifier to be permanent. This Recommended Practice is part of the basis for
the review of user privacy solutions for IEEE Std 802.11 (aka Wi-Fi) devices as
part of the RCM [rcm_privacy_csd] efforts. Annex T of IEEE Std 802.1AEdk-2023:
MAC Privacy Protection discusses privacy considerations in bridged networks.

(6) Since all readers may not be aware that IEEE 802 standards are available
for free from the IEEE GET program, we suggest including this information at
the beginning of the Informative References section:

IEEE 802 standards are available free via the IEEE GET Program at
https://ieeexplore.ieee.org/browse/standards/get-program/page/series?id=68.

(7) In the introduction text of this draft, reference is made to cellular
networks. These networks do not (currently at least) use MAC addresses. It is
suggested to remove the reference to cellular to avoid confusion.

Thank you for your consideration of these matters, and we welcome continued
collaboration going forward.