Authors: Khwaja Zubair Sediqi, Massimiliano Stucchi, Romain Fontugne, Amreesh Phokeer, Massimo Candela, Anja Feldmann
The security of Internet routing is increasingly dependent on the adoption of the Resource Public Key Infrastructure (RPKI), a framework designed to prevent the spread of bogus routing information. To combat BGP hijacks and misconfigurations, more networks are embracing RPKI to validate the legitimacy of route announcements. Yet, as the deployment expands, a critical performance bottleneck is emerging: delays in the synchronization process performed by Relying Party (RP) software.
In a previous paper, we looked at the whole Route Origin Authorization (ROA) publication chain and identified some bottlenecks that can impact the RPKI-to-BGP synchronization delay. We observed significant disparities in ISPs’ reaction time to new RPKI information, ranging from a few minutes to one hour. In this new paper presented at the Traffic Measurement and Analysis Conference (TMA) 2025, titled “RPKI Syncing: Delay in Relying Party Synchronization,” we offer an in-depth exploration of Relying Party (RP) software synchronization delay (one of the bottlenecks) and how this can impair the responsiveness of RPKI-based validation—and, by extension, Internet routing security.
The role of Relying Party software in the RPKI ecosystem is critical. RP software downloads, verifies, and processes cryptographic objects—primarily ROAs—from distributed Publication Points (PPs). It then provides the BGP-speaking routers with Validated ROA Payloads (VRPs), enabling them to filter out unauthorized BGP announcements. This process, known as RPKI synchronization, must be both accurate and timely. However, the paper reveals that synchronization can be surprisingly slow, often taking several minutes depending on the conditions and configuration of the RP software, the structure of the ROAs, and the location and accessibility of the PPs.
Through a series of large-scale experiments using over 700 RIPE Atlas probes from 91 countries, as well as detailed benchmarking of two leading RP implementations (Routinator and rpki-client), the authors provide the most comprehensive analysis to date of what causes RPKI synchronization delays—and what can be done about them.
One of the most striking findings is that the structure of ROAs has a significant impact on synchronization time. ROAs can contain multiple prefixes for a single Autonomous System (AS), or each prefix can be placed in a separate ROA. The paper shows that bundling multiple prefixes into a single ROA not only reduces the number of objects to fetch and verify but also cuts the cryptographic verification time by as much as a factor of three. This optimization is especially relevant for large ASes managing thousands of IP prefixes, such as major cloud providers. However, aggregating multiple prefixes for the same AS on a single ROA requires a complex system that has to carefully track data changes and reissue ROA objects proactively without risking IP prefix invalidation and is not recommended for networks that frequently change prefixes.
Another important factor is the operational model of Certificate Authorities (CAs). In RPKI, CAs can either operate in “hosted mode,” where the Regional Internet Registry (RIR) manages the publication infrastructure, or in “delegated mode,” where the CA manages its own Publication Point. While delegated mode offers greater autonomy and flexibility, it also introduces variability in performance. The researchers found that a small number of delegated CAs, contributing just 7% of the total VRPs, were responsible for more than 90% of the total synchronization delay for one of the RIR’s RPKI tree validation. These outlier PPs often failed to respond over the preferred RRDP protocol (RPKI Repository Delta Protocol) and fell back to rsync, which is both slower and more prone to operational issues.
Geography also plays a significant role. Because RPKI data is stored in globally distributed repositories, the physical distance and network latency between an RP and the PPs it contacts can dramatically affect synchronization times. The study measured Round Trip Time (RTT) to each PP from around the world and found large regional disparities. While most PPs were reachable within 50 milliseconds from their primary serving regions (e.g., RIPE PPs from Europe), delays could stretch into hundreds of milliseconds from more distant regions. These differences are not just academic—every additional 100 milliseconds of RTT can translate into up to 25 extra seconds of synchronization delay for some RP software.
One of the clearest opportunities for improvement lies in the hosting infrastructure of Publication Points. PPs hosted on Content Delivery Networks (CDNs) consistently exhibited faster and more globally consistent RTTs compared to self-hosted PPs. For example, RIPE’s CDN-hosted RRDP endpoint showed sub-10ms RTTs from all continents, while ARIN’s self-hosted RRDP endpoint had delays of 100–300ms or more for regions outside North America. This performance gap highlights how critical it is to use globally distributed, high-performance infrastructure to serve RPKI data if synchronization speed is to be improved globally.
The performance of RP software itself also matters. In the paper’s experiments, Routinator excelled in cryptographic verification tasks and was less affected by the system’s CPU cache state, but suffered from numerous page faults during data retrieval in cold-start scenarios, leading to the highest synchronization delays—up to 500 seconds. In contrast, rpki-client was better at efficiently downloading data, with almost no page faults, resulting in faster synchronization in cold mode, but it was significantly slower at cryptographic validation, especially when not using a memory cache. Interestingly, in typical operational conditions—known as warm cache mode—both RP software implementations performed similarly.
What should operators and the RPKI community take away from this research? First, there’s a clear need to optimize ROA structures and streamline validation paths, particularly by consolidating prefixes where feasible. Second, the importance of low-latency access to Publication Points should be encouraged. Improving the global accessibility of RPKI repositories (e.g. using anycast nodes), could yield important performance benefits. Third, RP software itself can be further optimized for example by adopting faster storage systems.If you are interested to learn more about this work, you can have a look at the full paper, “RPKI Syncing: Delay in Relying PartySynchronization.”
The post Unpacking the Bottlenecks in Relying Party Software Synchronization Delays appeared first on MANRS.