[Mesh] Changing the MAC address

[Jeremy Entwistle]

*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 at lists.sudoroom.org> wrote:

> Send mesh mailing list submissions to
>         mesh at 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 at lists.sudoroom.org
>
> You can reach the person managing the list at
>         mesh-owner at 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 at labitat.dk>
> To: rhodey <rhodey at anhonesteffort.org>
> Cc: "mesh at lists.sudoroom.org" <mesh at 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 at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> On Sun, Nov 10, 2013 at 5:00 PM, rhodey <rhodey at 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 at 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 at tnode.com>
> To: Marc Juul <juul at labitat.dk>, rhodey <rhodey at anhonesteffort.org>
> Cc: "mesh at lists.sudoroom.org" <mesh at lists.sudoroom.org>
> Subject: Re: [Mesh] Fwd: [Commotion-discuss] Seattle Police mesh
>         network for surveillance?
> Message-ID: <52808CBC.9070107 at 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 at labitat.dk>
> To: Mitar <mitar at tnode.com>
> Cc: "mesh at lists.sudoroom.org" <mesh at lists.sudoroom.org>
> Subject: Re: [Mesh] Fwd: [Commotion-discuss] Seattle Police mesh
>         network for     surveillance?
> Message-ID:
>         <CAL4ejvQVM=
> uY8J0qWX5CJKUn-ct9e1cXQLaT51JR3KLK9NZd4w at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> On Sun, Nov 10, 2013 at 11:52 PM, Mitar <mitar at 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 at tnode.com>
> To: Marc Juul <juul at labitat.dk>
> Cc: "mesh at lists.sudoroom.org" <mesh at lists.sudoroom.org>
> Subject: Re: [Mesh] Fwd: [Commotion-discuss] Seattle Police mesh
>         network for surveillance?
> Message-ID: <5280AFC2.1030703 at 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 at labitat.dk>
> To: Mitar <mitar at tnode.com>
> Cc: "mesh at lists.sudoroom.org" <mesh at lists.sudoroom.org>
> Subject: Re: [Mesh] Fwd: [Commotion-discuss] Seattle Police mesh
>         network for     surveillance?
> Message-ID:
>         <
> CAL4ejvQi13g6XfhCLOHFC16VumzeAMtddzpS_j8ghEg8AzOgyw at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> On Mon, Nov 11, 2013 at 2:21 AM, Mitar <mitar at 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 at lists.sudoroom.org
> http://lists.sudoroom.org/listinfo/mesh
>
>
> End of mesh Digest, Vol 10, Issue 23
> ************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://sudoroom.org/lists/private/mesh/attachments/20131111/275b80c3/attachment.html>