Hi,
Thanks everyone for joining us last saturday. You can find the meetup notes below.
The next Tor Relay Operator meetup will happen in June 25, 1900 UTC.
cheers, Gus
Agenda / Повестка дн ====================
May 21, 2022
* EOL work: - Tor versions lower than 0.4.5 are now unsupported and being removed from the network. - Ideally relays will be running 0.4.7 now because of the congestion control feature. - You can find more about this work at the Tor network health team repository: https://gitlab.torproject.org/tpo/network-health/team
* DemHack.ru hackathon: https://blog.torproject.org/event/demhack-2022/ - We are working with volunteers on a hackfest to develop a bridge distribution mechanism that uses Signal (woo). They might be on irc at #tor-dev; if you see them, help them! - You can read more about the projects here: https://roskomsvoboda.org/post/demhack-4-final/
* MCH event (in July): https://mch2022.org/#/Blog
At least four core Tor people will be present at this conference. Hopefully there will be a relay operators meetup. But there is no schedule published yet, so, stay tuned!
* "Sysadmin 101" workshop in June, will be announced on tor-relays@ mailing list. If you're a relay operator but not comfortable with sysadmining, please join the workshop! It will be faciliated by George (BSD fan) and Kushal (Linux fan): "How to run a good relay for the Tor network" -- learn to configure your time properly, and everything else.
* Brief update on the Ola Bini case - Roger and Linus finished their expert witness testimony last week. You can read more about the case here: https://www.eff.org/deeplinks/2019/08/telnet-not-crime-unconvincing-prosecut...
* Torservers updates No torservers.net people present at meeting yet, so we will catch up with this topic next time or on the mailing list.
* New Tor version support policy: https://lists.torproject.org/pipermail/tor-announce/2022-May/000241.html
- Historically, we were tied closely to the Debian release cycle, including having a "long term stable" that we support for years so it can be in Debian. - We would much prefer relays to use the deb.torproject.org debs, which will keep people on the latest Tor stable. - The new proposal is to drop the long term stable idea, and ultimately we only allow relays onto the network if they're running the latest versions. - Feedback: Getting recent Tor versions into OpenBSD (*/6 mos), NetBSD/pkgsrc (quarterly) stable is going to be a challenge. People need to reach out to their package repositories and begin that discussion. - The plan is that *clients* can stay on a Debian stable, and we will try to keep supporting them. So it is only relays that need to do this faster cycle. - We also need to make sure to avoid having many old zombie clients trying to reach the network. - https://gitweb.torproject.org/torspec.git/tree/proposals/266-removing-curren... is a good article to read to get up to speed on zombie clients and ways to handle them.
* Malicious relays and the health of the Tor network: https://blog.torproject.org/malicious-relays-health-tor-network/
- People have been asking us every so often about the "kax17" attacker that was publicized in blog posts in the past. We were trying to decide how to react to those -- leave it quiet, make new publicity, something else? Ultimately we decided to do a blog post on our own to summarize what the network health team has been doing for bad-relays, and using the kax17 as an example of what we did in the past, where we failed, how we learned from it. - [Discussion about whether it makes sense to do a new blog post for each new attack, or what. Brief summary is yes [The "yes" was more to an announcement, say, on tor-relays@ than doing a blog post. Blog posts for this kind of things should be really a rare exception --GeKo] if it results in a huge surprising drop in network size, but no if it is yet another small attack similar to the one before it.]
* Congestion control release (0.4.7.7)： https://blog.torproject.org/congestion-contrl-047/
- We need exit relay operators and onion service operators to upgrade to 0.4.7. Once both of these sides are upgraded, then everybody will see better performance. - Next step is to make a Tor Browser release with a client version that uses congestion control. At that point we expect to see network load going up, i.e. your relays will use more of their capacity. - https://metrics.torproject.org/bandwidth.html the spike in advertised bandwidth at the end is (hopefully!) due to the new feature. - Next step after this is multi-path (Conflux).
* What's the time plan, or version plan, for Conflux?
- We delayed 0.4.7 to have congestion control, which was a huge process. Conflux will come in 0.4.8 or 0.4.9, i.e. in the next 6 to 12 months, woo.
* Expectations for Relay Operators: https://gitlab.torproject.org/tpo/community/team/-/wikis/Expectations-for-Re...
- This is the periodic notice at each of these relay operator meetups, to let you all know that we have written down some expectations for our relays and for our relay operators, in terms of being good and useful members of our community. Please take a look!
* Q&A
* We've seen occasional traffic peaks in the last few weeks, is this Tor 0.4.7 already? For example exit nodes seen 2x the traffic for 10-20 minutes.
- How lately? It might be floodflow by Rob. Last one was Oct last year. You can read more about network experiments like this at https://status.torproject.org/ https://status.torproject.org/affected/network-experiments/ - If they are short term traffic peaks, you might also briefly be the introduction point (or HSDir, if it was entire day) for an onion service that is under attack (or just very popular). DDoS attackers send huge sets of intro cells toward the introduction points. - We've also seen some weird exit node flooding, seems related to Ukraine/Russia: https://gitlab.torproject.org/tpo/network-health/analysis/-/issues/30 - Tip: run Prometheus on our relay, and see if your dns resolving software sees traffic spikes in the same period as your traffic spike.
* When our relays are under heavy load, the Prometheus exporter is unable to talk to the control socket, and we get alerts. Is this known/should I create an issue?
- little-t-tor has its own metrics, much more lightweight. Look at MetricsPort manual entry. And how to enable it: "Enabling MetricsPort" - https://support.torproject.org/relay-operators/relay-bridge-overloaded/ - Yes, but also much more lightweight on information. It doesn't even have traffic metrics, AFAIK. It seems to be mostly about errors/overload status. - I think it has traffic stats. About errors is log file. - Probably not going to get fixed in c-tor. The arti sitation has a better architecture and so it shouldn't suffer from this particular issue.
* wrt to the change of tor release policy: it was our impression that tor gitlab tickets relevant to large relay operators did not get much attention in the last two years so we are glad you are formalizing what has been our impression anyway but that also means we will see no progress? for a while in the tor relay ops area? (until rust tor is ready)
- We aren't planning to completely ignore relay support in C-tor. For example, Conflux as discussed above. - We're certainly ramping down the efforts on C-tor relays -- e.g. being very narrow in terms of what new features we add. - If you have tickets or features or bugs that you think are important, raising them on the tor-relays@ list, or talking to Gus or network team or network health team people, are all good ways forward.
* When will the fast relay flag be redefined? - discussion will happen after conflux, which alex just talked about, will be implemented https://gitlab.torproject.org/tpo/core/torspec/-/issues/100#note_2804424
* Did enough exit nodes already upgrade to Tor 0.4.7.7, so that the planned Tor Browser release including this version will be on May 31st? - Yes [--GeKo]. "FYI: Over 80% of our Exit consensus capacity has upgraded to 0.4.7" (Mike Perry, May 18)
* Getting obfs4proxy packages upgraded, e.g. on Ubuntu. https://bugs.launchpad.net/ubuntu/+source/obfs4proxy/+bug/1967003 Not trivial because of go dependencies. Maybe deb.torproject.org can do a binary release to help?
- The fix went into 0.0.12: https://github.com/Yawning/obfs4/blob/master/ChangeLog - Here is the debian packaging ticket: https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/obfs4... - Gus will follow up with the AC team about that.
* Next Relay Operator Meetup: June 25 - 19:00 UTC.
We will open the room 10 minutes before, so you can test your audio settings.
On Sat, May 21, 2022 at 03:29:24PM -0300, gus wrote:
Hello!
The Tor Relay Operator is happening today in ~30 minutes!
Here is our agenda:
- Announcements:
- EOL work (GeKo)
- DemHack.ru hackathon (Gus)
- MCH event (Gus)
- Torservers updates
- New Tor version support policy (network team - ahf): https://lists.torproject.org/pipermail/tor-announce/2022-May/000241.html
- Malicious relays and the health of the Tor network: https://blog.torproject.org/malicious-relays-health-tor-network/ (GeKo)
- Congestion control release (0.4.7.7)：https://blog.torproject.org/congestion-contrl-047/ (ahf)
- Expectations for Relay Operators: https://gitlab.torproject.org/tpo/community/team/-/wikis/Expectations-for-Re... (Gus)
- Q&A
- Next Meetup
o/ gus
On Thu, May 05, 2022 at 12:19:42AM -0300, gus wrote:
Hello relay operators,
The next Tor relay operator meetup will happen on Saturday, May 21 @ 1900 UTC.
Where: BigBlueButton - https://tor.meet.coop/gus-og0-x74-dzn
No need for a registration or anything else, just use the room-link above.
We're working on the agenda here: https://pad.riseup.net/p/tor-relay-meetup-may-2022-keep
Everyone is free to bring up additional questions or topics at the meeting itself.
Please share with your friends, social media and other mailing lists!
cheers, Gus -- The Tor Project Community Team Lead
-- The Tor Project Community Team Lead
tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays