|  | @@ -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.
 |