Google's 2017 BGP Leak Made Transit Filtering a Japanese Reachability Accountability Test

Summary

• On 25 August 2017, Google advertised to Verizon a large set of routes that public analyses describe as having been learned from Google’s peers. Verizon then propagated the routes onward. Many of the announcements were more specific than the normal routes to the same address space, so ordinary longest-prefix forwarding could draw traffic toward Google even though Google was not providing transit to the destinations represented by those routes. The result was significant, but not universal, reachability disruption observed by Japanese operators and users.[1][2]

• The event cannot be explained as a generic cloud outage. Its causal core was an interdomain policy chain: an export boundary at Google admitted unexpected routes, an import and onward-export boundary at Verizon did not contain them, more-specific prefixes changed traffic attraction, and withdrawals then had to propagate while networks converged. Google said it corrected the configuration error within eight minutes, and the Internet Society described the leak as lasting less than ten minutes.[1][7] Neither statement means customers everywhere recovered within the same interval.

  NTT Communications reported OCN instability from 12:22 to 12:45 Japan time, while KDDI’s notice placed recovery for some affected Internet-access customers at 16:47.[3][4]

• The accountability lesson is practical. Registry and RPKI records can identify address holders and authorized origins, but they do not make a router enforce a peer-versus-customer relationship. Route Origin Validation may leave a relationship-policy leak valid when the legitimate origin remains at the end of the path. Responsibility therefore attaches to the controls that shaped the running route state: peer-specific export policy, relationship-aware import filtering, route-volume and more-specific alarms, monitoring, rollback authority, and evidence that convergence and customer recovery actually completed.

The event boundary and the accountability question

This analysis is confined to the Google-to-Verizon route leak of 25 August 2017 and the Japanese reachability effects recorded around it. It does not combine the event with Google’s November 2018 exposure to a MainOne leak, Google Cloud’s later control-plane incidents, Meta’s 2021 BGP outage, or every Japanese service disruption in which Google appeared somewhere in the dependency chain. Those events may illuminate other failure modes, but mixing them would obscure the controls that mattered here.

The bounded question is not simply, “Who made a mistake?” It is: which actors controlled the route state that transformed a short-lived configuration error into a wider reachability problem, which controls could have interrupted that chain, and what evidence would demonstrate that those controls worked? The public record supports a strong account of propagation and operator-observed impact.

It does not expose the exact command or software path that triggered the announcements, the complete Google and Verizon routing policies, every route accepted or selected by every network, all packet loss, all customer losses, or the full internal sequence of detection and escalation.

That distinction matters because Border Gateway Protocol distributes reachability claims between autonomous systems rather than centrally determining whether every claim reflects the commercial or operational relationship behind it. A BGP speaker sends routes under configured export policy; its neighbor applies import policy, chooses among available paths, and may advertise a selected route onward.

RFC 4271 defines that basic exchange and decision framework, but the protocol cannot infer the private intent of a peering relationship from corporate identity alone.[13] RFC 7908 later supplied a taxonomy for route leaks: propagation can be technically well-formed while violating the expected scope of an autonomous-system relationship.[14]

Public event accounts describe Google as advertising routes learned from peers to Verizon, thereby appearing in the control plane as a path through which third-party destinations could be reached. Verizon accepted and redistributed at least a consequential subset of those announcements.

The routes included deaggregated, more-specific prefixes, which gave them unusual power over forwarding because routers match destination addresses to the most specific available prefix before comparing paths for equally specific routes.[1][2][10] Google was not acting as a working transit service for those third-party destinations, so traffic attracted toward that path could be dropped or otherwise fail to reach the intended network.

Remove any link from that chain and the accountability thesis changes. Without the unexpected export, there is no initiating route state. Without acceptance and onward propagation, the state stays at one boundary. Without more-specific prefixes, many networks may continue using their ordinary aggregate routes. Without traffic attraction toward a non-transit path, there is no corresponding reachability mechanism. Without withdrawal and convergence, an eight-minute correction cannot become a bounded recovery claim.

This is why the event is a network-infrastructure accountability case rather than a broad story about the reliability of a large technology company.

The evidence also does not establish intent. “Leak” describes propagation outside the expected relationship scope; it is not, by itself, proof of a deliberate hijack. Google described a configuration error and apologized for the disruption.[7] No public route path can establish criminal intent, illegality, negligence, a breach of an undisclosed contract, or the individual decision owner. The defensible inquiry concerns control and verification: what a network exported, what its neighbor accepted and propagated, how quickly the route state changed, and how long downstream reachability remained unstable.

A causal chain written in routing policy

The first control boundary was Google’s export policy. A large network learns routes from multiple classes of neighbor: customers, peers, and transit providers. The usual economic structure is not a law of nature, but it strongly shapes safe routing policy. A network generally advertises customer routes broadly because it is prepared to carry traffic to those customers. It does not ordinarily advertise one peer’s routes to another peer as if it were providing free transit between them. The public analyses of this incident say that Google sent Verizon routes it had learned from peers, crossing that expected boundary.[1][2]

That description should not be overread as a reconstruction of Google’s private configuration. Public observations do not show whether a route-map was attached incorrectly, an automated policy generator produced an overbroad set, an exception was mishandled, or some other software path caused the export. They do not disclose whether every leaked route was present in the same local routing table, whether separate sessions behaved identically, or what change-approval process preceded the event.

What they do show is the external consequence: routes with Google in the observed path appeared where the relationship classification said they should not have been propagated.

The second boundary was Verizon’s treatment of those advertisements. The event became globally consequential only because routes received from Google moved beyond that session. Public accounts identify Verizon in the propagation path and describe it accepting and redistributing the announcements.[1][2][9] This supports scrutiny of Verizon’s import controls and onward-export controls. It does not establish the exact local preference assigned to the routes, the precise filters installed at the time, the language of any peering agreement, or that every Verizon router or peer received every announcement.

An import policy is a receiving network’s opportunity to ask whether a neighbor is authorized—operationally, not merely cryptographically—to announce a route. For a customer relationship, a provider may build an allowlist from registered route objects, customer instructions, and known customer-cone data. For a peer relationship, the acceptable set normally reflects the peer and its customers, not arbitrary routes learned by that peer from elsewhere. If a peer suddenly sends a vast table or an abnormal collection of more-specifics, a filter, maximum-prefix threshold, or anomaly detector can contain or rapidly flag it.

RFC 7454 describes import and export filtering, prefix limits, and other operational protections as components of BGP security practice.[15]

Onward export is distinct from import. A router can receive a route, reject it, accept it only for limited purposes, select it for local use, or advertise it to particular neighbors. The public propagation record indicates that the Google-originating path was not kept local to the Google-Verizon adjacency. That makes the receiving network’s outward policy part of the causal chain even if the initiating error occurred elsewhere. Accountability is shared across boundaries because BGP’s damage radius is created by both the party that sends an unexpected route and the party that gives it a larger audience.

The third mechanism was prefix specificity. An aggregate route covers a large address block; a more-specific route covers a smaller portion inside that block. Forwarding uses longest-prefix match. A route to a /24, for example, is selected for destinations inside that /24 over an otherwise available /20 that also covers them. This happens before AS-path length decides among routes of the same prefix length. A leaked more-specific can therefore attract traffic even when the normal aggregate path looks more sensible and even when the legitimate resource registration has not changed.

Japanese technical reconstruction and the event analyses emphasized this deaggregation effect.[1][2][10] It explains why route count alone is not the measure of harm. Ten more-specifics covering popular destination ranges can exert more traffic attraction than many aggregates with little traffic. Conversely, a very large count does not prove that every route was installed globally or that every covered service failed. The security-relevant questions include which prefixes were more specific than the normal announcements, where they were visible, which networks selected them, and whether the path led to working transit.

The fourth mechanism was the absence of functional transit along the attracted path. The control plane could tell a router that a destination was reachable through Google without creating the data-plane capacity and forwarding policy needed for Google to deliver third-party traffic onward. Traffic following the new more-specific route could reach a dead end or take a path inconsistent with the destination’s actual connectivity.

Event-specific traceroute and routing analysis connected the abnormal announcements to reachability problems in Japan.[2] The exact disposition of every packet is not public, so “dropped or misdirected” is a bounded mechanism, not a claim that one fate applied universally.

The final links were withdrawal and convergence. Correcting the configuration stops or changes the bad export at its source. It does not atomically erase every copy of the route from every router. Withdrawal messages must propagate. Each autonomous system must process updates, recompute its best path, modify what it advertises, and update forwarding state. Route flap damping, timers, queueing, session behavior, and local policy can affect the tail, while DNS caches, transport retries, application sessions, and access-network state can make user recovery lag behind control-plane convergence.

That separation is essential to interpreting the event’s four different clocks.

Prefix counts are measurements, not a single universal total

The event is frequently summarized with a single large prefix number, but the public analyses did not all count the same entity. The Internet Society’s event account referred to roughly 135,000 leaked prefixes, while Doug Madory’s analysis described more than 160,000 prefixes in the abnormal routing episode.[1][2] Those figures should remain attributed rather than merged into an apparently exact total.

Several defensible counting choices can produce different numbers. An observer might count all routes Google received from peers before the error, all routes Google exported to Verizon, all routes Verizon accepted, all routes Verizon propagated, unique prefixes visible at one collector, unique prefix-and-path combinations across several collectors, or destination prefixes associated with measured impact. A stream of updates may also contain announcements, withdrawals, and path changes for the same prefix. Counting update messages is not the same as counting unique prefixes.

Counting all visibility during a window is not the same as taking a simultaneous routing-table snapshot.

Collector position matters too. A route visible at one RouteViews peer may not be visible at another because the second network rejected it, preferred another path, did not receive it, or chose not to export it to the collector. A collector can also receive different paths to the same prefix at different moments. The resulting dataset is a sample of interdomain routing, not a global omniscient table.

BGPStream provides a framework for accessing and analyzing routing data from collector infrastructures, while RouteViews gathers route information from participating peers for operational and research use.[11][12] Their value is substantial precisely because they preserve observable route state; their limits must remain visible in any count.

Prefix granularity adds another source of ambiguity. Suppose an ordinary aggregate is split into multiple more-specifics during the event. One analysis may count each more-specific as a leaked route. Another may group them under the aggregate or under a single affected network. A third may count only the more-specifics that crossed a particular observation point. None of those totals necessarily contradicts the others. They answer different questions.

The count most relevant to accountability is therefore not one headline total. It is a linked set of measurements: what Google advertised on the relevant session, what Verizon accepted, what Verizon exported to each class of neighbor, what selected routes appeared at external vantage points, what local RIBs and FIBs installed, and what traffic or service indicators changed. The public record provides only parts of that chain. It supports the conclusion that the leak was large and operationally consequential, but it does not support an exact claim about every route everywhere.

This distinction also prevents a false inference about universal impact. A route visible in a collector does not prove every network installed it. Installation does not prove the route carried a meaningful volume of traffic. Traffic attraction does not prove every application using the covered address range failed. Conversely, a route absent from public collectors does not prove no private interconnection saw it. The counts are evidence of propagation scale, not a census of harmed users.

For incident reporting, operators should preserve count definitions alongside the numbers. A useful report would specify the observation points, start and end criteria, treatment of duplicate updates, whether the figure refers to unique prefixes or paths, how more-specifics were grouped, and whether accepted, selected, or exported routes were counted. Without those definitions, two technically accurate totals can look like a factual dispute when they are really measurements of different stages in the same causal chain.

Google’s export control and the eight-minute correction

Google’s direct control lay over the system that generated or exported the unexpected advertisements. That control surface includes the intended relationship classification of the Verizon adjacency, the export policy applied to it, the data used to build that policy, change review, staged deployment, monitoring, automated rollback, and the authority to stop the propagation once detected. The public evidence establishes the external routing outcome but leaves the initiating technical path unknown.

Contemporaneous Japanese reporting preserved Google’s statement that a configuration error was corrected within eight minutes, along with an apology for the disruption.[7] The Internet Society described the leak itself as lasting less than ten minutes.[1] These accounts are broadly compatible, but they should not be treated as the same metric. “Configuration corrected” is an action at the source. “Leak lasted” is an observer’s characterization of abnormal route announcements. Neither is a measurement of the instant at which every external router withdrew the route or every customer regained stable access.

An eight-minute correction can indicate effective detection and rollback at one layer while still exposing weaknesses at prevention and evidence. The key questions are when the first unexpected advertisement left Google, when internal monitoring detected it, whether an external alert arrived first, when a decision owner authorized reversal, when each relevant session stopped exporting it, and when route withdrawals became visible across independent collectors. The public record does not supply that complete chronology.

Prevention should begin before a change reaches a live peer. An export policy can be generated from a declared relationship map and tested against invariants: a peer-facing session should not receive prefixes learned from another peer or provider; a maximum route count should stay within an expected range; more-specifics outside an approved set should fail; and a policy diff should state exactly which prefixes and communities become newly exportable. Tests need a realistic route table, because a policy that behaves safely against a tiny laboratory sample may produce a radically different export set against the full table.

Deployment controls can further narrow the blast radius. A route-policy change can be staged on one session or limited to a canary router, with comparisons of Adj-RIB-Out before and after. An independent system can calculate the delta in advertised prefixes, identify new origin ASes, detect unexpected provider or peer paths, and stop the rollout if the shape exceeds a threshold. A rollback mechanism must be tested, not merely documented, and the person or automation that receives the alarm must have authority to use it.

Monitoring should distinguish volume from relationship violations. A max-prefix alarm may catch a sudden jump from an expected small set to more than a hundred thousand routes, but a smaller leak could still be harmful. A policy monitor should also detect a peer-learned route moving to another peer, an unexpected more-specific, a path containing an impossible relationship sequence, or a large change in destination coverage. External route monitoring adds confirmation that the route crossed the organization’s perimeter; it does not replace internal comparison of received and advertised state.

Google later described a broader routing-security program involving Internet Routing Registry data, RPKI validation, automated controls, coordination, and MANRS commitments.[5] Google’s current Interconnect documentation also sets out BGP filtering expectations and tells peers to maintain safeguards on their side.[6] Those materials are relevant comparisons for how a large network can express and validate routing intent. They are not proof of the exact controls present on 25 August 2017, independent confirmation that every later measure operated as described, or retroactive duties by which to declare a legal breach.

The accountability standard is therefore narrower and stronger than hindsight. Google controlled whether peer-learned routes left its boundary and how quickly it could identify and reverse an abnormal export. Its eight-minute correction is material evidence of response speed, but it does not answer whether pre-deployment checks should have blocked the state, how many sessions were affected, or when the wider Internet finished converging. Those unanswered questions call for route-state evidence, not speculation about motives.

Verizon’s import boundary and the meaning of transit filtering

The event’s scale depended on a receiving network turning an unexpected advertisement into propagated reachability. Public analyses identify Verizon as the neighbor that received the Google announcements and sent them onward.[1][2][9] That makes transit filtering a central accountability test. A sender’s error is one failure; a provider or peer’s inability to contain an implausible route set is another control boundary with its own owner.

“Filtering” is sometimes used as if it meant checking only whether a prefix exists in a registry. That is incomplete. A receiving network needs to evaluate at least three dimensions: resource authorization, relationship authorization, and operational shape. Resource authorization asks whether the origin and prefix are consistent with authoritative records. Relationship authorization asks whether this neighbor should be exporting this route across this type of adjacency. Operational shape asks whether the number, specificity, path pattern, and rate of announcements are plausible for that neighbor.

The 2017 leak was especially revealing because a route can look ordinary in one dimension and wrong in another. A prefix may have a legitimate origin AS at the end of the AS path. Its holder may have an accurate registry entry. Yet the path can still be propagated across a peer relationship that was not meant to provide transit. A filter limited to origin authorization may accept the route, while a relationship-aware policy would reject it. That is why the case cannot be reduced to “deploy RPKI.”

Customer-route filters are one practical form of relationship enforcement. A provider can maintain a defined set of prefixes and origin ASes that a customer is allowed to announce, built from authenticated instructions, registry data, RPKI, and verified customer-cone information. A peer presents a different problem because a large peer may legitimately advertise a broad and changing customer cone.

Even so, the policy need not be “accept anything.” Operators can set route-count envelopes, reject default and obviously unacceptable ranges, constrain excessive deaggregation, inspect unexpected AS-path relationships, and maintain emergency controls that stop an anomalous export from reaching the rest of the network.

Max-prefix is useful but blunt. A threshold could have identified an enormous departure from an expected table size, depending on the baseline and session design. But a limit set too high provides little protection; one set too low can tear down a session and cause its own reachability loss. The count also cannot detect a small leak aimed at high-traffic prefixes. Good practice therefore pairs maximum-prefix controls with graded alarms, route-shape analysis, and a deliberate response plan rather than treating session shutdown as the only safe action.[15]

Import acceptance and outward propagation should also be separately observable. A network may need to retain a snapshot of Adj-RIB-In showing what the neighbor sent, a post-policy view showing what survived filtering, the local RIB showing what was selected, and Adj-RIB-Out views showing where the result was advertised. Those records answer different accountability questions. Without them, an operator may know only that an external collector saw a path, not which internal policy stage allowed it.

The public record does not reveal Verizon’s complete filter configuration, local-preference values, route-reflector behavior, approval records, or per-peer export results. It would be wrong to claim that all Verizon peers accepted every leaked route or that all affected Japanese paths were identical. Different networks could reject, accept, or prefer different portions of the announcements. The defensible conclusion is that enough propagation occurred through the Verizon boundary to produce broad external visibility and reachability effects, so the efficacy of its relationship and transit controls is a legitimate subject of accountability.

That conclusion is not an allegation of a private contract breach. Commercial labels such as “peer,” “customer,” and “provider” are useful abstractions, but the public Internet does not expose every exception or bilateral term. The technical evidence instead shows a mismatch between the apparent reachability promise and working transit. If a network propagates a path that attracts traffic through a neighbor unable or unwilling to carry it onward, the operational control has failed regardless of whether the legal allocation of responsibility is public.

Why more-specific propagation moved traffic

The force of the leak came not only from the number of routes but from how IP forwarding resolves overlapping reachability. Routers compare the destination address against installed prefixes and use the longest matching prefix. If a normal path announces an aggregate and an abnormal path announces a covered more-specific, traffic for the covered addresses follows the more-specific. AS-path length, business preference, and other BGP attributes decide among candidate paths for the same prefix; they do not cause a less-specific aggregate to beat an installed more-specific.

This mechanism explains why correct high-level registry data can coexist with incorrect reachability. The holder of an aggregate has not necessarily changed. The legitimate origin of a prefix may remain visible. Yet a more-specific route, exported along an unintended AS relationship and selected by remote networks, can redirect packets away from the ordinary path. The recordkeeping layer can remain accurate while the running network behaves wrongly.

Public technical accounts of the event described deaggregated Japanese routes moving through Google and Verizon.[1][2][10] Those observations connect the control-plane anomaly to the location of the reported disruption. They do not establish that every Japanese prefix was more-specific, every network preferred the same path, or every packet entered Google. A complete assessment would compare, prefix by prefix, the normal aggregate and more-specific announcements, their origin and path attributes, their visibility by collector and time, and the destination traffic affected.

More-specifics also complicate prevention. An operator cannot safely reject every deaggregated route; multihoming, traffic engineering, mitigation, and operational transitions can make more-specific announcements legitimate. IPv4 /24s, in particular, are commonly propagated. A sound control asks whether this neighbor is authorized to advertise this particular more-specific in this relationship, whether the origin is authorized for that length, whether the announcement matches an expected customer cone, and whether its sudden appearance is anomalous.

RPKI can help with the prefix-and-origin component when a Route Origin Authorization exists. A ROA identifies an authorized origin AS and may constrain the maximum prefix length.[19] If a leaked more-specific exceeds the ROA’s maximum length, Route Origin Validation may classify it as invalid. But if the more-specific and origin are authorized—or if no covering ROA exists—the route may be valid or not found even though its propagation violates the relationship’s intended scope. RFC 6811 describes origin validation; it does not claim to validate the whole AS path or the commercial authorization for one network to transit another’s route.[18]

Traffic impact further depends on the data plane. A selected route must be installed in forwarding state, traffic must actually target the covered addresses, and the advertised next hop must fail to deliver it correctly. Public traceroute observations can support that link from route attraction to failed reachability, as the event analysis did.[2] They remain samples. Without flow telemetry, packet captures, and local forwarding records from relevant networks, the volume and fate of all affected traffic cannot be assigned precisely.

This is the running-code principle in concrete form. A registry can say who holds a number resource. A ROA can say which AS may originate it. A peering record or contract can describe an intended relationship. But packets follow the forwarding entries installed by operating routers. Accountability must therefore compare declarative records with actual received, selected, installed, and exported state. The reality layer is not an argument against registries; it is the reason registry evidence must be joined to enforcement and telemetry.

Four recovery clocks, not one eight-minute outage

The public timeline contains at least four distinct clocks. Collapsing them into one duration would make the response look either faster or slower than the evidence supports.

The first clock is Google’s configuration correction. Google said it corrected the configuration error within eight minutes.[7] This describes action at the initiating system. It is the narrowest response measure and an important one: the source stopped creating or exporting the bad state. It does not specify when every relevant session emitted a withdrawal, when Verizon processed it, or when remote networks changed their selected paths.

The second clock is observable leak duration. The Internet Society described the leak as lasting less than ten minutes.[1] That estimate reflects the abnormal routing episode as seen through available evidence. Its start and end can differ from an internal configuration timestamp because monitoring vantage points receive updates after propagation delay, and because “end” may mean the last abnormal announcement, the first withdrawal, or disappearance from a selected route at a particular observer. The source correction and the collector-observed interval are related but not interchangeable.

The third clock is interdomain withdrawal and convergence. Once the export was corrected, withdrawals or replacement announcements had to move through Verizon and other networks. Routers recalculated paths and advertised their choices onward. Some networks may have had unaffected alternatives ready; others had to process a large burst of changes. External visibility can normalize at different times across peers. No single global convergence timestamp is established in the public record.

The fourth clock is operator and customer recovery. NTT Communications reported that large Internet route changes made OCN connectivity unstable from 12:22 to 12:45 Japan time and stated that its own OCN equipment showed no abnormality.[4] Contemporaneous Japanese reporting also associated the instability with the route event.[8] That 23-minute operator window extends beyond Google’s eight-minute correction and is direct evidence that source rollback did not instantly equal stable access.

KDDI recorded instability affecting some Internet-access customers and reported a longer recovery window ending at 16:47.[3] The notice does not justify treating every KDDI customer as affected until that moment, much less all of Japan. It does show that at least one operator’s customer stabilization clock extended for hours beyond the initiating configuration correction. Local routing, session recovery, access systems, cached application state, retries, and operator confirmation practices can all contribute to such a tail, but the public notice does not allocate the duration among those mechanisms.

These clocks support a precise formulation: Google corrected the initiating configuration within eight minutes; public routing analysis characterized the leak itself as under ten minutes; withdrawals and route selection then had to converge; NTT observed a bounded 12:22–12:45 instability window; and KDDI’s notice placed recovery for some affected customers at 16:47. None of those statements proves the others wrong. Each measures a different layer.

It is equally important not to generalize the operator evidence. NTT’s statement concerned OCN connectivity and did not enumerate every service, prefix, or customer. KDDI’s notice concerned some Internet-access users. Secondary reporting named additional Japanese services and companies,[8][9] but it does not provide a complete impact census or verified loss total. “Substantial Japanese reachability disruption” is supported; “Japan was entirely offline” is not.

A mature incident closeout should publish these clocks separately. It should state when the bad configuration became active, when the first external abnormal route appeared, when the source stopped exporting it, when withdrawals reached representative observation points, when local RIB and FIB state normalized, when network service indicators recovered, and when customer-facing systems were confirmed stable. Each timestamp should name its measurement source and uncertainty. A single “resolved” time conceals the very boundaries needed to improve control.

Route evidence is powerful—and incomplete

Public route data makes this incident unusually inspectable. BGP collectors receive routes from participating networks and preserve routing-table snapshots and update streams. BGPStream provides structured access across collection projects,[11] while RouteViews maintains collector infrastructure and archives useful for historical reconstruction.[12] Event analysts can use those records to identify when a prefix appeared, which AS path a collector peer reported, when a more-specific emerged, and when a route changed or disappeared.

That evidence can test the propagation hypothesis. If multiple independent vantage points show a Japanese destination prefix with an AS path passing through Verizon and Google during the impact window, then revert after withdrawals, the temporal and topological match is meaningful. If more-specifics appear along that path while normal aggregates remain elsewhere, longest-prefix behavior supplies a credible traffic-attraction mechanism. Traceroute or operator telemetry aligned to the same window can strengthen the bridge from control plane to user impact.[2]

Yet a collector sees only what its peers choose to advertise to it. The view is shaped by the collector’s location, the peer’s selected route, and export policy. It usually does not expose all alternative routes in that peer’s Adj-RIB-In, the local preference and other private decision inputs, routes rejected by policy, or the exact forwarding entry installed on every line card. It cannot see every private peering session. It cannot prove why an engineer or automation changed a policy.

Absence and presence therefore have asymmetric limits. If a collector does not show a route, the route may still have existed on a private adjacency or at an unobserved network. If a collector does show a route, that does not prove every network received or selected it. Even selection by a collector peer does not prove every packet followed it, because forwarding state, traffic engineering, tunneling, or localized failures can change the data-plane result. Seeing an announcement also does not prove every application using the prefix became unavailable.

Time measurements have similar qualifications. Update timestamps record receipt at an observation point, not the instant a human entered a command or the precise moment the originating router altered its outbound policy. Clock quality, propagation delay, collector session state, and the analyst’s window definition matter. A “less than ten minutes” leak observed publicly can coexist with an eight-minute internal correction and a longer downstream recovery.

The best evidence framework combines four layers. First are authoritative records: ASN, prefix, route object, and ROA data that identify declared resource and origin relationships. Second are local control-plane records: received routes, policy decisions, selected routes, and advertisements. Third are forwarding and traffic records: FIB state, next-hop changes, flow volume, loss, and latency. Fourth are external observations: collectors, probes, traceroutes, and customer reports. Each layer can challenge or corroborate the others.

For this incident, public evidence is strongest at the external route and operator-notice layers. The missing internal evidence includes Google’s relevant Adj-RIB-Out snapshots, Verizon’s Adj-RIB-In and post-policy state, per-peer propagation records, policy versions, alert timestamps, rollback events, and local forwarding telemetry from affected networks. Publishing suitably redacted versions of those records would allow independent reviewers to distinguish an export-generation failure from an attachment error, an import allowlist gap, a threshold failure, or an unexpected policy exception.

Measurement organizations also carry responsibilities. They should describe collector coverage, data gaps, deduplication methods, and confidence limits. A striking path visualization can make a mechanism understandable, but it should not be presented as omniscient. Reproducible queries, named observation points, time zones, and definitions of prefix counts make the evidence more useful to operators and less vulnerable to false certainty.

Registry and RPKI records are ledgers, not enforcement engines

Internet number-resource records are indispensable to accountability. ASN and prefix registries identify recognized holders and contacts. Internet Routing Registry entities can express intended route-origin relationships. RPKI adds cryptographically verifiable authorization through ROAs. These records make it possible to compare an observed route with a declared source of authority, investigate anomalies, and generate filters. They are a ledger of expected facts.

A ledger does not execute router policy. A correct registry entry cannot stop a BGP speaker from advertising a route. A valid ROA cannot force a receiving network to perform Route Origin Validation or determine its local response. Even where ROV is active, it checks whether the origin AS is authorized for the prefix and length. It does not, by itself, prove that every AS in the path had authority to provide transit across every relationship.

That limitation is central to the 2017 event. The public account is a relationship-policy leak: Google exported routes learned from peers, and Verizon propagated them. If the final origin AS for a leaked route remained the legitimate origin and the prefix length fit a ROA, origin validation could classify the announcement as valid despite the unwanted propagation path. If the route had no covering ROA, it could be “not found.” Only a subset with an unauthorized origin or excessive length would necessarily become RPKI-invalid under the ROA semantics.[18][19]

ROV could still have helped for any announcement that violated origin or maximum-length authorization, and broad ROA coverage improves the evidence available to filters. The correct conclusion is not that RPKI was irrelevant. It is that origin authorization and relationship authorization solve different parts of routing security. Claiming that RPKI alone would certainly have stopped this event would erase the defining mechanism.

IRR-based filters have a parallel limitation. Accurate, authenticated route objects can help a provider construct an allowlist for a customer. But stale, incomplete, overly broad, or unauthenticated data can produce unsafe filters, and a route object does not encode every peer-versus-transit constraint. A large network must join registry data to an explicit definition of what each neighbor may announce and where each learned route may be exported.

The distinction can be expressed as three questions. “Who is recognized as the number-resource holder?” is a registry question. “Which AS is authorized to originate this prefix and length?” is a ROA and ROV question. “May this neighbor advertise this path to me, and may I send it onward to this other neighbor?” is an AS-relationship and routing-policy question. The first two inform the third; they do not answer it completely.

Running route state is the reality layer because it determines reachability. That phrase does not diminish the authority or value of records. It sets the standard by which their operational use is judged. A network that maintains accurate records but does not consume them into filters has an evidence layer without enforcement. A network that applies filters but cannot preserve the received, rejected, selected, and exported states has enforcement without adequate auditability. Reliable routing requires both.

This also places responsibility in the right locations. Resource holders should maintain accurate prefix, contact, and ROA data. Registries and RPKI repositories should preserve availability, integrity, and clear semantics. Network operators should retrieve, validate, and safely transform that data into policy while managing stale-data and fail-open or fail-closed risks. None of those roles can transfer the receiving router’s policy decision to the end user.

Later controls illuminate the gap without creating retroactive duties

Several routing-security mechanisms provide useful comparisons for the control gaps exposed in 2017. They should be used as engineering lenses, not as retroactive legal standards or proof that one product would have prevented every leaked route.

RFC 8212 specifies a safer default for external BGP: absent explicit import and export policy, routes should not be accepted or advertised.[16] The principle reduces accidental reliance on permissive defaults. In a mature design, every external relationship has intentional policy in both directions. Applied to the accountability analysis here, it asks whether the Google-Verizon session had explicit policies and whether those policies were generated, attached, and tested correctly. It does not reveal what configuration existed during the incident or guarantee that an explicit but incorrect policy would have blocked the leak.

RFC 9234 later standardized BGP Roles and the Only-to-Customer attribute as tools for communicating and enforcing relationship expectations.[17] BGP Roles let neighbors declare relationship types, while OTC can help identify paths that have crossed a boundary in a way inconsistent with valley-free propagation. This addresses more of the leak’s relationship dimension than origin-only validation. Deployment remains bilateral or ecosystem-dependent, and policy exceptions still require care. The RFC is a later comparison, not a retroactive duty imposed on the 2017 actors.

Peerlock is another relationship-aware technique. An operator creates filters intended to stop paths that contain a protected peer AS in positions where that peer should not appear, reducing certain leak patterns. It can be effective for selected high-value relationships but depends on correct configuration, coverage, and maintenance. It is not a universal path-validation system. APNIC’s later survey discusses Peerlock and emerging ASPA approaches among the mechanisms for interdomain routing security.[21]

ASPA—Autonomous System Provider Authorization—aims to let an AS attest to its authorized providers so relying networks can evaluate whether observed provider relationships in a path are plausible. It offers a more scalable foundation for detecting some valley violations than hand-maintained bilateral filters. Its security value depends on adoption, accurate authorizations, path-validation rules, and operational deployment. It should not be projected backward as a control that the parties were already obliged or able to use in 2017.

Max-prefix limits and abnormal-route alarms remain valuable regardless of cryptographic path mechanisms. A session expected to exchange a bounded set should not silently jump by orders of magnitude. Controls can watch total route count, new origins, new destination coverage, unexpected more-specific density, update velocity, and policy-class violations. The response need not always be a hard session reset: rate-limited quarantine, selective rejection, escalation, or retention of the last known safe policy may reduce collateral harm. The safe choice depends on relationship and topology.

Explicit export policy is equally important. The sender should tag or otherwise classify routes at ingress by source relationship, preserve that provenance through its routing system, and permit export only to allowed relationship classes. A peer-learned route should not become eligible for another peer merely because it wins a best-path calculation. Policy-generation systems should make the forbidden transitions testable as invariants.

Route Origin Validation complements these controls. It can reject or de-preference invalid origin claims, provided the operator has reliable RPKI data and a defined policy. But relationship-policy controls must stand alongside it. The incident demonstrates why “valid origin” cannot be treated as “valid path” or “authorized transit.”

MANRS frames filtering, coordination, global validation information, and anti-spoofing as operational responsibilities, and its measurement framework seeks observable evidence of routing-security actions.[20] Google’s later public commitments and routing-security work can be compared with that framework.[5] Such commitments are useful when they produce measurable route behavior, published scope, and independent observation. They are not substitutes for per-incident evidence or proof that every internal safeguard has been independently verified.

The right prevention strategy is layered because each control fails differently. Registry and ROA accuracy can be incomplete. Relationship filters can become stale. Max-prefix can miss small leaks or cause session loss. Roles and OTC require deployment. Peerlock covers selected patterns. ASPA depends on an authorization ecosystem. Monitoring detects after state begins to move. Together, with staged change control and tested rollback, they create multiple opportunities to stop or shorten a leak.

Responsibility follows practical control

Accountability is clearest when mapped to the controls each actor could actually exercise.

Google controlled the initiating route-generation and export environment. That includes the classification of learned routes, the policy applied to the Verizon adjacency, route-policy code and data, pre-deployment tests, change approval, staged rollout, internal and external monitoring, rollback, evidence retention, and its public account of the event. The public record supports an accidental configuration-error explanation and an eight-minute correction claim.[7] It does not identify the exact decision owner, triggering command, or complete remediation.

Verizon controlled whether routes received from Google were accepted, how they were ranked, and to which neighbors they were exported. Its relevant controls included relationship-aware allowlists, customer-cone or peer-route validation, max-prefix and route-shape thresholds, internal propagation boundaries, emergency rejection, monitoring, escalation, and evidence retention. The observed onward propagation makes those controls material. It does not establish the same result on every session or disclose private policy and contract terms.

Japanese network operators controlled their own route selection, local mitigations, customer communications, and the evidence used to declare service stable. They did not create the initiating advertisement merely because their customers experienced its effects. NTT’s notice distinguished external large route changes from abnormalities in its own OCN equipment,[4] while KDDI documented impact to some customers and a later recovery.[3] Those notices are valuable accountability records because they mark bounded observations without pretending to reconstruct the whole Internet.

Resource holders controlled the accuracy of their registry and ROA information. That information could help networks validate origins and generate filters, but a resource holder could not force Google or Verizon routers to enforce an AS-relationship rule. Registry operators and RPKI repositories controlled the integrity and availability of the record layer, not the local policy of every BGP speaker.

Measurement organizations and independent analysts controlled the quality of public reconstruction. Their responsibility was to preserve provenance, define counts and windows, disclose vantage limits, and avoid treating sampled control-plane observations as universal packet evidence. Their work made the event legible; it did not give them access to every private session or internal alert.

End users controlled none of the interdomain routing state. They could retry connections, change access providers, or use alternative services in some circumstances, but those are coping actions, not prevention duties. A customer’s dependence on an access network does not make the customer responsible for validating an upstream peer’s route export.

This map prevents two common errors. The first is assigning all responsibility to the originator of a mistake even when another network’s filters determined the blast radius. The second is spreading responsibility so broadly that no control owner remains identifiable. In BGP, both sending and receiving policies matter. The initiating network owns the bad export; the receiving and propagating network owns its containment boundary; downstream operators own local resilience and truthful recovery evidence.

The map also separates operational accountability from legal judgment. Public route observations can show control-plane behavior and support questions about safeguards. They do not disclose contractual allocation, regulatory findings, standards of care in a particular jurisdiction, or causally verified losses. This article therefore makes no allegation of illegality, negligence, or contract breach. Its claim is technical: practical control over route acceptance and propagation creates a corresponding obligation to measure, constrain, and explain that state.

Evidence still needed for a complete account

The strongest missing evidence is the exact route-state chain. From Google, that would include the relevant policy version, relationship classification, route-policy diff, Adj-RIB-In provenance, Adj-RIB-Out before and during the event, alarm timestamps, rollout scope, and rollback records. Such evidence could show whether the failure lay in route classification, policy generation, attachment, deployment, or another software path.

From Verizon, the needed record includes the routes received on the relevant adjacency, which ones survived import policy, which entered the local RIB, which were selected, and which were advertised to each neighbor class. The applicable filter versions, threshold settings, alarms, route-reflector propagation, and response timeline would show whether containment failed because a rule was absent, stale, bypassed, incorrectly scoped, or not acted upon.

From Japanese operators, local RIB and FIB changes aligned to service telemetry would clarify why customer recovery outlasted the initiating error. Prefix-level loss, latency, next-hop, and traffic-volume data could distinguish ongoing external convergence from local session recovery, cached state, application retries, or cautious confirmation. KDDI’s longer window is evidence of a customer-recovery tail, not an explanation of every minute in that tail.

Cross-operator evidence would also resolve the count differences. A shared timeline could define the first bad export, the first Verizon acceptance, the first onward advertisement, the peak unique prefixes at each stage, the first withdrawal, the last abnormal selected route at representative vantage points, and the return of traffic indicators. Each count should name whether it measures updates, unique prefixes, unique paths, more-specifics, or affected resources.

Internal alert and decision records remain unknown. The eight-minute correction does not reveal whether Google’s own systems detected the problem immediately, whether Verizon or an external observer alerted Google, who had rollback authority, or how quickly Verizon applied containment. These are not invitations to guess. They are specific evidence requests that determine whether monitoring, escalation, and authority worked as designed.

Loss attribution is also incomplete. Public notices and secondary reports demonstrate disruption, but they do not establish every affected organization, duration, transaction failure, financial loss, or contractual consequence. Any quantitative loss claim would need service-specific telemetry and a causation method that separates the BGP event from unrelated local failures.

Finally, later remediation lacks complete independent verification in the frozen public record. Google’s later routing-security publications describe significant controls,[5][6] and MANRS provides a useful accountability framework,[20] but a program description is not the same as proof that every relevant adjacency enforces the intended policy under failure. Verification would require current, appropriately protected test results and route observations rather than a retrospective assumption.

The account should remain open to revision. If contemporaneous configurations showed a materially different propagation chain, the responsibility map would need to change. If local operator telemetry contradicted the public route observations, the causal claim would need narrowing. Evidence-led accountability means identifying what would falsify the explanation, not protecting a preferred narrative.

A prevention and verification program

The 2017 event suggests a layered program organized around intent, enforcement, observation, and recovery.

First, maintain an authoritative relationship and resource inventory. Every external BGP session should have an owner, neighbor identity, relationship class, expected prefix and path envelope, escalation contact, and approved exceptions. Prefix, ASN, IRR, and ROA records should be accurate and monitored for change. This inventory is the ledger from which policy can be generated and against which route state can be audited.

Second, make export policy explicit and provenance-aware. Routes should retain a trustworthy classification based on where they were learned. Peer- and provider-learned routes should not be eligible for export to another peer unless a documented exception intentionally provides transit. Policy-generation tests should evaluate the full transition matrix—customer to peer, peer to customer, peer to peer, provider to peer, and so on—and fail when an unauthorized transition becomes possible.

Third, make import policy relationship-aware. Validate origin where RPKI data exists; build prefix and origin allowlists where the relationship permits; check expected customer-cone or provider relationships; reject unacceptable ranges and default routes unless explicitly intended; and scrutinize more-specifics. Treat “RPKI Valid” as one input, not a complete authorization verdict.

Fourth, set volume and shape controls. Maximum-prefix thresholds should reflect normal behavior and include warning bands before a hard action. Monitor the rate of updates, number of new origins, expansion of address coverage, sudden deaggregation, path anomalies, and policy-class violations. A leak of a few important routes should not pass merely because it stays below a count threshold.

Fifth, stage changes against realistic state. Before deployment, apply the proposed policy to a representative or full route table and compare received, selected, and advertised results. Require a machine-readable diff of newly accepted and exported prefixes. Canary the change where topology permits. Stop rollout automatically when the delta violates a declared invariant, and require explicit approval for exceptions.

Sixth, retain the evidence needed to reconstruct a boundary. Archive relevant Adj-RIB-In, post-policy, local RIB, Adj-RIB-Out, and FIB snapshots around changes and alarms, subject to security and privacy constraints. Record policy version, deployment identifier, timestamps, and decision owner. External collectors should corroborate the perimeter view, not substitute for the internal stages.

Seventh, monitor from both inside and outside. Internal telemetry can see rejected routes and policy decisions that collectors miss. Independent route monitors can detect that an unexpected path escaped into the wider Internet. Alerts should be routed to an owner with tested rollback authority, and the response playbook should specify when to withdraw routes, quarantine a session, apply a selective filter, or coordinate with a neighbor.

Eighth, rehearse failure. Test a peer-learned route attempting to cross another peer boundary. Test a large prefix surge and a small high-impact more-specific leak. Test stale IRR data, an RPKI repository problem, a mistaken ROA maximum length, and an incorrect relationship tag. Confirm that controls fail in understood ways and that a safety mechanism does not create a larger outage than the condition it addresses.

Ninth, separate correction from convergence and customer recovery in incident command. The source team should report when the configuration was reversed. Routing teams should track withdrawals and selected-path normalization. Network and service teams should verify forwarding, loss, latency, and application health. Customer communications should state the affected service scope and the evidence behind recovery. These workstreams may close at different times.

Tenth, publish a bounded post-incident record. A useful disclosure need not expose sensitive configurations. It can state the triggering class, affected adjacency scope, defined prefix-count method, first and last observed bad routes, correction time, convergence evidence, customer-impact windows, controls that failed, exact remediations, and how those remediations were tested. It should distinguish confirmed facts from hypotheses and list unresolved gaps.

Later mechanisms can strengthen this program. Explicit default-reject behavior under RFC 8212 can reduce permissive sessions.[16] BGP Roles and OTC can express relationship information that origin validation lacks.[17] Peerlock can protect selected relationships, and ASPA may support broader provider-path validation.[21] ROV can reject unauthorized origins or lengths.[18] MANRS can frame observable operator commitments.[20] None is sufficient alone, and none should be used to manufacture a retroactive legal duty.

The verification target is not a policy document. It is a set of measured claims: no peer-learned route appeared in the prohibited Adj-RIB-Out; an injected invalid origin was rejected; an unexpected more-specific triggered an alarm; a route-count surge invoked the planned response; external vantage points did not see the test route; and rollback restored both control-plane and service indicators within measured bounds. Governance becomes credible when the declared rule and the running route state agree.

Conclusion: reachability is governed at the boundary

Google’s 25 August 2017 error lasted minutes at its initiating control, but the route state it created crossed organizational boundaries and produced a longer recovery tail for some Japanese customers. Public evidence supports a specific sequence: Google exported a large set of peer-learned routes to Verizon; Verizon propagated consequential routes onward; more-specific announcements attracted traffic; Google was not providing functional transit to the represented destinations; and withdrawals then had to propagate while networks and services stabilized.[1][2][3][4]

The differing public prefix totals do not defeat that conclusion. They warn against pretending that one observer counted the entire Internet. The eight-minute correction, sub-ten-minute observed leak, NTT’s 12:22–12:45 instability, and KDDI’s recovery notice ending at 16:47 are likewise not rival versions of one duration. They are measurements of different layers: source correction, observable propagation, convergence, operator stability, and customer recovery.

The central accountability test is whether intent was encoded and verified at both sides of an interconnection. Google controlled which learned routes it exported. Verizon controlled which routes it accepted and propagated. Accurate registry and ROA records could inform those decisions, but could not execute them. ROV could identify an unauthorized origin or excessive prefix length, but could leave a legitimate-origin relationship leak untouched. Running routers, configured policies, and installed forwarding state determined whether packets arrived.

That reality does not make registries secondary. It makes them evidence ledgers that must feed enforcement. Nor does shared control excuse the initiating error. It shows why route safety cannot depend on one network being infallible. Export filters, import filters, relationship controls, more-specific and volume alarms, independent monitoring, and rapid rollback form a system of containment.

The unresolved facts remain consequential: the exact triggering path, complete policies, all accepted and installed routes, internal alerts, full Japanese impact, customer losses, and independent proof of later remediation. Those gaps should stay visible. The responsible conclusion is not that the case proves malicious intent, universal Japanese failure, or BGP’s inherent impossibility.

It proves something more operationally useful: a peering label or registry entry becomes protective only when machine-enforced policy governs actual route propagation, and recovery is complete only when route and customer evidence—not the first corrected configuration—show that reachability has returned.

Sources

[1] https://www.internetsociety.org/blog/2017/08/google-leaked-prefixes-knocked-japan-off-internet/ [2] https://circleid.com/posts/20170831_large_bgp_leak_by_google_disrupts_internet_in_japan [3] https://www.notice.kddi.com/news/mainte/content/syougai/jyouji_00021279.html [4] https://support.ntt.com/supportTopInfo/detail/pid2500000g6q [5] https://cloud.google.com/blog/products/networking/how-google-is-working-to-improve-internet-routing-security [6] https://support.google.com/interconnect/answer/9325705?hl=en [7] https://internet.watch.impress.co.jp/docs/news/1077715.html [8] https://internet.watch.impress.co.jp/docs/news/1077431.html [9] https://www.bleepingcomputer.com/news/technology/google-error-causes-widespread-internet-outage-in-japan/ [10] https://www.geekpage.jp/blog/?id=2017-8-29-1 [11] https://bgpstream.caida.org/docs/overview [12] https://www.routeviews.org/routeviews/ [13] https://www.rfc-editor.org/rfc/rfc4271.html [14] https://www.rfc-editor.org/rfc/rfc7908.html [15] https://www.rfc-editor.org/rfc/rfc7454.html [16] https://www.rfc-editor.org/rfc/rfc8212.html [17] https://www.rfc-editor.org/rfc/rfc9234.html [18] https://www.rfc-editor.org/rfc/rfc6811.html [19] https://www.rfc-editor.org/rfc/rfc6482.html [20] https://manrs.org/manrs-observatory/measurement-framework/ [21] https://blog.apnic.net/2021/07/09/a-survey-on-securing-inter-domain-routing-part-2/