On Sun, Nov 10, 2013 at 5:00 PM, rhodey <rhodey@anhonesteffort.org> wrote:
> Not really. Routing protocol measures packet loss from all neighboring
> nodes to the client to determine how to best route traffic to the
> client. You can possible use this as a signal strength indicator.

Aha! Awesome idea Mitar, very tricky. Now we need to configure mesh
nodes to arbitrarily drop packets :P

> You can maybe try to repurpose ARP proxy support in Linux:
>
> https://en.wikipedia.org/wiki/Proxy_ARP

Thanks, I'll take a look.

It seems to me that both of these solutions are likely to degrade the performance of the mesh.

Creating a bunch of fake nodes with fake MAC addresses could make it more difficult to initially identify the MAC address of a target node (because it is easy to associate a MAC with a physical device if there is only one device in that area), but I don't think it would actually accomplish much, since most modern operating systems broadcast stuff like their hostnames and shared files/music. It's often easy to associate a host and MAC/IP. Once you know the MAC of your target, you can track them until they change their MAC. Perhaps it would benefit people who often change their MAC address. It would cause a lot of extra network-wide broadcast of originator-messages.

Perhaps there is a better way to deal with the problem. If I understand batman-adv correctly, no node requires knowledge of anything but the next hop for every destination. This should mean that we don't need the layer 2 traceroute functionality that batman-adv includes. If we change batman-adv such that a node can only ever know the next hop for a given destination, that leaks limited location information (though it could leak info such as general location if e.g. you're in west oakland and you're simultaneously connected to a node that only links to berkeley and another that only links to east oakland). If we need the layer 2 traceroute as network admins, then we can implement crypto such that nodes only respond to layer 2 traceroutes if request has a valid signature. This would not be very difficult since Linux Kernel 3.7+ implements RSA signature verification.

--
Marc/Juul
 
--
-- rhodey ˙ ͜ʟ˙

On 11/10/2013 04:57 PM, Mitar wrote:
> Hi!
>
>> We can ensure that IP addresses are cycled frequent enough because
>> we'll have control over a majority of the DHCP servers on the mesh so
>> I'll be focusing on MAC addresses.
>
> Not to mention that IP addresses will be private and there will be NAT
> for Internet.
>
> And for IPv6 you will probably use autoconfiguration based on the MAC
> anyway, no?
>
> So the question is just MAC at the end.
>
>> It is important to realize that only mesh nodes (access points) have
>> *potential* knowledge of signal strength
>
> Not really. Routing protocol measures packet loss from all neighboring
> nodes to the client to determine how to best route traffic to the
> client. You can possible use this as a signal strength indicator.
>
> Depending on the routing protocol this information might not be
> available further down the routing path. In BATMAN I believe only direct
> neighbors know this information.
>
> But on the other hand, you often want to collect this information
> globally to be able to improve network performance. But we could be
> collecting this information in a way that clients are anonymized, while
> we still get link/topology data.
>
>> To increase user privacy I would like to experiment with a MAC address
>> spoofing service that could run on mesh nodes or volunteer hosts.
>
> You can maybe try to repurpose ARP proxy support in Linux:
>
> https://en.wikipedia.org/wiki/Proxy_ARP
>
>> But it is not that simple of course, because spoofed MAC addresses
>> need to persist just as legitimate MAC addresses do, and move about
>> in the physical world (connect to different mesh nodes) just as other
>> legitimate users will.
>
> And of course produce unique traffic as well.
>
>
> Mitar
>
_______________________________________________
mesh mailing list
mesh@lists.sudoroom.org
http://lists.sudoroom.org/listinfo/mesh