udp transport PoC

[Camilo Viecco]

Hi Nick

Thanks for your reply. I will try to answer your comments inline

Nick Mathewson wrote:
>
> Hi, Camilo!  This is interesting stuff.  We definitely need to move to
> a UDP transport at some point, and it's good to try out various
> approaches before we can get them onto the main network.  
>
> One question I got looking at your codebase for a few minutes: Do you
> have a protocol specification for this anywhere (that is, something
> like tor-spec.txt)?
There is no documentation for the protocol. I was more worried about 
making sure
the parts worked well together. That is this is a 'running specification'.
However, the 'philosophy' of the protocol is of a state machine.
Each packet that arrives can change the state of the machine (or create 
new state)
and depending on the state generate a new packet. Also, every second 
triggers
attempts to purge old link connections, circuits and streams.
There are no network buffers and packets currently are handled in a 'hot 
potato'
fashion, that is new packets are transmitted as soon as possible.
The redesign part is the moving of the socks server to the exit node.
I made my own socks4/4a server as other socks servers on the web seemed 
to have
performance problems (latency) when many connections where multiplexed over
high bandwidth delay product networks (antinat and socksd).
(maybe I did not looked hard enough).
>> I really like tor but had became disillusioned by its network
>> performance (or lack of). Thus,
>> as part of my graduate work I have designed a modification of the
>> transport mechanism in tor
>> to use tunnel tcp connections over ucp. That is, socks aware
>> applications open tcp streams
>> to a socks server running at the tor exit node.> Tor does not transport
>> tcp streams
>> but transports the tcp packets (build by the os) in the form of
>> encapsulated autonomous circuit cells over udp.
>
> I really worry about TCP stack fingerprinting and linking with this
> approach, especially if the exit nodes have freedom what they send
> back to the clients.  I guess that it doesn't matter much for a proof
> of concept of the routing algorithm, but it's a problem that will need
> to be solved before a solution can get deployed in Tor.
Actually even in the current codebase, exit nodes cannot send arbitrary 
data to the clients. This is because clients drops packets from 
unrecognized streams; and for streams created at the client node, the 
protocol and port numbers are fixed when each stream is created 
(actually there should be an exeption for ICMP dst unreachable 
messages). However, in practice, my protocol would still be vulnerable 
to clients binding to ports/protocols combination recently used by an 
output stream where the or code has not yet timeouted(?) the stream 
(stream timeouts are set to 300s now). However I think this risk is 
minimal. Use of more intelligent timeouts can reduce this risk, but I 
think it is not possible to avoid completely. Finally, OS firewalls 
could help us here too, but I would like to think of them as an 'extra' 
layer of security.
>
> That's pretty keen!  I had a talk with Roger today about development
> directions for Tor, and I think we're pretty sure that we need to
> support UDP transport within a year or two.  Work like this definitely
> helps to make the case for it.
I am preparing a much more detailed paper, that I can give you after it 
is done.

Camilo