[tor-relays] botnet? abusing/attacking guard nodes

[teor]

> On 19 Dec 2017, at 10:10, r1610091651 <r1610091651 at telenet.be> wrote:
> 
> I don't quite understand the last calculation.

It's a slightly better approximation that my wild guess.

> "if all 65535 connections on an IP were open" => I'm guessing you mean ports

No, I mean:
"let's use 65535 as the approximate limit on connections from behind a NAT,
even though it could be larger or smaller depending on the bandwidth and
RAM available to the NAT"

The technical limit is the number of unique (source IP, source port,
destination IP, destination port) tuples, or 65535 per source IP to every
unique Tor ORPort. But that's hardly ever reached.

> "the biggest Tor Guard has 0.91% Guard probability" => percentage of all entries into the network handled by this guard
> 
> => 0.91% of all user connections
> but how many user connections are there at a time?

Let's assume there are at most 65535 connections at once time from every 
source IP into the Tor network.

> and then don't understand how probability and ports availability can be combined?

If there are 65535 connections open from a source IP, and they all go to
Tor Guards, and the clients weight connections according to Guard
probability, then the largest guard will have 0.91% of 65535 connections,
or approximately 597.

Most guards would see 10-200 connections per IP.

T

>> On Mon, 18 Dec 2017 at 23:11 teor <teor2345 at gmail.com> wrote:
>> 
>> > On 19 Dec 2017, at 08:38, Toralf Förster <toralf.foerster at gmx.de> wrote:
>> >
>> > On 12/17/2017 10:24 PM, teor wrote:
>> >> Using 256 per IP is probably reasonable.
>> >
>> > Is this a rather arbitrary limit or does this limit fit the use of NATed addresses entirely ?
>> 
>> That's an arbitrary safe upper bound.
>> 
>> The number of active connections that can be NATed per IP address is
>> limited by the number of ports: 65535. (Technically, it's 65535 per
>> remote IP address and port, but most NATs don't have that much RAM
>> or bandwidth.)
>> 
>> Also, genuine users behind a NAT would likely have multiple Tor and
>> non-Tor connections open. And spare ports are needed for NAT to manage
>> port churn and the TCP delay wait state on connection close.
>> 
>> To be more precise:
>> * if all 65535 connections on an IP were open to the Tor network, and
>> * the biggest Tor Guard has 0.91% Guard probability[0], then
>> * it would expect to see 597 connections.
>> 
>> Feel free to do the sums for your own guard's probability.
>> 
>> (We are aware of the issue, and we are working on a more permanent fix.)
>> 
>> [0]: https://atlas.torproject.org/#details/9844B981A80B3E4B50897098E2D65167E6AEF127
>> 
>> 
>> T
>> 
>> --
>> Tim Wilson-Brown (teor)
>> 
>> teor2345 at gmail dot com
>> PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B
>> ricochet:ekmygaiu4rzgsk6n
>> xmpp: teor at torproject dot org
>> ------------------------------------------------------------------------
>> 
>> 
>> 
>> _______________________________________________
>> tor-relays mailing list
>> tor-relays at lists.torproject.org
>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
> _______________________________________________
> tor-relays mailing list
> tor-relays at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-relays/attachments/20171219/d4c36ebf/attachment.html>