[PATCH] SME: handle 802.11w association comeback

[Johannes Berg]

On Sun, 2024-01-21 at 22:44 +0200, Jouni Malinen wrote:
> On Sun, Jan 21, 2024 at 09:20:42PM +0100, Johannes Berg wrote:
> > On Sun, 2024-01-21 at 12:29 +0200, Jouni Malinen wrote:
> > > In fact, I was even
> > > able to test this with mac80211_hwsim by disabling the kernel side
> > > association comeback mechanism.
> > 
> > I suppose we could even make some kind of parameter from hwsim towards
> > mac80211 to disable using it, if you wanted to be able to test this
> > further? Perhaps hidden behind a Kconfig option, though in this case I
> > wouldn't even really be worried about code size/etc. since it's really
> > not a hot path in the first place.
> 
> It was actually easy to do this in hostapd/wpa_supplicant by having them
> use a different Timeout Interval Type field value in the Timeout
> Interval element as testing functionality since that was all that it
> took to "disable" the functionality in mac80211.. In other words, I
> already added a fully automated this for this without needing kernel
> changes.

Fair point, didn't think of that last night :)

> > I also have in the back of my mind to add a kind of strict mode to
> > mac80211, where we would remove workarounds for various broken APs like
> > the one we'll probably put in for the CSA thing ... Or checking more
> > strictly channel configuration from beacon vs. assoc response, etc.
> 
> That would likely be useful for various testing needs..

Yes ... not really just here. In fact I had other tests in mind foremost
:-)

> > I'm thinking of making that a parameter that comes from the driver to
> > the stack, so that it'd be possible to run tests with some hwsim radios
> > configured one way and some another way, or really more pragmatically so
> > we could do different tests in different ways without having to
> > reconfigure "everything" (just a new hwsim radio that changes the
> > settings here would be sufficient for the hwsim case). This would kind
> > of fit in a similar fashion?
> 
> This would also be useful for the mac80211_hwsim tests in hostap.git.

Right.

Though I guess we've established that for this particular use case it's
not needed in the first place.

> > Though actually if we have comeback mechanism in userspace, maybe more
> > generally we want to be able to disable the kernel mechanism, opt-in by
> > an assoc-request flag?
> 
> Yes, I started to think about something like this after realizing how
> simple it was to make this work in wpa_supplicant. I don't remember how
> we ended up with the mac80211-based design in the first place, but there
> is really no need for that there since the auth/assoc split works
> without issues with userspace taking case of that part of complexity.

I don't really remember either, but thinking about it now, I'd say
there's one slight/potential advantage of doing it in the kernel: it
leaves us with a bit less work towards the driver, because we keep
ifmgd->assoc_data around for the time, and that means we don't delete
the station, unconfigure the channel, etc. OTOH, you could argue that at
some timeout that actually makes less sense though, since that might use
additional power depending on how the driver/device handles this state.

We could also just handle it like the 'abandoned auth to assoc' case
with IEEE80211_AUTH_WAIT_ASSOC, where we wait for up to 5 seconds after
auth to see if userspace will assoc, to avoid reconfiguring the whole
state in case it comes around immediately... So we could do a similar
thing with assoc failure under the conditions where we handle it today
in the kernel completely?

I'm also not sure why we have a separate event (cfg80211_assoc_comeback
/ NL80211_CMD_ASSOC_COMEBACK) for this?

> If
> nothing else, this would have avoided the race condition issues that
> showed up with kernel scheduling changes in UML time travel.

:)

> One thing I noticed when looking at the details was that there was no
> explicit limit on the maximum comeback time. I added one in the
> wpa_supplicant implementation to avoid pointless wait of something like
> 50 days that could be hit by injecting an unprotected Association
> Response frame. mac80211 could do something similar. Though, at least
> wpa_supplicant would be timing that out with the overall connection
> timeout, so the practical impact from a potential attack would be quite
> limited.

Right. I feel like I've also thought about this in the past.

johannes