Feature request: use random MAC addresses when scanning

[Johannes Berg]

On Wed, 2014-06-11 at 01:00 +0200, Björn Smedman wrote:

> 1. Software-Defined Networking (SDN), arguably the most promising
> trend in networking research today relies heavily on MAC addresses as
> unique identifiers. A growing body of work applying SDN principles to
> Wi-Fi (e.g. CloudMAC [1], Odin [2] and our very own Anyfi.net [3])
> uses the MAC address in probe requests to do *good*, like providing
> seamless and secure access to your favorite Wi-Fi networks on the go
> [4].

This seems like it's already broken with iOS8 now - better think about
alternatives! HS2 is probably a decent one, even if it's not as
seamless.

> 2. As Jouni points out there's a number of corner cases... One is how
> Wi-Fi chipsets typically use an "ack filter" to support multiple
> virtual Wi-Fi interfaces, and how assigning random MACs to such
> interfaces could cause the hardware to start acking frames destined
> for other STAs. Not good.

Clearly this requires some kind of low-level help, but should in
practice be trivial: the driver would just reprogram the MAC address for
the duration of the scan, or so.

For many devices, this would also have to be done in firmware anyway as
offloaded scan (sched_scan) should have a new MAC address every
iteration.

> 3. I'm sure there's a bunch of other problems that nobody has thought
> of yet... That's why we have the IEEE Standards Assocation, so that we
> can carefully think through and define the interface between network
> and device. They could have opted for random MACs in general back when
> IEEE 802 went to the ballot, but they didn't... perhaps wisely, who
> knows.

I don't see where this type of behaviour would not be covered by the
spec, care to elaborate? As observed over the air, the device would
appear to simply be multiple devices to others, each of which is
scanning once and then disappearing from the area. This doesn't seem
like a problem at all.

> A. Scanning with a random MAC should IMHO be seen as sort of the Wi-Fi
> equivalent of an incognito browser window: sure you can browse the web
> with cookies and javascript disabled, but you can't expect to always
> see the same thing that you'd see in a normal browser window.

I don't think this makes sense at all. The whole purpose of this feature
is that you want to avoid being tracked while just doing background
scanning - if you really want incognito mode you already have it - turn
off wifi! When connecting you'd still use the regular MAC address, so
your "incognito scan" really makes no sense at all, you might as well
turn off wifi completely and only turn it back on when you get back
home.

> B. Like the incognito browsing mode the "incognito scan" doesn't come
> with an absolute guarantee of privacy. A malicious tracking device
> could e.g. answer all probe requests from random MACs with a storm of
> probe responses containing commonly used SSIDs... As I interpret the
> Apple slide [5] an iOS 8 device with one of these SSIDs in its
> preferred network list would then most likely transmit an
> Authentication frame with the device's real (universal) MAC address.
> For real privacy we need new standards.

This is clearly true, but as Dan points out it would also have to match
the security parameters, and, this is more important, this privacy leak
has mostly been plugged already anyway - many systems no longer add
SSIDs to active probe requests unless the network they're for has been
detected to have been using hidden SSIDs. As those are becoming deployed
less (afaict), there won't be much to respond with.

> C. IMHO this "incognito scan" operation should be considered a third
> type of scan, alongside the current active and passive scan types.
> This implies that it shouldn't be a static option in a configuration
> file, but instead a parameter in the DBus API
> (type=passive|incognito|active) or similar.

As this only affects active scan to start with, that makes some amount
of sense, but I don't see any situation in which it would make sense to
enable active rather than incognito - unless you specifically want to
interoperate with anyfi.net. Presumably though, that product not being
able to work with iOS 8 any more means deployments will become
uninteresting soon.

> D. Personally I think it's a reasonable to prioritize privacy over
> connectivity when my device is in standby, i.e. I'd like my connection
> manager to issue passive scan commands in this state. If it has to
> talk GAS/ANQP (to connect to an 802.11u / Hotspot 2.0 network) then
> I'd be happy for the connection manager to issue an incognito scan
> command now and again, while my device is in standby.

Passive scanning can use more power due to the significantly longer
dwell time, so you'd typically try to avoid that, especially in standby.
It's also less reliable.

> E. When I'm actively using my device on the other hand I prefer that
> it can connect to whatever network there is (be it hidden or
> SDN-based) without fuss. To me that's more important than the very
> marginal effect it might have on my privacy. So, for me at least, the
> golden rule of scanning should be: "when the device wakes up due to
> user input do a real active scan."

That doesn't make a lot of sense for most users though - when the device
wakes up due to user input you already want to have a connection active
and ready to go... As a user, you don't want to have to wait ~15 seconds
after you turn on your phone. Having a "foreground scan mode" thus makes
little sense.

> F. But everyone's entitled to their own opinion, and privacy vs.
> functionality is certainly an area where opinions differ a lot. For
> that reason I think this should be an option for the end-user, and a
> conservative approach dictates that it should probably be off by
> default.

I don't disagree with that, but I'd expect distributions and system
integrators to turn it on by default :-)

> To summarize I'd rather see this go through standardization within the
> IEEE. An amendment for improved privacy is sorely needed. That's my 2
> cents.

As I said, I don't think there's any need for this. I don't see anything
that's not in line with the spec already today.

Either way, in terms of the implementation, given that sched_scan is
deployed relatively widely, it'll mostly be drivers/firmware. This may
take a while, but a mac80211 implementation with e.g. ath9k should be
really simple.

johannes