Hi all,
For protection of ML IE, note that ML IE is not necessary in all management frame from client. However, I think we have protected ML IE in (re)association request/response due to element finger printing and essentially
all the left over management frame from client after association using PMF, so I think we do our part already to protect ML IE from client under CPE. For the ML IE in Beacon, this is related to mobile AP privacy discussion and there are indeed proposals before
about encrypting Beacon frame from Jarkko, but that is an undecided item for BPE.
Go back to the time alignment consideration. I do recall there is a SP before from
Stéphane on this and that seems to have majority support. Note that it does not really say individual or group Epoch, so this SP can be interpreted as for both.
SP#1 initial text: “Do you support that Epoch’s start time of all non-AP STA affiliated to a single non-AP MLD are aligned in time?”
SP#1 results: Y:8 / N:1 / Abstain :2
Best,
Po-Kai
From: Jerome Henry <jhenry@xxxxxxxx>
Sent: Wednesday, April 24, 2024 8:23 AM
To: STDS-802-11-TGBI@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBI] : Do you think that the change of OTA parameters values shall occur at the same time on each link of a given MLD non-AP STA ?
I think you raise a great point. If we are working hard to hide the otaMAC, the AID etc., shouldn't we also protect the ML IE? This sounds like an obvious piece that exposes
too much data about the STA MLD...
Then, this would bring Stephane's question back to the front burner, if the ML IE is protected somehow, should the STA MLD change all its links at the same time?
---- On Mon, 22 Apr 2024 02:27:32 -0400
ANTONIO DE LA OLIVA DELGADO <aoliva@xxxxxxxxxx> wrote ---
Hi Stephane, thanks for initiating this,
regarding question 1, I fear the multi-link element is sent in all frames and it includes the MLD MAC address, so we need to change simultaneously both links (imho).
Also, (please MLD experts correct me), I think a frame can be retx in any link of the MLD (I would assume that you need to redo the header of it), therefore we also need to
make sure that the epoch durations are the same in both links, so we go in the direction of changing simultaneously all links in an MLD.
Another thought is, if we have different bands, maybe one band is way slower than the other, and this may affect the time we need to wait for frames in a buffer to be sent.
So we need to be careful in the epoch time selection, so all buffered frames in all links have enough time to be transmitted.
Hi Carol,
Thank you for sharing your thought.
I think we have two questions now:
-
Shall all the MLDs of a given group initiate a change their OTA values on all links at the same time ? I think yes.
This is the original purpose of the SP I would like to run, since I think this is an important point to solve.
On one hand, this indicates correlation between links (revealing the MLD structure, but this info is also available in clear in the ML IE in beacons).
On the other hand, this avoid correlation between Old and new OTA values across links, and contribute to the mass effect to hide a STA in the crowd.
-
What happens to the buffered traffic when Epoch start occurs (on both AP and non-AP side)?
I think this question is related to the handling of transition period, but of course transition period and Epoch start are linked.
I my mind, as written in the D0.3, each Epoch starts with a transition period.
Assuming all the non-AP MLD of a given group starts a new Epoch at the same time (TSF counter based), all the non-AP STA, associated to a non-AP MLD registered to a given EDP Epoch group, starts
a new Epoch at the same time.
This new Epoch starts with a transition period that allow transmission of buffered frames using Old OTA values (currently only retransmissions in D0.3, but we can discuss that ), and New OTA
values without mixing them in a same TxOP (to avoid correlation).
At the end of the transition, a non-AP STA is not allowed to used old OTA values for transmission of any frames, nor decode received frames using old OTA values. So if the STA still has some
retransmission using OLD OTA values waiting for transmission, those frames should be flushed.
For transition period I think we can discuss using 11-23/1148r0 (slide 7 and 8) as support. I can (re)present it next session if needed.
Stéphane.
From: Carol Ansley <carol@xxxxxxxxxx>
Sent: vendredi 19 avril 2024 23:02
To:
STDS-802-11-TGBI@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBI] : Do you think that the change of OTA parameters values shall occur at the same time on each link of a given MLD non-AP STA ?
|
BEWARE: This email originated outside of our organization. DO NOT CLICK links or attachments unless you recognize the sender and know the content is safe.
Please report all suspicious emails to the ISS department as an attachment.
|
Hello Jerome and Stephane and everyone,
While I agree that to avoid an observer being able to use the changeover to glean more information about the MLDs, at the same time, we need to consider how to word the text
for clarity.
For example, If an MLD has a full queue of packets waiting to go out on its 5GHz link as the current epoch ends, do the other links in the MLD wait to start using the new
information until the 5GHz link finishes sending the old information? What about the other MLDs in the Epoch group? To say it another way, do all of the buffers on all of the links need to be purged before the new headers and numbers start being used?
What happens on the AP side? Does the AP MLD need to discard any packets that are still in a queue at the end of an epoch or rework them once the new epoch time is reached?
Or does it just finish blasting them all out with the old information until it gets to the next epoch’s packets?
Thinking about what can be seen on the air – the SN/PN sequences shared across the link of an MLD unfortunately can be used to connect those links to a single MLD. As long
as one of the affiliated STAs is still using the old parameters, an observer knows that MLD is still there.
Is this straw poll intended to ask about what a single MLD does across its affiliated STAs, or what all of the MLDS in that Epoch group will do?
Regards,
Carol
Thanks a lot for starting this exchange. I think that if elements about the MLD are visible on both links, then we have no choice but change at the same
time. If the common elements (e.g. MLD address) are hidden, then there is only a weaker need to change all links at the same time. Quite obviously, the simultaneity of these changes can be used to spot a STA (2 MACs change on 2 links at the same time -> it's
the same STA device). If we go that direction, I would recommend implementing your +/- rand interval method with different values for each link, to avoid this simultaneity.
Hi everybody,
During the last TGbi teleconference, one question was raised and some members expressed the need to discuss this question on the reflector, so here is the starting point of this thread.
The question is : “Do you think that the change of OTA parameters values (like MAC address, AID, SN, PN, etc.) shall occur at the same time on each link of a given MLD non-AP STA ?”
The plan is to be able to run this SP or a similar one during next TGbi session on April 17th, and to collect opinion on this subject in the meantime.
My personal opinion is that, yes, we need to do this to avoid easy correlation between old and new OTA values if some old and new OTA values are used for the same parameter on different links (for instance, MLD level
parameters like the AID).
The discussion is now open.
Best regards.
Stéphane.
To unsubscribe from the STDS-802-11-TGBI list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBI&A=1
To unsubscribe from the STDS-802-11-TGBI list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBI&A=1
To unsubscribe from the STDS-802-11-TGBI list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBI&A=1
To unsubscribe from the STDS-802-11-TGBI list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBI&A=1
--
Associate Professor
Telematics Department
Universidad Carlos III de Madrid
E-mail: aoliva@xxxxxxxxxx
Phone: +34 91 624 8803
Fax: +34 91 624 8749
To unsubscribe from the STDS-802-11-TGBI list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBI&A=1
To unsubscribe from the STDS-802-11-TGBI list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBI&A=1
To unsubscribe from the STDS-802-11-TGBI list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBI&A=1
|