RIPE NCC showed why ROA mistakes can become common-mode routing

Summary

RPKI and Route Origin Authorizations are security improvements, not hazards by nature. The accountability issue appears when inaccurate ROA data, narrow maxLength choices, stale records, or weak change control cause legitimate routes to be classified invalid by networks that enforce origin validation.
RIPE NCC should be treated as a registry and RPKI service/documentation surface, not as the controller of every route decision on the internet. Route originators create and manage ROAs; validators and networks decide how validation state affects routing.
A ROA mistake does not automatically create a global outage. Impact depends on which prefixes are affected, how routes are announced, whether validating networks reject invalid routes, how quickly operators detect the problem, and whether rollback paths work.
The common-mode risk is real because many networks can consume the same validation signal. Once automated rejection of invalid routes is deployed, a data error can move from one administrative action into many routing decisions.
A credible accountability record for RPKI operations should include change control, pre-publication validation, maxLength review, route-monitoring alerts, customer notice, rollback evidence, and clear division of responsibility among registries, resource holders, and networks.

Security controls need change control too

RPKI exists because BGP's trust model needs stronger origin evidence. RIPE NCC's RPKI certification page explains the registry context for certifying number resources. The RIPE Database documentation on RPKI and ROAs explains practical Route Origin Authorization management. Those materials support a simple point: routing-security data is operational data. It must be created, reviewed, monitored, and corrected with the same seriousness as router configuration.

A ROA states that a particular autonomous system is authorized to originate a prefix, with a maximum prefix length. RFC 6482, A Profile for Route Origin Authorizations, defines the ROA object. RFC 6480, An Infrastructure to Support Secure Internet Routing, describes the broader RPKI architecture. RFC 6811, BGP Prefix Origin Validation, explains how validation can classify route origins as valid, invalid, or not found. The mechanism is elegant, but operationally sharp.

The sharpness comes from enforcement. If a route is classified invalid and a network rejects invalid routes, reachability may change. That is the intended security benefit when the route is unauthorized or a hijack attempt. It is also the operational risk when the ROA is wrong, stale, or too narrow for the way the resource holder actually announces routes. A security control can block an attack; the same control can block legitimate traffic if its data is wrong.

This does not make RPKI a bad idea. It makes RPKI a production control. A firewall rule, DNSSEC key, identity policy, or certificate can protect users and also break service when mismanaged. ROAs belong in that family. The accountable question is not whether to use RPKI. It is whether the organizations using it have the operational discipline that production controls require.

The phrase "common-mode dependency" describes the risk. Many validating networks can act on the same ROA-derived validation state. If the source data is wrong and enough networks enforce invalid rejection, the mistake may have a broader effect than a single local router configuration error. The control becomes shared infrastructure. That is why change control matters.

MaxLength is small text with large consequences

One of the most important ROA decisions is maxLength. A resource holder may authorize an origin AS for a prefix and specify the most-specific route length that should be considered valid. If the organization later announces a more-specific prefix that falls outside the authorized length, validating networks may classify the route as invalid. The route may be legitimate from the organization's perspective and still fail validation.

This is where paperwork and packet flow meet. A person creating a ROA may think they are making a documentation choice. In fact, they are creating data that other networks may use to decide whether traffic reaches the origin. The choice should be checked against actual announcements, planned traffic engineering, DDoS mitigation practices, customer deaggregation, cloud migration, and emergency failover. A maxLength value that is tidy for policy may be wrong for operations.

ARIN's ROA request documentation and APNIC's Route Origin Authorisation documentation provide useful comparison context across RIRs. They show that ROA management is not a RIPE-only concern. Resource holders across regions need to understand how prefix authorization and maximum length affect route validity. Different registries provide different interfaces and guidance, but the underlying duty travels.

The accountability problem appears when organizational ownership is unclear. Network engineers may understand current route announcements. Registry administrators may have permission to create ROAs. Security teams may push for invalid-route rejection. Customer teams may know about DDoS providers or traffic-engineering needs. If those roles do not coordinate, a ROA can be "correct" in one team's mental model and wrong in production.

A mature ROA change process should compare proposed ROAs against observed BGP announcements before publication. It should flag more-specific announcements that would become invalid. It should account for emergency deaggregation plans. It should require peer review for high-impact prefixes. It should alert on new invalids immediately after publication. It should have a rollback path that can be executed quickly. This is ordinary change-management discipline applied to routing-security data.

Validation state is a signal, not a moral verdict

The words valid and invalid can sound like a moral judgment. In RPKI origin validation, they are technical validation states. A route classified invalid does not necessarily mean the origin AS is malicious. It can mean the route's origin and prefix length do not match the published ROA data. That may indicate an attack, a leak, stale documentation, a mistake, a migration gap, or a planned announcement that was not reflected in RPKI.

RFC 9319, The Use of BGP Origin Validation State in BGP Decision Making, is useful because it addresses how networks should handle validation state operationally. The point is that route validation is part of routing policy. Networks must decide how to treat valid, invalid, and not-found routes in their environment. A simplistic policy may not fit every transition or exception, while a policy that ignores invalids loses security benefit.

This is where accountability spreads. The resource holder controls ROA accuracy. The registry provides the RPKI service and documentation surface. Validators fetch and process RPKI data. Network operators decide whether to reject invalid routes and how to monitor the consequences. Customers experience reachability effects. A bad outcome can involve more than one layer: wrong ROA data, validator behavior, strict rejection, weak monitoring, and slow rollback.

Cloudflare's RPKI explainer and technical RPKI details help translate the mechanism for a broader audience. They also show why provider perspectives matter. Networks deploying validation need to think not only about standards, but about telemetry, rollout, exceptions, and customer impact. Route security is not a checkbox. It is operational behavior.

The accountable public language should therefore be careful. Do not say that RPKI "caused" an outage without specifying what data and policy changed. Do not say that RIPE NCC "broke" reachability simply because a RIPE-managed resource had a ROA issue. Do not say that invalid-route rejection is irresponsible because it can expose misconfiguration. The precise question is which layer had the wrong data or policy, and whether the affected parties had enough monitoring and rollback evidence to recover quickly.

Typography note

Typography is the art and technique of arranging type to make written language legible, readable, and visually appealing. It involves selecting typefaces, point sizes, line lengths, line-spacing, and letter-spacing.

Typography originated with the invention of movable type by Johannes Gutenberg in the 15th century.
Key elements include font selection, kerning, tracking, and leading.
Good typography enhances readability and conveys mood or tone in design.

Adoption increases the reward and the blast radius

MANRS' article RPKI is taking off describes adoption momentum and the incentives for route-origin security. MANRS' network operator actions place RPKI within a broader routing-security framework. This adoption is good. The internet benefits when more networks can reject unauthorized origin announcements. But adoption also increases the importance of data quality because more networks may act on the same signal.

This is the paradox of successful security controls. When a control is optional and ignored, misconfiguration may have limited effect because few systems consume it. When the control becomes widely used, its data quality becomes more important. DNSSEC, certificate authorities, identity federation, and cloud IAM all show versions of this dynamic. RPKI is no different. The more seriously networks treat origin validation, the more seriously resource holders must treat ROA management.

CISA's Securing Internet Routing resource frames routing security as a broader infrastructure issue. Public-sector attention matters because routing incidents can affect essential services, cloud reachability, government portals, and ordinary businesses. RPKI adoption is not only a network-operator preference. It becomes a public-resilience question when invalid-route rejection changes who can reach whom.

The accountability lesson is not to slow adoption. It is to pair adoption with safety. Validators should be reliable. Operators should monitor invalids before rejecting at scale where appropriate. Resource holders should test ROA changes. Registries should provide usable guidance and tooling. Customers should receive notice when route-origin changes may affect them. Community programs should measure both deployment and operational quality.

Adoption metrics alone can mislead. A chart showing more ROAs or more validators is encouraging, but it does not show whether organizations understand maxLength, maintain records during migrations, or monitor invalid announcements. The next maturity question is quality: how many ROAs match real routing practice, how quickly are invalids corrected, how often do changes break reachability, and how well do tools warn operators before publication?

RIPE NCC is a service surface, not the whole control chain

RIPE NCC's role matters because it provides registry and RPKI services for its region, documentation, and community engagement. The RIPE Labs RPKI update gives operational and adoption context. But RIPE NCC is not the autonomous-system operator for every route that references RIPE-region resources, and it does not decide every validating network's routing policy. A public article should preserve that boundary.

The service surface still creates duties. Registry interfaces should make risky choices visible. Documentation should explain maxLength consequences. Tooling should warn when proposed ROAs conflict with observed routes where feasible. Operators should be able to find, update, and revoke ROAs without unnecessary friction. Status and incident communication should be clear when registry-side services have issues. These duties do not make the registry responsible for every downstream route decision; they make it responsible for the usability and reliability of its part of the system.

Resource holders also have duties. They must know who can create ROAs, who approves changes, how route announcements are checked, and how emergency changes are handled. They should not treat RPKI administration as a one-time project. Prefixes move, ASNs change, DDoS providers are added, acquisitions occur, and traffic-engineering practices evolve. ROAs must evolve with the network.

Networks that enforce validation have duties too. They should understand their policy, monitor invalid drops, provide customers with actionable evidence when routes are rejected, and avoid silent failures. If a customer route becomes invalid, the provider should be able to tell the customer which prefix, origin, and ROA state are involved. A vague "routing problem" is not enough when validation data can identify the issue.

This division of duties is the heart of accountability. The registry provides the trusted-data infrastructure. The resource holder publishes authorizations. The validator processes them. The network applies policy. The customer experiences reachability. A failure may require repair at any point in that chain. Blaming only one actor can hide the actual fix.

Monitoring should start before rejection

One safer adoption pattern is to monitor validation state before relying on strict rejection. A network can observe which routes would be invalid, notify customers, fix records, and only then move toward enforcement. This does not mean indefinite delay. It means rollout with feedback. RPKI's security value increases when operators have confidence that invalid routes are truly undesirable and that customers know how to fix exceptions.

Resource holders should also monitor their own prefixes from the outside. They should know when their routes become invalid as seen by validators. They should receive alerts when ROA changes take effect, when observed announcements no longer match authorizations, or when a new provider announces a prefix without matching ROA data. Internal change tickets are not enough because the effect is external.

Rollback matters because RPKI data has distribution and caching behavior. Correcting a bad ROA may not instantly restore every route everywhere. Operators need to understand propagation delays, validator refresh behavior, and provider policies. A change process should include expected time to effect and verification steps. "We fixed the ROA" is not the same as "validating networks are now accepting the route."

Customers need usable language. If their route is rejected because of ROA state, a provider should explain the exact mismatch: prefix, origin AS, maximum length, current announcement, and expected correction. That evidence helps customers fix the record without turning a routing incident into hours of guesswork. It also helps avoid the common support problem where security, network, registry, and provider teams each see only part of the issue.

The strongest monitoring culture treats invalid state as a shared alert. The resource holder sees it. The provider sees it. The registry tooling helps prevent it. The customer support path can explain it. That culture turns RPKI from a brittle security switch into a managed control.

Residual unknowns and the accountable question

The public record does not contain a complete inventory of every ROA mistake, every customer reachability effect, or every validating network's enforcement decision. Some outages may be caused by ROA data; others by local route policy, validator failure, provider filtering, operational delay, or unrelated network conditions. Without route evidence, it is easy to over-attribute harm to RPKI simply because validation is visible.

Those unknowns should produce careful language, not paralysis. The accountable question is who controlled the data and decisions that made a route valid, invalid, accepted, rejected, detected, and restored. The resource holder controlled ROA content. The registry controlled the service and interface. Validators controlled data processing. Networks controlled routing policy. Providers controlled customer communication. Customers controlled change requests and emergency coordination. Each layer should leave evidence.

The repair evidence should be concrete. What changed? Which prefix and ASN were involved? What maxLength was set? Which observed announcement became invalid? Which networks rejected it? When was the issue detected? Who corrected the ROA or announcement? How long did validation state take to recover? Were customers notified? Was the change process updated so the same mistake is harder to repeat?

That evidence protects RPKI's legitimacy. Security controls lose trust when users believe they can break service mysteriously. They gain trust when failures are explainable, fixable, and rare. The goal is not to make route-origin security less strict. It is to make it safer to operate strictly.

The common-mode lesson

The internet benefits when shared signals improve security. RPKI gives networks a way to reduce route hijacks and mistaken origins. The same shared signal can create common-mode dependency when the signal is wrong. That is not an argument against the signal. It is an argument for disciplined stewardship.

The common-mode lesson should shape how operators write procedures. RPKI changes should be peer-reviewed. High-impact prefixes should have extra checks. DDoS mitigation and traffic-engineering plans should be reflected in ROAs before they are needed. Acquisitions and ASN migrations should trigger ROA review. Validation-state monitoring should be part of normal network operations. Customer support should know how to diagnose invalid routes. Public guidance should emphasize both adoption and operational hygiene.

For RIPE NCC and other registries, usability matters. Good security infrastructure should help users avoid dangerous mistakes. Interfaces can show observed route conflicts, explain maxLength, warn about likely invalids, and make rollback clear. Documentation can show examples of emergency deaggregation, multi-origin scenarios, and provider changes. Community engagement can turn incident lessons into better tools.

For networks, rejection policies should be paired with alerting and customer explanation. A provider that drops invalid routes silently may improve global security statistics while creating opaque customer harm. A provider that rejects invalids and provides precise diagnostic evidence strengthens both security and trust.

For customers, the lesson is to treat routing-security records as production assets. A ROA is not a document filed somewhere far from operations. It is a control that may decide whether traffic arrives. The right owner is not merely someone with registry login permission. It is a cross-functional owner who understands routing, security, customer impact, and emergency rollback.

That is why ROA mistakes belong in a Risk and Accountability series. They show how a security improvement becomes an operational dependency. The better the internet gets at using RPKI, the more important it becomes to operate RPKI with evidence, care, and humility.

The entity model should be understood outside the registry team

RPKI has a technical entity model that can look distant from everyday service delivery. The community documentation introduction to RPKI explains the roles of certificates, ROAs, repositories, validators, and relying parties. That structure matters because mistakes can appear when only one specialist group understands it. If registry administrators create ROAs without network-operation context, or network teams change announcements without registry context, the control can drift.

An accountable organization should translate the entity model into plain operational responsibilities. Who owns the certificate authority account or registry portal? Who can create, edit, or delete ROAs? Who approves changes for high-value prefixes? Who checks proposed ROAs against current BGP announcements? Who knows which providers announce the prefix during normal operation? Who knows which more-specific announcements may appear during DDoS mitigation? Who receives alerts when a route becomes invalid?

These questions are mundane, but they prevent the classic control failure where authority and knowledge are separated. The person with permission to publish a ROA may not know all traffic-engineering practices. The person who knows routing may not have registry access. The security team may push for strict validation without understanding a legacy deaggregation plan. The customer-support team may receive tickets from users who cannot reach a service but may not know how to interpret RPKI validity.

The repair is cross-functional ownership. A ROA change should not be a hidden registry action. It should be a network change with a security effect. That means peer review, change tickets, impact assessment, validation checks, rollback plan, and post-change monitoring. The procedure does not need to be slow for every low-risk change, but it needs to recognize when the prefix supports essential services, cloud customers, government portals, financial traffic, or large user populations.

The entity model also helps external communication. If a provider tells a customer that a route is invalid because the ROA authorizes only a shorter prefix, the customer can act. If the provider says only that "RPKI is wrong," the customer may not know whether to edit a ROA, withdraw a route, change origin AS, contact a registry, or wait for validator refresh. Good terminology shortens outages.

Migrations are high-risk moments for ROA drift

ROA mistakes often become more likely during change: network migration, ASN transition, provider change, acquisition, DDoS-provider onboarding, cloud move, traffic-engineering redesign, or emergency failover. The routing plan changes, but the authorization data may lag. A prefix that was valid yesterday may become invalid when announced by a new AS or as a more-specific route. The route may be operationally intentional and cryptographically unauthorized.

Acquisitions are especially risky. A company may inherit prefixes, ASNs, registry accounts, old route objects, unknown customers, and fragmented documentation. The acquiring network may announce routes before every authorization record is updated. Legacy teams may know why a maxLength was chosen, but those teams may leave. If strict validation is common among upstream networks, the integration can become a reachability incident.

DDoS mitigation creates another risk. During an attack, an organization may need to announce more-specific prefixes through a scrubbing provider. If ROAs do not authorize that origin and prefix length, validating networks may reject the mitigation route precisely when the organization needs it. The security control and the defensive emergency control can collide. Planning prevents that collision.

The accountable procedure is to attach ROA review to every network-change category that can alter origin or prefix length. A provider onboarding checklist should include RPKI. A DDoS contract should specify which prefixes and origins will be used and whether ROAs already authorize them. An acquisition checklist should inventory RPKI records. A cloud migration should compare planned routes with ROAs. Emergency playbooks should include pre-approved ROA updates or tested alternatives.

This may feel burdensome, but the burden is smaller than a reachability failure. The purpose of change control is to move the work into a calm moment. If the organization discovers ROA drift only during an outage, every minute becomes expensive. If it discovers drift during planning, the fix is routine.

Customer support is part of routing-security operations

Routing-security failures often surface as customer complaints before they are diagnosed. A customer says a service is unreachable from some networks. A monitoring system shows traffic drop from certain providers. A help desk sees reports that look regional or intermittent. If support teams do not know how route-origin validation failures appear, they may misclassify the issue as hosting, DNS, application, or last-mile connectivity.

Support teams do not need to become BGP experts, but they need escalation cues. If a service is reachable from some networks and not others, if route collectors show invalid state, if a new provider or DDoS service was just added, or if the affected prefix recently changed ROAs, the case should escalate to network operations. The support record should include source networks, traceroutes where useful, timestamps, affected prefixes, and customer impact. Good intake saves engineers from reconstructing basic facts.

Providers that reject invalid routes should also be ready to explain rejections to customers. A customer whose route is dropped because of a ROA mismatch needs precise evidence. The provider should identify the invalid route, the expected authorization, the observed origin, and the validation source. This is similar to email authentication support: telling a customer "your mail failed authentication" is less useful than showing the SPF, DKIM, or DMARC reason. Routing security needs the same customer-facing clarity.

This support dimension is part of accountability because users experience the harm. A route-origin validation issue may be elegant on a diagram, but the customer sees lost reachability, failed transactions, unavailable services, or reputational damage. The faster support can translate symptoms into route evidence, the faster the organization can repair the control.

Support evidence also improves post-incident review. Which customers reported first? Which networks were affected? How long did diagnosis take? Which teams were involved? Did support have the right escalation path? Did the customer receive a clear explanation? These questions show whether RPKI operations are integrated into service operations or isolated in a specialist corner.

Registry interfaces can reduce error, but not replace ownership

Registries and RIRs can make ROA management safer. Interfaces can warn about observed invalids, explain maxLength choices, show current announcements, flag common mistakes, require confirmation for high-impact changes, and make deletion or rollback understandable. Documentation can include migration examples, DDoS-provider examples, multi-origin scenarios, and customer-support diagnostics. Better tools reduce error.

But tooling cannot replace ownership. A registry interface may not know every future emergency announcement. It may not know a customer's private traffic-engineering plan. It may not know which prefix is mission-critical. It may not know whether a more-specific route is temporary, malicious, or planned. Human and organizational context still matters. The resource holder remains responsible for aligning authorization data with real routing policy.

This balance is important for assigning accountability. If a registry interface is confusing or fails to warn about obvious conflicts, the registry should improve it. If a resource holder ignores warnings or publishes ROAs without network review, the resource holder owns that choice. If a validating network drops invalids without customer diagnostics, the network owns that operational opacity. The point is not to find one villain. It is to identify the repairable layer.

The same principle applies across RIRs. APNIC and ARIN documentation show that ROA creation is a global operational task, not a single-region peculiarity. Each region has its own portal, documentation, and community practice, but resource holders with multinational networks may need to manage ROAs across registries. That increases the need for internal standards. A company should not rely on each local team inventing its own RPKI habits.

A strong internal standard would define naming, ownership, review, testing, monitoring, emergency changes, audit frequency, and customer communication. It would identify who can approve broad maxLength values and who can approve narrow values that may reduce flexibility. It would document why each high-impact ROA exists. That record makes later troubleshooting possible.

Route-origin security should be tied to business continuity

Organizations often classify RPKI as network security. It is also business continuity. If a prefix becomes unreachable because of invalid-route rejection, the effect may be failed transactions, unavailable SaaS products, inaccessible government services, broken customer portals, or lost revenue. The business owner may not know the word ROA, but the business depends on the outcome.

This means business-continuity plans should include routing-security dependencies. Which products depend on which prefixes? Which prefixes have ROAs? Which providers enforce invalid rejection? Which DDoS or failover routes are authorized? Which customer-facing services would be affected by a ROA mistake? Which teams must be contacted if reachability drops after a network change?

For critical services, ROA changes should be risk-ranked. A small lab prefix and a production payment prefix should not receive the same review. A prefix used by a public agency or medical system may deserve extra monitoring. A prefix with many downstream customers may need customer-notice planning before major origin changes. Business impact should shape technical control procedure.

The continuity lens also changes testing. A network team may confirm that a route is valid in one validator. A business-continuity test asks whether users in key markets can reach the service through providers that enforce validation. It asks whether monitoring catches the issue from the user side. It asks whether support receives a meaningful alert. It asks whether rollback works within acceptable time. Those tests bridge routing and service.

Security teams should welcome this connection. It prevents RPKI from being seen as a specialist mandate that occasionally breaks things. When business owners understand that accurate ROAs protect reachability from hijacks and mistakes, they are more likely to support the process. When they understand that mismanaged ROAs can break reachability, they are more likely to fund monitoring and ownership.

The adoption story should include negative testing

As RPKI adoption grows, organizations should test not only the happy path but the failure path. What happens if a planned more-specific announcement is not authorized? What happens if a ROA is deleted by mistake? What happens if a validator serves stale data? What happens if a provider begins rejecting invalids more strictly? What happens if a DDoS provider announces a prefix during an emergency and validation fails?

Negative testing turns theory into evidence. A test can reveal that alerts are missing, that support cannot diagnose invalid state, that registry access depends on one employee, or that rollback takes longer than expected. Those findings are valuable precisely because they occur before customers are harmed. RPKI operations should have tabletop and technical exercises just like incident response.

The tests should be carefully designed to avoid disrupting production. Lab prefixes, maintenance windows, simulations, and route-monitoring drills can provide learning without unnecessary risk. The goal is not to create outages for practice. It is to know whether the organization can detect and correct validation problems when they occur.

Community programs can encourage this maturity. MANRS-style adoption messaging is strongest when it pairs "deploy RPKI" with "operate RPKI well." Public guidance can include checklists for change review, monitoring, customer communication, and rollback. Case studies can describe mistakes without turning them into blame theatre. The routing community learns from honest operational detail.

Negative testing also protects confidence. If an organization knows it can recover from a ROA mistake quickly, it can deploy validation more confidently. If it has never tested the failure path, strict enforcement may feel risky. Good operations make strong security easier to adopt.

The final accountable question is evidence of alignment

The real question after a ROA-related reachability event is whether authorization data, routing practice, and validation policy were aligned. If they were not, why not? Was the ROA stale? Was maxLength too narrow? Did a network announce from the wrong origin? Did a provider enforce invalid rejection without notice? Did a validator behave unexpectedly? Did monitoring miss the issue? Did rollback lag? Each answer leads to a different corrective action.

Evidence of alignment should be routine. A resource holder should be able to show current prefixes, origins, maxLength values, observed routes, providers, and validation state. A network should be able to show how it handles invalids and how customers are informed. A registry should be able to show service status and clear guidance. A customer-facing service should be able to map business impact to route-origin controls. These are not exotic artifacts. They are the operating record of a security control that now affects reachability.

The public debate sometimes treats security and availability as competing values. RPKI shows that they are intertwined. Better origin validation protects availability against hijacks and leaks. Poorly operated authorization data can harm availability through mistaken invalids. The answer is not to choose one value. It is to operate the control so both values improve.

That is the accountability standard for RIPE NCC, other registries, resource holders, validators, networks, and customers. Each party should know its layer, produce evidence for its layer, and cooperate when a validation signal creates reachability risk. Shared security infrastructure deserves shared discipline.

The better RPKI becomes, the less forgiving weak operations will be. That is a healthy pressure if organizations respond with review, monitoring, and transparent repair. Route-origin security should make the internet harder to hijack and easier to explain when mistakes occur, especially under public service pressure and scrutiny.

Typography

Typography originated with the invention of movable type by Johannes Gutenberg in the 15th century.
Key elements include font selection, kerning, tracking, and leading.
Good typography enhances readability and conveys mood or tone in design.