| Internet-Draft | Monitoring of RPKI Repositories' Health | July 2026 |
| Fu, et al. | Expires 21 January 2027 | [Page] |
The Resource Public Key Infrastructure (RPKI) relies on a globally distributed set of repositories to deliver signed routing authorization data to Relying Parties (RPs). Internet Service Providers (ISPs) depend on RPs to collect RPKI objects from distributed repositories and validate them cryptographically, resulting in hundreds of thousands of Validated Route origin authorization Payloads (VRPs). Nevertheless, even with multiple RPs deployed, ISPs have limited insight into the operational health and reliability of each Publication Point (PP). When a large number of RPKI objects change unexpectedly, operators often lack sufficient visibility into individual PPs to determine the source of the changes. Consequently, ISPs cannot easily determine whether these changes are caused by routine updates, malicious behavior, or underlying repository instability.¶
This document provides operational guidance for monitoring the health and safety of RPKI repositories on a per-publication point basis. It defines measurable indicators related to reachability, availability, and content integrity, and explains how these metrics can be used to detect degraded performance or potentially 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.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 21 January 2027.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
The Resource Public Key Infrastructure (RPKI) architecture is described in [RFC6480]. 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 [RFC5781] and [RFC8182]. An operational best current practices for deployment and management of an RPKI Publication Server is described in [I-D.ietf-sidrops-publication-server-bcp-profile].¶
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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
The RPKI infrastructure consists of a large and growing number of Publication Points (PPs) distributed across multiple networks, organizations, and geographic regions. Internet Service Providers (ISPs) depend on Relying Parties (RPs) to collect RPKI objects from the distributed PPs 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 Publication Point(PP). Because RPs generally treat all repositories uniformly and do not maintain a persistent behavioral profile for each PP. When a large number of RPKI objects change unexpectedly, operators often lack sufficient visibility into individual PPs to determine the source of the changes. Meanwhile, not all PPs are well maintained—some are unreachable, and others contain outdated objects. As a result, ISPs lack clear visibility into the status of each PP.¶
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 PPs. In the absence of consistent per-Publication Point (per-PP) 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-PP 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.¶
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.¶
Indicators SHOULD be computed over a configurable time window. Windows MAY be sliding or tumbling. Implementations SHOULD document the window duration.¶
Counters defined in this section are per repository and per transport unless otherwise stated.¶
attempted_dns_resolutions: Number of DNS resolutions attemps initiated.¶
successful_dns_resolutions: Number of successful DNS resolutions.¶
failed_dns_resolutions: Number of failed DNS resolutions.¶
attempted_connections: Number of TCP/TLS connection attempts initiated.¶
successful_connections: Number of TCP/TLS successful connections.¶
failed_connections: Number of unsuccessful TCP/TLS connections.¶
attempted_syncs: Number of synchronization attempts initiated.¶
successful_syncs: Number of successful synchronization completed.¶
failed_syncs: Number of failed synchronization.¶
attempted_object_fetches: The total number of objects attempted retrieval during repository synchronization.¶
successful_object_fetches: Number of objects download successful.¶
failed_object_fetches: Number of objects downloaded failed.¶
total_objects: Number of successfully fetched RPKI objects, including ROAs, certificates, manifests, CRLs, and other signed objects.¶
valid_objects: Number of valid objects that pass cryptographic and syntactic validation.¶
invalid_objects: Number of invalid objects that fail cryptographic or syntactic validation.¶
referenced_objects: Number of objects in the manifest file.¶
present_referenced_objects: The actual downloaded objects.¶
observed_repository_update: Observed repository update time.¶
The indicators defined in this section measure the instantaneous operational health of a repository, including reachability, availability, and integrity.¶
DRSR = successful_dns_resolutions / attempted_dns_resolutions¶
Measures DNS resolution success rate.¶
TRR = successful_connections / attempted_connections¶
Measures probability that the publication point can be contacted.¶
FSR = successful_object_fetches / attempted_object_fetches¶
Measures reliability of object delivery.¶
SSR = successful_syncs / attempted_syncs¶
Measures probability that a complete update can be obtained.¶
Persistent low values indicate degraded availability.¶
UF = now − last_observed_repository_update¶
UF measures repository staleness and is time-based rather than a ratio.¶
VSR = valid_objects / total_objects¶
Indicates cryptographic and syntactic validity.¶
OCR = present_referenced_objects / referenced_objects¶
referenced_objects= files the manifest says must exist¶
present_referenced_objects= files actually download successfully¶
HMR = hash_mismatches / hash_verifications¶
This index indicates the proportion of hash verification operations that result in mismatches for RPKI objects, including manifests, certificates, CRLs, and ROAs.¶
Monitoring systems SHOULD generate alerts when TRR, SRR, FSR,OCR, HMR falls below a configured threshold value.¶
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.¶
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.¶
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 a count-based measure of repository churn.¶
OChR = 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.¶
Because ROAs directly affect route validation outcomes, their stability is particularly important.¶
RCD = added_roas + removed_roas + modified_roas¶
Large negative values MAY indicate accidental withdrawal¶
Large positive values MAY indicate bulk reissuance.¶
RCR = (added_roas + removed_roas + modified_roas) / previous_roa_count¶
Measures relative ROA churn.¶
Persistent or sudden spikes SHOULD generate alerts.¶
RWR = removed_roas / previous_roa_count¶
Unexpectedly large withdrawal ratios exceeds the configured threshold by ISP SHOULD send an alarm.¶
CCR = (added_certs + removed_certs + modified_certs) / previous_cert_count¶
Large values MAY indicate:key rollover, mass reissuance, misconfiguration, or abnormal behavior.¶
EOR = expired_objects / total_objects¶
Expired objects SHOULD NOT normally appear in a properly maintained repository.¶
Values greater than zero SHOULD trigger alerts.¶
IOR = invalid_objects / total_objects¶
Increasing IOR over time MAY indicate publication or signing defects.¶
SPD = current_serial − previous_serial¶
The SPD ≥ 0.¶
DV = number_of_objects_changed_in_rrdp_delta¶
Large deltas MAY indicate excessive churn.¶
Monitoring systems SHOULD generate alarms when: RCR or CCR significantly exceed historical norms, RWR, EOR exceeds an operator-defined threshold, SPD ≤ 0 unexpectedly.¶
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.¶
This document has no IANA actions¶