Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

[STDS-802-11-TGBH] Update points for WBA, on TGbh review of their liaison



Dorothy,

 

(FYI, to TGbh members.  If anyone believes I missed anything, or mischaracterized our analysis, please respond/let me know.)

 

Here are some notes for your update to WBA (next week?), to capture 802.11 TGbh’s review and discussion of the liaison WBA sent to us on April 14 (“The WBA's Wi-Fi Device Identification project would like to share with you their initial investigation into the problems of device and user identification posed when the MAC address is no longer used as an Identifier”).

 

802.11 TGbh have considered the document attached to the liaison, “Wi-Fi Identification Scope, in a post MAC Randomization Era”.  We noted the following sections to be relevant to our work on Randomized and Changing MAC addresses, with the following informal comments (below).  It is TGbh’s intention to capture these comments more formally in an “Issues Tracking Document” final version, that is intended to be a historical reference of TGbh’s thoughts, and potentially to add material to IEEE Std 802.11 as mentioned below:

  • MAC [address] collisions:
    • Recommend adding explanatory text to 802.11 to explain how the material added with IEEE 802.11aq can be used, and on the number of bits to randomize to help avoid duplication.
    • Recommend adding explanatory text on how to use ANQP to communicate an IEEE 802c-based policy for MAC address usage.
    • We will consider explanatory text suggesting ways to check for collisions and take action if a collision occurs.
    • We will consider adding a capability to IEEE 802.11 to protect the ANQP exchange on MAC address policy, especially in the case when the policy is “use your ‘true’ MAC”.
  • Accounting and billing issues:
    • TGbh does not understand how CUI can be used for accounting and billing, since it is another temporary identifier.
    • Consider an option for the station (client device) to identify itself to the network in a protected manner and with an identifier that is appropriate for the particular network.
    • This seems generally similar to our uses case for post-association identification of a client device, for uses such as Parental Controls, Home Automation, and Frequent Shopper scenarios.
  • Quality of Service (QoS) and Quality of Experience (QoE):
    • Again, this seems similar to the use cases mentioned just above.
    • TGbh is trying to understand if there is also a concern being raised for AP-AP roaming (in a multiple AP infrastructure network).  For this concern, TGbh notes that 802.11 requires a stable MAC address for the lifetime of an association to an ESS.
    • There may be an application of 802.11’s SCS and mirrored SCS mechanisms to the QoS scenarios, as well.
  • DHCP pool exhaustion:
    • TGbh broke out some of the “DHCP and ACL” use cases/impacts into separate scenarios to consider.
    • Consider a recommendation that DHCP lifetimes be set to less than typical MAC randomization intervals.
    • Consider a recommendation that the DCHP client identifier be used to detect when the same client device requests an IP address for different MAC addresses.
    • Similar to above, an option for the station to identify itself to the network in a protected manner could also be a solution.
  • DHCP allocation of fixed IP address:
    • Very similar to just above, except the DHCP lifetime control is not a solution here.
  • ACLs/firewalls:
    • Again similar to the above.
    • A unique consideration is if the ACL is IP-address based, then solutions for the DHCP assignment of IP-addresses could address this use case as well.
    • We also noted that some ACL behaviors may be applied pre/at-association time, so one of the post-associations solutions may not solve the issue.
    • If the ACL is for security purposes, then any identifier provided by the client device now must be authenticated to the same level of security.  Of course, we note that MAC addresses were never very secure, nor authenticated, in the past.

 

I wasn’t sure what format/style your update would be, and therefore how much detail to include.  Let me know if I can help boil this down to a few bullets, or whatever, as appropriate.

 

Thanks.  Mark


To unsubscribe from the STDS-802-11-TGBH list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBH&A=1