-----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 Hello people,
I've been following a number of recent threads with great interest and in the process came up with a number of ideas for changes to the architecture of tor which should be simple to implement and greatly improve both performance and anonymity. 1. Lower the barrier of entry for server nodes by permitting servers to go at any speed down to 1.5kb/s. The reason is that there probably is a lot of tor users on adsl 1 and perhaps even dialup connections who would be willing to contribute bandwidth. Anyone with less than 64kb/s upstream will be negatively affected (most adsl 1 links only have a maximum of 256kbit[32kb/s] upstream and 20kb/s is an unreasonable minimum for such users) 2. Make all clients run a 1.5kb/s server as a minimum by default. The more nodes the better the anonymity. Make this serving behavior mandatory as a minimum contribution to the network for any person using it (see below for an idea of how to eliminate any node not relaying traffic below) 3. Make all nodes into exit nodes - the reason being that the tor circuits are like pipes. At present the architecture makes tor a little bit like a pipe with a big opening on the in side and constricted on the out side. This increases pressure in a pipe bearing fluid, and I think the same goes for the tor network. From a legal perspective more exit nodes means a reduced likelihood of any one node being the primary exit point of an unsavoury type (such as child porn) ending up on the most gracious, at present small population, of exit nodes. Some have suggested encouraging the increase of middleman nodes, this will not help congestion and will further increase the capacity of the network only in the middle and thus further increase the turbulence problem, more than likely to a greater degree than the present asymmetric configuration of the network. 4. Encourage tor users who get attention from law enforcement to demonstrate to them that tor server operators, which, if my suggestion is adopted for making all nodes exit nodes at a minimal bandwidth by default, would greatly increase this exposure of law enforcement to a greater number of individuals who could demonstrate our commitment to abiding by the reasonable laws of a civil society, by setting up a means of specifically reporting accesses to these ip addresses, the times, and volumes of data, would show them that we are not interested in protecting criminals. Exit nodes send unencrypted data. If the data were logged and periodically sent to the local law enforcement they would definitely be more likely to protect our interests. Further to this, those who are unlucky enough to have such traffic exiting from their server could take the opportunity to explain to the police that tor could be used to enable them to have a greater ability to do undercover work online, the ideal situation would be to make it clear to those operators of online resources that tor server operators are not willing to be in any way complicit in their crimes, which would thus also discourage the clients of such despicable server operators from using tor in the first place. multiple vectors here: servers would pretty quickly find out that tor operators are likely to become taps directly to these sites sending the data onwards to law enforcement, and thus would put an anti-tor blocklist on their firewall, users accessing such sites would thus be unable to get at the site if they use tor, they would also find out that the tor network is likely to tap their traffic as it exits to the site, further making this difficult. The only defense they would have against this is to switch their servers to hidden services only and that would make their ip address appear on the directory server database and the chances of them trying the 'if you can't beat them, join them' approach is pretty low because the first thing they will encounter is this hostility of tor users towards their activities, which should deter them, and once a few are deterred from accepting connections from tor, this would quickly percolate out to the users who would use tor and then a negative feeling is generated between them and us and the chances that they will turn around and try and get lost in the crowd would be pretty low for various reasons. 5. Implement a peer-review type system of protecting against bogus and modified tor servers. Servers (in my suggestion, everyone) can check to ensure that any node they connect to actually transmits traffic. Any node which does not transmit traffic can be assumed to be a modified server intended to exploit the network in some way. The node could also report this to the directory server, and an exploiting node would be identifiable by the sheer mass of other nodes reporting its lack of carriage. This will also ensure that no node is not a peer and thus participating in the group solidarity defense against small organised attackers. Think about it as a classic pincer attack in open field warfare. Every node is ready, should a bogus node try to send traffic through them, to turn on that node, refuse to send packets originating from it, and furthermore, reporting the node to the directory as a possible suspect node. Or perhaps the warning systems of social animals would be a better metaphor :/ 6. Load balancing - Instead of only using locality as a criteria for node selection when generating a circuit, also include a flag that servers can raise in their directory profile which indicates they are underutilised (say, at or less than 10% of their bandwidth capacity limit), and have servers select one of these nodes regardless of locality in a circuit so every node is constantly trafficking packets. This would serve two purposes - one, it would mean that the network would more evenly disperse traffic, meaning less chances of a bottleneck occuring, and two, when geographically distant nodes become idle, the use of these less localised nodes introduces a further variance in latency which helps somewhat against the global adversary. This also reduces the likelihood of any one node repeatedly being the exit point of traffic that tor users who would give the network a bad name, dispersing it geographically. And finally, three, eliminating the constant talk of 'cover traffic' which would be unneccessary if the client side were selecting nodes without activity, thus maintaining a constant stream of packets through every node. This would only take up as fast as nodes are updating their directory information, meaning occasionally a node might be silent for 15 minutes or so, but overall this would reduce the deadspots too. Whether these idle nodes should be used for entry, middleman or exit nodes I'm not sure. I'd be inclined to say that there should be no prejudice in this respect. If an exit node cannot send to an ip address for any reason (including the great firewall and smartfilter), the more remote, idle node should respond to an attempt to do this by some kind of 'return to sender' mechanism which could be triggered by some means... I'm not sure exactly how this should be approached, I just thought of it so I thought it should be added. In general this would only occur to an exit node and exit nodes already know how to send packets back in the circuit. If the problem occurs on an entry or middleman node, this is more tricky to deal with, perhaps such nodes could report unreachable (to them) ip addresses in their profile so they are not selected in circuits. The originating server, upon experiencing a timeout of the circuit, could then query the directory for an update of the nodes in the circuit, and it would then receive the information about the unreachable address and establish a new circuit, and for some period of time (perhaps indefinitely) the server will maintain this information on the directory. (by the way, this suggests that it may be a good idea for accesses to the directories, by nodes, be done through a tor circuit, which may already be happening but I don't know). 7. The directory server could have a diff server operating so that it keeps a progressive history of updates to the directory information, so that when a node requests an update of the directory, it only has to be sent the changes since its last update, which will help reduce the load on the directory servers in their sending out of directory information, as well as making the mirroring of the directory less intensive, non-directory servers will only serve up one node info chunk at a time to peers, and directories are only ever queried for their updated information which is provided to them whenever a change occurs in the network. This may already be implemented, I'm not sure how this part of the architecture exactly works. 8. Prioritise the traffic of a user originating connections above those it relays. This would mean that the serving of traffic by the nodes would not so greatly interfere with the usefulness of the client side by a user. The rate of traffic permitted from originating traffic from within a node could be allowed to go to the maximum upstream speed of the connection, meaning the client gets full speed access. While this may at first glance seem like it would make the user's traffic stand out from the server as a spike in traffic, remember that generally, a user is receiving more than they are sending (eg websites), which means the traffic spikes on the in-side as much as on the out-side, usually more, and decreases latency issues, because ack packets are often the biggest bottleneck caused by asymmetric connections. If they cannot be sent then the downstream bandwidth will be limited as well. This modification would also encourage people to actually use tor, because their originating traffic would be of maximum possible responsiveness, meaning latency would be reduced. I hope this post stimulates some discussion about the pros and cons of these ideas and eventually brings us to a more hardened security and anonymity to the tor network, as well as improving performance. glymr -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32) iD8DBQFEaKOcGkOzwaes7JsRA7chAJ45P2MAlD1vXzuE/2y+7qU3RMMzSgCgsj4k j9E0ts/pQUs3FNEs1vpRDaw= =PSMH -----END PGP SIGNATURE-----
