Operational Monitoring of RPKI Repositories Health and Safety

Introduction The Resource Public Key Infrastructure (RPKI) architecture is described in . It defines a framework that represents the allocation hierarchy of IP address space and Autonomous System (AS) numbers, as well as a distributed repository system for the storage and dissemination of the signed objects used to improve routing security. Internet Service Providers (ISPs) and other participants rely on Relying Parties (RPs) to retrieve and validate this published information from the repositories. RP uses rsync protocol and RPKI Repository Delta Protocol (RRDP) protocol for efficient synchronization of repository contents. The rsync protocol and RPKI Repository Delta Protocol (RRDP) are described in and . An operational best current practices for deployment and management of an RPKI Publication Server is described in .

Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Problem Statement The RPKI infrastructure consists of a large and growing number of independently operated repositories distributed across multiple networks, organizations, and geographic regions. Internet Service Providers (ISPs) depend on Relying Parties (RPs) to collect RPKI objects from the distributed repositories and validate them cryptographically, resulting in hundreds of thousands of Validated ROA Payloads (VRPs). However, even with multiple RPs deployed, ISPs have limited insight into the operational health and reliability of each repository. Because RPs generally treat all repositories uniformly and do not maintain a persistent behavioral profile for each repository. When a large number of ROAs suddenly change from valid to unknown or invalid, operators often lack sufficient information to diagnose the cause, which may stem from an outage or instability in a specific repository. Meanwhile, not all repositories are well maintained—some are unreachable, and others contain outdated objects. As a result, ISPs lack clear visibility into the status of each repository. At present, ISPs lack the ability to distinguish whether changes in RPKI objects are due to routine updates, malicious behavior, or systemic issues within the repositories. In the absence of consistent per-repository monitoring and operational visibility, operators face significant challenges in identifying degraded repositories, correlating incidents across networks, and proactively detecting emerging risks. This document seeks to address these gaps. It provides operational guidance for monitoring the health and safety of RPKI repositories on a per-repository basis. It identifies measurable indicators related to reachability, availability, content integrity. It describes how these indicators can be used to detect degraded or unsafe repository behavior. The document discusses and provides recommendations for repositories alerting and operational response. The goal is to improve the transparency, operational availability and security of the RPKI ecosystem.

Metric Model

Overview This section summarizes all metrics defined in this document. Metrics are divided into three classes: Base Counters: Primitive observable events. Used for diagnostics and as inputs to derived metrics. Health Indicators:Ratios or computed values representing instantaneous repository correctness and usability. These indicators SHOULD be used for alerting. State-Change (Churn) Indicators: Metrics representing differences between successive repository snapshots. These indicators detect abnormal or unexpected publication behavior over time. Monitoring systems: MUST implement Base Counters, MUST compute Health Indicators, SHOULD compute State-Change Indicators.

Observation Window Indicators SHOULD be computed over a configurable time window. Windows MAY be sliding or tumbling. Implementations SHOULD document the window duration.

Base Counters Counters defined in this section are per repository and per transport unless otherwise stated.

Transport Counters attempted_connections: Number of connection attempts initiated. successful_connections: Number of successful connections. failed_connections: Number of unsuccessful connections. successful_dns_resolutions: Number of successful DNS queries. total_dns_queries: Number of total DNS queries.

Synchronization Counters attempted_syncs: Number of synchronization attempts. successful_syncs: Number of synchronization attempts completed without error. failed_syncs: Number of synchronization attempts that failed.

Object Retrieval Counters attempted_object_fetches: Number of objects such as ROA, Certificates,manifest, CRL etc. successful_object_fetches: Number of objects download successful. failed_object_fetches: Number of objects downloaded failed.

Validation Counters total_objects: Number of total objects, such as ROA, certificates. valid_objects: Number of valid objects. invalid_objects: Number of invalid objects. referenced_objects: Number of objects in manifest file. present_referenced_objects: The actual downloaded objects.

Repository Update Time observed_repository_update: Observed repository update time.

Derived Health Indicators The indicators defined in this section measure the instantaneous operational health of a repository, including reachability, availability, and integrity.

Reachability Indicators

Transport Reachability Ratio (TRR) TRR = successful_connections / attempted_connections Measures probability that the repository endpoint can be contacted.

DNS Resolution Success Rate (DRSR) DRSR = successful_dns_resolutions / total_dns_queries Detects DNS-related failures.

Availability Indicators

Fetch Success Ratio (FSR) FSR = successful_object_fetches / attempted_object_fetches Measures reliability of object delivery.

Synchronization Success Ratio (SSR) SSR = successful_syncs / attempted_syncs Measures probability that a complete update can be obtained. Persistent low values indicate degraded availability.

Update Freshness (UF) UF = now − last_observed_repository_update UF measures repository staleness and is time-based rather than a ratio.

Content Integrity Indicators

Validation Success Ratio (VSR) VSR = valid_objects / total_objects Indicates cryptographic and syntactic validity.

Object Consistency Ratio (OCR) OCR = present_referenced_objects / referenced_objects referenced_objects= files the manifest says must exist present_referenced_objects= files actually download successfully

Hash Mismatch Rate (HMR) HMR = hash_mismatches / hash_verifications Non-zero values MUST be treated as critical integrity failures.

Alerting Guidance Monitoring systems SHOULD generate alerts when TRR, SRR, FSR,OCR, HMR falls below a configured threshold value.

State-Change and Churn Indicators

Overview A repository MAY remain fully reachable and internally consistent while exhibiting abnormal or unsafe publication behavior. Examples include: sudden bulk withdrawal of ROAs, excessive object churn, incomplete or partially applied updates. Such events can materially affect routing outcomes even when health indicators remain nominal. To detect these conditions, monitoring systems should evaluate state-change indicators—also known as churn indicators—that measure the differences between consecutive repository states. When the change in these indicators exceeds an ISP-configured threshold, the monitoring system sends an alarm. These indicators provide temporal visibility and enable detection of unexpected or anomalous repository behavior.

Snapshot Model After each successful synchronization, a monitoring system SHOULD construct a repository snapshot containing at least: validated object identifiers, object hashes, object types (ROA, certificate, CRL, manifest, etc.), RRDP session identifiers and serial numbers. Change indicators are computed by comparing the current snapshot with the most recent prior successful snapshot.

General Object Churn

Object Change Count (OCC) OCC = added_objects + removed_objects + modified_objects added_objects are objects newly observed, removed_objects are previously observed objects no longer present, modified_objects are objects whose content hash has changed. OCC provides an absolute measure of repository churn.

Object Change Ratio (OCRate) OCRate = OCC / previous_total_objects This indicator normalizes churn by repository size and enables comparison across repositories. Large values MAY indicate: bulk re-publication, tooling errors, storage faults, or abnormal behavior. Monitoring systems SHOULD track historical baselines for this value.

ROA Stability Indicators Because ROAs directly affect route validation outcomes, their stability is particularly important.

ROA Count Delta (RCD) RCD = added_roas + removed_roas + modified_roas Large negative values MAY indicate accidental withdrawal Large positive values MAY indicate bulk reissuance.

ROA Change Ratio (RCR) RCR = (added_roas + removed_roas + modified_roas) / previous_roa_count Measures relative ROA churn. Persistent or sudden spikes SHOULD generate alerts.

ROA Withdrawal Ratio (RWR) RWR = removed_roas / previous_roa_count Unexpectedly large withdrawal ratios exceeds the configured threshold by ISP SHOULD send an alarm.

Certificate and CA Stability Indicators

Certificate Change Ratio (CCR) CCR = (added_certs + removed_certs + modified_certs) / previous_cert_count Large values MAY indicate:key rollover, mass reissuance, misconfiguration, or abnormal behavior.

Expired Object Ratio (EOR) EOR = expired_objects / total_objects Expired objects SHOULD NOT normally appear in a properly maintained repository. Values greater than zero SHOULD trigger alerts.

Invalid Object Ratio (IOR) IOR = invalid_objects / total_objects Increasing IOR over time MAY indicate publication or signing defects.

RRDP Publication Continuity

Serial Progression Delta (SPD) SPD = current_serial − previous_serial The SPD ≥ 0.

Delta Volume (DV) DV = number_of_objects_changed_in_rrdp_delta Large deltas MAY indicate excessive churn.

Alerting Guidance Monitoring systems SHOULD generate alarms when: RCR or CCR significantly exceed historical norms, RWR, EOR exceeds an operator-defined threshold, SPD ≤ 0 unexpectedly.

Security Considerations This document defines operational monitoring metrics for assessing the reachability, availability, integrity, and stability of RPKI repositories. It does not modify the RPKI trust model, cryptographic validation procedures, or protocol behavior.

IANA Considerations This document has no IANA actions