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;
Date:   Thu, 28 Apr 2022 20:07:29 +0300
From:   Jouni Malinen <j@w1.fi>
To:     Johannes Berg <johannes@sipsolutions.net>
Cc:     Vasanthakumar Thiagarajan <quic_vthiagar@quicinc.com>,
        linux-wireless@vger.kernel.org
Subject: Re: [RFC PATCH] cfg80211: do some rework towards MLO link APIs
Message-ID: <20220428170729.GA13599@w1.fi>
References: <20220414145522.116716-1-johannes@sipsolutions.net>
 <f137ca7f-8b59-3368-c666-247f83d80383@quicinc.com>
 <6b40798e349d11e495a6df20ecba479a8357dad2.camel@sipsolutions.net>
 <ff39ff9b6b1a6619ab30118e8a76b43ad2b9a715.camel@sipsolutions.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <ff39ff9b6b1a6619ab30118e8a76b43ad2b9a715.camel@sipsolutions.net>
Precedence: bulk

On Thu, Apr 28, 2022 at 02:36:26PM +0200, Johannes Berg wrote:
> However, I'm starting to have second thoughts on this.
> 
> I do understand the concern that Jouni mentioned, that the device might
> roam by itself, and change the underlying links, and you'd have races if
> you identify only by the link ID, and that just changed, and so now
> you're referring to something else. His suggestion was that we might
> need to include the BSSID or the address of the AP MLD, or such, in some
> cases. [1]
> 
> However, if e.g. roaming is offloaded but the supplicant isn't, then we
> really do need the ability to refer to the link ID, e.g. to set the per
> link GTK/IGTK/BIGTK after the 4-way-HS (or later 2-way-HS).
> 
> So now I'm wondering what we're achieving by having a mapping, if every
> component in the system needs to be aware of the mapping?

There are use cases where over-the-air Link ID is used and other cases
where it is more appropriate to identify the local link based on the
band (or subband, etc.) in a manner that is valid over one or multiple
associations. It might actually make more sense to come up with two
nl80211 attributes for identifying a link based on either the
over-the-air Link ID (which is valid only during an association and can
change whenever roaming occurs) or the internal identifier for a link.

This would allow nl80211 commands to use only one of the possible ways
of identifying link so that user space components would not need to know
or care about the mapping and would just use the variant that is easier
for the particular case. For nl80211 event messages, both attributes
could be included since the driver and/or cfg80211 would know the
mapping and could fill in both options so that the user space components
would not need to be aware of the full mapping.

In addition, there seems to still be some open discussion on how various
Management frames are targeting specific links and that might even
result in there being a protocol mechanism for targeting a subset of the
available links, i.e., not all of MLD but one or more links. I'm not
sure whether this would need anything particular in nl80211 since we
could always send multiple copies of the command/event (one per link),
but it might also be convenient to be able to use an array of the
over-the-air and/or internal identifiers for the links.

-- 
Jouni Malinen                                            PGP id EFC895FA