Per the D3.0 it clearly states that both are used to identify the device. Within 12.2.11.1 (next to last paragraph) states:
“When a non-AP STA receives an AP Identity frame with Identifier Status equal to “Recognized” it can proceed
with the assumption that the shared identity state with the AP or ESS (as per the concepts of 12.2.10) is now
bound to the non-AP STA’s current MAC address.”
From the actions it outlined that is an “assumption” that the device ID and the current MAC address are bound, but does not state that they are required to be bound.
In 12.2.11.2 it calls out that the IRM is used in associations and may be used as the TA.
Based on there is not hard requirement that the IRM and device ID be bound then which is used when? Should IRM be only used to indicate the current and next MAC address, and apply that any association functions and the device ID only used
for upper layer functions? If this is the case then there is no need to have the two bound.
IRM works in the cases where the MAC address needs to be known on the next association. Cases would be short time authentication to the network (ie when you are at a hotel, leave, then return you do not need to go through a captive portal.
As well addresses the “tracking” concern.
Device ID works in cases where that actual device needs to be know for controls (ie parental controls or troubleshooting.)
I feel that the two (IRM and device ID) can have two different functions and do not need to be bound. They can be bound in which case if they are out of sync – for whatever reason (such as an association failure in which IRM was updated
and not record within the AP) then I align with Graham that a status of “No Agreement” is returned. What is done with that status is not define and would simply be a “Warning” that things got out of sync.
Luther
From: G Smith <gsmith@xxxxxxxxxxxxxxxxxxx>
Sent: Tuesday, August 1, 2023 3:04 PM
To: STDS-802-11-TGBH@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBH] CIDs 23, 135 and 224
As I have stated before, I agree with Mark, IRM definitely identifies the STA.
Simple example:
Before RCM an AP identified the STA by registering its MAC Address, and if set up to accept certain MAC addresses, it would look at the MAC Address, identify the STA and let it associate every time. With IRM it is the same. The AP registers
the STA using the MAC address, then notes that next time the STA will use a different address, the IRM (which it has been provided advanced knowledge of). Hence, each time that STA arrives, it is still recognized and allowed to associate.
Hence, if the AP also is storing a device ID for that same STA, then, yes, there could be a discrepancy if either the STA or the AP make an error. It is a definite error if it goes wrong, so not 100% convinced it needs to be addressed.
But, if we insist on having the Status field, then why not use it and have a “No Agreement” message.
Graham
Hmm.
I don’t understand the comment “IRM does not identify a sta”.
My view is that both IRM and Device ID are used as a private (and potentially frequently changing, for both) way to identify a set of “state” that is shared between the client and the network, where that state is relatively durable (survives
across multiple associations).
I don’t see any difference between the two methods, except that IRM is derived by the STA, and Device ID is derived by the network. But, both mechanisms can be used for the same type(s) of “state”.
I’m completely missing this point-of-view that IRM is somehow identifying the STA “as a returning STA”, without also connecting that STA to some durable state that is shared between the STA and network.
Mark
Hi Mark,
My point is that I think the case of conflict cannot happen because both IDs do not identify the same. IRM does not identify an sta therefore cannot conflict with deviceid.
There is absolutely no problem if a device id is recognized but the IRM is not. This means the long term identity of the sta is identified but the sta is not a returning sta. I see no problem.
The other way around it's the same, I do not see a problem. The sta is a returning sta but the AP does not recognize the long term identity.
The case where both are recognized but map to different identities simply cannot happen because irm does not provide an identity.
Antonio/all, (as an individual, not as Chair):
I do not think your proposed text really resolves the problem pointed out in the comment. (I think perhaps I’m agreeing with Jay.)
We have agreed that the two mechanisms can be used at the same time (or in an overlapping, but not literally “at the same time” fashion – for example, IRM is used during pre-association,
but then a Device ID is provided at association from the same device). So, even if can agree that the mechanisms are independent, there is the scenario that the network does recognize both the identifiers provided, but they do not map to the same long-term
information (state) the network has stored because they map to two different devices’ state per the network’s history.
I think we need to say what does happen, in this scenario. The choices that I can see are:
-
It is implementation-dependent. Not my favorite choice, but I could live with it.
-
The network says this is an error. Something like the proposal Graham has created looks good to me. (I’d like to hear concerns about this “leaking information” and creating a security hole, though.)
-
We say that one or the other must be “Not recognized” or some such – do we go so far as to dictate which one takes precedence?
-
Maybe(?), there is a proposal that the network just doesn’t respond at all to both handshakes? (Although, this is gets very confusing in the “IRM is used during pre-association, but then a Device ID is provided at association from the same device, but they
don’t match” case – there is not necessarily a handshake for the IRM, although there _should_ be one…)
So, which is it?
Mark
Hi All,
I wanna jump in for the disscusion.
I guess the following two cases has nothing with the recognize/unrecognize issue if both schemes are applied together.
They are talking the recognize result is not consistent issue. E.g. based on IRM, the STA is identified as a returned Device A; based on Device ID, the STA is identified as a returned
Device B. How to address such issue?
|
135
|
|
Technical
|
1
|
12.2.11
|
30
|
24
|
It is not clear how IRM and Device ID can be used together. Is it possible that STA sometimes uses Device ID and other times uses IRM?
What if the IRM and Device ID match to different devices?
|
|
224
|
|
General
|
1
|
6.3.7..2.2
|
19
|
29
|
Both IRM and Device ID can be used simultaneously, what happens if each of them identifies a different STA?
|
Original
Subject: Re: [STDS-802-11-TGBH] CIDs 23, 135 and 224
Hi Benjamin, thanks for the word smithering, then the final version to be discussed will be:
“NOTE: Device ID and IRM are independent schemes that can be used concurrently. If an AP and a non-AP STA both support
both IRM and device ID, the non-AP STA might present both an IRM and a device ID. The two mechanisms are not related and their failure or success is not linked.”
@Graham, what do you think?
If you really think it is needed to state, better language is "The
two mechanisms are not related and their failure or success is not linked"
Subject: Re: [STDS-802-11-TGBH] CIDs 23, 135 and 224
Hi Benjamin, Luther, thanks for the comments. Regarding the "less words is better approach", I think we really need in this case to state that if both Device ID and IRM are presented
and one of them is not recognized it does not mean anything for the other schema.
Following Luther suggestion and trying to simplify, what about:
NOTE: Device ID and IRM are independent schemes that can be used concurrently. If an AP and a non-AP STA both support both IRM and device ID, the non-AP STA might present both an
IRM and a device ID. Both mechanisms are not related and their failure or success is not linked.
BTW, I am on vacation and will not be able to connect to the call. If you discuss this and the group agrees on a different wording let me know please
Thanks Antonio, I think I am closer to understanding
😉.
I remain a bit confused by "if both mechanisms while used concurrently
yield to different results" which led me to think there was a potential conflict. From your explanation I see that these are independent and there is no co-dependency or conflict. Perhaps this is a case where
less words is more clear:
"NOTE: Device ID and IRM are independent schemes that allow an AP to
recognize a non-AP STA prior to association and identify it during association respectively. "
which seems to clearly state what you have said. The rest is redundant information.
Hi Benjamin, what I am trying to clarify is that there are no possible conflicts since they do not tackle the same thing, therefore there is no possible conflict between them.
The only thing the AP can indicate is whether DeviceId is recognized or not and if IRM is recognised or not. In fact this indication means different things for both cases, for Device
ID means the identity cannot be recognised while for IRM means the station is not recognised as a returning STA, that is all.
I am not able right now to see a use case where a failure of, for example IRM, makes a recognised Device ID not valid or vice versa, if you have one please share it since for sure
will clarify this issue
Thankyou Antonio, for pointing out the need to address the failure cases where Device ID and IRM checks produce different outcomes. The
added text still doesn't inform the implementer what behavior is expected. Saying they are not linked still can produce different results, with different potentially conflicting actions. Is the intention that it be implementation specific which is given
precedence? Or am I incorrect in thinking there is a conflict in behavior?
as promised during the last AC I am providing new text for the resolution of these CIDs.
Current text agreed during comment resolution for these CIDs is the following:
NOTE: Device ID and IRM are independent schemes that allow an AP to recognize a non-AP STA prior to association and identify it during association respectively. The device ID is allocated by an AP, and the IRM is selected by a non-AP STA. If an AP and a non-AP
STA both support both IRM and device ID, the non-AP STA might provide both an IRM and a device ID.
I think this explanation lacks information on how to proceed if both mechanisms while used concurrently yield to different results. In addition, the above paragraph seems to indicate IRM provides identification, while it is not.
I am proposing the following text, let me know what do you think
NOTE: Device ID and IRM are independent schemes that can be used concurrently. The device ID is allocated by an AP, and enables identification of the STA during association. IRM enables an AP to recognize that a STA has been associated previously to the AP,
therefore not providing any identification. If an AP and a non-AP STA both support both IRM and device ID, the non-AP STA might provide both an IRM and a device ID. Both mechanisms are not related and their failure or success is not linked.
Associate Professor
Telematics Department
Universidad Carlos III de Madrid
E-mail: aoliva@xxxxxxxxxx
Phone: +34 91 624 8803
Fax: +34 91 624 8749
--
Associate Professor
Telematics Department
Universidad Carlos III de Madrid
E-mail: aoliva@xxxxxxxxxx
Phone: +34 91 624 8803
Fax: +34 91 624 8749
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
--
Associate Professor
Telematics Department
Universidad Carlos III de Madrid
E-mail: aoliva@xxxxxxxxxx
Phone: +34 91 624 8803
Fax: +34 91 624 8749
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
--
Associate Professor
Telematics Department
Universidad Carlos III de Madrid
E-mail: aoliva@xxxxxxxxxx
Phone: +34 91 624 8803
Fax: +34 91 624 8749
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
|