[anti-censorship-team] Turbo Tunnel: let's build a sequencing/reliability layer into our circumvention protocols

David Fifield david at bamsoftware.com
Fri Aug 16 21:27:18 UTC 2019


On Mon, Aug 12, 2019 at 08:34:57PM -0400, Roger Dingledine wrote:
> On Mon, Aug 12, 2019 at 12:58:30PM -0700, David Fifield wrote:
> > I've done a little survey and identified some suitable candidate
> > protocols that also seem to have good Go packages:
> >  * [QUIC](https://quicwg.org/) with [quic-go](https://github.com/lucas-clemente/quic-go)
> >  * KCP with [kcp-go](https://github.com/xtaci/kcp-go)
> >  * [SCTP](https://tools.ietf.org/html/rfc4960) with [pion/sctp](https://github.com/pion/sctp)
> > 
> > I plan to evaluate at least these three candidates and develop some
> > small proofs of concept.
> 
> This seems like a great next step. In terms of the goal here, I was
> originally thinking "but how shall we pick the one we tell everybody
> to use?" and then I realized that another approach would be to set up
> a framework where we describe what properties we want, and provide a
> few approaches that satisfy them, and now it wouldn't have to be the
> case that everybody uses the same one. Which world we want to live in
> will depend in large part on how your evaluation goes -- i.e. if you
> find that several of them are plausible candidates, don't be afraid to
> recommend all of those. :)

Yeah, potentially this idea could become a reusable component. I'm
thinking about what I know of Lantern's design, with stacked net.Conn
interfaces each implementing a specific feature such as rate limiting,
obfuscation, etc. Something standardized may be able to be just dropped
into a design like that.

But currently I'm just thinking about it as a design guideline.

Another interesting idea that came up in a conversation the other day:
the session/reliability layer doesn't necessarily have to be the
responsibility of the pluggable transport. It would require a more
radical rethinking of the whole model, but imagine if tor did its own
packetization and gave the pluggable transport discrete datagrams,
rather than a bytestream. (This would be more along the lines of Mike
Perry's proposal of putting Tor cells in QUIC packets and transporting
them over DTLS--except that the pluggable transport would replace DTLS
with [insert obfuscation here].)

> > Q: You're proposing, in some cases, to run a reliable protocol inside
> > another reliable protocol (e.g. QUIC-in-obfs4-in-TCP). What about the
> > reputed inefficiency TCP-in-TCP?
> > 	A: Short answer: don't worry about it. I think it would be
> > 	premature optimization to consider at this point. The fact that
> > 	the need for a session/reliability layer has been felt for so
> > 	long by so many systems indicates that we should start
> > 	experimenting, at least. There's contradictory information
> > 	online as to whether TCP-in-TCP is as bad as they say, and
> > 	anyway there are all kinds of performance settings we may tweak
> > 	if it turns out to be a problem.
> 
> I agree with your suggested plan of not letting future concerns slow
> down the experimenting now. But I wonder if there are ways to position
> ourselves so we are able to recognize when this issue has become a
> problem. In particular, if we put this issue aside for now, and move
> forward with encouraging everybody to have a sequencing layer, and then
> down the road somebody using this approach is unhappy with the performance
> of their pluggable transport, is there anything we can/should do in the
> near term that will help that developer in that future situation? For
> example, are there some warning signs we can list now, that people can
> look for later, that will help them realize that it's time for them to
> resume being suspicious of tcp-over-tcp? Or are there some tools we can
> imagine building, even if we don't build them now but just put them on
> a wishlist somewhere, that will help those future people understand and
> debug their performance issues?

I'm not sure of the answers to these questions. I guess it partly
depends on what the "carrier" protocol is--if it itself is not a
reliable channel, then there may be nothing to worry about. One of the
things we can do is experiment with different parameters such as
retransmission timeouts, to see whether they make a difference and how
much.


More information about the anti-censorship-team mailing list