Hello.
rE-Bo0t.bx1 wrote:
Short answer: no, Tor doesn't do Happy Eyeballs for OR connections.
Whatever address family gets picked for a connection attempt is what
gets tried, and if it fails, that's it for that attempt. Tor won't turn
around and retry the same relay over IPv4. A later circuit attempt may
try again or choose another path, but that's separate, not a fallback.
The reason I ask is because I'm considering implications of the toralf
tor-ddos script on relays that use IPv6. By its very design, there are a
number of hosting providers that will provide, say, a routed /48 for a
low cost which could then be used to completely overwhelm the IPv6 anti-
DDoS firewall rules (unlike the IPv4 rules where an attacker would need
to buy a costly new IPv4 just to get an additional 8 connections).
If a hard limit for the number of simultaneous IPv6 connections were set,
then that would force the attacker to fall back to IPv4 long before the
relay is actually overwhelmed, but that would also prevent anyone else
from connecting with IPv6. If connections fell back to IPv4 after failure
to connect with IPv6, it could be a solution. It's unfortunate they don't.
As it is, it seems like the anti-DDoS script and firewall rules are only
effective on dual-stack relays so long as no attacker figures out that
there are plenty of routed IPv6 netblocks that they can cheaply use.
Regards,
forest
···
_______________________________________________
tor-relays mailing list -- tor-relays@lists.torproject.org
To unsubscribe send an email to tor-relays-leave@lists.torproject.org
Build an escalation system.
E.g. a single IPv6 will be blocked first, if more come from the same /64, the entire /64 is blocked.
If more come from the same allocation (either use /48 or even bigger if you can query the BGP data) to block the entire ISP.
···
Am 21.07.26 um 02:52 schrieb forest-relay-contact--- via tor-relays:
The reason I ask is because I'm considering implications of the toralf
tor-ddos script on relays that use IPv6. By its very design, there are a
number of hosting providers that will provide, say, a routed /48 for a
low cost which could then be used to completely overwhelm the IPv6 anti-
DDoS firewall rules (unlike the IPv4 rules where an attacker would need
to buy a costly new IPv4 just to get an additional 8 connections).
--
Gruß
Marco
Junk-Mail bitte an trashcan@stinkedores.dorfdsl.de
Hello.
Marco Moock wrote:
Build an escalation system.
E.g. a single IPv6 will be blocked first, if more come from the same
/64, the entire /64 is blocked.
If more come from the same allocation (either use /48 or even bigger if
you can query the BGP data) to block the entire ISP.
The problem with that is that someone with an /80 in that /64 could get
everyone else on that /64 blocked, which could be used as a way to target
specific people by getting them kicked off their guard.
For a commercial spam filter, it makes sense to treat every /64 as an
individual, but it's quite exploitable. I assume that's why toralf's
script will fall back to blocking based on /128 otherwise.
Regards,
forest
···
_______________________________________________
tor-relays mailing list -- tor-relays@lists.torproject.org
To unsubscribe send an email to tor-relays-leave@lists.torproject.org
/64 is the smallest allocation for an ethernet link. The only place where multiple subscribers might be in the same /64 is hosting. For every other case, a /64 is assigned to one customer.
···
Am 21.07.26 um 08:40 schrieb forest-relay-contact--- via tor-relays:
Hello.
Marco Moock wrote:
Build an escalation system.
E.g. a single IPv6 will be blocked first, if more come from the same
/64, the entire /64 is blocked.
If more come from the same allocation (either use /48 or even bigger if
you can query the BGP data) to block the entire ISP.
The problem with that is that someone with an /80 in that /64 could get
everyone else on that /64 blocked, which could be used as a way to target
specific people by getting them kicked off their guard.
--
Gruß
Marco
Junk-Mail bitte an trashcan@stinkedores.dorfdsl.de