[tor-dev] Proposal Waterfilling

[A. Johnson]

Hi Florentin,

Thanks for the thoughtful response!


> So why is it working? I come up the following conclusion: OVH is a big enough company not to lie with "unlimited, unmetered 100Mbits". I did not try other big providers, but that would be likely the same result.
> 
> Conclusion: we can run many Gbps of bandwidth with the price I gave above, for now.

I wonder how confident we can be about this situation. If we are most worried about an attacker trying to get, say, 10% of the network, would the provider be as oblivious/generous? Your numbers below (10% = 15Gbps) would require running 15*(3/2) / 0.1 = 225 relays at 3 euros/month each. Would OVH still ignore 225 cheap VPSs at 100% bandwidth utilization? Would they still be able to provide 100Mbps at that number?

> Yes, you are right. This is insane price and theoretically stronger against Waterfilling. But let me count the number of relays needed to achieve, let's say 10% of bandwidth with that provider, and let's suppose 10% is 15 Gbps (https://metrics.torproject.org/bandwidth-flags.html <https://metrics.torproject.org/bandwidth-flags.html>). Waterfilling reduces the bandwidth that the adversary needs by (currently) a 2/3 ratio. So, the adversary needs 10 Gbits:
> 
> 10000/6 = 1666 relays.
> 
> From this number, I wonder the following things:
> 
> Can an adversary puts 1666 Guard relays in the network such that this community would not notice that something strange is happening? Given the fact that we don't even have 2000 Guards by now.

Again, I don’t see how this would be more noticeable or alarming than a single entity providing 10% of the guard bandwidth. Moreover, the security argument that “someone will surely notice and do something” doesn’t have a good track record. Absent a specific plan of how to notice it and respond automatically, I wouldn’t want to rely on it.

> Does the provider have enough IPv4? Are they the same /16?

Are you sure there aren’t many providers with such cheap deals (I fairly easily found another with $9/year for an IP and a 2TB cap: <https://www.woothosting.com/pulse/cart.php?gid=16>)? Being in the same /16 won’t make a difference in their guard probability.

>> Alternatively, I bet you could get bulk IPv4 addresses for much cheaper than the $3/month that OVH charges for its SSD VPS, which you could then potentially apply to your 100Mbps (or larger) server to get 10Mbps and more cheaply attack waterfilling. For example, OVH provides 256 IP addresses for its dedicated servers at no monthly cost (https://www.ovh.co.uk/dedicated_servers/details-servers-range-GAME-id-MC-64-OC.xml <https://www.ovh.co.uk/dedicated_servers/details-servers-range-GAME-id-MC-64-OC.xml>). These servers can be had for at least 55 euros/month, which provides 500Mbps unlimited. With two of those, you could achieve the above attack on waterfilling for 110 euros = $136.36/month instead of 300 euros/month = $371.92/month.
> 
> You're right. But you're also having the same /24 for all your relays running on this machine. Some easy rule on the directory server can prevent this to happen. Limiting the number of relays over a same /24 for example.

Incorporating IP prefix diversity in Tor’s path selection does seem like a good idea in general. It sounds like you are suggesting that waterfilling should include a fixed limit on the number of relays in a /24. This is now a new scheme that would need its security analyzed. A few things that come to mind:
  1. Would there be limits for larger prefixes than an adversary might obtain (e.g. /16)? If not, the limit is only effective for adversaries without resources to obtain a larger prefix.
  2. Wouldn’t this allow an adversary to squat on a prefix? For example, he could run a bunch of cheap relays on prefixes owned by the Tor-friendly ISPs and keep anybody else from contributing more resources using that ISP.
  3. If resource limits are a reasonable strategy, instead of waterfilling, why not apply such limits to bandwidth (e.g. no more than 10Gbps per /24)? It seems simpler. It is also not susceptible to an attack on water filling in which the water level is raised by contributing to both guard and exit bandwidth.

Best,
Aaron
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20180309/d78b5e4d/attachment.html>