Byzantine-Secure Relying Party for Resilient RPKI

TL;DR

This work addresses the fragility of RPKI relying parties by introducing BRP, a Byzantine-secure relying party layer that achieves global VRP consensus among multiple RP instances. BRP uses a threshold-vote, per-object consensus to tolerate Byzantine faults and malicious RPKI publishers, while remaining backward compatible and deployable as both a decentralized network or a centralized service. Through extensive benign and adversarial evaluations, BRP demonstrates improved resilience, reduced load on RPKI publication points, and robust VRP outputs even under repository failures or stalling attacks, with substantial traffic reductions projected for full deployment. The approach enables broader, more secure adoption of ROV without requiring changes to border routers or existing RPKI infrastructure, and it provides auditable, independently verifiable VRP data to operators and researchers alike.

Abstract

To protect against prefix hijacks, Resource Public Key Infrastructure (RPKI) has been standardized. To enjoy the security guarantees of RPKI validation, networks need to install a new component, the relying party validator, which fetches and validates RPKI objects and provides them to border routers. However, recent work shows that relying parties experience failures when retrieving RPKI objects and are vulnerable to attacks, all of which can disable RPKI validation. Therefore even the few adopters are not necessarily secure. We make the first proposal that significantly improves the resilience and security of RPKI. We develop BRP, a Byzantine-Secure relying party implementation. In BRP the relying party nodes redundantly validate RPKI objects and reach a global consensus through voting. BRP provides an RPKI equivalent of public DNS, removing the need for networks to install, operate, and upgrade their own relying party instances while avoiding the need to trust operators of BRP nodes. We show through simulations and experiments that BRP, as an intermediate RPKI service, results in less load on RPKI publication points and a robust output despite RPKI repository failures, jitter, and attacks. We engineer BRP to be fully backward compatible and readily deployable - it does not require any changes to the border routers and the RPKI repositories. We demonstrate that BRP can protect many networks transparently, with either a decentralized or centralized deployment. BRP can be set up as a network of decentralized volunteer deployments, similarly to NTP and TOR, where different operators participate in the peering process with their node, and provide resilient and secure relying party validation to the Internet. BRP can also be hosted by a single operator as a centralized service, e.g., on one cloud or CDN, and provides RPKI validation benefits even when hosted on a single network.

Figures (9)

• Figure 1: Container components represented as squares, data/files as cylinders. Color legend: red - standard RPKI; purple - detection/skiplisting; blue - peering/consensus; green - client output.
• Figure 2: Threshold vote for 3 nodes and resilience to 1 fault ($f=1$).
• Figure 3: Experiment A: convergence graph for a benign cluster, 10 seconds refresh interval.
• Figure 4: Experiment B: convergence graph for a benign cluster, 10 minute refresh interval.
• Figure 5: 24h-Experiment without cache: (a) VRP datasets of our system (b) overlap of VRP datasets of our system and rpki-client.