mirrors/tor
1
0
Fork 0
mirror of https://gitlab.torproject.org/tpo/core/tor.git synced 2025-02-23 06:35:28 +01:00
Code Issues Projects Releases Wiki Activity

Add goodell's feature-request 268 as a proposal idea.

Browse source 
svn:r17574
This commit is contained in:
Nick Mathewson 2008-12-11 03:40:25 +00:00
parent 9e8f8223db
commit cd0d28027a
1 changed files with 44 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

44
doc/spec/proposals/ideas/xxx-controllers-intercept-extends.txt Normal file
View file

@ -0,0 +1,44 @@
Author: Geoff Goodell
Title: Allow controller to manage circuit extensions
Date: 12 March 2006
History:
This was once bug 268. Moving it into the proposal system for posterity.
Test:
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.