Hello,

Thanks all for joining the Tor Relay Operator meetup! You can find the meeting notes below.

Our next meetup is on March 04, 2023 at 1900 UTC (duration between 60 to 90 minutes).

cheers, Gus

## Tor Relay Operator Meetup - 2023-01-28

Meting duration: 90 minutes

## Agenda

Introductions from Tor core people: Gus (community team), Roger (original founder, author of C-Tor, etc), GeKo (network health, bad relays), Alex (network team), Joydeep (community, user support), George (bridge authority operator, university relay advocacy, BSD!!!!1)

### Announcements

- Bridges 0.4.6.x EOL

In the past month we've removed relays running Tor 0.4.6 from the network, and the upcoming step is to do the same with bridges. If you're running an 0.4.6 bridge, please upgrade now!

If you have issues keeping your relay or your bridge up to date, please reach out to us. We want to help!

If you have friends or family who are running old Tor versions, please reach out to them to help them upgrade too.

- FOSDEM (Feb 04/05) activities

There will be many Tor people at Fosdem (Brussels) in person in a week. There might be a Tor meetup. If you will be there, let us know and we can connect you to Tor people.

- Tor on Universities

We're working toward a "relays at universities" campaign, in collaboration with EFF. Details coming soon hopefully. Not just relays but also Snowflake proxies and other good ways to help. The idea is to promote Tor not just to students, but also to faculty, to sysadmins, to other pieces of universities. Universities are good matches because they are about education and improving the world. Also their networks are less appetizing for nationstates to want to block. We're putting together a landing page that aims to help people do advocacy -- to explain what Tor is, why they should be contributing, why it's not as scary as they might think. Not just US-based, intended to be worldwide.

So: if you know universities that do run Tor, please tell Gus and George so we can coordinate the campaign with them. Or if you know university people who *should* run Tor, be thinking about that, and keep an eye out for this upcoming campaign.

Suggestion: Tor could contact GÉANT, which is the pan-European network where National Research and Education Networks (NRENs) all come together. In turn, pretty much all universities are members of those NRENs. If you can convince GÉANT you have a very nice foothold within the NRENs and universities

Follow-up suggestion: we have contacts at Nordunet, and the Nordunet people might be a great way to reach the right people inide GEANT.

Q: What about universities that run relays but they run them on separate IP blocks, to not have them on their main net blocks? Useful or not useful?

A: Yes, still very useful! Every situation is different, and our goal is to raise awareness and build capacity however it makes the most sense in each case. Exit relays must be on separate IP blocks because they ended on blocklists.

### State of DoS attack

- There is a blog post scheduled for next week - But it won't have that many operational details, because we don't want to give away details of what we are doing / what we have found. - Summary: the DoS is still ongoing. We have seen three or four different parallel attacks going on. It's of course unclear if it's the same actor or different actors. - At least one or two of them are still ongoing: the introduction cell flooding is ongoing. - Using Tor Browser to surf the web is not as painful now as it was a few weeks ago. Torperf/onionperf data for these timeframes supports this impression. - Late November was especially painful: https://metrics.torproject.org/torperf.html?start=2022-10-30&end=2023-01... - Things are better now, but if you look at the longer timeframe: https://metrics.torproject.org/torperf.html?start=2022-05-01&end=2023-01... you will see that things are still not back to normal. - The good news is that we have two new developers hired, for onion service fixes and for DoS defenses. Focusing on C-Tor fixes for now, so users will get actual improvements in the short term; the hope is to work on Arti later on too. - We originally had hoped to focus just on Arti, and leave C-Tor alone for new features or fixes, but we're bending that goal quite a bit here in order to help debugging and understanding C-Tor overload issues. - "It's not over but there is reason for optimism."

### NetCraft spamming operators, their upstream, LEA, national CERT, ISP, contact addresses, … How to handle this?

https://lists.torproject.org/pipermail/tor-relays/2023-January/020968.html

- One opinion: it is a nuisance but not a big deal. - Some other places use fail2ban and spam complaints that you can't answer anyway - As relay operators, you need to learn to use filters for incoming spam/abuse mails. - "It is easy to filter out, so no big problem."

### Allow more relays per IPv4 address

https://gitlab.torproject.org/tpo/core/tor/-/issues/40744

- We originally put this limitation in place because without it attacks are too easy: https://gitlab.torproject.org/tpo/core/torspec/-/blob/main/proposals/109-no-... - But back then, Tor relays scaled much better per cpu than they do these days. - So Roger's perspective is that yes we should raise the limit or find some similar approach. - The big question in my mind is: what does that do to the network health team people? They spend time hunting weird Sybil patterns and would this make their job a little bit harder or a lot harder? - Answer from GeKo: raising it to 4 or 8 would not change the network health things much, and it would be an easy change to make at directory authorities. - One issue to look for if we do make this change: will relays on crowded servers end up with more file descriptor problems or other scaling issues that make their relays crummy in a way that's hard to detect / confusing for users to fix? We would want to watch carefully!

Suggestion from the meeting here: pick 8, because it should last us a while, but make sure the network health team is prepared to look for overloads.

### Q&A

- Following http://eweiibe6tdjsdprb4px6rqrzzcsi22m4koia44kc5pcjr7nec2rlxyad.onion/tpo/co... i wish people add a Number 6. Where get funds with privacy aimed to support better guards , exits nodes.

- There are "relay associations" listed at e.g. https://torservers.net/partners/. But, you need to become well known among your community, or set up your own nonprofit within your community, or etc. - We could do a Tor relay operator meetup dedicated to this topic: how your relays are funded, what gaps there are and how/whether to fill them. - What do existing relay associations think about doing a workshop like this? - One thought is that relay associations should have an internal 'private' workshop among themselves, where they compare notes on funding models, membership, decision making, etc, and then once that community exists it would make more sense to do a public "and here's how you can do it too" workshop. - We do have some relay operator groups here at this meeting who would be interested in such a workshop.

- Exonerator: IPv6 exit scanner support needed. LEA getting a "negative" answer back, implying that the IPv6 is not used by a tor exit is bad for us exit operators. IPv6 exit traffic is more and more common. Note: normal IPv6 exiting is supported by exonerator, just not if you use the torrc to use a different IP for exiting. Root cause: exit scanner does not support IPv6 yet.

Ticket: https://gitlab.torproject.org/tpo/network-health/metrics/exit-scanner/-/issu...

There is an underlying earlier issue which is: the active exit scanner doesn't learn IPv6 addresses for exits. But apparently it *does* work if your IPv6 address is listed in your relay descriptor.

Idea: in the relay documentation, add a note about "if you set this torrc option to IPv6 exit on a different address, be aware that exonerator won't know about your new address, here's the ticket to watch"

- wrt to DoS against exits: please consider supporting a design that allows exit operators to filter inbound connections and allow authenticated relay-to-relay connections only

^^ Is there a gitlab ticket for this proposed idea? It might be reasonable, but also (a) you don't know if an incoming connection is from an authenticated relay until you've done all the tls handshake, tor handshake, etc to decide who it is, and (b) requiring relays to have synchronized views of 'who is a relay' can create more brittleness, not less.

https://gitlab.torproject.org/tpo/core/tor/-/issues/40715 (the ticket is just related, it is not the same thing)

- "anti-exit-DDoS: token bucket limit for new streams per circuit at exits" https://gitlab.torproject.org/tpo/core/tor/-/issues/40736 We have plans to work on this ticket -- it's on the current roadmap starting in April. Specific details not chosen yet.

- **Metrics Port documentation**: from the last meetup in Nov 2022: https://lists.torproject.org/pipermail/tor-relays/2022-November/020885.html ticket got closed but there is still no metrics and labels documentation. The linked MR didn't add much documentation to it, it mainly is a pasted output of metrics: https://gitlab.torproject.org/tpo/web/support/-/merge_requests/134/diffs

There is a huge support entry for this topic: https://support.torproject.org/relay-operators/relay-bridge-overloaded/ What does each label mean? Should I open a new ticket? yes, please open a ticket: web/support

Next steps: dgoulet and geko will work to share their dashboard template.

- When is the next relay operator meetup?

March 4, 19UTC

- Tor 0.4.5 is going end-of-life in about two weeks. This is the long-term stable version that we maintained for Debian. - This will be the last long-term stable for C-Tor, with the new upgrade treadmill we want everybody on. - There are packages on deb.torproject.org, there are packages for Red Hat, there is no excuse for sticking to 0.4.5. Please upgrade! - Even armhf should be working. Let us know if you have troubles.

- Any thoughts/updates about that person who published a ton of Snowflake etc. IPs on GitHub?

Did apparently not contact the Tor Project. No information otherwise. See: https://lists.torproject.org/pipermail/tor-dev/2023-January/014798.html

On Wed, Jan 11, 2023 at 01:50:27PM -0300, gus wrote:

Dear relay operators,

Save the date: our next Tor relay operator meetup will happen on January 28 at 19:00 UTC!

We're drafting the agenda here:

• pad: https://pad.riseup.net/p/tor-relay-op-meetup-j28-keep
• onionsite: http://kfahv6wfkbezjyg4r6mlhpmieydbebr5vkok5r34ya464gqz6c44bnyd.onion/p/tor-...

Feel free to add topics and/or questions.

Room Link - https://tor.meet.coop/gus-og0-x74-dzn

cheers, Gus -- The Tor Project Community Team Lead