aboutsummaryrefslogtreecommitdiff
path: root/proposals/125-bridges.txt
diff options
context:
space:
mode:
authorRoger Dingledine <arma@torproject.org>2007-12-06 17:01:16 +0000
committerRoger Dingledine <arma@torproject.org>2007-12-06 17:01:16 +0000
commit415fb5248cbfe327210aa10eaf0831bc0c14562f (patch)
tree8ec9eccc88ac4c6c1b83c908930f5c68c6efda33 /proposals/125-bridges.txt
parent8ce8a41e457385ede04c9f07439ac1842cea7944 (diff)
downloadtorspec-415fb5248cbfe327210aa10eaf0831bc0c14562f.tar.gz
torspec-415fb5248cbfe327210aa10eaf0831bc0c14562f.zip
Bridges now behave like clients with respect to time intervals for
downloading new consensus documents. Bridge users now wait until the end of the interval, so their bridge will be sure to have a new consensus document. svn:r12696
Diffstat (limited to 'proposals/125-bridges.txt')
-rw-r--r--proposals/125-bridges.txt35
1 files changed, 13 insertions, 22 deletions
diff --git a/proposals/125-bridges.txt b/proposals/125-bridges.txt
index 9601de4..a0d51f3 100644
--- a/proposals/125-bridges.txt
+++ b/proposals/125-bridges.txt
@@ -24,11 +24,13 @@ Status: Open
1.1. PublishServerDescriptor
To configure your relay to be a bridge relay, just add
+ BridgeRelay 1
PublishServerDescriptor bridge
to your torrc. This will cause your relay to publish its descriptor
to the bridge authorities rather than to the default authorities.
Alternatively, you can say
+ BridgeRelay 1
PublishServerDescriptor 0
which will cause your relay to not publish anywhere. This could be
useful for private bridges.
@@ -40,28 +42,17 @@ Status: Open
can supply their bridge users with cached copies of all the various
Tor network information.
- Right now (0.2.0.11-alpha) we require that bridges turn their DirPort on
- -- which means both that we answer BEGIN_DIR requests and that we fetch
- and cache directory information in an aggressive way like other servers.
-
- But:
- a) we don't enforce that DirPort is on, since it's not clear how to
- detect if the user meant to be a bridge. So it's easy to set up a bridge
- relay that silently refuses BEGIN_DIR requests and is thus useless.
- b) We don't actually care if they have an open or reachable DirPort. So
- at some point we should separate having an open DirPort from answering
- directory questions. Which leads to:
- c) We need to investigate if there are any anonymity worries with
- answering BEGIN_DIR requests when our DirPort is off. If there aren't,
- we should drop the DirPort requirement.
-
- I claim that we don't open any new attacks by answering BEGIN_DIR
- questions when DirPort is off: it's still a fine question to ask what
- partitioning attacks there are when you can query a Tor client about
- its current directory opinions, but these attacks already exist when
- DirPort is on.
-
- We need to answer this issue in 0.2.0.x.
+ As for Tor 0.2.0.13-alpha, bridges will answer begin_dir questions
+ (and cache dir info they see so the answers will be more useful)
+ whether their DirPort is enabled or not. (After all, we don't care if
+ they have an open or reachable DirPort to answer begin_dir questions.)
+
+ We need to investigate if there are any anonymity worries with answering
+ BEGIN_DIR requests when our DirPort is off. I claim that we don't open
+ any new attacks: it's still a fine question to ask what partitioning
+ attacks there are when you can query a Tor client about its current
+ directory opinions, but these attacks already exist when DirPort is on.
+ We should investigate this in 0.2.1.x.
1.3. Exit policy