Hi Sid,
A short response to your last point,
“if RCM broke that use case, the average user has not noticed the ramifications of it”. I will appreciate you can spend some time to read the following white paper released by WBA, there are 20+ use cases in which the RCM
brings troubles to Wi-Fi industry.
Wi-Fi Device Identification - A Way Through MAC Randomization - Wireless Broadband Alliance (wballiance.com)
BTW, If your guys have enough efforts to debate all the use cases, let’s go on..
Thanks
Best Regards
Jay Yang
From: Sid Thakur <00001f4073a0efd1-dmarc-request@xxxxxxxxxxxxxxxxx>
Sent: 2023年2月28日 7:52
To: STDS-802-11-TGBH@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBH] RRCM versus e-RRCM for TGbh motion on Feb 28
Dan
While troubleshooting in the pre-association case may be a necessity, the user by agreeing to troubleshooting does give consent to being identified. That is why I was asking for an explicit MIB for pre-association identification.
However, for client steering, there is no establishment of trust in a pre-association environment. Further, as Jarkko mentioned on several occasions that pre-association steering mechanisms have not been defined in 802.11, I’m not sure
we should add a mechanism to enable a mechanism that is not part of the standard. One of the reasons, RCM was designed because there was a concern about being identifiable in an untrusted environment. Therefore, I don’t understand why we would eliminate that
anonymity for the sake of one use case that’s not in the standard and second, if RCM broke that use case, the average user has not noticed the ramifications of it.
Hi Dan, some comments inline.
Hi Dan, some questions inline.
You know what else "does not exist in 802.11"? Troubleshooting. But I'm sure you'll admit that some STAs do have trouble connecting to 802.11 networks and that does require this thing we call troubleshooting and that traditionally involved
a question along the lines of "OK, what's your MAC address?"
The current Device ID is communicated in 4-way handshake. Why this is not enough for troubleshooting?
Well the 4way handshake is done not only post association but post authentication. If you've gotten that far then your need for troubleshooting is what exactly?
It is not good choice for STA to identify to an AP to which authentication fails.
In general, AP cannot provide the device identifier for the STA, because STA cannot authenticate with the AP.
If authentication fails then there will be no 4way HS so I still contend that "this is not enough for troubleshooting."
The device identifier is not used in authentication so the inability of an AP to provide a device identifier to the STA has no impact whatsoever on authentication.
Similarly APs do discriminate based on transmitter of probes because some STAs are poorly written and they need a bit of encouragement to do the right thing. This is a real world feature even if it "does not exist in 802.11."
I am lost here. Can you be more specific? What do you mean on encouragement?
Like not responding to a STA on a certain band that the AP doesn't want it to be on.
As discussed before, 802.11 does not have mechanisms to control Probe Responses transmission to STAs.
- The 802.11 rules for sending probe response frames do not consider the transmitter of the probe request.
- Even is STA never changes its MAC address, the STA will learn all available APs by passively scanning. Even bad behaving APs, not compliant with 802.11, cannot
As a summary "pre-associated STA steering with probes" cannot be fixed in 802.11bh, because:
1) It does not exist in 802.11
2) It is not broken by random and changing MAC addresses.
Just repeating yourself does not change anything. This is done today even if it is not described in 802.11 today. You know what else doesn't exist in 802.11? Split MAC architectures. Do they exist though in spite of not existing in the
standard? Of course! You seem to be in the "that which is not forbidden is cumpulsory" camp. That's not how things have been, are, and will be implemented.
"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
"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
Hi Jay, thank you for your responses.
Yes, it would be great if we can agree to IE instead of STA MAC addresses in device identification schemes.
As discussed earlier, the pre-associated STA steering with probes (use case 4.8) has functionality that is not compatible with 802.11 standard.
- The 802.11 rules for sending probe response frames do not consider the transmitter of the probe request.
- Even is STA never changes its MAC address, the STA will learn all available APs by passively scanning. Even bad behaving APs, not compliant with 802.11, cannot steer the STA.
As a summary "pre-associated STA steering with probes" cannot be fixed in 802.11bh, because:
1) It does not exist in 802.11
2) It is not broken by random and changing MAC addresses.
Other WBA or WFA groups may have their own device identifiers, rules and use cases for device identification.
- I need more details on this WBA use case to understand and comment it.
There is an use case/requirement defined by WBA pass point white paper that may attack STA vendor’s eyes for pre-association identification schemes, in which the network (including both base station and AP) support for roaming between
base station and AP without interruption in voice and video.
The general scenario may like this(See the figure below). The network understands the current traffic loading for each UE, based on “I know you” identifier, the network can recommend the
suitable candidate AP for each STA, to achieve the traffic seamless roaming from base station to AP. Such frame exchange may be happened via ANQP frame.
Form STA/UE side, regardless any recommendation in pre-association, there is no way for STA to understand whether the expected AP can afford current traffic loading requirement, the voice and video service interruption issue may happen.
Thanks for your response. At least I see it’s possible that we could reach some consensus and move forward. See my response in blue font.
Hi Jay, thank you for your comments.
Thanks for the comments, see my response inline.
· Are there aspects of e-RRCM that you oppose, and bringing those into the proposal
that is put to motion next week would cause you to vote No?
1) RRCM and e-RRCM allow STA to use only MAC addresses that are calculated by using RMAK.
- This limits STA operation flexibility to freely select its MAC address.
àBased on 11aq, each STA calculates its RMA based on one private equation. In e-RRCM, both side calculate the same RMAs based on the pre-defined equation, it’s
easy for implementor to switch from private equation to the pre-defined equation. Anyway, If you have a strong concern on the MAC based solution, we can move it to the IE element. The purpose of the generated RMA is to find the right key on both side in e-RRCM
solution, no matter it’s MAC address or other staff.
JKN: IE based solution would be much better than MAC address based solution.
The STA has selected its MAC address and this selection is widely deployed.
The use of IE would solve this comment.
<Jay> it will be grateful if the group can reach the consensus on this direction.
2) The use case for pre-association STA identification is not clear to me.
- What benefits does STA get if it identifies itself before association?
àWhen we talk some use cases like use case 4.8 and use case 4.26 etc. in last year, your guys also agree these cases should be addressed and updated them into
the latest use case tracking document, which is approved by the group with unanimous consensus.
Anyway, I’m happy to explain the benefit to the STA again, in order to get some STA vendor’s support.
If you look Link recommendation feature defined in the latest 11be draft, in which “An AP MLD may also use Multi-Link Traffic Indication element and AID Bitmap element in a Link Recommendation frame to recommend
a non-AP MLD to use one or more enabled links for all exchanges both for DL and UL”. Actually, Link recommendation inherits the spirt from Client steering/band steering function, in which AP provides the recommended candidate bands or Neighbor APs, so that
STA can obtain the better services on that AP/band. However, the Client steering/band steering is based on the BTM request/response frame change, while allow STA make the final decision. Please see the details in 818r2 “P5,
Client steering”
JKN: If I understand your response correctly, you are saying that main benefit of pre-associated STA identification is that network can steer the STA to operate on a network selected BSS, right?
- STA may have reasons to select a network that is not obvious for the AP. For instance, STA may have co-ex issues or operate P2P connection.
<Jay> The term of client steering or band steering is widely used in Wi-Fi industry, but the basic principle is that network provides the recommendation of the candidate AP. E.g. In our implementation, The network
will provide the candidate APs for mobility STA, It’s up to the STA to follow such recommendation or not.
The Link Recommendation and BSS Transition Management (BTM) can be used to steer associated STAs.
Steering in associated state is much better for the STA, because the STA can send data and have time to select the AP for its association.
<Jay> The use case 4.8 is aligned what you are talking, it’s a post-association client
steering case indeed.
I do not know how the pre-associated STA steering will be done. I think 802.11 specification has no feature or signaling to steer such pre-associated STA.
- Only steering mechanism I can think is to fail the identified STA association. This is bad for the STA, because:
- STA does not know to which BSS it should associate
- Some networks may require STA identification to get access to the network. The device identification should be always optional.
<Jay> I see the similar concern from other members, I think we can drop this use case in this round, maybe need further talk in the feature. Do you have some suggestion to avoid AP/ESS to have such implantation?
- What benefits does STA get if it identifies itself before association?
-I do not see any response to this question. It seems that there are no benefits for the STA to be identified before association.
<Jay> use case 4.8 is an instance of BTM for associated STA, seems you don’t object this use case, could you check that use case step by step, let we know which
step is unreasonable or unacceptable?
3) RRCM, e-RRCM and Device ID are alternative, non-interworking, protocols to identify a device.
- Why Device ID is not enough? Device ID has been long time in 802.11bh draft.
àThe current Device ID is only carried in 4-WAY handshake, if the Device ID or other identifier can be carried in other frame, like triggered probe, it will address
a lot of implementation broken issue.
- STAs do a lot of passive scanning, so limiting probe responses does not work
<Jay> I don’t remember this group have such use case in the use case tracking document. Maybe some members mentioned it during the call, I saw other members also against it. I also hope the group drop this use
case in this round.
- The probe responses should be common for all STAs. Probe Responses may select the APs they advertise in Reduced Neighbor Report, but this information is common for all STAs.
<Jay> It’s case by case, if we’re talking use case 4.8, the candidate APs only collect the metric based on the *-LTF filed in the probe request, while the information in the probe
response is common for all STAs.
Further, for broadcast probe response, I agree all information should be same for all STAs. For unicast probe response, there may be some difference for each STAs due to some security
concern on AP side. E.g. In some mesh network, the SSID information is only seen for candidate backhaul STAs in the unicast probe response.
Further, Our chair Mark made a lot of interpretation on the use cases defined in 11bh PAR in the previous meeting, and seems the current Device ID approach can’t meet the requirement on any of them. It’s decided
by whether you want to see the group to finish the task group job in the following plenary meeting. Or we still have enough time, like use more than 1 years to analysis the PAR, analysis the use case from End to End perspective as Sid proposed during the call.
After the down-select procedure, Sid provided 4 extra requirements for pre-association identification scheme in the last call. Suppose some of “Apple funs” keep this position as well. If we insist to working on RRCM solution, I believe
“Apple funs” will strong against the down-select results. And the expected motion will be failure definitely.
May I request to go with e-RRCM solution which may meet the 4 extra requirements listed by Sid? I would like to hear the group’s opinion.
1. Consent
2. Unauthenticated environment
3. Malicious 3rd party protection
4. What is identifier used for
I took an action item to start this discussion on the reflector…
On today’s call, we completed our down-selection process and settled on RRCM as the favored solution to work on, to try to get any additional solution into the Draft (or agree that we are not adding anything else). However, in discussion
following the down-selection process, it seems that some of the objection that might exist and prevent RRCM from passing such a motion, *might* be resolved by aspects of what’s in e-RRCM. So, we are left in a quandary – do we modify RRCM to include
some/all e-RRCM extensions to satisfy the concerns, or is that reversing our straw poll guidance that RRCM is preferred over e-RRCM, and therefore we’ll lose some RRCM supporting voters if we do so?
So, I’d like to start this thread to see if there is a sense in the group:
· Can those who preferred RRCM over e-RRCM provide an understanding of what
made that decision for you?
· Are there aspects of e-RRCM that we can add to RRCM (to satisfy those who
expressed concerns with RRCM as-is) and still hold your approval of RRCM going forward into the Draft?
· Are there aspects of e-RRCM that you oppose, and bringing those into the proposal
that is put to motion next week would cause you to vote No?
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
|