| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Hello Duncan and Rojan I agree with Rojan, for each AP in the AP MLD, we should leave SSID setting to the network operator/user like today, not need to add the restriction to .11 spec. They can be either
different or same. Thomas, feedback to your questions in the chat window
1.
I am not aware of any implementation where there is more than one SSID advertised/assigned to a single BSSID (??) ->correct, now each AP in an AP MLD has a unique BSSID, based on your awareness, it is reasonable to have a SSID per AP. Their SSID could be either same or different, depending on the
network operator/user
2.
@Ming, one example (not the only one, by far) - you do SAE auth with an MLD MAC and derive pwd-seed as follows - which SSID do you use? If the two peers don't use the same value it fails. pwd-seed = HKDF-Extract(ssid,
password [|| identifier]) ->It is a professional example, I am not good at this security. Could more than one SSID be mapped to one pwd? As I know, it can be done today. When the STA does SAE with one AP in a
MLD, it could use the SSID of this AP, is there any issue? Aha, I would like to learn it from you. Best wishes Ming Gan 发件人: Rojan Chitrakar [mailto:rojan.chitrakar@xxxxxxxxxxxxxxxx]
Hi Duncan, Thank you for initiating this conversation, I couldn’t ask my question during the call yesterday. Today, SSID is a parameter that is decided by the network operator/User based on the usage scenario.
My opinion is that we should continue this philosophy and not add restrictions in the .11 specification on how the SSIDs are assigned. The MLD framework should be flexible enough to accommodate different deployment scenarios. I have some further comments/questions
inline in blue. Regards, Rojan From: Duncan Ho <dho@xxxxxxxxxxxxxxxx>
Hi all, Thanks for all the comments and discussion regarding this contribution today. Based on the webex chat and comments, seems there are some fundamental issues we may need to resolve first before discussing the options. [RC]: Totally agree that we should resolve the fundamental issues before discussing specific solutions. I’ve listed my assumptions and rationale below. Please let me know your thoughts. Assumption 1: MAC-SAP <-> AP MLD addr <-> AP MLD <-> mlo_ssid are all one-to-one mapped Rationale:
-
Today, a BSSID can only be configured a single SSID and one set of authentication methods associated with it. [RC]: Older APs did support multiple SSIDs/BSSID, but agree that it increases broadcast traffic in a BSS. The motivation for one to one SSID to BSSID mapping was primarily to reduce the broadcast
traffic. What’s your assumption about BSSID for multi-link, is it per link, or do you also assume a MLO BSSID? If it is per link,
your proposal actually brings back the issue of mixed broadcast traffic in a BSS. Taking your example in option2 (slide 7), since the MLO_SSID is overlaid in both links, in each link there will be broadcast traffics for both legacy SSIDs as well as MLD_SSID.
If the same per-link BSSID is used in the broadcast frames, it will cause STAs to unnecessarily receive broadcast traffic not intended for them (which will likely fail due to wrong GTK).
-
Traffic of two different SSIDs should not be mixed together in a single MAC-SAP. The AP device naturally uses different MAC-SAPs to separate the traffic of different SSIDs (e.g., home traffic vs guest traffic). [RC]: I guess you are saying different IP addresses are assigned for different SSIDs, but I think there could be other methods to map upper layer traffic to SSIDs. E.g. for virtual LANs, SSIDs can
be mapped to VLAN IDs; or socket/port based solutions can be used. Q: btw, what’s your assumption for legacy AP MAC-SAP? Is it different from the MLD MAC-SAP or is it the same?
-
The AP MLD address will be used for MLO security key generation (along with the non-AP MLD address) and the AP MLD has a common security association that applies to all the links of the AP MLD. [RC]: Yes, but we did agree that different links have different GTKs, so even with the same SA different SSIDs can still have different GTKs (of course PTKs are always different). Assumption 2: a user (MLO or not) looks for a specific (single) SSID to connect to and inputs the credential corresponding to the SSID. i.e., a user has no control of which specific BSSID
the client should connect to (it’s a client’s decision). Therefore, the mlo_ssid will need to be exposed to the user via scanning. Rationale: preserve the existing Wi-Fi connection user experience (connect to a specific SSID displayed by scan result using the corresponding credential). [RC]: That means the network has one more name. e.g. say you already have a “family” SSID and a “guest” SSID on 5 GHz and 2.4GHz respectively. Now you are saying that there will be one more “family_MLO”
SSID running over both 5GHz and 2.4GHz and specifically caters to the family’s MLO devices right? So essentially the “family_MLO” SSID is overlaid on the 2.4GHz link (and also the 5GHz link). Even for this example, for discovery, each AP could advertise the
same “family_MLO” SSID e.g. in the MLO RNR element (it already has the compressed SSID field), or the MLA element can carry SSID, and a client can easily figure out that this is a MLO SSID. I fail to see why the MLO SSID has to be signaled in a special way.
This way, we can achieve this usage scenario (single MLO SSID over all links), but it also allows SSIDs to be different for links if the deployment chooses. Assumption 3: Most AP vendors provide an App to configure the AP. By default the App can set up a single SSID value for a network created by the user (e.g., home_ssid). For more advanced
users, the App can provide an option to configure extra legacy SSIDs per band Rationale:
-
Most users will be happy with a single SSID (per network created).
-
However, some advanced users may want separate legacy SSIDs so they can control which BSSID each legacy client connects to. It is also desirable not to force the user to re-onboard all the legacy clients (e.g.,
IoT devices) to the new mlo_ssid. [RC]: Agree that it is useful to have different SSIDs, but I disagree that a MLO level SSID should be mandated. Lets say for enterprise networks, you have 2 exiting VLANs on your wired network: VLAN1
for staff and VLAN2 for guests, and 2 legacy BSSs with SSIDs: “STAFF” and “GUEST” that maps to VLAN1 and VLAN2 respectively. Now if the network operator wants to deploy a new AP MLD, how does the VLAN maps to the MLO_SSID? Does a new VLAN needs to be added
just to cater to this new SSID? I think a easier solution is to use the exiting VLAN mapping and let the AP MLD use the same SSIDs, but the SSID is mapped to multiple links for MLDs. Thanks, Duncan To unsubscribe from the STDS-802-11-TGBE list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBE&A=1
To unsubscribe from the STDS-802-11-TGBE list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBE&A=1
To unsubscribe from the STDS-802-11-TGBE list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBE&A=1 |