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

Re: [STDS-802-11-TGBH] Pre-association identification (was: [STDS-802-11-TGBH] Mishandled TGbh motion vote)

Hi Amelia,

 

Luther makes the good point, your proposed solution will bring a great challenge to the implementation if we design different solutions to cover both legacy STA and 11bh STA.

It’s true that there are a lot of tools to implement the access control in post-association in enterprise network product, like BYOD SSID, VPN, portal and IT department, etc.

But we have to consider this function in residential environment and mobile AP product as well.

E.g. In the android cellphone/mobile AP menu, where is no portal, BYOD SSID or IT department, the simple way to implement the access control is to have a blocklist/allow list, as shown in following snap.

Anyway, use case 4.2 is pretty correct as the group consider the access control in both pre-association and post-association to cover different AP products.

 

Diagram Description automatically generated

 

 

 

Thanks

 

Best Regards

 

Jay Yang

 

From: Luther Smith <l.smith@xxxxxxxxxxxxx>
Sent: 2022年7月29日 21:30
To: STDS-802-11-TGBH@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBH] Pre-association identification (was: [STDS-802-11-TGBH] Mishandled TGbh motion vote)

 

I reviewing the comments, here is my inputs:

  • Is it not the nature of Wi-Fi to be backwards compatible, with that stated we cannot control how legacy non-AP STA and AP STA work as they are already in the wild or still being manufactured.
  • The use of a POI or Device ID is understandable and application could be updated to support this, however, again to go to backwards compatibility. Apps would have to relay on both MAC address for non-AP STA that do not support the new schema of POI or Device ID.
  • In the case of POI or Device ID, there needs to be a method for purging these as they may be a one time (limited time) use. Granted this is beyond TGbh but we should at least considered the impacts. (Noting that the AP STA could purge POI or Device IDs, but the non-AP STA would not know when that POI or Device ID have been purged from the AP STA and thus does not know when it could be purged internal to the non-AP STA. Again this is outside the scope of TGbh but we should consider the impacts on all types of STA (AP and non-AP).
  • I agree that applications are beyond the TGbh, however, root AP and non-AP STAs functions need to be, I am not sure where the line is between STA functions and applications. Does access/deny list fall under the AP STA function or at some application layer as an example.

 

Respectfully,

 

Luther

 

 

Luther E. Smith

Director Wireless Access Technologies/ Distinguished Technologist

CISSP

 

303-661-3305  voice
303-661-9199  fax

303-931-1759 mobile

www.CableLabs.com

 

 

 

 

From: Amelia Andersdotter <amelia.ieee@xxxxxxxxxxxxxxx>
Sent: Friday, July 29, 2022 3:17 AM
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 all,
 
I continue to be perplexed by why the POI (using Antonio's suggested 
terminology from earlier) generated by the network could not satisfy the 
use-cases.
 
To set up parental controls, surely the non-AP STA needs some prior 
relationship to the ESS. The establishment of this relationship (during 
association, for instance) would enable a POI to be set (a "WLAN cookie" 
if you will). The POI would also be set in a hotel. The hotel network 
could refuse to issue more than 4 POI per room and the non-AP STA device 
could indicate to the user that the privacy setting needs to be 
configured. Captive portal texts + mobile OS interfaces (=higher layers) 
would deal with human interaction based on the mechanism we're currently 
specifying.
 
If an ESS wants an allow-list for itself, that allow-list would have to 
be set up somewhere, for instance by associating the allowed non-AP STA 
(I imagine in a corporate environment, even with BYOD policies in place, 
if this is a strong concern there should be a procedure involving some 
IT department person - even if you used a legacy MAC for this purpose it 
would have to be reported and inserted in some allow-list so could just 
as well be made with a POI).
 
If TGbh moves in the direction of creating a non-MAC MAC that keeps all 
the flaws of the legacy MAC I do not think this is PAR conformant in the 
sense of "privacy". But what we could discuss is for instance if we want 
a recommendation on how often to change a MAC address during discovery 
or similar - I'm aware of several parallel discussions (including at the 
IETF) about the prospect of "rapidly changing MAC addresses breaking 
", but it's unclear to me what "rapidly" means and whether any 
instances of such "rapid changes" have been observed in the wild. I 
don't see that we would have a technical motivation for being concerned 
with changes that occur less often than, say, once per minute.
 
best regards,
 
Amelia
 
On 2022-07-28 22:43, G Smith wrote:
> 
> I can see Thomas’s point but the problem a lot of us seem to be facing 
> is that we are not the folks who have been directly affected by RCM.  
> I, for example, simply assumed that as the MAC address was being used 
> as the identifier, certain applications/uses did not work anymore or 
> were rendered useless due to RCM.  Now are we saying that, further to 
> those in 11aq, some rules might be required for RCM to even work in 
> some important areas, such as “steering” -  but, as Thomas says, is 
> that within TGbh to fix?
> 
> We have, for example, on our plate Use Cases such as “pre-association 
> steering”, “ allowed/disallowed steering”, “Parental controls”, 
> “managed network steering” and maybe some others.  It would be nice to 
> know in detail how these worked pre-RCM and to understand how 
> important or not the recognition or pre-recognition of the non-AP STA 
> is so that we can see if Device-ID solves it, or not.  I, and others, 
> took the approach that 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 only the particular 
> BSS/ESS should recognize that address.
> 
> So, I think we do have to at least find out how certain applications 
> worked “pre-RCM” and what they achieved.  If we stick to only the 
> Device ID scheme then if there were apps that identified the non-AP 
> STA pre-association, then we have not covered them.  That should be 
> our mission, it is not up to us to judge or, as Dan often said, tell 
> them how to do it better.
> 
> Hence at this stage, I am simply asking if those with the knowledge 
> can describe clearly what the applications in question really did and 
> how they did it, then we can see if we need to add another scheme or 
> schemes to the TGbh Draft.
> 
> At the moment I am reading several comments that seem to be saying 
> that these applications do/did exist, they were useful, and we should 
> be covering them.  So once again, I am asking for some clear details, 
> from those who know, how these apps worked.  As our Chair opined, It 
> is not up to us to determine the merits and then decide if they are 
> good applications or not, it is up to us to produce scheme(s) that 
> enable these and possible other future applications to work.
> 
> Thanks, and hoping that those with actual knowledge of these 
> applications can now chip in with “how they did it” and “why now they 
> don’t work”.  Of course, I could have a stab at how they probably 
> worked, but I don’t want to do that.
> 
> Thanks
> 
> Graham
> 
> *From:* Thomas Derham <00000ad2eabc2931-dmarc-request@xxxxxxxxxxxxxxxxx>
> *Sent:* Thursday, July 28, 2022 1:48 PM
> *To:* STDS-802-11-TGBH@xxxxxxxxxxxxxxxxx
> *Subject:* Re: [STDS-802-11-TGBH] Pre-association identification (was: 
> [STDS-802-11-TGBH] Mishandled TGbh motion vote)
> 
> Thanks Mark, all.
> 
> I agree in general with your description of the 11bh scope. However I 
> think part of the disagreement here relates to the level of detail and 
> assumptions associated with a given use case.
> 
> For example, there is a substantial difference between 11bh addressing 
> a use case where "a network can influence which BSS in a network an 
> RCM client initially connects to” (a high level use case)…
> 
> vs 11bh addressing a use case where “a network can influence which BSS 
> in a network an RCM client initially connects to by correlating 
> multiple probe requests sent by the client and selectively suppressing 
> probe responses” (a use case and a description of a specific technique 
> used).
> 
> While the specific technique described above has been effective for 
> legacy clients (and, yes, deployed quite broadly for many years), it 
> relies on multiple assumptions on client behavior which are not 
> mandated in the standard and (I am asserting) are no longer valid for 
> many modern client devices. Specifically, while historically most-all 
> client devices have performed discovery using exhaustive active scan 
> (sending probes), this is no longer true due to:
> 
>   * (a) implementation of power-efficient passive scanning
>     technologies on client devices, and
>   * (b) standards-defined rules that constrain probe request
>     transmission by clients (FILS, 6 GHz, ..), and
>   * (c) use of out-of-band discovery (and standards-defined rules for
>     advertisement of such information) such that discovery of a given
>     BSS also results in discovery of other BSSs
> 
> Given this particular technique is “broken” not only by RCM but also 
> by other capabilities in the standard and other (standards-compliant) 
> client implementations, I do not think it is in-scope for 11bh to try 
> to “fix” the RCM aspects of the issue given that, even if those are 
> fixed, the technique itself will still not be viable.
> 
> Rather, we should focus on other (preferably standards-defined) 
> capabilities to achieve same/similar high-level objective, and ensure 
> those will work with RCM clients.
> 
> Examples of these capabilities include Neighbor Report ANQP element, 
> association rejection / comeback delay, and AP metrics that influence 
> clients’ BSS join decisions based on link quality assessment.
> 
> These might or might not be 100% equivalent to the legacy techniques 
> from a functional perspective, but really that is irrelevant given the 
> above.
> 
> Thanks
> 
> Thomas
> 
> On Jul 27, 2022 at 7:18:15 AM, Mark Hamilton 
>  wrote:
> 
>     All,
> 
>     (This time, with my Chair hat on…)
> 
>     I would just like to note to those following this thread, that we
>     seem to have left the discussion of understanding this use case
>     (or these use cases), or discussing whether this is a use case
>     that used to work (before RCM) and has been broken by RCM. Rather
>     we now seem to be discussing whether we think it is a good
>     thing/necessary to make this use case work again, or if some other
>     approach is preferred.
> 
>     I don’t mean to pass any judgment on such discussion, but I’ll
>     note that our scope was to consider use cases that used to work,
>     and have been broken. Whether the “solution” to those situations
>     should be to replace the prior operation, or require deployments
>     to use other alternative methods to accomplish similar results, is
>     getting into a grey area.
> 
>     Just something to keep in mind, before we get too far into debate
>     over preferred ways to address these scenarios.
> 
>     Mark
> 
 
-- 
^\...~...~...~...~...~.../^
Amelia Andersdotter (affiliation: Comcast)
^\...~...~...~...~...~.../^
 
________________________________________________________________________
To unsubscribe from the STDS-802-11-TGBH list, click the following link: https://protection.greathorn.com/services/v2/lookupUrl/0246af11-5bd5-411a-9493-6bfd60972477/327/741d2285b2d7489748fc0363cbf1e68336f38a70?domain=listserv.ieee.org&path=/cgi-bin/wa

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