Send mesh mailing list submissions to
mesh@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@lists.sudoroom.org
You can reach the person managing the list at
mesh-owner@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@labitat.dk>
To: rhodey <rhodey@anhonesteffort.org>
Cc: "mesh@lists.sudoroom.org" <mesh@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@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sudoroom.org/pipermail/mesh/attachments/20131110/3d58672e/attachment-0001.html>
------------------------------
Message: 2
Date: Sun, 10 Nov 2013 23:52:28 -0800
From: Mitar <mitar@tnode.com>
To: Marc Juul <juul@labitat.dk>, rhodey <rhodey@anhonesteffort.org>
Cc: "mesh@lists.sudoroom.org" <mesh@lists.sudoroom.org>
Subject: Re: [Mesh] Fwd: [Commotion-discuss] Seattle Police mesh
network for surveillance?
Message-ID: <52808CBC.9070107@tnode.com>
Content-Type: text/plain; charset=us-ascii
Hi!
> 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,
I am not sure exactly what you are saying you would change? Batman
already knows only next hop for every destination. So what you would change?
Anyway, I think this is still complicating too much. Practically, any
attack would simply be listing all MAC addresses in the network. Once
you know this list you know that they are in the network. And then you
use other means to determine where a person is. You have to remember
that nobody is using only one approach or one tool. They will combine
data from multiple sources. Any change here will just make network less
open (in the sense that you would have a difference between admins and
non-admins), for what gain?
Can please somebody first describe a threat model we are trying to
address here? Who attacking whom and with which tools?
Mitar
--
http://mitar.tnode.com/
https://twitter.com/mitar_m
------------------------------
Message: 3
Date: Mon, 11 Nov 2013 02:12:42 -0800
From: Marc Juul <juul@labitat.dk>
To: Mitar <mitar@tnode.com>
Cc: "mesh@lists.sudoroom.org" <mesh@lists.sudoroom.org>
Subject: Re: [Mesh] Fwd: [Commotion-discuss] Seattle Police mesh
network for surveillance?
Message-ID:
<CAL4ejvQVM=uY8J0qWX5CJKUn-ct9e1cXQLaT51JR3KLK9NZd4w@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
On Sun, Nov 10, 2013 at 11:52 PM, Mitar <mitar@tnode.com> wrote:
> Hi!
>
> > 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,
>
> I am not sure exactly what you are saying you would change? Batman
> already knows only next hop for every destination. So what you would
> change?
>
> Anyway, I think this is still complicating too much. Practically, any
> attack would simply be listing all MAC addresses in the network. Once
> you know this list you know that they are in the network. And then you
> use other means to determine where a person is. You have to remember
> that nobody is using only one approach or one tool. They will combine
> data from multiple sources. Any change here will just make network less
> open (in the sense that you would have a difference between admins and
> non-admins), for what gain?
>
> Can please somebody first describe a threat model we are trying to
> address here? Who attacking whom and with which tools?
>
Bob is stalking Eve, and he has figured out her MAC address. 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. A simple layer 2 or 3 traceroute will now
tell him Eve's movements around town including her work location and home
location. I am proposing that we disable the layer 2 traceroute
functionality in batman-adv and block ICMP Time Exceeded messages such that
traceroute is no longer possible, and such that it becomes much more
difficult to find the physical location of a MAC address.
I think this scenario is our biggest concern with regards to tracking. The
government already tracks people using other methods, but we're setting up
a system that allows anyone to track anyone which brings with it a whole
slew of new problems.
Encouraging people to install apps that change their MAC addresses will not
solve the problem, since most people still won't install and use those apps
(and some devices don't allow that level of control).
--
Marc/Juul
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sudoroom.org/pipermail/mesh/attachments/20131111/ce099dc2/attachment-0001.html>
------------------------------
Message: 4
Date: Mon, 11 Nov 2013 02:21:54 -0800
From: Mitar <mitar@tnode.com>
To: Marc Juul <juul@labitat.dk>
Cc: "mesh@lists.sudoroom.org" <mesh@lists.sudoroom.org>
Subject: Re: [Mesh] Fwd: [Commotion-discuss] Seattle Police mesh
network for surveillance?
Message-ID: <5280AFC2.1030703@tnode.com>
Content-Type: text/plain; charset=us-ascii
Hi!
> Bob is stalking Eve, and he has figured out her MAC address. 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. A simple layer 2 or 3 traceroute will now
> tell him Eve's movements around town including her work location and home
> location. I am proposing that we disable the layer 2 traceroute
> functionality in batman-adv and block ICMP Time Exceeded messages such that
> traceroute is no longer possible, and such that it becomes much more
> difficult to find the physical location of a MAC address.
OK, and you believe this scenario warrants crimping the network?
I do not have a direct analogy here, but we used for some time a captive
portal which blocked all traffic until you clicked a button in the
browser. We got quite some reports of network not working from geeks who
first thing after they connected to network tried something non-HTTP and
then tried to ping and debug and nothing worked. Never tried to open
HTTP. Those were people not otherwise involved with the network. They
just assumed things should work. So what I am saying that I think should
always work as expected. Don't break things.
BTW, I am not sure if normal traceroute does anything smart in Batman
network. So how much people will really know how to use Batman specific
tool?
Mitar
--
http://mitar.tnode.com/
https://twitter.com/mitar_m
------------------------------
Message: 5
Date: Mon, 11 Nov 2013 02:36:41 -0800
From: Marc Juul <juul@labitat.dk>
To: Mitar <mitar@tnode.com>
Cc: "mesh@lists.sudoroom.org" <mesh@lists.sudoroom.org>
Subject: Re: [Mesh] Fwd: [Commotion-discuss] Seattle Police mesh
network for surveillance?
Message-ID:
<CAL4ejvQi13g6XfhCLOHFC16VumzeAMtddzpS_j8ghEg8AzOgyw@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
On Mon, Nov 11, 2013 at 2:21 AM, Mitar <mitar@tnode.com> wrote:
> Hi!
>
> > Bob is stalking Eve, and he has figured out her MAC address. 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. A simple layer 2 or 3 traceroute will now
> > tell him Eve's movements around town including her work location and home
> > location. I am proposing that we disable the layer 2 traceroute
> > functionality in batman-adv and block ICMP Time Exceeded messages such
> that
> > traceroute is no longer possible, and such that it becomes much more
> > difficult to find the physical location of a MAC address.
>
> OK, and you believe this scenario warrants crimping the network?
>
Yes! Emphatically yes! This is an issue of people's safety. People will not
reasonably expect that they are broadcasting their position to anyone who
cares to listen when they use the mesh. Many people have enemies and
stalkers. If we don't do anything about this issue then we are endangering
people's personal safety. We can't just say "oh, people can't expect to
keep their location private anymore".
> I do not have a direct analogy here, but we used for some time a captive
> portal which blocked all traffic until you clicked a button in the
> browser. We got quite some reports of network not working from geeks who
> first thing after they connected to network tried something non-HTTP and
> then tried to ping and debug and nothing worked. Never tried to open
> HTTP. Those were people not otherwise involved with the network. They
> just assumed things should work. So what I am saying that I think should
> always work as expected. Don't break things.
>
Sacrificing usability and/or personal safety for the many so a few techies
won't have to deal with workarounds is completely unreasonable. The
long-term solution to captive portals is a standard, implemented by all
major operating systems, that allows communication with users that connect
to your network without ugly hacks. I'm not sure what long-term solution
for not leaking geo-location information is, but there probably is a
non-ugly solution. We should work to create those solutions, but in the
mean-time, it's more important that the network works for the majority of
people than that it's technically beautiful.
> BTW, I am not sure if normal traceroute does anything smart in Batman
> network. So how much people will really know how to use Batman specific
> tool?
>
True. You'd need to use a batman-specific tool, but that's security by
obscurity territory and it only takes one person to make a "find anyone's
location" web app for that to break.
--
Marc/Juul
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sudoroom.org/pipermail/mesh/attachments/20131111/c674b0c7/attachment.html>
------------------------------
_______________________________________________
mesh mailing list
mesh@lists.sudoroom.org
http://lists.sudoroom.org/listinfo/mesh
End of mesh Digest, Vol 10, Issue 23
************************************