|
|
@@ -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?
|
|
|
+
|
Nick Mathewson