commit for nick

i'm now only working on 8-9


svn:r754

1 files changed, 12 insertions, 35 deletions

diff --git a/doc/tor-design.tex b/doc/tor-design.tex
index f96c76275..e7008e946 100644
--- a/doc/tor-design.tex
+++ b/doc/tor-design.tex
@@ -459,10 +459,6 @@ SSH.
 Similarly, Tor does not currently integrate
 tunneling for non-stream-based protocols like UDP; this too must be
 provided by an external service.
-% Actually, tunneling udp over tcp is probably horrible for some apps.
-% Should this get its own non-goal bulletpoint? The motivation for
-% non-goal-ness would be burden on clients / portability. -RD
-% No, leave it as is. -RD
 
 \textbf{Not steganographic:} Tor does not try to conceal which users are
 sending or receiving communications; it only tries to conceal with whom
@@ -534,8 +530,6 @@ establish paths (called \emph{virtual circuits}) across the network,
 and handle connections from user applications.  These onion proxies accept
 TCP streams and multiplex them across the virtual circuit. The onion
 router on the other side 
-% I don't mean other side, I mean wherever it is on the circuit. But
-% don't want to introduce complexity this early? Hm. -RD
 of the circuit connects to the destinations of
 the TCP streams and relays data.
 
@@ -558,6 +552,7 @@ built, extended, truncated, and destroyed. Section~\ref{subsec:tcp}
 describes how TCP streams are routed through the network, and finally
 Section~\ref{subsec:congestion} talks about congestion control and
 fairness issues.
+% NICK
 % XXX \ref{subsec:integrity-checking} is missing
 % XXX \ref{xubsec:rate-limit is missing.
 
@@ -708,8 +703,6 @@ corresponds to an open stream at this OR for the circuit, or because
 it is equal to the control streamID (zero).  If the OR recognizes the
 streamID, it accepts the relay cell and processes it as described
 below.  Otherwise, 
-%the relay cell must be intended for another OR on
-%the circuit.  In this case, 
 the OR looks up the circID and OR for the
 next step in the circuit, replaces the circID as appropriate, and
 sends the decrypted relay cell to the next OR.  (If the OR at the end
@@ -756,9 +749,6 @@ truncate} cell to a single OR on the circuit. That node then sends a
 \emph{relay truncated} cell. Alice can then extend the circuit to
 different nodes, all without signaling to the intermediate nodes (or
 somebody observing them) that she has changed her circuit.
-%---because
-%nodes in the middle of a circuit see only the encrypted relay cells,
-%they are not even aware that the circuit has been truncated.
 Similarly, if a node on the circuit goes down, the adjacent
 node can send a \emph{relay truncated} cell back to Alice.  Thus the
 ``break a node and see which circuits go down'' attack
@@ -877,13 +867,6 @@ receive a bad hash.
 Volunteers are generally more willing to run services that can limit
 their bandwidth usage. To accommodate them, Tor servers use a
 token bucket approach \cite{tannenbaum96} to 
-%limit the number of bytes they receive.
-%Tokens are added to the bucket each second; when the bucket is
-%full, new tokens are discarded. Each token represents permission to
-%accept one byte from the network---to accept a byte, the connection
-%must remove a token from the bucket. Thus if the bucket is empty, that
-%connection must wait until more tokens arrive. The number of tokens we
-%add 
 enforce a long-term average rate of incoming bytes, while still
 permitting short-term bursts above the allowed bandwidth. Current bucket
 sizes are set to ten seconds' worth of traffic.
@@ -899,20 +882,10 @@ sizes are set to ten seconds' worth of traffic.
 Because the Tor protocol generates roughly the same number of outgoing
 bytes as incoming bytes, it is sufficient in practice to limit only
 incoming bytes.
-% Is it?  Fun attack: I send you lots of 1-byte-at-a-time TCP segments.
-% In response, you send lots of 256 byte cells.  Can I use this to 
-% make you exceed your outgoing bandwidth limit by a factor of 256? -NM
-% Can we resolve this by, when reading from edge connections, rounding up
-% the bytes read (wrt buckets) to the nearest multiple of 256? -RD
-% How's this? -NM
 With TCP streams, however, the correspondence is not one-to-one:
 relaying a single incoming byte can require an entire 256-byte cell.
 (We can't just wait for more bytes, because the local application may
-be waiting for a reply.)
-%(If we waited too long for more bytes to fill the cell, we might stall
-%the protocol while the local application waits for a response to the
-%byte we never deliver.)
-Therefore, we treat this case as if the entire
+be waiting for a reply.) Therefore, we treat this case as if the entire
 cell size had been read, regardless of the fullness of the cell.
 
 Further, inspired by Rennhard et al's design in \cite{anonnet}, a
@@ -1327,7 +1300,6 @@ to selected users for consulting the DHT\@. All of these approaches
 have the advantage of limiting the damage that can be done even if
 some of the selected high-priority users collude in the DoS\@.
 
-
 \SubSection{Integration with user applications}
 
 Bob configures his onion proxy to know the local IP address and port of his
@@ -1453,10 +1425,12 @@ current evidence of their practicality.}
 
 \subsubsection*{Active attacks}
 
-\emph{Compromise keys.} An attacker who learns the TLS session key can see
-the (still encrypted) relay cells on that circuit; learning the circuit
+\emph{Compromise keys.} An attacker who learns the TLS session key can
+see control cells and encrypted relay cells on every circuit on that
+connection; learning a circuit
 session key lets him unwrap one layer of the encryption. An attacker
-who learns an OR's TLS private key can impersonate that OR, but he must
+who learns an OR's TLS private key can impersonate that OR for the TLS
+key's lifetime, but he must
 also learn the onion key to decrypt \emph{create} cells (and because of
 perfect forward secrecy, he cannot hijack already established circuits
 without also compromising their session keys). Periodic key rotation
@@ -1866,12 +1840,15 @@ issues remaining to be ironed out. In particular:
 deployability has led us to adopt a clique topology, a
 semi-centralized model for directories and trusts, and a
 full-network-visibility model for client knowledge.  None of these
-properties will scale to more than a few hundred servers, at most.
+properties will scale to more than a few hundred servers.
 Promising approaches to better scalability exist (see
 Section~\ref{sec:maintaining-anonymity}), but more deployment
 experience would be helpful in learning the relative importance of
 these bottlenecks.
 
+\emph{Incentives:} Volunteers may want to run nodes for publicity
+or better anonymity \cite{econymics}. 
+
 \emph{Cover traffic:} Currently we avoid cover traffic because
 whereas its costs in performance and bandwidth are clear, and because its
 security benefits are not well understood. With more research
@@ -1902,7 +1879,7 @@ becomes more widely deployed, more people will examine its
 specification.
 
 \emph{Multisystem interoperability:} We are currently working with the
-designers of MorphMix to make the common elements of our two systems
+designer of MorphMix to make the common elements of our two systems
 share a common specification and implementation. So far, this seems
 to be relatively straightforward.  Interoperability will allow testing
 and direct comparison of the two designs for trust and scalability.