[PATCH] SME: handle 802.11w association comeback

[Jouni Malinen]

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.

> 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..

> 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.

> 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. 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.

-- 
Jouni Malinen                                            PGP id EFC895FA