Help with TOR on UDP/QUIC
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? 3. We want to get *your opinions* on this idea. Attached is our (very) preliminary plan and goals for the project. Any feedback is welcomed. 4. 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 * 5. Any *testing suggestions*? How do Tor engineers test new stuff? Please take a look at our outline attached below. Thank you! Looking forward to hearing from you soon! Li.
> On 17 Feb 2016, at 04:28, Xiaofan Li <xli2@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
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@gmail.com
wrote:
On 17 Feb 2016, at 04:28, Xiaofan Li <xli2@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@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
On 20 Feb 2016, at 16:28, Xiaofan Li <xli2@andrew.cmu.edu> wrote:
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?
Onion Routing is designed to have multiple layers of encryption. And the double-encryption of TLS then Tor (whether over TCP or QUIC) is beneficial because it guarantees the integrity and authenticity of the whole connection. And it provides defence-in-depth against intrusion attempts. You might have to redo some of Tor's security proofs if you want to disable the outermost encryption layer. At the very least, you'll have to justify changing from TCP and TLS to QUIC without TLS, which is harder than TCP and TLS to QUIC and TLS. Why not leave it on? Tim Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP 968F094B teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F
participants (3)
-
teor -
Tim Wilson-Brown - teor
-
Xiaofan Li