Feature request: use random MAC addresses when scanning

[Jouni Malinen]

On Sun, Jun 15, 2014 at 10:49:37PM +0200, Bj?rn Smedman wrote:
> On Sun, Jun 15, 2014 at 1:33 AM, Mathy <vanhoefm at gmail.com> wrote:
> > Isn't this problem avoided by using the *same* random MAC address in
> > both bands? So in one single "individual" scan (over all channels
> > and/or bands) all probe requests get the same random MAC address. In
> > the next scan a new random MAC address is generated, which is again
> > used in all channels/bands. This way we're using random MAC addresses,
> > yet band steering still works.
> 
> I can't see how that would work. The AP has to decide immediately
> (while the scanning STA is still on the channel) if it should send a
> 2.4 Ghz Probe response, it can't sit back and wait for a 5 Ghz probe
> to show up or not. This is how the Aerohive describe their
> implementation [10]:

An AP that is not replying to Probe Request frames based on whether it
has or hasn't seen the station send frames on 5 GHz band is not
compliant with the IEEE 802.11 standard. When one uses non-standard
hacks, one better be prepared for them not working. Getting stations to
prefer 5 GHz band should be done in co-operation with stations, not by
trying to hide information (Probe Response frames or even worse, SSID
from Beacom frames) from them.

> The index in that radio management database is of course the client's
> MAC. And that's far from the only radio management implementation out
> there that uses Probe request MACs in some way. At least Meru and
> Extricom are doing quite a lot on that level.

> Essentially I think it boils down to this: Will some things break?
> Yes. Is privacy important enough to break some stuff over? Certainly.
> So there's a trade-off to be made. I guess what's debatable is how and
> where to make that trade-off. Personally I'm hoping for IEEE-SA, but I
> can certainly see how walking in Apple's footsteps (breaking the same
> things they do - or less) can also make sense.

Whether one would consider this breaking or fixing depends on the view
point, I guess.. For me, it sounds like this could actually be fixing
those APs to behave as the standard mandates if all scans are using
different MAC addresses.. Could even use different MAC address for 2.4
GHz and 5 GHz channel within the same scan if needed.. Bandsteering
should really be done with station vendors taking part in the design
rather than something being "forced" to them with AP trying to do
something non-standard in hopes of all stations reacting to this in a
predictable way.

The more I think about this from both the privacy and existing
bandsteering hacks view points, the more I want to make the random
source address active scan (while not associated) the default behavior.
This should come with improved channel selection/preference on the
station side to allow information from the APs to be used to give higher
priority to channels where the network would be more likely to get
better performance.

No one is going to wait for IEEE 802.11 to complete a new amendment
process (years) for this. The current standard does not take any
position in a physical device containing multiple virtual stations. This
applies both for multi-BSSID/SSID APs and stations using multiple
addresses. Unlike those bandsteering APs, the device using a different
instance of a station for a scan would be compliant with the standard,
IMHO.

Going beyond pre-connection steps (scan + GAS/ANQP) with random,
temporary addresses is a different question, though. That's something
that really should go through the IEEE 802.11 effort. That has been
proposed multiple times over the years, but nothing has received enough
support to get started yet.

-- 
Jouni Malinen                                            PGP id EFC895FA