As the subject says, what I am proposing is likely to be completely naive and
full of bad assumptions and errors, but here it goes anyway. ;) Perhaps my
suggestion will spawn other smarter more creative thinkers than me.
I can't help but wonder (especially after reading the recently published paper
on potential tor performance improvements,) if perhaps a simpler approach to
onion routing should be sought, particularly one that leverages other
technologies more?
It seems to me that tor can be thought of as a coperation between two primary
mechanisms enabled by a third. The first and formost mechanism is that of
3(4?) open NATting routers. The second mechanism is that of several VPNs. The
VPN mechanisms are primarily there to disguise the results of the primary
mechanism. Lastly, the third enabling mechanism is that of a directory server,
an information dissemination mechanism. Naturally, I have to then ask, why
does tor reinvent each of these? Why can it not make use (please excuse my
ignorance if you think that it already does) of current existing technologies
which already provide, probably more efficiently, these mechanisms?
Here is what I have in mind: it seems to me that a simple onion routing relay
could be created by combining a VPN endpoint, a NATting package forwarder, and
a simple application which publishes details about the relay to a directory. A
relay would publish the keys to access its VPN(s) and would forward any packets
which come in via it (them) to their destination (like a simple router) while
performing NAT on them.
Technology wise, I can envision several competing mechanisms to achieve each of
these pieces. Ideally it would be possible to use whatever combination one
chooses for each piece allowing mixed implementations. On the hardware support
side, one could imagine using simple generic home routers to implement the two
primary pieces. Many of them support VPNs now, and, of course, most of them
support NAT. On the software side, a unix or unix like OS which can perform
packet forwarding with NATting at the OS level, while running openvpn in user
space, would be logical. A VM solution such as qemu or virtualbox could also
be used to run this OS (relay) on windows or other OSes. Lastly an OS level
container system such as solaris zones or linux containers (bsd jails?) could
be used to isolate a relay if virtualization is not used and one wishes to use
the relay for other purposes also.
Once a technology has been chosen for VPNs and the NAT router, a tor specific
application would be needed on the relay to publish the relay's info and
perhaps help manage the VPNs and NAT router: setting up VPNs, routes, and
various filtering rules (to implement exit policies.)
The way I envision a client working, (after contacting directory servers and
deciding upon routes,) would be to start by setting up a VPN to an entry relay.
Next, a custom OS route to the middle relay would be setup, this route would
set the entry relay as the gateway. Now the client could open a VPN to the
middle relay (via the OS route and VPN to the entry relay). Once this VPN is
established, another custom OS route will be added: this time the route will
be for the exit node and it will point to the middle node as the gateway. With
a route to the exit node, it should become possible to establish a third VPN to
the exit node. I believe that all of this would additionally require enabling
packet forwarding on the local OS. Finally, either the local IP could be set
to some common default (say 192.168.1.2), or some local NATting rule could be
used to make it look so to each VPN. From there on out, things should take
care of themselves as long as
the proper keys were used, right? ;)
This could potentially mean that both UDP and TCP tunneling would be possible
(subject to any NATting deficiencies). Hopefully this onion transport would be
much more efficient since it would likely be using UDP, but it should be
possible to use a variety of technologies as lons as the VPN solution is fairly
common. With this, advances (and faults) in VPN and packet forwarding
technologies would be automatically available to tor. From a performance
standpoint, tor could focus more on the higher level stuff such as: what is
needed to perform optimum routing, how to deal with various network abuses, etc.
The other major piece I did not touch on yet, is the directory servers. Here
too it seems like tor should attempt to leverage other technologies, and could
perhaps even take advantage of many of them. The most obvious one would be to
use ldap. But, perhaps tor could look to other information sharing networks to
see how it can leverage them: bitorrent, freenet... By creating an API to
layer the tor directory services ontop of other sharing protocols, tor lookups
might be able to benefit from their respective strengths. It may become easier
to disguise that a client is even using tor. It may become easier to disguise
directory servers. It may make directory services more immune to DOS attacks,
imagine storing directory info in freenet. Using bitorrent may alleviate any
future directory server scalability issues. Some of these technologies might
also make setting up darknets more easy.
Lastly, it seems like even hidden services could potentially be easily
supported by adding a NAT whole punching assistant on each tor relay to act as
a potential introduction point.
Again, forgive me, if I glossed over really important details and sound like I
am hand waiving over the hard stuff. I do not expect anyone to jump up and say
"Hallelujah, a great new way to do things!" I realize that even if what I am
suggesting is possible, that it will be fraught with new potential problems.
Nevertheless, I figured that if I simply spark some "out of the box" thinking
it might be valuable. An very naive me even thinks that it might not be
terribly hard to prototype such a solution?
One final thought: if several of these technologies are better leveraged, it
might make it easier for new developers/admins, people familiar with just one
of these pieces, to get more involved with tor development. Currently, I could
not envision myself getting involved developing tor, it is probably way above
my head. However, if tor were less of a monolithic application, but rather a
joining of technologies, it might (might not) be more approachable/hackable?
Thanks for listening,
-Martin
