Tor Relay Deployment Dilemma: Handle BGP yourself or have it done upstream to announce your own AS?
I'm currently evaluating the best approach for having my AS announced with my owned (not rented) IPv4 addresses, and I've observed that hosting providers have different preferences for handling BGP sessions. For example, one provider requires that the BGP session be managed on the same server running the Tor relays, while another handles the announcement with my AS entirely on their side. This inconsistency makes it challenging to determine the most effective approach.
I'm seeking guidance on the following points (or others you think are helpful):
-
When given the option: Should I manage the BGP session myself, or is it preferable to delegate it to the upstream provider whenever possible?
-
When required to manage BGP myself:
-
To conserve CPU/RAM resources for Tor, is it advisable to only use a default route (0.0.0.0/24) rather than a full routing table, relying on the upstream provider for full routing?
-
Under what circumstances should I implement multi-homed strategies myself versus allowing the upstream provider to manage them?
-
Are there best practices for route filtering or failover management?
-
What are your experiences regarding the compute and memory requirements for these configurations?
-
What are some preferred monitoring solutions? bgpmon.net doesn't seem free...
Helpful read and suggestions at the end from this 6 year old article from nusenu, but couldn't find too much beyond this: https://nusenu.medium.com/how-vulnerable-is-the-tor-network-to-bgp-hijacking...
I'm already using ROA and RPKI via ARIN for each /24 and limit max length to /24 to help as well.
"The Tor exit fraction located in /24 prefixes is much higher than the guard capacity. So hijacks against exit capacity might be harder than attacks against guard capacity." - Seems also good to have /24 prefixes for guards, not just exits.
Thanks!
Hej,
When given the option: Should I manage the BGP session myself, or is it preferable to delegate it to the upstream provider whenever possible?
Depends on how much interest you have in BGP and what the upstream charges for managed BGP.
To conserve CPU/RAM resources for Tor, is it advisable to only use a default route (0.0.0.0/24) rather than a full routing table, relying on the upstream provider for full routing?
If you are single homed, receiving full v4 and v6 tables is imho a waste of cpu cyles. I'd go for receiving v4 and v6 default routes.
But playing around with BGP would totally justify full tables :)
Under what circumstances should I implement multi-homed strategies myself versus allowing the upstream provider to manage them?
For multi-homed you'd need two different upstream providers.
Your transit is hopefully multi-homed anyway and depending on their BGP community traffic engineering capabilties you can traffic engineer yourself quite a lot apart from using as-path prepends and MED.
https://www.noction.com/blog/bgp-community-based-traffic-engineering
Are there best practices for route filtering or failover management?
If you only receive default routes you save yourself the trouble for elaborated filtering.
Otherwise take a look here: https://bgpfilterguide.nlnog.net/
What are your experiences regarding the compute and memory requirements for these configurations?
memory for a full table is a couple of 100 MB. CPU cycles depend on the amount of route changes and the filtering you do. All in all it is not very resource heavy compared to tor traffic forwarding and crypto stuff.
What are some preferred monitoring solutions? bgpmon.net doesn't seem free...
you could host https://github.com/nttgin/BGPalerter yourself (it is using ripe ris as data source)
https://packetvis.com/ is a hosted bgpalerter for free
relatively newish: https://bgpwatch.cgtf.net/
you could ask bgp.tools for a free account
have fun!
tor-relays@lists.torproject.org
-
Fran -
Tor at 1AEO