mirror of
https://gitlab.torproject.org/tpo/core/tor.git
synced 2024-11-10 21:23:58 +01:00
56 lines
1.7 KiB
Plaintext
56 lines
1.7 KiB
Plaintext
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
|
|
|
|
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
|
|
|