Feature request: use random MAC addresses when scanning

[Björn Smedman]

On Thu, Jun 12, 2014 at 9:21 PM, Johannes Berg
<johannes at sipsolutions.net> wrote:
> 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.

The WWDC slide [5] reads "the MAC address used for Wi-Fi scans may not
always be the device's real (universal) address." If anything I think
that wording indicates thoughtfulness, which is really all I'm
advocating here (I'm not saying "don't ever randomize", I'm saying
"please think it through carefully").

5. https://twitter.com/fredericjacobs/status/475601665836744704

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

True, if the chipset/driver can completely focus on the scan. But
looking at mac80211 [6] as an example there's optimization for the
case when we're scanning only the operating channel and there's no
need to disrupt the normal operation of the driver/chipset. That would
be difficult (but also luckily relatively pointless) to do for an
incognito scan.

But what I was really referring to was the far more radical
implementation that would leave the MAC as random when connecting. If
you do that with ath9k and a few virtual STA interfaces (or attempt
the above optimization for incognito scan) you will end up with an ack
mask [7] that is dangerously close to all zeros, i.e. you run the risk
of acking frames addressed to other devices.

Again, I'm not saying there shouldn't be an incognito scan. I'm just
saying "the devil is in the details", and there are a lot of details
here...

6. http://lxr.free-electrons.com/source/net/mac80211/scan.c?v=3.15#L509

7. http://lxr.free-electrons.com/source/drivers/net/wireless/ath/ath9k/main.c?v=3.14#L963

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

True. The somewhat radical step comes if/when you use the probe
response addressed to this randomized MAC to generate an
Authentication frame with the real (universal) MAC (or decide that no
such Authentication frame can be generated)... Again taking mac80211
[8] as a reference there is an explicit check to avoid using probe
responses addressed to other devices:

    /* ignore ProbeResp to foreign address */
    if ((!sdata1 || !ether_addr_equal(mgmt->da, sdata1->vif.addr)) &&
        (!sdata2 || !ether_addr_equal(mgmt->da, sdata2->vif.addr)))
            return;

I think that code makes sense. Essentially that's what I'm (somewhat
clumsily) trying to say in A below: "just because some other device
got a certain Probe Response that doesn't mean I would necessarily get
the same". Also of course in the negative: "just because some other
device didn't get a response doesn't mean I wouldn't."

(And the phrase "some other device" is of course logically
interchangeable with my own incognito alter ego / random MAC.)

8. http://lxr.free-electrons.com/source/net/mac80211/scan.c?v=3.15#L186

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

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

I think there definitely are cases when you want to scan with the real
MAC address, e.g. (at the very least) when already connected there is
little point to incognito scanning (as the real MAC is already out
there) and a number of problems (e.g. it's disruptive to the normal
operation of the chipset/driver as discussed above and it can cause
problems for networks that try to manage handover).

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

Those are good reasons. And again, I'm absolutely not against
"incognito scan" in standby.

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

If there's an active connection ready to go I'm all for it of course,
then we're home free. :)

The case I'm thinking about is when there is no connection when the
device wakes up, because no suitable network has been found with
incognito scan. As I see it there can be two reasons for that: 1)
there simply is no suitable network or 2) there is at least one
suitable network but it's not visible in incognito scan mode. Now the
latter (2) could be a hidden network, or an SDN-based network, or
possibly some other type of networks we haven't yet thought of here at
all. In this case I think it makes sense to do an active scan.

(And I don't agree that this is very different from what a typical
phone does today: When you take the keylock off a smartphone there's
generally a burst of Probe Request frames, some with preferred SSIDs.
I'm just saying we should keep it that way for now.)

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

As I see it this incognito scan is a temporary hack. Real privacy IMHO
requires randomization/encryption of *all* identifying information,
both when scanning and when connected. That's doable, but not without
the IEEE getting involved (at least not in a safe way).

Bj?rn