[tor-dev] Pluggable Transports and rate limiting

[Yawning Angel]

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.

-- 
Yawning Angel