Deisgn of a war time civilian network
If you are watching news, you might see that especially recently, Taiwan and China isn't having a great relation. And unfortunately I live in Taiwan. I'm not going into the politics of it, but I'm going to talk about my plains of keeping my surroundings to have access to important information. Thus more likely to survive in case a war breaks out.
First, I'm assuming under war, the opponent won't be following the Geneva convention. It's war crime but it's in the opponent's best interests. Cutting infrastructure access is devastating to civilians. There's nothing I can do for water and gas. But I can do something for internet (not fully, we'll see) and power.
Power is relatively easy to solve. Just use solar or wind. There are cheap solar panels and wind turbines on the market. And cheap inverters, batteries, UPS. Put it somewhere and you are good to go. I'm not going to talk about it here. Internet is a bit more complicated. See, most servers people use day to day either runs on very power hungry servers located in local data centers. Which will likely shutdown during war. Or they are hosted on data centers abroad. Which can be easily cut off by cutting the undersea cables. In the current Ukraine war, this is solved by SpaceX's Starlink. But considering Elon's relation with China (they need Chinese labor to build Tesla cars), I don't think he will be willing to help Taiwan.
Given the above scenario, I think the following properties are desirable for a war time network.
- Mesh network (no single point of failure)
- Long range wireless connections
- Low power consumption
- Low cost
- Easy to setup
- Encrypted communication
Thus I imagine a network created using the following components.
- Raspberry Pi routers (or other low power Linux devices)
- LoRa for long range link
- WiFi for short range link and easy access
- GNUnet for encryption, routing, peer discovery and services
I imaging the following setup. Each "router" node is a RaspberryPi or other low power Linux device. Low power because it is unrealistic to expect long range wireless mesh to push massive amount of data. Just the communication latency and quality would limit the speed. And thus running on high speed systems would be a waste of power. Each node is equipped with wireless communication capabilities. 2.4GHz WiFi enables mid range connection to other nodes. Or LoRA for long range (but slow) connections. The IP address of each node is not important, in fact link local address is enough.
Then, each node runs a copy of GNUnet. Unlike Tor and Freenet. GNUnet can route traffic from node to node without going through the internet. This is perfect for this use case. Node A can send a message to node B directly via WiFi. Vise versa. Further more, devices connected to node B can connect to services hosted on servers routed by node A.
The idea sounds ok till now. There's one minor issue. GNUnet is unlike Tor, it does not speak TCP/IP. That's why we can get away without internet nor a DHCP in the first place. But it also means hosting and accessing services without using GNUnet's API is hard. GNUnet provided a solution on their side. The VPN (Virtual Public Network). GNUnet VPN can be thought of as a tunnel that is opened via GNUnet each time someone wants to access a service when there's a name record for it on GNS (GNUnet Name System). It only works for browsers and is a bit cumbersome to setup.
The better solution (that needs engineering work) is that we build something like the
torsocks command. It uses some
LD_PRELOAD magic to overwrite the default socket and name resolution functions. So that when a program tries to connect to an CADET address, it gets routed via GNUnet. And when it tries to resolve a name, it gets resolved via GNS. This way, we can use any program that uses TCP or UDP to access GNUnet services. Better, we could run this on the router nodes. Thus when devices uses the node's DNS resolver, it gets automatically converted to GNS. Same can be done for CADET addresses using some IPv6 trickery.
But what to serve on such a network? Theretically anything. But at a time of crisis, I think the following are the most important.
- Source code for the network itself
- Instructions on how to setup the network
- Maps in JPG format
- IRC or other low bandwidth chat
- Software to navigate the network
Furthermore, Gemini may be favorable to the public at large. It's a very simple and lightweight protocol. It won't cause much pressure on the network and should easily work over even the slowest speed over LoRa.
The main challenge is to build the network up. It's going to be hard to get materials and devices during war. And setting up GNUnet is not a trivial task for the average user. Nodes with hardware and software ready to go must be prepared in advance. Furthermore, it's best if nodes can autoconfigure themselves and avoid forming islands.
Secondly, large meshes usually have high latency of up to seconds. Might be longer depending on the link quality. But most applications, especially web browsers give up after like 30 seconds. Smol net browsers act better, Amfora and Lagrange will tolerate longer delays. The simpler structure of smol net may help too. As no other resource besides the text page itself is loaded.
I'd hate this is the usecase I found for GNUnet. But I have to protect myself the way I can. Hopefully I won't have to use it.
Systems software, HPC, GPGPU and AI. I mostly write stupid C++ code. Sometimes does AI research. Chronic VRChat addict
- marty1885 \at protonmail.com
- GPG: 76D1 193D 93E9 6444
- Jami: a72b62ac04a958ca57739247aa1ed4fe0d11d2df