more circuit design section work

svn:r677

doc/tor-design.tex

@@ -683,11 +683,21 @@ implement long-range dummies).
 
 We will talk more about each of these cell types below.
 
-% should there have been a table here? -RD
+% Nick: should there have been a table here? -RD
 
 \SubSection{Circuits and streams}
 \label{subsec:circuits}
 
+While the original Onion Routing design built one circuit for each stream,
+Tor circuits can be used by many streams. Thus because circuits can
+take several tenths of a second to construct due to crypto and network
+latency, users construct circuits preemptively. Users build a new circuit
+periodically (currently every minute) if the previous one has been used,
+and expire old used circuits that are no longer in use. Thus even very
+active users spend a negligible amount of time and CPU in building
+circuits, but only a limited number of requests can be linked to each
+other by a given exit node.
+
 Users set up circuits incrementally, negotiating a symmetric key with
 each hop one at a time. To create a new circuit, the user (call her
 Alice) sends a \emph{create} cell to the first node in her chosen
@@ -725,15 +735,43 @@ OR and an encrypted $g^x$ for it. That node copies the half-handshake
 into a \emph{create} cell, and passes it to the new OR to extend the
 circuit. When it responds with a \emph{created} cell, the penultimate OR
 copies the payload into a \emph{relay extended} cell and passes it back.
-% please fix my "that OR" pronouns -RD
-
-Once Alice shares a key with each OR on the circuit, she can
-start opening TCP streams over it. 
-
-Describe how circuits work and how relay cells get passed along,
-decrypted etc.  This will include mentioning leaky-pipe circuit
-topology and end-to-end integrity checking.  (Mention tagging.)
-Describe how circuits get built, extended, truncated.
+% Nick: please fix my "that OR" pronouns -RD
+
+Once Alice has established the circuit (so she shares a key with each
+OR on the circuit), she can send relay cells.
+%The stream ID in the relay header indicates to which stream the cell belongs.
+% Nick: should i include the above line?
+Alice can address each relay cell to any of the ORs on the circuit. To
+construct a relay cell destined for a given OR, she iteratively
+encrypts the cell payload (that is, the relay header and payload)
+with the symmetric key of each hop up to that node. Then, at each hop
+down the circuit, the OR decrypts the cell payload and checks whether
+it recognizes the stream ID. A stream ID is recognized either if it
+is an already open stream at that OR, or if it is equal to zero. The
+zero stream ID is treated specially, and is used for control messages,
+e.g.  starting a new stream. If the stream ID is unrecognized, the OR
+sends the relay cell downstream. This \emph{leaky pipe} circuit design
+allows Alice's streams to exit at different ORs, for example to tolerate
+different exit policies, or to keep the ORs from knowing that two streams
+originate at the same person.
+
+To tear down a circuit, Alice sends a destroy control cell. Each OR
+in the circuit receives the destroy cell, closes all open streams on
+that circuit, and passes a new destroy cell forward. But since circuits
+can be built incrementally, they can also be torn down incrementally:
+Alice can send a relay truncate cell to a node along the circuit. That
+node will send a destroy cell forward, and reply with a relay truncated
+acknowledgement. Alice might truncate her circuit so she can extend it
+to different nodes without notifying the first few nodes (or somebody
+observing them) that she is changing her circuit. That is, nodes in the
+middle are not even aware that the circuit was truncated, because the
+relay cells are encrypted. Similarly, if a node on the circuit goes down,
+the adjacent node can send a relay truncated back to Alice. Thus the
+``break a node and see which circuits go down'' attack is weakened.
+
+\SubSection{Tagging attacks on streams}
+
+end-to-end integrity checking.  (Mention tagging.)
 
 \SubSection{Opening and closing streams}
 \label{subsec:tcp}
@@ -745,6 +783,17 @@ close handshake.
 \SubSection{Congestion control and fairness}
 \label{subsec:congestion}
 
+Even with bandwidth throttling, we still need to worry about congestion,
+either accidental or intentional. If a lot of people make circuits into
+the same node, and they all come out through the same connection, then
+that connection may become saturated (be unable to send out cells as
+quickly as it wants to). For example, an adversary can make a 'put'
+request through the onion routing network to a webserver he owns,
+and then refuse to read any of the bytes at the webserver end of the
+circuit. These bottlenecks can propagate back through the entire network,
+mucking up everything.
+
+
 Describe circuit-level and stream-level
 congestion control issues and solutions.
 Describe circuit-level and stream-level fairness issues; cite Marc's
@@ -997,7 +1046,7 @@ When establishing an introduction point, Bob provides the onion router
 with a public ``introduction'' key.  The hash of this public key
 identifies a unique service, and (since Bob is required to sign his
 messages) prevents anybody else from usurping Bob's introduction point
-in the future. Bob uses the same public key when establish the other
+in the future. Bob uses the same public key when establishing the other
 introduction points for that service.
 
 The blob that Alice gives the introduction point includes a hash of Bob's
@@ -1177,8 +1226,17 @@ trick you. similarly, when it rejects you due to exit policy,
 it could give you a bad IP that sends you somewhere else.
 \end{itemize}
 
+we rely on DNS being globally consistent. if people in africa resolve
+IPs differently, then asking to extend a circuit to a certain IP can
+give away your origin.
+
 \item \textbf{Directory attacks}
 \begin{itemize}
+\item knock out a dirserver
+\item knock out half the dirservers
+\item trick user into using different software (with different dirserver
+keys)
+\item OR connects to the dirservers but nowhere else
 \item foo
 \end{itemize}