Hey Yawning (and tor-dev),
a topic that we will soon need to consider seriously is rate limiting of pluggable transports. For example, Obfsproxy at the moment does not understand rate limiting and will happily read and write as many bytes as needed.
After some discussions in IRC and #3587, we decided to add rate-limiting commands to the TransportControlPort -- that's the (unimplemented) real-time sister of ExtendedORPort. You can see the details in the relevant proposal: https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/196-transport... (see RATE_LIMIT command etc.)
The idea here was that Tor would monitor its bandwidth usage and order PTs to slow down appropriately. If an accounting limit was hit, Tor would order PTs to stop pushing traffic completely.
Does this look like a reasonable way to enforce accounting/rate-limiting policies? How could it be improved?
For example, I'm kind of sad about this approach, because it requires little-t-tor to do all the hard work of monitoring bandwidth usage and giving out intelligent rate-limiting orders. For example, how do we rate-limit N pluggable transports to 100 kb/s? Do we allow each pluggable transport to push 100/N kb/s? I don't like that this logic must be implemented in little-t-tor.
Also, do the TransportControlPort rate-limiting commands look reasonable? Is the payload of RATE_LIMITED (two integers: bandwidth rate and bandwidth burst) properly designed, or does it need more information?
Also also, will this work nicely with transport combos (#7167)?
On Tue, 10 Sep 2013 14:17:12 +0000, George Kadianakis wrote:
Hey Yawning (and tor-dev),
a topic that we will soon need to consider seriously is rate limiting of pluggable transports. For example, Obfsproxy at the moment does not understand rate limiting and will happily read and write as many bytes as needed.
My first reaction: Why should it care? As long as it only reads from the input as long as the output isn't/wouldn't be blocking, all is fine with the transport - it behaves like the direct TCP bridge protocol.
...
For example, I'm kind of sad about this approach, because it requires little-t-tor to do all the hard work of monitoring bandwidth usage and giving out intelligent rate-limiting orders.
So, why not? I think it is easier to implement that in one place than needing to reimplement it in any pluggable transport again (or at least once per implementation language).
After all, tor is the one who sees the total traffic anyway, and thus is in a unique position to throttle in a fair way, for any definition of 'fair'.
And it also means that we can throttle the regular bridge protocol as well. Which actually makes me wonder: Why do you expect that we need this kind of rate-limiting?
Andreas
Andreas Krey a.krey@gmx.de writes:
On Tue, 10 Sep 2013 14:17:12 +0000, George Kadianakis wrote:
Hey Yawning (and tor-dev),
a topic that we will soon need to consider seriously is rate limiting of pluggable transports. For example, Obfsproxy at the moment does not understand rate limiting and will happily read and write as many bytes as needed.
My first reaction: Why should it care? As long as it only reads from the input as long as the output isn't/wouldn't be blocking, all is fine with the transport - it behaves like the direct TCP bridge protocol.
The problem here is that 'len(<data Tor->PT>) != len(<data PT->Internet>)'. For example, a PT might be implementing an HTTP transport which has an overhead over the simple Tor TLS connection. So Tor cannot track the actual number of bytes sent to the network.
...
For example, I'm kind of sad about this approach, because it requires little-t-tor to do all the hard work of monitoring bandwidth usage and giving out intelligent rate-limiting orders.
So, why not? I think it is easier to implement that in one place than needing to reimplement it in any pluggable transport again (or at least once per implementation language).
After all, tor is the one who sees the total traffic anyway, and thus is in a unique position to throttle in a fair way, for any definition of 'fair'.
And it also means that we can throttle the regular bridge protocol as well. Which actually makes me wonder: Why do you expect that we need this kind of rate-limiting?
We need this kind of rate limiting to allow people to say "I want to donate 80kb/s to Tor; the rest of the bandwidth is mine.".
BTW, posting here two more PT-rate-limiting ideas (instead of the currently proposed RATE_LIMIT command) proposed by Andreas and Lunar in IRC:
* PTs calculate their overhead and send a "fudge factor" to Tor when they start up (for example, if an HTTP transport has 30% overhead over the underlying TLS connection, the fudge factor is 30%), which Tor uses to calculate the actual number of bytes sent to the network and do rate-limiting/accounting on its own.
Unfortunately, I doubt that PTs have a constant fudge factor.
* PTs periodically send to Tor (over the TransportControlPort or something) how many bytes (or how many bytes overhead) they have pushed to the network. These numbers are used by Tor to update its traffic stats and enforce rate-limiting/accounting on its own.
On 2013-09-10 05:34, George Kadianakis wrote:
BTW, posting here two more PT-rate-limiting ideas (instead of the currently proposed RATE_LIMIT command) proposed by Andreas and Lunar in IRC:
PTs calculate their overhead and send a "fudge factor" to Tor when they start up (for example, if an HTTP transport has 30% overhead over the underlying TLS connection, the fudge factor is 30%), which Tor uses to calculate the actual number of bytes sent to the network and do rate-limiting/accounting on its own.
Unfortunately, I doubt that PTs have a constant fudge factor.
Some of the PTs I can envision having a non-constant fudge factor are those that decide to insert cover traffic or randomize packet lengths in an attempt to evade detection or mimic other protocols. This feels like a lazier implementation of option #2.
- PTs periodically send to Tor (over the TransportControlPort or something) how many bytes (or how many bytes overhead) they have pushed to the network. These numbers are used by Tor to update its traffic stats and enforce rate-limiting/accounting on its own.
A more generic variant of option #1. I assume tor will enforce rate limiting by delaying writing to the PT connection(s) in question? PTs can/may end up breaking this if they need/want to insert constant cover traffic. It's entirely possible to say "Don't do that" in the spec, but that feels overly limiting.
For what it's worth the main example that comes to mind when I try to remember how this sort of problem was solved before (besides, "use iptables and tc") is similar to the original proposal.
See: http://monkey.org/~marius/pages/?page=trickle
They cheat and use a shared library that wraps socket calls though. I assume that's not an option due to "this needs to work on windows". For the U*IX targets, trickle does most of what we would want.
-
Andreas Krey -
George Kadianakis -
Yawning Angel