Routing Anomaly in Venezuela: Technical Malfunction or Something More?
Recent reporting has highlighted a Border Gateway Protocol (BGP) anomaly involving Venezuela’s state-run ISP, CANTV (AS8048). While speculation has suggested potential malicious intent, an analysis of the available routing data points to a more mundane explanation: poor routing policy configuration. Looking back over the past two months, Cloudflare Radar’s route leak alerting pipeline shows AS8048 has been involved in eleven separate leak events since the beginning of December, indicating a pattern of technical issues rather than a one-off, nefarious act.
BGP and the Mechanics of a Route Leak
To understand the event, it’s necessary to review how BGP is designed to function. BGP is the protocol that directs traffic across the internet. By design, it relies on the business relationships between networks, known as Autonomous Systems (ASes). There are two primary relationship types:
- customer-provider: A customer pays a provider for connectivity to the rest of the internet.
- peer-peer: Two networks agree to exchange traffic between their respective customers for free.
Based on these relationships, routing follows what is known as the valley-free routing rule. Traffic is expected to travel up to a provider, across a peering link if needed, and then down to the destination's network. A valid path should never traverse a "valley" by going up to a provider, down to a customer, and then up to another provider again.
A route leak is defined in RFC7908 as a violation of this valley-free principle. This happens when an AS redistributes routes learned from one provider or peer to another provider or peer. For example, in a Type 1 hairpin route leak, a customer network takes routes from one of its providers and re-advertises them to a second provider. The second provider, following standard BGP practices, would assume the customer is announcing its own or its downstream customers' routes and would prefer that path, potentially overwhelming the smaller customer network with traffic.
Examining the AS8048 Leak
The specific event in question occurred on January 2, when AS8048 (CANTV) took routes from its provider AS6762 (Sparkle, an Italian telecom) and redistributed them to another provider, AS52320 (V.tal GlobeNet).
The leaked prefixes are all part of the 200.74.224.0/20 subnet and are originated by AS21980 (Dayco Telecom). A critical detail here is the relationship between the leaker and the originator: AS8048 is the upstream provider for AS21980. This relationship is confirmed by AS relationship inference data from multiple sources, which shows with high confidence that AS8048 provides transit to AS21980.
Several factors suggest this was not an intentional attempt to intercept traffic. The leaked routes were heavily prepended, with paths showing AS8048 repeated up to nine times. Prepending makes a route less attractive to other networks, which would be counterproductive for a network attempting to become a man-in-the-middle for traffic. An attacker would typically try to make their routes as short and attractive as possible. Furthermore, AS8048 is already the provider for the network originating the prefixes, so a leak is not a necessary step to observe traffic from that customer.
The event also unfolded over roughly two hours on January 2, between 15:30 and 17:45 UTC, consisting of multiple separate announcements. This timing, over twelve hours before U.S. military strikes in Venezuela, alongside the network's history of similar events, points to a likely routing convergence issue or a misconfiguration stemming from loose export policies.
Over the past two months, Cloudflare Radar's alerting pipeline has logged numerous Type 1 hairpin route leaks with AS8048 as the leaker. This frequency of similar incidents points towards an accidental and ongoing technical configuration issue. For instance, AS8048 may have export policies toward its providers that match on an IRR-generated prefix list rather than on a customer BGP community tag. This would cause it to leak routes for its downstream customers, even if the direct BGP session for that customer was down.
Path vs. Origin Validation
Some analyses have noted that Sparkle (AS6762) had not fully implemented RPKI Route Origin Validation (ROV). While true at the time of the event, this observation is not directly relevant. ROV is designed to prevent route misoriginations, or hijacks, where an unauthorized network announces a prefix it does not own.
The Venezuelan leak was not a misorigination. The origin AS, AS21980, was correct for the announced prefixes. The problem was with the path itself, as the route was being invalidly redistributed by its own provider. This type of anomaly is known as a path-based problem and requires a different solution than ROV.
The most promising tool for this is Autonomous System Provider Authorization (ASPA). Similar to RPKI route origin authorizations, an ASPA object is a cryptographic record that defines which ASes are authorized to be a provider for your network. A tier-1 network, for example, could use the reserved value AS0 to indicate it has no providers. Other networks could then verify a BGP path against these ASPA records. In this case, if AS6762 had published an ASPA object stating it had no upstreams, AS52320 would see the leaked route containing "AS6762" from its customer, AS8048, and reject it as invalid.
Building a Safer BGP
This incident underscores that route leaks remain an inherent risk of BGP, given its foundations are based on trusting business relationships. While any single leak could theoretically be malicious, the long history of similar events from AS8048 strongly suggests a string of operational configuration errors rather than a targeted attack.
To mitigate these problems, the internet community is driving adoption of several mechanisms. ASPA offers the most comprehensive protection against path-based anomalies and is actively being developed. In addition, operators can implement simpler tools like Peerlock to sanity-check received paths for obvious leaks. Furthermore, RFC9234, which defines BGP roles and the Only-to-Customer (OTC) attribute, offers another practical mechanism to prevent these kinds of configuration slip-ups by explicitly coupling route announcements to business relationships.
