On Tue, 2017-04-11 at 11:30 -0400, Chris Laprise wrote: > On 04/10/2017 01:35 PM, Chris Laprise wrote:
Hi Chris, > > 1. A Study of MAC Address Randomization in Mobile Devices and > > When it Fails > > https://arxiv.org/pdf/1703.02874v1.pdf > > > > A listing of best practices from the paper: > > > Randomize across the entire address, providing > > 2^46 bits of randomization. This can be configured via the wifi.scan-generate-mac-address-mask setting (man NetworkManager.conf). Likewise, there are the per- connection settings wifi.generate-mac-address-mask and ethernet.generate-mac-address-mask. Note, that you can at most randomize 47 bits (to create a unicast MAC address, see man nm-settings). By default the local-address bit is set too, leaving you with mentioned 46 bits. The generate-mac-address-mask setting allows you to explicitly configure which bits are set and/or randomized. > > Use a random address for every probe request > > frame. > > > > Remove sequence numbers from probe requests. > > > > If sequence numbers are used, reset sequence > > number when transmitting authentication and > > association frames. All that NM's randomization does, is to configure a MAC address before issuing the scanning (or before associating). In the logfile you can grep for "set-hw-addr:". It does not sync with supplicant beyond that. This needs investigation what is needed there. > > Never send probe requests using a global MAC > > address. NM should set a random MAC address before requesting the first scan. So, the permanet MAC address shouldn't leave the device. (would need testing + verification). > > Enforce a policy requiring a minimal and stan- > > dard set of vendor IEs. Move any lost function- > > ality to the authentication/association process, > > or upon network establishment utilize discovery > > protocols. > > > > Specifically, the use of WPS attributes should > > be removed except when performing P2P opera- > > tions. Prohibit unique vendor tags such as those > > introduced by Apple iOS 10. > > > > Eliminate the use of directed probe requests for > > cellular offloading. > > > > Mandate that chipset firmware remove behavior > > where RTS frames received while in State 1 elicit > > a CTS response. this also seems to affect more the lower layers + supplicant. Needs investigation. > Seems like NM and careful configuration might address some of these > points... > > > (BTW, the usna.edu address appears to be disabled.) I agree, it would be a worthy task to investigate and fix issues. Thanks for bringing up this topic. Thomas
signature.asc
Description: This is a digitally signed message part
_______________________________________________ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
