24 February 2021 marked one year since Hurricane Electric began deploying Resource Public Key Infrastructure Route Origin Validation (RPKI ROV). Since then, significant progress has been made globally in the adoption of RPKI ROV.
2020 was a great year for routing security as eight large Internet Service Providers (ISPs) began validating origins with RPKI. Before then, some very large ISPs were validating their peers for RPKI ROV, and filtering for invalids.
Figure 1 shows the ISPs, cloud providers and Internet exchanges that adopted RPKI ROV over the past year.
As noted in many Network Operator Group (NOG) discussions, Hurricane Electric’s system does not rely on routers with a full set of validated ROA payloads (VRPs) from a RPKI-to-Router (RTR) protocol. Instead, our first line of defence is the filters we generate daily for our peers that validate against RPKI ROAs and IRR records.
Like many ISPs, Hurricane Electric has devices deployed at our edge that do not support the RTR protocol. Because of that, the system we deployed will identify an invalid announcement and remove our table in less than a minute. We were able to do this without replacing our existing routing infrastructure, which means that filtering for invalids does not have to depend on your equipment.
Tools to help if there’s a problem
If you want to know at a glance how your network measures up, we have two tools: the BGP Toolkit at bgp.he.net and the Route Filtering website at routing.he.net.
The BGP Toolkit features information from public sources about BGP and the Internet.
Each prefix in Figure 2 has a green checkmark, which means that every one of those prefixes has an IRR route object. If an object is marked with a green key, it means each prefix has a valid ROA. If it doesn’t have a check mark it is an unknown, and doesn’t have a ROA. If you see a red key by a prefix, that means the prefix is RPKI ROA invalid, which is shown in Figure 3.
The Route Filtering website lets you look at any network that advertises prefixes to Hurricane Electric and see how we filtered the routes. The filters in routing.he.net are refreshed daily.
There are four tables, as shown in Figure 4. The main table gives general information about the network, which we get from IRR sources, like PeeringDB. The Filters table shows which filters are going to be applied to the sessions. The Prefix Lists table details all the prefix lists that will be applied to each router where a session is hosted. The Sessions table details all of the sessions. So, if we want to find out which policy is going to be used for these IPv4 routes, or IPv4 prefixes, we click Display in the Received column.
This is how the route filtering algorithm works:
- Attempt to find an AS set to use for this network.
- Collect the received routes for all BGP sessions with this ASN. This details both accepted and filtered routes.
- For each route, perform rejection tests.
- For each route, perform an acceptance test.
- Reject all prefixes not explicitly accepted.
If you are curious about the algorithm used to create these filters, the link to the algorithm gives a detailed explanation.
What have we learnt in the last year?
The first thing we learnt was that Frank Sinatra was right; you really do need to do this your way.
The best way for you to roll out RPKI may not be the way that someone else does it. Getting RPKI ROV right does not help you a lot if you don’t have correct IRR filters, because you still need to use them for AS path validation and for validation of any prefix that doesn’t have ROAs.
Tools can give you a big advantage. routing.he.net and the BGP Toolkit were released a long time before we deployed RPKI, but when we did, they were able to explain what we were doing.
Read: Geoff Huston’s Measuring ROAs and ROV
Transparency will help you a lot when you’re doing a rollout because some operators have not paid attention to either RPKI or IRR records. For the ones that haven’t, it helps to have tools that can provide them with some answers.
The current state of RPKI
How many networks are creating ROAs for their prefixes?
The recent global table for IPv4 shows that 28% of the visible prefixes in IPv4 have RPKI ROAs, and less than 1% of those are invalid. IPv6 is doing a little bit better, with 32% of the prefixes having ROAs, and less than 1% invalid. The amount of invalid ROAs has declined year over year. It was approximately 7,000 in March 2020, and now it’s down to about 4,500. The IPv4 prefix pool has increased by over 5% over the year. The creation of ROAs is not only keeping up, it’s gaining.
So, how do we look for the year? In March 2020, we had about 19.5% of IPv4 prefixes with ROAs. Perhaps having operators at home gave them time to clean up routing security, because it was up to 23.86% by September. Now, we’re up to 27.6%.
That’s pretty good progress, but we need to look at the total IPv4 space by RIR, because we need to focus on creating more ROAs and getting more RPKI.
As Figure 7 shows, AFRINIC may only have 9.2% of their prefixes with ROAs but that is double from last year and making great progress. APNIC is at 30%, ARIN is at nearly 15%, LACNIC is almost 35%, and RIPE shows 43.3%. While ARIN has 37% of the IP space, only 14% of that 37% has ROAs. If we are ever going to get to the point where ROAs are the primary way to authenticate an origin, a lot of work is needed.
IPv6 is a better story. IPv6 does not suffer from the same problem as IPv4, with a lopsided distribution of prefixes. The IRRs can get as many IPv6 prefixes as they need. AFRINIC is doing even better in IPv6 than IPv4 at 21%, APNIC above 30% is very respectable, and LACNIC is at 29%. ARIN is still 90% better than IPv4, but it must work harder to get more ROAs in IPv6. Once again, RIPE are overachievers at 46.35%. The reason why RIPE is so far ahead is due to an aggressive and ambitious campaign to evangelize ROA creation. As you can see, it is working.
This brings us to IRR records, which are still the last defence in routing security, unfortunately.
While we have been making great progress in ROA creation, we still need to maintain IRR records as accurately as possible because they’re the only way to validate AS PATH, prefix announcements, and evaluate origins of everybody who doesn’t have a ROA filter.
When you don’t do those things, it leads to events like the Google route leak of November 2018, when a small unfiltered ISP advertised about 500 of Google’s prefixes that it had learned from a route server. The route leak affected Google and a number of others for about 74 minutes.
Read: A major BGP route leak by AS55410
Now, of the things in our toolbox, could RPKI ROAs have prevented this? Not really, because those were Google prefixes and the origins were valid, so that would not have helped. AS PATH filters would not have stopped it, because they weren’t leaked from an upstream. IRR path filters definitely would have helped. The network was not authorized to announce Google’s prefixes, so that would have stopped the leak. Maximum prefix limits might have helped if you had a prefix limit less than the additional 500 prefixes, for that AS.
On 24 June 2019, an outage occurred in Verizon. It was a route leak that happened when a small company used a route optimizer, which ended up making a small downstream the preferred path for a large quantity of Internet routes transiting Verizon. Would RPKI ROAs have helped? A little. RPKI would have dropped any invalid origin routes or prefixes with invalid lengths, possibly more efficiently than the current IRR method. AS PATH filters definitely would have helped because the network was leaking routes from its upstreams. IRR path filters would have been a sure thing. It wasn’t authorized to announce these prefixes, so this would have stopped the leak. Max prefix limits would have shut down the sessions before they could have done any damage.
What can make routing even more secure? Today, networks document the ASNs they are authorized to advertise to other networks, and you must trust them. A more secure system would have clients identify their providers, as Figure 9 illustrates.
Unfortunately, we do not have a way to do that yet. But until we do, thanks to a great year for RPKI ROA, routing is a lot more secure.
Susan Forney is a network engineer at Hurricane Electric Internet Services, which operates the largest IPv6 backbone in the world in terms of the number of connected networks.
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.