[$ ] doc: bgp-resilience-for-tor-relay-operators

Scope and assumptions

This is an analytical / planning doc rather than a step-by-step procedure: it describes how to think about the BGP topology of the Tor network when choosing where to host a relay. The goal is to maximise the network-diversity contribution per relay rather than to maximise raw bandwidth — the latter is mostly already saturated by a small number of operators on a small number of upstreams (Hetzner, OVH, DigitalOcean), and adding one more relay there is operationally cheap but provides diminishing diversity benefit. [Tor Project — relay diversity statistics, Tor Metrics]

This doc is for operators who already understand BGP at a working level. If “AS path”, “RPKI ROA”, “IXP”, and “ROV” are not familiar terms, read the BGP RFC bundle first [RFC 4271] [RFC 6480] and the Tor Project’s relay-diversity FAQ. This is not an introduction to BGP.

Baseline assumptions:

• The operator already runs at least one Tor relay per run-non-exit-tor-relay and is considering scaling to two or more.
• The relays target the non-exit role; the same diversity reasoning applies to exit relays but with a much bigger legal-and-abuse-handling overlay we don’t cover here.
• The operator does NOT operate their own AS or have a routed prefix — relays sit on upstream-provider-owned IP space. This is the typical case; the few operators with their own ASN make different trade-offs.

Why AS diversity matters for Tor

Tor’s circuit-construction algorithm picks three relays (guard, middle, exit) such that no two are in the same MyFamily. It also considers /16 IP-space proximity but does NOT consider AS-path or country at the circuit-construction layer. [Tor path-spec — circuit construction] The result: relays in the same AS are NOT considered the same family by Tor’s picker, even though for traffic-confirmation purposes an attacker who controls or observes that AS effectively sees both ends.

This is the well-documented “AS-level adversary” weakness. The Tor academic literature has measured the impact: an AS that hosts ~20% of relay capacity is in a position to deanonymise a non-trivial fraction of circuits via traffic-confirmation. [Murdoch & Zieliński, 'Sampled Traffic Analysis by Internet-Exchange-Level Adversaries', PETS 2007] The mitigation is operator-side diversity: spread relays across many ASes, ideally across many countries, and avoid concentrating on the small set of bandwidth-cheap providers.

The brand’s working calculus for a multi-relay operator:

The brand’s listed offshore providers are deliberately spread across distinct ASes:

• Iceland: AS47621 (Advania Data Centers), AS50613 (1984 Hosting), AS44486 (FlokiNET) — all separate operationally.
• Romania: AS39743 (Voxility), AS47331 (TTM)
• Switzerland: AS25053 (Hostpoint), AS41441 (Adminforge), AS199524 (GTHost)

Cross-checking these on bgp.tools reveals they peer at different IXPs and have different transit chains; an operator running one relay in each provides materially better diversity than running three relays at one provider in three different cities.

Step 1 — survey the AS-level topology of your candidate VPS providers

Before signing up with a new provider, look up its AS:

AS      | IP               | BGP Prefix          | CC | Registry | Allocated  | AS Name
47621   | 198.51.100.1     | 198.51.100.0/22     | IS | RIPE     | 2010-04-19 | ADVANIA-EHF

Then look up that AS’s transit relationships:

# Via the bgp.tools website (not scriptable cleanly), or via RIPEstat:
curl -s 'https://stat.ripe.net/data/as-overview/data.json?resource=AS47621' \
  | python3 -m json.tool

The fields that matter:

• transit_4 — list of upstream ASes providing IPv4 transit. An AS with 1-2 upstreams has a single point of failure; 3+ is more resilient.
• transit_6 — same for IPv6.
• peers_4 — count of peer ASes. A high-peer-count AS (typically because it’s at multiple IXPs) provides better path-diversity for traffic to and from your relay.
• announcing_prefixes_4 — count of distinct prefixes the AS announces. Usually irrelevant for relay placement, but a sanity check that the AS actually does any routing.

The brand’s rule of thumb: prefer ASes with 3+ transits, 30+ peers, IXP membership at 2+ exchanges. Advania, FlokiNET, and Voxility all qualify.

Step 2 — check RPKI ROA coverage for the relay’s prefix

RPKI Route Origin Authorisation (ROA) is the cryptographic statement that AS X is authorised to originate prefix Y/n. [RFC 6480] A prefix without ROA coverage is more vulnerable to BGP hijacking — an attacker announces the same prefix from a different AS, the more-specific or shorter-path route wins, and traffic destined for your relay routes to the attacker. With ROA, RPKI-validating routers (a growing fraction of the global routing table) reject the unauthorised announcement.

Check ROA coverage:

# Via routinator (open-source RPKI validator) if you've installed it:
routinator vrps | grep '198.51.100.0/22'

# Or via the public RPKI Routing Observatory:
curl -s 'https://stat.ripe.net/data/rpki-validation/data.json?resource=AS47621&prefix=198.51.100.0/22' \
  | python3 -m json.tool

The validating_roas field should be non-empty. If it’s empty, the prefix has no ROA — ask the upstream when they’ll publish one. Most credible offshore providers in 2026 have ROAs published; if a candidate provider doesn’t, factor that into the diversity calculus.

Step 3 — choose providers that participate in IXPs

A provider connected to multiple internet exchanges (IXPs — DE-CIX, AMS-IX, LINX, NETNOD-Stockholm, etc.) has multiple paths to the rest of the internet, which means circuits transiting your relay have more route diversity at the BGP layer. [Bischof et al., 'Network forensics on BGP route hijacking events', Internet Measurement Conference 2018]

Look up the provider’s IXP membership at PeeringDB:

"name": "Advania Data Centers",
"ixlan_set": [
{"id": 218, "name": "NETNOD Stockholm"},
{"id": 304, "name": "STHIX Stockholm"},
{"id": 822, "name": "RIX Reykjavik"}
]

Three IXPs is good. Single-IXP or no-IXP providers are usually small operators dependent on a single transit upstream — fine for some workloads, less ideal for a Tor relay.

Step 4 — monitor for route leaks affecting your relay’s prefix

Once your relay is operational, the threat to monitor for is BGP hijacks targeting the relay’s IP. Tooling:

bgpstream / bgpalerter

bgpalerter is an open-source BGP monitor that watches RIS (RIPE Routing Information Service) and Routeviews for unexpected announcements of prefixes you care about. [bgpalerter — RIPE NCC project]

Install:

apt install -y nodejs npm
npm install -g bgpalerter

Configure with your relay’s IP / prefix:

# ~/.bgpalerter/config.yml
monitors:
  - file: monitorHijack
    channel: hijack
    name: hijack-monitor
    params:
      thresholdMinPeers: 2
  - file: monitorVisibility
    channel: visibility
    name: visibility-monitor
    params:
      thresholdMinPeers: 6

reports:
  - file: reportEmail
    channels: [hijack, newprefix, visibility, path]
    params:
      smtp:
        host: smtp.example.invalid
        port: 587
      from: bgpalerter@example.invalid
      to: operator@example.invalid

monitoredPrefixes:
  - prefix: 198.51.100.0/22
    description: Relay is01-cypher prefix
    asn: 47621
    ignoreMorespecifics: false

Run as a service:

bgpalerter run --config ~/.bgpalerter/config.yml

Email alerts arrive when an AS other than 47621 starts announcing your prefix or when visibility drops below the configured peer threshold (a sign the prefix has been withdrawn from a meaningful chunk of the network).

RIPE Atlas measurements

For a more involved monitoring posture, use RIPE Atlas measurements to continuously verify reachability of your relay from globally-distributed probes. The basic pattern: schedule a recurring traceroute or HTTP measurement to your relay’s IP, alert if more than X% of probes fail.

# Via the ripe-atlas-tools CLI:
apt install -y ripe-atlas-tools
ripe-atlas measure traceroute --target 198.51.100.1 --interval 600 --probes 50

This is overkill for one relay; reasonable when running 5+.

Step 5 — when to migrate a relay to a different AS

Migration is operationally annoying — a new VPS, a new fingerprint, a 4-week consensus-weight ramp from scratch. Don’t migrate casually. Triggers that justify migration:

1. Your AS has been route-hijacked twice in 12 months. This isn’t your operational failure, but it does mean the AS’s BGP hygiene is suspect; circuits transiting it are at elevated risk.
2. The AS has been added to multiple network-level allowlists/blocklists. If your relay’s IP keeps getting flagged by content-providers or by Tor’s BadExit detection (rare for non-exit relays, but possible if the AS is shared with abusive operators), the relay’s effective contribution drops.
3. The AS now hosts > 5% of total Tor capacity. The Tor Project considers this a concentration risk; the network as a whole benefits when high-capacity ASes shed relays to less-concentrated places.
4. Upstream provider has changed AUP and now disallows Tor. Forces migration regardless.

Migration shape: provision a new VPS at a different AS, bring up a new Tor relay there, run BOTH relays for ~30 days (the new one ramps up while the old one wind-downs), then decommission the old one. The old relay’s identity-key is destroyed at decommission — do NOT migrate the identity-key, the new relay is a genuinely new identity from the network’s perspective.

Step 6 — operating the family across distinct ASes

A multi-relay operator with relays in distinct ASes still needs to declare the family relationship correctly via MyFamily in each torrc (per run-non-exit-tor-relay step 4). The family declaration is what tells the Tor circuit picker “these relays share an operator; don’t pick two of them in the same circuit” — without it, the picker might select two of yours despite the AS diversity, which doesn’t defeat AS-level adversaries but violates the operator-diversity load-balancing the network depends on.

The family is independent of the AS placement: a 3-relay operator with one relay each in IS / RO / CH still declares all three as one family, even though the AS-level adversary properties differ for each combination.

Step 7 — four ongoing monitoring checks

Check 1 — RIS-Live route announcements

Once a month, query RIS-Live (RIPE’s BGP feed) for announcements of your relay’s prefix:

curl -s "https://ris-live.ripe.net/v1/stream/?format=json&type=UPDATE&prefix=198.51.100.0/22" \
  | head -100

You should see your AS originating; if you see a different AS, investigate immediately.

Check 2 — Tor consensus weight stable

Per Tor Metrics search for your fingerprint, the consensus weight should be stable (within ±20% week-over-week once the relay is past the 4-week ramp). Sudden drops correlate with reachability issues caused by upstream changes.

Check 3 — relay flag set unchanged

Stable, Fast, Guard flags should persist. Loss of Stable typically means uptime fell below the threshold (recent restarts, or upstream connectivity blips). Loss of Guard is rarer and usually means consensus weight is now below the percentile threshold for guard election.

Check 4 — RPKI ROA still valid

ROAs expire (typical lifetime: 1-3 years). Re-check ROA validity on a monthly cadence:

curl -s 'https://stat.ripe.net/data/rpki-validation/data.json?resource=AS47621&prefix=198.51.100.0/22' \
  | python3 -c 'import json,sys; print(json.load(sys.stdin)["data"]["status"])'

Expected: "valid". If "unknown" or "invalid", the ROA has lapsed or the prefix-AS pairing has changed; ask upstream to refresh.

Closing — what to do next

The BGP-diversity posture for your relay set is now articulable. Order of next steps:

1. Subscribe to the tor-relays mailing list — bandwidth-authority deployments and consensus-affecting changes are announced there with operator-relevant detail.
2. Add bgpalerter as a permanent service alongside the relay; the email alerts cost nothing and catch the rare BGP hijack within minutes.
3. Read the academic AS-level-adversary papers semi-annually — the literature evolves as Tor researchers refine the threat model and as global BGP hygiene improves (or, occasionally, regresses).
4. If you scale to 5+ relays, consider acquiring an ASN of your own (the brand operator-trees include a couple of operators who do this; the trade-offs are non-trivial — own ASN means own RIR membership, own RPKI publication, own peering negotiations — but it eliminates the “upstream changes AUP” risk vector).

The point of this work is the network-diversity contribution, not the bandwidth contribution. A 100 KB/s relay on a unique-AS-in-a-rare-jurisdiction is a more valuable network resource than a 100 MB/s relay on a saturated provider.