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

Sat Feb 20 05:28:21 UTC 2016

Hi Tim:
Thank you so much for replying.
I hope to address your questions in detail in this email, as well as posing
some questions in the second part regarding some parts that we are less
sure of.

1. Question of scope. Regarding the question of:

> 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.

We will definitely replace relay-to-relay TCP links with QUIC. And we will
probably also replace the client-to-proxy link as well but without allowing
arbitrary IP traffic (for reasons described in your email). We will still
have the SOCKS proxy abstraction as it is right now but intercepting and
running on QUIC instead of TCP. Now, I think most of our gain is going to
be from the relay-to-relay links but we might be surprised by the reduction
in circuit setup latency (as a result of fast QUIC handshakes). So, for the
question of prioritization, we will examine relay-to-relay connections
first.

2. Question of goals and uniqueness. Regarding the question of:

> 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.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.

I think the KIST paper is really a study that improves over the EWMA
scheme, with the additional consideration for egress kernel queuing
"fairness". But I think these two papers are really on a different level
from our goal. The problems we set out to address are:

   - Head-of-the-line blocking problem introduced by multiplexing multiple
   independent circuits over a single TCP stream.
   - Better congestion control, or decoupling the congestion control from
   the transport layer.
   - Explore the benefits of fast handshake and setup time.
   - Explore security differences between QUIC's TLS-over-UDP and the
   current TOR implementation. I know this is most likely not going to be very
   beneficial based on the end-to-end security requirement of TOR right now
   but this gives a different (and perhaps better) option of doing things.

QUIC is specifically designed to tackle the HOL blocking problem when
multiplexing multiple flows on a single connection. See design doc
<https://docs.google.com/document/d/1gY9-YNDNAB1eip-RTPbqphgySwSNSDHLq9D5Bty4FSU/edit?pref=2&pli=1>
on "Multiplexing".
Also, QUIC has a pluggable congestion control, meaning that we can
"tailor-make" the congestion control mechanism based on the application.
Note that the KIST algorithm can still be applied with our changes to the
transport layer. The application scheduling algorithms will not see this
change. However, the EWMA algorithm might not be applicable anymore because
with QUIC, there is no TCP multiplexing anymore.

Finally, we are perfectly aware of the state that QUIC is in right now and
are not aiming to replace TCP in production code base overnight. Our goal
is to simply examine the benefits of QUIC and contribute to the
understanding of some of the problems of TOR over TCP. Maybe that one day
under a more suitable circumstance, our project can be useful to the
improvement of TOR.

*Here is a question that we have about security: *
Since QUIC comes with a transport layer security, we are worried that this
feature is conflicting with TOR's application layer security. By
"conflicting", I don't mean the QUIC will sabotage TOR's security, but it
might be doing redundant work, such as encrypting twice unnecessarily (once
for QUIC's TLS and once for TOR). So, we are exploring the possibility of
turning off this feature in QUIC. What do you think of this problem? Are we
on the right track?

Thank you!
Li.

On Tue, Feb 16, 2016 at 8:29 PM, Tim Wilson-Brown - teor <teor2345 at gmail.com
> wrote:

>
> 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:
>
>    1. We want to get some points of contact with the Tor community in
>    case of future integration and/or testing.
>    2. 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.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.
>
>
>    1. 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.)
>
>
>    1. 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/
>
>
>    1. 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://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
>
>
> _______________________________________________
> tor-dev mailing list
> tor-dev at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20160220/fa1ca5c1/attachment-0001.html>