mirror of
https://gitlab.torproject.org/tpo/core/tor.git
synced 2024-11-10 13:13:44 +01:00
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
This commit is contained in:
parent
39344fc301
commit
c32e19b4ed
@ -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
|
||||
|
@ -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;
|
||||
|
Loading…
Reference in New Issue
Block a user