| 1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556 |
- Filename: 107-uptime-sanity-checking.txt
- Title: Uptime Sanity Checking
- Version: $Revision$
- Last-Modified: $Date$
- Author: Kevin Bauer & Damon McCoy
- Created: 8-March-2007
- Status: Closed
- Implemented-In: 0.2.0.x
- Overview:
- This document describes how to cap the uptime that is used when computing
- which routers are marked as stable such that highly stable routers cannot
- be displaced by malicious routers that report extremely high uptime
- values.
- This is similar to how bandwidth is capped at 1.5MB/s.
- Motivation:
- It has been pointed out that an attacker can displace all stable nodes and
- entry guard nodes by reporting high uptimes. This is an easy fix that will
- prevent highly stable nodes from being displaced.
- Security implications:
- It should decrease the effectiveness of routing attacks that report high
- uptimes while not impacting the normal routing algorithms.
- Specification:
- So we could patch Section 3.1 of dir-spec.txt to say:
- "Stable" -- A router is 'Stable' if it is running, valid, not
- hibernating, and either its uptime is at least the median uptime for
- known running, valid, non-hibernating routers, or its uptime is at
- least 30 days. Routers are never called stable if they are running
- a version of Tor known to drop circuits stupidly. (0.1.1.10-alpha
- through 0.1.1.16-rc are stupid this way.)
- Compatibility:
- There should be no compatibility issues due to uptime capping.
- Implementation:
- Implemented and merged into dir-spec in 0.2.0.0-alpha-dev (r9788).
- Discussion:
- Initially, this proposal set the maximum at 60 days, not 30; the 30 day
- limit and spec wording was suggested by Roger in an or-dev post on 9 March
- 2007.
- This proposal also led to 108-mtbf-based-stability.txt
|
