January 2020 - network-health - lists.torproject.org

Upgrade your 'tarragon' Tor relay?
by Roger Dingledine 06 Apr '20

06 Apr '20

Hi William, You are running a Tor relay, which is great: http://rougmnvswfsmd4dq.onion/rs.html#details/1D4AB6248E3D7DF9C4FBE40DCFAA3… First: that Tor version is obsolete, and because of old bugs, we will soon cut relays running those versions out of the network. Please consider upgrading! Second: let us know if there is any way to help you bump up the bandwidth that you are allocating to the Tor relay. :) You can find Tor packages for your distro / OS here: https://trac.torproject.org/projects/tor/wiki/TorRelayGuide#Platformspecifi… Ideally you will switch to keeping up with our stable releases, but if you need a stable that is especially stable, the Tor 0.3.5 branch will be maintained until Feb 2022: https://trac.torproject.org/projects/tor/wiki/org/teams/NetworkTeam/CoreTor… and you can see the lifetimes of other Tor versions on that table too. Let us know if we can do anything to make the process easier. And lastly, I am cc'ing the new network health mailing list (which has public archives), to help us stay synced: https://trac.torproject.org/projects/tor/wiki/org/teams/NetworkHealthTeam Thanks! --Roger

3 2

Tor1AS20435 is failing to relay exit traffic
by Georg Koppen 16 Mar '20

16 Mar '20

Hello! Your relay Tor1AS20435[1] seems to fail relaying exit traffic according to our measurements. We ran tests from differnent vantage points and it was not possible in 10/10 cases to reach https://example.com. Could you please look into that and resolve the issue on your end? Our overall runs and results are available on Github.[2] Please let us know if you have further questions and when the problem is resolved on your side. Thanks for running a relay! Georg [1] https://metrics.torproject.org/rs.html#details/AD1639F47D6233E812A67F98F9D7… [2] https://arthuredelstein.net/exits/

1 1

Re: [network-health] ASMap Work for Sybil Resistance in Bitcoin Core
by Georg Koppen 31 Jan '20

31 Jan '20

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

3 2

(FWD) Directory authorities DDoSed by consensus fetches
by Roger Dingledine 29 Jan '20

29 Jan '20

FYI. --Roger ----- Forwarded message from Roger Dingledine <arma(a)torproject.org> ----- Date: Wed, 29 Jan 2020 04:11:46 -0500 From: Roger Dingledine <arma(a)torproject.org> To: dir-auth(a)lists.tpo Subject: Directory authorities DDoSed by consensus fetches Hi folks! I wanted to let you know about an issue that came up over the past few weeks, and is continuing. In short, many thousands of places around the internet are fetching the vanilla consensus document, uncompressed, from the dirport of the dir auths. moria and gabelmoo shot up to 400mbit/s sustained, and even that wasn't enough because they couldn't reliably interact with the other dir auths (e.g. send or receive votes) at that level of load. Probably your dir auth is under huge load currently too. Here's the plan: (0) If you need to squeeze down your bandwidth use for now, e.g. by setting a lower BandwidthRate, do it and don't feel bad. The pain will continue for a while yet, and answering all of the requests is not worth getting in trouble with your hoster. (1) If you're into patching your Tor source yourself, here is a very simple patch that will help you for now: https://bugs.torproject.org/33029#comment:18 It prioritizes answering other relays and other directory authorities, when rate limiting is kicking in. This patch won't by itself reduce your bandwidth load, but it will let you turn down the BandwidthRate knob while still being a productive useful dir auth. (2) We'll have a more thorough version of this patch out sometime soon, in the form of a git branch and eventually a Tor update. Let us know if the patch in #1 doesn't do it for you and you need us to get to step #2 quicker. (3) Longer term, we need to start refusing (some of) these extra requests. We have found some simple distinguishers that make us think they are not actual Tor clients, and that mean we can refuse the requests without that much collateral damage. We still need to think through exactly how we want to do that though -- and putting some more defenses in place, in case the requests morph into something else, could be smart too. The ticket to follow here is https://bugs.torproject.org/33018 More when we have it, --Roger ----- End forwarded message -----

1 0

Re: [network-health] AquaRayTerminus is failing to relay exit traffic
by Georg Koppen 25 Jan '20

25 Jan '20

Remi Gacogne: > Hi Georg, > > On 1/23/20 4:21 PM, Georg Koppen wrote: >> Your relay AquaRayTerminus[1] seems to fail relaying exit traffic >> according to our measurements. We ran tests from different vantage >> points and it was not possible in 10/10 cases to reach >> https://example.com. Could you please look into that and resolve the >> issue on your end? >> >> Our overall runs and results are available on Github.[2] Please let us >> know if you have further questions and when the problem is resolved on >> your side. > > This should be fixed now. We had a DNSSEC validation issue for this > domain, due to a MTU issue somewhere along the way between the NS for > example.com and our recursive servers (DNSKEY answers were lost over > UDP, leading to DNSSEC validation failure). > > I would suggest trying with an additional non DNSSEC-signed domain to be > able to differentiate various kinds of issues, although I completely > agree that exit nodes should handle DNSSEC-signed domains gracefully. Yes, that's a good idea and I'll tweak our script accordingly. > Thank you for running these measurements of the Tor exit nodes! You are welcome! Georg > Best regards, > > Remi >

1 0

Weekly network-health meeting Mondays 1900 UTC in #tor-meeting
by Georg Koppen 24 Jan '20

24 Jan '20

Hello! As written in my meeting notes, which I just sent to the tor-project list[1], we have a tentative weekly meeting time where we'll talk about work in the network health area (what we did/what we plan to do, issues that came up during the week etc.). Starting with February 3 we'll meet Mondays 1900 UTC in #tor-meeting at OFTC's IRC network. Everyone is welcome to listen in and contribute! See you there, Georg [1] https://lists.torproject.org/pipermail/tor-project/2020-January/002677.html

1 0

AquaRayTerminus is failing to relay exit traffic
by Georg Koppen 23 Jan '20

23 Jan '20

Hello! Your relay AquaRayTerminus[1] seems to fail relaying exit traffic according to our measurements. We ran tests from different vantage points and it was not possible in 10/10 cases to reach https://example.com. Could you please look into that and resolve the issue on your end? Our overall runs and results are available on Github.[2] Please let us know if you have further questions and when the problem is resolved on your side. Thanks for running a relay! Georg [1] https://metrics.torproject.org/rs.html#details/616081EC829593AF4232550DE6FF… [2] https://arthuredelstein.net/exits/

1 0

Kick-off meeting for network health work on Thursday, 1/23, 1800 UTC
by Georg Koppen 21 Jan '20

21 Jan '20

Hello! For those of you not subscribed to our tor-project mailing list here is the exciting news that we will have a kick-off meeting for our new network health team this Thursday, at 1800 UTC in #tor-meeting2 on IRC on OFTC's network[1]. Everyone is welcome! We have started to collect an agenda and noted already existing tickets for a potential roadmap[2]. If there are more items we should consider, please add them. Right now we want to make progress on - a vision and big items to work on in the medium and longer term - thinking about potential projects for the upcoming Google Summer of Code - starting our roadmapping for the coming weeks and months - setting up processes like other teams already have (weekly meetings, publishing meeting notes etc.) See you there, Georg [1] See: https://www.oftc.net/ [2] https://pad.riseup.net/p/tor-networkhealth-2020.1-keep

1 0

2024

2023

2022

2021

2020

2019

network-health January 2020