From c32e19b4ed62ef9609c35d4bd94654f2f9550dbf Mon Sep 17 00:00:00 2001 From: Nick Mathewson Date: Tue, 11 Jul 2006 03:33:16 +0000 Subject: [PATCH] OR_CONN_EVENT_NEW: we should probably handle that , should we not? Especially since 23:26 < phobos> nickm: grep -c "Unrecognized status code 4" tor.log svn:r6752 --- doc/path-spec.txt | 82 +++++++++++++++++++++++++++++++++++++++++++---- src/or/control.c | 1 + 2 files changed, 77 insertions(+), 6 deletions(-) diff --git a/doc/path-spec.txt b/doc/path-spec.txt index 2d48c4001c..50dc519add 100644 --- a/doc/path-spec.txt +++ b/doc/path-spec.txt @@ -19,18 +19,82 @@ list. -NM 1. General operation -* We build some circuits preemptively, and some on-demand. -* We attach greedily, and expire after time. + Tor begins building circuits as soon as it has enough directory + information to do so (see section 5.1 of dir-spec.txt). Some circuits are + built preemptively because we expect to need them later (for user + traffic), and some are build because of immediate need (for user traffic + that no current circuit can handle, for testing the network or our + availability, and so on). + + When a client application creates a new stream (by opening a SOCKS + connection or launching a resolve request), we attach it to an appropriate + open (or in-progress) circuit if one exists, and launch a new circuit only + if no current circuit can handle the request. We rotate circuits over + time to avoid some profiling attacks. + + These processes are described in more detail below. 1b. Types of circuits. + * Stable / Ordinary * Internal / Exit +1c. Terminology + + A "path" is an ordered sequence of nodes, not yet built as a circuit. + + A "clean" circuit is one that has not yet been used for any stream or + rendezvous traffic. + + A "stable" node is one that we believe to have the 'Stable' flag set on + the basis of our current directory information. A "stable" circuit is one + that consists entirely of "stable" nodes. + + A "persistent" stream is one that we predict will require a long uptime. + Currently, Tor does this by examining the stream's target port, and + comparing it to a list of "long-lived" ports. (Default: 21, 22, 706, 1863, + 5050, 5190, 5222, 5223, 6667, 8300, 8888.) + + An exit node "supports" a stream if the stream's target IP is known, and + the stream's IP and target Port are allowed by the exit node's declared + exit policy. A path "supports" a stream if: + * The last node in the path "supports" the stream, and + * If the stream is "persistent," all the nodes in the path are + "stable". + + An exit node "might support" a stream if the stream's target IP is unknown + (because we haven't resolved it yet), and the exit node's declared exit + policy allows some IPs to exit at that port. ??? + 2. Building circuits -* Preemptive building -* On-demand building - * Cannibalizing circuits +2.1. When we build. + + When running as a client, Tor tries to maintain at least 3 clean circuits, + so that new streams can be handled quickly. To increase the likelihood of + success, Tor tries to predict what exit nodes will be useful by choosing + from among nodes that support the ports we have used in the recent past. + + If Tor needs to attach a stream that no current exit circuit can support, + it looks for an existing clean circuit to cannibalize. If we find one, + we try to extend it another hop to an exit node that might support the + stream. [Must be internal???] + + If no circuit exists, or is currently being built, along a path that + might support a stream, we begin building a new circuit that might support + the stream. + + + +2.2. Path selection + + When we bui + + +2.3. Handling failure + +2.4. Tracking "predicted" ports + * Choosing the path first, building second. * Choosing the length of the circuit. * Choosing entries, midpoints, exits. @@ -46,7 +110,6 @@ list. -NM * Timeouts and when Tor autoretries. * What stream-end-reasons are appropriate for retrying. - 4. Rendezvous circuits 5. Guard nodes @@ -341,4 +404,11 @@ more than just let users ask for certain entry nodes. +============================================================ +Some stuff that worries me about entry guards. 2006 Jun, Nickm. +1. It is unlikely for two users to have the same set of entry guards. + +2. Observing a user is sufficient to learn its entry guards. + +3. So, as we move around, we leak our diff --git a/src/or/control.c b/src/or/control.c index 8e19aea94a..48139f3ce6 100644 --- a/src/or/control.c +++ b/src/or/control.c @@ -2735,6 +2735,7 @@ control_event_or_conn_status(connection_t *conn,or_conn_status_event_t tp) case OR_CONN_EVENT_CONNECTED: status = "CONNECTED"; break; case OR_CONN_EVENT_FAILED: status = "FAILED"; break; case OR_CONN_EVENT_CLOSED: status = "CLOSED"; break; + case OR_CONN_EVENT_NEW: status = "NEW"; break; default: log_warn(LD_BUG, "Unrecognized status code %d", (int)tp); return 0;