Feature request: use random MAC addresses when scanning

[Björn Smedman]

On Sun, Jun 15, 2014 at 1:33 AM, Mathy <vanhoefm at gmail.com> wrote:
> On Fri, Jun 13, 2014 at 10:51 PM, Bj?rn Smedman <bs at anyfi.net> wrote:
>> On Fri, Jun 13, 2014 at 9:30 AM, Johannes Berg
>> <johannes at sipsolutions.net> wrote:
>>> On Fri, 2014-06-13 at 02:53 +0200, Bj?rn Smedman wrote:
>>>> 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
>>>
>>> I think this is debatable. The check makes a certain amount of sense,
>>> though I'd argue it's mostly for the case where there actually *are*
>>> different probe responses. That's unlikely to start with.
>>
>> That depends on what you mean by unlikely... In addition to hidden and
>> SDN-based networks there's e.g. band steering [9]: a dual-band
>> AP/network makes note of the MAC addresses in 5Ghz Probe requests
>> (because they indicate that the device has a 5Ghz-capable radio) and
>> withhold Probe response to the same MACs in the 2.4Ghz band. This is a
>> feature on just about every enterprise/carrier-grade AP (Cisco,
>> Ruckus, Aruba, Meru, Extricom, Aerohive, Xirrus, etc). It's widely
>> deployed.
>>
>> 9. https://kb.meraki.com/knowledge_base/dual-band-operation-with-band-steering
>>
> 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]:

  To move user traffic to the 5 GHz band, the network must discover
  devices that are capable of 5 GHz operation and encourage its use.
  Aerohive?s cooperative control architecture allows the network to
  build a list of devices capable of 5 GHz operation that is shared
  among all HiveAPs in a network. When a HiveAP receives a Probe
  Request from a device on an 802.11a/na channel, that client?s
  record in the radio management database is marked as ?5 GHz-
  capable.? When a HiveAP receives a Probe Request from a 5 GHz-
  capable client device on an 802.11b/g band, it will hold the
  response to encourage the client to move to a 5 GHz channel.

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.

Bj?rn

10. http://www.aerohive.com/pdfs/Aerohive-Solution_Brief-Radio_Resource_Management_in_HiveOS.pdf