Summary

  • RPKI availability is an end-to-end property. A server health check can be green while outside validators receive stale, incomplete, inconsistent or cryptographically unusable material.
  • A short interruption need not alter routing validation because relying parties cache previously validated entities. The same interruption becomes consequential when a manifest or Certificate Revocation List passes its nextUpdate time, a certificate expires, or a needed change never becomes externally visible.
  • Public incidents show distinct failure classes: APNIC reported rsync inconsistency while RRDP remained valid in 2019; RIPE NCC reported an expired CRL after a silent publication failure in 2020 and inconsistent parent-child certificate publication in 2021; JPNIC reported ROAs becoming NotFound after publication stopped long enough for freshness fields to lapse in 2022.
  • A credible service commitment should measure successful fetches from independent networks, protocol-specific completeness, cryptographic validity, freshness headroom, validated payload changes, recovery convergence and any associated change in observed route validation.
  • Attribution requires a time-ordered record from authorised change through certificate production, publication, external retrieval, validation, router delivery and routing policy. Without that chain, a registry, repository, software vendor and network operator can each point to another layer.
  • Routing impact cannot be inferred from repository failure alone. Operators choose local policy, use different software and refresh intervals, and see different BGP paths. Reports should state the observed population and preserve unknowns rather than claim a universal outage rate.
  • NRS can strengthen registry legitimacy by sponsoring neutral probes, common incident fields and an externally reproducible assurance standard. Its positive contribution would be to make limited institutional claims testable, not to declare that every repository interruption caused customer loss.

An outage begins at the relying party, not in the server room

The decisive RPKI event is not a red light on a repository operator's console. It is the failure of an outside relying party to obtain and validate the material on which a network expects to base route-origin decisions. The two events may coincide, but they are not identical.

A repository operator can observe healthy processors, open sockets and successful local requests while users elsewhere encounter DNS failure, a broken content-distribution node, a TLS mismatch, an incomplete rsync tree, an RRDP session inconsistency or an entity set whose signatures no longer form a valid path. Conversely, a repository can be unreachable for several hours without changing the validated view already held by operators, provided cached material remains usable and no urgent update is missed.

This distinction is more than technical punctuation. Policy documents often use availability as if it were a property of a machine: minutes up divided by minutes in a month. RPKI is a publication service embedded in a distributed security decision. Its useful output is a validated set of assertions, not a responding web page. A measurement that stops at the repository's edge therefore measures the operator's ability to serve itself, not the relying party's ability to rely.

The proper question is observable from outside: at a stated time, from a stated network, using a stated protocol and validator version, could a relying party retrieve the complete material required for a stated certification path, validate it under the applicable standards, and produce the expected validated payloads before freshness margins were exhausted?

That question is longer than "was the server up?" because the service is longer. It also allocates responsibility more fairly. It can show a repository-side failure, a path-specific reachability problem, a validator defect, a stale local cache, or a router-delivery delay without pretending that all five are one event.

RPKI publication is a chain of timed dependencies

RPKI gives operators a way to evaluate whether an autonomous system is authorised to originate a prefix. A resource holder creates a Route Origin Authorisation. Certificates bind the relevant number resources into a certification path. Repositories publish certificates, ROAs, manifests and Certificate Revocation Lists. Relying-party software fetches and validates those entities, produces validated payloads, and supplies them to routing systems, commonly over the RPKI-to-Router protocol. The router applies local policy to BGP announcements classified as Valid, Invalid or NotFound.

Every verb in that sequence has its own failure boundary. A holder may submit the wrong origin or maximum length. A certification service may issue an inconsistent certificate. A publication service may fail to expose a completed change. One access protocol may work while another fails. A relying party may reject too much, retain too little or refresh too slowly. An RTR session may stop carrying a current set. A router may receive the set and apply an unexpected policy. A route may be filtered by one network and accepted by another.

The repository is central because all relying parties need a retrievable publication view, but it is not a router and does not command a universal response. RFC 7115 makes routing policy local. That limits what a repository report may honestly claim. It can establish that entities were unavailable or invalid, that certain validated payloads disappeared under defined software, and that observed routes changed state at selected vantage points. It cannot infer every operator's policy or every customer's reachability from those facts alone.

Time links the layers. A ten-minute interruption during ample freshness headroom differs from a ten-minute interruption that crosses a manifest's nextUpdate. A delayed new ROA differs from the disappearance of a previously valid one. A cache that protects continuity for one validator may be absent or already near expiry in another. Service quality must therefore be expressed as a sequence of timed evidence, not a single duration.

Internal uptime is necessary and radically limited public evidence

Conventional availability monitoring asks whether a host or application responds. It remains useful. An operator should know whether origin servers, storage, signing services, publication workers, DNS, TLS termination and distribution nodes are healthy. But an internal check has three structural blind spots.

First, it usually begins inside or near the provider's own network. It may bypass the DNS resolver, peering path, address family, content-distribution node or access control encountered by an external validator. A successful request from the same facility proves little about reachability from Africa, Asia, Europe or the Americas.

Second, it tends to test transport rather than meaning. HTTP status 200 can deliver an old RRDP notification file. An rsync daemon can answer while exposing a partially updated tree. A file can be present but absent from the current manifest, listed with the wrong hash, signed under an invalid chain, or paired with a stale CRL. The server is alive; the assertion is unusable.

Third, internal monitoring often knows that a publication action was attempted but not whether independent users received it. A queue can mark a task complete when data reached an origin directory, even if a distribution layer retained the previous view. The difference between attempted publication and externally visible publication is precisely where an assurance service must look.

An externally reproducible standard does not discard provider telemetry. It puts it in the right place. Internal evidence explains cause and accelerates repair. External evidence establishes user-visible condition. The service commitment should require both and specify how disagreement is resolved. If internal checks say healthy while diverse outside validators fail semantically, the service is degraded until the discrepancy is explained.

Caches turn a simple outage into a race against cryptographic time

RPKI was designed with local caching because repositories and network paths cannot be assumed continuously reachable. RFC 8182 advises relying parties to keep old entities, and RFC 9286 recommends continued use of cached entities associated with a failed fetch until they become stale or can be replaced successfully. This is an important continuity feature. It is also why raw downtime is a poor description of risk.

At the beginning of an interruption, two relying parties may hold different but valid cache states. One refreshed moments earlier; another is approaching its next scheduled retrieval. Their remaining freshness margins differ. If the repository recovers quickly, both may continue producing the same validated payloads. If recovery arrives after relevant time boundaries, one may lose entities earlier than the other. A third implementation may follow a different local policy for stale material.

The incident therefore has at least three clocks. The first measures external fetch failure. The second measures freshness headroom for each affected certification branch. The third measures when validated output actually changes. Policy reports commonly publish only the first, if they publish any. Yet the second identifies urgency and the third identifies security-service consequence.

Caching can also conceal a failed update. Existing entities remain valid, so general validation appears stable, but a holder's newly created correction is absent. If the missing change was intended to authorise a migration or repair an accidental Invalid state, continuity for old material does not mean service was available for the affected holder. Read availability and change-publication availability need separate measures.

A sensible report plots these clocks together. It states when independent fetches first failed, the minimum observed time to relevant expiry or staleness, when expected changes stopped appearing, when validators changed output, and when a defined share of probes converged on recovery. That account shows whether cache resilience worked and how close the system came to a sharper consequence.

Manifests and revocation lists make semantic availability testable

An RPKI repository is not merely a directory of signed files. Manifests enumerate the signed entities associated with a certification authority and include hashes. They help relying parties detect deletion, substitution and incomplete views. Certificate Revocation Lists identify revoked certificates. Their timing fields create externally visible expectations about freshness.

RFC 9286 gives an unusually useful basis for service measurement. A relying party must fetch the manifest identified by the certificate, check that current time falls within the manifest interval, acquire every listed file and verify each hash. An invalid or stale manifest, a missing listed file, or a hash mismatch is a failed fetch. The relying party should continue using appropriate cached versions until they become stale or a successful fetch replaces them.

This means an outside observer need not trust an operator's statement that publication was complete. The observer can test the signed inventory against the retrieved files. It can record the exact certification authority at which validation stopped, the reason, the protocol and the remaining cache margin. Repeating that test from independent networks creates a verifiable availability history.

The same method avoids exaggeration. A failed branch does not automatically invalidate unrelated branches. An unavailable delegated publication point should not be reported as proof that every entity under a regional trust anchor disappeared. Results should be scoped to the affected authority, entities and validators. Over-broad labels obscure both engineering and accountability.

Semantic measurement also prevents the reverse error: treating a reachable endpoint as a healthy repository when time fields or entity consistency have already failed. In RPKI, integrity controls are part of availability because a file that cannot be safely relied on is not the service promised.

The JPNIC interruption in 2020 shows why elapsed downtime is not impact

JPNIC reported that its ROAWeb and RPKI repository were unavailable from 23:29 on 15 May to 10:01 on 16 May 2020, Japan time, after a hardware-related power failure. Users could not create or delete ROAs, and outside parties could not download certificates, ROAs and other files. This was plainly a service interruption.

Yet JPNIC also reported that validation results based on previously downloaded ROAs did not change because certificate expiry and the nextUpdate values of the CRL and manifest were not exceeded. That is the distinction an external service commitment should preserve. The publication endpoint failed for roughly ten and a half hours, but the cached validation function described in the notice continued for the entities and users within the stated conditions.

The event still mattered. Holders temporarily lost the ability to make changes. A newly needed authorisation or revocation could not be completed. Validators without the relevant prior cache, or with a different local condition, might not have enjoyed the same continuity. The public notice did not establish every relying party's state or every route's reachability. It established a bounded, technically meaningful claim about unchanged published content and unexhausted freshness times.

That is better than calling the event either harmless or catastrophic. A well-designed metric would report separate unavailability for management actions and publication fetches, then a zero observed validated-output change among the tested cache states. It would disclose the probes, entity branches and validators used to reach that conclusion.

The lesson is positive. Cryptographic time and caching can absorb a repository failure as intended. Policy should reward that resilience while still recording the denied change service. A provider should not lose availability credit for routing continuity, nor receive full credit when holders could not issue a necessary update.

APNIC's 2019 event shows why each access protocol needs its own result

APNIC's service announcement for 13 December 2019 describes a twenty-minute partial RPKI outage. The rsync repository state was incomplete and a stale, revoked manifest was published, causing a number of certificates and ROAs to be invalid. Validators using RRDP were not affected and continued to see full validity.

One incident therefore produced two materially different external realities. A monitor that tested only RRDP would have declared success. A monitor that tested only rsync would have found semantic failure. A server-level aggregate might have averaged the two into a reassuring percentage while hiding that users of one standards-supported method received an unusable view.

Protocol diversity can provide resilience only if measurements retain the distinction. The relevant indicators include RRDP notification retrieval, snapshot and delta integrity, session and serial progression, rsync reachability, tree completeness, and whether fallback occurred when the preferred method failed. A provider should also disclose whether the two methods share an origin, storage system, network path or update process, because nominally separate access methods may have a common failure mode.

Relying-party behaviour belongs in the account. RFC 8182 permits alternative access mechanisms when RRDP has problems, but a configured or implemented fallback is not guaranteed to work in every deployment. The 2020 study of relying parties found inconsistent fetching behaviour under its experimental conditions. Those results came from a bounded set of observed certification authorities and tests; they are not a denominator for all current validators. They do show why publication operators should test actual client behaviour rather than infer it from protocol design.

An external commitment should never publish one RPKI availability number without a protocol breakdown. If one method supplies a complete valid view and another does not, the service is resilient for some users and degraded for others. Both facts belong in the headline.

RIPE NCC's 2020 failure shows the danger of a silent publication gap

In February 2020, RIPE NCC reported that a disk problem prevented newly created, modified or deleted ROAs from reaching its publication server. The notice identified 176 such changes. The affected information was retained elsewhere, but publication did not occur, and the disk did not report a problem that alerted engineers.

This was already an outage before any cryptographic entity expired. The holder-facing action and the externally visible state had diverged. A user could reasonably believe a change had been accepted while relying parties continued to retrieve the old state. The service failed at publication confirmation even though files were still being served.

The event then crossed a second boundary. RIPE NCC reported that the CRL expired, after which underlying entities also expired. The abnormal condition appeared differently depending on the relying-party software. Repair required more than clearing the disk problem; the organisation ultimately performed a full certification-authority key roll before resolution.

Traditional uptime misses both the silent phase and the semantic cliff. An externally reproducible test would have compared a signed or otherwise verifiable accepted-change reference with observed publication, tracked CRL freshness headroom, and raised an alarm when the repository view failed to advance. Independent validators would then show how the expired branch affected output under named versions.

The incident also demonstrates why status discovery is part of service quality. The failure began on a Saturday, the CRL became stale on Sunday, and the organisation said it was notified on Monday. A repository can be continuously monitored and still be operationally blind if its checks do not verify that new authoritative state is externally present.

Policy should ask not only how quickly engineers repaired a known event, but how long the service was wrong before anyone knew. Mean time to external detection is a first-class RPKI indicator.

RIPE NCC's 2021 incident shows that completeness can fail for only some validators

On 7 January 2021, an outgoing resource transfer caused RIPE NCC's system to publish an updated parent certificate ahead of the associated child certificate. During the inconsistent interval, the child over-claimed resources no longer present on the parent. The organisation reported that older relying-party implementations using a strict manifest interpretation rejected all certificates listed on the manifest when one entry was invalid.

The same published state therefore produced different results by software version. RIPE NCC estimated from access logs that 327 relying-party instances were affected and warned that the incident might have resulted in outages. It did not claim that 327 networks lost reachability, still less that every route under the trust anchor failed. That restraint is important: an instance count is not a network count, and rejected certificates are not a universal customer-impact denominator.

The event exposes a weakness in policy reports that use a single reference validator. Conformance evolves. Implementations interpret difficult cases differently, bugs are fixed, and operators update at different speeds. A repository can pass the newest implementation while creating serious consequences for a deployed older population.

External assurance should maintain a disclosed compatibility panel of supported and materially deployed validators. It should record output differences at certification-branch and validated-payload level. The panel is not a vote on standards compliance; a non-conforming implementation should be identified as such. It is a measure of foreseeable operational exposure while updates propagate.

RIPE NCC's proposed remedies also point to the right metric. It sought atomic publication and shorter inconsistency windows. The service objective should measure externally observed atomicity: no probe should retrieve a parent state and child state that cannot validate together. That is more meaningful than measuring how quickly two internal update jobs finished.

JPNIC's 2022 event shows the delayed conversion from Valid to NotFound

JPNIC's February 2022 notice reported that a growing access log filled the repository server's disk between 26 January and 2 February. The publication process could not update nextUpdate fields in CRLs or manifests. Once those fields passed, related ROAs could no longer be validated by clients, and routes they had covered were detected as NotFound.

This sequence matters. The service did not necessarily move routes directly from Valid to Invalid. It removed usable authorisation evidence, producing NotFound for the affected validation view. Many operational policies accept NotFound, often with different preference from Valid. The security consequence may be a loss of protection rather than an immediate loss of reachability. A report that calls every vanished ROA a routing outage confuses those outcomes.

The event lasted long enough for cached continuity to run out. An availability measure based solely on successful TCP connection would have been particularly misleading if the server still answered while publication freshness stopped. The useful alarm was decreasing time to nextUpdate combined with failure to observe a new manifest and CRL.

JPNIC also said a knowledgeable user reported the problem. That fact supports an institutional reform: independent monitors should have a defined, authenticated and continuously staffed route into repository operations. External discovery should not depend on whether a specialist happens to notice an anomaly and find the right contact.

A report for this class of event should quantify, within the measured set, when each affected ROA ceased producing a validated payload, which routes changed from Valid to NotFound at selected BGP vantage points, and whether any operators reported policy or customer consequences. If customer data is unavailable, it should remain unavailable rather than being inferred from the number of ROAs.

ARIN's 2022 degradation shows the value and limits of transport redundancy

ARIN reported a ninety-minute RRDP service degradation on 11 August 2022 after a configuration change installed mismatched certificate material on some serving nodes. The organisation removed affected nodes from DNS rotation, restored matching material and restarted repository generation. Its rsync service remained functional throughout, while publication of six ROAs was delayed.

This is a useful case of partial resilience. The alternative publication method remained available, and the provider gave a bounded number of delayed changes. But it does not follow that every relying party obtained those changes through fallback. Operators may prefer RRDP, apply retry schedules, lack working fallback or have network paths that reach one service differently from another.

The right scorecard would show successful retrieval by protocol and vantage point, fallback attempts and outcomes, publication delay for the six affected ROAs, and validated-output convergence after repair. It would also distinguish the public repository's existing state from the temporary pause in generating new state. Availability for an operator with a current cache was not identical to availability for a holder awaiting one of the delayed ROAs.

Redundancy deserves credit only when independently exercised. Two URLs served by the same misconfigured node pool are not two controls. RRDP and rsync with separate failure modes can improve continuity, but the provider should prove that validators can use the surviving path before freshness expires. Scheduled drills, such as a controlled withdrawal of one method, can reveal whether fallback works without waiting for an emergency.

This is where external tests outperform architectural diagrams. They show the path that clients actually took, the view they actually validated and the time at which delayed assertions became useful.

A repository service commitment needs four separate service objectives

The first objective is retrieval availability. From independent vantage points, can a relying party resolve the repository name, connect over the supported address family, negotiate the required transport and retrieve the RRDP or rsync material? Results should be divided by protocol, IP version, region and network provider. A monthly mean should not hide a complete failure for one combination.

The second is semantic availability. Does the retrieved view contain a current valid manifest, the listed entities with matching hashes, a usable CRL and a valid certification path? Can the validator produce the expected payload set without discarding an unrelated branch? This objective converts cryptographic correctness into a service indicator.

The third is publication timeliness. After an authorised action is accepted, how long until independent probes observe the new entity and produce the corresponding payload change? This objective covers creation, modification, revocation, transfer and emergency correction. It requires a privacy-preserving reference that lets an auditor match the action to publication without exposing account secrets.

The fourth is recovery convergence. After repair, how long until a defined panel of independent validators reaches the same current view and routing systems receive it? A repository that is fixed at origin but remains stale at distribution nodes has not fully recovered. Nor has one whose files are current while RTR sessions still supply an old payload set.

Each objective needs an explicit denominator. Retrieval may use scheduled probe attempts. Semantic availability may use certification branches expected to be current. Publication timeliness may use accepted actions eligible for immediate publication. Recovery may use active probes with a known pre-incident state. Mixing these populations produces an attractive but meaningless percentage.

The four-objective model also supports fair attribution. A repository can meet retrieval while failing semantic integrity, or meet both while a holder's requested change remains wrong. Operators and oversight bodies can see exactly which promise failed.

Independent probes must be diverse enough to challenge the provider's assumptions

A neutral measurement network should include probes in multiple regions and autonomous systems, using both IPv4 and IPv6 where offered. It should avoid concentrating all probes in one cloud whose path or resolver can fail as a unit. The number and placement need not pretend to represent every Internet user; they must be disclosed so readers understand the observed population.

Each probe should use a controlled clock, record DNS answers, destination address, transport timing, protocol response, entity hashes, validator name and version, trust-anchor material, cache state and final validated payload digest. Sensitive operational details can be protected, but enough evidence should be published for another qualified party to repeat the test.

Fresh and warm-cache modes are both necessary. A fresh validator shows whether a new relying party can build the view. A warm validator shows whether an established operator can continue through a failure. Testing only fresh instances exaggerates immediate loss; testing only warm ones hides onboarding and cache-exhaustion risk.

The probes should retrieve at realistic intervals while respecting repository capacity. A measurement system that overwhelms the service creates the condition it claims to observe. Providers and researchers can agree rate limits and dedicated identification without giving the provider a path that bypasses ordinary distribution.

False alarms need disciplined handling. A single probe failure may arise from its resolver, local clock, disk, validator or upstream path. Incident declaration should use a pre-announced rule, such as semantic failure across a minimum number of independent networks or a provider confirmation. Localised failures still belong in the data, but not every one becomes a global notice.

The standard should publish probe code, test vectors and result definitions. Reproducibility comes from shared method and signed observations, not from institutional prestige.

Freshness headroom is the risk indicator that a green dashboard cannot supply

At any moment, a repository branch has a remaining interval before a relevant manifest or CRL becomes stale or a certificate expires. That interval is its freshness headroom. It converts an ordinary fetch problem into an operational risk measure.

Suppose outside probes fail to fetch a branch while its current manifest has eighteen hours remaining. The event deserves attention, but cached validators have room to continue. If headroom falls to one hour without recovery, the same transport condition becomes urgent. If a newly required revocation is also waiting, the security risk may already be high despite unexpired old entities.

The provider should report minimum, median and distribution of headroom across affected branches, not only the repository-wide minimum. One delegated authority with an unusually short interval should not be used to imply that every branch is near failure. Equally, a long-lived parent certificate should not mask a child manifest near staleness.

Headroom supports a burn-rate alert. If an event consumes freshness margin faster than repair confidence rises, escalation should occur before expiration. This is analogous to managing a reserve: the service has not yet failed semantically, but its capacity to absorb delay is shrinking.

Entity timing is not the entire risk. A holder waiting for a new authorisation may have zero practical headroom because a network migration is under way. The incident record should permit affected holders to mark an urgent expected change, with evidence and review, without exposing confidential commercial plans publicly.

A policy report that publishes headroom explains why one ten-hour outage had no validation change while another multi-day publication failure did. It gives boards and operators a common language for urgency that raw uptime cannot provide.

Attribution requires a shared sequence from authorised action to route effect

When an RPKI incident becomes contentious, each entity sees only part of the sequence. The holder knows what it requested. The certification service knows what it accepted and signed. The repository knows what it served. The relying party knows what it fetched and rejected. The router knows which payload set and policy it used. The customer knows that a service became unreachable. Without correlated times, responsibility becomes assertion.

A common incident record should assign a stable reference to each material action and record six milestones: authorisation accepted, entity produced, entity externally published, entity fetched and validated, payload delivered to a router, and relevant route decision observed. Each milestone should identify the responsible institution and clock source. Public reporting can hash or aggregate sensitive references while preserving the sequence for independent review.

This method distinguishes a wrong entity from an unavailable entity. If the holder requested the wrong maximum length and the service faithfully published it, responsibility differs from a code defect that produced a certificate inconsistent with the registration state. If the repository published a correct entity but an obsolete validator rejected a wider branch, the provider still has compatibility and communication duties, but direct technical cause is different.

Attribution also needs counterfactual testing. Investigators can replay the observed entity set through named validators and compare the resulting payloads, then apply the operator's stated route policy to captured BGP announcements. This does not reconstruct every packet or lost transaction. It tests whether the alleged chain is technically possible and where state first diverged.

No institution should control the only copy of this evidence. Providers can sign milestone records; neutral monitors can sign external observations; operators can retain RTR and routing-policy history. Shared evidence makes narrow responsibility possible, which is fairer than both blanket blame and blanket immunity.

Routing impact must be measured, not presumed from entity count

A repository incident can change routing security without changing reachability. When a valid ROA disappears from the usable view, an announcement may become NotFound and remain accepted. Protection against an unauthorised origin may weaken, but the legitimate route may still work. When an inconsistent certificate causes a valid authorisation to disappear while another covering ROA remains, the route's state may not change at all. When a wrong ROA makes a legitimate announcement Invalid, operators that reject Invalid routes may withdraw reachability while others continue to accept it.

The impact study therefore begins with validated payload differences. Which prefix, maximum-length and origin tuples were added or removed under each validator? The next step joins those differences to BGP announcements observed at named collectors or operator feeds. The final technical step applies disclosed policy assumptions or, where available, the actual operator policy.

Customer impact needs separate evidence: alarms, traffic loss, failed sessions, support reports or service-level breaches. Route collectors do not see every private peering path, and a changed validation state does not reveal how much traffic used it. Reports should avoid translating prefixes into users or revenue without data supplied by affected networks.

The same discipline protects providers from inflated claims. An incident that made one branch temporarily NotFound should not be described as proof that the regional Internet went offline. It also protects operators from minimisation. If several independent networks recorded an Invalid route being rejected and traffic fell at the same time, a statement that the repository host remained reachable is irrelevant.

The proper output is a layered impact table: publication entities affected, validated payloads affected, observed announcements affected, networks with evidenced policy response, and customers or services with documented consequence. Unknown cells stay unknown.

Denominators should be local, disclosed and resistant to promotional reuse

RPKI measurement attracts impressive numbers because the system is global in purpose. But no public observer has a complete census of relying-party instances, software versions, cache histories, routing policies, private BGP paths or end-customer effects. A credible service commitment does not manufacture that denominator.

Every rate should carry its observed population. Probe availability is successful checks divided by scheduled checks from the named probe set. Validator compatibility is successful outputs divided by the versions and test cases in the panel. Publication timeliness is actions observed within target divided by eligible accepted actions in the reporting period. Route effect is changed announcements divided by announcements visible at the named collectors. None is "the percentage of the Internet affected."

The IMC 2020 relying-party study is valuable precisely when bounded. It observed clients reaching three certification authorities and used controlled conditions to expose inconsistent fetching. Its reported proportions describe that experiment, not every current operator or every future version. Policy reports should preserve such boundaries when citing research.

Incident-specific counts need similar restraint. RIPE NCC's estimate of 327 affected relying-party instances in January 2021 came from access logs and a defined software behaviour. Instances can share a network, serve several networks or be test systems. The number is evidence of operational exposure, not a count of disconnected organisations.

Good measurement can still be forceful. It can say that every probe in five independent networks rejected the same branch, that all three tested current validators lost the same payloads, or that a named route disappeared at two collectors. Precision strengthens accountability because the claim can be reproduced and challenged.

Incident reports should separate cause, condition, consequence and confidence

The cause is the initiating failure: full disk, misordered publication, mismatched certificate material, power loss or software defect. The condition is what outside users encountered: fetch failure, stale manifest, incomplete rsync tree, inconsistent certification path or delayed change. The consequence is the observed output: payload removal, state change, rejected route or customer interruption. Confidence states how strongly the evidence connects them.

Many notices collapse these layers into a single sentence. That creates confusion when later evidence changes. A provider may know the condition before it knows the cause. An operator may prove a route consequence before the provider reproduces the external path. Reporting the layers separately lets the public account improve without erasing the original observation.

The notice should include exact start and end definitions. Start may be the first failed external semantic check, not the time an engineer opened an incident. End may require successful validation from a quorum of probes and publication of delayed changes, not merely restart of a process. Detection, acknowledgement, mitigation and full convergence times should all be visible.

Confidence can be graded by evidence: confirmed by signed entity replay, observed by multiple independent validators, reported by an affected operator, or inferred from timing. This is not a substitute for facts. It tells readers where further investigation is needed.

The provider should also publish what was not measured. If no customer-loss data was collected, say so. If rsync was tested but RRDP logs were unavailable, state the gap. If a BGP collector did not see the affected route, do not treat absence as proof of no effect.

An honest report can be concise and still contain these fields. The purpose is not bureaucratic length. It is to prevent a narrow uptime claim from crowding out the evidence that operators need.

Service credits alone are a poor remedy for routing-security interruption

RPKI publication is often included within membership or registration service rather than sold as a separately priced utility. A conventional fee credit may therefore be trivial, difficult to calculate or unavailable to relying parties and downstream customers. The most valuable remedies are operational.

First comes rapid correction. Providers need a continuously staffed path for reporting a wrong, missing or stale entity, with authentication that does not depend entirely on the potentially affected portal. The response target should vary by freshness headroom and demonstrated routing risk.

Second comes evidence preservation. Entity versions, publication times, access-method state, validation results and change authorisations should be retained long enough for investigation and legitimate claims. A repair that overwrites the evidence leaves institutions arguing from memory.

Third comes portable communication. A signed incident notice should identify affected certification branches and entity digests so validators and operators can determine exposure without trusting screenshots or rumours. Updates should state whether existing caches remain usable and whether a requested change is delayed.

Fourth comes independent review for severe or repeated events. The reviewer should test the external objectives, examine provider controls and publish findings within security limits. A provider-authored account is necessary but cannot be the only assurance where the provider's own monitoring missed the failure.

Financial remedies may still matter where actual loss and legal responsibility are established. Their design belongs with liability, causation and applicable law. The service commitment should not promise impossible compensation, but neither should a low or zero fee be used to deny the duty to publish accurately and repair promptly.

Operators also have measurable continuity duties

External accountability is not a device for transferring every RPKI risk to a repository. Network operators choose validators, refresh intervals, redundancy, monitoring and routing policy. Resource holders choose ROA content and timing. These decisions materially affect consequence.

An operator should run supported relying-party software, monitor successful repository synchronization, retain at least the cache behaviour recommended by the applicable standards, and test RTR redundancy. It should know how its routers behave when payloads disappear or validators become unavailable. A second validator that shares the same resolver, power supply and software defect is not robust redundancy.

Resource holders should compare ROAs with intended announcements before network changes, avoid unnecessarily permissive maximum lengths, and verify external publication after creation or transfer. They should maintain emergency contacts and understand which party controls keys in hosted and delegated arrangements.

These duties should appear in incident analysis without becoming a blanket excuse for repository failure. If an operator ran obsolete software that rejected more than standards required, that is relevant. If a repository published an inconsistent state, that is also relevant. Several causes can contribute to one loss.

Shared drills can improve both sides. A provider can announce a test window in which one access method is withdrawn while operators verify fallback. Synthetic certification branches can test expiry alarms and atomic updates without putting production routes at risk. Operators can report anonymised convergence results.

The aim is reciprocal evidence. Providers demonstrate external publication quality; operators demonstrate prudent reliance. When both are measured, residual uncertainty becomes visible instead of being assigned by contract or rhetoric alone.

NRS can make external assurance a legitimacy service

NRS argues that number registries should maintain accurate records, respect the operational role of networks and remain bounded by a bookkeeping function. RPKI complicates that philosophy because certificate and repository actions can influence which routing announcements operators accept. The appropriate response is not to reject RPKI. It is to make the added power observable and accountable.

NRS could convene holders, operators, registry engineers, relying-party maintainers and researchers around a common repository assurance profile. The profile would define the four service objectives, minimum incident fields, protocol-specific tests, freshness reporting and attribution milestones described here. Participation could begin voluntarily, with results published by service and region.

It could also operate or commission neutral probes. Independence would require disclosed funding, open measurement code, conflict rules and multiple hosting networks. NRS should not certify its own advocacy by assertion. It should publish evidence that any operator, registry or researcher can reproduce.

A useful annual review would compare each participating repository with its own published objectives, not rank regions through a crude universal score. It could identify repeated partial failures, untested fallback, slow external detection or weak recovery evidence. Providers would have a right to correct factual errors and attach explanations, while the underlying observations remained available.

This is a positive institutional role because it rewards good performance. The JPNIC 2020 event, for example, could receive credit for cached validation continuity while recording management and fetch unavailability. APNIC's 2019 event could show RRDP resilience and rsync failure separately. Nuance would replace both alarmism and self-congratulation.

NRS would thereby translate a broad demand for registry accountability into a practical public good: comparable evidence about whether critical routing-security assertions are externally usable.

Procurement and public policy should ask for evidence that can survive disagreement

Governments, critical-infrastructure operators and large networks increasingly depend on RPKI without necessarily operating the certification and publication layers they trust. Their procurement questions should move beyond whether a provider claims high availability.

They should ask where RRDP and rsync are hosted, whether their failure domains differ, how often full external validation runs, what freshness headroom triggers escalation, how accepted changes are matched to publication, which validator versions are tested, how incidents are announced, and how evidence is preserved. They should request recent drill results and examples of recovery convergence.

Public policy should resist mandating one universal route response to a repository event. Operators have different risk positions, and fail-open behaviour has continuity benefits as well as security costs. The more constructive requirement is transparency: disclose the validation view, local policy and fallback plan for systems whose interruption would affect public services.

Oversight should also distinguish a regional registry repository from delegated publication points below it. A trust anchor can be reachable while a delegated authority fails. A policy that assigns every delegated outage to the parent will discourage delegation without improving measurement. The certification path identifies where the failure occurred; governance should follow that evidence.

Insurance and board risk reviews can use the same model. They can examine whether an organisation knows its cache margin, has independent validators, retains route-policy history and can reach the appropriate repository contact. This turns RPKI from an abstract cyber-security control into an auditable continuity dependency.

The standard need not guarantee uninterrupted routing. It should guarantee a disciplined answer to a narrower question: what was externally available, when did it cease to be usable, who controlled the failing step, and what routing consequence was actually observed?

The repository outage policy misses is the one hidden between publication and reliance

RPKI repositories have already demonstrated that failures do not fit a single uptime counter. Hardware can stop access without exhausting cached validity. A stale manifest can damage rsync while RRDP remains coherent. A disk can silently block changes until a CRL expires. Parent and child certificates can be individually authentic yet temporarily inconsistent. A distribution node can serve mismatched transport credentials while an alternative method remains available.

These are not arguments against route-origin validation. They are evidence that routing security has matured into infrastructure that deserves mature service assurance. Cryptography makes tampering detectable; it does not make publication infallible. Caching provides continuity; it does not prove that new state arrived. Local routing policy preserves operator autonomy; it does not eliminate repository responsibility.

The best availability claim is consequently modest and exact. A provider can say that named independent probes fetched complete current material through stated methods, that all tested certification branches validated, that accepted actions became visible within target, that supported validators converged after repair, and that observed routing effects were or were not found in a defined population. Another party can repeat the tests.

Anything broader needs more evidence. An internal dashboard cannot prove external fetchability. A missing ROA cannot prove customer loss. A stable BGP collector cannot prove no private network was affected. A global percentage cannot be built from an undisclosed sample.

Registry legitimacy grows when the institution does not ask the public to accept its uptime on faith. NRS and the wider operator community can help establish that norm. The repository should be judged at the point where its assertions become usable, before their clocks expire and after their consequences are visible.

That is the outage policy reports usually miss: not the moment a machine stopped, but the interval in which the Internet's relying parties could no longer obtain the same timely, coherent and accountable statement of routing authority.

Sources