[or-cvs] r17574: {} Add goodell's feature-request 268 as a proposal idea. (tor/trunk/doc/spec/proposals/ideas)

[nickm@xxxxxxxx]

Author: nickm
Date: 2008-12-10 22:40:25 -0500 (Wed, 10 Dec 2008)
New Revision: 17574

Added:
   tor/trunk/doc/spec/proposals/ideas/xxx-controllers-intercept-extends.txt
Log:
Add goodell's feature-request 268 as a proposal idea.

Added: tor/trunk/doc/spec/proposals/ideas/xxx-controllers-intercept-extends.txt
===================================================================
--- tor/trunk/doc/spec/proposals/ideas/xxx-controllers-intercept-extends.txt	                        (rev 0)
+++ tor/trunk/doc/spec/proposals/ideas/xxx-controllers-intercept-extends.txt	2008-12-11 03:40:25 UTC (rev 17574)
@@ -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.


Property changes on: tor/trunk/doc/spec/proposals/ideas/xxx-controllers-intercept-extends.txt
___________________________________________________________________
Name: svn:keywords
   + Author Date Id Revision