[Mesh] Changing your MAC address

[rhodey]

Although the below message was written in response to Yardena's concerns
about educated guesses I realize now that the system I proposed does not
itself resolve such concerns. Tricky stuff...

--
-- rhodey ˙ ͜ʟ˙

On 11/21/2013 01:52 PM, rhodey wrote:
> Last week Mitar pointed out that many of the tricks we're theorize are
> effectively turning our layer 2 mesh into something of a layer 3 mesh. I
> want to acknowledge this insight while expressing my interest in
> continuing these experiments because I think layer 2 has been out of
> sight out of mind for too long (at least for me). I hope that we can
> continue forward with our current deployment plan and once complete use
> it as a test platform for all these crazy hacks we're theorizing :)
> 
>> I'm also now skeptical that a malicious network couldn't work around
>> any of these tricks as long as you remain in their range. If one
>> device appears as soon as the other leaves, at the same location, they
>> can make a good guess that it's still you.
> 
> Following the general idea of mesh nodes maintaining a translation table
> for the purpose of masking real, static MAC addresses with fake MAC
> addresses-- why can't the "fake" MAC addresses be static. We could
> allocate each node in our network a generous chunk of the MAC address
> space which it could map to clients as they connect. Maintaining this
> translation table would add complexity but I believe that it could also
> remove some complexity from the routing protocol because of the static
> address space.
> 
> If we accept the above idea and trust nodes to manage a static block of
> the address space we also gain the option of adding trust into the
> network. There is currently nothing stopping a malicious node on a
> BATMAN-adv network from advertising that it has clients which it does
> not-- BUT if we accept that nodes control a static address space we
> defeat this attack. I believe this trust would have to be maintained
> between nodes and transparent to clients because of our lack of control
> over the client network stack, but I think this might be OK. A remaining
> problem is to implement this system of trust without ruining the
> decentralized nature of the mesh.
> 
> I get the impression that a lot of what we're theorizing has
> implications to roaming between networks but if we are able to establish
> trust between nodes I think we might not break everything. Either way, I
> need to educate myself on roaming.
> 
> --
> -- rhodey ˙ ͜ʟ˙
> 
> On 11/21/2013 01:11 PM, Yardena Cohen wrote:
>> On Wed, Nov 20, 2013 at 10:50 PM, Mitar <mitar at tnode.com> wrote:
>>> I would be more interested in what happens to the arp table. Does it grow?
>>
>> It appears to be staying up-to-date. At this very moment there are 5
>> obsolete dhcp leases hanging around, but none shows up in
>> /proc/net/arp
>>
>> After a week of this, I'm wondering if it's better to dissociate this
>> stuff entirely from the network logic. Maybe all interfaces should
>> just be randomized at boot time and/or every 24 hours, no matter what
>> the network is doing. Seems a lot less complicated.
>>
>> I'm also now skeptical that a malicious network couldn't work around
>> any of these tricks as long as you remain in their range. If one
>> device appears as soon as the other leaves, at the same location, they
>> can make a good guess that it's still you.
>> _______________________________________________
>> mesh mailing list
>> mesh at lists.sudoroom.org
>> http://lists.sudoroom.org/listinfo/mesh
>>
> _______________________________________________
> mesh mailing list
> mesh at lists.sudoroom.org
> http://lists.sudoroom.org/listinfo/mesh
>