Re: [STDS-802-11-TGBH] Observations and simplicity

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

Thank you Mike and Graham for responding,

As neither a device nor AP vendor, but a representative of operators of the technology that have the burden of making it work and having subscribers that report issues, troubleshooting issues is one of the huddles of daily operators. The second is providing services both to users and complying with legal enforcement.

Several on the call reported time consumed troubleshooting that was increased by RCM which is also felt by operators. This could have been reduced if the same MAC address was in use, so how do we work with RCM to enable living with RCM or as Graham put it SMA and enable operators of networks to troubleshoot issues as well continue to provide services and at the same time make it simple that device and AP vendor are willing to include it.

To Graham’s point and something I did not think about, changing the Device ID every time would loss the function of having a long term mutual identity of the device with the AP that would allow for some of the services (yes these are upper layer services that made use of the MAC addresses but never the less services that are used by Wi-Fi) to continue to operate. The use of proposal such as IRM which a every changing MAC address ever time would result in the privacy OTA which accomplishes the reason for RCM. Since the AP would have the link between the Device ID and the MAC address in use, an operator (and only the operator of the network which has access to the AP) would have access to the linking of the Device ID to the MAC Address (or could put the AP into a “debug mode” to maintain the same MAC address while debugging) which would allow the operator to troubleshoot an issue.

Again going back to the basics – keeping it simple, enabling privacy (or at least reducing ability to track), and maintaining current services – the three items in the PAR as I read the PAR.

Thank you all for listening (or reading) my view points.

Luther

From: G Smith <gsmith@xxxxxxxxxxxxxxxxxxx>
Sent: Tuesday, February 28, 2023 3:47 PM
To: STDS-802-11-TGBH@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBH] Observations and simplicity

Good points, and I would like to make some observations of my own. Sorry that it may be long, but, as I hope that others may realize, I spent a lot of time and effort on this TG and I strived to make presentations on all my points, rather than just make comments during a meeting.

“Keep it simple” – yes could not agree more.

Take the ‘de facto’ scheme presently in use; STA uses same MAC Address when returning to the same network (I termed this “SMA”, Same MAC Address). Based on this, I am surprised that some STA vendors are stating that they do not want to have any restriction on having to use a MAC Address, isn’t that exactly what is happening in SMA? Also, it is the STA that chooses the MAC Address to use, so I don’t quite follow that logic when used against other proposals.

So, what is the problem with SMA? Only that the same address is reused, so easy to identify and copy – this is enough to make it not meet the ‘privacy’ requirement.

So what is the next logical step? Simple, change the MAC Address each time…. enter IRM proposal. The STA gives a MAC Address to the AP, in the 4w HS, that the STA will use the next time. The STA chooses the MAC Address (similar to SMA) and remembers it for that network (similar to SMA). No hash calculations, no exchange of keys, no computations…who could argue that this scheme is not “simple”.

Now look at Device ID. As originally proposed, the Device ID is intended as a static ID, allocated by the network, to the STA. It is protected and never exposed in the clear. It, presumably actually means something. As I pointed out many times, the IRM scheme and the Device ID go together very well and complement each other. IRM means the network knows the STA from before, per-association if required, and then it can provide its Device ID during association – hence the AP has a double check and if it has allocated the Device ID to mean something, all looks good.

Now we are hearing about “why not put the Device ID in an IE?”. But that is in the clear so it needs to be changed every association, so it is a different concept to the “Device ID” (which as a static identification). So one should be asking what is better (or worse) about adding a new IE?

it is a clear giveaway and a fingerprint on that STA. Let alone a new IE.
who sets it ? STA or AP?
what length? Could make it 6 octets like a MAC Address? Oh, wait, why not simply send it as the MAC Address and save on an IE – back to IRM.
How to choose an ID that does not conflict with the Device ID? This one needs to change every association, so it cannot actually mean anything. Could it be the “opaque ID”? But now it is not so simple and requires calculations. I will not expand on that here.

I could go on. Luther hit the point exactly, keep it simple and it stands a chance of being implemented.

Hence, this is why, I surmise, RRCM failed (a 22 octet KDE plus two hash calculations every time solely to have the same MAC Address stored at AP and STA) AND I will state that the ID in an IE scheme will just get more and more complicated as it is “developed”.

I personally started of by proposing a scheme that required a key and calculations (hash provided in an IE and key exchanged during association) but soon realized, 2 years ago, it was too complicated and I changed to suggest the two very simple schemes MAAD and IRM which, as I explained in several presentations, achieved the exact same result and privacy without any calculations at all. Plus they are as close to SMA as could safely be and should be seen as a true, simple TGbh solutions.

So, in conclusion, thank you for making the point about keeping it simple, but I suspect we are simply stuck with Device ID as it is (note that I do still support it) but it should be used as intended. Expanding it to be used as an IE is a completely different scheme and suffers from the 4 points I made above.

I hoped in vain, that others would agree with that the IRM scheme was simple and effective and met the STA vendors requirement that the STA chose the address (similar to SMA). But, would I support the ID in an IE scheme? I suspect that it will suffer from problems as the fine details are worked out (again look at my 4 points).

Anyhow, if you have read this far, thank you

Graham

From: M Montemurro <montemurro.michael@xxxxxxxxx>
Sent: Tuesday, February 28, 2023 1:32 PM
To: STDS-802-11-TGBH@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBH] Observations and simplicity

Hi Luther,

For what it's worth,I agree with the majority of your comments in your email. I think a network provided identifier is OK.

If we had something derived from the Device ID (not necessarily the Device ID in the clear) during messages exchanged prior to association, that should be useful. Also, we'd need to add requirements such as (similar to what's in the baseline today) a STA includes the identifier if it elects to maintain/re-establish state with the network. (i.e. up to the STA if it includes it)

- the device ID is rotated each time the STA successfully associates with the network. (which I believe is already there).

Again, these are high level comments in response to your discussion email. The devil is in the details.

Cheers,

Mike

On Tue, Feb 28, 2023 at 12:44 PM Luther Smith <l.smith@xxxxxxxxxxxxx> wrote:

To everyone,

Based on today’s TGbh call I believe several items raised seemed to come to the surface.

One was that we are putting together tools to be used – that the simpler the tools the more likely that they will be incorporated and used
That we have already agreed upon making use of Device ID to identify the device to the AP

Keep in mind that the D2.0 includes provisions that the Device ID can be changed during the 4 way handshake – to be referred to later

That we keep “spinning” in circles with regards to pre-association and if it is needed or not.

Question I have, if we can provide it in an easy, simple way, why not include it? – then it can be used or not – this gets back to these are tools that “can” be used.

If and since the Device ID is in use the following would hold true:

The Device ID could be changed during each association meaning that the Device ID used during pre-association is linked to that device until association happens then is changed.
That the device has a new Device ID associated with that BSS
That next time that the device starts to association (or pre-associates) with that BSS is uses that last assigned Device ID – which is only known by the device and the AP. So sending in the clear has not value to anyone since it will be updated during the 4-way handshake to a new Device ID to be used the next time pre-association is done

I will share that I realize/acknowledge the concern of the Device ID being in the clear during pre-association, the use of an AP changing the Device ID on every association as defined above would work around this.

I would also share that this takes the control out of the user’s hands (RCM is an opt-in/opt-out on the device by the user) and puts it into under the control of the network provider to change the Device ID on every association. Again this goes back to putting together the tools to be used.

I would like to hear the opinion of others on my observations.

Thank you,

Luther Smith

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