[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-relays] Questions about 4 Relays per IP and the ddos mitigation scripts
- To: tor-relays@xxxxxxxxxxxxxxxxxxxx, nusenu <nusenu-lists@xxxxxxxxxx>
- Subject: Re: [tor-relays] Questions about 4 Relays per IP and the ddos mitigation scripts
- From: Chris Enkidu-6 <tor@xxxxxxxxxxxxxxx>
- Date: Tue, 7 Feb 2023 01:48:29 -0500
- Autocrypt: addr=tor@xxxxxxxxxxxxxxx; keydata= mQINBFWMtxIBEADWtP+m+KK37yXz5i/w5nCjxpjwS6H2QTNIpHTx+444DxlX90L8GOLEOwS7 LRx/OJ/Vo+aqmAOL49Slejj6U29r8qJz7Nq7g+HfE9AilJMTvBWU5W21PF2wuKuQJLboPR4s iCnoHBg2ylds1aIweW126t01GBy+lvFJ/c6mqeHn69kq0VzJkMWv1YcIPaPMWj/foGf+yPp9 3hB2r8fIrY6q6jkQdP+mvBpn8rNteqgtGviMqCeQIwtaA3VcwQqcomSOjY4zBA7Uhse1iMF0 tjK3N0Bar/rV2zMu+jqppoat6E9y0AjshFCSgUMiZKIkMQ3oWEalkwyNXHpgcGb69WBKD+kl 5kJtOCP7aSs3VAR2xA86pX6lwfYlzNL2CsNzHGmkSm6mZygLpkQOOn9I3zDjhzGQ6j00I0P9 pi3a39BbgBrVYUa0O6NAIs816+vuHacR91jFvYQzMTQJ1cesRXnxvmDpaCuTLxFNWM2sORh3 BdBx3H0Xf5JNF11dJZ1b7XGxuPDA+hbSZwlU68EqptBocE9jlfTZ/ja0wx6Pgn137EKJ4ZUy d5PMp7eEUUfZFtEretfJ+IKJ+/UFjKRfgPiP6OY536TNzramtMsHN2uMsW18DY7oYaDZ2Nm/ EOg36Bjp8551gWnstogdjmoJAbmsN/WqZKuOYtZwrbEb485+8wARAQABtBpXQ0IhIDx3Y2JA d2Nic2VjdXJpdHkuY29tPokCoQQQAQgAizAUgAAAAAAgAAdwcmVmZXJyZWQtZW1haWwtZW5j b2RpbmdAcGdwLmNvbXBncG1pbWUICwkIBwMCAQoCGQEaGGxkYXA6Ly9rZXlzZXJ2ZXIyLnBn cC5jb20FFgADAgEFHgEAAAAGFQoICQMCFiEE0cq5h5p8USgUPeenb/FtB2wEq2cFAmITVg0C GyMACgkQb/FtB2wEq2fPvBAAkJ3Z9lxFPVvGT5j40GnhsDkF7F0gJ2O1SNo+gTgWKs9Bn8MT 5UuShLhdXazFNfMLezjNXDWlRtEIIpoHkJ5MN/IPQmZ6/Pc/zLKfEIZVdD1HD6MImNVT8GyW vXuSrmQEqne7vV3CeoABXZSPyl7wiCibahlHyjPNmFcIpBY+EqSVKhTXwNgtquL5dJUUSwdz rwSoI9sNOQqcaqpyzZZOEUAEbqDImMMC3FsYf7p3VBmq0+fddxCVzoC0ibEf1YDPwZuVulbn URPv+O5AD+hQkAmYMXiI7As3FLnHY0XoimVhxnLKHPj+LZvYsrFczC808rnWuuW3ri05euLd P98/O4Y3Cpe88hFhaeG37Bp/wiwIzKXrYb0+pPf40GGUl1dI0694TgtV5Am1ithBiOJlL7IA I+/npSRitS751CpT8s9not5kQJVa7J9AIE0+7T20bR7dYXgLWyRank3vExOzy4GdeCeoFct9 M9WYEaxsp7dQdz4LNs0rndQeHkVr0nkwiQszeDrZntWGknMlXYx0wzJPF+RB1um1+YFs8bOA +N4qJ7MGejG4ucNC1DBkeZoAYYQJZfHWiyz1l3ncN9wOv9qNH7+zhSnyu3OwyjOa4GaIFtqj L2cjQI/LRU6J4hW+cN/G2weK5KPxntEyI5rPEqIR5AcmOvTqQrcSWLtnfdu5Ag0EVYy3FQEQ AM+zo7GBG+zkHJv+rK1RrwSCGeFdrHL1M6qHvvekc+29aId1i5V99C1fJo4a+Yl9LXFvS+p7 43rN/35FjR09FQx8wYUTRaYDYC287/Rwl1QI0AVzu7X4qnlnFvbij+BQyUXQyxoILQEoMjBA WnlQRe6OCMsi4AyozIvYCWZ2QG/03sMiQq9KCZM1UrTvBHGdtMaaq7b90VUZGCk+ME8Sz1b6 uSKjUttGqz+14U4c5lrMY5Ao4hZObsYwGq3JCfDfb8Ibiaj2qSRMC1lWBO6d/Cd3HD5jC1pE FFQHwZZmI26YIQMsrJ2+V7vWue/X+PUHMur2x6laMNE9ds06jipVV+ZQzzUp/V2Ledok2+4m f85sEOAC9mwloI2vjNqnyVM8k5VtnOAD86Y1I1wO87pthZSX5ZHmxkxxl+Vw5cx+siPo+etU FC+hHk7/zInv1lKnuVHrX2IHcW714l3I7RDaNWvLXuiAMY9M6loFLuG6VTXcrf2FI7BMgqXD dStznJNdBfslEbq5cOLXxfYKYbuwipJ/2LuaE3KVXcdebmBx12oMl8T/F70C1A+ynrfKecND eyar7OakYvxk6+lT7hdzkKzs9DDI75BU8SNKUKdWT/wl0d/6tTIQRhqySrcICGn6O+FU1ODh ccVrgPJiNBhRfXt4WG4P5yhSMnGXlywjzKoFABEBAAGJBEEEGAECAisFAlWMtxYFGwwAAADB XSAEGQEIAAYFAlWMtxUACgkQ//PgyfkqRnuEHQ//S626WYYerZMsjglzG9X+gRy9X15iYxm5 sfw2KMbVRXSkt++beT9R+4eefasdzOKzo37Hehnv8EpToKwk7nz5CFmPvicN/wZ4h4/UM1Jn wNMJH5QaLWzhNf+bD9a/8l+TUIMAfIQx+Ub82xgLFf1dD7JkIddH3WfEIOmDaoR9MlyLzglF +WKGaXZXYPkko6h7lZuq7rxkabtVohvQhk2UypwwfU25wqrI1i8RsivB5kFn7+UrgzulNCFM UDzvld/Ym6crqxGmYa0ayxnyTRzFdFGCA/A7fhuJo3WcJq8OuimV22BcXeK8t8cvijOmGFMR QZ74dh5yU/axg+EnWNsVQCwU8qjNgsm7vX2dfovE+8/tMFGh+NibfpXtfBtpQYpvYMsuQ4Z+ hxaozESGxWBmNXzZ9kPKrIQqTuut/tIe5IylISkfz0oTEskJp2E10zZq1mKIwtghlhmHXuA2 XW9/y7ivgoylHyDj+vopCeQo73UTNA5dOAfuzN8AyAaTo4cgki4KYq1mnKfMHp2yYku1RJEF 4BxqTeKfE2WdTYhsusqn6ZNT375hMYeA1pAbYfb3Ybh9NN4jxmXV5hMd15jQUdwwCZecK/34 zmgY9z2kV+9tbkofyc/8SJcYypqOPKIU4b6iPQdNyX2DoWuygEMtK+wLRxH/kTAQ9LYs7tM2 15MACgkQb/FtB2wEq2dU+Q/+NvoqGo1gDu+yvep5YhQLVyJZLvvYlMhQuGhYD02I22EeNZSh HPT2++9U2hbTAZuME+AZZfNVZUuc51BUZLXLYAwUE5+eJCyDq4amLiQaYYVJxK6q2XGcaSpJ K5gbR9U9BclXTLdcrpFUXLs2BTQvKRji8c6MjxTrmLgj5fKh4UAx4Aul0DkLH3lP+DgHmiLM JCPdTnyUpM5+TYe0spqybeEySWI5+e0BJHJkAYigdq97JWEvwnavvQo2mc9PRDyviVx/B21f jnqAmP9ihnWlBUc++jGLRAXfexpDvoWRaWCrNCh6SlNVfADgsnPmZeNx6IFVWSePVpn88Q1N RaNsAhEeFH7RxAHLzsxksbfHq18dUvv727E/JPtHF8gy6ymIdNgG9T0i24IxKhjZeDI+gHlp 6c85+R9P72tuf6K9RJ8qeM4EApwGADI5Y4hrlfpsoQhoxNe9AAuS1NJG+K43TxR1qGPirPq5 g7ZpbHrF3F4ZniPpAHYose6Dwy5iMIJcDITuZI9ek47UYtOkgdqOhcZVnKFXG7B1hWHX8G8L O3dJkuLU1JpZCg7BUXD4iQmlHd+niYwglexRtJBTdmzrbXHDSMVR1BaZuTyDY1pJTsJ9RkuP kMlJQPU9sRLT8Va+4ld4XXzJL9yjyP7WafiXaXrL+mew7zTcUNTtNFbwvS+5Ag0EVYy3GAEQ AL2lIVP8MSA4pviJ8D83MrJL5IEeR7CQwjWHFxh92T+M7JZVQ0pHkIMBHit1jRDo5MARqnR2 W14jZ6Nt7lVHQ8P7puOpYlvokDbv3+ln5JvgFvc/7P06VWesi24Ft5V8LBXGS9QZ8Jn031DE eGV+BVhX9UlF8U1WqWONRR1Sb3Nda+rg8n21fGGidUm+1gmjm50u9VYHb0ZK226OLfMASPYQ 8wt8ZSjkERK2fJwofGLZR1X67K3L4VuR7IQvS/xrY906oqZtl3/tjB2A7yFMWfxisv31kb/s mv3EWJspLs4eK+a3PZhHTsG4X1MQxP1UskM/9rx82aiMKENv8DsXxpvb+UPIX/AR4y2rwZwU KLYNVpGED9f/FcTxwozdl48GMsF/IQHQzYEu1LpAiznPj4icEGnjvdtABWk2ZMjhKYEXfTaj iEQxO3yaazkL9IuRssPIS87EwEKcIqIpxwXUBbEYKLe7XFijl+XkXKWl+35IYUzV/M0mLigE Xc4WReudjzVWF0jA/dP7Rsc1GEUq4vOxuiOOBiXxVKZPPWxU3MunGhhc8Cx8dEXf3FcDML2M px9WU5QxxuPon830KB4yz37tmgui5qkDaHuQkhTEwlvnP+ELo0yrw2CQXDqBVf77dmnUw9c9 jUPZmqsbrl4/nrbhQ89P8EhL2dKYfIH0iG6dABEBAAGJBEEEGAECAisFAlWMtxkFGwIAAADB XSAEGQEIAAYFAlWMtxgACgkQgIt/XQhd0uslbhAAruDf2E38K45HWP3qV0oDYnMNRIWq/dNZ qXHkmkSjmlKcbCHrklCb155Z9lLU75Yqtjax2KhiNCiNRHFhaSMuappO2pBhnHZqnlLbB250 FPWdu+mSzi4yi0pUrtEJ+Sksb4HyKZzfHIqaDV8XsCU1vPYu1b7rHkXVuFXP1HDKTGp7dimt VQ5vDSx0hikU6kFwYT685AC6VIFymGL6VxjwKwsZ1uR0/xAktryFAzVIRtnXV6jjQ7NoCkVV BrtQUAiVSxO0V7FeOmNhkoSAQewJKIhg0KjJ+le8+899ypw5+/JnnlvFbvv/ZKTNOMXi9oNO w8k2y+HyPx0PQjemb37JPTF7DgSkFqHpSPQ3UISMpceKByhOnnNhq92JsMp/Q3zVR+zvipj9 eOFNHxpoc0AFelcU1hnH61qUEutIsveGUvhw0IegWN0xxBD5KpGM3nwEqdJC6OnzqKwRD3TO tVGGHUA1lVkJu6AwwxPSyRDVGFIN8RBAMB4/ysuAKIraNWsIf0Y6fgXWLeaE2iuG43MWiYqR wtwrZ/R4nSBe+1EIUV4vIZXjpP6vLSfzeLnM8OHUw41TebDhfMwyMvIDaT3pnwpizTdoZ89g vJJJiDZmCWeWOV6HjMYhH5cg5VWor76uinG1fDRWJCbVUf5ZMYq+If5uLO893qMtA1oXcs5R /tsACgkQb/FtB2wEq2dMuw/+JQ6zm9C+tqReGGw1KM/39wVXTwnchJQKtSJYmcAsAd3tR7C5 e/xlX/ANLcjt/pZD9CKFdp9lBhT/yMzFFX7+k3UFspb+wPR83qjsZueEvf0VBC/FcW48vCJE BikGIGHpJhL3czSsLr6Tmtdy6D8iQ1HvWcZxAoZXa5h8J5T6QWD+u7TH7am+DZPg7ZqGA7zl Derbiiv9Xo8z4kRBO4eRin4funW7zPlpp9wOrsD8peTaw6QJcgZ/y60Ef+6Uz0FCngz8vq3O weXZFp87olPMsCoTZ/2gd9Q1346ozXGNfKIIrFeGnZhWSZIsbFrH1Eqm5bR/CwKFnPeQfogo JPKeTWX0john8EJAjkHwQOsypqzXGtFvL7k6tANL6V3A0lyhyC+GvfmSEUO+ey7s+VLK48QX 1JSr0kXenElTgzj3mKnCgRqf60oBTwepVXzwKahNhC5CJVQLfM3b1IS9y46sybyQQshup9YE sMaMBSyrSyiO6vaCwNhP6jWKwCK8FDyO78vOxfrUtcPahHb1YstnFLegLnrdl/OzanvfNB2s 54N5NCsONeKy3Iok1CTQbUb+ECIp16AN22lNICZoMj6csSR1S6Ah8Y3FVLSThaUpUMLMR9EE 4xEnRmqUaCvSvafjazfkbAUgxnN9V+CCVI68904gcm0Wkxk+u5KsBVFtVfY=
- Delivered-to: archiver@xxxxxxxx
- Delivery-date: Tue, 07 Feb 2023 03:33:46 -0500
- Dkim-signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=wcbsecurity.com; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:References:To:Subject:Sender: Reply-To:Cc:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=CiCpBrRb4RNwotKZwJwuWa+LeG/iCdcgPko/nTXmokM=; b=tZrhKAABHpU+Zq2Q5EILZdd/t3 /XstNkjVI1At5LtVYvh9+A3ec7G3O4LOKBDPIAKxQyLcj5KedhrC6i/j7Kfvukim5Sos9Ck2whSR9 GC2CZUp3SJXyIGF/dg7UMmU+8h4mWVOdgYdvIPJz01kRiHqRsVS15EHOASSaphCqi+8+pJAKmscfR Iqo+ZmhPphP5ityppRyulwmFZZ2NHczG+4+GH8QA/DtSo5eGS8KAmpB8IwkwIGURiG4PRNLVb9MuZ +5CMiS/+SzNY4th1Ai+aq73z747wJkzr9HCwTiVQuq4pW/Zl5V3+H4lOvJVoesXi2lDtQS93PcLpI zjoI0H6Q==;
- In-reply-to: <baec606d-7856-18e2-bf13-3f40bf207f6d@riseup.net>
- List-archive: <http://lists.torproject.org/pipermail/tor-relays/>
- List-help: <mailto:tor-relays-request@lists.torproject.org?subject=help>
- List-id: "support and questions about running Tor relays \(exit, non-exit, bridge\)" <tor-relays.lists.torproject.org>
- List-post: <mailto:tor-relays@lists.torproject.org>
- List-subscribe: <https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays>, <mailto:tor-relays-request@lists.torproject.org?subject=subscribe>
- List-unsubscribe: <https://lists.torproject.org/cgi-bin/mailman/options/tor-relays>, <mailto:tor-relays-request@lists.torproject.org?subject=unsubscribe>
- References: <32ba4f01-2e87-97c9-2310-746990fe1e27@wcbsecurity.com> <baec606d-7856-18e2-bf13-3f40bf207f6d@riseup.net>
- Reply-to: tor-relays@xxxxxxxxxxxxxxxxxxxx
- Sender: "tor-relays" <tor-relays-bounces@xxxxxxxxxxxxxxxxxxxx>
- User-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0
@nusenu
Thank you very much for taking the time to help me understand things
better. I can use all the help I can get.
> You can also not be sure whether it is an actual authenticated
relay to relay
> connection or a client to relay connection just by looking at the
source IP.
> In a vanilla current tor version it is not possible to use a tor
client
> to connect via an exit to another relay's ORPort so this is very
unlikely.
> An exit can share it's source IP with tor clients for example
behind NAT
Sorry I'm confused here. Those statements seem to contradict each other
or there's something here
I misunderstood. Even if that happens, why would a client connect
directly to an Exit and get the
Exit to connect to another relay or Guard using the Exit's IP address?
Wouldn't the same protection you mentioned kick in and
stop a client?
> I was not able to follow you there. I was unable to find any exit
relay that
> has more than one ORPort on IPv4 (I identify relays by fingerprint
not by IP address).
Sorry, I should have been more careful in using my words. In the world
of firewalls and iptables
we identify connections by IPAddress:port pairs hence my inaccurate
wording. A relay has only one ORPort
but an IP address can have 4.
> I think there is a misunderstanding there. One important point to
take away:
> Relays do not chose the next hop in a circuit, tor clients do.
> So if my tor clients picks a circuit with these relays:
> client -> A -> B -> C -> example.com
> and B can not reach C, B can not say "oh I can not reach C I'll
pick D instead for you",
I understand that and I think it might be my fault again for not being
clear. It doesn't matter who makes
that choice. What matters is that the choice is being made. My
understanding is that the moment you open
your Tor Browser, it starts establishing connections and building
multiple circuits and keeps them in a pool.
In the old days of vidalia you could actually see that in real time.
Many established circuits were just
sitting there waiting. Each time you try to browse a page, Tor doesn't
say, oh let's find a relay. It picks
a circuit from a pool of already Established ones. If Tor tries to build
a circuit with a relay and it's unable to,
it will try another one that works and keeps it in the pool for when
it's needed. Again, I may be wrong.
Feel free to tell me if I am.
If that wasn't the case, any time I rebooted, someone would scream for
being disconnected
from the Internet. Evey single relay is important but not that important.
> Blocking relay to relay communication should not be done
> as it breaks a core assumption of the tor network (every relay can
talk
> to all other relays ORPorts)
Okay, now let's be clear about DDoS mitigations. There's no such thing
as DDoS mitigation without rate limiting.
Both my rules and @toralf rules and frankly any other rules that anyone
could come up with by themselves, includes
rate limiting.This means that at any given time, someone, somewhere is
not allowed to connect due to their behaviour.
The idea that all relays must be able to connect to other relays any
time and in any shape or form they choose can not
exist in real world of DDoS mitigation. Right at this moment I have
about 1600 relays that have established connections
to me and I probably have as many connections to other relays and my
relay is happily operating at about its
Max Advertised Bandwidth. Do I really need to keep 6000 relays in my
allow list and let them do whatever they want?
Giving 6000 servers a free reign on your system is unheard of in the
security world.
DDoS mitigation like anything else in life is about compromise. Ideals
are sacrificed in favour of "good to haves" and
"good to haves" are sacrificed in favour of survival. Otherwise you'd be
a part of the currently
[over 2000 relays that are
overloaded](https://github.com/Enkidu-6/tor-relay-lists/blob/main/overloaded.txt)
and passing it along.
When I'm attacked, it's not just about me. I'm relaying that attack to
the next relay and they relay that to the next
one. So the idea that I should accept the attack when it's coming from
another relay is simply unacceptable.
Again I'd like to be very clear, this is not about blocking relays, it's
about rate limiting. They do get to connect
but at a reasonable rate. For example, there's no justifiable reason for
a relay to try to connect to another relay
at a rate of 10 times a second for 15 minutes straight.
So if for example we say a relay can have two Established connections to
me, we're not blocking them. If they do need
the connection, they use it. If they close a connection and at some
point they need one, they can open another one. But
they can't have 10 connections at the same time.
Again, My goal here with my questions is to find a way to keep the
balance of that compromise in our favour. But thinking
that we can go on without making those compromises would be naive.
Again thanks for reading and thank you for your time and response.
On 2/6/2023 6:17 PM, nusenu wrote:
> Hi,
>
> thanks for raising these questions and trying to understand before
> deploying/changes to filters.
>
> A good understanding of how tor relays and connections work is
> important when trying
> to defend against overload attacks, without breaking functionality
> with packet filters that cause false positive blocks, especially when
> such a
> long standing limit like the relays per IPv4 address limit is changed.
>
>> - I have a few Exit relays as permanent residents in my block list, not
>> because I want them to be there but because, no matter how many times I
>> remove them, day or night, they'll be back in seconds for making too
>> many concurrent attempts.
>
> As a relay operator you should allow all other relays
> to connect to your relay's ORPort no matter what flags or onionoo
> guard/middle/exit probability they might have.
> Place known relay IPs on an exception list so your filters don't block
> them
> and update that list at least every hour.
>
> If you have a problem on your relay's ORPort with a source IP that
> is also used by an exit relay please try to contact
> the operator by looking at their contactinfo, if they don't
> have a contactinfo, join the 'require a usable contactinfo' lobby ;)
> for this very reason and maybe ask on this list if they can drop you
> an email.
>
> You can also not be sure whether it is an actual authenticated relay
> to relay
> connection or a client to relay connection just by looking at the
> source IP.
> Some upcoming MetricsPort enhancement might help you there in the future
> not per source IP but as a general overview for your relay's ORPort
> connections.
> An exit can share it's source IP with tor clients for example behind NAT,
> but I don't think that is common and it is also discouraged. Exits
> should have dedicated
> IPs that is not shared for unrelated things.
>
> Blocking relay to relay communication should not be done
> as it breaks a core assumption of the tor network (every relay can talk
> to all other relays ORPorts). Upcoming tooling that detects
> broken relay to relay links might also detect and flag your relay
> if your filters break relay to relay communication.
>
> As an option of last resort - after verifying it is an authenticated
> relay to relay connection that is causing you trouble and not some tor
> client using the same source IP
> you might contact the bad-relays list. That is still better than blocking
> another relay from reaching your relay's ORPort.
>
> I've seen other problematic filter practices for relay to relay
> connections and I'll
> write up some recommendations in a separate email so it doesn't get
> lost in this lengthy email.
>
>> I'm assuming this is due to the fact that
>> Exits are being used to attack other relays
>
> In a vanilla current tor version it is not possible to use a tor client
> to connect via an exit to another relay's ORPort so this is very
> unlikely. The background here
> is that tor does not allow such connections to prevent an attacker
> from reentering
> the tor network via an exit relay.
>
> You can test that by opening this URL in tor browser, you will get a
> "Unable to connect" very fast:
>
> https://185.220.102.242/
> because it is this ORPort:
> https://metrics.torproject.org/rs.html#details/0A2366980A2842D770EF8E136A7DA14876360447
>
>
> the answer is very fast and not a slow timeout because a tor client
> can predict
> that is inaccessible before even trying to create a stream
> because exits will not allow such connections to relay ORPorts.
>
>> I have 2 Established connections to two Or Ports of an exit relay
>
> I was not able to follow you there. I was unable to find any exit
> relay that
> has more than one ORPort on IPv4 (I identify relays by fingerprint not
> by IP address).
> Maybe you can list the specific exit relay fingerprint and timestamp
> so I can cross
> check for bugs in my tooling/onionoo?
>
>> - Each relay has Established connections to many other relays and if
>> they're guard they will also have many connections to regular users and
>> their Tor browsers until they have enough traffic to reach their
>> MaxAdvertisedBandwidth. Obviously we don't Establish connections to all
>> 6300 relays out there.
>
> It is best to actually expect that.
>
>> So if we do not allow each IP more than two
>> connections and they need 4, They'll have two from us and they'll move
>> on to another relay and get the other two and get the job done and we
>> will reach our Max Bandwidth anyway by accepting traffic from other
>> relays. Diversity of relays as opposed to concentration of some relays.
>> Am I correct in my assumption that this will have little to no effect on
>> the health of the Tor network as a whole?
>
> I think there is a misunderstanding there. One important point to take
> away:
> Relays do not chose the next hop in a circuit, tor clients do.
> So if my tor clients picks a circuit with these relays:
> client -> A -> B -> C -> example.com
> and B can not reach C, B can not say "oh I can not reach C I'll pick D
> instead for you",
> a relay has no say in that. I hope that helps to reinforce the
> importance of
> ubiquitous reachability between relays. Relays have to obey a tor
> client's
> orders and a tor client expects that all relays can talk to each other.
> A few years ago David Stainton published some actual scan results on
> tor-dev
> that showed that this expectation might not be true in reality but
> close enough.
>
> I fear that overly aggressive relay to relay filter actually help the
> adversaries more
> than the network and would advise against filtering practices between
> relays.
> The first step should always be on a social level: Try to reach the
> operator if you feel
> they attack your relay and NOT iptables DROP without notice.
>
> kind regards,
> nusenu
>
_______________________________________________
tor-relays mailing list
tor-relays@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays