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
_______________________________________________
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
