|  | @@ -0,0 +1,76 @@
 | 
	
		
			
				|  |  | +Filename: 120-suicide-descriptors.txt
 | 
	
		
			
				|  |  | +Title: Suicide descriptors when Tor servers stop
 | 
	
		
			
				|  |  | +Version: $Revision$
 | 
	
		
			
				|  |  | +Last-Modified: $Date$
 | 
	
		
			
				|  |  | +Author: Roger Dingledine
 | 
	
		
			
				|  |  | +Created: 15-Aug-2007
 | 
	
		
			
				|  |  | +Status: Open
 | 
	
		
			
				|  |  | +
 | 
	
		
			
				|  |  | +Overview:
 | 
	
		
			
				|  |  | +
 | 
	
		
			
				|  |  | +  Tor servers should publish a last descriptor whenever they shut down,
 | 
	
		
			
				|  |  | +  to let others know that they are no longer offering service.
 | 
	
		
			
				|  |  | +
 | 
	
		
			
				|  |  | +The Problem:
 | 
	
		
			
				|  |  | +
 | 
	
		
			
				|  |  | +  The main reason for this is in reaction to Internet services that want
 | 
	
		
			
				|  |  | +  to treat connections from the Tor network differently. Right now,
 | 
	
		
			
				|  |  | +  if a user experiments with turning on the "relay" functionality, he
 | 
	
		
			
				|  |  | +  is punished by being locked out of some websites, some IRC networks,
 | 
	
		
			
				|  |  | +  etc --- and this lockout persists for several days even after he turns
 | 
	
		
			
				|  |  | +  the server off.
 | 
	
		
			
				|  |  | +
 | 
	
		
			
				|  |  | +Design:
 | 
	
		
			
				|  |  | +
 | 
	
		
			
				|  |  | +  During the "slow shutdown" period if exiting, or shortly after the
 | 
	
		
			
				|  |  | +  user sets his ORPort back to 0 if not exiting, Tor should publish a
 | 
	
		
			
				|  |  | +  final descriptor with the following characteristics:
 | 
	
		
			
				|  |  | +
 | 
	
		
			
				|  |  | +  1) Exit policy is listed as "reject *:*"
 | 
	
		
			
				|  |  | +  2) It includes a new entry called "opt shutdown 1"
 | 
	
		
			
				|  |  | +
 | 
	
		
			
				|  |  | +  The first step is so current blacklists will no longer list this node
 | 
	
		
			
				|  |  | +  as exiting to whatever the service is.
 | 
	
		
			
				|  |  | +
 | 
	
		
			
				|  |  | +  The second step is so directory authorities can avoid wasting time
 | 
	
		
			
				|  |  | +  doing reachability testing. Authorities should automatically not list
 | 
	
		
			
				|  |  | +  as Running any router whose latest descriptor says it shut down.
 | 
	
		
			
				|  |  | +
 | 
	
		
			
				|  |  | +  [I originally had in mind a third step --- Advertised bandwidth capacity
 | 
	
		
			
				|  |  | +  is listed as "0" --- so current Tor clients will skip over this node
 | 
	
		
			
				|  |  | +  when building most circuits. But since clients won't fetch descriptors
 | 
	
		
			
				|  |  | +  from nodes not listed as Running, this step seems pointless. -RD]
 | 
	
		
			
				|  |  | +
 | 
	
		
			
				|  |  | +Spec:
 | 
	
		
			
				|  |  | +
 | 
	
		
			
				|  |  | +  TBD but should be pretty straightforward.
 | 
	
		
			
				|  |  | +
 | 
	
		
			
				|  |  | +Security issues:
 | 
	
		
			
				|  |  | +
 | 
	
		
			
				|  |  | +  Now external people can learn exactly when a node stopped offering
 | 
	
		
			
				|  |  | +  relay service. How bad is this? I can see a few minor attacks based
 | 
	
		
			
				|  |  | +  on this knowledge, but on the other hand as it is we don't really take
 | 
	
		
			
				|  |  | +  any steps to keep this information secret.
 | 
	
		
			
				|  |  | +
 | 
	
		
			
				|  |  | +Overhead issues:
 | 
	
		
			
				|  |  | +
 | 
	
		
			
				|  |  | +  We are creating more descriptors that want to be remembered. However,
 | 
	
		
			
				|  |  | +  since the router won't be marked as Running, ordinary clients won't
 | 
	
		
			
				|  |  | +  fetch the suicide descriptors. Caches will, though. I hope this is ok.
 | 
	
		
			
				|  |  | +
 | 
	
		
			
				|  |  | +Implementation:
 | 
	
		
			
				|  |  | +
 | 
	
		
			
				|  |  | +  To make things easy, we should publish the suicide descriptor only
 | 
	
		
			
				|  |  | +  on controlled shutdown (SIGINT as opposed to SIGTERM). That would
 | 
	
		
			
				|  |  | +  leave enough time for publishing that we probably wouldn't need any
 | 
	
		
			
				|  |  | +  extra synchronization code.
 | 
	
		
			
				|  |  | +
 | 
	
		
			
				|  |  | +  If that turns out to be too unintuitive for users, I could imagine doing
 | 
	
		
			
				|  |  | +  it on SIGTERMs too, and just delaying exit until we had successfully
 | 
	
		
			
				|  |  | +  published to at least one authority, at which point we'd hope that it
 | 
	
		
			
				|  |  | +  propagated from there.
 | 
	
		
			
				|  |  | +
 | 
	
		
			
				|  |  | +Acknowledgements:
 | 
	
		
			
				|  |  | +
 | 
	
		
			
				|  |  | +  tup suggested this idea.
 | 
	
		
			
				|  |  | +
 |