Opened 13 years ago

Last modified 7 years ago

#268 closed enhancement (Deferred)

allow controller to manage circuit extensions

Reported by: goodell Owned by: arma
Priority: Very Low Milestone: post 0.2.0.x
Component: Core Tor/Tor Version:
Severity: Keywords:
Cc: goodell, nickm Actual Points:
Parent ID: Points:
Reviewer: Sponsor:


Tor controllers should have a means of learning more about circuits built through
Tor routers. Specifically, if a Tor controller is connected to a Tor router, it
should be able to subscribe to a new class of events, perhaps "onion" or "router"
events. A Tor router SHOULD then ensure that the controller is informed:

(a) (NEW) when it receives a connection from some other location, in which case
it SHOULD indicate (1) a unique identifier for the circuit, and (2) a ServerID
in the event of an OR connection from another Tor router, and Hostname otherwise.

(b) (REQUEST) when it receives a request to extend an existing circuit to
a successive Tor router, in which case it SHOULD provide (1) the unique identifier
for the circuit, (2) a Hostname (or, if possible, ServerID) of the previous Tor
router in the circuit, and (3) a ServerID for the requested successive Tor router
in the circuit;

(c) (EXTEND) Tor will attempt to extend the circuit to some other router,
in which case it SHOULD provide the same fields as provided for REQUEST.

(d) (SUCCEEDED) The circuit has been successfully extended to some ther router,
in which case it SHOULD provide the same fields as provided for REQUEST.

We also need a new configuration option analogous to _leavestreamsunattached,
specifying whether the controller is to manage circuit extensions or not. Perhaps
we can call it "_leavecircuitsunextended". When set to 0, Tor manages everything
as usual. When set to 1, a circuit received by the Tor router cannot transition
from "REQUEST" to "EXTEND" state without being directed by a new controller
command. The controller command probably does not need any arguments, since
circuits are extended per client source routing, and all that the controller does
is accept or reject the extension.

This feature can be used as a basis for enforcing routing policy.

[Automatically added by flyspray2trac: Operating System: All]

Child Tickets

Change History (5)

comment:1 Changed 13 years ago by nickm

Is there a use case for this other than Blossom? The stated reason of "enforcing routing
policy" is a little premature for any nonBlossomlike context, since right now Tor doesn't
support a non-clique topology on the circuit-building side, and so we shouldn't encourage
servers to do things that clients won't be able to handle.

comment:2 Changed 11 years ago by nickm

Geoff, are you still interested in this? If so, it should probably move to the proposal process, since it'll need
significant design work. If not, it should probably get closed as "won't implement."

comment:3 Changed 11 years ago by nickm

Arma had a great idea. I've added this to the proposal system as


Now I'm closing the bug.

comment:4 Changed 11 years ago by nickm

flyspray2trac: bug closed.

comment:5 Changed 7 years ago by nickm

Component: Tor RelayTor
Note: See TracTickets for help on using tickets.