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