Rostelecom's 2020 Route Leak Made Origin Validation Limits an Acc

Summary

Qrator’s monitoring account places the beginning of the incident at approximately 19:28 UTC on 1 April 2020 and describes an observation lasting roughly one hour. That is an attributed external observation window, not a complete internal Rostelecom chronology or proof of an exact start and end at every affected network.[1]
Qrator reported 8,870 affected prefixes belonging to almost 200 autonomous systems. CERT-EU separately summarized more than 8,800 routes from more than 200 networks. The figures describe the scale visible through different reporting perspectives; neither source establishes every data path, every affected user, or the total commercial impact.[1][2]
Qrator observed AS12389 announcements propagating through Rascom AS20764, Cogent AS174 and Level 3 AS3356. This chain shows that the event crossed independently controlled routing domains, but it does not reveal the exact import filters, contracts, validation state or router configuration at any named network.[1]
The routing evidence requires several categories to remain separate: a learned route exported beyond its intended policy scope; an unauthorized origin announcement; a re-originated more-specific prefix; and a route whose authorized origin remains intact even though its path violates an expected business relationship. Those categories interact differently with filtering and RPKI origin validation.[4][17]
A separate RIPE NCC incident occurred in the RPKI control plane. Following a registry-software update, 2,669 Route Origin Authorisations were deleted after some provider-independent assignments were classified as not certifiable. RIPE NCC restored the missing ROAs on 2 April.[3][5]
Contemporaneity did not establish causation. RIPE NCC’s retrospective and an independent Routing Working Group analysis found no direct relationship between the ROA deletion and the Rostelecom routing incident.[4][5]
The measured intersection between the incidents was narrow: three provider-independent resource holders and 12 prefixes. That overlap cannot be extrapolated to all 8,870 prefixes, and the public record does not support describing all affected routes as RPKI Invalid.[4][5]
Route Origin Validation can compare a prefix and its origin ASN against validated ROA data and classify the result as Valid, Invalid or NotFound. It does not validate the complete AS path, determine whether every export respected a commercial relationship, reconstruct a configuration change or establish intent.[13]-[15]
Practical control was distributed. Rostelecom controlled its announcements and export policy; accepting networks controlled their own import, export and validation decisions; prefix holders controlled their records and ROAs; RIPE NCC controlled its certification and ROA-management service; relying parties controlled cache freshness and enforcement; and monitoring providers controlled their observation and alerting systems.
Important facts remain unknown: the initiating internal sequence, the exact division between learned-route leaks and re-originated more-specifics, every accepting network’s RPKI view, the filters applied at each hop, the complete response chronology, the full data-plane effect and whether the incident began accidentally or intentionally.
The accountability finding is therefore operational rather than accusatory. Registry and ROA records supplied evidence about resource and origin authorization, while running configurations, current caches, neighbor policies, monitoring and coordinated recovery determined whether that evidence changed live routing behavior.

The accountability question

The 1 April 2020 incident matters because it exposed a division between recorded authority and running control. The RIPE Database could identify the administrative object associated with AS12389, and RPKI could express some prefix holders’ origin authorizations.[8][10] Neither system independently dictated what every router would accept, prefer or propagate. BGP speakers exchanged UPDATE messages, selected routes under local policy and advertised permitted results to their neighbors.[12] Once unexpected announcements crossed a network boundary, each receiving operator made another locally controlled decision.

That structure rules out a simple explanation in which one registry record, one security mechanism or one organization governed the entire outcome. Qrator’s reported propagation through AS20764, AS174 and AS3356 placed several operational control planes in the observed chain.[1] Rostelecom’s behavior was central because AS12389 appeared in the announcements under examination. The reach of those announcements, however, also depended on which neighbors accepted them, which routes those neighbors exported onward and what downstream networks selected.

This is why the event became a test of origin validation’s limits. If an announcement used an unauthorized origin or an impermissible prefix length covered by a ROA, an operator with fresh validated data and an enforcing policy could potentially classify and reject it as Invalid. If a route retained an authorized origin but was carried over an inappropriate AS path, the same origin check could return Valid. If no covering ROA existed, the result would ordinarily be NotFound, not Invalid. The technical controls therefore had different leverage over different parts of the observed event.

The public evidence supports accountability analysis only if these distinctions survive. Removing the BGP announcements, AS12389 evidence, propagation observations, ROA state, upstream acceptance decisions, monitoring and incident coordination would leave a generic security discussion rather than an explanation of this incident. Conversely, treating every route as the same kind of failure would assign capabilities to RPKI that it was not designed to possess.

Accountability here means identifying who had practical control over a measurable decision and what evidence can demonstrate that decision. It does not mean inferring negligence, criminality, individual fault, a breach, legal liability or an interception motive from external routing observations. CERT-EU said it was unclear whether the event was accidental.[2] The available record does not resolve that uncertainty, so the analysis must not resolve it by assertion.

Forensic timeline

A forensic reconstruction should distinguish directly reported observations from inferences and unresolved internal events. Public route collectors and monitoring platforms reveal selected control-plane views rather than a universal transcript. RIPEstat documentation similarly frames routing data as observation from available sources, with limits imposed by vantage points and data coverage.[9] The following timeline therefore identifies what is reported, what is separate and what remains unknown.

Time	Evidentiary event
Before 19:28 UTC, 1 April	The public record does not identify the initiating Rostelecom configuration change, router, command, employee or internal approval sequence. It also does not establish the precise pre-incident filter and RPKI state at every network that later accepted an announcement.
Approximately 19:28 UTC	Qrator places the beginning of its observation at about 19:28 UTC. It reported AS12389 announcing routes associated with a large set of other networks.[1] This timestamp belongs to Qrator’s monitoring account; it is not proof that every affected router saw its first update at that instant.
During the following propagation	Qrator reported that the announcements propagated through Rascom AS20764, Cogent AS174 and Level 3 AS3356.[1] The observation establishes visible onward propagation through those autonomous systems, but not every session-level decision, route-map evaluation or commercial relationship behind it.
During the roughly one-hour window	Qrator counted 8,870 affected prefixes belonging to almost 200 autonomous systems.[1] CERT-EU later summarized more than 8,800 routes from more than 200 networks.[2] These are attributed measurements, not proof that every route had the same origin-validation state or produced the same data-plane consequence.
During incident response	Qrator said that Rostelecom received a real-time warning and worked with Qrator on troubleshooting and restoration.[1] CERT-EU also recorded cooperation with the reporting firm.[2] The exact Rostelecom escalation, mitigation and rollback sequence is not public.
Approximately one hour after the first observation	Qrator described the event as lasting approximately one hour.[1] The public account supports restoration within that observed interval, but it does not establish which configuration or withdrawal ended each affected route or whether convergence completed simultaneously everywhere.
Contemporaneous RPKI incident	Separately, a RIPE NCC registry-software update caused certain provider-independent assignments to be classified as not certifiable, leading to the deletion of 2,669 ROAs.[3][5] This was a control-plane record-management failure distinct from the AS12389 routing behavior.
2 April	RIPE NCC restored the missing ROAs.[3][5] That restoration belongs to the independent RPKI-service recovery timeline and should not be presented as the mechanism that ended the Rostelecom event.
Subsequent analysis	A Routing Working Group analysis and RIPE NCC’s later retrospective found no direct relationship between the two incidents. They identified an overlap involving three PI holders and 12 prefixes.[4][5]

This chronology contains two simultaneous but analytically separate failure sequences. One appeared in BGP announcements and their acceptance across network boundaries. The other occurred in the production and availability of origin-authorization records. The first depended on live routing policy; the second affected what validated ROA data could be available to relying parties. Their limited intersection makes it legitimate to ask whether the missing records changed the treatment of 12 prefixes. It does not make the ROA deletion a cause of the 8,870-prefix event.

The timeline also separates detection time from trigger time. Qrator’s approximate 19:28 observation is evidence of when the event became visible at its vantage points. It does not identify when an internal change was entered, committed or distributed. Likewise, the approximately one-hour duration describes the external observation. It cannot establish the exact period during which every individual route was present in every routing information base.

The absence of a router-by-router chronology is consequential. Without it, no reliable conclusion can be drawn about the first accepting neighbor, the sequence of policy evaluations, which routes were withdrawn or corrected first, or whether some networks contained parts of the event while others continued to propagate them. A responsible reconstruction preserves these gaps instead of turning a route-monitoring trace into an imagined internal log.

What the observed propagation establishes

The AS path observations establish that unexpected reachability information did not remain confined to one network. BGP is a distributed protocol: an UPDATE accepted by one autonomous system can become input to another system’s decision process and, subject to policy, an advertisement to additional neighbors.[12] The reported AS12389–AS20764–AS174–AS3356 propagation therefore marks a sequence of operational decisions across separate administrative domains.[1]

That sequence does not prove that every named network accepted every one of the 8,870 prefixes or that one identical path reached the entire Internet. Nor does it disclose why a particular import policy accepted a route. An operator could have relied on customer-prefix filters, Internet Routing Registry data, RPKI validation, manually maintained exceptions, broad limits, contractual assumptions or some combination. The frozen evidence does not reveal the April 2020 configuration of any named upstream or peer.

Propagation evidence is nevertheless valuable because it identifies where containment opportunities existed. AS12389 controlled whether it originated or exported the announcements. Each directly connected receiving network controlled whether it accepted them. Every onward advertiser controlled another export decision. Downstream networks controlled route selection and any local validation policy. This is shared control in a precise technical sense: multiple operators possessed independent mechanisms capable of changing at least some routing outcomes.

Shared control must not be converted into shared blame by default. A visible AS path alone does not reveal the terms of a routing relationship, the accuracy of an operator’s prefix inventory, the state of its caches, or whether a route belonged to the learned-leak or re-originated-more-specific portion of the event. It identifies a point of decision, not the legal or moral meaning of that decision.

Four routing categories that must not be collapsed

The word “leak” is often used loosely, but this incident cannot be interpreted accurately without separating four routing conditions. RFC 7908 defines route leaks around the propagation of routing announcements beyond their intended scope, especially where the resulting path violates the expected ordering of customer, provider and peer relationships.[17] That concept is different from origin authorization.

Learned-route policy leak. A network learns a legitimate route from one neighbor and exports it to another neighbor outside the route’s intended policy scope. The prefix holder’s authorized origin can remain at the end of the AS path. The error lies in export scope: the intermediate network acts as transit where policy did not intend it to do so. Because the original origin ASN and prefix length may still match a ROA, ordinary Route Origin Validation can classify the route as Valid even though the path is commercially or operationally inappropriate.
Unauthorized origin announcement. An ASN originates a prefix that the relevant resource holder has not authorized it to originate. If a covering ROA authorizes a different ASN, and a relying party has current validated data, the announcement can be classified as Invalid because of an origin mismatch.[13]-[15] The technical term “origin hijack” is sometimes applied to this condition, but the label alone does not establish malicious intent, traffic interception, criminal conduct or legal ownership.
Re-originated more-specific. An ASN announces a longer prefix inside another network’s aggregate and presents itself as the origin. A covering ROA can render the more-specific Invalid either because the origin ASN differs or because the announced length exceeds the ROA’s maxLength. A more-specific can attract route selection because longest-prefix matching occurs before ordinary BGP path comparison. Even so, the public record does not establish the purpose of each re-origination or the data-plane effect of every prefix.
Valid-origin policy leak. The prefix, origin ASN and length are authorized, but the AS path or export relationship violates intended policy. This is the clearest demonstration of ROV’s boundary. Origin validation answers whether the origin is authorized under the available ROA data. It does not answer whether an intermediate AS was entitled to provide transit, whether the path followed a permitted relationship, or whether the route should have been exported to that neighbor.

The public analyses indicate that the April 2020 observations included a mixture of learned routes and more-specific re-originations.[4] The exact division is unknown. It would therefore be inaccurate to describe all 8,870 routes as unauthorized origins, all as policy leaks with authorized origins, or all as RPKI Invalid. Each description would replace an unresolved distribution with a uniform category unsupported by the evidence.

NotFound must also remain distinct. When no covering validated ROA exists, origin validation ordinarily returns NotFound.[14] That state is common in an incompletely covered routing system. It is not positive evidence that an origin is authorized, but it is also not an Invalid result and does not independently identify misconduct. A network may choose a local policy for NotFound routes, yet the state itself says only that the available validated ROA set supplied no covering authorization against which to test the announcement.

These categories define the reach of potential controls. Origin filters based on an agreed customer-prefix inventory could contain both unauthorized origins and wrongly exported learned routes at a customer boundary. ROV could identify some unauthorized-origin or impermissible-length announcements where suitable ROAs existed. Path-relationship controls could address valid-origin policy leaks. No single category of filter necessarily covers the full mixture.

What RPKI origin validation could establish

RPKI provides a cryptographically supported structure through which address-resource holders can create Route Origin Authorisations. A ROA expresses that a specified ASN is authorized to originate a prefix, subject to a maximum prefix length.[13] A relying party retrieves and validates RPKI material, produces validated ROA payloads and makes that information available to routing systems or policy engines. RIPE NCC operates certification and ROA-management services for resources in its service region, but it does not centrally program every participating network’s routers.[10]

Against a particular validated data set, origin validation can produce three relevant outcomes. A route is Valid when a covering authorization permits the observed origin ASN and prefix length. It is Invalid when covering authorizations exist but none permits the origin and length combination. It is NotFound when no covering authorization is available.[14] These are statements relative to the data held by a relying party at a given time, not timeless global properties embedded in the route itself.

That qualification matters during a record-management incident. Two relying networks could temporarily possess different validated views because their repository synchronization times, cache states, expiry behavior or operational responses differ. RFC 7115 discusses the operational importance of relying-party processing and validated information.[15] The frozen evidence does not reveal the exact cache contents seen by every network during the one-hour Rostelecom observation. A claim that a named operator “saw an Invalid” would therefore require evidence about that operator’s validated data and policy at the relevant moment.

ROV supplies useful origin evidence. If an AS12389 announcement for a covered prefix conflicted with the authorized ASN, or if a more-specific exceeded an applicable maxLength, an enforcing operator could potentially reject it as Invalid. That conditional statement depends on the relevant ROA existing, being correctly expressed, reaching a current relying-party cache, being passed into routing policy and being enforced without an overriding exception. Removing any one of those elements can change the live outcome.

A Valid result proves much less than “safe route.” It does not validate the intermediate AS sequence. It does not certify customer-provider or peer relationships. It does not show that an intermediate network was entitled to export a learned route. It does not establish that the data path reached the intended destination, that traffic was not diverted, or that operational contacts would respond. An authorized origin can appear behind an unintended path.

An Invalid result also has bounded meaning. It shows a conflict with the covering validated authorizations available to that relying party. It can arise from an unauthorized origin, an excessive prefix length, stale operational intent, or an erroneous ROA. It does not, by itself, prove motive, interception or criminal conduct. Operators still require change management, exception handling and investigation to distinguish an attack from a configuration or record error.

NotFound provides the least origin-specific evidence. There is no covering validated authorization in the relying party’s view, so ROV cannot confirm or contradict the origin through a ROA. Treating every NotFound route as hostile would be a separate local policy choice, not an implication of the validation state. It would also risk rejecting ordinary routes for address space without ROA coverage.

The RIPE NCC deletion illustrates this distinction. Deleting 2,669 ROAs could change some routes from Valid or Invalid to NotFound in relying-party views after synchronization, depending on the remaining covering records and cache timing.[3][5] It did not create AS12389 BGP announcements, cause intermediate networks to export them, or alter the complete AS paths. For the Rostelecom event, the documented intersection was only three PI holders and 12 prefixes, and later analysis found no direct relationship between the incidents.[4][5]

Universal ROV therefore cannot be claimed to have prevented this entire incident. It could have constrained the subset involving announcements that were Invalid under available, current ROA data and an enforcing operator policy. It would not inherently reject a learned-route policy leak whose authorized origin remained unchanged. Nor would it validate the complete AS path. That boundary is not a weakness in the evidence; it is the correct description of what the mechanism was designed to answer.

Root Cause

The initiating internal sequence at Rostelecom is unknown. The public sources do not identify a specific configuration change, command, router, employee, review decision or automation failure. They show externally observed AS12389 announcement behavior and onward propagation, not the internal mechanism that generated it. Accordingly, the root cause of the routing incident cannot be reduced to a named action or individual from the available evidence.

At the observable level, the incident began with AS12389 origin or export behavior that introduced unexpected routes into BGP, including evidence interpreted as learned-route leakage and re-originated more-specifics.[1][4] Acceptance and onward export by other networks enlarged the visible scope. This is an event sequence supported by routing observations; it is not a complete root-cause determination.

The RIPE NCC event had a different documented technical sequence. A registry-software update classified some provider-independent assignments as not certifiable and deleted 2,669 ROAs.[3][5] That software and record-management failure altered RPKI data, while the Rostelecom incident altered live BGP announcements. Subsequent analysis found no direct causal relationship between them.[4][5] Combining the two into one root cause would contradict the documented record.

Contributing Conditions

The first contributing condition was BGP’s reliance on local policy at every network boundary. BGP distributes reachability, but operators determine what to accept, prefer and advertise.[12] A route that should have remained within one policy relationship can propagate when successive configurations permit it. The observed passage through AS20764, AS174 and AS3356 demonstrates multiple acceptance and export points, although it does not reveal the specific policy at any one of them.[1]

The second condition was the uneven relevance of origin authorization. Routes with conflicting, covering ROAs could be candidates for ROV rejection. Valid-origin policy leaks would not be. Routes without covering ROAs would be NotFound. The unknown mixture of categories means no defensible analysis can assign one validation remedy to the complete set.

The third was dependence on current operational data. A correctly created ROA has no routing effect unless relying parties retrieve and validate it, caches remain current, routers receive the result and local policy acts on it. The RIPE NCC deletion temporarily affected the record layer; cache synchronization and local enforcement determined when or whether that change affected a network’s decisions.[3][10][15]

The fourth condition was distributed filtering. Customer-prefix filters, maximum-prefix controls, route registries, RPKI validation and export-policy checks can complement one another.[11][16] The public record does not establish which of those controls were present, absent, bypassed or incorrectly scoped at Rostelecom or the propagation networks in April 2020. They are relevant control categories, not findings about undocumented configurations.

The fifth was fragmented visibility. Monitoring providers can see abnormal announcements from selected vantage points and warn operators, but they do not possess every router’s Adj-RIB-In, local routing information base, forwarding table or configuration history. Qrator’s alert provided actionable external evidence.[1] It could not independently reconstruct the initiating internal fault or guarantee that every affected network converged at the same time.

Triggering Event

The immediate trigger inside Rostelecom remains unidentified. It could not responsibly be assigned to a person, command, router, contract or motive from the public evidence. The first defensible external event is the appearance of the relevant AS12389 announcements at Qrator’s observation points at approximately 19:28 UTC.[1]

“Trigger” should not be confused with “condition.” Permissive neighbor policy, incomplete ROA coverage, stale data or limited monitoring may permit an event to spread or delay its containment, but none of those conditions proves what initiated the announcements. Likewise, the separate deletion of ROAs was contemporaneous, not the documented trigger for the AS12389 routing behavior.[4][5]

Detection

Qrator reported detecting the event in real time and warning Rostelecom.[1] Its measurements supplied the approximate start, duration, scale and visible propagation chain that anchor the public reconstruction. CERT-EU later summarized the event and noted both the uncertainty over whether it was accidental and Rostelecom’s cooperation with the reporting firm.[2]

External detection is an important continuity control because an operator’s internal view may not show how neighbors or distant networks receive its routes. Its limitation is equally important: a monitoring alarm proves visibility at the monitoring system’s vantage points. It does not reveal the exact time of the internal trigger, every downstream selection decision or the full data-plane impact. Strong detection therefore combines local session and policy telemetry with independent route observations.

Response

Qrator said Rostelecom worked with it on troubleshooting and restoration after receiving the real-time warning.[1] That supports a finding of incident coordination. It does not disclose the internal escalation chain, the identity of responders, the configuration inspected, the corrective action selected or the exact time at which each step occurred.

The response of the propagation networks is not documented in comparable detail in the frozen record. Their practical options could have included filtering announcements, changing route preference, contacting adjacent networks or waiting for corrected updates, but it would be speculative to claim that a named operator used any particular method. Accountability requires separating available controls from demonstrated actions.

RIPE NCC’s response followed its own timeline. It investigated the missing ROAs, restored them on 2 April and later described improvements to monitoring.[3][5] That response addressed the integrity and availability of RPKI records. It was not the routing-response mechanism by which the AS12389 announcements were corrected.

Recovery

Qrator’s approximately one-hour observation and its account of troubleshooting and restoration support the conclusion that the visible routing event was brought under control within that broad window.[1] They do not identify whether recovery resulted from withdrawals, corrected announcements, export-policy changes, neighbor filtering or a combination. They also do not prove simultaneous convergence at every network.

Operational recovery has at least three layers. The announcement layer requires stopping or correcting the unexpected routes. The propagation layer requires neighbors and downstream networks to process the change. The evidence layer requires monitoring to confirm that the abnormal paths have disappeared across useful vantage points. A declaration based only on a local router may miss residual propagation; a declaration based only on external collectors may miss internal state.

The RPKI-service recovery was separate: RIPE NCC restored the deleted ROAs on 2 April.[3][5] Relying parties then depended on their own synchronization and validation processes to receive the repaired state. Restoration at the repository and convergence at every relying network are related but not identical events.

Allocation of practical control

Accountability becomes clearer when control is allocated by decision rather than by broad institutional label.

Actor	Practical control	Evidentiary limit
Rostelecom / AS12389	Route origination and export policy, neighbor-specific filters, prefix inventories, configuration review, change rollout, monitoring, escalation and rollback	The initiating configuration and internal response sequence are not public
Rascom AS20764, Cogent AS174, Level 3 AS3356 and other propagation networks	Their own import and export filters, relationship policy, prefix limits, ROV use, exceptions, anomaly response and onward advertisements	The April 2020 configurations, cache states and contracts are unknown
Prefix holders	Accuracy of resource records, ROA creation, origin ASN and `maxLength` choices, operational contacts and independent route monitoring	Their individual decisions cannot be inferred uniformly across almost 200 affected autonomous systems
RIPE NCC	Certification and ROA-management systems, software testing, service monitoring, rollback, restoration and incident disclosure within its role	It did not centrally select or enforce the paths used by independently operated routers
Relying-party operators	Repository synchronization, cache freshness, delivery of validation results, local Invalid/NotFound policy, exceptions and final routing decisions	No global observer can infer every relying party’s validation view at every moment
Route-monitoring providers	Vantage-point collection, anomaly analysis, alert delivery, coordination evidence and post-incident reporting	They observe selected routing views and do not control announcements or reconstruct every internal action

This allocation prevents two opposite errors. The first is concentrating all accountability in the originating network and ignoring the independent acceptance decisions that made propagation possible. The second is dispersing control so broadly that no decision has an owner. Rostelecom controlled what AS12389 announced or exported. Each neighbor controlled its own acceptance. Each onward network controlled another propagation decision. The registry operator controlled the availability of origin records. Relying parties controlled whether those records affected routing.

Control over one layer does not imply control over another. A prefix holder can publish a correct ROA but cannot force every network to retrieve or enforce it. RIPE NCC can restore a deleted record but cannot directly withdraw a BGP route from an unrelated operator. A monitoring provider can alert Rostelecom but cannot execute a rollback. An upstream can reject a route at its boundary but cannot repair the originating configuration. Operational continuity emerges from these controls working together.

The allocation also sets a limit on inference. An autonomous system appearing in a reported path is evidence that its network identifier appeared in the observation. It is not, by itself, evidence of an employee’s state of mind, a contractual violation or legal responsibility. Those conclusions would require records beyond the routing evidence considered here.

Root-cause evidence versus contributing evidence

Root-cause evidence would identify the internal mechanism that first produced the unexpected AS12389 behavior: for example, a configuration delta, automation log, commit history, session trace and matching timestamps. None is present in the public record. The external route observations establish the event and its spread, but they do not fill that internal evidentiary gap.

Contributing evidence has a different function. A route accepted and exported by successive networks shows that the live policies along that observed path did not contain it at earlier boundaries. An Invalid announcement visible beyond a validating network could raise questions about data freshness, enforcement or exceptions, but only if that network’s actual RPKI state were known. A Valid-origin leak passing ROV would instead demonstrate that origin authorization was the wrong control for that portion.

Trigger evidence would connect an internal action to the first unexpected updates. Detection evidence would show when monitoring systems identified the anomaly. Response evidence would record contacts, decisions and changes. Recovery evidence would show withdrawal or correction across local and external views. Keeping these evidence classes separate makes a post-incident account testable and prevents a detection timestamp from masquerading as a trigger timestamp.

Measurable remediation

The incident supports layered remediation, but the measures should be expressed as observable controls rather than claims about fault.

First, an originating or transit network can maintain a neighbor-specific route inventory and test both import and export policy before deployment. Useful measurements include the number of prefixes permitted per neighbor, changes from the approved baseline, unexpected origin ASNs, more-specific announcements and routes whose relationship classification changes during a proposed update. A test should distinguish routes originated locally from routes learned elsewhere.

Second, operators can measure containment at external boundaries. Customer and peer sessions can be checked for default-deny behavior, explicit allow-lists, maximum-prefix thresholds and export rules that prevent provider- or peer-learned routes from being sent into another inappropriate relationship. General filtering and validation practices described in operational guidance provide a layered model rather than a single universal check.[11][16]

Third, RPKI operations can be measured end to end. Relevant indicators include repository synchronization age, cache serial progress, validation-feed availability, the count of Valid, Invalid and NotFound routes per session, policy exceptions, and alarms for abrupt changes in ROA coverage. A record existing at the issuing system is insufficient if a stale cache or disconnected policy engine prevents it from influencing live decisions.[10][15]

Fourth, prefix holders can review whether ROAs reflect current origins and whether maxLength is no broader than operationally required. Narrower authorization can make some unauthorized more-specifics Invalid, but an overly restrictive value can also invalidate legitimate traffic-engineering announcements. The correct setting depends on actual routing plans, and later analysis of maxLength and forged-origin subprefix exposure reinforces the need to treat it as a precise operational choice.[20]

Fifth, incident response can be evaluated through time-based measures: time from first abnormal update to internal alarm; time to an external corroborating observation; time to contact the relevant neighbor; time to identify the affected policy; time to stop new propagation; and time to confirm recovery across multiple vantage points. The Qrator account demonstrates the value of real-time warning and coordination without revealing all of those intervals.[1]

A useful post-incident record would preserve the first observed update, the configuration state, route-policy evaluation results, RPKI cache state, operator contacts, corrective change and final external verification. Such evidence would permit a later review to distinguish origin failure, export failure, acceptance failure, stale validation data and delayed coordination. Without it, investigators are forced to infer internal causes from partial global observations.

These measures remain neutral about intent and liability. They ask whether a control existed, whether it operated, whether its output was observed and how quickly the system recovered. That is a stronger accountability method than assuming that a route anomaly necessarily proves malice or that one security technology should have prevented every route category.

Registry evidence and running reality

Registry objects and ROAs are essential evidence. A database record associates administrative information with a network resource, while a ROA expresses a resource holder’s origin authorization.[8][13] Accuracy, uniqueness and current security metadata make those records useful to operators and investigators. They help answer who is recorded for a resource and which ASN has been authorized to originate a prefix.

Records do not operate the Internet by decree. A BGP speaker applies its running policy to received updates. A relying party must obtain current RPKI data. A router must receive validation results. An operator must decide what to reject, prefer or investigate. Export filters must encode intended relationships, and monitoring must reveal when actual propagation diverges from those intentions. Coordinated recovery must then turn evidence into corrective action.

The separate RIPE NCC deletion underscores both sides of this structure. The registry and RPKI service mattered because removing authorizations could alter the origin evidence available to relying parties. Yet the deletion did not centrally rewrite AS paths or force networks to accept AS12389 announcements. Operational continuity depended on record restoration, current caches, local routing policy, active filters and response coordination acting as a chain.

This reality-layer view avoids treating the registry as a sovereign path-enforcement authority. It also avoids dismissing records as irrelevant merely because enforcement is local. ROAs can supply machine-verifiable evidence that makes certain origin conflicts actionable. Their value is greatest when record accuracy, distribution, cache health and operator policy are all measurable.

Later design context, not retroactive requirements

RFC 8212 describes a default-reject posture for external BGP sessions when import or export policy has not been explicitly configured.[18] As design context, that approach reduces the risk that an incompletely specified relationship will exchange routes by default. It is relevant to future configuration discipline, but it is not evidence that every named operator deployed the behavior in April 2020 or that the RFC supplies a retroactive liability standard.

RFC 9234 later specified BGP Roles and the Only-to-Customer mechanism, providing protocol signals intended to help identify and prevent certain route leaks based on relationship structure.[19] That work addresses information ROV does not carry: whether a path’s propagation is consistent with declared roles. It should not be described as an April 2020 requirement, proof of the event’s cause or a mechanism known to have been available on the observed sessions.

RFC 9319 later analyzed operational considerations around RPKI maxLength and forged-origin subprefix exposure.[20] It helps explain how a covering authorization may or may not constrain a more-specific announcement. It does not establish the exact ROA configuration seen for every affected prefix in 2020, and it cannot turn the 8,870-prefix count into an Invalid-route count.

Together, these later documents show why layered design is necessary. Default-reject policy can address missing relationship configuration. BGP Roles and path signals can address some policy-scope leaks. RPKI can address some origin conflicts and prefix-length violations. Monitoring and coordination remain necessary because no one mechanism validates every property of a route.

What this article does not conflate

The 2020 event is distinct from Rostelecom’s 2017 financial-route anomaly. The earlier event involved a different time, affected-route set, duration and attribution question. It is not retold here, and evidence from that episode cannot be used to infer intent, recurring causation or responsibility for the 1 April 2020 incident. This analysis is bounded to the observed AS12389 propagation chain, its approximately one-hour observation and the controls relevant to that specific event.

The article is also distinct from a generic analysis of ROA misconfiguration and common-mode dependency. The RIPE NCC deletion matters here only as a separate contemporaneous incident with a measured overlap of three PI holders and 12 prefixes.[4][5] A broader theory of ROA creation errors would obscure the concrete question: which portions of this mixed routing event could origin validation identify, and which required path-aware policy and boundary filtering?

The distinction preserves the event’s evidentiary center. The 2020 accountability test depends on AS12389 announcements, propagation through AS20764, AS174 and AS3356, differentiated route categories, time-dependent ROA state and independently controlled routing decisions. Without those elements, the analysis becomes either a retelling of another Rostelecom event or an abstract RPKI essay.

Essential uncertainties

The initiating internal fault sequence remains unknown. The exact split between learned-route leaks and re-originated more-specifics remains unknown. The complete set of affected forwarding paths and end-user symptoms remains unknown. The RPKI state visible to every relying party at each moment remains unknown. The import and export filters configured by each propagation network remain unknown.

The full response chronology is also unavailable. Qrator documented real-time warning, cooperation, troubleshooting and restoration, but not every internal decision.[1] The evidence does not establish a responsible individual, intentional interception, a criminal act, a breach, negligence or legal liability. It does not measure an outage at every service whose routes may have appeared in the affected set.

These are not minor caveats. They define the boundary between observed infrastructure behavior and speculation. A precise account can identify control owners and containment opportunities while leaving motive and legal conclusions unresolved.

Conclusion

Rostelecom’s 1 April 2020 incident demonstrated that origin evidence and route-policy evidence answer different questions. Qrator observed a large AS12389 event beginning around 19:28 UTC, lasting approximately one hour and propagating through Rascom, Cogent and Level 3. It counted 8,870 prefixes associated with almost 200 autonomous systems and reported real-time coordination with Rostelecom.[1] Those observations establish scale, propagation and response, but not a complete internal cause.

The simultaneous deletion of 2,669 RIPE NCC ROAs was a separate operational failure. Later analysis found no direct relationship to the Rostelecom leak and measured only three intersecting PI holders and 12 prefixes.[3]-[5] That evidence prohibits both causal conflation and the claim that all affected routes were Invalid.

ROV could have supplied actionable evidence for some unauthorized origins or excessive-length more-specifics where current covering ROAs and enforcing policies existed. It could not validate complete AS paths or reject every valid-origin policy leak. The remaining containment responsibility lay in running import and export policy, relationship-aware filtering, current caches, route monitoring and coordinated recovery.

The accountability lesson is consequently distributed but concrete. Rostelecom owned its announcement and export decisions. Propagation networks owned their boundary decisions. Prefix holders owned the accuracy of their authorizations and contacts. RIPE NCC owned the reliability of its certification and ROA-management service. Relying parties owned data freshness and enforcement. Monitoring providers owned the quality and speed of their observations and alerts. None controlled the whole system, but each controlled an identifiable part of operational continuity.

Rostelecom's 2020 Route Leak Made Origin Validation Limits an Accountability Test