Hi Duncan,
Thank you for the presentation.
I agree somewhat with Ming and Rojan that we can leave SSID for operators.
Though I also see a good point in your presentation that a MLD should be clearly identified as such.
I was wondering whether including the MLD address for all links of the MLD would be sufficient for this purpose?
[DH] I think that is a different issue. Here I’m trying to design
how a non-AP MLD discovers an SSID to connect to. This SSID is “served” by an AP MLD.
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
[DH] Please check my diagram. I don’t see how an MLD can advertise different SSID values on its APs.
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.
[DH] Even WPA2, the SSID and password are used to generate the PMK between the AP MLD and the non-AP MLD.
Best wishes
Ming Gan
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.
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).
[DH] Please check if my diagram clears up the above.
-
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?
[DH] To me, the MAC-SAP is similar to the legacy AP MAC-SAP, except that the AP MLD has multiple APs “connected” to the MAC-SAP.
-
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.
[DH] Your example is NOT something I would recommend because it will be very confusing if my family
members see TWO SSIDs with “family…” in them. They will not know which one to connect to. A more practical example would be “IoT” SSID on 2.4, “guest” SSID on 5GHz, and “Family” SSID on the AP MLD (2.4+5).
We can further discuss how to convey the “Family” SSID. One way is like my diagram shows using M-BSSID set.
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.
[DH] I think the point is an AP MLD should have a single SSID associated with it. The non-AP MLD
will request such SSID when associating with the AP MLD. In your VLAN example above, I would create
two AP MLDs, one for “Staff” and another for “Guest”, and they will be connected to VLAN1 and VLAN2, respectively.
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