[network-health] ASMap Work for Sybil Resistance in Bitcoin Core

[Matt Corallo]

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 at 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
>