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.