[tor-relays] So long and thanks for all the abuse complaints

[teor]

>> On Mon, Dec 4, 2017 at 10:57 AM, Ralph Seichter <m16+tor at monksofcool.net> wrote:
>>> On 04.12.17 11:59, James wrote:
>>> 
>>> As a private individual, after just receiving my 4th abuse complaint
>>> in as many days it's time to stop running my exit node.
>> 
>> I've had an ongoing debate with a hosting service over a fresh exit node
>> being abused for network scans (ports 80 and 443) almost hourly for the
>> last few days. I can understand that they are pissed off, and the whole
>> thing resulted in this particular exit being shut down by the hoster. If
>> I could detect and prevent these scans, it would go a long way to avoid
>> having my exit nodes shut down by hosting services.
> 
> With my exit node operator hat on, I too would like to see some sort
> of port-scanning prevention built into the network.  In my case, I had
> to turn off exiting to the SSH port because we were getting daily
> complaints about abusive scanning for devices with weak admin
> passwords.  Which is a shame, since there are plenty of legitimate
> uses for SSH-over-Tor.
> 
> The tricky part is designing some sort of exit-node-controlled
> new-connection rate limiting that's content-blind and won't interfere
> with legitimate uses.  And "legitimate uses" include things like a web
> browser generating a burst of TCP connections to the same HTTP/1.1
> server cluster, exitmap connecting to the same test server repeatedly
> via every exit node in the network, and so on.  I would want to see
> any proposal document include a long list of known non-abusive traffic
> scenarios and an argument that the mechanism would not interfere with
> each.

Previous proposals have become bogged down in the process of trying
to define "abuse".

Let's limit excessive use of scarce resources instead. It should have a
similar effect, is easily made content-neutral, and doesn't require any
agreed definition of legitimate and illegitimate uses.

Here's a quick sketch of a proposal - I would be happy to work with
others to turn it into a Tor proposal and post it to tor-dev at . Here's
what Tor proposals look like:
https://gitweb.torproject.org/torspec.git/tree/proposals

Background:

Relays currently have token buckets that limit the number of bytes
that can be sent per second. This limits relay bandwidth, but does
not limit the use of other scarce resources, like file descriptors,
TCP ports, and CPU time. (There is an existing file descriptor limit,
but it is an absolute maximum, not a rate limit.)

Proposal:

We define relay-wide token buckets for circuit and stream creation.
These token buckets are refilled on a regular basis. Every time a circuit
or stream is created, a token is removed from the bucket. When the
bucket is empty, the relay takes some action that slows down circuit or
stream creation. (This could be a delay until the next refill, a randomised
delay, or some more sophisticated exponential backoff system.)

We set these limits at default values that are unlikely to be exceeded
during normal exit usage. (This needs measurement on live exits.)

This provides operators with tools to limit excessive usage, while we work
on more fine-grained solutions.

Alternatives:

We could also define a stream limit per circuit, destination IP address, or
destination port. However, this may be a level of complexity which we
don't need. It also significantly increases the number of buckets
required to implement the scheme. And it moves away from the original
goal of limiting resource usage towards a scheme that allocates these
resources more fairly between competing circuits or destinations.
Designing a fairness scheme like this requires more research, including
more sophisticated data collection on live exits.

There are also privacy concerns inherent in storing destination IP
addresses and ports which would have to be addressed.

On 5 Dec 2017, at 06:00, Iain Learmonth <irl at torproject.org> wrote:
>> On 04/12/17 18:19, Ralph Seichter wrote:
>> This is not about third party X complaining to the hoster about their
>> network being scanned. The hoster itself is automatically monitoring all
>> their machines for outgoing network scans, as these scans are prohibited
>> by their terms of use.
> 
> I do wonder how much of this is related to the scarcity of IPv4 address
> space, prevalence of reputation systems and fear of ending up being
> labeled as "bad". When we move to IPv6, perhaps hosting providers would
> be more relaxed knowing that it doesn't matter so much if a /64 or even
> a /56 ends up bad in a reputation system, because for other customers
> you have other address space.

Tor already supports exiting over IPv6, and Tor Browser prefers IPv6 by
default. Now we need Exit operators and major websites to enable IPv6.

I suspect the IP reputation space may take a few years to catch up with
IPv6 - we should take advantage of that as much as we can.

T
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-relays/attachments/20171205/90aadd94/attachment-0001.html>