| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
| --- This message came from the IEEE 802.11 Working Group Reflector ---
Hi Luther, On 1/24/23, 6:13 AM, "Luther Smith" <l.smith@xxxxxxxxxxxxx> wrote: --- This message came from the IEEE 802.11 Working Group Reflector ---
All, Returning to the foundation of the working group, how do we fix the issues injected by RCM. If requiring the non-AP STA to do “computation” may put a burden on the non-AP STAs; however to have the AP STA do this
may be less of a burden. (Thinking of simpler, low CPU non-AP STAs such as IOT devices).
With this stated, EBSS would need to share the “device ID” to enable functions that are broken by RCM. While there are some lower level items that have depended upon the MAC address, there are also upper layer applications
there were depending on the MAC address to be static. (Captive Portal, Network access, legal intercept to name a couple).
I'm not so sure that "computation" is the issue. What are we talking about, a few hashes? IoT devices can do that and my phone has more power than the computers that took men to the moon (although the software back in the 60s was obviously
of higher quality so there's that). IMHO, it's not that the STA vendors would balk at a few hashes, it's that they don't have a compelling reason to implement anything to address the use cases we formed 11bh on. Even if the AP did all the work (which I would push back on)
there are still changes required on the STA side. Yes, we argued about some things that the user of a STA might find useful ("I want to use my phone to get targeted advertisements for peas and detergent while I roam the aisles of the supermarket!") but is
that sufficient customer demand for a vendor to put this work on a STA's roadmap given the other feature sets that are targeted for it? Color me doubtful but then I'd be interested in hearing the opinions of either of the two large handset vendors on this
matter. regards, Dan. -- "the object of life is not to be on the side of the majority, but to escape finding oneself in the ranks of the insane." – Marcus Aurelius From: Mark Hamilton <mark.hamilton2152@xxxxxxxxx>
--- This message came from the IEEE 802.11 Working Group Reflector ---
All, Please let me (the reflector) know if there is support from others for Straw Poll(s) trying to ask simply if there is consensus on a direction for pre-association scheme(s) to be “non-computation” or “computation”,
per Graham’s suggestion. Note that (per my previous email) I do think there is an outstanding request from the end of the Baltimore session to try an “Option 5” Straw Poll. We could that or Graham’s suggestion, both, or one instead of
the other. I’m open to any suggestion that seems like it might get some direction for us. Thanks! Mark P.S., Graham, I am checking on your question about recording the results of a Straw Poll. From: G Smith <gsmith@xxxxxxxxxxxxxxxxxxx>
Hi Mark, I have been thinking about the results of the polls we had and it is difficult to get a clear picture as may be the votes were split among the schemes. In an attempt to get a clearer picture of where the group wants to go I would like to propose the following Poll: “Would you vote to include in the Draft one or more of the following schemes? Non-computation schemes:
·
SMA
·
MAAD
·
IRM
·
Non-encrypted ID in IE (AP allocates)
·
Non-encrypted ID in IE (STA allocates ) Schemes with Computation:
·
IRMA
·
RRCM
·
ID encoding” I would also request if there were any objections to recording the votes. I know this is not normal but this has only been the case is only post-COVID.
Maybe Mark, would you please ask the 802.11 Exec/Chair if it were permitted to ask the group if they would agree to a recorded Straw Poll vote, and further if this has to be unanimous? Depending upon the result of the Poll, it would be a matter of searching for a scheme that had enough support. We could start by polling non-computation versus computation, for example. I would be interested in hearing others’ views, of course. Thanks Graham From: G Smith 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.
6
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 Hi Mark, Re: 5th Option This is the same as the 3rd Option. It was already polled. Graham From: Mark Hamilton <mark.hamilton2152@xxxxxxxxx>
--- 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 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 |