<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div><span></span></div><div><span></span><blockquote type="cite" __apple_fixed_attribute="true"><font color="#000000"><span style="background-color: rgba(255, 255, 255, 0);"></span></font></blockquote><blockquote type="cite"><blockquote type="cite" __apple_fixed_attribute="true"><font color="#000000"><span style="background-color: rgba(255, 255, 255, 0);">On Mon, Dec 4, 2017 at 10:57 AM, Ralph Seichter <<a href="mailto:m16+tor@monksofcool.net" dir="ltr" x-apple-data-detectors="true" x-apple-data-detectors-type="link" x-apple-data-detectors-result="1">m16+tor@monksofcool.net</a>> wrote:<br></span></font></blockquote><blockquote type="cite" __apple_fixed_attribute="true"><blockquote type="cite"><font color="#000000"><span style="background-color: rgba(255, 255, 255, 0);">On 04.12.17 11:59, James wrote:<br></span></font></blockquote><blockquote type="cite"><font color="#000000"><span style="background-color: rgba(255, 255, 255, 0);"><br></span></font></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><font color="#000000"><span style="background-color: rgba(255, 255, 255, 0);">As a private individual, after just receiving my 4th abuse complaint<br></span></font></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><font color="#000000"><span style="background-color: rgba(255, 255, 255, 0);">in as many days it's time to stop running my exit node.<br></span></font></blockquote></blockquote><blockquote type="cite"><font color="#000000"><span style="background-color: rgba(255, 255, 255, 0);"><br></span></font></blockquote><blockquote type="cite"><font color="#000000"><span style="background-color: rgba(255, 255, 255, 0);">I've had an ongoing debate with a hosting service over a fresh exit node<br></span></font></blockquote><blockquote type="cite"><font color="#000000"><span style="background-color: rgba(255, 255, 255, 0);">being abused for network scans (ports 80 and 443) almost hourly for the<br></span></font></blockquote><blockquote type="cite"><font color="#000000"><span style="background-color: rgba(255, 255, 255, 0);">last few days. I can understand that they are pissed off, and the whole<br></span></font></blockquote><blockquote type="cite"><font color="#000000"><span style="background-color: rgba(255, 255, 255, 0);">thing resulted in this particular exit being shut down by the hoster. If<br></span></font></blockquote><blockquote type="cite"><font color="#000000"><span style="background-color: rgba(255, 255, 255, 0);">I could detect and prevent these scans, it would go a long way to avoid<br></span></font></blockquote><blockquote type="cite"><font color="#000000"><span style="background-color: rgba(255, 255, 255, 0);">having my exit nodes shut down by hosting services.<br></span></font></blockquote><span style="background-color: rgba(255, 255, 255, 0);"><br>With my exit node operator hat on, I too would like to see some sort<br>of port-scanning prevention built into the network. In my case, I had<br>to turn off exiting to the SSH port because we were getting daily<br>complaints about abusive scanning for devices with weak admin<br>passwords. Which is a shame, since there are plenty of legitimate<br>uses for SSH-over-Tor.<br><br>The tricky part is designing some sort of exit-node-controlled<br>new-connection rate limiting that's content-blind and won't interfere<br>with legitimate uses. And "legitimate uses" include things like a web<br>browser generating a burst of TCP connections to the same HTTP/1.1<br>server cluster, exitmap connecting to the same test server repeatedly<br>via every exit node in the network, and so on. I would want to see<br>any proposal document include a long list of known non-abusive traffic<br>scenarios and an argument that the mechanism would not interfere with<br>each.</span></blockquote><br></div><div>Previous proposals have become bogged down in the process of trying</div><div>to define "abuse".</div><div><br></div><div>Let's limit excessive use of scarce resources instead. It should have a</div><div>similar effect, is easily made content-neutral, and doesn't require any</div><div>agreed definition of legitimate and illegitimate uses.</div><div><br></div><div>Here's a quick sketch of a proposal - I would be happy to work with</div><div>others to turn it into a Tor proposal and post it to tor-dev@. Here's</div><div>what Tor proposals look like:</div><div><a href="https://gitweb.torproject.org/torspec.git/tree/proposals">https://gitweb.torproject.org/torspec.git/tree/proposals</a></div><div><br></div><div>Background:</div><div><br></div><div>Relays currently have token buckets that limit the number of bytes</div><div>that can be sent per second. This limits relay bandwidth, but does</div><div>not limit the use of other scarce resources, like file descriptors,</div><div>TCP ports, and CPU time. (There is an existing file descriptor limit,</div><div>but it is an absolute maximum, not a rate limit.)</div><div><br></div><div>Proposal:</div><div><br></div><div>We define relay-wide token buckets for circuit and stream creation.</div><div>These token buckets are refilled on a regular basis. Every time a circuit</div><div>or stream is created, a token is removed from the bucket. When the</div><div>bucket is empty, the relay takes some action that slows down circuit or</div><div>stream creation. (This could be a delay until the next refill, a randomised</div><div>delay, or some more sophisticated exponential backoff system.)</div><div><br></div><div>We set these limits at default values that are unlikely to be exceeded</div><div>during normal exit usage. (This needs measurement on live exits.)</div><div><br></div><div>This provides operators with tools to limit excessive usage, while we work</div><div>on more fine-grained solutions.</div><div><br></div><div>Alternatives:</div><div><br></div><div>We could also define a stream limit per circuit, destination IP address, or</div><div>destination port. However, this may be a level of complexity which we</div><div>don't need. It also significantly increases the number of buckets</div><div>required to implement the scheme. And it moves away from the original</div><div>goal of limiting resource usage towards a scheme that allocates these</div><div>resources more fairly between competing circuits or destinations.</div><div>Designing a fairness scheme like this requires more research, including</div><div>more sophisticated data collection on live exits.</div><div><br></div><div>There are also privacy concerns inherent in storing destination IP</div><div>addresses and ports which would have to be addressed.</div><div><br><span>On 5 Dec 2017, at 06:00, Iain Learmonth <<a href="mailto:irl@torproject.org">irl@torproject.org</a>> wrote:</span><br><blockquote type="cite"><blockquote type="cite"><span>On 04/12/17 18:19, Ralph Seichter wrote:</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>This is not about third party X complaining to the hoster about their</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>network being scanned. The hoster itself is automatically monitoring all</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>their machines for outgoing network scans, as these scans are prohibited</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>by their terms of use.</span><br></blockquote></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>I do wonder how much of this is related to the scarcity of IPv4 address</span><br></blockquote><blockquote type="cite"><span>space, prevalence of reputation systems and fear of ending up being</span><br></blockquote><blockquote type="cite"><span>labeled as "bad". When we move to IPv6, perhaps hosting providers would</span><br></blockquote><blockquote type="cite"><span>be more relaxed knowing that it doesn't matter so much if a /64 or even</span><br></blockquote><blockquote type="cite"><span>a /56 ends up bad in a reputation system, because for other customers</span><br></blockquote><blockquote type="cite"><span>you have other address space.</span><br></blockquote><span></span><br><span>Tor already supports exiting over IPv6, and Tor Browser prefers IPv6 by</span><br><span>default. Now we need Exit operators and major websites to enable IPv6.</span><br><span></span><br><span>I suspect the IP reputation space may take a few years to catch up with</span><br><span>IPv6 - we should take advantage of that as much as we can.</span><br><span></span><br><span>T</span><br></div></body></html>