Rostelecom's 2017 Financial-Route Leak Made Attribution Evidence an Accountability Test

Summary

• BGPMon placed the AS12389 event between 22:36 and approximately 22:43 UTC on April 26, 2017. It counted 50 affected prefixes across 37 autonomous systems. ThousandEyes used a different frame: it observed 137 AS12389-originated prefixes during the window, treated roughly 100 as ordinary or associated with Russian organisations, and identified 36 outside-company prefixes. Those denominators describe different selections and should not be merged. [1][2]
• The direct infrastructure mechanism was false route origination and propagation. Some announcements were more-specific routes. BGPMon highlighted 203.112.90.0/24 against a normally announced /23, a distinction that helps explain why ordinary route selection could prefer the false route without any compromise of the affected service itself. [2]
• ThousandEyes observed peers including Cogent, Hurricane Electric and Tata accepting and propagating AS12389 announcements. Its path measurements showed traffic for at least one affected e-commerce service entering Rostelecom and later reaching the intended destination. That supports diversion of some production traffic, not a claim that every route, user or packet was diverted. [1]
• Financial, payment, e-commerce, web-security and certificate-related services were represented among the affected prefixes. Named examples in the reporting included Mastercard, Visa, BNP Paribas, HSBC, Symantec and GeoTrust. The routing evidence does not show that those organisations' internal systems were compromised. [1][2]
• The confirmed evidence consists of AS12389 origin observations, the short event window, some more-specific announcements, propagation by multiple peers and measured path changes. A routing or configuration failure is a plausible explanation. Deliberate targeting and interception remain disputed. Actor identity, the internal trigger, packet inspection, decrypted content, transaction effects, loss and durable remediation remain unknown.
• The concentration of financial and security-related destinations made the pattern suspicious to BGPMon and ThousandEyes. BGPMon also observed announcements involving other Rostelecom-related autonomous systems, which supports an accidental internal failure as a competing hypothesis. Neither monitoring organisation had the operator's internal change, authentication or configuration records. [1][2]
• Accountability follows practical control, not an unsupported conclusion about motive. Rostelecom controlled route creation and export inside AS12389. Accepting peers controlled filters, validation, route acceptance and propagation. Prefix holders controlled authorisation data, external monitoring and escalation. Independent monitors controlled the quality and preservation of outside observations.
• RPKI can help a network evaluate whether an origin is authorised by a matching Route Origin Authorization, but it does not prove intent or the internal mechanism. The event also predates broad Route Origin Validation enforcement. The historical ROA state of each affected prefix and each peer's validation policy would have to be established before claiming that RPKI would have blocked a particular route. [11]-[14][18]
• The supported harm is a temporary loss of intended routing control and exposure of some traffic to an unauthorised transit path. The record does not establish transaction fraud, stolen credentials, TLS compromise, altered data, a full outage, a quantified affected population or financial damage. Encryption may reduce content exposure, but the available evidence does not establish which sessions used effective encryption.
• A decisive account would require records that public routing observations cannot supply: AS12389 change and authentication logs, a root-cause report, peer filter and route-selection logs, reproducible archive analysis, historical ROA state, service-side traffic and TLS records, packet captures, customer incident records, and evidence about whether the measured paths carried production traffic.

Seven minutes created a durable evidence problem

The event was short, but its evidentiary structure remains important. BGPMon placed the start at 22:36 UTC and the end at about 22:43 UTC on April 26, 2017. During that interval, route collectors and monitoring systems saw AS12389 announce reachability for address space associated with other autonomous systems. Multiple outside networks accepted at least some of those announcements and propagated them. ThousandEyes also measured changed end-to-end paths rather than relying only on control-plane updates. [1][2]

Those observations establish more than a vague routing anomaly. They identify an origin autonomous system, a time window, announced prefixes, propagation and a path consequence. Distributed routing data can therefore support a strong conclusion about what the Internet was told: AS12389 represented itself as an origin for routes that were not part of its ordinary authorised set, including address space used by organisations outside Rostelecom.

The same observations establish less than many descriptions imply. A BGP update does not contain an operator's motive. A changed path does not reveal who entered a command, which system generated it, whether an account was misused, or whether a planned configuration escaped its intended scope. Even a suspicious set of destinations does not disclose the internal decision that produced the set.

The distinction matters because the words used to describe a routing incident can silently import a conclusion. "Leak" can describe the propagation of routes that should not have been exported. "Hijack" can describe false origination or a route that diverts traffic, but it is often heard as proof of hostile intent. The observable record supports false origin announcements and traffic diversion. It does not by itself establish deliberate seizure, espionage or a plan to target financial institutions.

Later assessments by CERT-EU and ENISA placed the event in broader discussions of BGP hijacking and routing-security risk. Those descriptions are useful as attributed institutional assessments. They do not substitute for undisclosed AS12389 logs, peer policy records or service-side traffic evidence. [4]-[6]

The appropriate accountability test starts with that asymmetry. Public routing evidence can be independently observed and reproduced. Internal cause and purpose depend largely on records controlled by the originating operator and other participating networks. The stronger the outside evidence of a routing change, the more specific the unanswered internal questions become. Yet the outside evidence should not be stretched into answers it cannot provide.

That is why a seven-minute event can remain unresolved years later. Withdrawal ended the immediate routing condition. It did not close the evidence gap. Operational recovery and public explanation are separate duties: one restores routing, while the other shows how the failure arose, what traffic was exposed, why controls did not contain it, and what changed afterward.

The two prefix counts answer different questions

BGPMon counted 50 affected prefixes across 37 autonomous systems. ThousandEyes reported that AS12389 originated 137 prefixes during the relevant window, then separated roughly 100 that appeared ordinary or associated with Russian organisations from 36 prefixes belonging to outside organisations. [1][2]

The figures are close enough to tempt a single headline number and different enough to make that move unreliable. BGPMon's 50-prefix count concerns its affected set across 37 autonomous systems. ThousandEyes began with all 137 observed AS12389-originated prefixes and then classified them to isolate 36 outside-company prefixes. Each organisation used its own observations and selection method. The public record supplied here does not define a conversion that turns one denominator into the other.

This is not a minor statistical detail. Counts are part of the causal claim. A figure for all announcements seen from an autonomous system is not the same as a figure for suspected false origins. A figure for prefixes is not a figure for victim organisations, services, users, sessions or packets. A figure for autonomous systems is not a figure for legal entities. Combining these units can turn a bounded route anomaly into an unsupported population estimate.

The responsible formulation preserves both measurements and names what they measure. BGPMon observed 50 affected prefixes across 37 autonomous systems. ThousandEyes observed 137 AS12389-originated prefixes, treated about 100 as likely ordinary or Russian-associated, and identified 36 outside-company prefixes. The difference may reflect vantage points, timing, classification and counting choices, but those explanations remain possibilities unless a reproducible comparison demonstrates them.

Historical reconstruction can improve that position. The peer-reviewed work by Moriano and co-authors used historical BGPStream data, while CAIDA describes BGPStream's access to archived Route Views and RIPE RIS material. Those sources make reproducible reanalysis possible in principle. They do not erase the need to document collector coverage, time boundaries, prefix filters and classification rules. [7][8]

Count discipline is an accountability control because it limits overstatement. An operator response, an outside monitor and an institutional assessment should all disclose their denominator. If their numbers differ, the task is to reconcile methods or preserve the difference, not choose whichever number makes the event look largest or smallest.

More-specific routes explain why ordinary selection could divert traffic

BGP is the inter-domain system through which networks exchange claims about reachability to IP address blocks. The event's crucial mechanism was not merely that AS12389 appeared somewhere in an unexpected path. It was observed as the origin of routes for address space associated with other autonomous systems. Some of those routes were more specific than the covering routes normally used for the same address space. [1][2]

BGPMon highlighted 203.112.90.0/24, while the normal announcement covered a /23. A /24 describes a smaller address block than a /23. Routers commonly prefer the more-specific route for traffic whose destination falls inside that smaller block. That preference occurs before many other best-path comparisons. The false /24 could therefore attract traffic even if the legitimate /23 remained visible.

This mechanism is important for attribution discipline. A diverted path does not require proof that a remote bank, payment service or certificate-related provider was breached. The route-selection system can send traffic toward the false origin because the network received and preferred a more-specific reachability claim. The affected organisation may continue operating its own systems normally while some users reach those systems through an unintended transit path.

The more-specific observation also distinguishes the event from a loose claim that AS12389 simply redistributed a route with a longer or unusual path. RFC 7908 supplies a route-leak classification framework, and RFC 7454 provides operational security and filtering guidance. Those standards help operators describe route-policy failures and controls. They do not determine, from the public evidence alone, which internal action generated the April 2017 announcements or whether the action was intentional. [9][10]

An accountability analysis should separate creation, export, acceptance and selection. First, a route was created or introduced inside AS12389. Second, AS12389 exported it to neighbours. Third, some neighbours accepted and propagated it. Fourth, downstream routers selected it according to their local information and policy. Fifth, at least some measured traffic followed the resulting path.

Each step has a different evidence owner. Route-generation and authentication records would sit closest to the origin. Export policy and session logs would show what AS12389 sent to which neighbour. Peer records would show acceptance, filtering and local selection. Collector archives would show what reached outside vantage points. Active measurements would show end-to-end path effects. Service operators would hold traffic and application evidence.

That chain prevents a simplistic assignment of all responsibility to one place. AS12389 was the observed false origin and controlled the first export. Peers did not create the route, but acceptance and propagation widened its reach. Prefix holders did not cause the announcement, but their authorisation and monitoring posture could affect detection and rejection. No single entity controlled the whole Internet, yet several controlled specific points where the event could have been prevented, limited or explained.

Path measurements prove diversion, not interception intent

Control-plane observations show what routes were announced. Path measurements add evidence about where traffic travelled. ThousandEyes reported that some peers, including Cogent, Hurricane Electric and Tata, accepted and propagated the AS12389 announcements. Its measurements for at least one affected e-commerce service indicated that traffic entered Rostelecom's network and later continued to the intended destination. [1]

That path shape matters. It supports more than a theoretical risk that a false route might attract traffic. It indicates that measured production traffic followed an unauthorised transit path. The path did not simply terminate at AS12389 in the cited example; traffic later reached the intended destination. This is consistent with diversion followed by onward delivery.

The measurement does not support a universal statement. Not every network accepted or preferred the route. ThousandEyes noted that acceptance varied. A path seen from one or more measurement vantage points cannot be expanded into a claim about all users, all source networks or all packets. Routing decisions vary by location, provider, timing and policy.

Nor does onward delivery prove interception. Traffic passing through an unintended network creates an opportunity for observation or interference, but opportunity is not evidence that inspection occurred. The available path data does not show packet capture, content access, modification, credential collection or transaction manipulation. It does not identify an interception system or an operator who used one.

Encryption further complicates harm assessment. Effective encryption can limit what an unintended transit network can read or change, but the public routing record does not establish the security state of each affected session. The presence of financial and certificate-related services does not prove that encryption failed. It also does not prove that every connection was protected correctly. Service-side TLS records, session telemetry and packet evidence would be required for a more specific conclusion.

The safest supported harm is therefore a loss of intended path control and temporary exposure of some traffic to an unauthorised transit path. That is a real network-security consequence even without proof of content compromise. Users and service operators rely on inter-domain routing to deliver traffic through expected reachability relationships. A false origin can break that control boundary while leaving application servers and encrypted sessions intact.

This distinction protects both accountability and accuracy. Minimising the event because no data theft has been proved ignores the demonstrated route diversion. Calling the event interception because traffic crossed Rostelecom treats a possible capability as a completed act. The evidence supports the middle position: diversion occurred for measured traffic; inspection, decryption, alteration and exploitation remain unknown.

Four evidence classes keep attribution honest

The event is best understood through four evidence classes: confirmed, probable, disputed and unknown. Mixing those classes is the main route from a technical observation to an unsupported accusation.

Confirmed evidence includes the AS12389 origin observations, the 22:36 to approximately 22:43 UTC window, false announcements, some more-specifics, propagation by multiple peers and measured path changes. The named service categories and examples are also supported when tied to the monitoring reports. These conclusions depend on distributed observations rather than access to Rostelecom's private systems. [1][2]

Probable explanations should remain conditional. An internal routing or configuration failure is a plausible root-cause candidate. BGPMon observed simultaneous announcements involving other Rostelecom-related autonomous systems, a pattern that can support the hypothesis of a broader internal mistake rather than a carefully limited external target set. The evidence does not establish the exact configuration, command or system that failed.

Disputed interpretations concern deliberate targeting and interception intent. The concentration of financial, payment, e-commerce and security-related destinations, combined with newly introduced more-specific routes, made the pattern look suspicious to BGPMon and ThousandEyes. Suspicion is relevant because it shapes incident response and evidence preservation. It is not a finding of purpose.

Unknowns include who initiated the change, whether that person was authorised, the exact internal mechanism, the reason for the selected prefixes, whether packets were inspected, whether any content was decrypted, whether transactions were affected, whether users lost data or money, the complete affected population under a common measurement method, and what durable remediation occurred.

CERT-EU and ENISA later used stronger threat-oriented framing in their institutional discussions. Those assessments deserve accurate attribution because public bodies use past incidents to explain routing risk. Their framing does not create access to AS12389 change logs or affected-service packet records. A later, categorical label should not be treated as new primary evidence about an operator's 2017 intent. [4]-[6]

The Internet Society's routing-security year review places the episode within a much larger pattern of routing incidents and prevention concerns. That context helps show why the case matters beyond one operator. It should not flatten the event into a generic statistic or answer its unresolved attribution questions. [3]

An evidence ladder clarifies what would justify stronger language. Distributed route updates can establish false origination. Multi-vantage propagation data can establish reach. Active path measurements can establish diversion from particular vantage points. Service logs can establish received connections, TLS state and application effects. Packet captures can establish traffic content and modification within their scope. Operator change and authentication logs can identify internal action. A root-cause investigation can connect those records to responsibility and intent.

The April 2017 public record reaches the first three levels for parts of the event. It does not reach the later levels. That boundary permits firm operational accountability without assigning an unsupported motive. Rostelecom can be held responsible for explaining routes originated and exported by AS12389 even when deliberate targeting is unproved. Peers can be asked to explain acceptance and propagation even when they did not create the routes. Prefix holders can be asked about authorisation and monitoring without implying that they caused the incident.

Attribution evidence should also be symmetric. Evidence that supports a hostile hypothesis should be preserved, including target concentration and more-specific announcements. Evidence that supports an accidental-failure hypothesis should also be preserved, including announcements involving related autonomous systems. A credible account explains why one hypothesis ultimately fits better or states that the available record cannot decide between them.

That discipline is not indecision. It assigns clear responsibility for observable actions while refusing to invent the mental state behind them. In routing incidents, that is often the difference between accountable analysis and geopolitical storytelling.

AS12389 controlled the most probative internal evidence

Rostelecom, as the operator of AS12389, controlled the system that public observers saw originating and exporting the routes. That does not prove that senior management directed the event or that an individual acted intentionally. It does identify the organisation closest to the route-generation process and the evidence most capable of explaining it.

The relevant controls begin before export. Route-generation permissions determine which accounts, systems and workflows can introduce a prefix into the routing process. Change review can require a second check on sensitive or unusually broad modifications. Prefix allowlists can constrain customer and infrastructure announcements to expected address space. Egress policy can stop a route that should not leave the autonomous system. Monitoring can detect an unexpected origin or a sudden set of more-specific announcements. Withdrawal procedures can shorten exposure after detection.

These are control categories, not claims about the exact AS12389 configuration in April 2017. The public record does not disclose which controls existed, which failed, or which were bypassed. It also does not disclose whether the route set came from a manual command, automation, a customer session, an internal redistribution error, compromised credentials or another mechanism.

The operator's evidence should connect the categories. Configuration history could show what changed. Authentication records could show which account or system made the change. Approval records could show whether it was authorised. BGP session and export logs could show which routes were sent to which neighbours. Alert records could show when staff first knew. Incident records could show who ordered withdrawal and how the affected set was determined.

Speed alone is not enough. The announcements were withdrawn after a short window, but a seven-minute duration does not reveal whether monitoring worked, a peer raised an alarm, an operator noticed a mistake, or the originating condition ended automatically. A fast end reduces exposure; it does not explain detection or control effectiveness.

Disclosure is the final origin-operator checkpoint. A useful public incident account would distinguish observed route facts from the operator's root-cause finding. It would state the affected export scope, explain whether the prefixes were introduced by configuration, automation, a customer or another route source, identify the control that failed, describe containment and give bounded remediation evidence. It need not expose credentials, customer-confidential topology or exploitable detail.

Without that account, outside observers can still assign operational responsibility for the origin and export. They cannot reliably assign personal responsibility, intent or internal fault allocation. The evidence asymmetry is itself an accountability fact: the organisation that controlled the route process also controlled the records needed to resolve the most consequential uncertainty.

An operator cannot answer that gap by pointing out that BGP is distributed. Distribution means AS12389 did not control which remote networks accepted the route. It does not erase control over what AS12389 originated and exported. Conversely, locating the false origin at AS12389 does not erase the role of neighbours that propagated it. Practical responsibility follows each checkpoint rather than collapsing the whole chain into a single actor.

Accepting peers controlled the event's propagation boundary

A false origin becomes broadly consequential only when other networks accept and propagate it. ThousandEyes observed Cogent, Hurricane Electric and Tata among the peers carrying AS12389 announcements. That observation does not show the complete policy or decision process inside any named network. It does show that peer acceptance was part of the path from origin to measured diversion. [1]

The peer's accountability question differs from Rostelecom's. An accepting network did not necessarily know that a route was false when it arrived, and it did not create the original claim. It nevertheless controlled local import policy, customer and peer filters, the use of route-authorisation information, anomaly alerting, onward export and emergency coordination.

Filtering responsibilities must be described with evidence rather than assumed from a commercial label. A network may treat a neighbour as a customer, peer or transit provider under its own policy. The public observations do not disclose those contracts or each session's import rules. They also do not show whether a route passed because no filter existed, an allowlist was too broad, registry data was incomplete, a validation signal was unavailable, or local policy accepted a warning.

RFC 7454, NIST SP 800-189 and the MANRS operator materials provide control references for filtering, coordination and resilient route exchange. They support the expectation that networks should know what routes a neighbour may announce, reject implausible advertisements where reliable information permits, monitor anomalies and maintain contact paths for rapid correction. They do not establish that a particular peer violated a specific duty in April 2017. That conclusion would require the peer's historical policy, route-selection and alert records. [10][15]-[17]

Propagation creates a proportional evidence duty. A peer that carried an unexpected more-specific route should be able to show what it received, what validation or filters ran, which local preference selected it, where it exported the route and when it withdrew it. Retained evidence enables a later distinction between an unavoidable limitation in available authorisation data and a controllable policy failure.

The same evidence can prevent unfair blame. A peer may show that no applicable ROA existed, that registry data did not define a sufficiently narrow customer set, that it accepted the route under a documented policy, or that it promptly changed course after an alert. Alternatively, records may show that a known restriction was absent or ignored. Public route observations identify the networks to question; they do not supply the full answer.

Distributed routing therefore produces distributed accountability. AS12389 bears responsibility for the false origin and export. Accepting networks bear responsibility for the controls at their own boundary. Those responsibilities overlap in effect without becoming identical in cause.

Prefix holders and independent monitors controlled different forms of readiness

The organisations whose address space appeared in the affected set did not create AS12389's announcements. Their responsibility concerns preparation, detection, escalation and service-side evidence, not blame for the origin.

Prefix holders can maintain accurate routing and authorisation records, arrange external origin monitoring, define provider escalation contacts and preserve service evidence when an alert occurs. Where operationally suitable, they can consider announcing a mitigating more-specific route through legitimate providers. Any mitigation must be evaluated carefully because route changes made during an incident can create new reachability problems.

Historical context is essential. The event occurred before broad Route Origin Validation enforcement. The available record does not establish which affected prefixes had valid ROAs in April 2017, which maximum lengths those ROAs authorised, or which receiving networks used validation. It would therefore be wrong to treat the absence of universal rejection as proof that each prefix holder neglected RPKI or that each peer ignored an available invalid signal.

Monitoring organisations controlled a different checkpoint: the quality of outside evidence. BGPMon provided a bounded event window, an affected-prefix count, a 37-autonomous-system denominator, a more-specific example and competing hypotheses about intent. ThousandEyes supplied its 137-prefix observation frame, the classification leading to 36 outside-company prefixes, peer propagation observations, affected-service examples and measured paths. [1][2]

Those records are strongest when their vantage points, time boundaries and classification methods remain reproducible. CAIDA's BGPStream data access and the historical reconstruction by Moriano and co-authors illustrate how archived Route Views and RIPE RIS material can support later analysis. A later reconstruction still needs to state which collectors and update intervals were used and how prefixes were grouped. [7][8]

Independent monitors also have a language duty. They can describe suspicious selection and explain why more-specific routes raise concern. They should separately state whether they possess evidence of purpose, internal access or content interception. This separation allows a monitor to warn operators quickly without converting an anomaly score into an attribution verdict.

Affected service operators hold the evidence needed to assess downstream harm. Traffic logs may show connection shifts. TLS records may show whether sessions completed securely. Application and transaction records may show errors, fraud or no material effect. Customer reports may identify geography and duration. None of those records can be reconstructed reliably from route updates alone.

The practical division is clear. Prefix holders control readiness and escalation. Independent monitors control outside observation and analysis. Service operators control evidence of application and customer effects. Each can close a different part of the incident record, and none should claim that another party's evidence is unnecessary.

RPKI can constrain false origins but cannot decide motive

RPKI is central to the control discussion because the event involved a false origin. Its role must be stated narrowly. The RPKI architecture supports cryptographically verifiable statements about Internet number resources. A Route Origin Authorization identifies an autonomous system authorised to originate specified prefixes within the entity's scope. Route Origin Validation lets a receiving network compare a BGP origin announcement with available authorisation data. [11]-[14][18]

That mechanism can give a network useful evidence that an observed origin does not match a covering authorisation. If an affected prefix had an appropriate ROA in April 2017 and a receiving network performed validation, an AS12389 origin could have produced a signal that policy might reject or de-prioritise. The actual result would depend on the historical authorisation, prefix length, validation data and local routing policy.

Several boundaries follow.

First, RPKI does not prove intent. A route can fail origin validation because of a hostile announcement, an operator mistake, stale authorisation, an incorrectly scoped ROA or another mismatch. The signal concerns authorisation of the origin, not the mental state or identity of the person behind the update.

Second, origin validation does not explain the internal trigger. It can identify a conflict at a receiving boundary while leaving unanswered whether the route came from manual configuration, automation, a customer, compromised access or an unintended redistribution path.

Third, RPKI does not by itself validate the complete AS path. An authorised origin statement is not a cryptographic proof that every transit relationship or path segment is legitimate. RFC 7908 route-leak classification and RFC 7454 filtering guidance address broader policy and operational concerns that cannot be reduced to one origin check. [9][10]

Fourth, a retrospective claim requires retrospective data. Present-day RPKI coverage, validation practice or registry guidance cannot be projected backward without evidence. The relevant questions are which affected prefixes had suitable ROAs on April 26, 2017, what prefix lengths they authorised, what validation data each peer received, and how each peer treated the resulting state.

Fifth, a control is only as useful as its operational integration. Authorisation records must be accurate and maintained. Validators and data distribution must be monitored. Route policy must define what happens when a signal is present or absent. Operators need exception, rollback and emergency-contact procedures. MANRS and NIST guidance place filtering, validation, coordination and global routing hygiene within a broader operational practice rather than presenting RPKI as a complete answer. [15]-[17]

These limitations do not weaken the case for route-origin security. They clarify what the control can prove. RPKI can reduce reliance on an unauthenticated origin claim and can help receiving networks make a more informed decision. It cannot determine why AS12389 announced the routes, whether traffic was inspected or who should bear all responsibility.

The April 2017 case is therefore an argument for layered controls. Origin authorisation can constrain acceptance. Prefix filters can constrain what a neighbour exports. More-specific and origin-change monitoring can reduce detection time. Peer coordination can accelerate withdrawal. Active measurement can show path impact. Service logs can assess harm. Operator records can explain cause.

No layer supplies the entire account. The strongest institutional design makes the layers produce evidence that can be reconciled after an event.

Route-security standards create duties of capability, not retroactive verdicts

Standards and best-practice documents are most useful here as control maps. RFC 7908 supplies a vocabulary for route leaks. RFC 7454 addresses operational BGP security and filtering. RFC 6811 and RFC 7115 describe origin validation and its operational use. RFC 6480 and RFC 6482 define the RPKI and ROA foundations. NIST SP 800-189 and MANRS connect filtering, validation, coordination and monitoring to resilient inter-domain operations. RIPE NCC explains BGP Origin Validation and its boundaries. [9]-[18]

Together, they support institutional duties that are measurable without claiming a 2017 legal breach. An origin network should constrain which prefixes it can create and export. A receiving network should maintain proportionate import controls and use reliable authorisation data where available. A prefix holder should maintain accurate records and monitor unexpected origins. Operators should preserve logs and contacts that allow rapid withdrawal and later explanation.

The duties are capabilities, not slogans. "We use RPKI" is incomplete without the historical ROA, validation state and local response. "We filter customers" is incomplete without the permitted prefix set and evidence that the filter ran. "We monitor BGP" is incomplete without alert thresholds, timestamps and escalation. "The route was withdrawn" is incomplete without the detection and decision record.

The documents do not establish that Rostelecom or any named peer failed a specific control during the event. That would require a comparison between the historical requirement, the operator's actual architecture and the incident evidence. Present standards can still define the questions an accountable institution should now be able to answer.

This approach avoids two errors. One is technological fatalism, in which BGP's distributed design becomes a reason no one can be responsible. The other is technological certainty, in which one modern control is declared a guaranteed historical prevention. The evidence supports neither.

Institutional accountability instead asks whether each actor could demonstrate its control at the point it owned. That standard remains valid even when the global system has no central operator and the original motive is unresolved.

Harm should be measured without inventing a breach

The affected set included financial, payment, e-commerce, web-security and certificate-related services. Reports named Mastercard, Visa, BNP Paribas, HSBC, Symantec and GeoTrust among examples associated with the affected prefixes. Those names explain why observers treated the pattern seriously. They do not prove compromise of the organisations or their customers. [1][2]

The confirmed harm is routing harm. Some traffic lost its intended path and crossed an unauthorised transit network. That changed the trust boundary for the affected connections and reduced the prefix holders' control over how users reached their services.

Possible secondary harms require separate evidence. Transaction fraud would require transaction records. Credential theft would require authentication, user or forensic evidence. TLS compromise would require session and certificate evidence. Data alteration would require packet, application or integrity records. An outage would require availability measurements tied to affected users. Financial damage would require loss records and causal analysis.

No such conclusion follows merely from a route passing through AS12389. Onward delivery may allow the service to remain available, and encryption may limit readable content. Neither fact eliminates risk. Neither proves safety for every connection.

Harm reporting should therefore use a layered scale. Route-control loss is established. Exposure to an unintended transit path is established for measured traffic. Content visibility is possible but unproved. Active interception is disputed and unproved. Data compromise, transaction effects and loss are unknown.

This scale gives affected organisations room to report honestly. They can acknowledge a serious network-control event while investigations continue. They can later add service-side findings without rewriting routing observations. If no application harm is found, that result should be reported as evidence within the examined scope, not as proof that the false origin was harmless.

The same discipline applies to public agencies and researchers. Strong threat framing can motivate better controls, but it should not turn categories of possible harm into incident facts. The credibility of routing-security advocacy depends on maintaining that line.

Disclosure should answer control questions even when attribution remains unresolved

An incident report need not identify a hostile actor to be useful. It can state what the operator knows about route creation, export, propagation, detection and withdrawal while marking motive as unresolved.

For AS12389, the minimum useful account would identify the source class of the announcements, the route set and export scope, the detection channel, the withdrawal decision, the affected period and the control changes made afterward. It could explain whether the event involved configuration, automation, customer input or another internal mechanism without exposing sensitive commands or credentials.

Accepting networks could disclose whether the routes were treated as customer, peer or transit announcements; whether prefix, origin or path checks applied; whether historical RPKI data produced a usable signal; and how the routes were removed. Prefix holders could disclose when they were alerted, what providers they contacted and whether service evidence showed measurable customer effects.

The public record supplied by monitors already separates some facts from interpretations. BGPMon and ThousandEyes documented timing, route sets, more-specifics, propagation and path effects, then discussed why the target pattern looked suspicious. BGPMon also preserved evidence supporting an accidental-failure hypothesis. [1][2]

That is the model for accountable uncertainty. A report should not hide suspicious evidence to avoid reputational risk. It should not present suspicion as intent. It should name the records that would decide the issue and state whether those records were examined.

Disclosure also needs a durable remediation test. A statement that routes were withdrawn describes containment. It does not demonstrate that permissions changed, filters narrowed, alerts improved, logs were retained or peer coordination was tested. Remediation evidence should identify the failed control, the change, the test and the monitoring result.

Institutions have different disclosure constraints. Operators may protect security-sensitive and customer-confidential information. Financial and security-service providers may avoid exposing traffic patterns. Peers may treat policies as commercially sensitive. Those constraints justify aggregation and redaction, not an evidence-free conclusion.

The public interest is strongest at the boundary between confirmed operation and alleged purpose. A clear account can say that AS12389 originated false routes, peers propagated some of them and measured traffic changed path. It can also say that deliberate targeting, interception and espionage are not established. That combination is more accountable than either denial through vagueness or accusation through inference.

Evidence that could change the assessment

Several records could materially strengthen, narrow or reverse parts of the current assessment.

AS12389 configuration history could identify the exact route source and change. Authentication and authorisation logs could identify the account or system involved and whether the action followed an approved workflow. Export and BGP-session records could establish which neighbours received which announcements. Alert and incident-response logs could show how the event was detected and why withdrawal occurred.

A Rostelecom root-cause report could connect those records, distinguish error from unauthorised action and document remediation. Its credibility would depend on method, evidence preservation and whether competing hypotheses were examined. A bare assertion of accident or attack would not resolve the attribution question.

Accepting-peer filter, validation and selection logs could show why specific routes passed. Historical policy snapshots could distinguish a missing control from missing authorisation data. Export records could show the propagation boundary, while contact and ticket records could show when peers coordinated withdrawal.

A reproducible reanalysis of archived RIPE RIS and Route Views updates could reconcile the BGPMon and ThousandEyes counting frames or explain why they differ. It could also map propagation across time and vantage points. The analysis would need declared collectors, timestamps, deduplication and prefix-classification methods. [7][8]

Historical ROA records for every affected prefix could show whether origin validation would have produced a useful result at the time. The analysis would need the relevant authorised origin, prefix and maximum-length scope, plus evidence of what validation data each receiving network had and how its local policy responded.

Affected-service traffic, TLS, authentication, application and transaction logs could establish whether diverted connections completed, failed or showed suspicious effects. Packet captures could provide more direct evidence within their limited vantage and retention period. Customer incident and loss records could connect technical effects to people or organisations.

Evidence that the measured path did not carry production traffic would narrow the harm conclusion. Evidence of packet inspection, modification or credential use would expand it. Evidence of a deliberate, authenticated route change tied to a responsible actor would materially change the attribution assessment. Evidence of an internal error and tested corrective control would strengthen the accidental-failure explanation.

Until such records are available, the conclusion should remain bounded. AS12389 announcements and path diversion are confirmed. A routing or configuration failure is plausible. Deliberate targeting, interception and actor identity are unresolved. Data compromise and loss are unproved.

Accountability begins where the evidence is controlled

The April 2017 event is not primarily a story about whether one alarming label defeats another. It is a test of how responsibility is assigned in infrastructure that is distributed by design.

Rostelecom controlled route creation, export policy and the internal records closest to cause. Accepting peers controlled filters, validation, propagation and their own evidence. Prefix holders controlled authorisation data, monitoring and escalation. Independent monitors controlled outside observation and analytical transparency. Affected services controlled evidence of customer and application impact.

No actor controlled the whole path. Each controlled a checkpoint where prevention, limitation, detection or explanation was possible. That is enough for operational accountability even when motive remains unknown.

The event also shows why RPKI must be treated as a bounded control. Origin authorisation can help receiving networks reject or reduce trust in a false origin when the historical data and policy support that result. It cannot identify the person behind the update, prove interception or replace export filtering, peer coordination, path measurement and service-side investigation.

The strongest conclusion is therefore both firm and limited. Public observations prove that AS12389 originated false routes, that multiple peers propagated some announcements and that measured traffic changed path. They do not prove that Russia or Rostelecom intended espionage, that traffic was inspected, or that financial data or money was lost.

Accountability does not require inventing those facts. It requires the operators that controlled the decisive evidence to preserve it, test it and explain what it shows.

Sources

Access checked: 2026-07-25

1. ThousandEyes, event mechanism, path evidence and affected-service surface: https://www.thousandeyes.com/blog/rostelecom-route-leak-targets-ecommerce-services
2. BGPMon, event timing, counts, more-specific example and competing hypotheses: https://www.bgpmon.net/bgpstream-and-the-curious-case-of-as12389/
3. Internet Society, independent routing-security year context: https://www.internetsociety.org/blog/2018/01/14000-incidents-2017-routing-security-year-review/
4. CERT-EU, later institutional incident and harm summary: https://cert.europa.eu/publications/threat-intelligence/threat-memo-190611-1/pdf
5. ENISA, BGP security analysis and control recommendations: https://www.enisa.europa.eu/sites/default/files/publications/WP%202019%20-%20O.1.2.3.P%20-%20Short%20position%20paper%20%E2%80%94%20analysis%20of%20a%20technical%20topic%20%28BGP%20security%29.pdf
6. CERT-EU, later attributed threat assessment: https://cert.europa.eu/publications/threat-intelligence/threat-memo-bgp-hijacking-russia/pdf
7. Moriano and co-authors, peer-reviewed historical reconstruction: https://pmoriano.com/docs/COMNET21.pdf
8. CAIDA BGPStream, historical Route Views and RIPE RIS data access: https://bgpstream.caida.org/data
9. IETF RFC 7908, route-leak definitions and classification: https://datatracker.ietf.org/doc/html/rfc7908
10. IETF RFC 7454, BGP operational security and filtering guidance: https://datatracker.ietf.org/doc/html/rfc7454
11. IETF RFC 6811, BGP origin-validation states: https://datatracker.ietf.org/doc/html/rfc6811
12. IETF RFC 7115, operational use of RPKI origin validation: https://datatracker.ietf.org/doc/html/rfc7115
13. IETF RFC 6480, RPKI architecture: https://datatracker.ietf.org/doc/html/rfc6480
14. IETF RFC 6482, Route Origin Authorization profile: https://datatracker.ietf.org/doc/html/rfc6482
15. NIST SP 800-189, BGP security and resilient exchange guidance: https://csrc.nist.gov/pubs/sp/800/189/final
16. MANRS, network-operator actions: https://manrs.org/netops/
17. MANRS, network-operator implementation guidance: https://manrs.org/netops/bcop/
18. RIPE NCC, BGP Origin Validation explanation and boundaries: https://www.ripe.net/manage-ips-and-asns/resource-management/rpki/bgp-origin-validation/