Missed table headers, sending again Relay Time frame · UTC All directory starts HS attempts HS requests/s · lifetime mean Other / unclassified Other / unclassified starts/s · lifetime mean HS requests · recognized hop HS requests · unrecognized hop Repeat HS requests Circuits with repeat HS Relay 01 20 Oct 2026 05:32:50.240 → 22 Oct 2026 14:56:40.395 (57.40 hours) 309,085 17,175 0.0831 291,910 1.4127 17,165 10 0 0 Relay 02 20 Oct 2026 06:20:04.510 → 22 Oct 2026 14:56:30.646 (56.61 hours) 409,883 15,605 0.0766 394,278 1.9348 15,596 9 0 0 Relay 03 20 Oct 2026 18:57:50.110 → 22 Oct 2026 14:56:41.006 (43.98 hours) 46,596 1,586 0.0100 45,010 0.2843 1,477 109 0 0 Relay 04 20 Oct 2026 18:59:19.620 → 22 Oct 2026 14:57:23.013 (43.97 hours) 378,027 51,201 0.3235 326,826 2.0648 50,952 249 0 0 Relay 05 20 Oct 2026 19:00:51.160 → 22 Oct 2026 14:57:15.105 (43.94 hours) 327,540 12,161 0.0769 315,379 1.9937 12,045 116 0 0 Relay 06 20 Oct 2026 19:02:12.690 → 22 Oct 2026 14:57:16.881 (43.92 hours) 289,399 27,026 0.1709 262,373 1.6595 27,000 26 0 0 Relay 07 20 Oct 2026 19:03:30.190 → 22 Oct 2026 14:56:28.144 (43.88 hours) 33,485,952 2,333,969 14.7740 31,151,983 197.1920 2,291,822 42,147 1,959,218 360,542 Relay 08 20 Oct 2026 19:04:46.830 → 22 Oct 2026 14:56:50.323 (43.87 hours) 348,007 25,998 0.1646 322,009 2.0390 25,855 143 0 0 Relay 09 20 Oct 2026 19:06:05.750 → 22 Oct 2026 14:56:42.229 (43.84 hours) 64,436 595 0.0038 63,841 0.4045 550 45 0 0 Relay 10 20 Oct 2026 19:07:24.640 → 22 Oct 2026 14:57:16.120 (43.83 hours) 325,052 17,687 0.1121 307,365 1.9479 17,477 210 0 0 On Thursday, October 22nd, 2026 at 8:31 AM, Tor at 1AEO <tor@xxxxxxxx> wrote: > Amazing progress! We have 4 new metrics gathering but not all yet. Haven't experimented with enforcement yet. > > Time frame last ~36 hours > > Relay 01 20 Oct 2026 05:32:50.240 → > 22 Oct 2026 14:56:40.395 > (57.40 hours) 309,085 17,175 0.0831 291,910 1.4127 17,165 10 0 0 > Relay 02 20 Oct 2026 06:20:04.510 → > 22 Oct 2026 14:56:30.646 > (56.61 hours) 409,883 15,605 0.0766 394,278 1.9348 15,596 9 0 0 > Relay 03 20 Oct 2026 18:57:50.110 → > 22 Oct 2026 14:56:41.006 > (43.98 hours) 46,596 1,586 0.0100 45,010 0.2843 1,477 109 0 0 > Relay 04 20 Oct 2026 18:59:19.620 → > 22 Oct 2026 14:57:23.013 > (43.97 hours) 378,027 51,201 0.3235 326,826 2.0648 50,952 249 0 0 > Relay 05 20 Oct 2026 19:00:51.160 → > 22 Oct 2026 14:57:15.105 > (43.94 hours) 327,540 12,161 0.0769 315,379 1.9937 12,045 116 0 0 > Relay 06 20 Oct 2026 19:02:12.690 → > 22 Oct 2026 14:57:16.881 > (43.92 hours) 289,399 27,026 0.1709 262,373 1.6595 27,000 26 0 0 > Relay 07 20 Oct 2026 19:03:30.190 → > 22 Oct 2026 14:56:28.144 > (43.88 hours) 33,485,952 2,333,969 14.7740 31,151,983 197.1920 2,291,822 42,147 1,959,218 360,542 > Relay 08 20 Oct 2026 19:04:46.830 → > 22 Oct 2026 14:56:50.323 > (43.87 hours) 348,007 25,998 0.1646 322,009 2.0390 25,855 143 0 0 > Relay 09 20 Oct 2026 19:06:05.750 → > 22 Oct 2026 14:56:42.229 > (43.84 hours) 64,436 595 0.0038 63,841 0.4045 550 45 0 0 > Relay 10 20 Oct 2026 19:07:24.640 → > 22 Oct 2026 14:57:16.120 > (43.83 hours) 325,052 17,687 0.1121 307,365 1.9479 17,477 210 0 0 > > > >Are you able to tell me if these BEGIN_DIR are for onion service descriptors as in your relay being an HSDir? Or they are normal regular BEGIN_DIR requests from a client asking for other directory information (ex: consensus)? > > Both. Non HSDir seems to be much larger, 33M to 2M, but data is early / small sample. Will have higher confidence in next 48 hours. > Source: Relay 07 in the table. > > > > if the channel those circuits are on is authenticated vs not. > Both. HS requests: 2M "authenticated" vs 42K "not authenticated". > > We called "not authenticated" as "unrecognized hop" since the relay fingerprint is not in consensus and is a direct connection. We called "authenticated" as "recognized hop". > Source: Relay 07 in the table. > > > > Also, that limit you put in is global to all circuits or per circuit? > > We'd prefer both. Seeing both patterns. Attack seems fairly sophisticated since starting in June, exploring different variations. > > > Is that maybe part of an attack? > Most likely. Most unusual resource exhaustions are part of the various attacks happening since late June. > We published a lot of details on ~4 different types: https://1aeo.com/blog/circuit-building-dos-anatomy-june-2026.html#wave-3-malformed > > > >Is there a good way to detect such attacks? > Unfortunately, C Tor metrics has many blind spots. Not possible to categorize everything correctly until metrics expand. Proposing expanding around BEGIN_DIR flood happening, likely targeted at HSDir relays serving .onion descriptors. > https://gitlab.torproject.org/tpo/core/tor/-/work_items/41460 > Separate issue is that under attack, main thread is too busy to provide metrics so they get dropped and relay operator is blind. Proposing moving metrics off main thread into worker pool: https://gitlab.torproject.org/tpo/core/tor/-/work_items/41458 > > >Are relays known which have HSDir and do such censorship attacks? > Yes, relays are known publicly by HSDir flags but not publicly known by which onion services they support. Unsure whether attacks are censorship focused, somebody upset as a specific onion service, somebody wants to send some relays offline, or something else. > > > > On Thursday, October 22nd, 2026 at 6:42 AM, David Goulet via tor-relays <tor-relays@xxxxxxxxxxxxxxxxxxxx> wrote: > > > On 22 Oct (09:00:27), TinCan via tor-relays wrote: > > > Hi everyone, > > > > Hello TinCan! > > > > dgoulet here, from the Tor network team. First, thanks for this report, very > > useful! > > > > We are currently working on several fixes for this ongoing BEGIN_DIR DDoS badly > > affecting the network. Next release (soon!) will most likely have them in. > > > > It will be a fun one because to be effective, we will need most of the relays > > to upgrade so to avoid degradation. > > > > I have couple questions for you. > > > > > > > > The attack started targeting my relay yesterday at 12:00 UTC, 15 hours after > > > the relay achieved the HSDir flag. This time I had implemented a rate cap (on > > > version 0.4.9.14) for BEGIN_DIR which allowed me to try out a few different > > > things. The rate limiter has a configurable rate/burst limit and two > > > configurable defense types: > > > Either > > > - Refuse the stream by sending END_STREAM_REASON_NOTDIRECTORY back to the offender > > > Or > > > - Close the offending circuit by sending -END_CIRC_REASON_RESOURCELIMIT back to the offender > > > > > > At the beginning of the attack I was limiting BEGIN_DIR requests to 200/s and > > > refusing anything beyond that. The attacker was spawning 300 circuits per > > > second on average and hitting me with ~55,000 BEGIN_DIR requests per second > > > on average. After 8 hours of being attacked the relay logged "1647224804 > > > BEGIN_DIR rejected". During these first 8 hours, the relay remained > > > responsive, with memory usage staying flat at or under 1000MB, main thread > > > CPU usage 20-80% and traffic 200-850 Mbps with a bandwidth ratio of around > > > 2:1 down:up. CPU usage was highly correlated with the amount of traffic being > > > moved. There were also occasional latency spikes while the bandwidth was > > > close to the Gbit line rate. > > > > Are you able to tell me if these BEGIN_DIR are for onion service descriptors as > > in your relay being an HSDir? Or they are normal regular BEGIN_DIR requests > > from a client asking for other directory information (ex: consensus)? > > > > Also, that limit you put in is global to all circuits or per circuit? > > > > > > > > At 8 hours into the attack I reloaded Tor with the other defense type (close > > > BEGIN_DIR circuits) and lowering the limit to 100 requests per second. > > > Bandwidth usage immediately dropped to 80-100 Mbps in both directions and CPU > > > usage plummeted to <10%. The attack now changed its strategy and started > > > creating circuits at an increasing rate, topping out at 1500 circuits per > > > second, still no match for 12 Ryzen cores though. At the time of writing the > > > attacker is still spawning around 1000 circuits per second and the main > > > thread is at 10% of one core with the circuit work being spread out over the > > > rest of the cores. > > > > The circuit rate here is wild! We have DoS defenses in place for rate limiting > > circuit creation per IP address so are these 1000/sec circuits coming from 1000 > > different addresses? > > > > Note here that if they come from tor clients, you will have a single > > **unauthenticated channel** (tor channel) per client IP address. This would > > imply they are a single hop request to your relay so client -> your relay. And > > thus generic directory requests such as consensus fetch for instance. > > > > If they come from a relay, it would be on an **authenticated** channel and this > > means these BEGIN_DIR request come from a multi-hop circuit implying onion > > service descriptor get/post. > > > > I'm giving you these details because if you point a LLM at your 500MB debug > > logs ;), it is possible to tell if the channel those circuits are on is > > authenticated vs not. > > > > The difference is very important here because in both cases, we will apply > > different fixes. And it would be very useful to learn what you are seeing. > > > > Thanks a lot for your help! If you want to chat, I'm "dgoulet" on our #tor-dev > > IRC channel which you can access via Matrix as well. > > > > Cheers! > > David > > > > -- > > Fwj9yfk1MF4rtih0k2x/SemjPPhGxtNXDVaAx9n7TgQ= > > _______________________________________________ > > tor-relays mailing list -- tor-relays@xxxxxxxxxxxxxxxxxxxx > > To unsubscribe send an email to tor-relays-leave@xxxxxxxxxxxxxxxxxxxx > >
Attachment:
publickey - tor@1aeo.com - 0x9288289B.asc
Description: application/pgp-keys
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ tor-relays mailing list -- tor-relays@xxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to tor-relays-leave@xxxxxxxxxxxxxxxxxxxx