What Is My RPKI Validator Doing Right Now?#

Santiago Aggio (CONICET BB / UTN-FRBB, Argentina)

• Why: RPKI validators are quietly becoming production-critical infrastructure for anyone doing ROV — this gives a concrete measurement plus an ops playbook for running and monitoring them, which the PM can treat as a case study in operating a PKI at scale.
• What: An operator-oriented examination of relying-party software (FORT, Routinator 3000, rpki-client, StayRTR, rpki-prover) and the synchronization layer: RRDP (RFC 8182) vs rsync, where RRDP's snapshot/delta model substantially reduces data transferred per validation cycle (one publication point shows ~4,425 RRDP vs ~135 rsync fetches). Includes measured sync latencies from 20 RIPE Atlas probes in Argentina showing that the geographic location of publication points influences synchronization times, and notes 26 active IETF drafts in the RPKI space (publication-server BCP, ERIK sync protocol, decentralized repository architecture).
• How: Routinator's Prometheus exporter + Grafana for VRP and session metrics; validator metrics pages; RIPE Atlas ping/traceroute to publication points. Operational recommendations: size the validator VM (memory, tmpfs, CPU); run more than one validator implementation for redundancy; use different IPv4/IPv6 source addresses toward repositories (to survive DDoS filtering); run DNS resolvers with parallel resolution; monitor both sides of the validator (RRDP/rsync toward publication points, RTR toward routers); consider RTRTR as an RTR proxy for mid/large operators.
• Where applicable: Any operator running RPKI ROV — broadly applicable and immediately adoptable. The latency measurements are Argentina-specific; the practices are general.