two more thoughts to consider for blocking resistance

svn:r7034

1 files changed, 26 insertions, 1 deletions

diff --git a/doc/design-paper/blocking.tex b/doc/design-paper/blocking.tex
index 14d204d62..b58a0a1df 100644
--- a/doc/design-paper/blocking.tex
+++ b/doc/design-paper/blocking.tex
@@ -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}