Angola Cables' 2023 Route Leak Accountability Test

Summary

The bounded event is the 25 May 2023 BGP route leak associated with Angola Cables AS37468. The Mutually Agreed Norms for Routing Security initiative and Internet Society Pulse described the incident as slowing connectivity for many Australian users reaching sites in the United States, including AWS and Akamai services [1][2].
The article is not a corporate profile of Angola Cables, not an article about the 2024 West Africa submarine cable faults, and not a broad cloud outage story. It is about how a routing-path failure becomes an accountability problem when export scope, import policy, relationship evidence and public observation do not line up.
BGP tells networks where to send traffic for destination prefixes. It does not, by itself, prove that a neighbor was authorized to advertise every path it sends. A route leak is dangerous because a route can look syntactically valid while still crossing a business or operational boundary that should have stopped it [9][10].
RPKI origin validation can say whether a prefix has a Route Origin Authorization, or ROA, permitting a particular autonomous system to originate that prefix. It is useful evidence, but it does not validate the whole AS path. A path leak can still require relationship-aware policy, import and export filters, role evidence, route collector review and operator records [13][15].
AS37468 identity evidence from bgp.tools, AFRINIC RDAP and PeeringDB can bind the route-leak discussion to a real network operator and public registry context. Those records are not blame evidence. They are ledger records for the number resource and interconnection surface [4][5][6].
A serious closeout would need more than a restored route table. It would need the intended export set, actual Adj-RIB-Out samples, accepted-route logs at neighbors, route-collector timelines, RPKI and IRR validation state, withdrawal evidence, customer-impact bounds and a repair control that can be tested later.

What happened

The public event record points to a BGP route leak on 25 May 2023 associated with Angola Cables AS37468. Internet Society Pulse and MANRS described the visible consequence in plain terms: Australian users saw significantly slower connectivity when reaching sites in the United States, and the affected destinations included services associated with AWS and Akamai [1][2]. That framing matters. The problem was not that a submarine cable had been cut or that every affected cloud service failed on its own. The problem was that routing information caused traffic to prefer or encounter a path that did not match the intended scope of the route.

BGP is often described as the Internet's routing protocol, but that shorthand hides the most important governance issue. BGP is not a central permission system. Each autonomous system, or AS, receives advertisements from neighbors, applies local policy, chooses a path and may export that route to other neighbors. If a network sends a route beyond the role in which it learned or should have used it, other networks can accept the advertisement and carry traffic through a poor or unintended path. The wrong advertisement can then produce a real user experience: delay, instability, unreachable services or visible application errors.

For this event, the source capsule is narrow. The candidate is Angola Cables' 2023 route leak, not Angola Cables' broader business, not later cable damage off West Africa, and not a general complaint about transoceanic connectivity. The accountable surface is the route-policy boundary. Which routes were exported? Which neighbors accepted them? Which paths were selected? Which controls could have stopped the propagation? Which records can prove the condition was withdrawn and fixed?

The fact that Australian users noticed a United States path problem is itself a signal. A domestic user reaching a foreign service may cross many networks: an access network, a domestic transit provider, an international carrier, a content network or cloud edge, and sometimes a route optimizer. A leak can insert an unexpected detour or make a remote path more attractive than it should be. Even if the destination service remains healthy, the selected path can become slow enough that users experience the failure as a service outage. That is why route leaks are not merely operator housekeeping.

They can turn an invisible control-plane error into public harm.

The public sources do not disclose the exact router command, internal ticket, full accepted-prefix set, or every affected flow. They also do not prove intent. It would be careless to turn a route collector observation into a claim that a particular engineer deliberately caused damage. It would be equally careless to treat the absence of private records as an excuse to ignore the route leak. Accountability starts with the observed control-plane state and asks what evidence a responsible operator should be able to produce.

Why this was a path-validation problem

Many routing-security discussions start with origin validation. Origin validation asks whether the AS that originates a prefix is authorized by a ROA to originate it. That question is important, but it is narrower than the Angola Cables event. A route leak is about where a route travels and under which relationship it is exported. The origin may be valid, invalid, unknown or irrelevant to the propagation error. If the path violates intended scope, origin validation alone cannot describe the whole failure.

RFC 7908 gives the useful mental model. A route leak is a propagation mistake. A route learned in one relationship may be advertised into another relationship in a way that violates the intended policy. In commercial terms, a route learned from a provider or peer might be leaked to another provider or peer. In operational terms, a route that should have remained within one scope escapes and becomes visible somewhere it should not be. The damage comes from the mismatch between advertised reachability and intended routing relationship [10].

Path validation is harder than origin validation because it depends on relationships, roles and policy. A ROA can say, in effect, that AS X may originate prefix Y. It does not say whether AS A should export a path learned from AS B to AS C. It does not prove whether the route passed through a customer, peer or provider relationship correctly. It does not tell downstream networks whether the selected path will add a long detour or move traffic through an unexpected continent. Those questions require policy evidence.

The Angola Cables event therefore asks a layered question. Did AS37468 export routes outside the set it intended to export? Did a neighbor accept and propagate those routes without a relationship-aware filter? Did downstream networks select the route because of local preference, AS path length or lack of more specific policy? Did public collectors show the path in enough places to reconstruct the propagation? Did the route withdraw cleanly? Did the operators change controls so the same class of leak would fail closed next time?

That is the accountability test. A routing incident is not closed just because the path disappears from a looking glass. The operator has to show why it disappeared, who removed it, what prevented recurrence, and whether the repair is observable from outside. Otherwise the public record only shows that the bad condition ended, not that the system learned from it.

The role of AS37468 identity records

AS37468 is the public autonomous-system identifier bound to Angola Cables in the evidence package. bgp.tools provides a convenient public routing-context page. AFRINIC RDAP provides registry data for the autnum resource. PeeringDB provides voluntary interconnection context, including how an operator presents its peering surface to the market [4][5][6]. Those sources matter because accountability requires a stable object. Without an ASN, the article would drift into a brand story. With an ASN, the discussion is anchored to a routing entity.

The registry point is also a Heng.lu doctrine point. A registry is a ledger and recordkeeper for number-resource claims; it is not a sovereign verdict on every operational act. The fact that AFRINIC has an RDAP record for AS37468 does not prove negligence, innocence or the exact route policy used on 25 May 2023. It proves the public resource identity around which other evidence can be organized. That is enough for an accountability article, provided the article keeps the line clear.

PeeringDB has the same limitation. It can help describe the operator as an interconnection participant. It can show where a network advertises peering posture, contact style and exchange presence. It cannot prove a specific route leak by itself. A PeeringDB page is not a router log. It is useful because route leaks are relationship events: who learned from whom, who exported to whom, and what the parties were supposed to do with those routes.

A good evidence chain uses these records for their proper role. AS37468 identity binds the event. RDAP confirms the number-resource context. PeeringDB helps orient the interconnection surface. Route collectors and incident reports show visible routing state. RFCs and MANRS guidance provide the control map. None of those sources alone is a complete postmortem. Together they define the questions that a postmortem must answer.

The deletion test is simple: remove BGP, AS37468, route propagation, collectors and transit policy from the article, and the accountability thesis collapses. What remains would be a generic connectivity story. Daniel Kade's target is narrower. The point is not that Angola Cables exists or that traffic between continents can be slow. The point is that a named autonomous system and its neighbors sit inside a public routing fabric where mistakes can be externally observed and should be externally accountable.

Why route collectors help but do not decide the case

RouteViews and RIPE RIS are public route-collector systems. They receive BGP data from participating peers and make it possible to study what routes were visible from those vantage points [7][8]. They are essential for outside accountability because they give researchers an independent view of the control plane. Without collectors, the public would depend almost entirely on private operator statements.

Collectors are not perfect evidence. A collector sees what its peers send it. It may not see every route used by every network. It does not necessarily show the path that a specific end user's packet selected. It cannot reveal a private route-map, a rejected route, an internal exception or a customer contract. It can also include update churn that needs careful interpretation. An announcement observed at one collector is a data point, not a universal truth.

That limitation does not weaken the need for collector evidence. It makes the evidence discipline stronger. If Pulse and MANRS report a slowdown and a route leak, the next responsible step is to preserve the collector timeline: when the anomalous route appeared, which AS path was visible, how many collectors saw it, when withdrawals arrived, and whether the route reappeared. That timeline can be compared with operator logs. Public observation and private records should converge.

For a route leak that affected paths from Australia to the United States, geographic and topological diversity matters. A collector near one region may see a route that another collector never sees. An Australian access provider may select a different path than a European transit provider. AWS and Akamai destinations may be reached through different interconnection choices. A credible analysis therefore avoids a single global count unless the method is disclosed. It states which collectors, peers, time window and route set are being counted.

This is also why an article should separate route visibility from traffic harm. A route can be visible but not selected. It can be selected by some networks and not others. It can slow a path without creating a total outage. It can affect one content delivery mapping more than another. Public incident writing often compresses these distinctions for readability. Accountability writing has to expand them again, because repair depends on knowing which layer failed.

The source operator's control questions

The first question is what AS37468 intended to export. A network should know the prefixes and route types it is allowed to announce to each external neighbor. That intended set should be specific enough to detect an abnormal jump. It should distinguish self-originated prefixes, customer prefixes, routes learned from peers, routes learned from providers, test routes and internal redistribution artifacts. If those categories collapse, a route leak can escape through an export policy that looks broad but was never meant to carry that scope.

The second question is how the export policy was generated. Some networks maintain static prefix lists. Some generate filters from IRR objects, ROAs, provisioning systems, or a mix of sources. Some use route maps and communities to constrain export by relationship. The method is less important than the audit trail. A postmortem should show which input source produced the final policy, when it was changed, who approved it, and how the router's actual Adj-RIB-Out compared with the approved set.

The third question is whether the network had a source-side anomaly limit. If a session normally exports a small and known set of routes, a sudden expansion should trigger a local hold even before a neighbor filters it. That hold can be implemented as a maximum-prefix threshold, an export-diff gate, a commit-time check, or an external monitor that compares live announcements to the inventory. A source network should not rely on upstream providers to notice every mistake.

The fourth question is whether the operator monitored the public Internet view of its own routes. A network can query collectors and route-monitoring systems for unexpected origins, paths and propagation. The goal is not vanity monitoring. It is evidence that what left the network matches what the network intended. The public route table is the running code of routing accountability. If the public table shows the wrong path, a private assertion that the intended policy was correct is not enough.

The fifth question is how the route was withdrawn. Did an engineer roll back a change? Did an automated control shut the session? Did a neighbor filter the route? Did a route reflector converge after a policy change? Did the bad path disappear from all relevant collectors, or only one? A withdrawal is an operational action, not merely a timestamp. The action should be reconstructable.

The public sources do not answer those questions. That is not a reason to publish speculation. It is the boundary of the public record. The article can state that AS37468 identity and the event boundary are supported while the internal root cause remains unknown. The accountability demand is for the missing records, not for invented certainty.

The neighbor and transit-provider duty

A route leak usually needs more than one failure to become large. A source network can export something wrong, but a neighbor decides whether to accept it. The neighbor also decides whether to advertise it onward. That acceptance boundary is where a local error becomes shared risk. A provider cannot reasonably promise to catch every possible customer error, but it can be expected to apply customer-specific policy, route limits and validation signals.

Customer-prefix filtering is the core. A provider should know what the customer is allowed to originate or transit. That knowledge may come from contracts, provisioning databases, IRR data, ROAs, previous route history and direct communication. Each source has defects. IRR data can be stale. ROA coverage can be incomplete. Contract records may not be machine-readable. Historical routing can legitimize past mistakes. The point is not to find one perfect source. The point is to combine sources into a conservative acceptance rule.

Default deny matters here. RFC 8212 updates BGP operational expectations so external BGP sessions should require explicit import and export policy rather than implicitly exchanging routes [12]. The practical lesson is simple: a route should not enter or leave a boundary merely because a session is up. There should be a policy saying why the route is acceptable for that relationship. If the policy is absent, the safe outcome is not to pass the route.

BGP roles and the Only-to-Customer attribute described in RFC 9234 add another control map. The design helps neighbors signal relationship roles and detect exports that violate expected customer, peer or provider paths [13]. It is not a magic retrofit for every legacy session, and deployment is not universal. But it shows where the industry has moved: route-leak prevention needs relationship evidence, not only origin evidence.

Maximum-prefix thresholds are another independent control. A customer that suddenly sends a route set far outside its normal range should trip a warning or session protection. The threshold has to be meaningful. A limit set high enough to protect router memory but not routing integrity is not enough. Operators should track baseline route counts, alert on abnormal deltas and require a deliberate approval path for large changes.

The provider duty is not about blame theater. It is about blast-radius reduction. If a source AS leaks a route, upstream and peer boundaries should prevent the leak from becoming a global detour. If different neighbors respond differently, the comparison becomes evidence. One path propagated, another did not. That contrast can teach operators which controls worked and which were missing.

RPKI helps, but it was not enough

The Resource Public Key Infrastructure lets a resource holder publish a Route Origin Authorization, or ROA, saying which AS may originate a prefix. Routers or validation systems can then classify a route as valid, invalid or not found. RFC 6811 describes BGP prefix origin validation, while related operational guidance explains how this validation can be deployed [14][15]. For a route where the wrong AS appears as origin, RPKI can produce a strong rejection signal.

That signal is narrow. It answers the origin question. It does not answer the whole path question. A route can have a valid origin and still be leaked across the wrong relationship. A route can be RPKI unknown because no ROA exists. A route can be covered by a ROA but still require local policy on prefix length, customer authorization and export scope. Origin validation is therefore necessary evidence, not a complete route-leak firewall.

For the Angola Cables event, the public capsule intentionally avoids claiming that RPKI would have stopped everything. The safer conclusion is that origin validation should be part of the review. Which affected prefixes had ROAs? Which appeared invalid with the observed path? Which were not found? Which networks rejected invalids? Which accepted unknowns? Which used validation state only for local preference rather than rejection? Without those answers, RPKI is a slogan rather than evidence.

RPKI also requires resource holders to publish accurate ROAs. If affected destinations lacked ROAs, downstream operators had less cryptographic evidence for origin rejection. That does not excuse accepting every route. It shows why routing security is cooperative. Resource holders publish origin evidence. Source networks constrain their exports. Providers filter customers. Peers preserve relationship policy. Collectors reveal what escaped. Each layer reduces uncertainty for the next.

There is another lesson: a public route leak should trigger ROA hygiene review for the affected destinations as well as policy review for the leaking and propagating networks. If a high-value destination depends on the Internet to reject unauthorized origins, its own resource records must support that outcome. That is not victim blaming. It is a recognition that the routing system's safety properties are distributed.

What proof of repair should include

A repair claim should start with an incident boundary. The boundary should identify the date, time window, origin or path pattern, affected relationship, observed collectors and known impact class. For this event, the boundary is the 25 May 2023 route leak associated with Angola Cables AS37468 and Australian paths toward United States services [1][2]. A repair statement that only says the issue was resolved is not enough.

Next, the operator should preserve the intended route set. That set should show which prefixes AS37468 was allowed to originate or export on each external session. If the leak involved customer, peer or provider routes, the categories should be explicit. The intended set should be compared with the actual Adj-RIB-Out during the event. The difference is the defect surface.

The operator should then preserve neighbor evidence. Which neighbors received the wrong routes? Which accepted them? Which rejected them? Which exported them further? For each relevant session, the postmortem should identify import policy, export policy, route count limits, validation state and alert behavior. If a neighbor stopped the route, that success should be documented as much as a propagation failure. Positive controls are part of the accountability record.

Collector evidence should be tied to the private record. A timeline from RouteViews and RIPE RIS can show when the route became visible and when it vanished. Operator logs can show what action changed the state. If the public route disappeared before the operator took action, the cause may have been a neighbor filter or convergence elsewhere. If the route persisted after the claimed fix, the repair was incomplete. The two timelines should reconcile.

The repair should also include a prevention control. Examples include stricter export lists, generated customer filters, default-deny EBGP policy, meaningful maximum-prefix thresholds, RPKI validation policy, BGP role support where available, automated collector monitoring and a rollback rule for abnormal export deltas. The control should be testable. A future configuration should fail closed when the same class of route is attempted.

Finally, the repair should preserve the unknowns. Exact packet-loss totals, full customer harm, internal staff actions and financial effects may remain private or unavailable. That does not make the public article weak. It makes the article honest. Accountability is strongest when it states what is known, what is inferable, and what only the operator can prove.

The business impact without overclaiming

The public reports say the leak slowed connectivity for many Australian users reaching United States sites, including AWS and Akamai services [1][2]. That is a serious claim because AWS and Akamai sit under many ordinary digital experiences. A slower path to a cloud endpoint can feel to a user like a broken application. A slower path to a content delivery network can turn a healthy origin into a poor experience. The control-plane error becomes a business problem through latency, timeouts and uncertainty.

The article should not convert that into an unsupported list of victims. The public capsule does not include every affected service, every customer complaint or a packet-loss ledger. The correct phrasing is therefore bounded: the event affected paths toward named classes of services, and public reports identified AWS and Akamai as examples. It does not say every AWS customer was affected, every Akamai-served site slowed, or every Australian network selected the leaked path.

That restraint is not cosmetic. Overclaiming turns a route leak article into advocacy copy. The Daniel Kade target is a reality-layer article. It should help readers understand how a routing-control failure can harm users while preserving the evidentiary distance between route visibility and experienced outage. The harm is credible; the exact perimeter is not public.

For business leaders, the lesson is that network incidents can sit outside the application team's direct control. A cloud service may be healthy, a content network may be operational, and the user's access network may still take a poor path because routing policy somewhere else changed. Incident management therefore needs path evidence, not only application dashboards. Synthetic monitoring, traceroutes, route collector checks and provider escalation paths matter because they expose the layer that ordinary uptime metrics can miss.

For network operators, the lesson is that a route leak's cost is not measured only by how long it remains visible in BGP. The cost includes investigation time, customer trust, escalation load and confidence in future routing changes. A short leak can still force many teams to ask whether their traffic was hijacked, detoured or merely slow. That uncertainty is part of the damage.

What readers should watch next

The next signal is whether Angola Cables or involved neighbors publish a detailed technical postmortem. A useful postmortem would not need to disclose sensitive customer contracts or router passwords. It would need to disclose the route-policy class that failed, the scope of prefixes or paths, the neighbors that accepted or rejected the routes, the monitoring that detected the issue, the withdrawal timeline and the prevention control added afterward.

The second signal is whether route-leak prevention standards become operational defaults rather than conference advice. RFC 8212 default policy, RFC 9234 roles and OTC, RPKI origin validation, IRR filter generation and collector monitoring all point toward the same direction: explicit route permission beats implicit trust. The remaining question is deployment quality. A standard that exists on paper but is absent from production sessions will not stop the next leak.

The third signal is whether affected destinations improve their own origin evidence. If high-value prefixes have accurate ROAs, more networks can reject unauthorized origins. If they do not, providers must rely more heavily on other filters. Destination resource holders are not responsible for another operator's export mistake, but their records influence how much of that mistake downstream networks can automatically detect.

The fourth signal is whether incident reporting separates path, origin and harm. A public article should say whether it is discussing a route leak, an origin hijack, a path leak, a latency event, a partial outage or a customer-visible service failure. Those labels are not pedantry. They decide which controls matter. Origin validation addresses one problem. Relationship-aware path policy addresses another. Capacity engineering addresses another. A precise label directs repair.

The fifth signal is whether public collectors remain healthy and widely peered. RouteViews and RIPE RIS are accountability infrastructure. They let outsiders test claims about what the Internet saw. More diverse peering improves the public record. Fewer collectors or narrow peering would make future incidents easier to deny and harder to bound.

Why this is a network accountability case

The failure belongs in network accountability because the object is not a brand narrative or a general latency story. It is a BGP route leak. The accountable surfaces are AS37468, path propagation, relationship policy, registry evidence, public route collectors, RPKI limits and operator continuity. Remove those surfaces and the story no longer works. The remaining question would only be whether a company had a bad day. The public evidence supports a narrower and more useful question: which routing controls should have made the bad path harder to export, accept, propagate or leave unexplained?

Registry and number-resource records matter here as evidence systems, not as symbolic ownership claims. AFRINIC RDAP records help identify registered resource context. bgp.tools and PeeringDB help frame network identity and visible relationships. None of those records decides the routing reality by itself. Running code and visible route state remain primary. The reality layer is the path packets were encouraged to take, the announcements collectors saw, and the policies operators should be able to prove.

That standard also keeps the article inside the available evidence. It does not say Angola Cables intentionally harmed users. It does not say every affected service failed. It does not turn RFCs into retroactive legal duties. It uses RFC 7908, RFC 8212 and RFC 9234 as control maps: definitions, defaults and relationship signals that explain how this class of event can be constrained. That is different from declaring a past violation of a rule the public record has not proven.

The same restraint is why the article is useful. A reader who does not operate BGP can still understand the chain: a network announces routes, a neighbor accepts or rejects them, other networks may select the path, users may see degraded service, public collectors make the condition observable, and repair requires evidence. The technical details are not decoration. They are the route from public harm to accountable control.

Closeout questions

The route-leak closeout questions remain clear:

What exact route set did AS37468 intend to export on 25 May 2023?
Which routes escaped that set, and through which external sessions?
Which neighbors accepted, rejected or propagated the routes?
Which collectors saw the path, and when did the route withdraw?
Which RPKI, IRR, maximum-prefix, BGP role or export-policy controls were present?
Which prevention control changed afterward, and how can it be tested?
Which user-impact claims are supported by measurements rather than assumption?

Those questions do not require a punitive theory. They require evidence. That is the right standard for a route leak. The Internet does not become more reliable when operators win arguments about blame. It becomes more reliable when route permissions are explicit, collector evidence is preserved, unknowns are not hidden, and the next bad path fails closed before users have to notice it.

Angola Cables' 2023 Route Leak Made Path Validation an Accountability Test

Why it matters

Summary

What happened

Why this was a path-validation problem

The role of AS37468 identity records

Why route collectors help but do not decide the case

The source operator's control questions

The neighbor and transit-provider duty

RPKI helps, but it was not enough

What proof of repair should include

The business impact without overclaiming

What readers should watch next

Why this is a network accountability case

Closeout questions

Sources

Deeper Profile Context

Strategic Circle

Leadership Alliance

Strategic Circle Briefing

Leadership Alliance Briefing