Difference between revisions of "Mesh/Tracking"

From Sudo Room
Jump to navigation Jump to search
Line 1: Line 1:
sudomesh does not want to do any tracking or logging, nor do we wish to facilitate any tracking or logging.  
sudomesh does not want to do any tracking or logging, nor do we wish to facilitate any tracking or logging.  


= MAC address tracking =
= IPv6 MAC-embedding =


Since batman-adv operates on layer 2, it should be trivial to track the movement of a device around the network. This means that physical tracking of individuals is very easy if you can link someone's identity to e.g. their smart phone's MAC address.  
The default strategy for clients to self-assign IPv6 addresses according to the standard involves embedding the MAC address of the network adapter into the IPv6 address. This is terrible for privacy since anyone who can see your IPv6 address can track your hardware anywhere you go. There is an alternative specified in the standard but it is only the default in Windows (7 or later I believe). All other major operating systems use the standard-defined default.  


It is difficult to do anything about this. The only solution I can think of is to have people install an app on their phone that switches their MAC address periodically. Every time the MAC address changes, all connections would be dropped though, but it could happen e.g only every 24 hours. We would have to exempt a pool of MAC addresses from seeing the splash page and have the app switch between addresses in that pool. Guaranteeing unique MAC addresses can then become a problem. It seems like this is a mayor downside to using a layer 2 protocol.
The only way we can see around this problem is to run DHCPv6 severs on the mesh nodes so clients have randomized IP addresses assigned every time they connect.
 
Is it possible to have a functioning batman-adv network where devices can communicate, but it is not possible to figure out which node another device is connected to? I know batman-adv has built-in layer 2 traceroute, but is that feature essential to the functioning of the mesh?
 
= MAC address logging =
 
We have to log at least some sort of hash of MAC addresses at the exit nodes in order to ensure that the same device does not see the splash page constantly. This is problematic since a normal hashing algorithm could probably be brute-forced given the effective in-use pool size of MAC addresses, especially if the type of device is known in advance. The solution seems to be to use a hashing algorithm that has some percentage of false positives, such that several MAC addresses would hash to the same value. The only side-effect would be that some devices would not show the splash page when they should. This is ok.

Revision as of 06:15, 2 July 2015

sudomesh does not want to do any tracking or logging, nor do we wish to facilitate any tracking or logging.

IPv6 MAC-embedding

The default strategy for clients to self-assign IPv6 addresses according to the standard involves embedding the MAC address of the network adapter into the IPv6 address. This is terrible for privacy since anyone who can see your IPv6 address can track your hardware anywhere you go. There is an alternative specified in the standard but it is only the default in Windows (7 or later I believe). All other major operating systems use the standard-defined default.

The only way we can see around this problem is to run DHCPv6 severs on the mesh nodes so clients have randomized IP addresses assigned every time they connect.

Retrieved from "https://sudoroom.org/mediawiki/index.php?title=Mesh/Tracking&oldid=9494"