11 Nov
2013
11 Nov
'13
12:07 p.m.
*He wants to follow her around the city or simply learn where she lives.
Using the node map, which includes node IP addresses (or because he simply
drove around the city and mapped them out himself) he knows the IP/MAC to
physical location mapping of all nodes.*
I think this is a concern. I don't think anybody wants to go from the
government having this ability to anybody having this ability. I'm not sure
the best idea of implementing this, but what it sounds like it comes down
to is the identifier. We need something on the mesh which will allow 1)
nodes communicate to nodes on the mesh and 2) nodes communicate to nodes
through the internet (via a tunnelling program). Currently batman does this
with MAC addresses, however, as we mentioned in a previous meeting, you can
have duplicate MAC addresses because of the manufacturer (most likely
problem) or randomly generated. I think it's possible to do the following:
Client <-- MAC addresses --> Node
Node <-- unique keys --> Node
Exit Node < -- IP addresses --> Internet (or Tor Network)
In the same way that the exit node serves as a barrier for the mesh to the
internet, I think a node can do the same for MAC addresses of phones and
it's locally connected devices. This should eliminate the need for
disabling the traceroute function, which from what understand needs to be
there in order for batman to determine a reliable and quick connection
between nodes. The only complication I can think of being able to create
your own unique key is to verify on the network that it's unique. It
probably can be figured out with working with the DAT files.
http://www.open-mesh.org/projects/batman-adv/wiki/DistributedArpTable
*I see the localization possibilities as a feature which can empower local
communities, where users can get services and content based on where in the
mesh network they are. I see mesh networks as connections between people.*
Agreed! I don't think by being the protocol to be anonymous makes it so
that you have to remain anonymous. It just allows you to be anonymous by
default. In my mind, I think it would be amazing to implement into the
protocol something comparable to the networks on social media sites. Such
that, I have a unique key as my address on the mesh, I run a server from my
node and I want people to have access to it. However, maybe I have very
good reason to want to change my key every couple of days, but I want to a
specific group of nodes to know my address change. Then I think it would be
important to allow that node update this group of nodes with your key
change, once verified with the network as being unique. Or as mentioned,
only sharing your key to a group of nodes (or a certain number of hops)
then the packets being carried out by another identifier beyond that point.
All that being said... I'm still learning and this may not work at all.
Feedback please! :)
On Mon, Nov 11, 2013 at 2:36 AM, <mesh-request(a)lists.sudoroom.org> wrote:
Send mesh mailing list submissions to
mesh(a)lists.sudoroom.org
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.sudoroom.org/listinfo/mesh
or, via email, send a message with subject or body 'help' to
mesh-request(a)lists.sudoroom.org
You can reach the person managing the list at
mesh-owner(a)lists.sudoroom.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of mesh digest..."
Today's Topics:
1. Re: Fwd: [Commotion-discuss] Seattle Police mesh network for
surveillance? (Marc Juul)
2. Re: Fwd: [Commotion-discuss] Seattle Police mesh network for
surveillance? (Mitar)
3. Re: Fwd: [Commotion-discuss] Seattle Police mesh network for
surveillance? (Marc Juul)
4. Re: Fwd: [Commotion-discuss] Seattle Police mesh network for
surveillance? (Mitar)
5. Re: Fwd: [Commotion-discuss] Seattle Police mesh network for
surveillance? (Marc Juul)
----------------------------------------------------------------------
Message: 1
Date: Sun, 10 Nov 2013 21:22:32 -0800
From: Marc Juul <juul(a)labitat.dk>
To: rhodey <rhodey(a)anhonesteffort.org>
Cc: "mesh(a)lists.sudoroom.org" <mesh(a)lists.sudoroom.org>
Subject: Re: [Mesh] Fwd: [Commotion-discuss] Seattle Police mesh
network for surveillance?
Message-ID:
<CAL4ejvRY+Specdgjh_w1hOfHY==BP8t5+3n4=
HwH_gBCWf+OPw(a)mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
On Sun, Nov 10, 2013 at 5:00 PM, rhodey <rhodey(a)anhonesteffort.org> wrote:
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
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.
--
-- 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.
_______________________________________________
mesh mailing list
mesh(a)lists.sudoroom.org
http://lists.sudoroom.org/listinfo/mesh
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