Summary

  • The RPKI-to-router chain separates authority from action. Resource holders and certification authorities publish signed entities; relying-party software validates them and exports validated payloads; routers classify routes; operators decide what Valid, Invalid and NotFound mean in local import, best-path and export policy.
  • RFC 8481 made the boundary explicit in 2018: implementations should set the validation state, but no policy should be applied without specific operator configuration. The operator, not the registry or validator, makes the final treatment decision.
  • Local control does not make upstream actors irrelevant. A mistaken certificate, revocation, ROA or repository state can alter every downstream classification that correctly follows it. Responsibility therefore has to be divided by the act controlled, rather than assigned entirely to either a registry or a network carrying the route.
  • “Invalid” is a cryptographic and syntactic result against the validated data available at a moment. It is strong evidence for routing policy, but it does not identify whether the underlying cause is a hijack, a holder mistake, a transfer lag, an incorrect maxLength, an adverse certificate action or stale validation data.
  • Router policy is not a single binary switch. Networks can reject Invalid routes, retain them but make them ineligible for best-path selection, lower preference, limit treatment by peer class, alert first, or maintain narrow local exceptions. Each choice has different security, reachability and recovery effects.
  • The operating chain has timing and state. RPKI-Router Protocol sessions carry announcements and withdrawals from caches, use serial and session identifiers, and specify refresh, retry and expiry behaviour. A correction at the registry does not become a repaired forwarding decision until publication, validation, cache transfer and router reevaluation have all converged.
  • Governance should require decision receipts at every boundary: the signed entity and reason for change, validator version and trust inputs, cache serial and age, router policy version, affected peer class, observed route consequence, exception authority and recovery time. A label without this evidence is too thin for appeal or liability.
  • A Number Resource Society can compare these boundaries, test correction paths and represent smaller operators without becoming a global routing controller. Its useful role is to make authority and remedy legible while preserving the operator's right and duty to decide local routing policy.

The final decision is local by design

The most consequential sentence in modern origin validation is not found in a registry contract or a router command guide. It appears in RFC 8481, published in September 2018: once routes have been evaluated and their validation state set, the operator should be in complete control of policy applied from that state. Without specific operator configuration, policy must not be applied. The standard's instruction is “set state, don't act.”

That distinction answers the narrow question of who decides the final treatment of an Invalid route. The network operator does. An RIR can operate a trust anchor, issue certificates, host a certification service and publish entities. A resource holder can authorize an origin AS in a ROA. A validator can retrieve repositories, authenticate a certificate path and produce validated ROA payloads. A router can compare a BGP announcement with those payloads and attach a state.

None of those steps, on its own, decides whether a particular network accepts the route from a customer, prefers it from a peer, exports it to transit or installs it in a forwarding table.

The answer is simple only if “decides” means the last configured action. It becomes more difficult when deciding is confused with causing. A registry error can cause a correct validator to remove an authorization. A correct cache can cause a router to reclassify a long-standing route. A vendor default can make a policy more aggressive than its operator understood. A transit provider's rejection can make a holder unreachable even while the holder's own network continues to accept the route. Several institutions can be causally important, but only one network administration controls each local routing decision.

This distribution is a constitutional feature of interdomain routing. Autonomous systems are autonomous partly because they choose whom to connect to and which routes to use. Turning a registry's signed entity into a universal remote-control instruction would concentrate routing power in the certification hierarchy and erase differences in risk, customer obligation and local knowledge. Conversely, pretending the registry merely publishes harmless information understates how strongly its authenticated entities can shape automated policy.

Good governance must hold both propositions together. Certification authorities are accountable for the statements and status changes they control. Operators are accountable for the routing policy they choose and the resilience with which they apply it. The missing layer is not a new central decider between them. It is a visible allocation of duty, evidence and remedy across the boundary.

Four verbs prevent one institution from inheriting every duty

Public discussion often compresses origin validation into one verb: “RPKI blocks hijacks.” The phrase is useful advocacy and poor institutional analysis. Four different verbs are involved: authorize, validate, classify and act. Each has a different subject, evidence base and remedy.

A holder authorizes an origin by issuing or requesting a ROA under a certificate path. In a hosted service, an RIR may control more of the key and publication operation; in delegated arrangements, the holder can control more directly. The certification hierarchy establishes whether the signer has the relevant number-resource authority. The resulting entity says that an AS is authorized to originate a prefix within a specified length bound. It does not announce the prefix in BGP and it does not promise that the route is commercially acceptable.

A relying party validates. It retrieves signed entities, checks certificates, revocation lists, manifests and entity profiles, and constructs a current set of usable payloads according to standards and local trust configuration. This is a computational judgment about authenticated data. Different validator implementations or repository views can temporarily disagree. Local filters and assertions can also produce a view that differs deliberately from the global data.

A router classifies a route by comparing its origin and prefix with validated payloads. The familiar states are Valid, Invalid and NotFound. Valid means at least one relevant authorization matches. Invalid means covering authorization data exists but none authorizes the observed origin and prefix-length combination. NotFound means no relevant validated payload covers the route. The state describes that comparison; it is not a complete account of the route's history or legitimacy.

Finally, an operator acts. Its policies can reject, prefer, de-prefer, quarantine, tag, log or temporarily except a route. They can differ by customer, peer, transit, route server, address family, region or critical service. They interact with prefix filters, IRR data, max-prefix limits, communities, commercial preference and longest-prefix forwarding. A route retained at low preference can still attract traffic when it is more specific than a competing aggregate, a point RFC 7115 warns operators not to overlook.

The vocabulary matters because liability should follow control. A signer should answer for an erroneous authorization. A validator maintainer should answer for a reproducible validation defect within the assurance offered. A cache operator should answer for an insecure or stale distribution service it promised to operate. A network should answer for its own policy and testing. No layer should be allowed to claim the power of its output while describing every consequence as someone else's problem.

Invalid is a state, not a verdict on motive

An Invalid classification is more precise than a rumour and narrower than a judicial finding. Under origin validation, it means that at least one validated payload covers the route's prefix, but no payload both covers the announced length and names the observed origin AS. The mathematics do not say why the mismatch exists.

The mismatch may be an attempted origin hijack. It may also be a resource holder that changed transit providers before changing its ROA, an operational team that announced a more-specific prefix beyond maxLength, a transfer whose certificate state changed before routing coordination finished, or a registry action that removed authority unexpectedly. A validator may have a newer repository view than the operator's change ticket anticipated. A router may be using one cache while an engineer's diagnostic tool consults another. A local assertion may repair or create a difference.

All of these can produce the same three-letter state on a command line.

This does not make Invalid weak evidence. The purpose of origin validation is to turn authenticated authorization into a usable routing signal, and rejection of Invalid routes materially raises the cost of accidental and malicious misorigination. The classification is designed to support action. But a security control becomes governable only when it can distinguish immediate containment from final attribution.

An operator can reasonably reject an Invalid route first and investigate second, especially at a peer or transit edge where no authenticated customer exception exists. That immediate action is a local security judgment. If the affected holder claims error, the question changes. The parties then need the exact prefix, origin AS, covering payloads, maxLength, validator time, cache serial, router policy and first observed transition. They need to know whether any matching authorization existed elsewhere, whether a withdrawal was published and how quickly different views converged.

Treating every Invalid as proof of hostile conduct denies a meaningful correction right. Treating every Invalid as harmless configuration noise defeats the protection. The workable middle is procedural: contain according to declared policy, preserve evidence, provide an authenticated escalation path, classify the cause, correct at the layer that introduced it, and measure restoration. Such a procedure respects both the value of automated rejection and the possibility that authenticated data can be wrong.

The governance question is therefore not whether the label should be trusted. It is what claim the label supports, for how long, under which inputs, and what happens when a person with a legitimate interest contests it.

Registry authority is substantial, but it stops short of the forwarding table

RIRs occupy a powerful position because the RPKI certificate hierarchy follows number-resource administration. They operate regional trust anchors and services, maintain registration relationships and publish certificate material on which relying parties depend. In hosted arrangements they may generate and publish ROAs based on a holder's authenticated instructions. A revocation, resource-set change or publication failure can alter which payloads validators produce.

That is genuine authority. Calling RPKI merely an optional database obscures the effect of cryptographic priority and automated consumption. Once many networks reject Invalid routes, an erroneous upstream change can be translated into reachability loss across independent networks. The fact that each operator freely configured rejection does not make the erroneous certificate state irrelevant. A bridge authority cannot disclaim its own faulty signal merely because each driver chose to obey the light.

Yet an RIR does not operate the world's BGP speakers. It cannot know every bilateral peering term, emergency service dependency, private route, customer maintenance window or local exception. It cannot force a network to reject an Invalid announcement, nor should it be able to do so through an undocumented default. RFC 8481's operator-control rule prevents validation software from silently converting registry state into routing policy.

The boundary should be expressed in service commitments. Registries should warrant authenticated control, accurate processing of holder instructions, protected key operations, coherent publication, notice, correction and preserved records within defined limits. They should publish how certificate and ROA changes are authorized, what emergency channel exists, which timestamps are recorded, and how adverse or mistaken actions can be challenged. They need not warrant that every network carries every corrected route or compensate for all consequential business loss.

Operators, in turn, should not blame a registry for choices the registry did not make. A network that applies rejection without monitoring cache age, testing reevaluation or providing a customer escalation route owns those design decisions. A provider that ignores a corrected payload because its router discarded the path and never recovered it owns a different failure. A network that continues to accept a known misorigin for commercial convenience cannot describe that acceptance as compelled by the RIR.

Visible boundaries make responsibility stronger rather than weaker. They identify the institution capable of repair. The registry can fix the authorization state. The validator operator can correct retrieval or validation. The router vendor can fix implementation. The network can change policy and restore the route. A vague claim of shared responsibility often means no one has a clock running.

Validators are independent interpreters, not appellate courts

Relying-party software sits between signed publication and router consumption. It gathers entities from distributed repositories, authenticates them against configured trust anchors, applies validation rules and produces a set of payloads. RFC 8897 consolidates many requirements for this role, while independent implementations provide useful diversity in parsing, retrieval, cache handling and release practice.

The validator's discretion is bounded. It can reject a malformed entity, regard a stale or revoked chain as unusable, choose repository transport behaviour within standards, and expose diagnostics. It cannot declare a properly authenticated ROA unjust and substitute a different global authorization merely because an operator disputes the registry. If it did, software maintainers would become unappointed appeals bodies over number-resource authority.

There is nonetheless local autonomy. RFC 8416 defines SLURM, allowing an operator to filter validated payloads or add local assertions. This can protect routes during an adverse action or permit private use that the global RPKI cannot represent. The important adjective is local. An exception changes the view used by that operator and any customers to whom it deliberately supplies the modified view. It does not rewrite the signed state for other networks.

Validator operation therefore contains governance choices that should be declared. Which trust-anchor locators are accepted? Are any local filters or assertions loaded? Which repository transports are enabled? How is stale data treated? Which validator version and cryptographic libraries are running? Does the router receive one cache view or select among several? Who may approve an exception, how narrow can it be, when does it expire, and what evidence closes it?

Running multiple validators is valuable but does not answer those questions by itself. Two instances may share a repository path, trust configuration or package channel. When their outputs differ, majority voting can preserve a stale state just as easily as it can identify a defect. A useful comparison explains the difference at entity and input level: which bytes were fetched, which certificate path was accepted, what serial was exported, and which payload was added or withdrawn.

This is also why validators should not absorb routing policy. They should provide high-quality state, provenance, age and error information. The router and network policy layer should decide operational treatment. Combining validation and rejection behind one opaque managed service may be convenient, but it conceals the most important handoff: the moment an authenticated statement becomes a connectivity decision.

The RPKI-Router Protocol carries state, not institutional consent

RFC 8210 describes the practical bridge from a validated cache to routers. The router establishes a relationship with one or more caches, chooses according to configured preference, and requests a full or incremental set of data. Session identifiers distinguish cache instances; serial numbers identify logical versions within a session. Prefix announcements and withdrawals add or remove exact validated records. An End of Data message completes a coherent update and carries timing parameters.

These details are operationally important because policy is applied to state that changes over time. A cache can notify a router that new data are available, but the notification is a hint; the router still queries. If incremental history is unavailable, the router can reset and request a complete set or move to another cache. If the session identity changes unexpectedly, stale records may need to be flushed. A withdrawal in the cache-to-router protocol removes a previously announced right with the same prefix, maximum length and ASN.

The timing model creates a limited continuity window. A refresh interval indicates when the router should poll again. A retry interval governs attempts after failure. An expire interval limits how long current cache data may continue to be used without successful renewal. RFC 8210's recommended defaults are engineering parameters, not universal service promises, and deployments can configure values within specified ranges. What matters institutionally is that stale authorization does not have an indefinite life merely because a cache connection failed.

At the same time, expiry can change reachability risk. When validated data disappear, routes can move toward NotFound treatment or another implementation-specific state, depending on architecture and policy. A design that rejects only Invalid routes may fail open after expiry. A design that treats loss of validation as grounds for broad rejection may fail closed and disconnect valid networks. The standard transport behaviour cannot choose which continuity risk the operator should prefer.

The protocol's existence can tempt institutions to overread the message. A Prefix PDU is not a directive from an RIR to a router. It is data emitted by a cache trusted by the router operator, derived from the cache's validated view. Its serial number proves ordering within that cache session, not agreement among registries or permission under a peering contract. The router's use of it remains a configured local act.

A governable deployment records the handoff. It can show which cache session and serial supplied the payload used for a disputed decision, when the router accepted it, when a later withdrawal arrived and when affected paths were reevaluated. Without that record, the most operationally decisive step leaves less evidence than the certificate ceremony upstream.

Routers offer several treatments, each with a different remedy

Vendor and open-source router documentation confirms that origin validation does not impose one universal action. Cisco examples show policies that assign different local preference to Valid, NotFound and Invalid routes, and alternatives that keep Invalid paths while preventing them from becoming best. Juniper guidance separates the policy that marks validation state from the later term that rejects an Invalid route. FRRouting exposes route-map matches for the same states and can lower preference instead of discarding the path.

The first treatment is hard rejection on import. It prevents the route from entering the usable BGP decision set at that boundary. This offers clear protection but can complicate recovery if the implementation did not retain the rejected path. When a corrected ROA arrives, the router may need stored pre-policy routes, soft reconfiguration or a route refresh from the neighbor. RFC 9324 addresses the harm caused when new RPKI data trigger burdensome refreshes and recommends retaining paths affected by RPKI policy so they can be reevaluated locally.

The second treatment retains the path but makes it ineligible for best-path selection. It can recover quickly when validation changes because the route remains available for reevaluation. It consumes memory and requires assurance that the path cannot accidentally leak into forwarding or export. Evidence should distinguish “retained for recovery” from “accepted as usable.”

The third treatment lowers preference. This can support staged deployment or a customer-specific transition, but it is not equivalent to safety. If the Invalid route is the only path, it may still win. If it is more specific than a Valid aggregate, longest-prefix forwarding can attract traffic regardless of lower BGP preference. The exception must be designed around actual forwarding consequences, not only route-table cosmetics.

The fourth treatment is monitoring and tagging before enforcement. It gives operators time to identify customer errors, build an escalation service and test equipment. Its weakness is obvious: observation alone does not stop a hijack. A staged plan therefore needs dates, thresholds and accountable approval rather than an indefinite pilot.

Finally, an operator can apply narrow local exceptions. An exception may be justified for a verified holder during correction, but it should specify prefix, origin, affected sessions, approver, evidence, expiry and review. A broad permanent bypass silently creates a second authorization regime. The remedy for a false rejection and the control against an unsafe exception are the same thing: precise, time-bounded state with a preserved decision record.

Peering and transit turn one state into different obligations

Networks do not receive routes in a legal vacuum. A customer session, settlement-free peering session, transit feed and route-server session carry different expectations. Origin validation enters those relationships as one input among prefix authorization, export scope, traffic engineering, max-prefix protection and commercial preference.

A transit provider usually promises reachability subject to acceptable-use and routing-security terms. If it rejects a customer's Invalid route, the customer needs a clear notice and an authenticated way to demonstrate a corrected authorization. The provider may have strong grounds to reject, but it should still identify the prefix, observed origin and validation evidence. “The Internet says Invalid” is not an adequate service response because there is no single Internet router making the decision.

At a peering edge, a network may owe no duty to carry every route. It can adopt a strict policy as a condition of exchange. Yet transparency still matters because a false classification can affect both peers and their customers. Peering coordinators need to know whether rejection came from the local network, a route server, a validation service or a propagated state community. The use of an origin-validation extended community across iBGP or route-server arrangements can distribute state, but RFC 8481 warns against automatic action unless the operator configured it.

Route servers make the boundary especially visible. They may validate and filter on behalf of many members, or merely attach information and leave each member to decide. A shared service can improve consistency and reduce deployment cost. It can also multiply one configuration error across an exchange. Its policy, exception rights, cache inputs and change notices should therefore be explicit in the service terms and technical documentation.

Downstream customers complicate attribution. A small network may not operate a validator and may receive only the upstream's effective policy. Its route can be rejected far from the RIR that published the data, with no contractual path to that distant operator. This is where collective institutions can help: standardized notices and interoperable evidence reduce the need for a small holder to negotiate separately with every filtering network.

Commercial autonomy should not become informational impunity. A network may retain the right to reject any route, but if it presents the rejection as RPKI enforcement, it should be able to show which state and policy produced it. That minimum disclosure preserves accurate responsibility without forcing carriage.

A correction is not complete when the ROA changes

The operating chain is asynchronous. A holder can correct a ROA in a portal and still remain unreachable. The new entity must be generated and published. Repository clients must fetch it. Validators must authenticate a coherent current view and alter their payload set. Caches must notify or await router polling. Routers must receive the addition or withdrawal, recompute validation state and reapply policy. Neighbors may need reevaluation if paths were discarded. Traffic must then reconverge.

Each stage can succeed while the end result remains broken. The RIR can show a corrected entity in its repository while one validator is unable to fetch the publication point. A validator can show the right payload while a router is pinned to a failed preferred cache. The router can update state but retain a policy result calculated before the change. One border cluster can recover while another has expired data. A provider can restore import but continue to suppress export to peers.

For that reason, the meaningful service measure is not “time to portal confirmation.” It is time from authenticated correction request to observed restoration across declared checkpoints. The checkpoints do not need to include every network on Earth. They should include the issuer's publication, at least two independent validation views where available, the affected provider's cache and router state, and representative external BGP collectors or customer probes.

RFC 9324 adds an important recovery lesson. If a router discarded Invalid paths and did not retain enough pre-policy state, fresh RPKI data may prompt route refresh requests to neighbors. At scale, this has caused serious load and even de-peering. Keeping affected paths for local reevaluation is therefore not merely a performance improvement; it is part of a correction right. A holder's authorization cannot be repaired promptly if the network has forgotten the route and has no safe way to recover it.

The chain also explains why fixed global deadlines can mislead. Publication frequency, repository health, validator polling, cache timers, router architecture and BGP convergence differ. Governance should specify measurable objectives at controlled stages and report observed end-to-end restoration, rather than promise an impossible universal instant.

A correction receipt should include the old and new entity identifiers, publication time, validator first-seen times, payload change, router first-applied time, route reevaluation method and external observations. This creates a record for post-incident improvement and for any dispute over which institution delayed recovery.

Five failure cases reveal five different accountable actors

Consider first an incorrect ROA created from a holder's authenticated instruction. If the holder entered the wrong origin or maximum length and the registry accurately processed it, the primary correction duty lies with the holder, while the registry still owes usable change controls and warning tools. If the portal transformed a correct instruction incorrectly, responsibility moves toward the service operator. The router that rejects the resulting Invalid route has applied its declared policy; it has not created the bad authorization.

Second, consider a registry certificate or publication error that removes a valid payload. Validators may agree because they are faithfully processing the same upstream state. Their agreement does not absolve the issuer; it locates the cause. Operators still decide whether emergency exceptions are appropriate, but the registry owes rapid restoration, reasons and preserved evidence.

Third, suppose two validators disagree because one has stale repository data or a software defect. The cache operator should isolate the input difference, and the software maintainer should correct a reproducible defect. The network must decide which view to use during disagreement. A simple majority is not enough; two stale instances can outvote one current instance. The decision should consider freshness, trust inputs, entity evidence and failure independence.

Fourth, suppose the cache-to-router connection fails until data expire. RFC 8210 prevents indefinite retention, but it does not choose the network's subsequent routing policy. The cache service is accountable for availability within its commitment. The operator is accountable for redundancy, expiry handling and whether loss of validation fails open or closed. A vendor is accountable if the implementation contradicts configured or standardized behaviour.

Fifth, suppose a correct payload reaches the router but a policy term is ordered incorrectly, applied only to some sessions or inherited from a vendor default. This is an operator configuration failure, perhaps assisted by inadequate vendor diagnostics. The registry cannot repair it. The evidence must include policy version, session scope and route-table result, not merely a screenshot of a Valid payload.

These examples show why one broad “RPKI incident” category is inadequate. The same visible symptom—an unreachable prefix—can arise from authorization, validation, distribution, classification or policy. Incident review should assign the first incorrect state transition and every failed containment or recovery duty. Several actors may be accountable for different parts without responsibility becoming meaningless.

Rights and remedies must be enforceable at the boundary where harm occurs

A governance charter is useful only if an affected party can invoke it. The holder needs an authenticated emergency channel to the certification service, a way to see pending and published changes, and a durable receipt. It needs a reason when authority is removed and a route to challenge mistakes or adverse actions. For routine holder error, self-service correction may be enough. For disputed revocation or legal compulsion, independent review and continuity arrangements become more important.

The operator's customer needs a different remedy. It should be able to ask why a route was rejected and receive an answer tied to the provider's own observation. The provider should disclose the validation state, cache time, covering payload and relevant policy class without exposing unrelated network security details. It should offer a narrowly controlled temporary exception procedure where the commercial and security risk permits, but no customer should assume an unconditional right to force propagation.

The operator also needs rights against its cache or managed validation supplier. Service terms should identify trust anchors, software, update targets, stale-data behaviour, notification, log retention and support during divergence. If a supplier combines validation and routing recommendations, it should separate factual payload changes from its policy advice. The customer must remain able to understand and override the final routing choice.

Router vendors owe implementable control. Operators need commands and telemetry that distinguish validation from action, show cache sessions and ages, retain or recover affected paths safely, and expose why a policy term matched. Defaults should be documented and upgrades should not silently change treatment of Invalid or NotFound routes. A reproducible defect should have a security response and release record.

Remedies should be proportional. Immediate technical correction is usually more valuable than speculative damages. Notice, preserved state, rapid withdrawal or replacement, reevaluation and external verification come first. Financial or contractual remedies may follow when a controlled fault and documented loss remain, but unlimited liability would discourage shared infrastructure and cannot reflect the many independent decisions between certificate and packet.

The enforceable minimum is therefore not a guarantee of universal reachability. It is a right to evidence and timely action from the institution controlling the disputed step. That right converts a diffuse technical dependency into a series of answerable services.

Decision receipts make distributed authority auditable

The RPKI already contains signed entities and carefully specified validation rules. What it often lacks at the operator boundary is a compact record linking those entities to a routing consequence. A decision receipt would not be a new global authorization. It would be an evidence format produced by each actor for its own action.

At the certification layer, the receipt should identify the resource, old and new authorization, request identity, approval method, effective publication time, reason category and any appeal or emergency reference. Sensitive personal details can remain protected while the entity-level change and authority basis are visible.

At the validator layer, it should record software and version, active trust anchors, local modifications, repository snapshot or observation time, validation outcome, payload addition or withdrawal and relevant warning. At the cache-to-router layer, it should add cache identity, protocol version, session identifier, serial, transfer completion and data age. These details turn “my validator says something else” into a reproducible comparison.

At the router layer, the receipt should name the route, peer class, validation state, matched policy term, resulting action, policy version and time. If a route was retained but ineligible, the record should say so. If an exception applied, it should include scope, approver and expiry. For a large provider, records can be generated automatically and disclosed selectively in response to legitimate queries.

External observation completes the chain. RIPE RIS, RouteViews and operator looking glasses can show whether announcements appeared from selected vantage points. They cannot prove what every network accepted, and absence at one collector is not proof of global suppression. Their value is independent temporal evidence: the route was visible here before the change, absent here afterward and restored here at a recorded time.

Receipts should use stable identifiers without pretending serial numbers from different caches are directly comparable. They should preserve raw timestamps and clearly mark inference. A central dashboard may aggregate them, but the underlying evidence should remain attributable to the actor that produced it.

This practice changes incentives. Registries improve change records because downstream effects can be traced. Validators improve diagnostics because differences become reviewable. Operators test policy because they may need to explain a rejection. Holders maintain ROAs because their own instructions remain visible. Accountability emerges from linked evidence rather than from installing a new authority above all entities.

Measurement must respect what can and cannot be observed

Claims about deployment are often weakened by ambiguous denominators. Counting valid ROAs measures authorization publication, not the number of networks rejecting Invalid routes. Counting networks that appear to filter one experimental announcement does not establish their policy for every customer, peer and region. Counting router vendors with an RPKI feature does not show that operators enabled it correctly.

A useful measurement programme separates at least four quantities. First is publication coverage: address space or routed prefixes covered by validated payloads, with explicit treatment of overlapping authorizations and maximum lengths. Second is validator availability and consistency: whether selected independent relying parties derive the same payload set from identified trust inputs. Third is router-policy deployment: whether observed networks appear to reject, de-prefer or propagate controlled Valid, Invalid and NotFound announcements. Fourth is consequence: which prefixes and paths changed during a real authorization event.

RIPE RIS and RouteViews provide broad but sampled BGP visibility through volunteer peers and collectors. Their archives can support before-and-after analysis, but they do not see every bilateral path or internal policy. Active experiments can reveal treatment along tested paths, but route propagation, commercial relationships and path changes can confound attribution. Operator attestations add context but may describe intended rather than actual policy.

The correct response is not to abandon measurement. It is to publish the vantage points, time window, tested route state, confidence and limitations. Repeated observation from diverse collectors can identify trends and incidents without inventing an exact global percentage. The evidence should distinguish “not observed” from “rejected” and “AS-level inference” from “router-level configuration.”

For correction audits, measurement can be narrower and stronger. The relevant provider can expose its cache and policy record; independent validators can show payload convergence; route collectors can show external reappearance; endpoint probes can test reachability. This does not prove universal repair, but it can prove the operating chain for the parties involved.

A Number Resource Society could maintain common measurement definitions and publish reproducible event studies. It should resist rankings based on incomparable denominators. The purpose is to show where authority and implementation diverge, not to award a single virtue score to registries or operators.

A bounded Number Resource Society role can fill the institutional gap

The gap between RIR publication and router action invites either resignation or centralization. Resignation says every network is autonomous, so no common accountability is possible. Centralization says one institution should dictate the treatment of every validation state. Both answers are too easy.

A Number Resource Society can occupy a narrower position. It can define decision-receipt formats, compare registry correction commitments, test validators against identified snapshots, publish cache-to-router recovery exercises and help smaller operators interpret vendor behaviour. It can convene holders, RIRs, transit providers, exchange operators, vendors and researchers around evidence that crosses organizational boundaries.

It can also operate an escalation directory. A holder facing rejection should be able to find the right registry emergency contact, validator maintainer, provider routing desk and exchange service owner. Standardized case fields would prevent repeated translation of prefix, origin, payload and timing evidence. Aggregated cases could reveal recurring maxLength errors, stale-cache patterns or policy-order defects without exposing private customer data.

The Society should not sign replacement ROAs for resources it does not administer, compel carriage, or declare disputed title by institutional preference. It should not turn a voluntary best practice into a hidden global rule. Its legitimacy would come from transparent methods, balanced representation, published limitations and the practical value of faster correction.

Nor should it certify that a network is “RPKI compliant” through a one-time questionnaire. Assurance should be event-based. Can the network show cache age? Does a changed payload trigger safe reevaluation? Can a customer obtain a reasoned rejection notice? Does an exception expire? Can two validators' disagreement be explained? Does the registry's correction become externally visible within the reported interval?

These tests preserve autonomy while making it answerable. RIRs retain certification responsibility. Operators retain routing responsibility. Vendors retain implementation responsibility. The Society supplies common evidence and review where bilateral relationships are too fragmented to do so efficiently.

The positive case for such an institution is strongest for networks with the least bargaining power. Large carriers can build their own telemetry and call registry engineers directly. Small holders and regional providers often cannot. Shared procedures can give them a credible remedy without pretending that they have a right to dictate every remote network's policy.

The governance layer is a map of boundaries, not another switch

The mature view of RPKI deployment begins where promotional diagrams often end. A signed entity reaches a validator; a payload reaches a router; a state reaches a policy; a policy affects a commercial relationship and a packet path. Every arrow is a technical interface and an institutional handoff.

The core rule remains clear. RIRs and resource holders publish authenticated authority statements. Validators determine what follows from the trusted data they can validate. Routers classify routes and execute configured controls. Network operators decide final treatment. Standards deliberately keep automatic policy from being smuggled into classification.

That division should not become a chain of disclaimers. The issuer must answer for issuance and publication. The validator and cache operator must answer for faithful, timely computation and distribution. The vendor must answer for implementation. The network must answer for policy, exception and recovery. Transit and peering services must explain the terms under which shared controls affect others.

Three reforms would make the arrangement governable. First, publish decision receipts that connect entity changes to validator, cache and router state. Second, provide enforceable correction and challenge procedures at every controlled boundary. Third, measure end-to-end events with declared vantage points rather than substituting adoption counts for operational proof.

The result would not eliminate routing incidents or disagreements over authority. It would make them tractable. An affected holder could identify the first incorrect state, the institution able to repair it and the evidence needed to verify recovery. An operator could defend a security decision without pretending that an Invalid label proves motive. A registry could accept responsibility for its own act without becoming an insurer of every routing choice.

The missing governance layer is therefore not missing code. It is missing legibility. The RPKI-to-router architecture already leaves the final choice with autonomous operators. The institutional task from 2018 onward is to ensure that autonomy remains visible, reasoned and reviewable rather than hidden behind a green, grey or red validation state.

Sources

  • RFC 8481: Clarifications to BGP Origin Validation Based on RPKI — Establishes the 2018 rule that validation sets state while operator configuration controls policy. It does not prescribe one preferred treatment for every peer class or incident.
  • RFC 8210: The RPKI to Router Protocol, Version 1 — Defines cache-to-router sessions, serial updates, payload announcements and withdrawals, transport options, and refresh, retry and expiry parameters. It specifies data delivery rather than commercial routing obligations.
  • RFC 6811: BGP Prefix Origin Validation — Defines the Valid, Invalid and NotFound comparison and treats use of the result as local policy. It does not identify motive behind a mismatch.
  • RFC 7115: Origin Validation Operation — Provides deployment and routing-policy guidance, including warnings about traffic shifts, low preference and more-specific routes. Some operational assumptions reflect an earlier adoption stage and should not be read as current deployment counts.
  • RFC 9324: RPKI-Based Policy without Route Refresh — Documents harmful refresh behaviour seen in deployment and recommends retaining affected paths for reevaluation. It does not measure every vendor or network implementation.
  • RFC 8897: Requirements for RPKI Relying Parties — Consolidates requirements for fetching, validating and distributing RPKI data. It is a requirements map, not an audit of current private validator services.
  • RFC 8416: Simplified Local Internet Number Resource Management with the RPKI — Defines local filters and assertions that can support bounded exceptions. Such local state does not alter the global signed view for other operators.
  • RFC 8211: Adverse Actions by a Certification Authority — Analyses how certificate and repository actions can harm holders and how local controls may mitigate effects. It does not adjudicate whether a particular registry action is legally justified.
  • Cisco: BGP RPKI with IOS XR 7 on Cisco 8000 — Shows policy matches, de-preference, best-path treatment and reevaluation choices in one product family. Examples do not establish global operator practice.
  • Cisco IOS XE: BGP Origin AS Validation — Documents cache connections and multiple policy outcomes for validation states. Product commands should not be generalized to other releases without verification.
  • Juniper Networks: Configuring RPKI — Separates state marking from later accept or reject policy and explains placement on customer, peer and transit imports. It is operational guidance rather than an independent measurement study.
  • FRRouting BGP documentation — Demonstrates open-source route-map treatment of Valid, Invalid and NotFound states and cache telemetry. Behaviour depends on release and local configuration.
  • RIPE RIS documentation — Describes a distributed BGP collection platform and its raw data. Collector visibility is sampled and cannot prove every network's treatment.
  • RouteViews API documentation — Describes current and archived views from participating collectors. Absence from a collector is not, by itself, proof that a route was globally rejected.
  • NRS Charter — Supplies normative support for distributed participation and limits on concentrated number-resource power. The assurance, receipt and escalation functions proposed here are recommendations, not evidence of universal current deployment.