TCP sessions get reset when you get a new lease on a different IP. Hopefully short lease times comes with giving you the same IP if you stay connected and keep re-acquiring leases. But I've encountered equipment that doesn't. -a On 20 November 2013 13:47, Steve Berl <steveberl(a)gmail.com> wrote: _______________________________________________ mesh mailing list mesh(a)lists.sudoroom.org http://lists.sudoroom.org/listinfo/mesh

I would be more interested in what happens to the arp table. Does it grow?

Hi! Mesh networks and open source routing protocols we are using in general have a lousy security properties because at least until know development was mostly concentrated on getting routing itself to work properly (no loops and so on) in a all the time changing wireless networks with packet losses, where anybody can join in and add their own routing device. In comparison, Internet itself has very similar bad security properties, but there not everybody can deploy a BGP router. In mesh networks, people can deploy an equivalent to the BGP router. Which is what we want. Cjdns is trying to address some of this issues: https://en.wikipedia.org/wiki/Cjdns But from what I understand it is more of a Internet overlay network, so using VPN tunnels, and not really for wireless mesh networks. It can work in wireless mesh as it is transport agnostic, but I am a bit skeptical about performances there. Which is probably reasonable, because it is a trade-off between security and usability. Still, the security and privacy of end-users (those connecting through APs) is another question. There were some other proposals made in time, but at general you have always the same issue: if you allow untrusted (in security sense of trusted) devices to route in your network, you have a hard problem. A problem which is scope of much scholarly research and publications. Mitar

My last email was poorly timed with the reception of your previous email, no relation sorry, always enjoying your insight :) -- -- rhodey ˙ ͜ʟ˙ On 11/21/2013 02:01 PM, Mitar wrote: _______________________________________________ mesh mailing list mesh(a)lists.sudoroom.org http://lists.sudoroom.org/listinfo/mesh

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 :) 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(a)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. > > _______________________________________________ > mesh mailing list > mesh(a)lists.sudoroom.org > http://lists.sudoroom.org/listinfo/mesh > _______________________________________________ mesh mailing list mesh(a)lists.sudoroom.org http://lists.sudoroom.org/listinfo/mesh

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.