Summary

  • Cloudflare reported two distinct routing events on 27 June 2024. AS267613 began originating the more-specific route 1.1.1.1/32, while AS262504 leaked 1.1.1.0/24 upstream to AS1031. They affected the same resolver address but were not the same announcement, path or control failure [1].

  • The /32 was more specific than Cloudflare's normal /24 announcement. Cloudflare said multiple networks used it for forwarding even though its origin and prefix length made it RPKI invalid and unsuitable for the default-free zone. A tier-one provider reportedly accepted it as a remotely triggered blackhole route, causing traffic from that provider's downstream networks to be discarded [1].

  • The leaked /24 presented a different validation problem. Its path still ended at Cloudflare AS13335, so route-origin validation could regard the origin as valid even though the customer-to-provider and peer propagation path was unauthorized. A valid ROA does not authorize every intermediate AS relationship [1][2][6][9].

  • Cloudflare said it raised an internal incident at 20:03 UTC, disabled two peering points with AS267613, contacted the named networks and observed the /24 leak fully resolve at 02:28 UTC on 28 June. Reported user effects were either inability to reach 1.1.1.1 or high latency. Cloudflare also cautioned that the illustrated traffic represented a relatively small share of requests from the example source countries [1].

  • APNIC's independent commentary said the event was not globally visible and was probably marginal relative to the total Internet user base, although it may still have affected many users. Internet Society Pulse reported a broader observation footprint. Those descriptions should remain attributed rather than combined into an unsupported global-outage claim [2][3].

  • APNIC's allocation records and Cloudflare's ROA provide important evidence about the address block and authorized origin. They do not program import filters in other networks. Operational continuity depends on the policies actually enforced by origin networks, customers, route servers, transit providers and blackhole systems [4][5][6].

  • RFC 4271, RFC 7908, RFC 6811, RFC 8893, RFC 7454 and RFC 8212 define the BGP, route-leak, origin-validation and filtering context. RFC 9234 adds relationship-aware Roles and the Only-to-Customer attribute. RFC 7999 and RFC 3882 explain blackhole signaling and remotely triggered blackholing. These documents describe available controls, not proof that every involved network had deployed them [7]-[15].

  • RouteViews and RIPE RIS preserved public observations that helped reconstruct propagation. Collectors are evidence systems, not routing authorities. The accountability test is which party could prevent, reject, detect, contain or reverse each route, and what record proves that the control worked [16][17].

One address exposed several different control planes

The visual simplicity of 1.1.1.1 hides a chain of independent decisions. A user enters or configures one address. A local device sends a packet. A network selects a route. Transit providers compare alternatives. Route servers distribute announcements. Cloudflare's anycast sites advertise reachability. A registry records number-resource information, and RPKI can bind a prefix to an authorized origin. Each step answers a different question.

The incident matters because two bad paths could influence that chain in different ways. One was an origin announcement for a single address. The other was a leak of the covering /24. The first challenged origin and prefix-length authorization as well as blackhole controls. The second challenged relationship-aware export and customer-route filtering even though the route retained Cloudflare's origin at the end of the AS path [1].

Collapsing those events into a generic claim that "BGP failed" would remove the evidence needed to assign responsibility. BGP did what configured speakers and policies told it to do: distribute route information, compare attributes and select paths. The accountability failure lay in which routes were originated, which were accepted from customers or peers, which were exported onward, and which defensive signaling rules were allowed to discard traffic.

The same distinction prevents a second error. An address allocation or ROA can establish evidence about a resource and its authorized origin, but neither record reaches into every router. A network must fetch validation data, classify a route, connect that classification to policy and reject or de-preference invalid announcements. A route server or transit provider must also understand the commercial or operational relationship under which a path was received. Records support those decisions; running policy makes them real.

For a public resolver, the consequence is unusually visible. DNS queries are often the first dependency in an application session. If a client cannot reach its configured resolver, a browser may report that many unrelated names and services are unavailable. That does not mean the authoritative DNS for every destination failed. It means access to one recursive resolver address was impaired. Precise language is therefore essential: this was a reachability incident affecting 1.1.1.1, not evidence that the global DNS namespace stopped working.

The disclosed chronology keeps the two events separate

Cloudflare's published timeline begins at 18:51 UTC on 27 June, when AS267613 started announcing 1.1.1.1/32 to peers, providers and customers with AS267613 as the origin. One minute later, Cloudflare says AS262504 leaked 1.1.1.0/24, received through AS267613, upstream to AS1031. The disclosed path was 1031 262504 267613 13335. Cloudflare says AS1031 then propagated the /24 to Internet exchange peers and route servers [1].

At the same 18:52 point, according to Cloudflare, a tier-one provider received the /32 from AS267613 as an RTBH route. Traffic using that provider's route toward 1.1.1.1 was discarded. This is a separate causal path from the leaked /24: a provider acted on the host route as a discard instruction, while other networks learned the covering prefix through a leaked AS path [1].

Cloudflare raised its internal incident at 20:03 after reachability reports from multiple countries. At 20:08 it disabled a partner peering location with AS267613 that was receiving traffic for the /24, and it contacted AS267613. At 20:10, Cloudflare observed a new leaked path for the /24; it said traffic following that path reached Cloudflare but did so with high latency. At 20:17 it contacted AS262504 about the upstream leak [1].

The response continued beyond the first containment. Cloudflare says it disabled a second peering point with AS267613 at 21:56 because it was receiving traffic for the prefix from sources outside Brazil. At 22:16, another /24 leak attracted some traffic toward a Cloudflare peering point in Sao Paulo. The host-route hijack and blackholing appeared resolved by then, while some queries still returned with elevated latency. Cloudflare records full resolution of the /24 leak at 02:28 UTC on 28 June [1].

This sequence does not establish a single continuous experience for every user. Routes can flap. Different networks can accept different paths. Some traffic may be discarded, some may follow a long path to a working Cloudflare location, and some may remain on an unaffected path. Cloudflare described the user-facing outcomes as inability to reach 1.1.1.1 or successful reachability with high latency. Its example graphs covered Germany and the United States, not every source network [1].

The sequence also does not establish intent. Cloudflare uses the term hijack for the unauthorized /32 origin and identifies AS262504 as the leaking network for the /24. Those are technically meaningful descriptions of observed route state. The public sources in this record do not prove whether a person intended to divert, discard or disrupt traffic. Accountability can still be assigned to controls without converting an operational finding into a claim about motive.

Why a host route could override normal anycast reachability

Cloudflare normally advertises the covering 1.1.1.0/24 from many locations as part of its anycast service. Anycast allows the same address to be reachable through multiple sites, with BGP policy and topology influencing which site a network selects. The arrangement provides scale and proximity, but it still depends on the routing system selecting an authorized route.

IP forwarding uses longest-prefix matching. A route for /32 identifies one IPv4 address and is more specific than a route for /24, which covers 256 addresses. If both entries reach a forwarding table, the /32 wins for packets to 1.1.1.1 regardless of whether the /24 has a more attractive AS path. That mechanical rule explains why a host route can redirect or discard traffic for one address without replacing the covering route for every address in the block.

The default-free zone normally filters IPv4 routes longer than /24. Cloudflare reported seeing the /32 at multiple public collectors and in pre-policy BGP monitoring data from route servers. It said its own import policy rejected the route as both RPKI invalid and invalid for the default-free zone. The pre-policy observation remained valuable because it showed that a neighbor sent the update even though Cloudflare did not install it [1].

That distinction between receipt and acceptance is an accountability requirement. A route collector may record that a route was announced. A router's pre-policy telemetry may show that a neighbor sent it. An accepted-route table may show that import policy allowed it. A forwarding table may show that it became usable for traffic. Traffic measurements may show consequences. Each record answers a different stage of the path, and none should be substituted for all the others.

Cloudflare's ROA authorized AS13335 for 1.1.1.0/24 with a maximum length of /24. The 1.1.1.1/32 route originated by AS267613 therefore failed both the origin and maximum-length conditions described by origin validation. A network performing route-origin validation could classify the route as invalid and connect that state to rejection policy [1][6][9].

The operative word is could. RFC 6811 defines origin validation, not a universal deployment mandate. RFC 8893 explains terminology and operational considerations. A network can receive RPKI data but fail to apply it consistently. It can classify a route without rejecting it. It can create exceptions. A route server and its clients may apply different policies. The record proves that a validation basis existed; it does not prove how every network used it [9][10].

RTBH turned authorization into availability

Cloudflare's most consequential allegation about the /32 is that a tier-one transit provider accepted it as a remotely triggered blackhole route. RTBH is a legitimate and widely used defense. During a denial-of-service attack, a customer may ask a provider to discard traffic toward a destination before that traffic saturates the customer's connection. Sacrificing reachability to one target can preserve the rest of the service.

RFC 7999 defines a well-known BLACKHOLE community for signaling that a route should be discarded. It requires strict scope and filtering because the community's effect is destructive by design. RFC 3882 describes a remotely triggered blackhole technique in which a route and forwarding behavior are coordinated to drop traffic. Neither document means that any neighbor is entitled to request a discard for any address [14][15].

That is the accountability boundary exposed by this incident. A blackhole system must authenticate more than syntax. It should establish that the requesting party is authorized for the affected prefix, that the requested prefix length is permitted, that the neighbor relationship allows the request, that the community is removed or constrained at the proper boundary, and that the action is observable and reversible.

A provider that accepts a /32 blackhole route from an unrelated party can make an invalid origin operationally effective even if ordinary unicast route policy would have rejected it. The defensive path becomes a bypass around normal authorization. Cloudflare's account says precisely that occurred: AS267613 was not authorized to blackhole 1.1.1.1, yet a tier-one provider accepted the instruction and discarded downstream traffic [1].

The lesson is not to abandon RTBH. Without it, operators facing a high-volume attack may have fewer options to protect network capacity. The lesson is to treat discard authority as a privileged capability. It needs explicit customer-prefix bindings, validated maximum lengths, restricted communities, auditable activation, expiry or withdrawal handling, and monitoring that compares the requested discard with registry and RPKI evidence.

The exact private policy of the unnamed provider is not in the public record. It would be wrong to infer whether the provider used RFC 7999's well-known community, a private community or another mechanism. Cloudflare reported the result as RTBH. The defensible accountability question is what evidence the provider required before converting the received route into a discard action, not which unverified configuration line it used.

The /24 leak passed an origin test but failed a path test

The leaked 1.1.1.0/24 illustrates the complementary limit of route-origin authorization. In Cloudflare's disclosed paths, AS13335 remained the rightmost origin. If a validator asks only whether AS13335 may originate the /24, the answer can be valid. That does not answer whether AS267613 should export the route to AS262504, whether AS262504 should export it to AS1031, or whether AS1031 should distribute it to peers and route servers [1].

BGP's AS path is both a loop-prevention mechanism and evidence about propagation. It is not a signed commercial contract. A path containing an authorized origin can still violate expected customer-provider or peer relationships. RFC 7908 defines route leaks as propagation beyond an intended scope and provides a taxonomy for common relationship failures [8].

Cloudflare's account analyzes an example path and identifies the critical transition at AS262504. It describes AS267613 as functionally a peer of Cloudflare and AS262504 as a customer of AS267613. On that account, AS262504 received the Cloudflare route through its provider side and then announced it upstream to AS1031. Cloudflare says AS1031 accepted the route from its customer and redistributed it across multiple peering locations [1].

These relationship claims come from Cloudflare's analysis and should remain attributed. They nevertheless expose concrete controls. A provider can maintain an explicit list of prefixes a customer is authorized to originate or announce. It can use RPKI origin state, Internet Routing Registry data and observed customer cone information as evidence. It can cap the number of routes accepted, reject unexpected origin or path patterns, and stop a customer from becoming transit for arbitrary Internet routes.

RFC 7454 describes BGP operational practices, including filtering routes received from customers and peers. RFC 8212 changes a dangerous historical default by requiring explicit import and export policy for eBGP routes in conforming behavior. These measures reduce accidental openness, but they do not automatically detect that an explicit customer policy is too broad. A filter that merely checks the adjacent AS can still accept a route that the customer was not authorized to propagate [11][12].

This is why AS1031 matters in Cloudflare's account. The original leak may begin at a customer, but the radius depends on who accepts and redistributes it. A transit or exchange operator is not responsible for every error inside every customer. It is responsible for the acceptance and export controls within its own boundary, the evidence those controls use, and its ability to withdraw or contain a bad route once notified.

Roles and OTC add relationship evidence

RFC 9234 addresses route leaks with BGP Roles and an Only-to-Customer attribute. Roles allow two eBGP speakers to describe their relationship, such as provider, customer, peer or route server. OTC can mark a route so that a receiving network can detect propagation inconsistent with those roles [13].

This control targets a question RPKI origin validation does not: where a route may travel after an authorized origin announces it. In simplified terms, a route learned from a provider or peer should not be offered to another provider or peer as though the network were authorized transit. Relationship metadata can make that rule machine-checkable at adjacent boundaries.

OTC is not retrospective proof of what happened in June 2024. The public record used here does not establish whether AS267613, AS262504, AS1031, their route servers or the affected downstream networks negotiated Roles or enforced OTC. The standard is useful as a control reference because it identifies an enforceable boundary that matches the failure class. It must not be described as a control known to have failed in this event.

Role metadata also cannot replace basic customer filtering. A network still needs to know which prefixes, origins and route volumes are plausible for a customer. It needs exception handling that does not silently become a permanent bypass. It needs monitoring for sudden changes and a contact path that reaches an operator able to withdraw the routes.

The strongest design uses several independent checks. Origin validation asks whether the origin is authorized. Prefix filtering asks whether this customer may announce the resource. Role and OTC checks ask whether the route traveled through a permitted relationship. Maximum-prefix controls detect gross changes in volume. Path anomaly systems compare an update with expected topology. None is perfect; together they reduce the chance that one mistaken or malicious announcement becomes widely usable.

Allocation and ROA records are evidence, not remote control

The history of 1.1.1.0/24 makes the recordkeeping layer especially visible. APNIC's prop-109 allocated 1.0.0.0/24 and 1.1.1.0/24 to APNIC Labs as research prefixes. The policy material describes address blocks that had attracted substantial unsolicited traffic because they had long been used in examples and private configurations. APNIC later entered the arrangement under which Cloudflare operates the 1.1.1.1 resolver service [2][4][5].

The allocation record answers who holds and administers a number resource under the registry system. Cloudflare's ROA answers which origin AS is authorized for the prefix and what maximum prefix length is covered. These are durable evidence objects. They support automation, dispute resolution and post-incident reconstruction. They do not make a packet flow toward Cloudflare by themselves.

That distinction matters because the word ownership can obscure operations. An address block is not protected by a declaration alone. Routers around the Internet receive updates from neighbors and apply local policy. A registry cannot directly stop an unrelated router from announcing a route. A relying network must retrieve and validate the record, decide what invalid or unknown means for its risk model, and enforce that decision in running configuration.

The same is true during recovery. Updating a registry object without withdrawing the bad route does not remove it from forwarding tables. Withdrawing a route without preserving collector and configuration evidence may restore service while weakening the investigation. Effective accountability links the record and the running state: the prefix, authorized origin, observed path, neighbor, policy decision, selected route, forwarding outcome and withdrawal time.

This is the practical value of a registry-as-ledger model. It does not diminish registry integrity. It gives registry data a precise role: unique and accurate resource records, transfer history, security metadata and a basis for validation. It also prevents the registry from being blamed for every local policy decision it cannot execute, while making networks answer for ignoring records they could have used.

Collectors show propagation, not every forwarding decision

Cloudflare used public route collectors to illustrate sightings of the /32 and /24. RouteViews and RIPE RIS receive BGP feeds from participating networks and preserve updates and table snapshots. Their data helps establish when a route was visible at a collector, which peer sent it, what AS path and attributes were recorded, and when a withdrawal or replacement appeared [1][16][17].

That evidence is indispensable but bounded. A collector sees the view its peers export. It does not see every route in every network. A BGP update does not prove the receiving router installed the route as best. A selected control-plane path does not prove every packet followed it. A missing update may mean the route was filtered, not exported to the collector, or outside the collector's visibility.

Those limitations do not make collectors weak evidence. They make the claim precise. Collector data can corroborate that an announcement escaped a private boundary and reached external observers. It can show propagation paths and timing. It can support alerting when a protected prefix gains an unexpected origin or path. It can verify that withdrawals become visible after mitigation.

Service operators should combine external observations with internal telemetry. Pre-policy monitoring shows what neighbors sent. Post-policy route tables show what was accepted. RIB and FIB state show control-plane selection and forwarding installation. Flow, latency and loss data show consequences. Peering and ticket records show response. The evidence chain becomes stronger when timestamps and identifiers let those layers be correlated.

Collectors also enable independent scrutiny. Cloudflare's post is the principal source for its response and the private effects it observed. RouteViews and RIPE RIS are separate public infrastructures. Agreement between operator telemetry and collector observations can strengthen a chronology, but public data cannot reveal private intent, every customer effect or the full internal decision process.

Impact was real but not uniform or globally measured

Cloudflare said affected users either could not reach 1.1.1.1 or could reach it only with high latency. The blackhole route explains one failure mode: traffic was discarded before reaching Cloudflare. The leaked /24 explains another: traffic could travel toward Brazil and eventually reach a Cloudflare location over a path far longer than the normal anycast choice [1].

Cloudflare's example graphs for Germany and the United States show traffic landing at Brazilian data centers during parts of the event. It cautioned that the plotted traffic could represent a relatively small share of total requests in each source country. That caveat should travel with the graph. It would be misleading to infer that most users in either country were affected [1].

APNIC's commentary says the event was not globally visible and was probably marginal relative to the total Internet user base, even while acknowledging that a large absolute number of users may have been affected. Internet Society Pulse described observations across numerous networks and countries. Different visibility systems, definitions and vantage points can produce different scope descriptions [2][3].

A responsible account keeps those statements separate. It does not average them, select the largest number as the definitive impact or transform network observation into a user count. The available public record does not supply a complete denominator, a full list of affected access networks, query-failure totals or independently verified financial loss.

The absence of a global measurement is not an absence of accountability. A control can be material even when only a minority of users encounter it. 1.1.1.1 is a critical dependency for those who configure it. A tier-one blackhole can affect all downstream paths that rely on that provider for the address. A route-server leak can spread beyond the originating networks. The proper standard is proportional evidence: measure what can be measured, state what remains unknown, and do not let uncertainty erase the controls that clearly mattered.

Cloudflare's containment showed the limits of unilateral action

Cloudflare's immediate controls were operational rather than declarative. It raised an incident, disabled peering points that were drawing traffic toward the wrong path, contacted the named networks and monitored the route state until the /24 leak resolved. Those actions could reduce exposure within Cloudflare's boundary and apply pressure through operational coordination [1].

They could not directly edit another network's router. Disabling a peering location changes where Cloudflare exchanges traffic, but it does not automatically withdraw a route originated or propagated elsewhere. The stale path toward Sao Paulo remained visible after earlier containment, according to Cloudflare. Full resolution required action by the networks responsible for the announcements [1].

This division of control is why incident response needs reliable contacts and evidence packages. A useful notification identifies the prefix, observed origin and path, collector and timestamp, expected authorization, effect, and requested action. It should reach a network operations team rather than disappear into a generic mailbox. The recipient should be able to confirm withdrawal and explain the policy correction without exposing unrelated confidential configuration.

Cloudflare also had a responsibility to monitor a highly visible service from diverse vantage points. The public timeline shows more than an hour between the first disclosed announcement and the internal incident at 20:03. That interval alone does not prove a monitoring failure: the public record does not say when impact crossed an alert threshold, which signals were available, or whether earlier events were visible to Cloudflare's systems. It does define a question for review: what observation should have detected the unexpected origin or path, and how quickly should it have escalated?

A strong post-incident record would therefore include time to first external observation, time to internal detection, time to incident declaration, time to first containment, time to responsible-network contact, time to host-route withdrawal, time to leak withdrawal and time to verified service recovery. These measures correspond to different owners. Combining them into one "resolution time" would hide where delay accumulated.

Prevention must be evaluated at each boundary

The originating boundary for the /32 should prevent an AS from announcing a host route for an address it is not authorized to originate. Candidate configuration validation can compare intended prefixes with registry, IRR and RPKI data before activation. Export policy can restrict announced prefixes by neighbor and service. A maximum prefix length can stop a /32 where only a /24 is authorized. Post-change monitoring can compare actual Adj-RIB-Out with the approved set.

The receiving boundary should reject implausible or unauthorized routes. RPKI origin validation supplied a clear invalid state for the /32. Default-free-zone prefix-length filters supplied another signal. Customer-prefix authorization supplied a relationship check. A network that accepted the route should be able to show which rule allowed it and whether an exception bypassed ordinary rejection.

The RTBH boundary needs its own authorization table. A provider may permit a customer to blackhole only prefixes associated with that customer, within agreed maximum lengths, through designated sessions and communities. Activation should be logged with the requesting neighbor, route, validation state, scope, timestamp and expiry. An invalid origin or unrelated prefix should fail closed rather than become a discard route.

The /24 propagation boundary requires customer and role controls. AS262504's export policy should have prevented a provider-learned route from being sent to another provider if Cloudflare's relationship analysis is correct. AS1031's customer policy should have rejected a route outside the customer's authorized set or inconsistent with the relationship. Route servers should apply or enable controls appropriate to their operating model, and participants should not assume that a route server makes every client route safe.

The service boundary requires diverse reachability probes and route-security alerts. A resolver operator can monitor query success, latency, route origins, more-specific announcements and unexpected AS paths from multiple regions. It can correlate those signals so that a routing anomaly affecting a known service address is not treated as an application-only issue.

Finally, the evidence boundary requires retention. Configuration versions, validation results, BGP updates, RIB decisions, FIB state, blackhole activations, collector observations, peering changes and incident communications should share stable timestamps. Without that chain, operators may restore service but be unable to explain which control failed or prove that the correction addresses the failure class.

Detection should distinguish bad origin, bad path and bad action

A single "route anomaly" alert is not enough for this incident. The /32 could trigger an unexpected-origin alert, an RPKI-invalid alert and an excessive-prefix-length alert. The /24 might not trigger the first two because AS13335 remained the origin and the prefix length was valid. It needs path-relationship or customer-authorization analysis.

The blackhole action adds another layer. An RTBH system should alert when a discard route is requested by a neighbor not authorized for the prefix, when the route is RPKI invalid, when its length exceeds the customer's allowance, or when the discard would affect a high-value shared service. A route can be invalid for ordinary forwarding and still be accepted by a specialized mitigation path if that path lacks equivalent authorization checks.

These alerts should preserve their basis. "RPKI invalid" should record the validated prefix, origin, maximum length and validator state. "Customer unauthorized" should identify the approved prefix set and its source. "Role violation" should identify the expected relationship and observed export. "Unexpected blackhole" should identify the signaling community or mechanism and the scope applied.

Alert quality matters because false positives can encourage exceptions that later become permanent bypasses. Operators need bounded, explainable evidence and a way to update authorization safely. That is another reason no single database should be treated as unquestionable sovereignty. Registry, RPKI, customer contracts, operational topology and observed routing state are separate records that must be reconciled.

Containment and recovery need independent proof

Containment for the host route means stopping its origination, removing it from blackhole and forwarding policy, and confirming withdrawals at external vantage points. Containment for the /24 leak means stopping the unauthorized export at AS262504 and onward propagation at AS1031 and other networks. Cloudflare's peering changes reduced the traffic paths under its control but were not substitutes for those withdrawals.

Recovery should be demonstrated at three layers. Route state should return to authorized origins and paths. Forwarding should send traffic to intended Cloudflare anycast locations rather than discard it or detour it. Resolver service measurements should show normal success and latency. A green application dashboard without route verification could miss a lingering abnormal path; a clean route table without user measurements could miss a service problem.

The correction also needs durability. The source network should explain what prevented the /32 from being originated again. The leaking network should bind exports to relationship policy. The amplifying network should correct customer acceptance and redistribution. The RTBH provider should ensure that an unrelated neighbor cannot authorize a discard for the prefix. Cloudflare should test that its monitoring detects the same signatures sooner.

Public evidence does not establish which of those changes were deployed. Cloudflare says it engaged the networks about prevention mechanisms and discusses RPKI, RTBH authorization, OTC and ASPA as relevant directions [1]. Those proposals are useful, but a proposed or discussed control is not a verified remediation. Accountability requires a test result tied to the failure condition.

A bounded accountability matrix

The originating AS for the /32 controlled whether the host route was created and exported. Its evidence should include approved prefix lists, configuration change records, Adj-RIB-Out and withdrawal confirmation. The public record identifies the observed announcement but does not disclose the internal cause or intent.

AS262504 controlled whether the /24 learned through one relationship was exported upstream. The relevant evidence is neighbor role, import source, export policy, route authorization and post-incident correction. Cloudflare calls it the leaking network; a fuller internal account is not in the public record used here [1].

AS1031 controlled customer-route acceptance and redistribution at its boundary. The relevant evidence is the authorized customer prefix set, filtering policy, route-server or exchange design, maximum-prefix handling, RPKI and relationship checks, and withdrawal response. Cloudflare attributes broad amplification to AS1031; the article does not infer private configuration beyond that published analysis [1].

The tier-one provider controlled whether a received route could invoke RTBH and how far the discard applied. The key evidence is customer authorization, route and prefix-length validation, community scope, activation logs and withdrawal. Cloudflare does not name the provider in the source used here, so the analysis should not speculate about its identity [1].

Cloudflare controlled its ROA, import policy, service monitoring, peering response, customer communication and public disclosure. It says it rejected the /32 on its own import and disabled affected peerings during containment. The review question is whether route and service monitoring could have shortened detection and whether external coordination and recovery evidence were sufficient [1][6].

APNIC and the RPKI system controlled record integrity within their defined roles. The allocation and authorization records supplied evidence that could support rejection. They did not control every relying router. Their accountability is accuracy, availability and secure publication of records, not direct responsibility for another operator's acceptance policy [4][5][6].

RouteViews and RIPE RIS controlled collector operations and evidence publication. They helped make external propagation inspectable. They did not authorize the routes, select them for customer forwarding or withdraw them. Their value is an independent reality check on what parts of the routing system exposed [16][17].

What the standards can and cannot prove

RFC 4271 explains the BGP mechanism by which autonomous systems exchange reachability. It does not assign liability for this event. RFC 7908 supplies route-leak categories, but classification depends on relationship facts that may be private or disputed. RFC 6811 and RFC 8893 explain origin validation, while actual rejection remains local policy [7]-[10].

RFC 7454 and RFC 8212 establish strong reasons for explicit filters and policies. They do not prove that a particular operator had no policy, and they do not guarantee that an explicit policy is narrow enough. RFC 9234 provides Roles and OTC, but the source record does not establish deployment by the incident participants [11]-[13].

RFC 7999 and RFC 3882 show that blackholing is an intentional network-control mechanism with serious scope and authorization requirements. They do not identify the exact signaling implementation used by the unnamed tier-one provider. The incident-specific claim remains Cloudflare's attributed report that the /32 was accepted as RTBH [1][14][15].

Standards are therefore best used as control maps. They help ask whether an operator had explicit policy, validated origins, bounded customer announcements, encoded relationships, restricted blackhole authority and retained evidence. They should not be used to invent a post-incident audit that the public record does not contain.

The route-propagation accountability test

The June 2024 incident demonstrates why Internet accountability cannot stop at resource ownership. APNIC's records and Cloudflare's ROA supplied strong evidence. Cloudflare's own import policy reportedly used that evidence to reject the /32. Other networks still accepted, propagated or acted on routes that should not have controlled reachability to 1.1.1.1 [1][4][5][6].

Nor can accountability stop at the first bad announcement. The /24 leak acquired its radius because subsequent networks accepted and redistributed it. The tier-one blackhole acquired its effect because a defensive mechanism treated an unauthorized route as a discard request. Each boundary converted information into operational state.

A practical test follows five questions.

First, prevention: could the operator prove before activation that the neighbor was authorized to originate, propagate or blackhole this prefix at this length?

Second, rejection: did running policy use origin, prefix, customer and relationship evidence to reject an invalid or out-of-scope route?

Third, observation: could internal telemetry and independent collectors show when the route was received, accepted, exported, selected and withdrawn?

Fourth, containment: could the operator stop its own propagation or discard action without waiting for every other network, and could it reach the parties controlling the remaining bad state?

Fifth, recovery: did route state, forwarding and resolver performance return to normal, and did a repeatable test show that the same authorization failure could no longer pass?

These questions do not require a claim about motive. They assign responsibility to practical control. The origin network answers for its exports. Customers and providers answer for relationship policy. A blackhole operator answers for discard authorization. A service operator answers for monitoring and containment. Registries and RPKI publishers answer for trustworthy evidence. Collectors answer for the integrity and limits of their observations.

The result is a reality-layer standard. The authoritative state is not the narrowest public promise or the most confident ownership claim. It is the route that running routers accepted, the forwarding action they installed, the traffic outcome users encountered and the evidence that made those facts inspectable.

Cloudflare's 1.1.1.1 incident did not show that one control is useless. It showed why several controls must interlock. Origin validation could reject the /32 but not the leaked path with a valid origin. Relationship policy could constrain the /24 but would not by itself authorize RTBH. Allocation records established resource context but could not enforce filters. Collectors exposed propagation but could not withdraw it.

The enduring accountability requirement is therefore exact: every network that can turn an announcement into reachability or discard must be able to show why the route was authorized, what evidence it used, how quickly it detected a contradiction and how it proved the correction. Anything less leaves a familiar address dependent on controls that exist on paper but not in the path packets actually take.

Sources

  1. https://blog.cloudflare.com/cloudflare-1111-incident-on-june-27-2024/
  2. https://blog.apnic.net/2024/08/02/when-routing-breaks-your-open-dns-service/
  3. https://pulse.internetsociety.org/en/news/2024/07/cloudflare-dns-outage-traced-to-bgp-hijacking-incident/
  4. https://www.apnic.net/community/policy/proposals/prop-109/
  5. https://www.apnic.net/wp-content/uploads/prop-109/assets/prop-109-v001.txt
  6. https://rpki.cloudflare.com/?prefix=1.1.1.0%2F24&view=explorer
  7. https://www.rfc-editor.org/rfc/rfc4271
  8. https://www.rfc-editor.org/rfc/rfc7908
  9. https://www.rfc-editor.org/rfc/rfc6811
  10. https://www.rfc-editor.org/rfc/rfc8893
  11. https://www.rfc-editor.org/rfc/rfc7454
  12. https://www.rfc-editor.org/rfc/rfc8212
  13. https://www.rfc-editor.org/rfc/rfc9234
  14. https://www.rfc-editor.org/rfc/rfc7999
  15. https://www.rfc-editor.org/rfc/rfc3882
  16. https://www.routeviews.org/routeviews/
  17. https://ris.ripe.net/docs/