Some simple changes to the tor architecture I believe may greatly improve it

[glymr <glymr_darkmoon@xxxxxxx>]

-----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-----