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
[email protected]
https://srv1.openwireless.org/mailman/listinfo/tech
_______________________________________________
Tech mailing list
[email protected]
https://srv1.openwireless.org/mailman/listinfo/tech
