Opened 6 years ago

Last modified 22 months ago

#9775 new enhancement

Authorities should report when they don't vote Running but some addresses are still reachable

Reported by: arma Owned by:
Priority: Medium Milestone: Tor: unspecified
Component: Core Tor/Tor Version:
Severity: Normal Keywords: tor-dirauth logging reporting easy
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

We withhold the Running flag if *any* of the relay's addresses is unreachable.

I just spent a while debugging 'trouble', where his IPv4 address was set up correctly, and moria1 kept logging

Sep 19 02:22:45.986 [info] dirserv_orconn_tls_done(): Found router
$67DE1CFEC8957833EAEE623F561BF57EB2D9CF2B~trouble at 5.9.125.198 to be
reachable at 5.9.125.198:443. Yay.

but his IPv6 address was port forwarding incorrectly.

The result was that 2 relays voted Running (I assume they're the ones who don't have IPv6 support), and the rest voted not Running.

One option is that we (e.g. consensus-health) should paw through the votes each hour to look for relays that have that same pattern of Running votes so we can contact them.

Another option would be for the authority votes to add an annotation somewhere, like in their votes, saying "partially reachable" or some such. That approach has the benefit that we could automatically have a record over time of how big an issue this is.

(If it's a big issue, it might argue for working harder to put partially reachable relays into the consensus somehow.)

Child Tickets

Change History (20)

comment:1 Changed 6 years ago by arma

(This one's ok to push to 0.2.6 if you need to.)

comment:2 Changed 6 years ago by nickm

Milestone: Tor: 0.2.5.x-finalTor: 0.2.6.x-final

comment:3 Changed 5 years ago by nickm

Keywords: 026-triaged-1 added
Type: defectenhancement

comment:4 Changed 5 years ago by nickm

Milestone: Tor: 0.2.6.x-finalTor: 0.2.7.x-final

comment:5 Changed 5 years ago by nickm

Status: newassigned

comment:6 Changed 4 years ago by nickm

Keywords: 027-triaged-1-out added

Marking triaged-out items from first round of 0.2.7 triage.

comment:7 Changed 4 years ago by nickm

Milestone: Tor: 0.2.7.x-finalTor: 0.2.???

Make all non-needs_review, non-needs_revision, 027-triaged-1-out items belong to 0.2.???

comment:8 Changed 3 years ago by teor

Milestone: Tor: 0.2.???Tor: 0.3.???

Milestone renamed

comment:9 Changed 3 years ago by nickm

Keywords: tor-03-unspecified-201612 added
Milestone: Tor: 0.3.???Tor: unspecified

Finally admitting that 0.3.??? was a euphemism for Tor: unspecified all along.

comment:10 Changed 2 years ago by nickm

Keywords: tor-03-unspecified-201612 removed

Remove an old triaging keyword.

comment:11 Changed 2 years ago by nickm

Keywords: 027-triaged-in added

comment:12 Changed 2 years ago by nickm

Keywords: 027-triaged-in removed

comment:13 Changed 2 years ago by nickm

Keywords: 027-triaged-1-out removed

comment:14 Changed 2 years ago by nickm

Keywords: 026-triaged-1 removed

comment:15 Changed 2 years ago by dgoulet

Keywords: tor-dirauth added; tor-auth removed

Turns out that tor-auth is for directory authority so make it clearer with tor-dirauth

comment:16 Changed 2 years ago by nickm

Status: assignednew

Change the status of all assigned/accepted Tor tickets with owner="" to "new".

comment:17 Changed 2 years ago by nickm

Keywords: logging reporting easy added
Severity: Normal

comment:18 in reply to:  description Changed 22 months ago by arma

Replying to arma:

Another option would be for the authority votes to add an annotation somewhere, like in their votes, saying "partially reachable" or some such. That approach has the benefit that we could automatically have a record over time of how big an issue this is.

I still think this is a good plan.

(We continue to run into relay operators who enable ipv6, screw it up, and wonder why their relay quietly fell out of the consensus.)

comment:19 Changed 22 months ago by teor

I think this is a good change. Don't we do it already with IPv6 by dropping the addresses in votes?
Or do we drop the entire relay from the vote when we drop the Running flag?
If I had to choose, I would prioritise relays checking their own IPv6 ORPort reachability over this change.

comment:20 in reply to:  19 Changed 22 months ago by teor

Replying to teor:

I think this is a good change. Don't we do it already with IPv6 by dropping the addresses in votes?

We do this, but Onionoo doesn't currently parse votes and use them for its new unreachable_or_addresses field:
https://metrics.torproject.org/onionoo.html#details_relay_unreachable_or_addresses

So this only works for IPv6 addresses when a minority of authorities is on IPv6.

Or do we drop the entire relay from the vote when we drop the Running flag?

We keep it, but vote it not Running. It only gets dropped from the consensus.

If I had to choose, I would prioritise relays checking their own IPv6 ORPort reachability over this change.

Also, consensus-health has a "ReachableIPv6" pseudo-flag, but doesn't parse votes or descriptors, so it can't do "UnreachableIPv6" yet:

https://consensus-health.torproject.org/

And Relay Search (Atlas) has IPv6 ORPort and IPv6 Exit flags, but, again, that doesn't really help:

https://atlas.torproject.org/#toprelays

Note: See TracTickets for help on using tickets.