I'm not sure how much merit this proposal has, or how serious it's problems are. Does anyone have any thoughts on it? Are the problems I've outlined fatal, or is there a problem with it I've missed? I suspect one or the other. -- Filename: xxx-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?
Description: This is a digitally signed message part.