Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
Trac
Trac
  • Project overview
    • Project overview
    • Details
    • Activity
  • Issues 246
    • Issues 246
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • Operations
    • Operations
    • Metrics
    • Incidents
  • Analytics
    • Analytics
    • Value Stream
  • Wiki
    • Wiki
  • Members
    • Members
  • Collapse sidebar
  • Activity
  • Create a new issue
  • Issue Boards

GitLab is used only for code review, issue tracking and project management. Canonical locations for source code are still https://gitweb.torproject.org/ https://git.torproject.org/ and git-rw.torproject.org.

  • Legacy
  • TracTrac
  • Issues
  • #33530

Closed (moved)
Open
Opened Mar 04, 2020 by Roger Dingledine@arma

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

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 (moved) 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.

To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
Tor: unspecified
Milestone
Tor: unspecified
Assign milestone
Time tracking
None
Due date
None
Reference: legacy/trac#33530