3c.3 relay: TLS-front path has no rate limiting (per-connection RelaySend cap) #65

New issue

Open

opened 2026-07-14 00:59:30 +00:00 by vxfemboy · 0 comments

vxfemboy commented

2026-07-14 00:59:30 +00:00

(Migrated from github.com)

Summary

The 3c.3 relay's TLS-front path has no rate limiting. The UDP path's RendezvousServer::rate_ok (per-source token bucket) is only invoked from handle (UDP). The TLS discriminator calls register_if_fresh_tls directly and conn_tunnel::route forwards RelaySend with no per-connection or per-source cap. A single upgraded TLS peer can pump unlimited RelaySend frames through the blind relay.

This compounds the (now-fixed) per-pair backpressure: deliveries are best-effort try_send (drop-on-full), so an abuser can't wedge the relay, but can still consume CPU/bandwidth forwarding.

Severity

Minor for a blind best-effort relay, but worth an explicit per-connection RelaySend budget given the active-adversary threat model this milestone targets. The fixed synthetic src = 0.0.0.0:0 on the TLS path also makes per-source limiting meaningless there, so a per-connection (per-task) counter is the right granularity.

Fix directions

A per-connection token bucket in run_tunnel (frames/sec), dropping or tearing down on sustained abuse.
Or a global forwarded-frames/sec cap across the TLS front.

Surfaced by the 3c.3 final whole-branch review.

## Summary The 3c.3 relay's TLS-front path has **no rate limiting**. The UDP path's `RendezvousServer::rate_ok` (per-source token bucket) is only invoked from `handle` (UDP). The TLS discriminator calls `register_if_fresh_tls` directly and `conn_tunnel::route` forwards `RelaySend` with no per-connection or per-source cap. A single upgraded TLS peer can pump unlimited `RelaySend` frames through the blind relay. This compounds the (now-fixed) per-pair backpressure: deliveries are best-effort `try_send` (drop-on-full), so an abuser can't wedge the relay, but can still consume CPU/bandwidth forwarding. ## Severity Minor for a blind best-effort relay, but worth an explicit per-connection `RelaySend` budget given the active-adversary threat model this milestone targets. The fixed synthetic `src = 0.0.0.0:0` on the TLS path also makes per-source limiting meaningless there, so a per-connection (per-task) counter is the right granularity. ## Fix directions - A per-connection token bucket in `run_tunnel` (frames/sec), dropping or tearing down on sustained abuse. - Or a global forwarded-frames/sec cap across the TLS front. Surfaced by the 3c.3 final whole-branch review.