This is an automated email from the git hooks/post-receive script.
ahf pushed a commit to branch main in repository torspec.
commit 38469b0626084cd654009355c7615d2c805e2d21 Author: Mike Perry mikeperry-git@torproject.org AuthorDate: Thu May 25 13:12:00 2023 +0000
Prop327: Onion service rate limiting is not congestion control.
It is just rate limiting. We could apply real Prop324 congestion control to the intro circuit, but so far we have not done so. --- proposals/327-pow-over-intro.txt | 11 +++++------ 1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/proposals/327-pow-over-intro.txt b/proposals/327-pow-over-intro.txt index 8f17753..8723cb9 100644 --- a/proposals/327-pow-over-intro.txt +++ b/proposals/327-pow-over-intro.txt @@ -13,12 +13,11 @@ Status: Draft
So far our attempts at limiting the impact of introduction flooding DoS attacks on onion services has been focused on horizontal scaling with - Onionbalance, optimizing the CPU usage of Tor and applying congestion control - using rate limiting. While these measures move the goalpost forward, a core - problem with onion service DoS is that building rendezvous circuits is a - costly procedure both for the service and for the network. For more - information on the limitations of rate-limiting when defending against DDoS, - see [REF_TLS_1]. + Onionbalance, optimizing the CPU usage of Tor and applying rate limiting. + While these measures move the goalpost forward, a core problem with onion + service DoS is that building rendezvous circuits is a costly procedure both + for the service and for the network. For more information on the limitations + of rate-limiting when defending against DDoS, see [REF_TLS_1].
If we ever hope to have truly reachable global onion services, we need to make it harder for attackers to overload the service with introduction