| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Just a level-check… The current D0.2 draft defines a network-provided Device ID which is designed to be constant, that is the underlying identity of the device does not change, while having the over-the-air blob that is sent from STA to AP change with every
association. So there is no need to update any upper layers. The identity the upper layer has and uses will not change but what a passive snooper sees as the identity being exchanged between STA and AP will change dramatically (if it is being implemented properly)
with every association. The intent was that there would be some IE defined to carry this ever-changing blob in frames that are sent pre-association so the AP could get it, deblobify the blob, and extract the constant and never-changing identity. We just never
got around to defining that IE. Of course, the Annex is not required so theoretically one could use D0.2 without it and have an ID that changes and requires upper layer notification with each association, as Kurt mentions. But that just seems like too much work and
too many moving parts. regards, Dan. -- "the object of life is not to be on the side of the majority, but to escape finding oneself in the ranks of the insane." – Marcus Aurelius On 3/1/23, 8:36 AM, "Lumbatis, Kurt" <kurt.lumbatis@xxxxxxxxxxxxx> wrote: Thank you all for your comments and observations. I agree completely. Keep it simple. D0.2 defines the network provided Device ID (Identifier). With updates for control, acknowledgement, etc. it becomes easier and allows If a=b and b=c, then a=c. Something missing in the current specification are the MLME mechanisms to pass the identity and other information to/from upper layers.
I do agree that there is a need for pre-association identification of a device for many and various reasons. Utilizing the MAC address or adding the IE utilizing existing mechanisms already in the draft (Annex Z) however it does add computations, key sharing and key storage requirements. Anyway, my two cents. Kurt Lumbatis Distinguished Software Engineer DOCSIS CPE R&D SW Architecture (Wi-Fi) ARRIS AND RUCKUS
HAVE JOINED COMMSCOPE
3871 Lakefield Dr, Suwanee, GA 30024 USA
Office: +01-678-473-2921 From: Luther Smith <l.smith@xxxxxxxxxxxxx>
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>
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?
1.
it is a clear giveaway and a fingerprint on that STA. Let alone a new IE.
2.
who sets it ? STA or AP?
3.
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.
4.
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>
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.
Mike On Tue, Feb 28, 2023 at 12:44 PM Luther Smith <l.smith@xxxxxxxxxxxxx> wrote:
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 |