[tor-dev] Help with TOR on UDP/QUIC

[Tim Wilson-Brown - teor]

> On 17 Feb 2016, at 04:28, Xiaofan Li <xli2 at andrew.cmu.edu> wrote:
> 
> Hi everyone:
> 
> I'm new to Tor dev community and my name is Xiaofan Li, currently a senior at Carnegie Mellon University studying ECE and CS. My friend Kevin Ku and I are taking a graduate class <http://www.cs.cmu.edu/%7Esrini/15-744/S16/> on computer networks and we decided to examine the possibilities of substituting TCP with the Google QUIC protocol for Tor in order to improve performance.
> 
> We are emailing you because:
> We want to get some points of contact with the Tor community in case of future integration and/or testing.
> We want to know if anyone else has done (or is doing) Tor with QUIC. If so, what their status is; and if not, why not?
Some of the issues your proposal describes are addressed by tor's circuitmux implementation, and by the KIST scheduler implementation.
http://www.cypherpunks.ca/~iang/pubs/ewma-ccs.pdf <http://www.cypherpunks.ca/~iang/pubs/ewma-ccs.pdf>
http://www.robgjansen.com/publications/kist-sec2014.pdf <http://www.robgjansen.com/publications/kist-sec2014.pdf>

Another answer may be that TCP is a proven technology that works acceptably well for the Tor use case. It has a number of cross-platform implementations, stable interfaces, and decent security properties.
> We want to get your opinions on this idea. Attached is our (very) preliminary plan and goals for the project. Any feedback is welcomed.
It's unclear whether your proposal is to:
* replace Tor's client to relay and relay to relay TCP links with QUIC, or
* allow Tor to carry arbitrary IP traffic, in addition to streams via a SOCKS proxy.

These are two very different goals, they're both referred to in the proposal, but they're not described separately or prioritised.

Tor likely contains a number of implementation assumptions that make arbitrary IP traffic difficult, and there are security implications in moving from a stream-based proxy to an arbitrary IP traffic proxy.

And there's currently no mechanism for tor to accept arbitrary IP traffic from clients, so you'd have to build that, too. (The transparent proxy support might be a good place to start.)
> Any implementation recommendations. My plan is to find a clean layer of abstraction where I can substitute TCP with QUIC. Any ideas? On a first look, I'm thinking about either or/channel.c or or/transports.c
Read torguts, it describes the abstraction layers within tor:
https://gitweb.torproject.org/user/nickm/torguts.git/ <https://gitweb.torproject.org/user/nickm/torguts.git/>Any testing suggestions? How do Tor engineers test new stuff?
I typically use chutney for smoke tests. Others use shadow for simulations:
https://gitweb.torproject.org/chutney.git/ <https://gitweb.torproject.org/chutney.git/>https://shadow.github.io/ <https://shadow.github.io/>

Tim

Tim Wilson-Brown (teor)

teor2345 at gmail dot com
PGP 968F094B

teor at blah dot im
OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20160217/68bba6de/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20160217/68bba6de/attachment.sig>