How vulnerable is the Tor Network to BGP Hijacking Attacks?

How resilient are the BGP prefixes containing Tor relays and what properties do we consider?

We categorize prefixes by analyzing the following properties

BGP Prefix Length

The prefix length is relevant in the context of hijacks because the longest prefix wins. This has an impact on whether a more-specific prefix hijacking attack is feasible. If you/your ISP is announcing /22 prefixes but the attacker announces the same space using multiple more-specific /24 prefixes his routes will generally and globally win.

RPKI Validity State (ROAs)

The resource public key infrastructure (RPKI) provides signed data about which AS is authorized to announce what prefixes (and optional max prefix length). Organizations holding IP space can authorize ASes to announce their prefixes. In RPKI the regional internet registries (RIRs) are the root CAs.
The available options to IP address holders (hosted vs. delegated PKI) depend on the RIR. Creating a ROA can be as easy as clicking a few buttons in a LIR interface (BGP router configuration changes are not required).
The RPKI adoption rate on the general internet is considered low, NIST’s RPKI monitor (figure 1) shows that RPKI adoption is around 10% when measured by address space,

Figure 1: NIST RPKI Monitor (https://rpki-monitor.antd.nist.gov)
Figure 2: RIPE NCC’s RPKI Stats shows that the number of distinct ASNs deploying ROAs is steadily growing (in the RIPE region) (https://certification-stats.ripe.net/)

ROA maxlength attribute

When creating a ROA, the IP holder can specify an optional max length field. This allows an AS to announce prefixes that are longer (more-specifics) than the prefix in the ROA, but it also introduces a potential attack opportunity when not all prefixes that are allowed by the ROA are actually announced. If the actual AS announces a /22 only but specifies a max length field of /24 in the ROA, then attackers can announce more-specific /24 prefixes (using the victim’s AS number) without causing RPKI INVALID validation results.

RIPE IRR coverage (in-region only)

Internet routing registries (IRRs) also provide data to verify BGP routes (prefix to AS mapping) but their data quality varies. We consider only the IRR which has somewhat reasonable data quality and authorization checks in place: RIPE

Results

Figure 3
Figure 4
Figure 5: What fraction of Tor capacity has which RPKI state?

RIPE IRR Coverage (in-region only)

Figure 6: 77% of the Tor network capacity has a valid route object in RIPE IRR and is in the RIPE managed IP space.

IPv6 Prefixes

We also looked at the over 200 IPv6 prefixes used for the Tor network, but it is important to note that only about 25% of the Tor network capacity has an IPv6 address and IPv6 is only used for entering and exiting the Tor network at this point. To be able to compare figure 7 directly with figure 3 we extrapolated IPv6 CW fraction values to 100%.

Figure 7
Figure 8

Who are the biggest RPKI ROA adopters on the Tor network?

ROAs are not created by the AS but by the IP address space holder, but for most cases this is the same entity so we simplify above question by grouping by the Autonomous System. This list can be of use to relay operators (and others) as a reference list when talking to their ISPs about enabling ROAs.

+------------------------------+------+--------+
| as_name | CWfr | relays |
+------------------------------+------+--------+
| Hetzner Online GmbH | 7.02 | 284 |
| Online S.a.s. | 5.16 | 113 |
| myLoc managed IT AG | 2.02 | 41 |
| netcup GmbH | 1.73 | 50 |
| NForce Entertainment B.V. | 1.50 | 25 |
| Voxility S.R.L. | 1.06 | 14 |
| SOFTplus Entwicklungen GmbH | 0.81 | 15 |
| ISPpro Internet KG | 0.62 | 21 |
| I.C.S. Trabia-Network S.R.L. | 0.61 | 45 |
| SWITCH | 0.48 | 9 |
| Telenor Norge AS | 0.39 | 28 |
| Joshua Peter McQuistan | 0.37 | 5 |
| 1&1 Internet SE | 0.34 | 8 |
| Brass Horn Communications | 0.33 | 6 |
| True B.V. | 0.30 | 1 |
| Deutsche Telekom AG | 0.29 | 152 |
+------------------------------+------+--------+

Who are the biggest Tor related network operators not adopting ROAs (completely)?

+------------------------+-------+--------+
| as_name | CWfr | relays |
+------------------------+-------+--------+
| OVH SAS | 13.04 | 530 |
| Online S.a.s. | 8.42 | 231 |
| Joshua Peter McQuistan | 2.83 | 27 |
| Hetzner Online GmbH | 2.67 | 72 |
| DigitalOcean, LLC | 1.80 | 274 |
| FranTech Solutions | 1.41 | 35 |
+------------------------+-------+--------+

Recommendations for Tor Relay Operators

1. Monitor your relay’s BGP prefix for suspicious BGP activity and share alerts with tor-relays@lists.torproject.org
The easiest way to do so is to subscribe to your prefixes using BGPmon. You should practically get zero alerts.

“Virtual” Route Origin Validation in the Tor Context

The are two good reasons why Tor should care of relays located in RPKI ‘Invalid’ prefixes:

  1. It will eventually break the “the Tor network is a full mesh” assumption. Relays in such RPKI ‘invalid’ prefixes with no alternative valid route will not be reachable from ASes performing ROV, but the Tor network assumes that every relay can reach every other relay. When ROV breaks that assumption it is better to exclude these relays than to keep only partially reachable relays.
  2. An RPKI ‘Invalid’ route might as well be an actual BGP hijacking attempt and why not stop that?

The unsolved problem: AS Path Verification

We only looked at route origin (which AS announces what prefix?) but even which a hypothetical ROA and ROV coverage of 100% BGP routing attacks that spoof the AS origin itself via AS PATH are still possible. At the IETF 102 SIDROPS meeting Alexander Azimov presented (15min) (slides) a new Internet-Draft that aims totackling AS PATH verification using ASPA which as an attendee and Geoff Huston pointed out is similar to soBGP. ASPA builds on top of RPKI as well (like ROAs).

Key Take Aways

  • ROA adoption in the context of Tor is higher than on the general internet due to some big hosters (used by many relays) having adopted RPKI
  • ROA adoption could further be significantly increase even if a very limited number of entities enable them (due to of the centralization around big ISPs like OVH)
  • legacy IP blocks are apparently the reason for a significant portion (>10%) of the Tor network not having ROAs yet
  • RIPE’s IRR (limited to RIPE managed space) covers most of the Tor network’s capacity (77%)
  • More than 84% of the Tor capacity uses RIPE managed IP space
  • Hijacking exit capacity is probably harder than hijacking guard capacity (due to the increased use of /24 prefixes for exits)
  • ROA adoption is higher for IPv6 than for IPv4 while IPv6 has less (none) RPKI ‘Invalid’ routes
  • a significant portion of ROAs has a weak maxlength attribute (this confirms what others have reported as well)
  • ROV could be performed by Tor directory authorities to cover all relays (by rejecting/flagging them) even if global ROV deployment rate is very low
  • most of the Tor network capacity is not covered by RPKI ROAs and is not located in /24 prefixes

Future Work: BGP Monitoring for Tor Prefixes

Since using commercially available services like BGPmon are too expensive to monitor the entire Tor network with over 3100 prefixes (>40k USD / month) there is a need for other solutions.

Acknowledgements

We’d like to explicitly mention the used data sources:

  • Tor Project’s onionoo from 2018–08–09 21:00 UTC for relay IP addresses, cw fraction, guard probability and exit probability data
  • RIPEstat for BGP prefix, ASN and IRR data. (We stumbled on a bug in RIPEstat’s IRR related part that might has a minor impact on the graph in figure 6 but we believe it to affect only a non-significant portion <1% cw fraction)
  • RPKI Validator v2.24 (local instance with ARIN’s TAL enabled)
  • RIPE IP Space to filter IRR entries to RIPE in-region items only
  • CAIDA AS Rank API (2018–07–01)

Appendix

Mutually Agreed Norms for Routing Security (MANRS) by the Internet Society

References to RIR documentation for creating/managing ROAs

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store