Mesh/Tracking - Revision history

Juul at 14:16, 2 July 2015

2015-07-02T14:16:38Z

← Older revision		Revision as of 07:16, 2 July 2015
Line 6:		Line 6:

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

			Well, there is another way: Don't give clients IPv6 addresses at all and drop all IPv6 packets to/from clients. This is easy but sucks.

Juul at 14:15, 2 July 2015

2015-07-02T14:15:45Z

← Older revision		Revision as of 07:15, 2 July 2015
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~~.

Juul: /* MAC address logging */

2013-10-10T08:22:47Z

MAC address logging

← Older revision		Revision as of 01:22, 10 October 2013
Line 11:		Line 11:
	= MAC address logging =		= 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~~. It's unclear if not logging MAC addreses is really that important, since anyone listening to network traffic would be able to see which devices connect~~.		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.

Juul: Created page with "sudomesh does not want to do any tracking or logging, nor do we wish to facilitate any tracking or logging. = MAC address tracking = Since batman-adv operates on layer 2, i..."

2013-10-10T08:22:25Z

Created page with "sudomesh does not want to do any tracking or logging, nor do we wish to facilitate any tracking or logging. = MAC address tracking = Since batman-adv operates on layer 2, i..."

New page

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

= MAC address tracking =

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.

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.

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. It's unclear if not logging MAC addreses is really that important, since anyone listening to network traffic would be able to see which devices connect.