Hi Matt!
Matt Corallo:
Hey gk@!
I was directed to send a mail with this to you to make you aware of it by a random IRC'izen.
Thanks and sorry for the meeting confusion. It should be better from next week on once we get used to all the new processes in the network health world. I am CC'ing the network-health list, so others can chime in as well.
I wanted to point folks to some recent work in bitcoin-land that is likely of particular interest to tor folks: we've begun work to consider the asn which announces a given ip block in our peer selection algorithm in order to bolster our sybil-resistance, and have a relatively-efficient file format to be able to ship the global routing table with our binaries (eventually).... if you're interested, check out https://github.com/bitcoin/bitcoin/issues/16599 (and the academic work on Bitcoin sybil resistance at https://erebus-attack.comp.nus.edu.sg/ ). as well as the encoder for said encoding at https://github.com/sipa/asmap
Happy to get the right folks to join Tor-Network-Health meetings or so if there's room to collaborate given the highly overlapping problem sets here.
Skimming the paper I think Tor has already included a solution to this problem a while back: It's the "Whitelisting IP addresses"-approach in VII A. 3) in the paper, which is not a desirable solution for Bitcoin it seems.
In particular, the Tor client is not considering any node which is saying "Hey, I am a Tor node!" when it decides to build a path through the network, but rather only those nodes the directory authorities have consensus over. They are essentially the ones who get to decide which relays count as Tor relays for which purpose (like an exit relay) and which not, and anyone else uses that consensus (i.e. whitelist) for path-building. In the Tor context there are no "shadow IPs" which the attacker can flood a victim node with to get traffic re-routed.
Does that make sense? If not, I am happy to see how you think the Erebus attack is important for the Tor network. (Don't get me wrong. Tor is not immune to sybil attacks. It just seems to me that the Erebus version is not one we need to worry about.)
Georg
Right, Tor has a much simpler Sybil repentance solution in the directory authorities, and I didn’t mean to imply that Tor was vulnerable to an Ereberus-style attack by any means.
Still, relying on the dirauths as they exist today is not perfect. While it may, in principle, be ok that OVH has a preponderance of Tor relays, it wouldn’t be ok to build a path through only OVH relays (even if they are in different countries). In theory ASMap could address exactly that.
While that may not be a pressing enough issue that simple reweighing of OVH nodes can’t handle, doing so still requires BGP topology data at the dirauths. Some of the preprocessing that we’re looking at (eg common path/ASN flooding detection) may help here.
Matt
On Jan 31, 2020, at 02:36, Georg Koppen gk@torproject.org wrote:
Hi Matt!
Matt Corallo:
Hey gk@!
I was directed to send a mail with this to you to make you aware of it by a random IRC'izen.
Thanks and sorry for the meeting confusion. It should be better from next week on once we get used to all the new processes in the network health world. I am CC'ing the network-health list, so others can chime in as well.
I wanted to point folks to some recent work in bitcoin-land that is likely of particular interest to tor folks: we've begun work to consider the asn which announces a given ip block in our peer selection algorithm in order to bolster our sybil-resistance, and have a relatively-efficient file format to be able to ship the global routing table with our binaries (eventually).... if you're interested, check out https://github.com/bitcoin/bitcoin/issues/16599 (and the academic work on Bitcoin sybil resistance at https://erebus-attack.comp.nus.edu.sg/ ). as well as the encoder for said encoding at https://github.com/sipa/asmap
Happy to get the right folks to join Tor-Network-Health meetings or so if there's room to collaborate given the highly overlapping problem sets here.
Skimming the paper I think Tor has already included a solution to this problem a while back: It's the "Whitelisting IP addresses"-approach in VII A. 3) in the paper, which is not a desirable solution for Bitcoin it seems.
In particular, the Tor client is not considering any node which is saying "Hey, I am a Tor node!" when it decides to build a path through the network, but rather only those nodes the directory authorities have consensus over. They are essentially the ones who get to decide which relays count as Tor relays for which purpose (like an exit relay) and which not, and anyone else uses that consensus (i.e. whitelist) for path-building. In the Tor context there are no "shadow IPs" which the attacker can flood a victim node with to get traffic re-routed.
Does that make sense? If not, I am happy to see how you think the Erebus attack is important for the Tor network. (Don't get me wrong. Tor is not immune to sybil attacks. It just seems to me that the Erebus version is not one we need to worry about.)
Georg
On Fri, Jan 31, 2020 at 05:48:19PM -0500, Matt Corallo wrote:
Still, relying on the dirauths as they exist today is not perfect. While it may, in principle, be ok that OVH has a preponderance of Tor relays, it wouldn???t be ok to build a path through only OVH relays (even if they are in different countries). In theory ASMap could address exactly that.
Hi Matt!
The real fun begins when you think not just about the locations of the relays, but about the locations that the traffic goes through, when it's transiting between relays.
That is, yes you should worry about whether all your relays are in buildings owned by OVH. But you should also worry about whether the traffic between the relays transits a single (the same) telephone company at each hop. And for the Tor case (I don't know about your case), what matters most to us is the internet path between the client and the first relay, and the internet path between the last relay and the destination.
Many papers have been written about the topic, from measuring how bad it is: https://www.freehaven.net/anonbib/#feamster:wpes2004 https://www.freehaven.net/anonbib/#DBLP:conf:ccs:EdmanS09 https://www.freehaven.net/anonbib/#ccs2013-usersrouted https://www.freehaven.net/anonbib/#trustrep-pets2015 https://www.freehaven.net/anonbib/#tortraceroutes-pets2015
to designing alternate path selection mechanisms to avoid trust bottlenecks: https://www.freehaven.net/anonbib/#ccs2011-trust https://www.freehaven.net/anonbib/#ASlevel-ndss2016 https://www.freehaven.net/anonbib/#taps-ndss2017 https://www.freehaven.net/anonbib/#counter-raptor https://www.freehaven.net/anonbib/#placement-pets2019
And those are just a few of them. To start reading, I would suggest these three: https://blog.torproject.org/improving-tors-anonymity-changing-guard-paramete... https://www.freehaven.net/anonbib/#ccs2013-usersrouted https://www.freehaven.net/anonbib/#placement-pets2019
Hope this helps, --Roger
network-health@lists.torproject.org
-
Georg Koppen -
Matt Corallo -
Roger Dingledine