Increase the amount of allowed relays per IP address to 8
Tor currently restricts relay operators to a maximum of two Tor relays per IPv4 address. With this issue we propose to change this limitation, with the aim of enabling Tor operators to run more Tor relays per IPv4 address.
Reasoning for restriction
The original intent of restricting the amount of Tor relays per IP address is to increase the cost for a Sybil attack. Despite the restriction, Sybil attacks have been detected in the past.
The "two relays per IP" restriction is likely to impede poorly organized adversaries' efforts. But on the other hand it's hard to imagine that more organized adversaries would be held back by this limitation.
Reasoning for changing the restriction
The server market has been focused on increasing the amount of threads (instead of high clockspeeds) for more than a decade now. And with great success: AMD64 CPU's with 128 threads are commonplace now and it won't be long before CPU's with 256 threads will make their debut.
While this is great in general, it also adds significant complexity for Tor operators since Tor does not scale well on multi-core CPU's. In order to effectively use a modern server with a large amount of threads, you would need to run many Tor relays. This has many downsides, such as complex system management and additional OS/system overhead. But the biggest challenge by far is overcoming the restriction of two Tor relays per IPv4 address. The TCO and amount of IPv4 addresses Tor operators need to acquire in order to run a high amount of Tor relays on a modern server is disproportionately high.
And we all know the reason. The available IPv4 address space has become sparse and significantly more expensive over the past ten years. In 2013 the price of one IPv4 address was around € 6,00. At the time of writing this proposal, the price fluctuates between € 50,00 and € 55,00 per IPv4 address. This steady increase in cost is passed on to Tor operators one way or another. For Tor operators using colo/DPS/VPS the increase in cost is reflected in the colo/cloud providers' rates. Tor operators running their own ASN/datacenter have to spent a large amount of money or need to spent considerable time on lobbying for a sympathetic party that owns and wants to sponsor IPv4 addresses. The latter is getting more difficult by the year, since the IPv4 address space is running dry for pretty much everyone.
All in all we experience the aforementioned restriction as a disproportionate measure in terms of benefits vs. cost for Tor operators. It's safe to say that this restriction currently and increasingly limits the amount of CPU cycles and bandwidth Tor operators can contribute to the Tor network (and make contributing to the network significantly more expensive). This will only become worse with time.
The Tor project is putting effort in a multi-threaded rust implementation of Tor named Arti. However, Arti is still a long way off and does not solve the problem we face for the coming years.
Changing Tor
To solve this problem, we propose to implement one of these options:
1) Enable 32 Tor relays per IPv4 address
The number is somewhat arbitrary and could be less or more. Modern servers with 64-96 cores/128-192 threads are readily available on today's server market. A lot of Tor operators run one Tor process per thread, so this would mean 4-6 IPv4 addresses per modern server CPU instead of 64-96 IPv4 addresses. Detecting operators that make use of this increased limit should be trivial.
2) Allow relay operators to request exceptions
If after discussion our first proposal is still met with hesitation/resistance, the Tor project could provide exceptions for Tor operators that request an increase or even removal of the restrictions in place. This would be a manual process and a Tor operator could request such an exception based on:
- IP address/network (e.g. 1.1.1.1 or 1.0.0.0/24).
- Authenticated Relay Operator ID (AROI).
- Autonomous System Number (ASN).
All of these options have advantages and disadvantages. IP addresses/networks used by an operator will change over time, which could add significant maintenance for managing the exceptions. AROI is a long term static ID (domain) that should be less likely to change than IP addresses. The ASN provides a long term static ID as well, but is only applicable to a small number of Tor operators.
We are not asking the Tor project to implement both options, one option that works for us is all we need. We will also bring this topic to the next Tor Relay Operator Meetup on 2023-01-28.
https://applied-privacy.net/
https://artikel10.org/
https://nothingtohide.nl/