Opened 8 months ago

Last modified 4 months ago

#33530 new enhancement

Dir auths should notice relays with wrong clocks and act somehow (BadClock flag, withhold Guard)

Reported by: arma Owned by:
Priority: Medium Milestone: Tor: unspecified
Component: Core Tor/Tor Version:
Severity: Normal Keywords: network-health, needs-proposal, 044-deferred
Cc: Actual Points:
Parent ID: Points: 2
Reviewer: Sponsor:


Directory authorities scan every relay every 22 minutes or so, to test reachability.

As part of establishing the Tor connection handshake, they get a netinfo cell from the relay. So if they look at it, they will know whether the relay's clock is right or wrong.

So we're nearly there. Now we should act when we find a relay with a wrong clock, to help the relay operator fix it, and to reduce the harm to clients.

I suggest taking two responses if a relay has a wrong clock:

(A) Don't assign it the Guard flag. Clients rely on their guards for time, e.g. because they need the guards to have proper cached dir info. And in the glorious future where we've made progress on #2628 and friends, while we won't want to rely solely on non-dir-auth relays to tell us if we're skewed, if we can drive down false positives from normal relays, the parameters get easier to pick for whatever solutions we decide on.

(B) Put the "BadClock" flag in our vote about it. We don't need to change the consensus building process, or even get that flag into the consensus itself. Just having it in the votes means that consensus-health and relay-search can look at it and visualize it for relay operators, rather than needing to do their own clock scans. (And having it there helps the operator debug confusing questions like *why* they aren't getting the Guard flag.) And as a bonus here, eventually Serge will put that flag in its bridge networkstatus document, so bridgedb can make a smarter decision, and so relay-search can visualize it too.

Child Tickets

Change History (2)

comment:1 Changed 8 months ago by nickm

Keywords: needs-proposal added
Milestone: Tor: 0.4.4.x-final
Points: 2

If we can decide what behavior we want here, it should be pretty easy to implement.

comment:2 Changed 4 months ago by nickm

Keywords: 044-deferred added
Milestone: Tor: 0.4.4.x-finalTor: unspecified

Bulk-remove tickets from 0.4.4. Add the 044-deferred label to them.

Note: See TracTickets for help on using tickets.