|
Added "Wi-Fi" to the title. New title is:
Randomized and Changing MAC Address: Context, Network Impacts, and Use
Cases for Wi-Fi Network
Section 6 update:
Larger and more complex
networks can also incorporate more advanced services, from AAA to AR/
VR applications. To the network, its top priority is to provide the
best Quality of Experience to its users. Often the network contains
policies which help to make forwarding decision based on the network
conditions, the device, and the user identity associated to the
device. For example, in a hospital private network, the network may
contain policy to give highest priority to doctors' Voice-Over-IP
packets. In another example, an enterprise network may contain
policy to allow applications from a group of authenticated devices to
use ECN [RFC3168] for congestion and/or DSCP [RFC8837] for
classification to signal the network for specific network policy. In
this configuration, the network is required to associate the data
packets to an identity to validate the legitimacy of the marking.
Before RCM, many network systems use MAC address as a persistent
identity to create an association between user and device. After RCM
being implemented, the association is broken.
Section 6.1. Added the following statement:
Note that
this behavior is against standard operation and existing privacy
recommendations. Implementations must avoid changing MAC address
while maintaining previously assigned IP address without consulting
the network.
Changed "fast-paced MAC address randomization" to "aggressive (e.g., once an hour or shorter) MAC address randomization"
Added informal definition of "Hospitality environment":
Hospitality environment refers to space provided by
hospitality industry, which includes but not limited to hotels,
stadiums, restaurants, concert halls and hospitals.
I also updated the draft to version 16 which includes all other recommendations stated in the PDF.
From: Lee, Yiu <Yiu_Lee@xxxxxxxxxxx>
Sent: Tuesday, December 3, 2024 11:59 PM To: int-dir@xxxxxxxx <int-dir@xxxxxxxx>; Dave Thaler <dave.thaler.ietf@xxxxxxxxx> Cc: draft-ietf-madinas-use-cases.all@xxxxxxxx <draft-ietf-madinas-use-cases.all@xxxxxxxx>; last-call@xxxxxxxx <last-call@xxxxxxxx>; madinas@xxxxxxxx <madinas@xxxxxxxx> Subject: Re: Intdir last call review of draft-ietf-madinas-use-cases-15
@Dave: Thanks for reviewing the draft. Comments inline.
Best,
Yiu
From: Dave Thaler via Datatracker <noreply@xxxxxxxx>
Sent: Tuesday, December 3, 2024 11:33 PM To: int-dir@xxxxxxxx <int-dir@xxxxxxxx> Cc: draft-ietf-madinas-use-cases.all@xxxxxxxx <draft-ietf-madinas-use-cases.all@xxxxxxxx>; last-call@xxxxxxxx <last-call@xxxxxxxx>; madinas@xxxxxxxx <madinas@xxxxxxxx> Subject: Intdir last call review of draft-ietf-madinas-use-cases-15 Reviewer: Dave Thaler
Review result: Almost Ready Although the document has good information in it, I found a couple of important issues that I think should be addressed before publication. 1. Neither the title nor the abstract is WiFi specific (or even wireless specific). However some places in this document appear to be very WiFi specific. If the intent is to be wifi specific or wireless specific, then I’d recommend changing the title and the abstract to add WiFi or wireless in them. If the intent is not to be wifi specific (and the MADINAS WG charter implies to me that it should not be wireless specific), then some sections of the document need work to just use wifi as an example, rather than implying the point is only relevant to wifi. I called out several such places in my marked up copy. [YL] You are absolutely right. This draft is specifically about RCM in WiFi. I think we should add WiFi to the title and abstract.
2. Section 6 talks about using a MAC address to distinguish "voice traffic coming from a smartphone" from "keepalive data coming from an IoT endpoint". I think voice vs keepalive here sounds irrelevant. Wouldn’t it be more correct to remove “voice” and “keepalive data” and just say “traffic”? In such a scenario as the one described, it seems that the point it's making about using a mac identity is NOT about identifying the _traffic type_ per se (voice from smartphone vs keepalive data from a smartphone) but rather about the _device_ (voice or data from a smartphone, vs voice or data from a baby monitor). If you could distinguish the traffic type then you shouldn’t need the mac identity since you could prioritize voice (whether from phone or from baby monitor) over keepalive data (whether from phone or from baby monitor). So the example in section 6 doesn't make sense to me as written. [YL] We will remove voice and keepalive, and replace with traffic or data packets. I heard your argument. MAC isn't relevant to distinguish application type. This draft should only mention what MAC can be used,
We will go back and rework Section 6.
3. Section 6.1 says "Changing the MAC address, even at disconnection-reconnection phase, without changing the IP address, may disrupt the stability of these mappings for these peers, if the change occurs within the caching period." This is true, but that would generally be a bad idea anyway since then you’d have persistent linkage by IP address which would defeat the purpose of the MAC randomization in the first place. So saying it may disrupt the stability is a relatively minor issue to point out by comparison. It’d be better to rephrase to point out that this issue should not exist if devices actually follow existing privacy recommendations. [YL] Agreed. Will fix it in next version.
4. Section 6.2 says about public Wi-Fi that "Privacy is the number one concern for the user." Really? Can you cite a study that supports this claim? I’d think that reliable connectivity (no connection drops) and bandwidth may be higher priority concerns for many users, especially novice users (e.g., kids) who are unaware of the privacy dangers. [YL] How about replacing it to "Privacy is a major concern for many users"?
5. A couple of terms are used without definition and I find hard to follow: - Hospitality environment - "fast-paced" MAC address randomization (as opposed to fast paced MAC address _changing_) - over-solicited [YL] We will address those terms in next version.
A PDF copy with my comments and a bunch of editorial nits inline can be found at [YL] Thanks. We will make the changes accordingly in next versoin.
|
-- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
