Re: Naive proposal for a complete tor redesign

[mogulguy@xxxxxxxxx]

--- On Mon, 3/16/09, Martin Fick <mogulguy@xxxxxxxxx> wrote:
> 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.
... 
> 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? ;)

Is there an easily implementable variant of this which would allow the connections between relays to combine all of the connections into a single connection.  With the above suggestion, it seems like each connection between relays would happen on separate ports making it easier to distinguish data streams.  My next thought would be to setup an additional VPN between each relay that is currently speaking to each other which would carry all the VPNs between them.  This would make each relay much more complicated tough, since it would have to detect connections to new relays and setup a VPN to them (and potentially tear them down when no longer used).  Can anyone think of an easier/simpler way?

-Martin