Feature request: use random MAC addresses when scanning
Björn Smedman
bs
Tue Jun 10 16:00:10 PDT 2014
Please don't use random MAC addresses without thinking it through
carefully. Depending on how you do it a whole lot of good things can
break:
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].
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.
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.
With that said I can certainly see the need for privacy. If something
has to be done now (before standardization can run its course) I think
we should take a conservative approach. Some thoughts that come to
mind:
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.
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.
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.
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.
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."
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.
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.
Cheers,
Bj?rn
1. http://teampal.mc2lab.com/attachments/682/p393-vestin.pdf
2. http://conferences.sigcomm.org/sigcomm/2012/paper/hotsdn/p115.pdf
3. http://anyfi.net/documentation#a_how_it_all_fits_together
4. http://static.anyfinetworks.com/anyfi-sdwn-concepts-wp-20140514.pdf
5. https://twitter.com/fredericjacobs/status/475601665836744704
More information about the Hostap
mailing list