| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Hi Dan,
Before I answer your questions, I would like to know what's the term of "transactional exchange" . In order to get the answer, I have to go through many 11aq contributions.
Lucky, such term appreas in https://mentor.ieee.org/802.11/dcn/17/11-17-0521-03-00aq-privacy-enhancements.docx for the first time. And It's your submission 6 years ago .
In this submission, there is a standalone paragragh said "
A non-AP STA shall refrain from MAC randomization during transactional exchanges, for example transmitting public action frames for pre-association discovery.
"
It's a general description, and there is no context to say anything about state created.
But now, you persist to say "If there's no state created then it's not a transactional exchange" in this mail loop.
I feel some confused on the two views of the same thing from one expert.
It's appreciated if you can explain the term of "transactional exchange" as it's invented by you.
For the de-auth case, we share the same position. As it's a conversation, I don't add (except auth/de-auth frame ) when refer to Class 1 frame in every place, but you expected such. Applogized for making you feel confused.
Best Regards
Jay Yang (杨志杰)
Wi-Fi Standard Research Engineer
ZTE Corporation
R&D Building I, No.899 Bibo, Pudong District, Shanghai, P. R. China
Jay,
On 9/2/23, 5:45 AM, "yang.zhijie@xxxxxxxxxx" <yang.zhijie@xxxxxxxxxx> wrote:
Hi Dan,
Hope you fully undertand what I am talking before you say NO! NO! NO!
I've never said "Deauth from a random MAC address", why you assume such, and then get the conclusion "I don't think you understand how 802.11 works." My God !
You're right I don't fully understand what you're talking about.
In a previous email you said, "while probe request/response between STA1/AP2 is another transactional exchange." But down below you say, "In my mind, Class 1 frame (except auth/de-auth frame) exchange don't create new state on both side." If they don't create state then they're not transactional. So what is it?
Then you say, "But for Class 1 frame exchange, the STA can use any RMC to do frame exchange with AP, who cares.." and "the STA have to use the same MAC address when probe or send other Class 1 frame to the AP each time, which will bring a lot of privacy concern". You know what a Deauth is? It's a class 1 frame. So can the STA use any MAC address to send this class 1 frame? No, it can't, it has to use the same MAC address it used when it entered state 2. To me, the critical nature is what state the state machine is in, not what class of frame is being sent. But to you…well, I'm not sure.
So yes, I will admit I don't understand what you're talking about because you seem to say contradictory things.
If there's no state created then it's not a transactional exchange. Please explain what's the state created when the STA transmits Public Action frames for preassociation discovery.
To further add confusion to your email you seem to be quoting me without using quotes. Is "If there's no state created then it's not a transactional exchange" a statement you're making or is it a quote of mine? If the former then, again, you're contradicting yourself, if the latter then you're unnecessarily adding confusion to an email so don't get upset when people then don't understand you.
Regarding your question, I've asked you a question twice and you never answered. So maybe you answer me first, OK?
Dan.
--
"the object of life is not to be on the side of the majority, but to
escape finding oneself in the ranks of the insane." – Marcus Aurelius
Best Regards
Jay Yang (杨志杰)
Wi-Fi Standard Research Engineer
ZTE Corporation
R&D Building I, No.899 Bibo, Pudong District, Shanghai, P. R. China
Original
From: Harkins,Dan <daniel.harkins@xxxxxxx>
To: STDS-802-11-TGBH@xxxxxxxxxxxxxxxxx <STDS-802-11-TGBH@xxxxxxxxxxxxxxxxx>;
Date: 2023年09月02日 13:59
Subject: Re: [STDS-802-11-TGBH] 11-23/1453r0
Jay,
On 9/1/23, 5:29 PM, "yang.zhijie@xxxxxxxxxx" <yang.zhijie@xxxxxxxxxx> wrote:
Hi Dan,
I fail to understand what your said "The transactional exchange generates shared state" . There is nothing with the state(or new stated created).
I'm sorry but what do you think a PMKSA is?
I agree what Mark said, "transactional exchange like a set of related tasks that form a logical unit of work" . For me, it looks like a serial of frame exchanges between two sides.
That definition encompasses almost everything and is therefore useless. A transaction involves giving and getting. "a serial of frame exchanges between two sides"? What? I don't even understand what that means.
See following highlight sentence, before the STA associated/or authenticate with a BSS, both side stay in state 1.
They can do some transactional exchange, like Public action frame exchange without created a new state. But during the frame exchange period, the STA can't change it's MAC address.
What is this "public action frame exchange"? If it doesn't create state then what sort of transaction has occurred? You're making these weird statements, "frame exchange period", what is that? What does that have to do with anything?
e.g. STA sends a ANQP request frame with MAC1, STA must use MAC1 to recevie ANQP response frame, as the whole procedure belong to a "transactional exchange"
And the STA can repeat the same procedure in another transactional exchange with a new MAC address, which will be aligned with the first cited sentence.
Otherwise, there's no corelation between the following two sentences.
"The STA shall periodically change its MAC address to a random value while not associated to a BSS. The STA
shall construct the randomized MAC address from the locally administered address space as defined in
IEEE Std 802-2014 and IEEE Std 802c™-2017. However, the non-AP STA shall not change its MAC address
during a transactional exchange, for example, transmitting Public Action frames for preassociation discovery"
What is your point?
Another question, what's the state of a STA and an AP duing probing or other Class 1 frames frame exchange? In my mind, Class 1 frame (except auth/de-auth frame) exchange don't create new state on both side, the STA and AP will stay the state where it was after Class 1 frame exchange. If there is some state change on both side, the STA should use the same MAC address when the state was created. As state 1 is a default state, it should be a exception case when we talk state created.
If there's no state created then it's not a transactional exchange. I guess you will be voting "yes" on straw poll #1 from my submission.
E.g., when the AP and STA stay in state 2 (authenticated), the STA shall use the same MAC address when send a De-authention frame or association request fame, as the two frames will cause the state change.But for Class 1 frame exchange, the STA can use any RMC to do frame exchange with AP, who cares..
No! Not if it's in state 2. If it's in state 2 the frames it sends are bound to the MAC address used to enter state 2.
In the contrary, if you assume the STA must use the same MAC address when send a frame to the AP in state2. e.g. in some cases, the STA never go to state3 and state4. the STA have to use the same MAC address when probe or send other Class 1 frame to the AP each time, which will bring a lot of privacy concern.
I don't think you understand how 802.11 works.
The STA must use the MAC address it used to establish state on the AP. A Deauth frame is a class 1 frame. If it sends a Deauth frame to an AP it has to use the MAC address it used when it established the authentication state on the AP otherwise the AP has no idea what this Deauth refers to. Deauth from a random MAC address? What is the AP supposed to do with that? The requirement to use a particular MAC address is not based on the frame class, it's based on the whether there is state that the frame refers to. 802.11 authentication establishes state on the AP. If the STA wants to send a Deauth frame and destroy that state on the AP it MUST send the Deauth frame from the MAC address it used to create it. You seem to think that if it's a class 1 frame then the STA can use any random address. That's not how it works.
Dan.
--
"the object of life is not to be on the side of the majority, but to
escape finding oneself in the ranks of the insane." – Marcus Aurelius
Best Regards
Jay Yang (杨志杰)
Wi-Fi Standard Research Engineer
ZTE Corporation
R&D Building I, No.899 Bibo, Pudong District, Shanghai, P. R. China
Original
From: Harkins,Dan <daniel.harkins@xxxxxxx>
To: STDS-802-11-TGBH@xxxxxxxxxxxxxxxxx <STDS-802-11-TGBH@xxxxxxxxxxxxxxxxx>;
Date: 2023年09月02日 04:52
Subject: Re: [STDS-802-11-TGBH] 11-23/1453r0
Hi Mark,
On 9/1/23, 11:20 AM, "Mark Hamilton" <mark.hamilton2152@xxxxxxxxx> wrote:
Dan, below. Mark
From: Harkins, Dan <daniel.harkins@xxxxxxx>
Sent: Friday, September 1, 2023 11:55 AM
To: mark.hamilton2152@xxxxxxxxx; STDS-802-11-TGBH@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBH] 11-23/1453r0
Hi Mark,
On 9/1/23, 10:25 AM, "Mark Hamilton" <mark.hamilton2152@xxxxxxxxx> wrote:
Dan/Jay/all,
I might be missing some of what Jay is trying to point out – please respond if there is more, Jay.
But, I have a couple comments, if I can jump into this thread:
1. @Harkins, Dan: Jay pointed out below what I think is just a typo: The frames are called “Beacon Request” and “Beacon Report”. There is no “Beacon Report Request” – I think you meant just “Beacon Request”.
Thank you, yes.
2. Dan asks below: >>> “When STA1 sends a probe request to AP2 what shared state is it creating?”
1. I would respond: The state is that STA1 is able to hear both AP1 and AP2, and some information about the link quality between STA1 and each of those APs. This state information can be gathered by both the AP and the STA, during a Beacon report scanning (probing). The STA will report the information in the actual Beacon Report. The APs may also create their own state information based on the reception of the Probe Requests, but that only works if the APs can identify the Probe Request(s) that are from STA1.
That's not shared state. Gathering information about RF conditions through probing or scanning or whatever may create state on the STA doing the probing and scanning but the AP doesn't create the same state and bind the STAs MAC address to it.
[[MAH]] Dan, nothing in the 11aq text says that the state has to be “shared”. It’s just “state on an AP” and “state bound to a MAC address”, and both of those apply here.
I think you're just parsing words here. What is the point of creating state bound to a MAC address on an AP? Why would a STA "configure its MAC address according to the rules of the local address space prior to the start of the transaction" if it didn't have any knowledge of the state or share the state? How would it use that state? It doesn't even know whether it is generated or not! That can't be transactional.
There's a reason this text exists. The reason is to allow a STA to access state on an AP that it created earlier. If it doesn't know that state was created in the first place or know anything about what that state looks like then there's no point in applying this section. Is it "state on an AP"? Yea, I guess. Is it "state bound to a MAC address"? Well, that depends on what the AP is doing with that state, we don't know and neither does the STA. But is it usable by the STA at some future time such that it would want to change its MAC address back to use it? Absolutely not. It has nothing to do with 12.2.10.
When the state is shared it becomes useful for the STA. It does a transactional exchange that results in state being created on the AP. The STA knows about this state and what it can be used for. That is the sharing.
(I know that the 12.2.10 text ended up getting massaged during the RAC wars after sponsor ballot, so there are lots of fingerprints in it, but the original text was mine. The intent was to indicate to STAs that if they create state on an AP and want to use it in the future they have to return back to the MAC address they used when it was created. That's the whole point).
For the purposes of band steering an AP may create state regarding who it is that's probing the AP in an effort to not answer if the desire is to steer the STA to another band but that is not state that the STA even knows is being created nor is it state that the STA can refer to later with a particular MAC address. But in general I don't believe APs fill up memory with "I got probed by MAC-X" state because they get probed a lot.
[[MAH]] I agree with you here, although I’ll note that some APs do keep some of this in memory (with a quick FIFO flush). However, in this case were talking about an AP that does a specific Beacon Requests, so it is likely to store the state for these responses (at least long enough to make a roaming recommendation decision), but of course only if it can correlate the Probe Requests.
AP1 did the beacon request. That is to an associated STA. The question is, when the STA goes off and probes AP2 is it accessing any state that was created with the MAC address used while associated to AP1? No. The probing is not transactional. It gathers information, sure. The STA gets some environmental information it can send back to AP1 but AP2 does not need to be aware of this and the STA does not have to use the MAC that is associated to AP1 in order to probe to AP2. The probing is not transactional. If you think it is, then what would the STA do in the future with AP2 using whatever state you think AP2 created as a result of that probe? What would compel the STA to use a particular MAC address when interacting with AP2?
When talking about these transactional exchanges, they are things that create the same stuff on both the STA and AP. Think of SAE. Or FILS. Pre-auth is another example of creating shared state between a STA and and AP that can be referred to later by using the MAC bound to that state. Just gathering some requested environmental data is not a transactional exchange because there's really no transaction made when gathering said data. Probe request, probe response. End of exchange. No transaction, no state retained. There is nothing the STA expects the AP to have that it would use on a future connection. But with SAE there is. There is an exchange of 802.11 authentication frames and the end result should be a PMKSA on both the STA and AP. When the STA wants to use that state to association it must revert back to the MAC address it used to create that PMKSA. A STA could do SAE with AP1 using MAC1, do SAE with AP2 using MAC2, and SAE with AP3 using MAC3. Now it has shared state, each bound to a unique MAC address, on 3 APs in the ESS. If it later wants to go associate with AP2 it will change its MAC address to MAC2 and associate. But a probe? No, there's no shared state bound to a MAC address that the STA will want to refer to later. It's not a transactional exchange.
[[MAH]] SAE, FILS, pre-auth, etc. are all great examples, I agree. But, I disagree in your claim that Beacon Request is not also an example. First, “transaction” (transactional exchange) to me, is defined something like “a set of related tasks that form a logical unit of work”. In the case of a Beacon Request, all the Probe Requests and the information gleaned from them, is combined into a set of data for decision-making. To me, those all become one transaction as a result. (And, again, per above, there is nothing that says this state has to be shared, so how/whether the STA expects the AP to have this state is not relevant.)
I'm getting dizzy jumping from the minutiae of specific words to the 10000' view of what's going on…. AP1 is asking the STA to go do some work for it. Is that a "transaction"? Who cares. It's not relevant to the 12.2.10 text. It's a semantic argument which I do not wish to have. The point I'm trying to make here and in my submission is that when the STA goes off and starts to act on that request, the probes it does are not transactional per 12.2.10 and do not create state which would cause the 12.2.10 rules to apply. Yes the STA is gathering data. Yes it's going to send that data back to AP1. AP2 doesn't care. And if AP2 created any state as a result of this probing—no one knows, including the STA—then the STA will have no use of it in the future so 12.2.10 doesn't apply.
regards,
Dan.
--
"the object of life is not to be on the side of the majority, but to
escape finding oneself in the ranks of the insane." – Marcus Aurelius
Mark
From: Harkins, Dan <daniel.harkins@xxxxxxx>
Sent: Friday, September 1, 2023 10:24 AM
To: STDS-802-11-TGBH@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBH] 11-23/1453r0
Hi Jay,
On 8/31/23, 11:26 PM, "yang.zhijie@xxxxxxxxxx" <yang.zhijie@xxxxxxxxxx> wrote:
Hi Dan,
The state created on the AP and STA is per-AP level, not per-BSS. After the STA associated with the AP(AP1),the STA can send Class1/2/3 frame to AP1. But the STA is only allowed to send Class 1 frame to the second AP(AP2). e.g. the STA can't send Class 3 frame, like Data frame, to AP2. Obviously, the STA is in the state 1 from AP2 perspective.
So? I don't understand what point you're making here. Yes, the state governs what frames can be sent. And….
When we talk "transactional exchange", i guess there is a precondition to say the transactional exchange shall be between one entity peer, like AP1 and STA1 is an entity peer, while STA1 and AP2 is the another entity peer. If so, beacon request/report between AP1/STA1 is a transactional exchange, while probe request/response between STA1/AP2 is another transactional exchange. It looks like one transactional exchange insert into the procedure of another transactional exchange. Maybe I'm totally wrong as 11aq doesn't describe this part very clear.
The transactional exchange generates shared state. If there is no shared state created then it's not a transactional exchange—"starts any transaction that establishes state bound to a MAC".
Let me ask my question below again. When STA1 sends a probe request to AP2 what shared state is it creating? Or is it using some state it created due to the fact that its associated with AP1? If so how?
regards,
Dan.
--
"the object of life is not to be on the side of the majority, but to
escape finding oneself in the ranks of the insane." – Marcus Aurelius
Best Regards
Jay Yang (杨志杰)
Wi-Fi Standard Research Engineer
ZTE Corporation
R&D Building I, No.899 Bibo , Pudong District, Shanghai, P. R. China
Original
From: Harkins ,Dan <daniel.harkins@xxxxxxx>
To: 杨志杰10343608;STDS-802-11-TGBH@xxxxxxxxxxxxxxxxx <STDS-802-11-TGBH@xxxxxxxxxxxxxxxxx>;
Date: 2023年09月01日 11:02
Subject: Re: [STDS-802-11-TGBH] 11-23/1453r0
Hi Jay,
The question is, does the STA doing the probing require the use of any state it had created on an AP in the ESS to perform its activities? If so then what is that state?
Is this a transactional exchange or not? The fact that there might be 4 types of frame exchanges does not affect the answer. So? What's the answer? You don't need to wait until Tuesday, you can answer now.
regards,
Dan.
--
"the object of life is not to be on the side of the majority, but to
escape finding oneself in the ranks of the insane." – Marcus Aurelius
On 8/31/23, 6:28 PM, "Jay Yang" <yang.zhijie@ZTE .COM.CN> wrote:
Hi Dan,
I have a quick look at your contribution. I've some hard time to understand the question "Is a probe made in response to a Beacon Report Request a transactional exchange? ". There are 4 type of frames exchange in this procedure: Beacon request, Beacon report, probe request and probe response. Beacon report is the response to the Beacon request. So not sure what's the meaning "Beacon Report Request" here.
Anyway, I'm happy to discuss more with you next Tues.
Best Regards
Jay Yang (杨志杰)
Wi-Fi Standard Research Engineer
ZTE Corporation
R&D Building I, No.899 Bibo , Pudong District, Shanghai, P. R. China
Original
From: MarkHamilton <mark.hamilton2152@xxxxxxxxx>
Date: 2023年09月01日 03:59
Subject: Re: [STDS-802-11-TGBH] 11-23/1453r0
Thanks, Dan. I’ve added it.
Mark
From: Harkins , Dan <daniel.harkins@xxxxxxx>
Sent: Thursday, August 31, 2023 12:41 PM
To : Mark Hamilton <mark.hamilton2152@xxxxxxxxx>
Cc: STDS-802-11-TGBH@xxxxxxxxxxxxxxxxx
Subject: 11-23/1453r0
Hi Mark,
I've uploaded document 11-23/1453r0 to mentor. Can you put me on the agenda for the next teleconference on 5 September please?
thanks and regards,
Dan.
--
"the object of life is not to be on the side of the majority, but to
escape finding oneself in the ranks of the insane." – Marcus Aurelius
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
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