|  | @@ -35,7 +35,7 @@ relay. Only authorized users should be able to communicate with the private
 | 
	
		
			
				|  |  |  bridge. This should be done with Tor and if possible without the help of the
 | 
	
		
			
				|  |  |  firewall. It should be possible for a Tor user to enter a secret key into
 | 
	
		
			
				|  |  |  Tor or optionally Vidalia on a per bridge basis. This secret key should be
 | 
	
		
			
				|  |  | -used
 | 
	
		
			
				|  |  | +used to authenticate the bridge user to the private bridge.
 | 
	
		
			
				|  |  |  
 | 
	
		
			
				|  |  |  1.x Issues with low ports and bind() for ORPort
 | 
	
		
			
				|  |  |  
 | 
	
	
		
			
				|  | @@ -71,6 +71,23 @@ will not trigger a response from Tor. With base32 encoding it should be
 | 
	
		
			
				|  |  |  possible to encode SPA as valid DNS requests. This should allow use of the
 | 
	
		
			
				|  |  |  public DNS infrastructure for authorization requests if desired.
 | 
	
		
			
				|  |  |  
 | 
	
		
			
				|  |  | +2.x Ghetto firewalling with opportunistic connection closing
 | 
	
		
			
				|  |  | +
 | 
	
		
			
				|  |  | +Until a user has authenticated with Tor, Tor only has a UDP listener. This
 | 
	
		
			
				|  |  | +listener should never send data in response, it should only open an ORPort
 | 
	
		
			
				|  |  | +when a user has successfully authenticated. After a user has authenticated
 | 
	
		
			
				|  |  | +with Tor to open an ORPort, only users who have authenticated will be able
 | 
	
		
			
				|  |  | +to use it. All other users as identified by their ip address will have their
 | 
	
		
			
				|  |  | +connection closed before any data is sent or received. This should be
 | 
	
		
			
				|  |  | +accomplished with an access policy. By default, the access policy should block
 | 
	
		
			
				|  |  | +all access to the ORPort.
 | 
	
		
			
				|  |  | +
 | 
	
		
			
				|  |  | +2.x Timing and reset of access policies
 | 
	
		
			
				|  |  | +
 | 
	
		
			
				|  |  | +Access to the ORPort is sensitive. The bridge should remove any exceptions
 | 
	
		
			
				|  |  | +to its access policy regularly when the ORPort is unused. Valid users should
 | 
	
		
			
				|  |  | +reauthenticate if they do not use the ORPort within a given time frame.
 | 
	
		
			
				|  |  | +
 | 
	
		
			
				|  |  |  2.x Additional considerations
 | 
	
		
			
				|  |  |  
 | 
	
		
			
				|  |  |  There are many. A format of the packet and the crypto involved is a good start.
 |