Re: [STDS-802-11-TGBH] 11-23/1314, TGbh CIDs 20 and 89 (identify clients

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

Hi Mark,

Thanks for the excellent summary on the issue and the proposal, see my further clarification inline in blue font.

Best Regards

Jay Yang (æ?¨å¿?æ?°)

Wi-Fi Standard Research Engineer

ZTE Corporation

R&D Building I, No.899 Bibo , Pudong District, Shanghai, P. R. China

T: +86 15021324431

E: yang.zhijie@xxxxxxxxxx

www.zte.com.cn

Original

From: MarkHamilton <mark.hamilton2152@xxxxxxxxx>

To: STDS-802-11-TGBH@xxxxxxxxxxxxxxxxx <STDS-802-11-TGBH@xxxxxxxxxxxxxxxxx>;

Date: 2023å¹´08æ??30æ?¥ 04:02

Subject: [STDS-802-11-TGBH] 11-23/1314, TGbh CIDs 20 and 89 (identify clients in Probe Request)

All,

I have some thoughts on our discussion in TGbh this morning, that I didnâ??t try to get into the discussion (too hard to chair and try to inject technical opinion at the same time, on topics that are this lively â?? and thank you all for the lively discussion!).

TL;DR: I support 11-23/1314â??s proposal, only in so far as adding a Measurement ID to those Probe Requests which are in response to a Beacon Report Request, and keeping the Measurement ID small. â??Keep it simple.â??

--><Jay> Thanks for your support, as most members show the support on measurement ID solution during the call, we can go with this direction.

My thinkingâ?¦:

First, I am having trouble trying to relate the comments, to the discussion and proposal. The comments both talk about use case 4.8 (from our tracking document). As a reminder, use case 4.8 is about the fact that client devices are randomizing their MAC address when sending Probe Requests. The use case describe probing in support of a Beacon Request as one example (an â??e.g.â??), but that is not the whole scope of the problem â?? the issue of the infrastructure learning about the clientâ??s RF situation, in order to help with client steering to the best AP, is actually much more likely for clients that are just scanning, and not scanning specifically to do a Beacon Report.

--><Jay> Client steering is one use case, the mechanism described above is quite enough. Another use case is for off-channel Wi-Fi sensing, as TGbf group already release 11bf draft2.0, some vendors plan to integrate some Wi-Fi sensing technology into their product. When the target stuff/human stay between the AP and the associated STA, there is no accuracy problem based on current Wi-Fi sensing technology. When the target stuff/human moves far from the current AP and near to the second AP, the accuracy will drop too much. Therefore, some implementer plan to have the off-channel Wi-Fi sensing mechanism , which help improve the Wi-Fi sensing accuracy based on consistently collect trigger probing from a certain STA by a unassociated AP. but all these mechanism rely on the identifier in the probe, 11bh identifier or the same MAC address.

That said, in our discussions, a concern was raised about infrastructure doing this sort of â??client steeringâ??, or at the very least it should only be when the client wanted steering advice in which case it could use a consistent MAC address intentionally to help. As a result, we left this feature in the tracking document as â??In scopeâ??, but â??Perhaps only recommendations in Spec.â?? (recommendations, as opposed to making this be part of the reason for a new feature).

So, in short, Iâ??m torn about the importance of this solution, and Iâ??m also not very clear about the scenarios for when it would/could be used (just for Beacon Report, or also for regular scanning).

--><Jay> The use case of client steering in post-asosciation captured from the specification defined by other WIFI standard group, please refer to Link metric collection subclause in "Multi-AP specification", while 11bh group should address the implementation broken issue caused by RMA .

Anyway, I will take a position that it would be a â??nice to haveâ?? if our infrastructure (APs ) could tell when a Probe Request is coming from a device that is scanning because it was sent a Beacon Report Request. That information, and being able to correlate the receiver information we have from the Probe Requests that come in, would be one more bit of benefit to making better roaming suggestions to the client.

I will further this position by saying that I think trying to get clients to provide any kind of identifying information in general/scanning Probe Requests is just not going to happen. First, many clients donâ??t even do active scanning anymore (or rarely). And, when they do, they are very privacy conscious of the information in those Probe Requests. And, it is too expensive (computation and OTA bandwidth) to provide identification that is encrypted sufficiently (and differently on each Probe Request?) to remove the privacy concerns. So, my view is that we give up on trying to identify such clients.

That brings me back to using this only for Beacon Report probing. For that, it really is only necessary for the â??Option 2â?? method, and for the Measurement ID to be a very small â??tokenâ??. I donâ??t see any reason that this would be exposing a client privacy concern, since any third-party can tell that there is _some_ client at its location sending frames, anyway â?? and the concept that a third-party could correlate the Probe Requests to that location (without any further information about the client) is not providing any new/sensitive information.

By similar logic (what a third-party can really learn from sniffing this), I donâ??t see any reason to change the deviceâ??s RMA /IRM during this scanning scenario. The device will be in a location, and sending all its traffic within the association context using its current MAC address. For a third-party to notice that the STA is also sending a few Probe Requests with that same address is not exposing any information that I can see. Thus, I donâ??t think there is any point in using (a new?) IRM for this.

--><Jay> There is a use case that the 3rd party only operates on a certain band. e.g. the STA associated with an AP operating on 6GHz, the 3rd party can't track and locate the STA based on STA's data frame if it only has the capability to operate on 2.4GHz and 5GHz. But if the STA always off-channel probing with the same MAC address on 2.4GHz and 5GHz in some scenario, the traceable issue may happened. That's why most smart device in current market use a different RMA in the probe after association. This behavior doesn't violate any rules according to 802.11 draft. And it can also improve user privacy in some perspective.

Therefore, a different IRM can help keep such spirit.

Of course , some members may debate that the smart attacker may capture all the frames on all ISM bands, this will be another story if we always assuming the worst case..

So, in the end, I come around to supporting the proposal in 11/23/1314 for CIDs 20 and 89, with Option 2, but with the Measurement ID element only (and we should make the Measurement ID explicitly both small (a couple octets at most) and will _not_ be an opaque identifier).

--><Jay> OK, I will remove opaque identifier stuff.

I would then resolve the CIDs 20 and 89 by noting that while use case 4.8 is covering identification information in Probe Requests broadly, the mechanism that is proposed by the TG is only to address the correlation between Probe Requests for the purpose of responding to a Beacon Report Request.

--><Jay> We can leave the broadly probe request case on CID171. And focus on the special measurement use case on CID20 and CID89.

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

Re: [STDS-802-11-TGBH] 11-23/1314, TGbh CIDs 20 and 89 (identify clients in Probe Request)