[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: udp transport PoC



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