Hello Kevin,
If you are interested in learning more about the transport combiner idea we were recently discussing, check out trac tickets #10061, #9744 and #7167.
It would be awesome if you could comment with any ideas or criticisms you have.
Cheers!
Hi George,
Maybe I'm missing something from the discussions that happened eight months ago at the dev meeting. (as per the initial comment in [1]) However, I guess I'm a bit confused about the motivation.
Just to be clear, the goal is to be able to combine multiple transports easily, right? For example, we may want a transport that has the DPI-resistance of obfsproxy, but the address diversity of flashproxy.
My main concern is that a general composition framework is going to add uneeded complexity to the interface between Tor and the pluggable transports. I understand the long-term benefits to being able to compose pluggable transports, but my concern is that it won't work well in practice, will be a nightmare to manage/deploy/develop, and will have irreconcilable performance bottlenecks.
I think pluggable transport composition will be a good topic to discuss at the PT standup on Friday. To get my head around the current design, it would be great if we could discuss a few use cases beyond obfsproxy+flashproxy.
-Kevin
[1] https://trac.torproject.org/projects/tor/ticket/7167
On Sun, Nov 10, 2013 at 3:43 AM, George Kadianakis desnacked@riseup.net wrote:
Hello Kevin,
If you are interested in learning more about the transport combiner idea we were recently discussing, check out trac tickets #10061, #9744 and #7167.
It would be awesome if you could comment with any ideas or criticisms you have.
Cheers!
Hey Kevin, to get you updated on what we've discussed so far, you could try to build the diagrams from this repo:
https://github.com/infinity0/tor-notes/blob/master/pt-compose.rst
The build-dependencies are short and listed in the Makefile. There is also a sketch at the bottom of #9744:
https://trac.torproject.org/projects/tor/ticket/9744#comment:3
For simplicity, we are only considering the case where, for a compsition chain of PT[0]..PT[n], every element except PT[n] makes one single outgoing stream to an address specified by the previous element. This excludes a chain that e.g. contains flashproxy in the middle.
Our current preferred design would require minimal changes to the Tor PT spec. However, we haven't considered potential performance bottlenecks.
X
On 19/11/13 20:15, Kevin P Dyer wrote:
Hi George,
Maybe I'm missing something from the discussions that happened eight months ago at the dev meeting. (as per the initial comment in [1]) However, I guess I'm a bit confused about the motivation.
Just to be clear, the goal is to be able to combine multiple transports easily, right? For example, we may want a transport that has the DPI-resistance of obfsproxy, but the address diversity of flashproxy.
My main concern is that a general composition framework is going to add uneeded complexity to the interface between Tor and the pluggable transports. I understand the long-term benefits to being able to compose pluggable transports, but my concern is that it won't work well in practice, will be a nightmare to manage/deploy/develop, and will have irreconcilable performance bottlenecks.
I think pluggable transport composition will be a good topic to discuss at the PT standup on Friday. To get my head around the current design, it would be great if we could discuss a few use cases beyond obfsproxy+flashproxy.
-Kevin
[1] https://trac.torproject.org/projects/tor/ticket/7167
On Sun, Nov 10, 2013 at 3:43 AM, George Kadianakis desnacked@riseup.net wrote:
Hello Kevin,
If you are interested in learning more about the transport combiner idea we were recently discussing, check out trac tickets #10061, #9744 and #7167.
It would be awesome if you could comment with any ideas or criticisms you have.
Cheers!
tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
-
George Kadianakis -
Kevin P Dyer -
Ximin Luo