The infrastructure that supports the Resource Public Key Infrastructure (RPKI) security standard is not as secure as one would believe and is prone to multiple attacks that could hinder or crash global internet routing.
A new research paper that will be presented next week at the Network and Distributed System Security (NDSS) Symposium looks at a type of server that is part of the RPKI infrastructure known as PP, standing for Publishing Point, and how attacking these servers can prevent routers from validating routing information.
The topic of internet routing and its security protocols is a complex one, so here are the main acronyms and terms that we'll be using and what they mean:
BPG—stands for Border Gateway Protocol and refers to an internet routing protocol through which routers talk to each other and exchange information about where IP addresses blocks are located across the globe and where they should be sending traffic.
AS—stands for Autonomous System and refers to a company or organization that owns IP addresses and engages in routing internet traffic or hosting content.
BGP announcement—refers to messages sent by ASes (and their routers) to other ASes (and their routers) about what IP address blocks they are hosting, inviting others to send data to them.
RPKI—stands for Resource Public Key Infrastructure and refers to a collection of standards and protocols to secure internet routing.
ROA—stands for Route Origin Authorization and is a mechanism through which an AS announces and cryptographically attests that it owns and hosts a specific IP address block.
ROV—stands for Route Origin Validation and refers to the process where an AS/router takes an incoming BGP announcement and verifies the routing information against a list of known ROAs.
PP—stands for Publishing Point and they are central servers where all the cryptographically-signed ROAs are stored.
RP—stands for Relying Party and is software that runs on an AS' infrastructure that downloads ROA lists from PP servers, lists that are later used by the ROV mechanism to verify that routing information from a BGP announcement matches the ROA entry.
What the research team looked at was the interaction between RPs and PPs, which is not as simple as running a curl command and downloading a list of signed ROA entries from the PPs. These are multi-step operations that have their own quirks and expose the entire routing validation process to bugs and errors.
"Specifically speaking, the process involves two key sub-processes. The first sub-process is that the RP resolves the domain name of each individual PP through the DNS infrastructure to obtain the PP's IP address. This resolution sub-process involves iterative interactions with authoritative name servers across varying levels of the DNS hierarchy. The second sub-process involves the RP establishing communication with the PP via its IP address to retrieve ROAs using either RRDP or rsync, which we refer to as the download sub-process. To ensure data integrity during the resolution sub-process all involved entities must adopt DNSSEC, which provides cryptographic validation of DNS responses. In contrast, the download sub-process ensures data integrity through RPKI's built-in security mechanisms. Notably, the download sub-process benefits from strong cryptographic protections inherent in RPKI, whereas the resolution sub-process remains vulnerable due to partial DNSSEC deployment on the Internet. To ensure end-to-end connectivity, routing security for all data flows within both sub-processes must be meticulously upheld."

The study created an inventory of all PP servers and tried several attacks to hijack parts of this infrastructure. The results were pretty bad.
From the 64 total PP servers discovered, 31 were vulnerable to DNS spoofing attacks because the PP domain names did not use DNSSEC, a protocol that lets domain owners cryptographically sign their DNS records for authenticity.
Fifty-five PP servers also relied on DNS servers that lacked ROA coverage, meaning you could use a BGP hijack to take over the servers meant to protect against BGP hijacks.
Four of the PP servers themselves were on networks that didn't use ROAs, leading to the same attack scenario.
Researchers also evaluated the practicality of an attack against PP servers. Results showed that attacking the most vulnerable PP server would impact ROV operations of up to 65% to 83% of all ASes due to dependencies among PPs that would trigger cascading failures in the entire PP ecosystem.
The research team, all from the Tsinghua and Fudan universities in China, offered some recommendations for strengthening the RPKI/PP ecosystem. Some of the most important included rolling out DNSSEC for the PP domain names, covering the PP and their DNS servers with ROA protections, and avoiding hosting PP servers on CDNs.
Post by @joebeone@techpolicy.social
