Thread Links | Date Links | ||||
---|---|---|---|---|---|
Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Just a follow up on sending IRM in msg 2 of 4W HS. In the highly unlikely event of a duplicate, then AP can sent “duplicate” in msg 3, and then STA can sent new IRM in msg 4. Voila, all is good.
Actually AP could send either “recognized but duplicate” or “not recognized and duplicate”, we have plenty of bits.
In FILS, I think the opportunity to send a new IRM is not there – but I may be wrong. Could inform of duplicate but not sure what a STA could do. Can it simply send a new FILS Auth request before
it sends an association request? If it can do that, then we are good. Is that possible? – any FILS experts? In PASN if could send (encrypted) IRM in msg 1, then AP could send “duplicate” in msg 2, and STA sends new IRM in msg 3. Not sure if you are able to overcome the non-encrypted IRM or Device ID
in msg 1 yet. Having said that, in PASN I think the numbers are very low, i.e., how many STA IRMs might we expect the APs to handle when using PASN? As I keep saying, saving 100 IRMs, there is a 1 in 14 billion chance of duplicate. Saving 10 is 1 in 1.4
trillion. Hence, maybe not having the duplicate in PASN might be acceptable. I am still on the fence about using status. If duplicate could be used then I might flip.
What do you think? Also anyone else on Reflector please feel free to chime in. Graham From: G Smith
Thanks. Yes, I think I now understand it better. Please do work on making it clearer. One other point is that the Device ID is sent in the clear, so in this case we use the Opaque ID? The underlying Device ID is, however, the same one. So over the air it is a different ID field,
but in fact it is the same ID. Is that right? That may need some explaining. Reason is that from today’s meeting I had push back when I said the Device ID is “longterm” or permanent – someone pointed out it changes in PASN. But my point is that it actually
does not, the Device ID is the same but the Opaque ID does. That is not easy to explain, but I think that is correct. Thanks, and best of luck making the text changes.
One last point, the “IRM Duplicate” can’t be in the Status field because the IRM is sent in msg 4, after the Status field in msg 3. Could we change to sending IRM in msg. 2 of 4W HS? I understand
that there is still a problem with PASN (sending IRM in Msg 1 would be in the clear), but maybe we accept that “duplicate” not used in PASN? What would be the effect? Any ideas? Thanks Graham From: Okan Mutgan (NSB) <okan.mutgan@xxxxxxxxxxxxxxx>
Hi Graham, Thanks for putting some thoughts and efforts on this. Let me put the IRM Element/KDE and device ID Element/KDE here for the sake of the discussion. They contain two fields, namely, “IRM/Device ID status” and “IRM/Device ID”. But the usage of these fields varies depending on the situation.
<Q> I do not see any mention of the AP sending the Status bit. In FIG for example, MAC 2, does AP-2 send devID2
and the status on devID1? The figure does not show any status field, but the text describes it (please see below). We can modify the picture (adding status field to the picture) if necessary. Correct that In FIG for example, MAC 2, AP-2 sends devID2
and the status on devID1. <Q> By the way, what is in the Auth Msg, I assume it’s the Device ID element?
Yes it is (please see Fig 9-788fm). However, in Msg1, only Device ID field is used, and in Msg2, both device ID field (i.e. new device ID) and device ID status field (i.e. status on old device ID) are used. <Q> Similarly when using IRM, STA sends new IRM in third PASN frame (encrypted?), does AP send the status on the used IRM in Msg 2? It’s not mentioned.
-> Correct that STA sends new IRM in third PASN frame encrypted (encryption is still not defined in details, it is one of the CIDs (CID84) so we will work on it. Note that CID84 talks about encrypting both device ID IE for Msg2 and IRM
IE for Msg3). -> Currently, status field (recognized or not recognized) is not defined for IRM in PASN (please see the text below it talks about recognition for FILS and non-FILS & non-PASN, but not for PASN), so AP does
not send the status in Msg2 on the used IRM. This is also one of the CIDs (CID113), we will work on it. Please feel free the drop your comments. Thanks! BR, Okan From: G Smith <gsmith@xxxxxxxxxxxxxxxxxxx>
Hi Okan, I am reading again the PASN description and FIG 12.0a. I do not see any mention of the AP sending the Status bit. In FIG for example, MAC 2, does AP-2 send devID2
and the status on devID1? By the way, what is in the Auth Msg, I assume it’s the Device ID element?
Similarly when using IRM, STA sends new IRM in third PASN frame (encrypted?), does AP send the status on the used IRM in Msg 2? It’s not mentioned.
Just trying to get my head around it all, wrt status. 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 |