[tor-relays] Experimental DoS mitigation is in tor master

[teor]

Cc'ing torservers for bridge OutboundBindAddrrss, and Mike for vanguards.

Here are the mitigations again:

>  o Major features:
>    - Give relays some defenses against the recent network overload. We
>      start with three defenses (default parameters in parentheses).
>      First: if a single client address makes too many connections
>      (>100), hang up on further connections. Second: if a single client
>      address makes circuits too quickly (more than 3 per second, with
>      an allowed burst of 90) while also having too many connections open
>      (3), refuse new create cells for the next while (1-2 hours).

We could patch clients so they never exceed this number of circuits
by default. But that would penalise large clients that have a dedicated IP
address.

Should we warn once instead?

"Your client is making a large number of circuits (%u over %u seconds).
If multiple (%u) Tor clients are connected from your IP address, your guards
make refuse to make circuits."

I think there would be so many false positives, it wouldn't be worth it.

> Third:
>      if a client asks to establish a rendezvous point to you directly,
>      ignore the request. These defenses can be manually controlled
>      by new torrc options, but relays will also take guidance from
>      consensus parameters, so there's no need to configure anything
>      manually. Implements ticket 24902.


On 2 Feb 2018, at 03:04, David Goulet <dgoulet at torproject.org> wrote:

>>> On 01 Feb (04:01:10), grarpamp wrote:
>>> Applications that use a lot of resources will have to rate-limit themselves.
>>> Otherwise, relays will rate-limit them.
>> 
>> It's possible if relays figure that stuff by #2 might not be
>> an attack per se, but could be user activities... that relays
>> might push back on that one by...
>> - Seeking significantly higher default values committed
>> - Seeking default action committed as off
>> - Setting similar on their own relays if commits don't
>> work. And by not being default off, it should be prominently
>> documented if #2 affects users activities [1].
> 
> That I agree. We've set up default values for now and they will probably be
> adapted over time so for now this is experimental to see how much we make
> people unhappy (well except for the people doing the DoS ;).
> 
> But I do agree that we should document some "real life" use cases that could
> trigger defenses at the relay in some very public way (blog post or wiki)
> before this goes wide in the network. Large amount of tor clienst behind NAT
> is one I have in mind, IPv6 as well...

We did some analysis when we were choosing these figures.

It takes a few hundred clients behind an IP address, to have a 50% probability
of 3 clients choosing the same large guard. That's unusual. And if clients see their
guard timeout, they will move to another guard.

Here are some other scenarios:

Peer-to-peer clients like Ricochet, when the user has >90 contacts, but only
when there are hundreds of other clients on the same IP address.

Any Tor client that doesn't use guards. For example:

Bridges with multiple users, but only when there are >=3 bridges per outbound
IP address. (This is unlikely, because bridges need their own IPv4 address.
If you have multiple bridges using the default route, and multiple IP addresses,
set OutboundBindAddress on each bridge.) We will need to consider this issue
when we allow IPv6 bridges without a public IPv4 address. Perhaps an appropriate solution is to make bridge clients use vanguards.

Multiple (>=3) Tor2web or single onion services using separate tor instances,
behind a single IP address, making large numbers of circuits. This is a likely
source of our current issues.

T