diff options
| -rw-r--r-- | doc/design-paper/roadmap-future.pdf | bin | 66714 -> 64900 bytes | |||
| -rw-r--r-- | doc/design-paper/roadmap-future.tex | 56 | ||||
| -rw-r--r-- | doc/design-paper/tor-design.bib | 8 |
3 files changed, 60 insertions, 4 deletions
diff --git a/doc/design-paper/roadmap-future.pdf b/doc/design-paper/roadmap-future.pdf Binary files differindex 67923de06..9d83a55dd 100644 --- a/doc/design-paper/roadmap-future.pdf +++ b/doc/design-paper/roadmap-future.pdf diff --git a/doc/design-paper/roadmap-future.tex b/doc/design-paper/roadmap-future.tex index 5c1fa34f6..2b13723d2 100644 --- a/doc/design-paper/roadmap-future.tex +++ b/doc/design-paper/roadmap-future.tex @@ -17,6 +17,7 @@ \title{Tor Development Roadmap: Wishlist for 2008 and beyond} \author{Roger Dingledine \and Nick Mathewson} +\date{} \maketitle \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 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} + +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} \subsection{Reducing directory fetches further} \label{subsec:fewer-descriptor-fetches} diff --git a/doc/design-paper/tor-design.bib b/doc/design-paper/tor-design.bib index 95aba9392..848aa2bae 100644 --- a/doc/design-paper/tor-design.bib +++ b/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}, } +@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: %%% mode: latex %%% TeX-master: "tor-design" |