[tor-relays] (Notes) Tor Relay Operators Meetup - 2023-01-28 @ 19UTC

Thu Feb 2 15:14:37 UTC 2023

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-28&server=public&filesize=5mb
- 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-28&server=public&filesize=5mb
  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-sharing-ips.txt
- 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/community/team/-/wikis/Expectations-for-Relay-Operators
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/-/issues/29624

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-relay-op-meetup-j28-keep
> 
> 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

-- 
The Tor Project
Community Team Lead
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.torproject.org/pipermail/tor-relays/attachments/20230202/a79b33eb/attachment.sig>