[OpenWireless Tech] My thoughts on deploying a secure mesh network.

Wed Jul 29 05:32:19 PDT 2015

Hi Dan,

My suggestion actually derives from a number of pre-existing protocols 
including CJDNS. I found neither of them satisfying and the features I 
wanted where not easy to just add to an existing protocol -> therefore I 
came up with making a new one. The protocol I started out with where I2P 
and it's not alone in adding features that can't just be added to CJDNS.

I hope I didn't write this to aggressively, I've been told that I have a 
tendency to do that. I am open for the idea that I'm wrong about these 
issues but I have tried finding other solutions to them. If the 
requirement to design a new protocol could be dropped that would spend 
some time. Although even if it's a new protocol I suspect that a lot of 
the work on CJDNS, I2P and others can be reused.

I2P and CIP as defined can be implemented entirely as a 
platform-independent application. This while CJDNS needs to get data 
from the IP stack which is the reason that there are limits to the 
number of platforms it currently support. If course my IP over CIP 
feature would have the same limit, but that's an optional feature and 
you would still be able to run CIP and CIP-based applications without it.

Another issue with basing a protocol on IPv6 and that is that there are 
no clear distinction between CJDNS and IP, where a CIP application would 
know for certain that it's using CIP and not IP. An IP application 
running tunneled over CIP would have similar problems, but the solution 
to that is to replace all IP code with CIP code in the application.

I2P has this handshaking protocol where it discovers neighboring nodes 
and check the version of the protocol. That makes it easy to do 
fundamental changes in the protocol without having the problems we are 
having while migrating from IPv4 to IPv6. That's also a feature that I 
want to carry over in CIP but that would be hard to do in a protocol 
specified to use IPv6 packages.

Finally it's the problem of having to manually find and configure 
friends. I want to peer with my neigbors wireless networks as that's 
probably how the mesh network becomes most efficient. However like most 
people in western civilization I don't want to actually talk with my 
neighbors. To tell the truth personally I can do that because I want 
this to happen. But the problem with "most people in western 
civilization" still stands.

A mesh network that requires participants to communicate IRL and also 
requires manual router configuration - I don't see that spreading 
outside of enthusiast circles and replace internet.

On the other hand the idea of a network design that forces communities 
to cooperate IRL in order to perform some manual administration during 
deployment and maintenance is tempting. But it's also a vulnerability 
when outside forces can control the network by controlling those that 
administrates it.

Currently I install I2P on computers I maintain in order to remote 
administrate them while their are spread out to different locations that 
cannot easily be reached using IPv4. Manually configuring friends in 
that network would be a lot more painful than the current setup.

//Mattias Eliasson

Den 2015-07-29 kl. 12:08, skrev Dan Ryan:
> Hey Mattias,
>
> You've just described CJDNS <https://github.com/cjdelisle/cjdns>, the 
> only thing it is missing is CJDNS over USB, but I feel that that is 
> something that should be done at a higher level than a routing daemon. 
> That being said, if you wanna modify CJDNS to bundle packets to go on 
> flash drives, go for it!
>
> Automatic local peering over raw ethernet frames is the main method of 
> peering, although you can peer over any IPv4 or IPv6 network 
> (including OnionCat over Tor/i2p for VPNception!), allowing CJDNS 
> users to leverage any existing IP based network. CJDNS also uses self 
> generated keypairs to assign you a unique IPv6 address, then using the 
> Salsa20 stream cypher it encrypts all traffic twice (end to end & hop 
> to hop).
>
> CJDNS also supports transporting any IPv4 or IPv6 network over itself, 
> so public exits or commercial providers could offer or sell you an 
> IPv4 and/or IPv6 address and legacy internet access, or you could just 
> use it to access a remote LAN too, depending on your use case.
>
> If anyone needs CJDNS peering over the IPv4 or IPv6 internet, or if 
> you are in Seattle and would like to link up, feel free to email me or 
> head over to SeattleMesh.net <https://seattlemesh.net/>.
>
> - Dan Ryan
>
> On 07/29/2015 01:42 AM, Mattias Eliasson wrote:
>>
>> Hi
>>
>>
>> For quite some time I've been thinking about how to release Internet 
>> from various problems and now that I found the OpenWireless project 
>> I'll share some of my ideas to see what response I get. I've spent a 
>> lot of time thinking about usability and cost of deployment rather 
>> than just focusing on technical issues. I think that the usability 
>> perspective is very important. The easier it is for users to open up 
>> their networks, the more users will join.
>>
>>
>> While analysing the technical and security aspect of this idea please 
>> also consider the usability aspect. This idea is very plug and play 
>> and allows for the creation of a router and installable software that 
>> will connect users without additional configuration. Its usage as a 
>> flexible VPN technology alone makes it a free alternative to Cisco:s 
>> Dynamic Multipoint VPN. Of course the latter will require some 
>> configuration but not more than any VPN service. For the network 
>> administrator it will probably be far easier to set up this as a VPN 
>> than any traditional technology.
>>
>>
>> My suggestion is to make a new network-level protocol that allows for 
>> automatic configuration of mesh networking. Let's call it the CIP, 
>> Cryptographic Internet Protocol. It's inspired by Serval Project’s 
>> MDP, Mesh Datagram Protocol.
>>
>>
>> Like MDP and other cryptographic protocols like TOR and I2P it relies 
>> on self generated public keys for addressing, and encryption to 
>> secure its contents and provide some degree of anonymity. From MDP we 
>> can derive automatic routing. This makes it fully distributed and 
>> "plug and play". Fast autonomous mesh networking was the main design 
>> goal, not anonymity. Whatever anonymity it provides that’s just a bonus.
>>
>>
>> My main problem with MDP is that it’s included in the larger 
>> “BatPhone” bundle which is an Android application which makes it hard 
>> to implement in routers and other network-level hardware which is 
>> required in order to make it a fast and very available protocol. As 
>> you can guess from my CIP name choice I think that a network level 
>> protocol that exists in parallel with the IP protocol(s) is the best 
>> way to go. Unlike other cryptographic protocol I suggest keeping it 
>> lightweight, easy to implement at a router/kernel level. Having an 
>> OpenWRT implementation is a necessity in order to perform mass 
>> deployment.
>>
>>
>> In order to utilise existing infrastructures it should be able to 
>> send data on top of IP. For non obscured fast connection there could 
>> be a dictionary where IP endpoints close to the target CIP address 
>> can be looked up. For higher anonymity onion or garlic routing can be 
>> used. This would make CIP both a mesh networking protocol and a high 
>> level protocol like TOR and I2P. The success of CIP would very much 
>> depend on this interoperability.
>>
>>
>> A complex scenario would be people setting up CIP over IP in LAN:s 
>> that are filtered enough to not support passing such traffic onto the 
>> Internet. In such a case they would be able to leverage existing IP 
>> infrastructure locally but they would need to connect their networks 
>> to the a mesh network to communicate across networks. It becomes even 
>> more complex if there are internet connections somewhere in the mesh 
>> network that can become a shortcut. That’s scenarios that neither MDP 
>> nor TOR/I2P is fully tested in, as neither does both mesh networking 
>> and internet tunneling.
>>
>>
>> Now that I introduced CIP over IP the next part is IP over CIP. It 
>> can be a powerful way to secure IP traffic, even locally on LAN:s. 
>> Here an IP2CIP directory service would be a simple and secure way to 
>> let the IP stack know where to send packages, similar to ARP on 
>> ethernet networks. Using multiple such directories would be similar 
>> to connecting to multiple VPN:s but more like Cisco’s DMVPN. This 
>> should be implemented in the hosts IP stack for end to end security. 
>> Ideally when communicating over an IP network I would want to lock 
>> down my unprotected IP traffic to just allow CIP over IP and then use 
>> IP over CIP in order to use IP-based software.
>>
>>
>> When accessing the unprotected internet there could be something 
>> similar to TOR out proxies or commercial VPN services that provides 
>> an anonymized bridge. However I probably eventually would prefer to 
>> stop using non-encrypted communication. A middle road would be to 
>> have exit nodes but only allow encrypted protocols like TLS and SSH 
>> to pass, but that may be a problem because many TLS implementations 
>> defaults to broken ciphers and SSH can easily be configured in an 
>> insecure way.. Perhaps the best thing would be the ability to mark a 
>> package as encryption-only and therefore allow the sender's IP stack 
>> and local configuration (firewall) to decide.
>>
>>
>> My next idea is to bridge gaps in mesh networking/internet by using 
>> DTN-based/like technology by the means of DTN mules in order to 
>> extend internet far beyond the reach of network equipment. Flash 
>> drives carried by mules are so much cheaper than building satellite 
>> networks, and field tests have shown it to work real well. But that’s 
>> a higher level project so I’ll save that for later. :)
>>
>>
>> //Mattias Eliasson
>>
>>
>>
>> _______________________________________________
>> Tech mailing list
>> Tech at openwireless.org
>> https://srv1.openwireless.org/mailman/listinfo/tech
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.eff.org/pipermail/tech/attachments/20150729/361e3831/attachment.html>