add proposal from Robert Hogan as 133: Incorporate Unreachable ORs into the Tor Network

svn:r14213

1 files changed, 128 insertions, 0 deletions

diff --git a/proposals/133-unreachable-ors.txt b/proposals/133-unreachable-ors.txt
new file mode 100644
index 0000000..4127161
--- /dev/null
+++ b/proposals/133-unreachable-ors.txt
@@ -0,0 +1,128 @@
+Filename: 133-unreachable-ORs.txt
+Title: Incorporate Unreachable ORs into the Tor Network
+Author: Robert Hogan
+Created: 2008-03-08
+Status: Draft
+
+Overview:
+
+  Propose a scheme for harnessing the bandwidth of ORs who cannot currently
+  participate in the Tor network because they can only make outbound
+  TCP connections.
+
+Motivation: 
+
+  Restrictive local and remote firewalls are preventing many willing
+  candidates from becoming ORs on the Tor network.These
+  ORs have a casual interest in joining the network but their operator is not
+  sufficiently motivated or adept to complete the necessary router or firewall
+  configuration. The Tor network is losing out on their bandwidth. At the
+  moment we don't even know how many such 'candidate' ORs there are.
+
+
+Objective:
+
+  1. Establish how many ORs are unable to qualify for publication because
+     they cannot establish that their ORPort is reachable.
+
+  2. Devise a method for making such ORs available to clients for circuit
+     building without prejudicing their anonymity.
+
+Proposal:
+
+  ORs whose ORPort reachability testing fails a specified number of
+  consecutive times should:
+  1. Enlist themselves with the authorities setting a 'Fallback' flag. This
+      flag indicates that the OR is up and running but cannot connect to
+      itself.
+  2. Open an orconn with all ORs whose fingerprint begins with the same
+      byte as their own. The management of this orconn will be transferred
+      entirely to the OR at the other end.
+  2. The fallback OR should update it's router status to contain the
+      'Running' flag if it has managed to open an orconn with 3/4 of the ORs
+      with an FP beginning with the same byte as its own.
+
+  Tor ORs who are contacted by fallback ORs requesting an orconn should:
+   1. Accept the orconn until they have reached a defined limit of orconn
+      connections with fallback ORs.
+   2. Should only accept such orconn requests from listed fallback ORs who
+      have an FP beginning with the same byte as its own.
+
+  Tor clients can include fallback ORs in the network by doing the
+  following:
+   1. When building a circuit, observe the fingerprint of each node they
+      wish to connect to.
+   2. When randomly selecting a node from the set of all eligible nodes,
+      add all published, running fallback nodes to the set where the first
+      byte of the fingerprint matches the previous node in the circuit.
+
+Anonymity Implications:
+
+  At least some, and possibly all, nodes on the network will have a set
+  of nodes that only they and a few others can build circuits on.
+
+    1. This means that fallback ORs might be unsuitable for use as middlemen
+       nodes, because if the exit node is the attacker it knows that the
+       number of nodes that could be the entry guard in the circuit is
+       reduced to roughly 1/256th of the network, or worse 1/256th of all
+       nodes listed as Guards. For the same reason, fallback nodes would
+       appear to be unsuitable for two-hop circuits.
+
+    2. This is not a problem if fallback ORs are always exit nodes. If
+       the fallback OR is an attacker it will not be able to reduce the
+       set of possible nodes for the entry guard any further than a normal,
+       published OR.
+
+Possible Attacks/Open Issues:
+
+  1. Gaming Node Selection
+    Does running a fallback OR customized for a specific set of published ORs
+    improve an attacker's chances of seeing traffic from that set of published
+    ORs? Would such a strategy be any more effective than running published
+    ORs with other 'attractive' properties?
+
+  2. DOS Attack
+    An attacker could prevent all other legitimate fallback ORs with a
+    given byte-1 in their FP from functioning by running 20 or 30 fallback ORs
+    and monopolizing all available fallback slots on the published ORs. 
+    This same attacker would then be in a position to monopolize all the
+    traffic of the fallback ORs on that byte-1 network segment. I'm not sure
+    what this would allow such an attacker to do.
+
+  4. Circuit-Sniffing
+    An observer watching exit traffic from a fallback server will know that the
+    previous node in the circuit is one of a  very small, identifiable
+    subset of the total ORs in the network. To establish the full path of the
+    circuit they would only have to watch the exit traffic from the fallback
+    OR and all the traffic from the 20 or 30 ORs it is likely to be connected
+    to. This means it is substantially easier to establish all members of a
+    circuit which has a fallback OR as an exit (sniff and analyse 10-50 (i.e.
+    1/256 varying) + 1 ORs) rather than a normal published OR (sniff all 2560
+    or so ORs on the network). The same mechanism that allows the client to
+    expect a specific fallback OR to be available from a specific published OR
+    allows an attacker to prepare his ground.
+
+    Mitigant:
+    In terms of the resources and access required to monitor 2000 to 3000
+    nodes, the effort of the adversary is not significantly diminished when he
+    is only interested in 20 or 30. It is hard to see how an adversary who can
+    obtain access to a randomly selected portion of the Tor network would face
+    any new or qualitatively different obstacles in attempting to access much
+    of the rest of it.
+
+
+Implementation Issues:
+
+  The number of ORs this proposal would add to the Tor network is not known.
+  This is because there is no mechanism at present for recording unsuccessful
+  attempts to become an OR. If the proposal is considered promising it may be
+  worthwhile to issue an alpha series release where candidate ORs post a
+  primitive fallback descriptor to the authority directories. This fallback
+  descriptor would not contain any other flag that would make it eligible for
+  selection by clients. It would act solely as a means of sizing the number of
+  Tor instances that try and fail to become ORs.
+
+  The upper limit on the number of orconns from fallback ORs a normal,
+  published OR should be willing to accept is an open question. Is one
+  hundred, mostly idle, such orconns too onerous?
+