| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Another thing*… how is this going to be explained to the user? It's gonna have to be on a per-profile basis because there's some SSIDs you might want to roam to regardless of what the location is, think of "xfinity" or "boingo" if you
had such a service, or "ieee" or "marriot_guest" if you attend 802.11 meetings. "Check this box if you want to restrict access to geographically specific APs". "Huh?", said Joe Random. Then imagine the debugging issues when Joe Random calls the Boingo IT helpline because he's paying all this money and it doesn't
work. regards, Dan. * yea, I don't work for a STA vendor but I keep hearing people who do complain about this or that feature because their UI is getting cluttered and confusing. -- "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 On 8/18/22, 1:43 PM, "Luther Smith" <l.smith@xxxxxxxxxxxxx> wrote: Joseph and All, It seems to be confusing in the later part:
“This mechanism should allow the non-AP STA to limit its transmission of Probes Requests and Association Requests to a known AP to a location where the known AP is actually present (i.e., not to a spoofed AP). “
Based on the text it appears that the non-AP STA will be able to limit Probes Requests and Association Request to a known AP and it is linked to the location of the AP. Could this be read that if the known AP is
at a different location the non-AP STA does not have the mechanism limit the messages? As well we may not want to link the AP location (use case would be a mobile AP).
Maybe the following: This mechanism should allow the non-AP STA to limit its transmission of Probes Requests and Association Requests to
an AP which appears to be known to the non-AP STA; however, is not the actual known AP. (i.e., not to a spoofed AP). Cheers, Luther From: G Smith <gsmith@xxxxxxxxxxxxxxxxxxx>
Love it. My excuse is that I obviously have not understood the BPE/CPE concept. Thanks Joe, Graham From: Joseph Levy <Joseph.Levy@xxxxxxxxxxxxxxxx>
Hi Graham and All, A couple questions/comments:
1)
Graham what was your motivation to restrict this mechanism to a BPE AP? I don’t think it is a necessary restriction.
2)
I think the proposed requirement could be more clearly stated so the privacy advantage is clearer, how about: Regards, Joseph From: G Smith <gsmith@xxxxxxxxxxxxxxxxxxx>
Thank you for the comments and feedback on 22/1253r0 on the subject of protection against a Spoof AP. I am considering proposing the following text for insertion into 21/1848 Requirements document:
•
11bi shall define a mechanism for a BPE AP to be identified such that a BPE Client can confirm that the AP is not a spoof AP. Hence, the BPE Client will not send an Association Request and reveal its presence. I welcome any suggestions or comments Thanks Graham To unsubscribe from the STDS-802-11-TGBI list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBI&A=1 To unsubscribe from the STDS-802-11-TGBI list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBI&A=1 To unsubscribe from the STDS-802-11-TGBI list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBI&A=1 To unsubscribe from the STDS-802-11-TGBI list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBI&A=1 |