Received-SPF: pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <09556b33ad998ad243cf75dbc230f3b07349a87e.camel@sipsolutions.net>
Subject: Re: [PATCH 00/27] another set of MLO patches
From:   Johannes Berg <johannes@sipsolutions.net>
To:     Wen Gong <quic_wgong@quicinc.com>, linux-wireless@vger.kernel.org
Date:   Tue, 06 Sep 2022 09:28:16 +0200
In-Reply-To: <6175bc95-201c-cfab-2ae6-9ba77e830394@quicinc.com>
References: <20220902141259.377789-1-johannes@sipsolutions.net>
         <6175bc95-201c-cfab-2ae6-9ba77e830394@quicinc.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.44.4 (3.44.4-1.fc36) 
MIME-Version: 1.0
Precedence: bulk

Hi,

> The 3 commit below=C2=A0

> wifi: mac80211: mlme: transmit assoc frame with address translation
> https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next.gi=
t/commit/?h=3Dmld&id=3D4ca04ed36478e21b037fc379a7e6f52d0e6d8d52
>=20
> wifi: mac80211: support MLO authentication/association with one link
> https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next.gi=
t/commit/?h=3Dmld&id=3D81151ce462e533551f3284bfdb8e0f461c9220e6
>=20
> wifi: mac80211: do link->MLD address translation on RX
> https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next.gi=
t/commit/?h=3Dmld&id=3D42fb9148c078004d07b4c39bd7b1086b6165780c


(Just noting that they're not part of this patchset, they were there
before)

> changed to use MLD address for send=20
> authentication/assoc request for station and
> changed to use MLD address of rx management packet include=20
> authentication/assoc response received by station from AP.

Yes.

> Does it has any description about the MLD adress in authentication/assoc=
=20
> request/assoc response in IEEE P802.11be=E2=84=A2/D2.0 or other sepcifica=
tion?

Not _really_. I don't think the spec ever really talks about this since
it simply doesn't (need to) care what you do inside your software stack.

However, I believe there are (or will be) cases where even for
management frames we will not want to make a determination which link to
use to transmit - since they're "addressed to the MLD" (see D2.0 35.3.14
Multi-link device individually addressed Management frame delivery).

Note also that for protected management frames, the MLD addresses become
part of the AAD.

Today, auth/assoc frames cannot be encrypted (though that may quite
possibly change for assoc frames in the future), and for them also only
a single link can be selected.

However, I thought that from a software POV it would still be better if
as many MLD-addressed frames actually carried MLD addresses in the
software stack as possible, to unify things with the encryption
requirements etc.

The only exception to this is the first received authentication frame on
the AP which cannot be translated in the stack/driver/firmware since we
don't have a station entry for the new station yet, so hostapd has to be
prepared to handle that very first frame with link addresses.

johannes