Browse Source

more details on 'everybody can be a relay'

svn:r13684
Roger Dingledine 17 years ago
parent
commit
c3ac638971

BIN
doc/design-paper/roadmap-future.pdf


+ 52 - 4
doc/design-paper/roadmap-future.tex

@@ -17,6 +17,7 @@
 
 
 \title{Tor Development Roadmap: Wishlist for 2008 and beyond}
 \title{Tor Development Roadmap: Wishlist for 2008 and beyond}
 \author{Roger Dingledine \and Nick Mathewson}
 \author{Roger Dingledine \and Nick Mathewson}
+\date{}
 
 
 \maketitle
 \maketitle
 \pagestyle{plain}
 \pagestyle{plain}
@@ -138,11 +139,58 @@ bytes.  But a) we could use some more intelligent heuristics, and b)
 this leaks information to an active attacker about when local traffic
 this leaks information to an active attacker about when local traffic
 was sent/received.
 was sent/received.
 
 
-\subsection{Tolerate absurdly wrong clocks, even for servers}
-\subsection{First a bridge, then a public relay?}
-Metrics for deciding when you're fast enough and stable enough
-      to opt to switch from being a bridge relay to a public relay.
+\subsection{Tolerate absurdly wrong clocks, even for relays}
+
+Many of our users are on Windows, running with a clock several days or
+even several years off from reality. Some of them are even intentionally
+in this state so they can run software that will only run in the past.
+
+Before Tor 0.1.1.x, Tor clients would still function if their clock was
+wildly off --- they simply got a copy of the directory and believed it.
+Starting in Tor 0.1.2.x, the clients only believed networkstatus documents
+that they believed to be recent, so clients with extremely wrong clocks
+stopped working. (This bug has been an unending source of vague and
+confusing bug reports.)
+
+Step one is for clients to recognize when all the directory material
+they're fetching has roughly the same offset from their current time,
+and then automatically correct for it.
+
+Once that's working well, clients who opt to become bridge relays should
+be able to use the same approach to serve accurate directory information
+to their bridge users.
+
 \subsection{Risks from being a relay}
 \subsection{Risks from being a relay}
+
+Three different research
+papers~\cite{back01,clog-the-queue,attack-tor-oak05} describe ways to
+identify the nodes in a circuit by running traffic through candidate nodes
+and looking for dips in the traffic while the circuit is active. These
+clogging attacks are not that scary in the Tor context so long as relays
+are never clients too. But if we're trying to encourage more clients to
+turn on relay functionality too (whether as bridge relays or as normal
+relays), then we need to understand this threat better and learn how to
+mitigate it.
+
+One promising research direction is to investigate the RelayBandwidthRate
+feature that lets Tor rate limit relayed traffic differently from local
+traffic. Since the attacker's ``clogging'' traffic is not in the same
+bandwidth class as the traffic initiated by the user, it may be harder
+to detect interference. Or it may not be.
+
+\subsection{First a bridge, then a public relay?}
+
+Once enough of the items in this section are done, I want all clients
+to start out automatically detecting their reachability and opting
+to be bridge relays.
+
+Then if they realize they have enough consistency and bandwidth, they
+should automatically upgrade to being non-exit relays.
+
+What metrics should we use for deciding when we're fast enough
+and stable enough to switch? Given that the list of bridge relays needs
+to be kept secret, it doesn't make much sense to switch back.
+
 \section{Tor on low resources / slow links}
 \section{Tor on low resources / slow links}
 \subsection{Reducing directory fetches further}
 \subsection{Reducing directory fetches further}
 \label{subsec:fewer-descriptor-fetches}
 \label{subsec:fewer-descriptor-fetches}

+ 8 - 0
doc/design-paper/tor-design.bib

@@ -1435,6 +1435,14 @@ Stefan Katzenbeisser and Fernando P\'{e}rez-Gonz\'{a}lez},
   publisher = {Springer-Verlag, LNCS 2578},
   publisher = {Springer-Verlag, LNCS 2578},
 }
 }
 
 
+@inproceedings{clog-the-queue,
+  title = {Don't Clog the Queue: Circuit Clogging and Mitigation in {P2P} anonymity schemes},
+  author = {Jon McLachlan and Nicholas Hopper},
+  booktitle = {Proceedings of Financial Cryptography (FC '08)},
+  year = {2008},
+  month = {January},
+}
+
 %%% Local Variables:
 %%% Local Variables:
 %%% mode: latex
 %%% mode: latex
 %%% TeX-master: "tor-design"
 %%% TeX-master: "tor-design"