Censorship is on the rise, and has been for a while. Censors are working hard every day to restrict access to crucial information that challenges their authoritarian regimes across the world. It’s important that we continue work to counter their efforts, and develop new and innovative ways to build out anti-censorship infrastructure which helps people evade unjust Internet restrictions.

Since late last year, we’ve been experimenting with various ideas and projects to aid in the advancement of anti-censorship and privacy-focused infrastructure. Experimentation is a big part of what we do, and it’s important to continue with that experimentation. To house all of these experiments, we created the concept of Unredacted Labs. While most of the work was conducted in secret, we’ve dropped hints about our work via our community chats and social media channels in the past.

It’s time that we show the public what is and has been happening inside the Unredacted Labs.

Unredacted Labs Experiments:

• NoiseNet – an experimental anycast network
• GreenWare – power efficient hardware that scales

---

NoiseNet (AS401401)

NoiseNet is an experimental anycast network designed by Unredacted that attempts to introduce noise (randomness) and an additional layer of encryption into parts of our network, making it more more difficult for censors to monitor and perform traffic correlation attacks against parts of our infrastructure. NoiseNet also helps us distribute load across our network and mitigate DDoS attacks.

NoiseNet operates on top of AS401401, and has edge routers distributed all over the world which can be seen below.

Understanding the NoiseNet flow

When a packet is destined to an anycasted NoiseNet prefix, it’ll generally reach the closest PoP to where the packet originated. Depending on the specific destination, the NoiseNet edge node will route the packet through an encrypted tunnel to the core router(s) where it should be delivered to. The router(s) will then pass it to the server it’s destined for where the encrypted tunnel terminates. This means that not even the core router(s) in our datacenters can inspect the true nature of inbound packets. Only the network before the edge node (the upstream), the edge node itself, and the server in which the packet is destined for can see what an inbound packet contains. This essentially reduces the amount of intermediary networks that can potentially snoop on our traffic, while also making it generally more difficult to do so at the same time.

Once the server processes an inbound packet, it can generate a response which is sent directly out via our upstream provider(s) in the datacenter where the server lives.

Breakdown of the flow of packets through NoiseNet

• Packet gets sent to a NoiseNet prefix.
  • A NoiseNet PoP receives the packet.
    • The router forwards the packet to the proper core router via an encrypted tunnel.
      • A core router forwards the tunnel flows to a server, where the tunnel terminates.
        • The server generates a response, and sends the packet back out to the core router.
          • The core router forwards the packet directly via it’s upstream(s) back to the source.

Visual examples of how packets can flow through NoiseNet

This design makes it harder for snoopers to snoop due to the following:

1. It results in the ingress and egress network paths being asymmetrical, and makes correlating ingress and egress flows more difficult for a censor or would-be snooper.
2. It encapsulates each packet destined to our core network PoPs, so that it reduces the amount of intermediary networks that can observe and track flows going through NoiseNet.

There’s also several ways that NoiseNet introduces additional noise and resiliency into our network.

• Anycasting our prefixes (advertising them from all of our PoPs) creates variance in network paths when packets are en route to our edge network. The more upstreams and Internet Exchange points (IXPs) we’re connected to, the more diversity there is in the ways different networks can reach ours. The more paths to our edge network, the harder it is for snoopers to conduct dragnet surveillance.
• No single point of failure. We have a large amount of edge nodes, and additional core network PoPs can be created at will, creating more network path diversity and general resiliency.
• Our distributed edge network allows us to more easily mitigate DDoS attacks, because the load is spread out across our entire network rather than a single point of ingress.

Diversity is our strength

The more upstreams we have, and Internet Exchanges Points (IXPs) we’re on, the better. Many of our upstreams are tier 2 or tier 3 networks, and they advertise our prefixes over their own interconnections with other networks. We’re continually working on expanding NoiseNet by deploying new edge nodes around the world and connecting directly to more Internet Exchanges.

How we utilize NoiseNet today

Currently, at the time of writing NoiseNet ingests and routes packet for all of our Tor exit relays. As we assess the stability and feasibility of NoiseNet, we’ll begin to host more of our services behind it. Until then, we may periodically disable NoiseNet by unicasting our IP prefixes for research & testing purposes.

The future of NoiseNet

While the foundations of NoiseNet are in place, we have a lot of work to do.

Below is a list of things we’re planning to develop over time.

• Partner with more companies & organizations that can downstream us. A special thank you to Triplebit, a nonprofit who has partnered with us and become one of our upstream networks.
• Consideration to exchange routes over our edge & core allowing for the egress of packets from our core back over tunnels to edge nodes to keep traffic more “local” if packets can be routed over an IXP or kept more local in some way.
• The development of noisenet-randomizer, a program that utilizes Traffic Control (TC) and/or eBPF to introduce random delays in packet processing/routing on our edge or core network.

There are some glaring issues that we need to resolve before NoiseNet is considered stable as well.

• Some of our upstreams appear to track L4 connections, and drop packets for flows which they have not observed us initiating (an anti-spoofing DDoS protection mechanism). This causes an issue with our current design, and can cause packet loss or blackholed inbound traffic in certain PoPs. We are working on a way to detect this and disable prefix advertisement via upstreams we detect this behavior on.
• Network health is not currently determined, nor it is a factor in prefix advertisement status. We need to develop automations that observe automatic speed tests and packet loss metrics from edge <-> core and edge <-> Internet. These automations will be able to decide when to disable prefix advertisement, use path prepending or BGP communities to shift traffic away from edge nodes to improve network performance and reliability.

Interested in helping us, and have an interest in what we’re doing? Reach out! We’re always looking for students or professional volunteers to help us with our ambitious projects.

GreenWare

GreenWare started as a general proof-of-concept to operate Tor relays on top of power efficient hardware that is easy to scale. It’s also an initiative which helps us reduce our overall carbon footprint, and sets us on the right path to powering some of our services entirely by renewable energy in the future.

In addition to reducing our carbon footprint, we attempt to offset the footprint of our services using Stripe Climate by automatically allocating 1% of donation revenue that we receive to it. As of writing, we’ve helped to remove 184 kg of CO₂ in the air from planet Earth, which is roughly equivalent to the carbon output from driving 417 mi in a car. This simply isn’t enough, and we need to work to reduce that potential footprint as well.

Last year, in our “year in review (2024)” blog post we showcased some of our experimentation with this idea using PoE powered Raspberry Pi 5s. Over several months, we validated that this would actually work – and it worked well.

It progressed into something that we’re quite confident can be deployed on a large scale, and could be powered 100% by renewable energy in the future with the proper battery storage.

There were some quirks to be had with the Raspberry Pi 5s, though. We found the PoE HATs to be generally buggy and unreliable. The boards being exposed were easy to bump into and cause a Pi to reboot. The density also wasn’t dense enough for what we truly had in mind.

For quite a long time, we’d been tracking the development of the ComputeBlade – modular CM4/5 blades servers with the potential for very high density. They’re so dense that you can fit 20 blades in a single 1U chassis. We recently got our hands on a kit and began tinkering with them right away.

Deployment time

We ended up deploying all 20 blades in our datacenter and have migrated the majority of our Tor exit relays to them. They’re currently running great, and while having several design flaws with the chassis – we’re confident that power efficient efficient hardware like this can help reduce the carbon footprint of the Tor network and more of our services in the future.

All together, they only use a little over 100W of power.

The future of GreenWare

As time goes on, we’ll be exploring new ways to experiment with power efficient hardware. We’re even thinking about ways that we can operate micro-PoPs in cheaper, less important locations where we can harvest the energy of the sun and use it to power our hardware.

We’re also exploring all-in-one carbon tracking solutions such as the “Compute Energy & Emissions Monitoring Stack” (CEEMS) to track our carbon footprint, and find ways to lower it or offset it across the board.

Have questions or want to deploy your own power efficient hardware like we did? Join any one of our community chats!

Parting thoughts

Now more than ever, it’s time to fight against Internet censorship and dragnet surveillance! Our hope is that the experiments we create inspire others to build more tech in the anti-censorship & privacy space. We can’t do it alone, nor could be do it without our generous donors. In the years to come, we’ll continue building and updating innovative experiments to help create the most impact.

If you like what we do, and want to help us fund our mission – consider making a donation.

If you’re an organization or company, and want to collaborate – contact us.