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

[vxfemboy]

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.