Re: [STDS-802-11-TGBH] Pre-association identification (was: [STDS-802-11

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

Hi Luther,

To piggy back on Ben’s comments, this is liken to hotels with captive portals that make use of MAC addresses to authorize devices on the network. In some cases a hotel will only allow a set number of devices per room. How many of us now have to go through the captive portal almost every time to get on the network that is most likely due to a new MAC addresses on the device. (I realize that there is several solutions that enable knowing the current and future MACs which should resolve this use case)

Captive portal is IETF spec right?

In your proposal, the Captive portal spec should be updated to use 802.11bh STA ID.

I am wondering why captive portals do not use higher layer ID?

Seems strange that IETF would use L2 ID which use requires updates to WLAN STAs, APs and Captive portal server.

It seems more easy to update just the captive portal server and client.

Cheers,

Jarkko

On Jul 27, 2022, at 7:11 AM, Mark Hamilton <mark.hamilton2152@xxxxxxxxx> wrote:

Ben,

The part that is a arguably a bit “fringe” is that the device would be configured to have access to the “secured side” of the network (not the guest network), but would be expected to remain only within some portions of the facility and not in others. That particular use case seems possible, but rare, to me.

To extend the guest network and secure network duality example, to apply to use cases 4.8 and 4.9, I think we would need to assume:

The guest network SSID is only available in part of the facility, with the rest of the facility having only the secure network configured. This is not fringe, but is a very common deployment method.
Some device is configured to attach to the guest network, but _not_ allowed or configured for the secure network (again, very common and normal).
Such a device now wanders into the “secure only” area of the facility. Would the device attempt to join the network (either the guest or the secure sides) while in this area, and therefore would it provide it’s “Device ID” while in this area? That might be a bit of a stretch, but I could imagine devices which are “scan happy” (like devices all used to be, not that long ago) would probably do so. Newer devices are mostly more careful to not provide such information when they are not in the range of a known network (in this case the guest network), and so the device would remain silent while in the secure area. But, it is a grey area, with multiple possible behaviors.

Luther, to your point, I agree that it would be very helpful/necessary that the device provides some identification so that the hotel network realizes this is really the same device as a previously authorized one, and hence this “new” device does not add to the device count. I’m not sure if that would need to be pre-association or not – I think it depends on how the hotel network’s onboarding system and device count blocking works.

Mark

From: Luther Smith <l.smith@xxxxxxxxxxxxx>
Sent: Wednesday, July 27, 2022 7:31 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)

To piggy back on Ben’s comments, this is liken to hotels with captive portals that make use of MAC addresses to authorize devices on the network. In some cases a hotel will only allow a set number of devices per room. How many of us now have to go through the captive portal almost every time to get on the network that is most likely due to a new MAC addresses on the device. (I realize that there is several solutions that enable knowing the current and future MACs which should resolve this use case)

Luther

From: Benjamin Rolfe <ben@xxxxxxxxxxxxxx>
Sent: Monday, July 25, 2022 5:56 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)

Hi Mark, All,

I may be misunderstanding the last case completely, but it seems not fringe at all. Most enterprises will have a guest network separate from the (more secure) network. This seems to fit the "partially known" case as the guest network will often require authorization and "remember" an authorized device that may come and go.

Not sure that helps.

Ben

From: Mark Hamilton <mark.hamilton2152@xxxxxxxxx>
Sent: Monday, July 25, 2022 3:44 PM
To: STDS-802-11-TGBH@xxxxxxxxxxxxxxxxx <STDS-802-11-TGBH@xxxxxxxxxxxxxxxxx>
Subject: Re: [STDS-802-11-TGBH] Pre-association identification (was: [STDS-802-11-TGBH] Mishandled TGbh motion vote)

+ Jakko, explicitly, as I think he asked a very similar question…

(And, my Chair hat _off_, for the moment – but to give some perspective from an infrastructure point-of-view.)

Mark,

Can't we just use BTM for client steering?

BTM is only useful after association. So, the client needs to associate somewhere (and depending on the client and the conditions that might be a good connection point, or it might not), and then get steered if needed. Note that there are a number of reasons for steering a client, and not all (in fact, not many) clients are currently aware of all these, for their initial connection decision.

For example, the best/strongest RSSI AP (which is a popular way to choose) might be very loaded, and the client might not be checking adequately for that load. Thus, it tried to connect to an AP that really can’t service it. Think the “front door” AP pointing into a parking lot, when many people arrive at a site simultaneously. Or, the first AP heard as a train pulls into a station.

Another example is when there are overlaid and coordinated ESSs/SSIDs, and the client has known “network profile” for both. These infrastructures can often figure out which network the client device really wants (for example, the employee/homeowner-private network, versus an overlaid public Wi-Fi), if it can identify the client device, and look it up in some internal database.

An example mentioned by Nokia on some recent calls is where the APs are powered down (or at least not transmitting), until they notice a known client in the area, and then they turn on and respond to its probes; for example at an office building overnight/over the weekend. (I think I have captured that right – they can correct me, if not.)

In the above cases, there are few options:

I hesitate to even bring it up, because I know I’ll hear how the 802.11 Spec says this is not allowed, but many commercial AP products will just not respond to Probe Requests, except from the AP(s) that are the best choice for where the client should attach.
The APs can adjust their Neighbor Report information, etc., in the Probe Responses to strongly suggest to the client where it should attach.
In the Nokia example, the APs don’t even “exist” (in the 802.11 sense) until they detect the known client, and only then will they respond to the Probes, etc.

Why does this need to be done prior to association; why isn't waiting for the 4WH acceptable?

Much of the above goes to answer this as well, but in particular the case where the infrastructure knows which network the client should connect to, in the multiple overlaid networks, or the Nokia powered-down scenarios, it is really painful (or impossible) to find out after you’ve already associated.

OK, but why, specifically? (for use cases 4.8 and 4.9, detecting unapproved clients)

The “why?” is a security thing. If I detect an unauthorized device in my secure building, I would like as much information about that device as possible. Of course, if the device is really completely unauthorized, I believe all of the solutions that have been proposed will not help with that identification. But, there is a corner case here, perhaps of a device which is “partially authorized” to be on the network (and thus has some identifier the network knows), but is not allowed in certain areas of the building, etc., and could be detected to be there inappropriately. I know, pretty far on the edge, that one – maybe someone else has a better real-world scenario…

Mark

From: Mark Rison <m.rison@xxxxxxxxxxx>
Sent: Monday, July 25, 2022 3: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)

Hello Graham,

Thanks for these pointers.

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.

Can't we just use BTM for client steering?

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.

Why does this need to be done prior to association; why isn't

waiting for the 4WH acceptable?

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”.

OK, but why, specifically?

Use Case 4.6 Grocery Store notifications talks about pre-recognition.

Just to be clear: I'm not saying there are no use cases for pre-association

identification. I'm currently in the "undecided" camp, and trying to decide

which side's arguments I find more persuasive! So

a presentation that hopefully will explain things better vis a vis “pre-association”, the PAR, reassociation, steering, privacy

will be helpful.

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

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