On Mon, Dec 4, 2017 at 10:57 AM, Ralph Seichter <m16+tor@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

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@. Here's

what Tor proposals look like:

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.)

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.

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@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