| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
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?
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 |