Hi Jarkko,
On 7/26/22, 2:58 PM, "Jarkko Kneckt" <00000d5619618f4f-dmarc-request@xxxxxxxxxxxxxxxxx> wrote:
JKN: To my knowledge, the pre-association steering operation that requires identification of a STA is not described in 802.11 specifications. 802.11 defines general broadcast level steering, where AP delivers in
Beacons and probe responses broadcast out-of-band information by using Reduced Neighbor Report (RNR). This information may help scanning STAs in hurry to select the next channel for scanning and it may help to find some APs faster than other APs.
There's lots of stuff that is done in 802.11 that is not described in the 802.11 specification. Basically, the entire logic of when a STA decides to roam is not described in 802.11 but STAs do make such a determination anyway. So I don't
think that some AP behavior that is, likewise, not defined in 802.11 is out of bounds. What's good for the goose (STA) is good for the gander (AP).
The pre-association steering discussed 802.11bh aims to provide STA specific steering. The AP needs to identify the STA and then know how to steer the identified STA to the correct AP. I think this is problematic
in many ways:
Why does the identity need to be determined? This was done with static MAC addresses without knowing the STA's identity so the problem introduced by randomized MAC addresses isn't due to the AP needing to identify the STA. It just needs
to know that some STA on 2.4 is the same STA on 5, the identity is irrelevant, and to provide sufficient hints to the STA to do the right thing.
- STA has no knowledge that it is providing its identity to the correct AP. There is no authentication of the AP to the STA.
And none needed.
- I do not know how this pre-associated STA steering is done:
- Some examples suggests that AP is not discoverable for this identified STA, but I thinks this is not possible. STAs will passively scan all available APs, so hiding a BSS from the identified STA is not possible.
It's not a discoverability thing, it's that the AP will neglect a STA on a band that is not preferred. If the AP doesn't want to provide you with service on 2.4 then it won't respond to your efforts to advance the 802.11 state machine on
that band on that AP.
- To me the only STA specific pre-association steering operation seems to not allow association requests from the AP. This will be bad for the STA, because the STA does not know why the association was rejected.
It would be much better solution to allow the STA to associate and then perform STA specific steering with BTM frames.
The AP doesn't send association requests.
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
will be helpful.
I will try
Thanks,
Mark
--
Mark RISON, Standards Architect, WLAN English/Esperanto/Français
Samsung Cambridge Solution Centre Tel: +44 1223 434600
Innovation Park, Cambridge CB4 0DS Fax: +44 1223 434601
ROYAUME UNI WWW: http://www.samsung.com/uk
From: G Smith <gsmith@xxxxxxxxxxxxxxxxxxx>
Sent: Monday, 25 July 2022 21:55
To: STDS-802-11-TGBH@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBH] Pre-association identification (was: [STDS-802-11-TGBH] Mishandled TGbh motion vote)
Hi Mark,
The main idea behind using a “one-time MAC address” is that noting that the fixed MAC address was for many years used as the ‘identifier’, and that is what caused RCM to happen. If the MAC address can still be the ‘identifier’, then applications that used it before, should be able to use it again. The big difference being that now, only the particular BSS/ESS recognizes that one-time address. Hence, Applications that used the MAC Address as the identifier before RCM should be able to be easily adapted, i.e. a true TGbh solution, as per the PAR.
Then, to distinguish the idea of using a “one-time MAC address” from the “Device ID” post association scheme, it became easier to refer to these other schemes, where the non-AP STA can be recognized from the Association Request, as “pre-association schemes”. That is the where the name comes from but it is not true that the so called “pre-association schemes” are restricted to just pre-association, they are simply schemes where the non-AP STA is identifiable from its TA.
Having said that, there are Use Cases of particular interest where the non-AP STA (mobile) is able to be recognized before it associates, including being recognized from the Association Request. The Issues Tracking document 21/0332 is supposed to be the place which captures all the Use Cases but have to admit the definitions and descriptions of those Use Cases is not always that clear.
Use Case 4.1 is labelled “Pre-Association Client Steering” but the description has changed so much that it is now not that clear, and I may not the best expert to describe it correctly as the description therein does not seem to describe the title. However, the idea, as I understand it, is that a mobile probes the ESS and the ESS/BSSIDs recognize the mobile and respond such that the mobile is steered to the “best” BSSID. This can be done before association.
Use Case 4.2 is based upon Parental control but generally also covers cases where the mobile may be identified from the Association Request (or directed probes) such that it is allowed (or not) to associate and/or certain settings applied. Conversely, non-recognized mobiles can be dealt with. Also we have similar Use Case 4.3 Home Automation, such as, for example, the lights are switched on.
Use Case 4.8 talks about “A managed WLAN network may desire to detect unapproved client stations operating in its service area, even when they do not (cannot) connect to the network”, the converse being Use Case 4.9 “A managed WLAN network may desire to detect unapproved client stations operating in its service area, even when they do not (cannot) connect to the network”.
Use Case 4.6 Grocery Store notifications talks about pre-recognition.
Hopefully others will chime in with better explanations and maybe other cases.
As a result of the 15/14 vote, I am working on a presentation that hopefully will explain things better vis a vis “pre-association”, the PAR, reassociation, steering, privacy. Hopefully this will be ready for prime time soon.
Regards
Graham
From: Mark Rison <m.rison@xxxxxxxxxxx>
Sent: Monday, July 25, 2022 12:02 PM
To: STDS-802-11-TGBH@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11-TGBH] Pre-association identification (was: [STDS-802-11-TGBH] Mishandled TGbh motion vote)
Could I ask the proponents of pre-association identification to succinctly
describe one or more specific use cases where this would be useful, please?
(Or point me at certain slides in a submission, if this has already
been done.)
Thanks,
Mark
--
Mark RISON, Standards Architect, WLAN English/Esperanto/Français
Samsung Cambridge Solution Centre Tel: +44 1223 434600
Innovation Park, Cambridge CB4 0DS Fax: +44 1223 434601
ROYAUME UNI WWW: http://www.samsung.com/uk
From: Mark Hamilton <mark.hamilton2152@xxxxxxxxx>
Sent: Friday, 15 July 2022 13:45
To: STDS-802-11-TGBH@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11-TGBH] Mishandled TGbh motion vote
All,
I have made a large mistake, and I apologize to the group.
I failed to properly save the results of the voting on our motion in Thursday’s TGbh session: “In order to meet the PAR, the TGbh Amendment shall include a scheme or schemes that address the pre-association use cases 4.1 and 4.2 in Document 21/332r37”. As a result, while we have the raw vote results (15-14-5, “procedural” voting rules, meaning a 50% passing threshold, so that count results in “Passed”):
· Those results cannot be verified. As the vote was so close, clearly if there were any voting irregularities, it could affect the result.
· The vote was requested to be a recorded vote, but the detail records are lost, and I don’t believe there is any way to get that information.
At this point, there seems to be nothing I can do, but to apologize to the group and the mover and seconder. Thus, my sincere apologies.
All that said, I would like to remind everyone that even if this motion’s results were properly recorded in detail, those results show that the group is clearly split on this topic. Our work cannot proceed until we find a consensus with support by at least 75% of the members on our technical decisions related to this (and other) technical topics. I strongly suggest that proponents and opponents on these topics PLEASE take some actions to help the group progress.
I strongly encourage discussion, either off-line with individuals that have expressed interest or an opinion to understand each other’s’ opinions, or on the reflector to pull in all the interested members and work toward a broad consensus. A reminder, once again, we need to find a consensus for our work to progress, so when decisions reach an apparent impasse, it is very important to dig in more deeply to understand the root of the disagreement, and try to find compromise.
Thanks. And, again apologies for the process error!
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
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
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
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
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
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