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

Re: [STDS-802-11] TGbh conference calls announcement

--- This message came from the IEEE 802.11 Working Group Reflector ---

Just noticed Option 5 is slightly different to option 3 in that the ID is supplied by the network.  In option 3 the ID was supplied by the STA.  The reasoning behind that was that we already had a network generated ID. 

Anyhow, if we want to make the list completely complete, then we should also add MAAD.

 

  1. MAAD scheme
    • AP picks MAC to be used next time, as per present rules (local bit).
    • AP tells STA the MAC address it should use for the next association
    • STA maintains list of ESS/SSIDs and latest MAC Addresses.
    • AP maintains list of STA addresses
    • Needs an “opt-in” mechanism (Capability bit or MIB variable?))
  • ADs
    • Simple, easy to implement. 
    • Similar level of privacy as RCM (random MAC address for listener)
      • Network can track STA
    • Provides good protection against copying
    • Meets every Use Case
    • No computations
  • DIS
    • STA is constrained to MAC provided by AP last time.

 

Maybe a way ahead is to simply see if there is any way forward at all wrt pre-schemes.

 

A Poll to have pre-schemes at all

Then

A poll along the lines of “pre-schemes with or without computations”

 

Graham

 

From: G Smith
Sent: Sunday, January 22, 2023 10:37 AM
To: mark.hamilton2152@xxxxxxxxx; STDS-802-11@xxxxxxxxxxxxxxxxx
Subject: RE: [STDS-802-11] TGbh conference calls announcement

 

Hi Mark,

Re: 5th Option

This is the same as the 3rd Option.  It was already polled.

 

Graham

 

From: Mark Hamilton <mark.hamilton2152@xxxxxxxxx>
Sent: Saturday, January 21, 2023 8:04 PM
To: STDS-802-11@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11] TGbh conference calls announcement

 

--- This message came from the IEEE 802.11 Working Group Reflector ---

All,

 

With 10 days’ notice, as mentioned at the closing plenary yesterday, I am announcing TGbh teleconferences on the following Tuesdays, at 9:30 am ET, for 2 hours:

  • Jan 31
  • Feb 7
  • Feb 14
  • Feb 21
  • Feb 28

 

Agenda and call in details will follow, shortly.

 

Also note that I will be able to attend or chair the call on Jan 31, so one of the Vice Chairs will step in (thanks, Peter and Stephen!).

 

I anticipate that further discussion on the “5th option”, as described below, will be our next item of discussion on the way forward topic.  REMINDER: I am looking for a volunteer to champion/lead this discussion.  And, we need to complete the review of the latest proposed resolutions for comments on the D0.2 text.

 

5th option:

    • Network generates an ID, communicated in 4-way handshake (similar/as done in D0.2)
    • STA returns that ID in a new IE in a non-encrypted frame at next association (Association Request?) and/or pre-association frames
    • ID is changed every association
    • STA maintains list of ESS/SSIDs and IDs.
    • Needs an “opt-in” mechanism
  • Advantages
    • Simple, easy to implement
    • Provides good protection against copying
    • Meets every Use Case
    • No computations
  • Disadvantages
    • Requires new IE
    • Needs to specify some uniqueness to ID (6 octets?)

 

 

Thanks.  Mark

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

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