<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On 1 Sep 2015, at 07:45, Philipp Winter <<a href="mailto:phw@nymity.ch" class="">phw@nymity.ch</a>> wrote:</div><br class="Apple-interchange-newline"><div class="">We sometimes see attacks from relays that are hosted on cloud platforms.<br class="">I have been wondering if the benefit of having cloud-hosted relays<br class="">outweighs the abuse we see from them.<br class=""><br class="">To get an idea of the benefit, I analysed the bandwidth that is<br class="">contributed by cloud-hosted relays. I first obtained the network blocks<br class="">owned by three cloud providers (Amazon AWS, Google Cloud, Microsoft<br class="">Azure), and determined the percent of bandwidth they contributed in July<br class="">2015. The results show that there were typically ~200 cloud-hosted<br class="">relays online:<br class=""><<a href="https://nymity.ch/sybilhunting/png/cloud-hosted_relays_2015-07.png" class="">https://nymity.ch/sybilhunting/png/cloud-hosted_relays_2015-07.png</a>><br class="">The spike shortly after hour 200 was caused by a lot of Amazon relays<br class="">named "DenkoNet". The spike at the very beginning was caused by a<br class="">number of relays that might very well belong together, too, based on<br class="">their uptime pattern.<br class=""><br class="">What counts, however, is bandwidth. Here's the total bandwidth fraction<br class="">contributed by cloud-hosted relays over July 2015:<br class=""><<a href="https://nymity.ch/sybilhunting/png/cloud-hosted_bandwidth_2015-07.png" class="">https://nymity.ch/sybilhunting/png/cloud-hosted_bandwidth_2015-07.png</a>><br class="">There were no Google Cloud relays to contribute any bandwidth. Amazon<br class="">AWS-powered relays contributed the majority of bandwidth, followed by<br class="">Microsoft Azure-powered relays. Here's a summary of the time series in<br class="">percent:<br class=""><br class=""> Min. Mean Median Max.<br class=""> 0.2% 0.8% 0.79% 1.5%<br class=""><br class="">In an average consensus in July 2015, cloud-hosted relays contributed<br class="">only around 0.8% of bandwidth. Note, however, that this is just a lower<br class="">bound. The netblocks I used for the analysis could have changed, and I<br class="">didn't consider providers other than Google, Amazon, and Microsoft.<br class=""><br class="">There are also cloud-hosted bridges. Tor Cloud, however, has shut down,<br class="">and the number of EC2 bridges is declining:<br class=""><<a href="https://metrics.torproject.org/cloudbridges.html?graph=cloudbridges&start=2015-01-01&end=2015-07-31" class="">https://metrics.torproject.org/cloudbridges.html?graph=cloudbridges&start=2015-01-01&end=2015-07-31</a>><br class=""></div></blockquote><div><br class=""></div><div>Can we preserve cloud-hosted bridges independently of whatever we decide to do to cloud-hosted relays?</div><br class=""><blockquote type="cite" class=""><div class="">The harm caused by cloud-hosted relays is more difficult to quantify.<br class="">Getting rid of them also wouldn't mean getting rid of any attacks. At<br class="">best, attackers would have to jump through more hoops.<br class=""><br class="">If we were to decide to permanently reject cloud-hosted relays, we would<br class="">have to obtain the netblocks that are periodically published by all<br class="">three (and perhaps more) cloud providers:<br class=""><<a href="https://docs.aws.amazon.com/general/latest/gr/aws-ip-ranges.html" class="">https://docs.aws.amazon.com/general/latest/gr/aws-ip-ranges.html</a>><br class=""><<a href="https://msdn.microsoft.com/en-us/library/azure/Dn175718.aspx" class="">https://msdn.microsoft.com/en-us/library/azure/Dn175718.aspx</a>><br class=""><<a href="https://cloud.google.com/appengine/kb/general?hl=en#static-ip" class="">https://cloud.google.com/appengine/kb/general?hl=en#static-ip</a>><br class=""><br class="">Note that this should be done periodically because the netblocks are<br class="">subject to change.</div></blockquote><br class=""></div><div>I wonder about the impact of this proposal on Tor research and on Tor developers.</div><div><br class=""></div><div>Some may consider it a benefit if researchers have to take more steps to interact with the Tor network.</div><div><br class=""></div><div>I wonder how many Tor developers develop using cloud machines, and whether it’s a benefit for them to be able to test changes on the live Tor network, or a drawback.</div><div>I test my changes on Linux using a cloud machine, and have used it at times to ensure that my changes don’t break when deployed on the live network. (I don’t do this at home, for both legal and connectivity reasons.)</div><div><br class=""></div><div>Of course, I use chutney to test my changes on a test network, before I use them on the live network.</div><div>So that’s another option for both researchers and developers.</div><div>As an aside, we're working on making chutney easier to use, and we’re getting there incrementally.</div><div>Here is a very rough draft plan:</div><div><a href="https://trac.torproject.org/projects/tor/wiki/doc/TorChutneyGuide" class="">https://trac.torproject.org/projects/tor/wiki/doc/TorChutneyGuide</a></div><div><br class=""></div><div>Of course, if researchers or developers or others really need a machine, they can move to a smaller cloud provider. This has benefits for diversity, and reduces what Google, Amazon, and Microsoft can know about Tor.</div><div><br class=""></div><div>Tim (teor)</div><div><br class=""></div></body></html>