From 3fb3822318d4c5998ad93af3ae556c0eb2638663 Mon Sep 17 00:00:00 2001 From: Nick Mathewson Date: Thu, 27 Mar 2008 15:52:44 +0000 Subject: add proposal from Robert Hogan as 133: Incorporate Unreachable ORs into the Tor Network svn:r14213 --- proposals/133-unreachable-ors.txt | 128 ++++++++++++++++++++++++++++++++++++++ 1 file changed, 128 insertions(+) create mode 100644 proposals/133-unreachable-ors.txt (limited to 'proposals/133-unreachable-ors.txt') 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? + -- cgit v1.2.3-54-g00ecf