Commit fe33ca95 authored by Roger Dingledine's avatar Roger Dingledine
Browse files

two more thoughts to consider for blocking resistance


svn:r7034
parent 75b40e46
......@@ -206,12 +206,37 @@ connectivity, perhaps based on not getting their bridge relays blocked,
\section{Other issues}
\subsection{How many bridge relays should you know about?}
If they're ordinary Tor users on cable modem or DSL, many of them will
disappear periodically. How many bridge relays should a blockee know
about before he's likely to have at least one up at any given point?
The related question is: if the bridge relays change IP addresses
periodically, how often does the blockee need to "check in" in order
to keep from being cut out of the loop?
\subsection{How do we know if a bridge relay has been blocked?}
We need some mechanism for testing reachability from inside the
blocked area. The easiest answer is for certain users inside
the area to sign up as testing relays, and then we can route through
them and see if it works. But we're back to the earlier question
them and see if it works.
First problem is that different network areas block different net masks,
and it will likely be hard to know which users are in which areas. So
if a bridge relay isn't reachable, is that because of a network block
somewhere, because of a problem at the bridge relay, or just a temporary
outage?
Second problem is that if we pick random users to test random relays, the
adversary should sign up users on the inside, and enumerate the relays
we test. But it seems dangerous to just let people come forward and
declare that things are blocked for them, since they could be tricking
us. (This matters even moreso if our reputation system above relies on
whether things get blocked to punish or reward.)
\subsection{Tunneling directory lookups through Tor}
......
Supports Markdown
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment