Today’s Internet is made up of interconnected Autonomous Systems (ASes). These ASes use the Border Gateway Protocol (BGP) to announce ranges of contiguous address space — also referred to as prefixes — to their peers. BGP configured routers can accept or reject incoming announcements based on their attributes, for example, their prefix, AS-PATH, or its attached BGP communities. The BGP guidelines recommend rigorous filtering of prefixes more specific than /24 in IPv4 and /48 in IPv6. We refer to the prefixes /25 to /32 in IPv4 and /49 to /128 in IPv6 as hyper-specific prefixes (HSPs).
In theory, HSPs shall not appear in the public Internet routing ecosystem. In reality, the route collectors from RIPE RIS and Routeviews saw around 100,000 IPv4 and 10,000 IPv6 HSPs (approximately 1/10 of all the prefixes they see) by the end of 2021.
Using 11+ years of BGP data from these route collector projects, we at the Max-Planck Institute for Informatics took a closer look (paper) at the prevalence of HSPs in the Internet to understand why they can be seen by collectors, and how we might handle them in the future.
Life span and propagation of HSPs
First, we looked at how long HSPs are visible and how far they propagate in terms of the number of the peer ASes shown on route collectors. We analysed BGP Routing Information Bases (RIBs) and updates for the entire year of 2020 and plotted them in Figure 1 with IPv4 (left) and IPv6 (right) heatmaps.
In Figure 1, the y-axis shows the visibility of an HSP (the maximum number of peer ASes that saw the prefix), and the x-axis represents the consistency (the duration of time an HSP was visible). Every heatmap cell represents 10 feeder ASes on the y-axis and two weeks duration on the x-axis. The colour (or heat) of a cell represents the number of HSPs within it (using the log10 scale).
We observed that some HSPs have a life span of less than a week, while others are visible throughout the year. Even though most of the HSPs propagate only locally (that is, to a few ASes), others are globally visible.
Why are HSPs announced?
We wanted to know whether HSPs are the result of an accidental internal route leakage due to configuration errors or if network operators intentionally advertise HSPs to the public Internet. To identify the possible function of HSP, we used the fact that particular Classless Inter-Domain Routing (CIDR) sizes — the size of a prefix — can hint at the use case of HSPs.
Figure 2 shows the number of HSPs, coloured by their respective CIDR size over time. For IPv4 (left), the /31 – /32 group forms the largest group of HSPs, which hints that possibly many IPv4 HSPs are associated with BGP blackholing. The second largest group is the /29 – /30 CIDR size, a CIDR size used mainly by routing infrastructure (such as peering subnets).
For IPv6 (right), we observed that /49 – /64 is the dominant CIDR size, which we associate with address block assignment. The small fraction of /113 – /128 HSP CIDR sizes are possibly associated with IPv6 BGP blackholing.
Are HSPs associated with prefix hijacks?
Next, we wanted to understand whether HSPs are associated with prefix hijacks or not. One protocol that aims at hindering prefix hijack attacks is the Resource Public Key Infrastructure (RPKI). We checked each HSP and its origin-AS against Route Origin Authorization (ROA) records using RPKI data. We classified HSPs according to their Route Origin Validation (ROV) status into the following categories:
- Valid: Matching ROA entry
- Invalid (Length): Matching origin-AS, but invalid prefix length
- Invalid (Origin): Matching prefix, but invalid origin-AS
- Invalid (Both): Neither prefix nor origin-AS matches the ROA entry
As can be seen in Figure 3, we found a higher share of valid ROA entries for IPv6 (right) compared to IPv4 (left). The ‘Invalid (Length)’ category is the largest in IPv4 and IPv6. The ‘Invalid (Origin)’ category contains only a small portion of the HSPs. Both ‘Valid’ and ‘Invalid (Length)’ categories together make up around 75% of all HSPs, which underlines that HSPs are not majorly associated with BGP prefix hijacks.
It is also possible that not correctly entering sibling ASes or DDoS Protection Service (DPS) causes the ‘Invalid (Origin)’ and ‘Invalid (Both)’ ROV status. Upon examining the data, we found that only 1% of HSPs in IPv4 and IPv6 were announced from ASes belonging to DPS companies.
How to handle HSPs in the future
We discussed our results with 13 different network operators and found that limited filtering of HSPs is often due to customer requests. Some transit networks told us that in 2020 they changed their BGP filters from filtering all IPv4 HSPs (/25 or more specific) to allowing up to /28 prefixes. The reason for this change was to allow new customers and small ASes to perform basic traffic engineering.
Finally, the question is whether to filter HSPs or not. Considering the current situation of IPv4 and IPv6 usage and availability, we make two proposals.
For IPv6, there is no shortage and obtaining a new block is very cheap and easy (compared to IPv4), so the answer is ‘yes, filter IPv6 HSPs’. This ensures that the routing table size growth is kept under control.
For IPv4, we propose loosening the restrictions to allow HSPs to enable small networks to perform traffic engineering. To limit routing table size growth, shifting the current filters by a few CIDR sizes (for example, /26 or /28) might be an agreeable compromise.
HSP dashboard
To improve awareness and help the community, we collect and provide up-to-date statistics and graphs of HSPs, including top contributors, on our project dashboard at hyperspecifics.io.
If you are interested to learn more about HSPs, please read our paper published in ACM SIGCOMM Computer Communication Review in April 2022: Hyper-Specific Prefixes: Gotta Enjoy the Little Things in Interdomain Routing.
Contributors: Lars Prehn, Oliver Gasser.
Khwaja Zubair Sediqi is a Research Assistant and Ph.D. Candidate at the Max Planck Institute for Informatics.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.
This is the kind of blog post that I like! Thanks! 🙂