From 38469b0626084cd654009355c7615d2c805e2d21 Mon Sep 17 00:00:00 2001 From: Mike Perry Date: Thu, 25 May 2023 13:12:00 +0000 Subject: [PATCH] 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