Summary

  • A ROA authorizes an origin AS for a prefix and, optionally, more-specific prefixes down to a maximum length. If the permitted length is shorter than a legitimate BGP announcement, that announcement can become RPKI Invalid even when the origin AS is correct.
  • Invalid is not a universal off switch. Each network decides how to use route-origin-validation results, validators refresh at different times, and less-specific routes may remain. The consequence can still be serious: selective rejection fragments reachability and makes diagnosis depend on external vantage points.
  • A maximum length can fail in the opposite direction as well. A value broader than routing intent can authorize unused more-specifics and increase exposure to forged-origin sub-prefix attacks. The safest ordinary default is an exact authorization for each intended announcement.
  • The 2012 ROA format made the field technically available; later operational research and RFC 9319 made its risks and interface implications much harder to dismiss. A modern portal cannot reasonably present it as an ordinary text entry without consequence-aware controls.
  • Prevention should combine exact-match defaults, prefix-aware input, live route comparison, planned-route declarations, machine-readable previews, two-person approval for high-impact changes and refusal of impossible values. Warnings that can be clicked through without showing affected routes are inadequate.
  • A signed change should be published with an auditable before-and-after record, externally validated, monitored for unexpected Invalid states and reversible through a tested emergency action. Reversal means restoring a known-good authorization, not pretending a distributed cache can be rewound instantly.
  • Responsibility should follow control. The holder is responsible for routing intent and authorized submissions; the portal operator is responsible for safe representation, accurate signing, declared checks and rapid correction of provider-controlled failures; validating networks remain responsible for their local routing policy.
  • Number Resource Society can help by publishing comparative interface tests, emergency-recovery exercises and anonymised incident evidence. Its role should be to make member rights and service duties testable, not to claim that every Invalid route proves registry misconduct.

The character that changes a route's status

Imagine an operator that announces an IPv4 aggregate and several more-specific routes from the same autonomous system. The aggregate is 198.51.100.0/24; the network also announces four /26s for traffic engineering. An administrator creates a Route Origin Authorization for the aggregate and enters the correct origin AS. In the maximum-length field, however, the administrator selects /25 rather than /26.

The ROA is syntactically sound. The signer is authorized for the address block. The origin AS is the intended one. The certificate path validates. Nothing about the signed entity says that the administrator hesitated over the final digit. Yet each /26 route is more specific than the authorization permits. For route-origin validation, the routes are Invalid unless another covering validated payload separately authorizes them.

That last qualification matters. RPKI validation compares a route with all covering validated authorizations, not merely the entity most recently edited. A second exact /26 authorization could preserve Valid status. In a simple account with one covering authorization, however, the difference between 25 and 26 can determine whether remote networks regard the four routes as consistent with the holder's cryptographic statement.

The signature gives the typo institutional force. Before signing, the value is a local input error. After publication, repositories distribute it; relying-party software validates it; routers or route servers receive the resulting payload; network policy may lower preference or reject the route. No cryptographic component is malfunctioning. Each component can perform exactly as designed while carrying a mistaken intention into a reachability problem.

The route does not necessarily vanish everywhere. Some networks do not enforce origin validation. Some may retain older validated data for a period. Some may accept Invalid routes under a local exception. A valid less-specific aggregate can continue to carry traffic, though perhaps through a different path or without the intended traffic engineering. The effect may be regional, provider-specific or intermittent as systems refresh.

That variability can make the incident more expensive rather than less. The network operations centre sees its routes and local sessions. Customers in one transit cone report failure while others connect normally. A status dashboard checks the aggregate and stays green. Engineers investigate DNS, filtering, transport and application layers before discovering that four correct BGP origins conflict with one signed length.

The institutional question begins here. When a predictable one-character mistake can produce externally enforced evidence, what must the interface do before it accepts the value? A portal that merely records the user's click has not completed its public function. It has converted an ambiguous human instruction into a machine-consumable claim with consequences far beyond the screen.

MaxLength is a boundary, not a description of the aggregate

The ROA specifications separate the address prefix from the optional maximum length. The prefix identifies a block within the signer's certified resources. The origin AS identifies who may originate an authorized route. The maximum length defines how far into more-specific prefixes that authorization extends. If it is absent, the authorization ordinarily covers the stated prefix length only.

This sounds elementary, but the interface vocabulary invites a category error. An operator looking at 198.51.100.0/24 may think of /24 as the size of the allocation, /26 as the size commonly announced, and "maximum" as an upper quantity. In prefix notation, a larger number describes a smaller block. A user who thinks in address counts, route aggregates or subnet masks can reverse the practical meaning.

There are therefore two distinct mistakes. A maximum length that is too short excludes intended more-specific announcements. The correct-AS routes become Invalid because their prefixes are longer than the authorization permits. A maximum length that is too long authorizes more-specific announcements the holder may never intend to originate. That does not make the holder's current routes Invalid. It creates unnecessary authorization space that can assist a forged-origin sub-prefix attack in which the legitimate origin AS is appended to a deceptive path.

RFC 9319 calls for minimal ROAs whenever possible: authorize the prefixes actually originated and no others. Its recommendation is not a moral preference for neat records. It follows from the fact that route-origin validation checks the origin, not the truth of every preceding AS in the path. A loose authorization can make an unused sub-prefix look consistent with the named origin even when the announcement was constructed elsewhere.

There are legitimate reasons to authorize a route before it is visible. A DDoS mitigation provider may need to originate a more-specific only during an attack. An operator may have a scheduled migration. Defensive deaggregation may be an emergency option. These cases justify explicit planned authorizations, not a casual maximum that silently covers every intermediate prefix.

The important distinction is between convenience and intention. A maximum length is convenient because one entry can represent many possible routes. But the number of possible more-specifics expands rapidly. An IPv4 /16 with maximum /24 covers the aggregate plus a large set of nested prefixes; an IPv6 range can imply an even larger combinatorial space. The interface need not dramatize that with a misleading global risk score. It should tell the user exactly which current and declared routes are being authorized and which additional route space is included.

This is why "the user chose the wrong value" is not a sufficient post-incident account. The field encodes a non-intuitive boundary with two opposite failure directions. Its safe operation depends on explanatory design, observed routing context and deliberate exceptions. An institution that knows these facts has a duty to represent them at the point of decision.

The standards describe computation; they do not excuse presentation

The principal RPKI architecture and ROA documents were published in 2012. They established a certificate hierarchy tied to Internet number resources and a signed entity through which a holder could authorize an AS to originate prefixes. The standards needed a precise, compact representation. An optional maximum length was a rational way to represent sets of more-specific authorizations.

The standards also made the validation consequence knowable. A route can be covered by a validated authorization yet fail authorization because its origin AS differs or its prefix is more specific than the permitted length. RFC 6907, published in 2013, illustrated the case directly: matching origin, covering prefix, exceeded maximum length, Invalid result. The mechanism was not an obscure interpretation invented after deployment.

Early interfaces and operating practices nevertheless developed in an environment where comparatively few networks rejected Invalid routes. A mistaken authorization might appear in measurement data without producing an obvious outage. That history influenced user expectations. RPKI could be presented as a registration improvement whose mistakes were mostly advisory.

The operating environment changed. More networks began using route-origin validation in routing decisions. Public tools exposed route validity. RIR portals compared authorizations with routes seen by collectors. Operator guidance increasingly warned that an incorrect origin AS or maximum length could cause remote networks to drop a route. The practical cost of a formally valid but semantically wrong entity grew.

RFC 9319, published as a Best Current Practice in 2022, consolidated a decade of concern about loose maximum lengths. It recommended minimal authorizations where possible, discouraged broad use of the field, and devoted a section to user-interface design. Among other points, it called for interfaces to communicate risk, make exact authorization easy and avoid steering users toward loose settings. That is a governance milestone as much as a technical one. It moves preventable misuse from informal operator lore into documented service-design knowledge.

The later ROA profile, RFC 9582, replaced the original entity profile in 2024 while preserving the optional field and pointing readers to the best-current-practice guidance. Technical evolution did not remove the choice; it clarified the responsibility surrounding it.

An RIR can therefore say, correctly, that the standard permits maxLength. It cannot infer that any standards-conforming input form is institutionally adequate. Protocol specifications create interoperable entities. Service institutions decide how people are invited to create them, what evidence appears before confirmation, which defaults are offered and what recovery follows error.

That division of labour is familiar elsewhere. A payment standard permits a valid high-value transfer, but a bank still uses confirmation, beneficiary checks and fraud controls. A certificate format permits many names, but a certificate authority still validates requests. RPKI portals occupy an analogous conversion point between an authenticated person and a globally consumed assertion. Their legitimacy depends on more than encoding the submitted value without alteration.

Invalid is a distributed verdict, not an outage button

Discussions of RPKI errors often jump from "the route became Invalid" to "the Internet dropped it." The shortcut is tempting and wrong. A validated route-origin state is an input to local routing policy. Networks choose whether to reject Invalid routes, lower their preference, tag them, monitor them or apply exceptions. They retrieve and refresh RPKI data on different schedules and through different implementations.

The result is not one global moment of failure. First, a new ROA or replacement entity is signed and published. Publication protocols and repositories make the material available. Relying-party software retrieves and cryptographically validates it. The software derives validated payloads. Routers or route servers receive those payloads through an interface such as RPKI-to-Router. Local policy then changes the treatment of affected BGP routes.

Each stage has timing and state. A validator may retain previous data while a repository is temporarily unavailable. Two validators may refresh minutes apart. A router may maintain a session to one cache and fail over to another. A network may reject Invalid routes only at selected external boundaries. Route collectors provide valuable visibility but do not observe every private peering link, customer session or policy decision.

For the resource holder, the incident can therefore have four layers. The signed authorization is wrong. The externally computed validity state changes. Some networks alter route selection. Users experience a service consequence. Evidence at one layer does not prove every later layer. A screenshot showing Invalid does not establish a global outage; a customer complaint does not by itself identify maxLength as the cause.

This evidentiary discipline should not become an excuse for delay. The holder does not need a worldwide denominator before restoring a known-good authorization. If a newly published value unexpectedly makes intended routes Invalid in independent observation, the rational action is to halt, reverse and investigate. Proof standards for public attribution and compensation can be more demanding than the threshold for emergency mitigation.

Less-specific coverage also complicates consequence. Suppose the four /26s become Invalid while the /24 remains Valid. Networks rejecting the /26s may still reach the addresses through the aggregate. But the path can change. Traffic engineered to a regional provider may follow the aggregate to another site. Capacity may concentrate. DDoS controls may fail to attract the intended range. A service can be technically reachable and operationally degraded.

Conversely, no covering aggregate may exist, or it may be filtered for ordinary prefix-length reasons. Then selective rejection of the more-specific can produce complete unreachability from enforcing networks. The interface cannot know every remote policy, but it can know that an intended route is about to become Invalid. That is enough to display a high-consequence warning and require an explicit resolution.

The user-error defence confuses origin with responsibility

Suppose the audit record establishes that the account administrator entered /25, reviewed a confirmation page and clicked publish. The RIR did not alter the value. The signed entity faithfully contains the request. It is reasonable to call the initiating act user error.

It does not follow that the institution has no responsibility. Responsibility is distributed according to control. The user controls declared routing intent and credentials. The RIR controls the semantics of the form, the default value, the comparison data, the warnings, the signing sequence, the entity history and the emergency support channel. A remote network controls its route policy. Each can discharge or fail its own duty without taking over the duties of the others.

Human-factors engineering starts from the premise that foreseeable mistakes are properties of systems, not surprising moral defects. Prefix length is a particularly strong example. It is compact, easy to mistype, counter-intuitive to non-specialists and capable of changing several routes at once. The portal also often knows the user's resource set and sees observed announcements. It can detect a mismatch that the signer may not notice.

A warning such as "Incorrect information may affect routing" is not proportionate. It tells the user nothing about which route, what state or what alternative. Repeated generic warnings become background decoration. The decisive warning is specific: "This change will leave these four currently observed /26 announcements covered but unauthorized by any other known ROA. Networks rejecting RPKI Invalid routes may not accept them."

The portal must also explain the limits of its observation. A collector may not see a backup route, private interconnection or future announcement. "No conflict observed" is not the same as "safe." A good interface separates current observed routes, user-declared planned routes and additional prefixes implied only by the maximum length.

Blame is especially weak when the provider has chosen a risky default. If the interface automatically sets the maximum to the allocation's longest conventional boundary, or encourages a single broad entry instead of exact routes, it has shaped the error. If it shows a warning but allows publication without requiring the user to inspect affected announcements, it has treated disclosure as absolution.

The relevant institutional test is not whether a user can make a mistake. Users always can. It is whether the service made the intended safe action easy, the dangerous action conspicuous, and the recovery fast. A portal that passes these tests can fairly allocate remaining error to the holder. One that fails them should not hide behind the mathematical correctness of its signature.

Prevention begins with an exact-match default

The ordinary case is simple: authorize exactly what the network intends to originate. When the portal sees a current announcement for a held prefix, its primary action should create an exact authorization for that prefix and origin AS. The maximum length should equal the prefix length and need not appear as a separate value in the signed entity.

This is now reflected in RIPE NCC hosted guidance, which recommends creating authorizations from known announcements and describes a matching maximum as the default. The principle should be common even where interface details differ. Users should not have to understand the full combinatorics of maxLength to choose the safe ordinary action.

Free-form creation still has a place. Routes may be planned rather than visible. Collector data may be incomplete. A holder may need to prepare authorization before a maintenance window or a DDoS event. But the interface should ask which case applies. "Authorize observed route," "authorize planned route" and "authorize a controlled set of more-specifics" are different intentions and deserve different screens.

Prefix input should be structural rather than textual where possible. The portal can validate address-family boundaries, ensure the maximum is not shorter than the prefix, reject lengths beyond /32 or /128, and show the address ranges represented. It should detect pasted whitespace and visually distinguish the prefix length from the maximum length. Accessible design matters: colour alone cannot communicate risk, and screen-reader labels must state the consequence.

For a broad maximum, the portal should calculate the authorization expansion. It can list currently observed routes that become Valid, observed routes that remain Invalid, planned routes declared by the holder, and implied prefixes that are not currently declared. It should avoid a single alarming count when nested prefix sets make that count hard to interpret. A tree view or downloadable list can reveal what the shorthand means.

The default should not become a prohibition. RFC 9319 recognizes exceptional cases, including pre-authorized DDoS mitigation and defensive routing changes. An operator with a legitimate reason should be able to proceed after specifying the operational purpose and expiry or review date. The burden is not to persuade registry staff of its network design. It is to make the exceptional authorization deliberate and reviewable.

Defaults are policy because they distribute attention. A safe default protects a small operator that creates one authorization a year. A capable large operator can override it with evidence and automation. The reverse design - loose by default, expert correction required - places the greatest risk on those least equipped to detect it.

Preview must show consequences, not merely fields

Most confirmation pages repeat the entered values. That guards against some transcription errors, but it does not answer the user's actual question: what will happen to the routes I intend to operate?

A consequence preview should be calculated from at least four inputs. The first is the complete set of validated authorizations currently associated with the holder's resources, because another entity may preserve validity. The second is the current proposed state after the change, not just the new entity in isolation. The third is BGP announcements visible through named observation systems. The fourth is the holder's own planned-route inventory, which may include announcements not yet public.

The preview should classify changes. "Becomes Invalid because maximum length is exceeded" differs from "becomes Invalid because origin AS is not authorized." "Becomes NotFound because the last covering authorization is removed" differs from both. "Remains Valid through another authorization" should identify that authorization. These distinctions accelerate diagnosis and reveal whether a rollback will restore the expected state.

The portal should also show uncertainty. Observed routes are a sample, not a complete global table. A route seen from few collectors may still be important. A route absent from collectors may be planned or private. The interface can state when it last refreshed observations and invite the holder to upload or enter an intended route set. It should never promise that no unobserved route will be affected.

Machine users need the same protection. An API that accepts a valid JSON request but omits preview semantics can reproduce the risk at greater speed. It should offer a dry-run action returning the prospective validated payloads, affected observed routes, warning codes and a deterministic change identifier. High-impact publication should require the client to acknowledge the preview identifier so a stale review cannot approve a changed request.

This design permits automation without pretending automation is infallible. A network controller can compare its intended BGP state with the dry-run result. A change-management system can stop on INVALID_LENGTH. A reviewer can see that a proposed /16 to /24 shorthand authorizes many routes not present in the intent file.

Preview is not prediction of the whole Internet. It cannot tell how every network will route, how long caches will take to refresh or whether an application will fail. Its legitimate claim is narrower and powerful: given the provider's current RPKI state and named route observations, these are the validity changes the signed authorization is expected to create. An institution able to compute that answer should not make users discover it after publication.

High-impact changes deserve friction of the useful kind

Security designers often celebrate low friction. Creating a first exact ROA should indeed be easy. But friction is not uniformly bad. A short pause before replacing an authorization that covers thousands of customer routes can prevent an outage without making routine maintenance burdensome.

The portal can classify change impact without inventing a global risk probability. Relevant facts include the number of current authorizations replaced, the number of observed announcements expected to become Invalid, whether the change affects both address families, whether the resource has customer subdelegations, whether the new value broadens maximum length substantially, and whether the account is using an unfamiliar device or credential.

For a high-impact change, two-person approval should be available and, for designated critical resources, required by the holder's own policy. The second reviewer should receive the consequence preview, not merely a one-time code. Organisations should be able to assign roles: a preparer models the change, a network approver confirms routing intent, and a security approver handles key or credential anomalies.

Time delay can help in non-urgent cases, but it must be configurable and cancellable. A blanket delay would obstruct DDoS response or urgent correction. The better pattern is a scheduled activation window with an immediate abort before publication and an emergency fast path that leaves a stronger audit record.

Portals should support batches atomically at the intention level. If a network needs four exact /26 authorizations to replace one loose /24-26 authorization, publishing deletion before creation can create a transient gap. The service should preview the resulting set, sign the replacements, verify publication and only then withdraw superseded material where protocol and repository constraints permit. Distributed relying parties will still observe states at different times, so "atomic" must not be marketed as instantaneous global convergence.

Credential safeguards also matter. A maxLength error may be accidental, but an attacker with portal access may deliberately narrow or broaden authorizations. Strong authentication, scoped API keys, change notifications, approval separation and revocation of dormant tokens protect the same control surface.

Useful friction is visible, specific and chosen according to consequence. Useless friction consists of generic legal text, repeated checkboxes and support queues that slow correction. The distinction is a governance decision. The former helps the member exercise authority accurately; the latter protects the institution from criticism while leaving the route exposed.

Publication needs a known-good checkpoint

Prevention will not eliminate error. Networks change, observation is incomplete, APIs malfunction and humans approve the wrong preview. Recovery therefore has to be designed before publication.

Every consequential ROA change should create a durable checkpoint: the prior validated payload set, the proposed set, the authenticated requester, approvals, timestamps, observation inputs, warning results and publication identifiers. The holder should be able to download this record. The service should preserve it long enough to investigate delayed reports and demonstrate what was signed.

A rollback control should restore a known-good authorization state through new valid entities and appropriate withdrawal of the mistaken state. It cannot erase an entity already fetched by relying parties, reverse every cache or command remote networks to accept a route. The word "rollback" is shorthand for a forward repair that recreates the prior intended cryptographic result as quickly and safely as the system permits.

The implementation must account for manifests and revocation lists. Simply putting an old file back into a repository is not a safe restoration. The CA should issue current, internally consistent material, publish it, and verify it from an independent relying-party perspective. If a whole hosted CA was affected, the recovery may require more than changing one ROA.

The holder should be able to initiate emergency restoration through both the normal portal and an authenticated out-of-band channel. The latter is essential when the same account compromise or portal fault caused the problem. Identity checks must resist social engineering without requiring a committee meeting while routes fail. Pre-registered emergency contacts, hardware-backed credentials and call-back procedures can make this possible.

Recovery targets should be stated in operational terms. How quickly will the provider acknowledge a suspected authorization error? How quickly can it freeze further changes? When can it publish a known-good replacement under ordinary conditions? Which events require parent-certificate work or security investigation? A promise of "commercially reasonable efforts" is too vague for a control that may influence reachability.

The service should then monitor independent outputs. It should not declare success because its database says the old value was restored. It should confirm repository consistency, successful validation by more than one maintained implementation where feasible, expected validated payloads and improving external route state. It should tell the holder which parts remain uncertain.

A rollback button without these controls can be dangerous theatre. It may replay stale scope after a legitimate resource transfer, overwrite a newer valid change or create a second inconsistency. The right remedy combines speed with a clear checkpoint, authority verification and externally observed completion.

The incident clock starts before customers complain

An institution that waits for a support ticket wastes the best detection signal: it knows a high-impact authorization has just changed. The publication event should start a bounded observation period.

The service can compare expected validated payloads with independently retrieved results. It can query named route collectors for new Invalid states and distinguish maximum-length conflicts from origin-AS conflicts. It can notify the holder through multiple channels when an intended observed route changes state. Where an API client supplied an intent set, it can verify that every declared route remains authorized.

This does not require the RIR to monitor every route forever or guarantee reachability. The duty is strongest immediately after a provider-mediated change, when causation is clearest and reversal is easiest. A fifteen-minute-old authorization that unexpectedly conflicts with current routes deserves different handling from a longstanding Invalid observed without a known recent event.

The alert should carry evidence. It should name the prefix, origin AS, covering authorization, maximum length, first observation time and the portal change that produced the prospective conflict. It should provide safe actions: inspect, restore checkpoint, add an exact authorization if appropriate, or declare that the route observation is stale or unintended.

Users need suppression controls, but suppression must not erase evidence. A network may intentionally leave a route Invalid during decommissioning or testing. It can acknowledge the state with a reason and review date. Permanent silent suppression invites the return of forgotten hazards.

Public incident reporting should be proportionate. A private typo affecting one network does not always justify naming the holder. Aggregate reporting can state how many hosted changes triggered unexpected length conflicts, how quickly they were detected, how many were reversed and which interface improvements followed. Counts should include clear denominators, such as all hosted ROA publication events in the reporting period, rather than percentages drawn from visible routes alone.

Where the provider caused the error - through a form defect, faulty preview, signing bug or publication race - the threshold for a public explanation should be lower. The report should preserve the difference between RPKI validity impact and proven user reachability. It should identify the failed control, the affected period, restoration, remaining uncertainty and corrective action.

Early detection changes accountability. It turns the institution from a passive issuer that waits to be blamed into an operator of a consequential safety system. The cost is monitoring and support capacity. The benefit is that a typo can be corrected while it is still a validity anomaly rather than after it becomes a business crisis.

Remedies should follow the failed control

Not every mistaken maximum length creates a legal claim, and not every route loss is attributable to the portal. A coherent remedy system begins by identifying the first wrongful divergence from authorized intent.

If the holder entered and approved the wrong value despite an accurate, specific preview, the provider's immediate duty is still to help restore service. The holder should bear ordinary responsibility for its instruction and internal approval. If the portal computed the wrong consequence, substituted a value, failed to apply a promised safety rule or could not execute its advertised emergency action, responsibility shifts toward the provider.

Remote networks retain responsibility for their policies. Rejecting Invalid routes is a legitimate security choice, not a wrongful act merely because the underlying ROA was mistaken. A network can nevertheless improve resilience through current validators, controlled exceptions, good telemetry and contacts for customers whose routes are rejected. It should not accept indefinite local overrides that conceal an unresolved authorization error.

Remedies should begin with restoration: freeze the damaging change, publish a corrected entity, verify it, preserve evidence and provide expert assistance. Fee credits may be appropriate when a paid service misses a stated target. For provider-controlled fault causing evidenced direct loss, regional contracts and applicable law should offer a proportionate compensation route rather than total immunity. Unlimited consequential liability would be difficult to price and could weaken useful services.

Independent review is important where the parties disagree about the request or preview. The reviewer should have access to signed entities, audit records, API requests, warning results, repository history and route observations. The question is not whether RPKI is good in general. It is whether the institution and holder performed the duties attached to the particular change.

The review should distinguish a typo from unauthorized access. A credential compromise may produce a validly authenticated request that the account owner never intended. Authentication logs, device signals, approval roles and rapid-report timing matter. The provider should not characterize every signed account action as informed consent.

Finally, a member must be able to challenge systemic interface design through governance, not only individual support. If repeated incidents show that users misread the same field, the remedy is a redesigned control and community review. Quietly correcting each case while preserving the trap externalizes the cost to operators.

Legitimacy comes from matching responsibility to preventable control. The resource holder does not become a ward of the registry. The registry does not become an insurer of the Internet. Each accepts the narrower and more defensible duty created by its place in the operating chain.

Comparative service evidence should test outcomes, not screenshots

RIR interfaces differ, and they change over time. A fair comparison should not freeze one portal in an old screenshot or assume that a feature available to hosted users exists for delegated CAs. It should test a set of observable outcomes.

Can the user create an exact authorization directly from a known announcement? Is a broad maximum discouraged and explained? Does the preview consider all existing covering authorizations? Can the user declare a planned route absent from collectors? Does the API offer the same validation semantics as the web interface? Can the holder configure dual approval and notifications? Is there a documented emergency restore path?

RIPE NCC materials provide concrete examples of route-state explanation, exact creation from observed announcements, API dry information and alerts distinguishing invalid length. ARIN materials describe maximum length in its ROA and API guidance and advise exact matching in best-practice material. APNIC guidance explicitly warns that an incorrect maximum length can make routes Invalid and be rejected by networks using origin validation. These sources establish recognition of the risk, not identical implementation or measured effectiveness.

A comparison must exercise realistic cases. Test one exact route, a legitimate set of more-specifics, a scheduled route not visible to collectors, multiple origin ASes, replacement of a loose authorization with exact entries, an accidental maximum that is too short, and an over-broad maximum. Record what the interface predicts, blocks, permits and publishes.

The test should run only in authorized resources or a designated environment. Its purpose is not to surprise production networks. Where a provider offers a test service, operators should be able to rehearse the change and recovery with the same semantics as production. A test environment that omits critical publication or migration features has limited assurance value and should say so clearly.

Comparisons should be versioned. A poor result is an invitation to repair, not a permanent institutional grade. RIR staff should receive the case, observation time and expected behavior and be able to respond. The public record can then distinguish unresolved defects from corrected ones.

No selected public material provides a complete cross-RIR denominator of maxLength typos, route rejections, customer outages, restoration time or interface-prevented errors. A responsible study must not turn visible Invalid routes into a rate of user mistakes. It can still identify whether a safety control exists and whether a reproducible test passes.

This evidence is more useful than a ranking based on feature count. The question is whether the member can exercise routing authorization accurately and recover from a foreseeable error. An elegant portal that cannot show affected routes is weaker than a plain interface that prevents the wrong state.

Number Resource Society can make prevention a membership issue

Number Resource Society presents itself as an advocate for resource holders, accurate registration, operational stability and constraints on arbitrary institutional power. A maxLength safety programme would give those principles a concrete, measurable application.

NRS could publish an annual RPKI authorization-interface review using the cases above. The review would separate hosted, delegated and hybrid services; web and API controls; prevention, preview, publication, detection and recovery. It would cite current provider materials and preserve test evidence. It would not infer global incident rates from members who volunteer complaints.

It could maintain a member checklist for critical changes: export current entities, list intended BGP routes, obtain a dry-run result, require a second reviewer, schedule monitoring, preserve the checkpoint and test emergency contacts. Small operators could use a simplified version. Larger members could integrate machine-readable checks into their own change procedures.

NRS could also convene confidential recovery exercises with willing RIRs. The exercise would inject a mistaken maximum length into an authorized test setting, measure detection, validate the restore action and document where responsibility changes hands. Common lessons could be published without exposing member topology or credentials.

Where an incident occurs, NRS can help the member assemble evidence: authorization history, intended routes, validator outputs, remote observations, customer reports and provider response times. It can ask whether the applicable service terms provide review and remedy. It should not claim that holding a prefix proves every disputed property right or that every Invalid state is an RIR sanction.

Its positive role is strongest when bounded. NRS is not the parent CA in the scenarios examined here, does not control remote routing policy and cannot guarantee global acceptance of a corrected route. Its public statements are first-party evidence of its aims, not proof that its proposed assurance mechanisms already have institutional recognition.

The membership contribution is to shift the conversation from individual embarrassment to shared service quality. Operators can accept responsibility for accurate intent while collectively demanding interfaces that prevent predictable harm and emergency paths that work. That is not hostility to RIRs. It is how members help essential regional institutions mature with the consequences of their services.

Objections reveal the necessary limits

One objection is that portals cannot know an operator's routing intent. Correct. Collector visibility is incomplete, future routes are unknowable and some more-specifics are announced only during emergencies. The answer is not to abandon preview. It is to distinguish observed, declared and implied routes and to state uncertainty. The holder remains the authority on intent; the portal remains responsible for showing the consequence of the instruction it will sign.

A second objection is that strong warnings will discourage RPKI adoption. Poorly designed warnings might. Exact-match defaults and creation from observed routes reduce burden rather than add it. Friction should increase only when a change creates an observed conflict or unusually broad authorization. Easy safe use and difficult accidental misuse are compatible.

A third objection is that automatic rollback could restore a route authorization after the holder has lost the resource. That risk is real. Recovery must verify current certified scope and use a known-good authorization compatible with present registration state. A one-click historical replay without authority checks would be reckless. Emergency speed does not mean bypassing the parent certificate hierarchy.

A fourth objection is that local route operators, not RIRs, cause rejection. They do make the final policy choice. But the portal produces an input designed to be consumed by precisely those choices. Distributed enforcement limits the provider's control over consequence; it does not eliminate its duty to represent and sign accurately.

A fifth objection is cost. Route comparison, retained checkpoints, dual approval and twenty-four-hour emergency support require investment. The strongest answer is proportionality. Not every account needs every control. High-impact services and designated resources justify stronger safeguards. Shared open standards for preview responses can reduce implementation cost across regions.

A final objection is that exposing all implied more-specifics could overwhelm users. Interfaces should use layered detail: a plain-language consequence, the affected current routes, an expandable prefix tree and a downloadable machine-readable record. Complexity already exists in the authorization. Hiding it does not remove it; it transfers discovery to the incident.

These objections improve the design because they prevent a paternalistic or impossible standard. The portal should not decide routing architecture, promise universal reachability or make every expert exception unavailable. It should make the cryptographic consequence legible, require informed action where danger is foreseeable and support rapid restoration where evidence justifies it.

The governance metric is time to safe intent

Coverage percentages are often used to describe RPKI progress. They matter, but they do not measure whether authorizations remain aligned with intended routing or whether members can recover from mistakes.

For this control surface, a better primary metric is time to safe intent. It begins when a mismatch is created or externally detectable and ends when a current, valid, independently observed authorization matches the holder's verified routing intention. The metric can be split into detection, acknowledgement, authorization, signing, publication, validation and observed route-state intervals.

Providers can publish medians and ranges only where sample size and privacy permit. They should also report the number of changes screened, specific warnings issued, publications cancelled after preview, emergency restorations and provider-caused defects. A prevention event is valuable even though it does not become an outage ticket.

Operators can measure their own discipline: proportion of critical changes with an intent file, second review, dry run, checkpoint and post-publication verification. They can test whether emergency contacts work and whether their monitoring distinguishes invalid length from invalid origin.

External researchers can observe authorization and BGP states but should resist causal overreach. A route may be intentionally Invalid during transition, a collector may miss a valid alternative, and an authorization may prepare for future use. Public measurements are strongest when joined to voluntary holder confirmation or provider incident records.

The governance purpose of measurement is correction. If most risky changes come through an API, improve the API preview. If users misunderstand the direction of prefix length, redesign the language. If restoration stalls on identity checks, pre-register emergency authority. A league table without this feedback is less useful than a small sample that changes a control.

No credible metric can promise that typos disappear. The aim is to reduce how often they become signed, how long they remain distributed and how uncertain recovery feels. That is an attainable institutional standard.

A signature should confirm informed intent

RPKI's strength is that networks can distinguish an origin authorized by a resource holder from one that is not. The system gains that strength by giving signed statements operational consequence. It cannot then treat the quality of the signing interface as incidental.

MaxLength condenses a potentially large set of route authorizations into one field. Set too narrowly, it can make legitimate correct-origin routes Invalid. Set too broadly, it can expose unused more-specifics to a forged-origin technique. The risk has been documented across the life of operational RPKI and is now reflected in standards and regional guidance.

The appropriate institutional response is not to remove every expert option. It is to make exact authorization the default, separate present and planned routes, explain both directions of risk, preview the resulting state, add useful approval friction, preserve a known-good checkpoint, monitor publication and provide a tested emergency restoration path.

Accountability must remain precise. The holder owns its routing intention and the actions of its authorized administrators. The portal operator owns the safety and accuracy of the conversion service it supplies. Relying networks own their policy. Evidence must connect a signed error to actual route treatment and user loss before broad claims are made.

RIRs are well placed to improve this boundary because they already authenticate holders, maintain certified resource scope, operate hosted signing services and observe public routing. Investing in safer interfaces reinforces rather than weakens their legitimacy. It demonstrates that institutional authority grows more careful as reliance grows.

NRS can help turn the expectation into a membership norm through comparative tests, exercises, evidence discipline and collective requests for remedy. Its contribution should remain practical and reciprocal: members accept duties to verify intent; institutions accept duties to prevent foreseeable conversion errors and repair their own failures.

The cost of a typo should not be measured only in dropped packets. It includes the time spent locating a distributed cause, the uncertainty of selective reachability, the absence of a clear remedy and the erosion of confidence when a safety system blames the last person who touched the form. A mature RPKI service reduces each cost before asking the operator to sign.

The cryptographic entity can prove who authorized a value. A legitimate institution must also make it reasonable to believe that the value represented informed intent. That is the difference between a valid signature and trustworthy routing governance.

Sources