[or-cvs] r9951: TODO file updates w/ reputation brainstorming plus some thin (torflow/trunk)

[mikeperry@xxxxxxxx]

Author: mikeperry
Date: 2007-04-14 01:00:21 -0400 (Sat, 14 Apr 2007)
New Revision: 9951

Modified:
   torflow/trunk/TODO
   torflow/trunk/metatroller.py
   torflow/trunk/nodemon.py
Log:
TODO file updates w/ reputation brainstorming plus some thing arma wants to
help bootstrapping of non-dirport routers.



Modified: torflow/trunk/TODO
===================================================================
--- torflow/trunk/TODO	2007-04-14 01:12:17 UTC (rev 9950)
+++ torflow/trunk/TODO	2007-04-14 05:00:21 UTC (rev 9951)
@@ -68,11 +68,29 @@
 - Design Reputation System (not for GSoC)
   - Emit some kind of penalty multiplier based on circuit/stream failure rate
     and the ratio of directory "observed" bandwidth vs avg stream bandwidth
-    - Add keyword to directory for clients to use instead of observed
-      bandwidth for routing decisions
-      - Make sure scanners don't listen to this keyword to avoid 
-        "Creeping Death" 
-    - Queue lengths from the node monitor can also figure into this penalty
-      multiplier
+	- Add keyword to directory for clients to use instead of observed
+	  bandwidth for routing decisions
+	  - Make sure scanners don't listen to this keyword to avoid "Creeping
+	    Death" 
+	- Queue lengths from the node monitor can also figure into this penalty
+	  multiplier
   - Figure out interface to report this and also BadExit determinations
-    - Probably involves voting among many scanners
+	- Probably involves voting among many scanners
+  - Justify this is worthwhile, sane, and at least as resistant as the current
+    Tor network to attack
+	- Does a reputation system make it easier for an adversary w/ X% of the
+	  network to influence it?
+	  - Preliminary: http://archives.seul.org/or/dev/Nov-2006/msg00004.html
+      - Sybil attacks
+	- What about clients that ignore the reputations? Can their behavior game
+	  the system, or are they just behaving suboptimally?
+      - First impressions: meh; suboptimal
+	- Does changings in ratings leak any information about clients? 
+	  - Does it influence their paths in predictable ways in a greater degree
+	    than bandwidth ranking already does?
+    - What about detecting the scan and giving better service? Time of day, 
+      source IP, exit IP?
+
+- Stopgap for bootstrapping
+  - push traffic through the 0.1.1.x with 0 dirport and earlier servers 
+    that claim less than 20KB traffic

Modified: torflow/trunk/metatroller.py
===================================================================
--- torflow/trunk/metatroller.py	2007-04-14 01:12:17 UTC (rev 9950)
+++ torflow/trunk/metatroller.py	2007-04-14 05:00:21 UTC (rev 9951)
@@ -24,7 +24,7 @@
 
 # TODO: Move these to config file
 control_host = "127.0.0.1"
-control_port = 9061
+control_port = 9051
 meta_host = "127.0.0.1"
 meta_port = 9052
 max_detach = 3
@@ -33,8 +33,8 @@
 # Use PathBuilder.schedule_selmgr instead.
 # (Modifying the arguments here is OK)
 __selmgr = PathSupport.SelectionManager(
-      pathlen=3,
-      order_exits=False,
+      pathlen=2,
+      order_exits=True,
       percent_fast=100,
       percent_skip=0,
       min_bw=1024,
@@ -709,6 +709,7 @@
         s.write("510 Integer expected\r\n")
     elif command == "SETEXIT":
       if arg:
+        # XXX: This is broken.
         # FIXME: Hrmm.. if teh user is a dumbass this will fail silently
         def notlambda(sm): sm.exit_name=arg
         h.schedule_selmgr(notlambda)

Modified: torflow/trunk/nodemon.py
===================================================================
--- torflow/trunk/nodemon.py	2007-04-14 01:12:17 UTC (rev 9950)
+++ torflow/trunk/nodemon.py	2007-04-14 05:00:21 UTC (rev 9951)
@@ -10,7 +10,7 @@
 import socket
 import traceback
 import re
-from TorUtil import *
+from TorCtl.TorUtil import *
 import sched, time
 import thread