Since it is still all fresh in our heads, I wanted to pitch an idea real fast. No idea if it was covered at a tor meeting at some point.
For bridge relay operators, such as those with very low bandwidth, it may be worth it to keep lower-than-consensus-restrictions using the DOS flags here https://2019.www.torproject.org/docs/tor-manual.html.en#DoSCircuitCreationEn... -- but this might be higher maintenance though, as keeping up to date with consensus params may be needed often.
Does it seem worth it or necessary to have a multiplier variable? Like bridges with low bandwidth can set, for example,
DoSConsensusMultiplier 0.75
In order to lower all or select values by 75%, rounding up to the nearest whole number or the configured floor value ( perhaps DoSConsensusMultiplierFloor 2 ...?).
If there is DoS on bridges on domestic connections, or connections with very low throughput, then handling (D)DoS at an application layer becomes futile - it will simply overload the NIC.
But for bridges on at least 100MbE ports, this would be a nice addition.
On Sunday, August 11th, 2024 at 9:20 PM, pasture_clubbed242--- via tor-relays tor-relays@lists.torproject.org wrote:
Since it is still all fresh in our heads, I wanted to pitch an idea real fast. No idea if it was covered at a tor meeting at some point.
For bridge relay operators, such as those with very low bandwidth, it may be worth it to keep lower-than-consensus-restrictions using the DOS flags here https://2019.www.torproject.org/docs/tor-manual.html.en#DoSCircuitCreationEn... -- but this might be higher maintenance though, as keeping up to date with consensus params may be needed often.
Does it seem worth it or necessary to have a multiplier variable? Like bridges with low bandwidth can set, for example,
DoSConsensusMultiplier 0.75
In order to lower all or select values by 75%, rounding up to the nearest whole number or the configured floor value ( perhaps DoSConsensusMultiplierFloor 2 ...?).
tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Sorry, slight correction, instead of NIC / network card, I meant the internet connection established by the modem itself.
Same for cable and fiber, but those usually have higher download speed, and that's what it comes down to when facing DoS attacks, how many megabytes an attacker needs to put on the line for it to drop or get null-routed automatically.
On Wednesday, August 14th, 2024 at 3:47 PM, George Hartley via tor-relays tor-relays@lists.torproject.org wrote:
If there is DoS on bridges on domestic connections, or connections with very low throughput, then handling (D)DoS at an application layer becomes futile - it will simply overload the NIC.
But for bridges on at least 100MbE ports, this would be a nice addition.
On Sunday, August 11th, 2024 at 9:20 PM, pasture_clubbed242--- via tor-relays tor-relays@lists.torproject.org wrote:
Since it is still all fresh in our heads, I wanted to pitch an idea real fast. No idea if it was covered at a tor meeting at some point.
For bridge relay operators, such as those with very low bandwidth, it may be worth it to keep lower-than-consensus-restrictions using the DOS flags here https://2019.www.torproject.org/docs/tor-manual.html.en#DoSCircuitCreationEn... -- but this might be higher maintenance though, as keeping up to date with consensus params may be needed often.
Does it seem worth it or necessary to have a multiplier variable? Like bridges with low bandwidth can set, for example,
DoSConsensusMultiplier 0.75
In order to lower all or select values by 75%, rounding up to the nearest whole number or the configured floor value ( perhaps DoSConsensusMultiplierFloor 2 ...?).
tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays____________...
tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
tor-relays@lists.torproject.org
-
George Hartley -
pasture_clubbed242＠simplelogin.com