Cox's 2025 route leak and the proof RPKI containment can provide

Summary

APNIC's analysis of BGP update logs found that AS22773 appeared as the origin of 4,651 additional IPv4 routes on 1 May 2025. The observation point intentionally did not reject RPKI Invalid routes, which made routes visible there that an Invalid-rejecting speaker would exclude. [1]
The additions appeared in two broad waves. APNIC recorded about 3,365 routes between roughly 16:45 and 16:50 UTC, then about 1,141 between roughly 17:50 and 17:55. Broad withdrawals also came in two stages, around 21:30 to 21:45 and 22:30 to 22:40. These are receipt times at one observer, not timestamps for an internal Cox change. [1]
Of the 4,651 additional routes, 4,644 would have been RPKI Invalid to a validating speaker. Seven were not covered by a valid ROA. That result demonstrates a large containment difference between a non-validating observation point and a network that rejects Invalid routes, without proving what every network accepted or exported. [1]
A ROA supplies authorization for a prefix to be originated by an AS, and Route Origin Validation evaluates the observed prefix-origin pairing against validated authorization data. ROV does not authenticate every AS in the path, prove the business relationship behind an announcement, or establish that a route was operationally intended. [8][10][11]
The confirmed injury is to routing integrity. Erroneous origins entered the BGP information retained by the observer and remained available to networks that did not reject Invalid routes. The supplied record does not establish a user-visible outage, packet diversion, interception, customer loss, regulatory action, or monetary damage. [1][8]
Containment by downstream networks does not excuse the origin. Cox controlled route creation, redistribution, outbound policy, deployment review, monitoring, withdrawal and disclosure. Resource holders controlled ROA accuracy, while peers and transit providers separately controlled import filters, ROV and propagation decisions.
APNIC's then-current figure that ROAs covered about 95.06 percent of Cox's advertised IPv4 prefix set is useful adoption context, not proof of the exact configuration on 1 May and not an explanation of every leaked route's validity. Current APNIC Labs, RIPEstat and Cloudflare Radar views must not be read backward as historical snapshots. [1]-[3][5][6]
Export-side origin checks, BGP Roles, the Only-to-Customer mechanism, explicit prefix and AS-path filters, and path-oriented defenses such as Peerlock represent different control classes. Their standards and research records show what operators can deploy, but do not establish which controls Cox or any neighbor had enabled during this event. [12]-[17]
The public evidence can support a containment finding only if its limits remain visible. A single non-validating observer shows receipt at that location. It does not show neighbor-by-neighbor acceptance, route selection, onward export, traffic flow, global reach, or the exact time and cause of an internal correction.
A credible accountability record would add an intended-prefix inventory, semantic export-policy tests, abnormal-origin alarms, staged deployment evidence, neighbor rejection data, historical ROA snapshots, exact withdrawal timing and a post-event explanation of trigger, ownership and repair. Until that evidence exists, accidental leakage and material ROV containment remain probable conclusions, while root cause, user impact and remediation remain unknown.

The contrast is the evidence

The most important fact in this event is not simply that thousands of routes appeared with an unexpected origin. Route leaks are often described through the routes that propagated, the services that failed or the organizations that later explained a configuration error. The supplied record for 1 May 2025 is different. It provides a controlled observational contrast between a BGP vantage point that intentionally retained Invalid routes and the route set that would remain usable under a policy that rejects them.

Geoff Huston's APNIC analysis reported 4,651 additional IPv4 routes with AS22773 as the observed origin. It then evaluated those prefix-origin pairs against RPKI authorization data. Of the full set, 4,644 would have been classified Invalid by an RPKI-aware speaker. Seven did not have valid ROA coverage. [1] Those numbers do not show that every validating network behaved identically, but they identify a clear technical boundary: almost the entire observed set was susceptible to origin-validation rejection because the authorization record did not permit AS22773 to originate it.

That is positive control evidence. The authorization data existed independently of the event. Networks could fetch and validate it independently. Each network could then apply its own routing policy to the resulting validity state. A network rejecting Invalid routes did not need Cox to identify the mistake, publish a postmortem or ask that each route be filtered. The mismatch between the observed origin and the published authorization was machine-testable.

The same evidence also defines what cannot be claimed. The APNIC observer was deliberately configured not to discard the routes merely because they were Invalid. Its view therefore cannot be presented as the view of a typical validating network. Conversely, the classification does not prove that every network claiming to perform ROV had fresh data, applied rejection to every session, or prevented every route from being selected or exported. The result is a strong policy counterfactual, not a global census.

The distinction matters for accountability. If the event is described only as a leak that was "stopped by RPKI," the phrase hides the actors and decisions that produced the outcome. Resource holders had to publish accurate authorizations. RPKI repositories and validators had to make usable data available. Operators had to choose to validate and reject. Monitors had to preserve a non-validating view so the difference could be observed. Meanwhile, the originating network still had to control what it originated and exported. Containment emerged from independent layers, not from one automatic shield.

That layered result is the article's direct network-infrastructure nexus. Remove BGP origin, ROA data and local rejection policy, and both the event and the evidence comparison disappear. The accountability question is not attached to routing as an analogy. It follows from who controlled the announcements, who controlled the authorization entities, who controlled acceptance, and who retained enough evidence to test the containment claim.

A two-stage event seen from one vantage point

The timeline begins with the observer, not with an assumed internal change. APNIC reported a first large addition of about 3,365 routes between roughly 16:45 and 16:50 UTC. A second addition of about 1,141 routes followed between roughly 17:50 and 17:55. Broad withdrawals appeared later in two stages, with the largest changes around 21:30 to 21:45 and 22:30 to 22:40. [1]

Those figures should remain in their reported contexts. The two interval counts are broad observations of change, while 4,651 is the analysis's count for the additional route set across the event. They should not be forced into a new arithmetic decomposition or used to infer an undocumented third stage. The defensible statement is that the observer saw two dominant waves of additions, a total set of 4,651 additional origins, and two dominant waves of withdrawals.

Receipt time is also not action time. A BGP collector records updates after they have moved through routing relationships and policy decisions to reach it. The first update visible at 16:45 UTC is not proof that a Cox operator, automation system or router changed state at exactly 16:45. The last withdrawal visible around 22:40 is not proof that internal repair ended at that moment. The public timeline measures when one observer received routing information.

That caution does not make the timeline weak. The shape is operationally important. Thousands of origins arrived within a short interval, another large set arrived about an hour later, and broad removal occurred several hours after the first observations. The sequence is consistent with unintended export and subsequent correction, which is why the supplied analysis treats an accidental leak as probable. It is not evidence of malicious intent, and it does not identify the change that produced the announcements.

The two waves invite control questions without answering them. Did two policy paths activate separately? Did one configuration affect different route groups at different times? Did monitoring detect the first wave before the second? Were withdrawals staged by technical necessity, by separate devices or by separate policy groups? Nothing in the supplied record chooses among those possibilities. A responsible account can identify the questions because the timestamps make them measurable, but it cannot convert them into findings.

The withdrawals likewise show correction in the routing view, not durable remediation. Removing an erroneous announcement is necessary. It does not establish why the announcement was created, whether the responsible configuration was rolled back, whether a guard was added, whether a similar path remained elsewhere, or whether a tested repair prevented recurrence. A post-event record would need to connect observed withdrawals to internal change evidence.

This is where independent observation supports accountability. The operator controls its internal logs and change records. External monitors control separate evidence of what reached them and when it disappeared. When those records are compared, they can test statements about detection, response and propagation. Without the external record, the public would have only whatever timeline the origin chose to disclose. Without internal records, the observer can describe route visibility but not root cause.

What the 4,644 Invalid classifications mean

BGP supplies reachability information between autonomous systems. The protocol baseline describes how speakers exchange routing information and use attributes, including an AS path, to make routing decisions. It does not, by itself, prove that the origin at the end of a received path was authorized by the holder of the address space. [9]

RPKI adds a separate authorization layer. A Route Origin Authorization states that an AS is authorized to originate a covered prefix. Origin-validation specifications describe how a BGP speaker can compare an observed prefix and origin AS with validated authorization data and assign a validity result. [10][11] In this event, that comparison was decisive: the observer saw AS22773 as the origin, while the authorization state made 4,644 of the 4,651 additional routes Invalid to a validating speaker. [1]

Invalid is a precise result, but it is not a complete verdict on the route. It says the observed prefix-origin pair conflicts with the validated authorization state. It does not prove why the conflict occurred. A bad export, an unintended redistribution path, stale local policy or some other operational event may produce the mismatch. The public record here does not identify which one did.

Invalid also does not authenticate the complete AS path. A route can have an origin that is authorized while still being propagated in a way that violates intended business relationships. It can also have an unauthorized origin even if the visible path contains real AS numbers. ROV answers the origin-authorization question. It does not prove that every transit relationship, path segment or export decision was legitimate.

That boundary is why the seven uncovered routes matter. They did not share the same valid-ROA basis for an Invalid classification. The absence of that authorization coverage does not make them demonstrably legitimate, and it does not prove that networks accepted or used them. It means this particular containment mechanism could not reject them on the same Invalid basis. Different filters, route policy or operator decisions would have to carry the control burden.

The 4,644 figure is therefore evidence of authorization precision outside the leaking origin's own export system. Resource holders had published information that allowed a validating network to distinguish an unauthorized AS22773 origin from an authorized one. The value of that information became visible precisely because the origin event was wrong. A correct route and a wrong route may look similar at the level of ordinary BGP syntax; RPKI gives policy an externally verifiable authorization input.

APNIC also reported then-current ROA coverage of about 95.06 percent for Cox's advertised IPv4 prefix set. [1][2] That figure belongs in the record, but it must not be confused with the 4,644 classification. Cox's coverage metric describes authorization context for prefixes Cox advertised. The leaked set involved AS22773 appearing as origin for additional routes whose authorization state largely did not permit that origin. The containment depended on the relevant resource holders' authorization data and each receiving network's validation policy.

The associated APNIC Labs RPKI view can provide behavior context, while ARIN's RDAP record establishes the registration context for AS22773. [3][4] RIPEstat and Cloudflare Radar offer additional routing context for the ASN. [5][6] None of those current surfaces should be used as a substitute for a historical snapshot of 1 May. Dashboard state can change as routes, authorizations and measurement methods change. The event finding rests on the historical analysis and its observed update data, not on reading a current chart backward.

Containment is a policy counterfactual, not a global reach claim

The phrase "RPKI contained the leak" is defensible only when its terms are explicit. The APNIC observation point retained Invalid routes. A speaker using the same validated authorization state and a policy that rejects Invalid routes would exclude 4,644 routes from the usable set. The observed contrast demonstrates what the rejection policy could contain. It does not enumerate every network that applied that policy.

This difference separates receipt, classification, acceptance, selection and propagation. A router can receive an update from a neighbor and classify its origin state. Local policy then determines whether that update remains eligible. A rejected route may still be present in a diagnostic record even though it is not selected for forwarding or advertised onward. The APNIC evidence concerns routes retained by a non-rejecting observer and the classification they would receive under validation. It is not packet telemetry.

As a result, the analysis does not prove that traffic was diverted toward AS22773. It does not prove that a customer experienced loss, latency or reachability failure. It does not prove interception. It also does not prove that no user was affected. Those outcomes require traffic measurements, affected-network statements or service evidence that is not in the supplied record.

The same discipline applies to propagation. One observer's receipt proves that the announcements crossed enough policy boundaries to reach that observer. It does not establish global reach. It does not identify every neighbor that accepted the routes, every upstream that exported them, every route server that relayed them or every network that rejected them. A multi-collector replay could produce a broader propagation map, but that evidence is not supplied here.

NIST's RPKI monitoring methodology is relevant because validation measurements depend on data, vantage, timing and classification method. [7] A historical validity conclusion should bind the route view to the authorization state used for that time. A current validity check can be informative but may not reproduce what validators knew during the event. That is why historical ROA snapshots are part of the missing evidence.

NIST's practice guidance explains the architecture and the routing-integrity risks that origin validation is designed to address. [8] It can support the conclusion that unauthorized origins create a control problem and that ROV supplies a practical defense. It cannot turn the Cox event into a proven outage or loss event. General harm classes are not event-specific harm findings.

The strongest conclusion is narrower and more useful. The leak reached a deliberately non-validating observer. Nearly all of the additional prefix-origin pairs were incompatible with validated authorization data. Therefore, an operator rejecting Invalid routes had a concrete, locally enforceable basis to prevent those routes from entering its usable route set. The evidence supports material containment potential and probable real containment, while the exact network-by-network outcome remains unknown.

The confirmed harm is to routing integrity

Risk analysis often weakens when a dramatic mechanism is made to carry an unsupported impact claim. That is unnecessary here. The event has a confirmed harm even without evidence of an outage: routing information was contaminated by thousands of additional origins that the authorization system largely identified as Invalid.

Routing integrity matters because operators depend on received announcements to decide where prefixes are reachable. An erroneous origin creates exposure at every network that receives it without an effective rejection rule. The exposure is not identical to traffic diversion, but it is the precondition that can make a wrong route operationally available.

The non-validating observer demonstrates that exposure directly. Its policy preserved the announcements, showing that ordinary BGP propagation could carry them to that point. A network with comparable visibility but without Invalid rejection could have retained them as candidates. Whether it selected or exported them would depend on its other routes and policy. The public evidence does not resolve those downstream decisions.

This boundary prevents both understatement and exaggeration. Calling the event harmless because a large part of the Internet may have applied ROV would ignore the observed contamination and the seven routes without the same authorization coverage. Calling it a major outage would invent an outcome. The correct impact statement is that AS22773's additional origins created routing-integrity exposure, while accurate ROAs and local ROV policy provided a measurable containment layer.

The impact rating should therefore reflect control significance rather than assumed customer loss. The event tested an Internet routing safeguard against a large erroneous-origin set. It also showed the residual exposure of non-validating networks and uncovered routes. That is a meaningful infrastructure event even though the supplied sources do not establish a named victim or financial consequence.

Downstream success does not transfer the origin's duty

The most important accountability error would be to treat successful downstream filtering as permission for an originating network to rely on its neighbors. ROV is valuable because independent networks can protect themselves. That independence does not change who controlled the creation and export of the bad origins.

Cox controlled the systems and policies that caused AS22773 to appear as origin. The public record does not reveal the internal mechanism, but the control categories are clear: route creation, route redistribution, outbound policy, change deployment, monitoring, escalation, withdrawal and disclosure. Each category remains with the operator even when another network rejects the result.

An intended-prefix inventory is the first evidence unit. An operator should be able to state which prefixes each origin AS and each export context may announce. That inventory must be usable by policy generation and testing, not merely documented after the event. A change that would make an AS originate thousands of additional prefixes should be compared with the intended set before it reaches an external session.

Semantic testing is different from checking whether a configuration parses. A syntactically valid policy can still export the wrong routes. The relevant test asks what the resulting policy would announce after route redistribution, local transformations and session-specific rules are applied. A test should fail when the effective result exceeds the intended prefix and origin boundary.

Staged deployment is another origin-side control. A policy that changes route eligibility across many sessions should not need the global routing system to reveal its meaning. Bounded rollout, route-difference inspection and automatic stop conditions can expose a large origin-set change before it reaches every affected egress. The supplied record does not establish whether Cox used such controls.

Monitoring must look for semantic change, not only device health. A router can be available and a BGP session can remain established while the routes sent across it are wrong. An abnormal-origin alarm can compare the current originated set with an approved baseline. A maximum-change threshold can require review when thousands of routes appear. Independent monitors can confirm what escaped the network's own telemetry.

Response evidence then connects detection to withdrawal. The observed two-stage removal provides external timestamps. Cox's internal record could show when the anomaly was first detected, who owned the decision, which sessions or policies were changed, why withdrawal occurred in two broad waves and what checks confirmed completion. Without that record, the public can see correction in the route feed but not the control path behind it.

Disclosure is part of operational accountability because the origin owns facts that outsiders cannot recover from BGP alone. A post-event explanation need not expose sensitive configuration. It can identify the control class that failed, the scale of the unintended export, the detection source, the correction sequence, the safeguards added and the evidence used to test them. No Cox postmortem is present in the supplied record, so none of those details can be claimed.

ROA accuracy belongs to resource holders

The event also shows why authorization data is an operational control, not decorative registry metadata. The 4,644 Invalid results were possible because relevant resource holders had supplied authorization that did not permit AS22773 as origin. Their control action occurred before the leak, and downstream networks could consume it without coordinating with Cox during the event.

That produces a distributed responsibility model. A resource holder controls whether its ROAs accurately describe authorized origin arrangements. An RIR service and the wider RPKI publication system support availability of the signed material. Relying parties validate the data. Network operators decide how validation state affects routing policy. No single party controls the whole chain.

Accuracy is essential because an authorization error can create a different failure mode. An overly narrow, stale or otherwise incorrect authorization may cause a legitimate announcement to be classified Invalid. That inverse outcome is outside this article's event, but it explains why RPKI adoption must include change coordination and testing. The positive evidence here comes from authorization data that distinguished the erroneous origins; it is not a claim that every ROA is always correct.

The seven uncovered routes identify the residual. Where no valid authorization covers a route, an Invalid-rejection policy lacks the same basis to block the origin. That does not move responsibility away from the origin operator. It shows that resource-holder coverage and operator-side export controls solve different parts of the problem.

Historical evidence is therefore part of ROA governance. A current dashboard cannot conclusively show what authorization existed when an update was observed. Resource holders, repositories and monitors should preserve snapshots that allow a later reviewer to reproduce validity classification against the relevant time. In this event, a historical snapshot capable of testing the 4,644 and seven counts would strengthen the record.

Neighbor policy is a separate control surface

Peers and transit providers controlled what happened after the announcements left AS22773. Their controls included prefix filters, AS-path filters, ROV policy, maximum-prefix limits, abnormal-change alerts and onward-export rules. The fact that the origin was responsible for the bad routes does not make neighbor decisions irrelevant. A neighbor can either constrain or amplify an origin's error.

ROV is the clearest neighbor-side evidence in this case. A network rejecting Invalid routes had a direct reason to exclude 4,644 prefix-origin pairs. That policy protected the network and limited the routes available for onward propagation. It also reduced dependence on a manually maintained list of every prefix Cox was expected to originate.

Yet ROV alone does not settle every leak. Route-leak taxonomy recognizes that announcements can escape an intended relationship even when the origin itself is authorized. [12] In such a case, a prefix-origin pair may pass ROV while the path violates an export expectation. This event produced a large Invalid set, so origin validation was unusually effective. That success should not be generalized to every route leak.

Explicit prefix filtering remains relevant for the seven uncovered routes and for defense in depth. MANRS guidance places both prefix and AS-path filtering in the operator control set. [15] A provider that has a reliable view of what a customer may announce can reject routes outside that boundary. AS-path rules can also detect relationships or path contents that should not arrive from a given session.

Maximum-prefix controls are useful but incomplete. A threshold can detect a sudden route-count change, but a count alone does not prove that each route is authorized or intended. A high threshold may allow a large error; a low threshold may interrupt legitimate change. The stronger design combines count-based guardrails with authorization and relationship-aware policy.

Neighbor evidence would make the containment claim measurable. Each direct neighbor could report how many of the additional routes it received, how many it classified Invalid, how many it rejected, whether any were selected, and whether any were exported. Aggregated disclosure could preserve commercial confidentiality while showing the control outcome. No such neighbor-by-neighbor data is in the supplied record.

The accountability allocation is therefore asymmetric but shared. Cox retained primary responsibility for preventing erroneous origins and correcting them. Neighbors retained responsibility for protecting their own routing domains and limiting propagation. Resource holders retained responsibility for accurate authorizations. The success of one layer is evidence that layered controls work, not a reason for another layer to disappear.

Export and relationship safeguards address different failure classes

The standards record provides additional control classes without proving deployment. RFC 8893 addresses RPKI origin validation in the export context and directs attention to the effective origin after a network's local routing transformations. [13] That matters because a route can change meaning inside an operator before export. A check that occurs at only one intake point may not evaluate the prefix-origin result that an external neighbor will actually receive.

For AS22773, the relevant question is whether the effective exported origin and prefix set were compared with an approved and authorized boundary before the updates left the network. The public evidence cannot answer it. The standard shows that export-side validation is a recognized control option; it does not establish Cox's router capabilities, configuration or enforcement on 1 May.

RFC 9234 supplies a relationship-oriented control through BGP Roles and the Only-to-Customer mechanism. [14] These mechanisms help networks express session roles and identify announcements that should not be propagated in certain directions. They address a different dimension from origin authorization: whether a route's propagation is consistent with the relationship represented by the session.

That distinction matters because an operator can produce at least two broad error classes. It can originate a prefix it is not authorized to originate, which ROV can identify when authorization exists. Or it can propagate a route with an authorized origin beyond its intended relationship, which may require path and relationship controls. A robust routing design treats these as complementary checks.

MANRS filtering guidance makes the operational expectation explicit by including prefix and AS-path controls rather than reducing routing security to one validity flag. [15] The MANRS Observatory measurement framework also recognizes route leaks and the networks that enable propagation as measurable phenomena. [16] Measurement does not assign legal liability, but it can show whether an operator repeatedly originates, accepts or propagates anomalous routing information.

Peerlock research provides evidence that path-oriented defenses can constrain route-leak propagation. [17] Its relevance here is not that Peerlock was necessarily deployed by Cox or its neighbors. The supplied record does not say that. The research demonstrates that operators have control options beyond ROV when the path or relationship, rather than the origin authorization, carries the warning.

These control classes should not be collapsed. ROV checks origin authorization. Prefix filters compare announcements with an allowed set. AS-path filters inspect path content. BGP Roles and OTC communicate relationship expectations. Peerlock-style policy constrains paths involving protected networks. Maximum-prefix limits detect scale changes. Monitoring compares observed behavior with baselines. Each catches a different subset of failures.

Observation is both a control and an evidence function

The APNIC observer's decision not to reject Invalid routes may appear contrary to normal defensive policy. In a measurement system, it served a different purpose. By retaining announcements that a production network might discard, the observer preserved evidence of what was being emitted and propagated. [1]

That evidence function is essential. If every public vantage rejected the same routes before recording them, the routing community could know that the defense worked locally but lose visibility into the bad announcements themselves. A deliberately non-validating feed can expose the origin, prefixes, timing and withdrawal pattern needed to understand the event.

Production networks and measurement systems therefore have different valid objectives. A production operator may reject Invalid routes to protect traffic and reduce propagation. A monitor may retain them in an isolated analytical view to make anomalies observable. The monitor's choice is not evidence that production networks should accept the routes.

Multiple observation surfaces improve confidence. ARIN RDAP provides registry context for AS22773. [4] RIPEstat can supply independent ASN and routing context. [5] Cloudflare Radar provides another routing view. [6] APNIC Labs offers ROA coverage and RPKI behavior context. [2][3] NIST describes a methodology for RPKI monitoring. [7] The event-specific counts and timeline, however, come from the APNIC analysis, and current dashboards cannot replace that historical record.

An accountable monitoring design preserves both route updates and the authorization data used to classify them. It records collector identity, policy, clock basis and data freshness. It distinguishes routes received from routes selected. It also retains enough information to recompute the result when validity software or source data changes.

The same design should support rapid alarms. A new origin for thousands of prefixes is an observable event. Resource holders can monitor their own address space for unauthorized origins. An origin operator can monitor its announced set for unexpected growth. Neighbors can monitor accepted and rejected updates. Independent services can compare views and alert when propagation crosses expected boundaries.

The supplied record does not show who first detected the AS22773 anomaly or whether external observation preceded internal detection. That fact would materially affect the accountability analysis. If Cox detected the event from its own semantic controls, the evidence would support internal observability. If outsiders detected it first, the case for stronger origin-side monitoring would be more direct. The current record leaves that sequence unknown.

Accountability follows five control owners

The event can be allocated across five practical owners without pretending that each had equal power.

Cox and AS22773 controlled origin and export. This includes which routes entered an originated or redistributed set, which policies made them eligible for external sessions, how changes were reviewed, how abnormal growth was detected, how withdrawals were executed and what the company disclosed afterward. The observed origin makes this the primary prevention and explanation surface.

Resource holders controlled authorization accuracy. Their ROAs allowed validating networks to identify most AS22773 origins as Invalid. They also controlled whether uncovered prefixes remained outside this layer. Their responsibility is to keep authorization aligned with legitimate routing arrangements and to preserve change evidence.

Peers and transit providers controlled acceptance and propagation. Each network chose whether to validate, whether to reject Invalid routes, what prefix and path filters to apply, what thresholds to enforce and whether to export a received route onward. Their choices determined the event's reach beyond the origin.

Vendors and standards implementers controlled available safeguards. Router behavior, policy language, validation integration, effective-origin checks, BGP Roles and OTC support shape what operators can enforce reliably. Availability is not deployment, and deployment is not correct configuration. The public record establishes neither for Cox.

Independent monitors controlled public observability. Their route feeds, authorization snapshots and analytical methods determine whether containment claims can be tested. A monitor can show that a route arrived and how it classified at that vantage. It cannot supply Cox's internal trigger or traffic outcome.

This allocation avoids two common errors. The first is single-party simplification, in which every downstream acceptance is treated as the origin's action. Networks make independent policy decisions, so propagation control is shared. The second is responsibility dilution, in which shared control becomes no one's duty. Cox's neighbors could contain an error, but only Cox controlled whether AS22773 emitted it.

The evidence burden should track those powers. Cox could disclose intended-export and correction evidence. Resource holders and RPKI services could preserve authorization history. Neighbors could disclose aggregated rejection and propagation data. Vendors could document supported safeguards and tested behavior. Monitors could publish reproducible observations. No actor needs access to every other actor's internal system to prove the part it controlled.

Disclosure should make the control result reproducible

A strong post-event disclosure would begin with the observed route set and separate fact from inference. It would identify how many additional prefixes were originated, which export contexts were involved, when the operator first detected the change, and when corrective actions began. It would reconcile its internal timestamps with external receipt and withdrawal times.

The next section would identify the trigger without overstating blame. A redistribution rule, automation change, customer-session input, maintenance action or human configuration are all possible categories. The supplied record does not establish one. A disclosure should name the actual path and explain why existing review or guardrails did not stop it.

Control evidence should follow. The operator could show that the repaired policy produces only an approved prefix set, that effective origins are checked before export, that a large route-set increase triggers a stop, and that staged deployment prevents an equivalent change from reaching all external sessions. Test results are more useful than a general statement that procedures were improved.

Containment evidence should remain separate. Cox could request aggregated reports from direct neighbors showing Invalid rejection and any residual acceptance. Independent collectors could replay the event. Historical ROA data could reproduce the 4,644 and seven classifications. These records would quantify what external controls accomplished without rewriting them as origin-side prevention.

Impact evidence should also stay bounded. Traffic telemetry could show whether packets followed any erroneous route. Service records could show whether reachability or performance changed. Affected networks could report incidents. In their absence, the operator should not imply that successful ROV means no effect occurred, and critics should not claim an outage merely because a leak was observed.

Finally, remediation should be tied to recurrence tests. A route withdrawal ends the visible event. It does not prove that the responsible condition cannot recur. A durable account would identify the control added, the scenario used to test it, the scope of deployment and the ongoing metric that would reveal regression.

No such Cox disclosure is included in the supplied record. That absence does not prove that Cox failed to investigate or repair the issue internally. It means the public evidence cannot evaluate those actions. Accountability stops at the boundary of what can be shown.

Evidence map and claim limits

The reference supports different claims at different strengths. Keeping those roles separate prevents a standards document or current dashboard from being used as event proof.

Ref.	Evidence role	Supported use	Limit
[1]	APNIC event analysis	Date, observed origin, route counts, two-wave timeline, non-validating observer and Invalid containment comparison	One analytical vantage does not prove global acceptance, traffic outcome, Cox's internal trigger or remediation
[2]	APNIC Labs ROA dashboard	ROA coverage context for AS22773, including the then-current 95.06 percent figure reported with the analysis	A changing dashboard is not a complete historical snapshot of every leaked prefix
[3]	APNIC Labs RPKI view	Context about measured RPKI behavior associated with AS22773	Current behavior cannot prove policy on 1 May 2025
[4]	ARIN RDAP	ASN registration context for AS22773	Registry identity does not prove operational cause or intent
[5]	RIPEstat AS overview	Independent routing and ASN context	Current overview data does not reconstruct event propagation
[6]	Cloudflare Radar routing view	Additional independent routing context	A present dashboard is not a historical neighbor-by-neighbor acceptance map
[7]	NIST RPKI monitor methodology	How RPKI validation measurement depends on data and methodology	Methodology is not event-specific proof
[8]	NIST routing-integrity practice guide	ROV architecture and general harm classes associated with unauthorized origins	General risk does not prove a Cox outage, diversion or loss
[9]	RFC 4271	BGP protocol baseline	BGP exchange alone does not establish origin authorization
[10]	RFC 6483	ROA validation semantics	Authorization validation does not establish the full path or operational intent
[11]	RFC 6811	BGP prefix origin validation	Origin validation does not replace relationship and path controls
[12]	RFC 7908	Route-leak taxonomy	Taxonomy does not identify the specific internal trigger in AS22773
[13]	RFC 8893	Export-side origin validation and effective-origin control	The standard does not prove Cox deployed or correctly configured the mechanism
[14]	RFC 9234	BGP Roles and Only-to-Customer safeguards	Availability in a standard does not prove implementation on the event's sessions
[15]	MANRS filtering guidance	Prefix and AS-path filtering as operator controls	Guidance does not establish historical compliance by Cox or a neighbor
[16]	MANRS Observatory framework	Route-leak and propagation-enabler measurement concepts	A measurement framework does not assign event-specific legal fault
[17]	Peerlock research	Evidence that path-oriented defenses can constrain leak propagation	Research on deployment and effect does not show Peerlock was used in this event

This map leads to a clear hierarchy. Source [1] carries the event facts. Sources [2] through [7] supply measurement, identity and context, with temporal limits. Sources [8] through [17] explain control architecture, standards and available defenses. None of the latter can be substituted for a Cox postmortem or a multi-collector event reconstruction.

Evidence that would change the analysis

Several kinds of new evidence could materially alter the conclusion.

A Cox postmortem could identify the trigger, the responsible policy path, the detection source, the withdrawal sequence and the repair. It could strengthen the finding that the event was accidental, or show that some routes were intentionally generated in a bounded context. It could also reveal that an assumed control category was not involved.

A multi-collector replay could quantify actual propagation. It might show that the routes reached many non-validating networks, or that acceptance was far more limited than one observer's receipt suggests. Direct-neighbor records could identify where Invalid rejection worked and where it did not.

Historical ROA snapshots could reproduce or revise the 4,644 Invalid and seven uncovered classifications. Because authorization data changes, a time-bound archive is more probative than a current query. Any revision to those counts would change the measured containment boundary.

Traffic telemetry, service monitoring or affected-network statements could prove or refute user-visible harm. Evidence that traffic followed the additional routes would move the analysis beyond routing-integrity exposure. Evidence that the routes were never selected would narrow the impact. Neither result is available here.

Finally, evidence that the routes were authorized, deliberately originated or confined to a bounded test environment would challenge the leak characterization itself. The present pattern makes an unintended export probable, but probability is not a substitute for internal evidence.

Until one of those records appears, the disciplined conclusion is stable. AS22773 was observed originating 4,651 additional IPv4 routes. Nearly all had an authorization mismatch that an Invalid-rejecting speaker could enforce. The event demonstrates material RPKI containment capability and the value of accurate ROAs, while leaving global reach, traffic effect, trigger, intent and repair unresolved.

Containment is proof of a layer, not proof of a system

The 1 May event gives network operators a rare measurable comparison. The non-validating observer preserved thousands of routes. RPKI data classified 4,644 of them in a way that allowed validating networks to reject them locally. That is strong evidence that origin authorization can turn a routing error into a containable policy condition.

It is not evidence that RPKI validates the complete path, that all networks rejected the announcements, that the seven uncovered routes were harmless, or that origin and export controls can be delegated to neighbors. Nor does it prove a customer outage, interception, loss or regulatory breach.

The accountability result follows control. Cox controlled what AS22773 originated and exported. Resource holders controlled authorization accuracy. Neighbors controlled acceptance and propagation. Vendors controlled usable safeguards. Monitors controlled independent evidence. Each layer can prove its own action, and no layer can use another's success to erase its duty.

The most credible closeout would therefore be measurable: an intended-prefix inventory, tested export semantics, abnormal-origin alarms, staged deployment, neighbor rejection data, historical authorization snapshots, reconciled withdrawal timing and a public explanation of cause and repair. RPKI containment has already shown what one layer can prove. The unanswered question is whether the other control owners can produce evidence of equal precision.

Sources

Access checked: 2026-07-25