Maybe it's a solution in search of a problem, maybe UPnP will sort most of this out, but assuming that the following problem is real and substantial: Problem: Restrictive local/remote firewalls and routers are preventing many willing candidates from becoming OR servers. UPnP can mitigate this problem if it is confined to a DSL router firewall (with UPnP enabled by the user) but it still leaves a substantial chunk of willing servers out there whose ORPort is not available to outside connection attempts. The Tor network is losing out on their bandwidth. At the moment we don't even know how many such 'candidate' servers there are. Possible solution: Tor servers whose ORPort reachability testing fails should: i. enlist themselves with the authorities setting a 'Fallback' flag. This flag indicates that the server is up and running but cannot connect to itself. ii. Open an orconn with an Xth part of the other Tor servers on the network. The management of this orconn will be transferred entirely to the servers at the other end. iii. When building circuits clients will take into account the number of servers it knows about that have a 'Fallback' flag. Whatever proportion this is of the total will determine what proportion of circuits it attempts to build using one of these servers. So if 1/4 of listed servers are flagged fallback it will attempt to build 1 in every 4 circuits with one of these servers at either middleman or exit. (These numbers are hypothetical). iv. After a presumably mathematically predictable number of maximum tries the client will try a combination that works and build a circuit with a fallback server on it. Expected behaviour of 'Fallback' servers: i. Open as many idle orconns with other servers on the network as possible and keep them open until the server is shut down. ii. Always respect other servers requests to shut down the orconn. iii. Always allow themselves to be exit servers if called upon. Expected behaviour of other server towards 'Fallback' servers: i. Only accept orconns from listed 'Fallback' servers. ii. Do not always build client-requested circuits to 'Fallback' servers you have an orconn with. Reject some as unreachable? Halfway house: If we don't know how big the problem actually is, perhaps we should start allowing such servers to at least register their attempt with the authorities in some way, perhaps just by implementing step i under 'Possible Solution'. Questions I don't know the answers to: i. How many other servers a 'Fallback' server should connect to in order to allow a client successfully include it in a circuit without trying an unreasonable amount of times. ii. How a client proportions the number of 'fallback' servers listed to the number of circuits it attempts to build with them. iii. What kind of critical mass of fallback servers is required for the thing to work. Major objections: i. Thousands, millions of idle orconns! Uugh! It's an ugly thought I admit, but they're pretty cheap as far as I know. Would a server have any actual problem handling them? ii. [insert major anonymity problem here] This isn't the result of days of solemn reflection so feel free to kick me out of the park on it.
Attachment:
signature.asc
Description: This is a digitally signed message part.