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

Re: [STDS-802-11-TGBH] IRM Points at Tuesday's meeting

I recall commenting on the issue of the check being an identifier in one of the calls. The check is in essence a transient identifier;  I think it would be best to clearly separate the key(s) used and any transient ID used -e.g., like that derived in the Transient STA ID proposal, where the ID could directly be used as an index. I think the check field in the IRMA proposal will also  get in the way of pre-association use cases in addition to scalability on use, like the stadium case.



On Wed, Jan 19, 2022 at 9:48 AM Mark Hamilton <mark.hamilton2152@xxxxxxxxx> wrote:

Thanks for this, Graham.

 

I have two follow-on points/questions:

  1. On your first paragraph, and that IRM would (might) not be used in a 10,000 seat stadium: I’d just like to clarify that the devices would still randomize their MAC address (to not be tracked) and that could be done with IRM, but with the “IRM Indicator” set to 0 for most devices.  That is, most of the users have no reason to provide any identity to the stadium, and probably don’t/won’t trust what the stadium would do with it and would want to disable IRMA on that network anyway.  Are there advantages to having IRM enabled, but rarely used?  For example, a few devices (staff, vendors) might actually provide a identity (although this is likely handled with a separate SSID, actually).  But, if there would be any advantages, I *think* that enabling IRM but having very few devices participate would remove the burden on the APs, right?
  2. On your second paragraph, and the IRMK Check offset: If we proceed with a constant/a priori offset, doesn’t that turn the Check value into a simple (non-unique) “identifier of the identifier”?  We would need to consider:
    1. Does this make devices more easily trackable again, by introducing a constant identifier that can be tracked on every re-use?  (I’m assuming that the “new key with every association” is not at every _Re_Association, is it?  So, while the device is associated to the network, but moving between APs within the stadium, they can be tracked?  Is that a big deal?)
    2. Is there any advantage in this Check being derived from the key via some algorithm, versus just being an extra “token” that is stored along with the key, and the AP just does a straightforward search/lookup (no arithmetic at all)?  In fact, this then devolves into just being a few extra bits of the key itself, I think.

 

Mark

 

From: G Smith <gsmith@xxxxxxxxxxxxxxxxxxx>
Sent: Wednesday, January 19, 2022 10:17 AM
To: STDS-802-11-TGBH@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBH] IRM Points at Tuesday's meeting

 

Dan brought up a couple of good observations after my presentation on the IRM/ID scheme.

 

Dan was concerned that in the case of a stadium there could be 10’s of thousands of devices which would put a big burden on the AP/Network in calculating the hash and finding the key (IRMK).  This would be true but on reflection I now realize that this is not a Use Case that TGbh has considered and also I doubt if it would be.  In this case I suspect that the APs would not indicate support for IRM and hence the STAs would not use it.  The ID Query might be used, not sure.  Still it’s a good point and I do want to make sure the effort is kept a low as possible. 

The idea of the IRMK Check was to reduce the work by the AP.

 

The IRMK Check at the moment uses a random start bit.  Dan expressed that it was still a lot of work for an AP to go through all the IRMKs and perform the 16/8 bit EXOR at the point that the STA is associating.  There was a suggestion that a fixed offset could be used and on reflection I think this is a practical solution.  When the STA associates, it provides a new key (IRMK) and if we had a fixed offset, the AP could quickly calculate the 8 bit Check and store it with the key, i.e., it stores the 9 octet key and 1 octet check, 10 octets per STA.  Then when the STA indicates the Check, the AP has a simple job to find those keys that match the check (reducing the list by a factor of 256). 

As an aside to this, I did at one time consider using a CRC-8 as the check.  I am not an expert on this but I felt that that was more work – I may be wrong, so if anyone feels that would be better please let me know.

 

Thanks

Graham

 

 

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