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