[tor-relays] Re: Circuit-building DoS wave: 20x peak, 8x sustained circuits on guard relays since Jun 25

@Logforme — stock defenses, nothing custom: Tor's built-in DoS subsystem, driven by consensus parameters every relay applies by default (a source holding a second connection may create circuits at 2/sec with a burst of 60, and keep at most 50 concurrent connections per tor process). You can watch them fire in tor_relay_dos_total (via Tor MetricsPort). Your ~1.5x is consistent with the same flood — intensity varies hugely by position and weight, and our guard-only fleet sits at the extreme end. We haven't looked for a 2-hour periodicity; our circuits recede and resurge on a multi-day scale.

What's firmed up since my first mail:

* Three attacks offset in time, not one: an onion-service INTRODUCE2 flood (peaked Jun 27, then collapsed), the main circuit-creation flood (onionskins peaked Jun 29 at ~11.5x, ~97% ntor_v3; open circuits Jul 5 at ~20x), and since Jul 5 malformed, protocol-violating circuits — tor_relay_circ_proto_violation_total surged >150x, peaked Jul 6, still running at dozens of times baseline.

* Network-wide, in the public archives: relays signing overload-general climbed from a 2–3% baseline to 8.2% on Jun 28, then a second wave to 12.2% (1,254 relays) on Jul 12. It lands on guards: guard-only overload hit ~17.7% by Jul 12 while pure exits stayed far lower. Running-flag churn roughly tripled — ~5,900 distinct relays flapped Running at least twice vs ~2,000 in an equal pre-flood window: saturated relays failing reachability probes while still relaying, not going down.

* The cost to absorb it: busiest hosts pegged at 90–99% CPU for two weeks (raw ntor cost), resident memory ~2.5x fleet-wide (~8x on the worst relays) with kernel OOM kills on the hardest-hit hosts (every process auto-restarted), and real onionskin drops only on our smallest host (7.6% of its own load; zero everywhere else). Refinements to my first mail: onionskins settled at 6.3x avg / 11.5x peak, streams 2.5x avg / 6.0x peak (the early 7x/12x were point-in-time reads).

Full write-up in four posts — every number is an aggregate counter or reproducible from CollecTor/Onionoo:

* Network-wide picture, public data alone: https://1aeo.com/blog/tor-network-dos-wave-june-2026.html

* Anatomy of the attack (the three waves): https://1aeo.com/blog/circuit-building-dos-anatomy-june-2026.html

* What absorbing it costs an operator: https://1aeo.com/blog/circuit-building-dos-fleet-cost-june-2026.html

* Measurement traps + what Tor could change: https://1aeo.com/blog/defending-against-circuit-dos-june-2026.html

Chart-reproduction scripts: https://github.com/1aeo/1aeo-blog-charts

Attached: the three waves in one picture, Tor's defenses firing per vector, and the network-wide overload curve.

On Monday, July 13th, 2026 at 12:56 PM, Logforme via tor-relays <tor-relays@xxxxxxxxxxxxxxxxxxxx> wrote:

On 7/10/26 18:44, Tor at 1AEO via tor-relays wrote:

Summary:

- Our guard relay family has been under a sustained circuit-building DoS wave since 2026-06-25 23:00 UTC, still ongoing: open circuits at 20x peak and 8x sustained, onionskin load 7x, stream creation 12x -- but bandwidth only +20%. Millions of near-idle circuits. See the attached charts (fleet open circuits, onionskin processing, and bandwidth, Jun 10 - Jul 10).

- Impact contained so far: tor's DoS defenses engaged, brief onionskin drops on a small subset of relays, consensus flags dipped ~5%, zero TCP port exhaustion and zero global rate-limit events.

<...>

Is anyone else seeing this since Jun 25? Happy to share more detail.

I run the non-exit relay 8F6A78B1EA917F2BF221E87D14361C050A70CCC3

I have seen weird circuit behavior since about July 1st. Number of circuits are much higher than normal, about 120k instead of 80k. Every 2 hours, on the hour, the number of circuits drops before quickly climbing back to the high level.

What do you mean by "tor's DoS defenses engaged"? The automatic ones or something of your own?