Reticulum & Internet Shutdowns

[4c3e]

Currently I believe Reticulum already is extremely useful as a resilient long-term network of devices and IOT-type applications. I can't help but think that Reticulum might also have a possible role as a network layer in the event of an internet shutdown (either by natural disaster or even state-level actor). I wanted to put up this topic for discussion.

For protection against an adversary, or simply for users that want more metadata protection, they could build traffic analysis prevention (TAP) tools, like mix-nets with onion-routed packets, or a tunneling system that forwards packets through two or more RNS Link's.

For better performance in more ad-hoc situations like an internet shutdown, Reticulum peers could be extended to provide more functionality by also storing and forwarding packets, possibly in a way that could take advantage of their mobility. Of course Ad-hoc mesh routing is a very complicated problem on its own.
Another interesting feature that could aid in this area is adding qaul.net as a transport. (In short, qaul.net is a platform that tries to create wifi mesh's out of consumer devices' wifi hotspots and access points).

These are just some thoughts of mine, I hope I can work towards some of these ideas eventually, but I already have quite the queue of work on my plate :) Would love to hear others thoughts, and if there are other projects in this space. It seems like disaster.radio developement is paused right now, and meshtastic seems to be primarily for outdoor enthusiasts.

[markqvist]

These are good and interesting thoughts. They also completely align with some of the original motivations for developing Reticulum, so you can safely assume that the ability to use Reticulum as a resilient data transport, in the event of loss of internet access, is something that has been taken into account in the design of the stack.

Some of the problems that onion routing and other methods are designed to tackle does not exist in Reticulum. As such, I think it is very important to carefully analyse the possible attack vectors, and focus specifically on remediating those that are most important to user privacy and anonymity. Luckily, Reticulum already provides a very important component of preventing analysis of traffic patterns and metadata analysis: All senders are anonymous by default.

Sending a packet or establishing a link in Reticulum does not reveal your source address by default. In fact Reticulum does not even have any concept about "source addresses". Even if an app identifies itself (for authentication purposes for example) to the endpoint of a link, no one else in the network will be able to see or deduce the revealed identity.

There are several ways forward to improve the situation even more, that I planned when designing the protocol, but they have not been implemented yet due to prioritisation of other factors (and frankly it is better to wait with those until we are feature-complete for the core protocol and wire-format stable, I think). One is hop count obfuscation.

This simple method can be implemented quite easily and would make it impossible to analyse where packets are really coming from, whether they are originating at the system that they were received from, or somewhere entirely else. This coupled with the already existing initiator anonymity already provides very good protection against mining metadata for patterns and information.

Another is something I call "dynamic packet structure scrambling" (I don't know if this is already an established concept with a different name), that serves to defeat deep-packet-inspection firewalls and traffic analysis by semi-randomly reordering (scrambling) packet structure, making it impossible for DPI firewall software to inspect, or even identify, Reticulum traffic.

I think those two approaches would be the most effective right now at further enhancing privacy and resistance to traffic analysis. I'd love to hear any other ideas you have, or expansions on the ideas you already mentioned. Thaks for raising this interesting topic.

Also, you would not believe how much time I have spent thinking about, conceptualising and simulating versions of Reticulum where peers transport information on an ad-hoc basis. I can tell you it is one hard problem to solve, especially when you want it to work over ultra-low bandwidth. In the current scheme of things, I don't think there is a way to do this without necessarily throwing a lot of extra (very valuable) bandwidth at the problem, which is something I really want to avoid. Reticulum is extremely bandwidth-efficient, and it needs to be kept that way. That being said, it is still an extremely useful function, and in practical terms, I think it has another solution, where the tradeoff can be memory instead of bandwidth (which goes fine within Reticulums mode of operation: The doctrine is to use memory to save bandwidth whenever possible. Memory is cheap, bandwidth is expensive).

In general, you can say that what you want to allow via ad-hoc information routing through non-designated routers, ie. peers, is what can be termed delay- and disruption tolerant communication. By limiting the scope to this, we can work within a framework that lets peers transport a lot of data efficiently, without wasting any bandwidth. That is why I ultimately decided to put this kind of functionality into LXMF, and not the core of Reticulum (even though I might one day merge them, LXMF will probably become an integral part of the stack).

While it is not yet implemented, I designed LXMF to allow for this kind of ad-hoc transport by peers. It is important to remember here that LXMF is not only a system for carrying "email" or "chat" messages, but that it can be used for almost anything. It is a general purpose extensible data transport format. One likely scenario is that peers will be allowed to simply sync as much of the full LXMF message store from any other peers they encounter over fast links (such as WiFi), carry this on with them while moving around in the physical world, and allowing any other peers they encounter to sync from their own message stores as well.

This was already thought into the design of LXMF, and I will probably begin experimenting with this once current priorities of deploying mobile/tablet apps have been fulfilled.

[4c3e]

@markqvist thank you so much for taking the time to write such a detailed response, please know it is much appreciated.

On the topic of metadata protection you bring up some excellent points, hop obfuscation, packet splitting, and the existing Link API are great tools for creating a resilient, private, network layer. A few more points I'd like to add while were on the topic:

• Multi-link connections, in order to obfuscate both the initiator and destination of a Link. (i.e. A -link-> B -link-> C instead of A -link-> C)
• Link multiplexing (multiple virtual channels over one established link) would also help multi-link connections.
• Artificial packet delay to prevent timing attacks.
• Appending random packet padding to further mitigate DPI effectiveness.

On the topic of ad-hoc peer networking, I fully agree with the "use memory to save bandwidth" doctrine, trying to increase peer2peer routing by adding more "announcement"-type packets seems impossible to scale properly, especially over transports like LoRa.

One likely scenario is that peers will be allowed to simply sync as much of the full LXMF message store from any other peers they encounter over fast links (such as WiFi), carry this on with them while moving around in the physical world, and allowing any other peers they encounter to sync from their own message stores as well.

This sounds like this project I recently learned about called librerouter which was created for a PhD thesis that you can read here: https://www.netlab.tkk.fi/~jo/papers/2014-04-wons-liberouter.pdf
I'm fairly certain LXMF's functionality would only need some minor extensions in order to function like librerouter, and it seems like it would be extremely useful functionality in offline scenarios, while using effectively no "global bandwidth".