Naive proposal for a complete tor redesign

[Martin Fick <mogulguy@xxxxxxxxx>]

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