Adoption of RPKI/ROV security protocol progressing very quickly
Next step is implementation of ASPA
More than half of both the IPv4 routes and the IPv6 routes in the BGP internet routing system are now secured with RPKI. Even more importantly, three quarters of all IP traffic is now bound for RPKI-secured destinations. Those are amongst the key takeaways from the annual survey by internet engineer Job Snijders.
Although RPKI/ROV is being adopted very quickly, it's still early days for the other 2 RPKI-based protocols. Anyone now running RPKI with ROV will be able to take the next step to ASPA in the next few years. Where BGPsec is concerned, it's a question of waiting for the next generation of routing systems.
Figure 1: RPKI/ROV numbers of unique prefix-origin pairs (IPv4). [Source: NIST]
RPKI is a cryptographic security protocol that enables IP address block owners to digitally sign the routes they publish. With RPKI enabled, it's harder for malicious actors to inject false route information into the system with the aim of hijacking IP addresses or redirecting internet traffic. RPKI also prevents the propagation of innocent errors made by network operators, which could otherwise result in the disconnection of important components and services.
The proportion of RPKI-secured web servers in the .nl domain now stands at nearly 90 per cent. Since last year, RPKI has also been an important topic on SIDN Labs' research agenda. And, in late January this year, testing for RPKI support was added to the Internet.nl test portal.
Figure 2: Proportion of RPKI-secured web servers in the .nl domain. [Source: SIDN Labs]
Security infrastructure
What we refer to above as RPKI is actually only part of the story. Strictly speaking, the term 'RPKI' is applicable only to the PKI infrastructure erected by the RIRs and LIRs. That infrastructure forms the basis for Route Origin Validation (ROV) security, which involves the use of Route Origination Authorization (ROA) records to establish cryptographic links ('authorisations') between AS numbers and prefixes. All ROA information is collected and validated by local RPKI caches, which then make the validated information available to local routers using the RTR protocol (while the route information itself is still distributed using BGP).
ROV validation is already performed by all backbone providers and major internet service providers. Almost everyone that handles a large amount of data traffic now uses ROV. Consequently, adoption by smaller players is less important, since any erroneous route announcements secured using ROV are now blocked higher in the infrastructure.
Various RPKI-based security protocols
In addition to the ROV protocol, 2 other security protocols based on the RPKI infrastructure have been developed to increase the security of internet routing. The first is BGPsec, which adds secure path functionality to the BGP protocol. With BGPsec, the supplemented path information is re-signed at each hop, as is the recipient's AS number. The system enables validators to verify that a BGP update message is intended for them (i.e. for their network), and that the whole composite path from the origin is authentic.
The second protocol is ASPA (Autonomous System Provider Authorization), which cryptographically specifies the AS numbers that are allowed to make route announcements for a given AS number. The idea is that organisations publicise who their upstream (transit) providers are, so that routers can use that information to verify the individual hops in a path.
In that respect, the RPKI architecture serves a similar function to the DNS system's DNSSEC security architecture: RPKI provides a distributed PKI infrastructure, which is used as a basis for various other security protocols. Furthermore, RPKI serves to supplement DNSSEC: DNSSEC assures the correct translation of domain names into IP addresses, while RPKI ensures that traffic to those IP addresses does arrive at its intended destination.
Route security
The stack of RPKI security protocols resolves problems of 3 types:
So-called "misoriginated destinations": route announcements made for incorrect prefixes due to typing errors or other mistakes by the announcers (e.g. accidentally claiming a destination that doesn't actually belong to the announcer). Misoriginated destinations are easily the most common problem (occurring about 100 times a day), and can be prevented by using ROV.
Route leaks (considered in detail in RFC 7908), where a misconfiguration by a legitimate actor results in the route to one upstream provider or peer actually going to another upstream provider or peer. That creates a side route, which may well work in a technical sense, but isn't the intended route. If might mean, for example, that traffic between 2 independent upstream providers is routed via a narrow-band internal connection. Problems of this kind are much less common (maybe one a day), and can be prevented by using ASPA.
Spoofing, where a malicious actor tries to use BGP to take over another party's route and redirect traffic (BGP hijacking), typically for criminal purposes. Spoofing is thankfully uncommon (occurring a few times a year), and can be prevented by using BGPsec (together with ASPA if used on a large scale).
Complementary
Although ASPA is often seen as a more efficient alternative to BGPsec, Snijders emphasises that the 3 RPKI security protocols are complementary and address different problems. "The good thing about RPKI is that the security mechanism that's easiest to implement (ROV) also prevents the most common type of problem. ASPA requires considerable BGP system processing capacity, but most of the work is still done on the RPKI infrastructure. Finally, BGPsec is a demanding protocol, whose processing capacity needs are such that its widespread deployment will have to wait for a future generation of router systems. While ASPA does not require any cryptographic processing to be done on the routers themselves, a BGPsec router has to generate a digital signature every time it passes on a route announcement. However, spoofing involves a sophisticated attack with a high expertise threshold and is consequently a rare occurrence."
Although ROV is being adopted very quickly, it's still early days for the other 2 RPKI protocols. "Anyone now running RPKI with ROV will be able to take the next step to ASPA in the next few years," says Snijders. "At the moment, the adoption level is negligible, but ASPA is already more widely supported than BGPsec in the open-source packages OpenBGPD, BIRD and FFRouting. Those packages are used mainly by the internet exchanges. If, say, 100 big exchanges enable ASPA, that immediately has a huge impact. The latest generation of router systems used by other players has sufficient onboard processing power to cope with ASPA. However, the big vendors don't yet support that option, because ASPA is still under development." Snijders thinks that most of the ASPA specification won't be published in RFC form until next year at the earliest. Significant work remains to be done on the RTR protocol in particular.
By contrast, the theoretical development of BGPsec was completed long ago, but there is no internet-scale tooling. According to Snijders, "BGPsec is an idea that's ahead of its time. Its implementation requires too much processing power for existing equipment, meaning that adoption is quite costly. That's why very little progress has been made with refinement of the BGPsec protocol for several years. However, I do expect that the next generation of router systems will have enough onboard processing power to run BGPsec."
Low-hanging fruit
"It will definitely take several decades to fully implement a solution to the problem of route security," Snijders continues. "So far, we've only just begun picking the low-hanging fruit. The market for Cisco's and Juniper's biggest router systems is only hundreds or maybe thousands of units. Consequently, the number of engineers that can be assigned to the development of those systems is far smaller than the number working on smaller computer systems, which sell in their hundreds of thousands. For the same reason, the lifecycles of the big systems are longer. Cisco will spend several years developing a major software release, after which companies like KPN and Ziggo have to do extensive testing before rolling out the update. As a result, the lead time from idea to operational use is maybe 5 years. And, for the hardware of the core routers in the internet backbone, you've got to be thinking of an update cycle of 10 or 15 years."
The good news is that last year various new ideas were published in the form of RFCs, making the RPKI stack more complete and robust. What's more, like RPKI/ROV before it, ASPA is now gathering momentum. "The adoption of RPKI is going very well," says Snijders. "For anyone who is currently using ROV, ASPA is the next step. I expect that, in the next few years, ASPA support will be added to existing modern router systems by means of a software update."