Thread Links | Date Links | ||||
---|---|---|---|---|---|
Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Hi Li Yan Thanks for following up with me. Please see my comments response in-line below.
In summary: Figure 12-0a provides a pure PASN device ID exchange.
Figure 12-0b provide a PASN device ID exchange for a previously associated non-AP STA which has a PASN ID (and therefore including the association and the establishment of the initial PASN ID). I believe this
figure should focus on PASN behavior; hence the three parts should be association/obtaining a PASN ID from AP1, using the PASN ID (PASN ID1) without association with AP2 and obtaining a new PASN ID (PASN ID2), and then using PASN ID2 with AP1 (without association
or reassociation) and obtaining a new PASN ID (PASN ID3). All of three of these parts should include an FTM Session, before deauth or disassociation. If you or others think we should add a figure to show how device ID is used in association for a “returning non-AP STA” (see definition below), that should be a different figure and should not have any PASN
exchanges. Also, if we add such a figure for device ID exchange, we may also want to add a figure for IRM exchange. But I’m not looking to add work and I don’t think we received any comments requesting such figures.
Regards, Joseph From: li.yan16@xxxxxxxxxx <li.yan16@xxxxxxxxxx>
Hi Joseph, I really appreciate your comments on the figure 12-0b of my PASN ID contribution(789r3). If i remember correctly ,you pointed out such 2 comments: 1. in figure 12-0b, 4-way handshake should be started with association request/response Yes, i will add it [JL] – Great this will put the flow in the correct context, as it is my understanding that a PASN ID is provided during a 4-way handshake. So, association is required.
2. the second 4-HS should be reassociation and the non-AP STA can not use new mac address in this part. commenter wants to clarify the third part is for PASN ,so it needs to provide PASN ID in the 4-way
handshake. Firstly, i totally agree with you that non-AP STA should not use random MAC address and should not further use device ID feature in the reassociation case. [JL] – as you affirm under the current random MAC “rules” a non-AP STA that is reassociating with the same ESS does not change its MAC address, it does however complete a new 4-way handshake after reassociation. Therefore,
a reassociating non-AP STA has no need for device ID, as it has identified itself with its MAC address. However, I believe deferent “rules” apply for the case of a “returning non-AP STA”, a non-AP STA that previously was associated to the ESS that is using
a “new” random MAC address to associate with an ESS that it had previously provided the non-AP STA with a Device ID. A “returning non-AP STA” may (should?) use the Device ID to identify itself to the ESS. Also, a non-AP STA that is using PASN (that is not
associating with the ESS) that has be previously assigned PASN ID may (should?, shall?) use the PASN ID to identify itself in PASN exchanges. Note as PASN is an optional feature, it may make sense to require the non-AP STA to use a PASN ID when one has been
provided. This doesn’t mean that the non-AP STA is required to use device ID to use PASN. However, if the non-AP STA has chosen to use device ID and PASN and has received a PASN ID from an AP in the ESS, then it (shall/should) uses the PASN ID.
Secondly i added the third part for 4-HS just to describe a case of reporting and providing a new device ID, which is an association case and is for data transmission(I know STA can do FTM during association, but in this figure, i just want to separate
association part from PASN authentication part, which is used for data transmission and FTM session, respectively). My intention is as below: 1) provide both of Device ID1 and PASN ID1 in first
part(4-HS) 2) report PASN ID1 and provide PASN ID 2 in second part(PASN authentication) 3) report Device ID1 and provide Device ID 2 in third part(as the reassocation is taken into consideration, i suppose to change the third
part to associate with a new AP(AP3),which is used for data transmission with AP3, such as class 3 frame, instead of FTM session) [JL] While this a valid use case and may occur the focus of this figure is to illustrate PASN functionality. I think it would be best to have:
I also recalled Mark helped to clarify the third part(4-HS) uses association instead of reassociation. Maybe this is another option. [JL] While this is true and may be useful to be shown in a figure, I don’t think this belongs in the figure describing PASN operation.
In summary , i would like change the figure as below: a) add association frame exchange before the first part(4-HS)
[JL] agree b) add data transmission after 4-HS for the first part and third part [JL] agree with adding data transmission to the first part and third part. But for the third part not
including a 4-HS, for the third part as I believe this should be a PASN exchange, basically identical to the second part, but using PASN ID2 and ID3.
c)in the third part, just use association instead of reassociation. or in the third part, non-AP STA associates with a new AP(i.e., AP3) for 4-HS
[JL] As stated above I think the third part should be a PASN exchange (PASN ID2 in Auth Msg1 and PASN ID3 in Auth Mesg2). the original figure is as below Best Regards! 李炎 Li
Yan 标准预研工程师 Standard
Development Engineer
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 |