Routing all traffic through rendezvous mailboxes with a put/get interface prevents direct DoS against end hosts and hides service host addresses; each service deploys many mailboxes with a randomly chosen sequence per connection, so an attacker can disrupt at most a fraction of any given flow even with substantial resources.

By integrating onion routing at the ISP/AS boundary (exactly one onion router per AS hop), the specific relay used is neither specified in the protocol nor addressable by end hosts, eliminating the enumerable relay list that makes overlay Tor blockable. The end host only knows ISP public keys, not individual relay addresses.

§5 defense

Encrypting traffic at the application layer still discloses communicating parties to every ISP along the path; overlay anonymization is subject to blacklisting of exit nodes and traffic analysis. The paper argues that effective privacy requires building anonymity into the network routing layer itself, with the necessary tradeoff being hardware cost and routing inefficiency for privacy-requiring circuits.

§1, §8 defense

Tor-like anonymizing overlays are easily censored because they rely on centralized, publicly visible relay lists; governments can blacklist Tor nodes or monitor all Tor exit traffic so that traffic analysis can reveal the source. Traffic to or from Tor 'essentially advertises itself as probably worth tracking.'

§1–§2 detection

The design guarantees that as long as an end host can reach any non-censoring ISP, it can trampoline to any service; the anonymity properties make it difficult for ISPs to selectively block flows without cutting off the end host from the outside world entirely. Wikileaks-like services require only one willing authority for name resolution, not universal cooperation.

§7.1 defense