[Int-dir] Re: Intdir last call review of draft-ietf-madinas-use-cases-15

[Dave Thaler <[e-mail]>]

The MADINAS WG charter has the following milestone:




Nov 2024

Use Cases and Identity Requirements (informational) document submitted to the IESG for publication

 

That milestone does not appear to be specific to wifi or wireless.

Is the WG splitting that milestone into multiple documents, only one of which is
ready?  Or is the milestone wrong?  I note that the WG charter is not constrained

to wifi or wireless so expect MADINAS cares about links in general, not just wifi

use cases.

 

Let me know if that is incorrect or if the charter is being updated 😊

 

Otherwise, my reading is that the -15 title and abstract are correct and the
content of the document needs updating, as I mentioned in my review.

 

Thanks,

Dave

 

From: Lee, Yiu <[e-mail]> 
Sent: Wednesday, December 4, 2024 12:35 PM
To: Lee, Yiu <[e-mail]>; [e-mail]; Dave Thaler <[e-mail]>
Cc: [e-mail]; [e-mail]; [e-mail]
Subject: Re: Intdir last call review of draft-ietf-madinas-use-cases-15

 

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 <[e-mail] <mailto:[e-mail]> >
Sent: Tuesday, December 3, 2024 11:59 PM
To: [e-mail] <mailto:[e-mail]>  <[e-mail] <mailto:[e-mail]> >; Dave Thaler <[e-mail] <mailto:[e-mail]> >
Cc: [e-mail] <mailto:[e-mail]>  <[e-mail] <mailto:[e-mail]> >; [e-mail] <mailto:[e-mail]>  <[e-mail] <mailto:[e-mail]> >; [e-mail] <mailto:[e-mail]>  <[e-mail] <mailto:[e-mail]> >
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 <[e-mail] <mailto:[e-mail]> >
Sent: Tuesday, December 3, 2024 11:33 PM
To: [e-mail] <mailto:[e-mail]>  <[e-mail] <mailto:[e-mail]> >
Cc: [e-mail] <mailto:[e-mail]>  <[e-mail] <mailto:[e-mail]> >; [e-mail] <mailto:[e-mail]>  <[e-mail] <mailto:[e-mail]> >; [e-mail] <mailto:[e-mail]>  <[e-mail] <mailto:[e-mail]> >
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

https://urldefense.com/v3/__https://1drv.ms/b/s!Aqj-Bj9PNivcoIJPKEdMZa9zQhpnBA?e=hBVO2d__;!!CQl3mcHX2A!GBCd3lsTAZ6lrxBMYCIFILkQWTMRLbAk4o7obxeP9qr1dsEGj4IYH-IpSOP4dZQQ38xKZDZeeepoF64$ <https://urldefense.com/v3/__https:/1drv.ms/b/s!Aqj-Bj9PNivcoIJPKEdMZa9zQhpnBA?e=hBVO2d__;!!CQl3mcHX2A!GBCd3lsTAZ6lrxBMYCIFILkQWTMRLbAk4o7obxeP9qr1dsEGj4IYH-IpSOP4dZQQ38xKZDZeeepoF64$> 

 

[YL] Thanks. We will make the changes accordingly in next versoin.