We explored the data. There have been eleven route leak incidents since the beginning of December, affecting multiple prefixes where AS8048 is leaking. Although it is impossible to determine with certainty what happened on the day of the incident, this pattern of route leaks suggests that the CANTV (AS8048) network, a popular Internet service provider (ISP) in Venezuela, has inadequate routing export and import policies. In other words, the BGP anomalies observed by the researcher may be associated with poor technical practices by ISPs rather than malicious intent.
In this post, we will briefly discuss Border Gateway Protocol (BGP) and BGP route leaks, and then look into the anomaly observed and what might be causing it.
Background: BGP route leak
First, let’s recap what bgp route leak Is. BGP route leaks cause behavior such as taking the wrong exit from a highway. Although you can still reach your destination, the route may be slower and there may be delays than you otherwise would have if you were traveling on a more direct route.
Root leak was given a formal definition RFC7908 as “propagation of routing announcements beyond their intended scope”. The desired scope is defined using in pairs Business relationships between networks. The relationship between networks, which in BGP we represent using Autonomous Systems (ASes)May be one of the following:
- Customer-provider: A customer pays the provider network to connect itself and its downstream customers to the rest of the Internet.
-
Peer-to-peer: Two networks decide to exchange settlement-free (without payment) traffic between each other, for each other’s customers.
In the customer-provider relationship, the provider will declare all routes to customerOn the other hand, the customer will advertise route only Generated from their own customers and directly from their network.
In a peer-to-peer relationship, each peer will advertise to the other Only their own routes and the routes of their downstream customers,
These advertisements help direct traffic in expected ways: from customers to the provider network, potentially over a single peering link, and then potentially back from their providers to customers at the far end of the path.
A valid path would look like the following which follows valley-free route Rule:
A passage leak Valley-free routing is a violation where an AS takes routes from one provider or peer and redistributes them to another provider or peer. For example, a BGP path should never pass through a “valley” where traffic goes to the provider, and back to the client, and back to the provider again. Various types of route leaks are defined in RFC7908, but a simple type is Type 1: Hairpin route leak between two provider networks by a subscriber.
In the above diagram, the AS64505 takes routes from one of its providers and redistributes them to their other provider. This is unexpected, as we know that providers should not use their customers as intermediate IP transit networks. The AS64505 will be overwhelmed with traffic as a smaller network with smaller networks and network links than its providers. This can become effective very quickly.
Route leakage by AS8048 (CANTV)
Now that we have reminded ourselves what a route leak is in BGP, let’s look at what was envisaged in it newsletter postThe post attracted attention some route leakage anomalies On Cloudflare radar connected to AS8048. But radar page For this leak, we see this information:
We see the leaker AS, which is AS8048 – CANTV, Venezuela’s state-run telephone and Internet service provider. We observed that the routes were taken from one of their providers AS6762 (Sparkle, an Italian telecommunications company) and then redistributed to AS52320 (V.tal GlobeNet, a Colombian network service provider). This is definitely a root leak.
The newsletter suggests “BGP tricks” and believes that such leaks can be exploited to gather intelligence useful to government entities.
Although we can’t say for sure what caused this pathway leak, our data suggests that the likely cause was more mundane. That’s partly because BGP route leaks happen all the time, and they’ve always been a part of the Internet – often for reasons that aren’t malicious.
To understand more, let’s take a closer look at the affected prefixes and networks. All prefixes included in the leak were generated by AS21980 (Deco Telecom, a Venezuelan company):
The prefixes are also all members of the same 200.74.224.0/20 SubnetAs mentioned by the newspaper writer. However, what is much more interesting is the relationship between the original network AS21980 and the leaked network AS8048: AS8048 is a provider Of AS21980.
The customer-provider relationship between AS8048 and AS21980 is visible in both cloudflare radar And bgp.tools AS relationship interference data. We can also get the confidence score of the AS relation using the Monocle tool bgpkitAs you see here:
➜ ~ monocle as2rel 8048 21980
Explanation:
- connected: % of 1813 peers that see this AS relationship
- peer: % where the relationship is peer-to-peer
- as1_upstream: % where ASN1 is the upstream (provider)
- as2_upstream: % where ASN2 is the upstream (provider)
Data source: https://data.bgpkit.com/as2rel/as2rel-latest.json.bz2
╭──────┬───────┬───────────┬──────┬──────────────┬──────────────╮
│ asn1 │ asn2 │ connected │ peer │ as1_upstream │ as2_upstream │
├──────┼───────┼───────────┼──────┼──────────────┼──────────────┤
│ 8048 │ 21980 │ 9.9% │ 0.6% │ 9.4% │ 0.0% │
╰──────┴───────┴───────────┴──────┴──────────────┴──────────────╯
While only 9.9% of route nodes see these two ASES as adjacent, almost all of those paths show AS8048 as the upstream provider for AS21980, meaning that trust in the provider-client relationship between the two is high.
Many of the leaked routes were also heavily associated with AS8048, meaning it may have been potential Less Attractive for routing when received by other networks. Preparation Padding of an AS more than once is the act of attempting to switch traffic from one particular circuit to another in an outbound advertisement by a subscriber or peer. For example, during the leak by AS8048 several paths looked like this: “52320,8048,8048,8048,8048,8048,8048,8048,8048,8048,23520,1299,269832,21980”.
You may notice that the AS8048 has sent its AS advertising to the AS52320 multiple times, because the path through BGP loop prevention will not actually travel in and out of the AS8048 multiple times in a row. A non-prepended path would look like this: “52320,8048,23520,1299,269832,21980”.
If AS8048 Was Deliberately Trying To Be Man in the Middle (MITM) For traffic, why would they make BGP advertising less attractive More Attractive? Plus, why leak a prefix to try and MITM traffic when you can already Anyway a provider for downstream AS? It won’t have any special meaning.
Leaks from AS8048 also surfaced in several separate announcements, each over the span of an hour between 15:30 and 17:45 UTC on January 2, 2026, suggesting that they may contain network issues that resulted in a routing policy issue or a convergence-based crash.
It is also noteworthy that these leakage events begin twelve hours before US military attack in VenezuelaLeaks that affect South American networks are commonAnd based on the timing or the other factors I’ve discussed, we have no reason to believe that the leak is related to Maduro’s capture several hours later.
In fact, looking at the last two months, we can see a lot of leaks by AS8048 that are exactly like this, meaning this is not a new BGP anomaly:
You can see in the history of Cloudflare Radar’s root leak alerting pipeline above that the AS8048 is no stranger to Type 1 hairpin root leaks. This has been happening since the beginning of December Eleven route leakage incidents Where AS8048 is going to leak.
This leads us to a more innocent possible explanation about the route leak: AS8048 may have configured export policies too loosely in front of at least one of its providers, AS52320. And because of that, the redistributed routes belong to their customer, even when the direct customer BGP routes were missing. If their export policy towards AS52320 only matches IRR-generated prefix list no more Customer B.G.P community The tag, for example, would understand why an indirect path towards AS6762 was leaked back upstream by AS8048.
Some of these types of policy errors are RFC9234 And the customer-only (OTC) feature, if supported, will help significantly by more tightly connecting BGP to customer-provider and peer-to-peer roles. by all routing vendorsI’ll save more technical details on RFC9234 for a follow-up blog post,
Difference between Origin and Path Verification
The newsletter also states that Sparkle (AS6762) does not implement this “notably” RPKI (Resource Public Key Infrastructure) Root Origin Validation (ROV). Although it is true that AS6762 appears to have a incomplete deployment of ROV and is marked as “unsafe” isbgpsafeyet.com because of itBasic authentication could not have prevented this BGP anomaly in Venezuela.
It is important to separate BGP anomalies into two categories: incorrect route origination, and path-based anomalies. Knowing the difference between the two helps in understanding the solutions to each. Wrong origin of the route, often called BGP hijack, is corrected by RPKI Route Origin Validation (ROV) by ensuring that the originator of the prefix is the same one that is its rightful owner. In the case of the BGP anomaly described in this post, the original AS was correct as AS21980 and Only The path was uneven. This means that ROV will not help here.
Knowing this, we need path-based validation. What is this Autonomous System Provider Authority (ASPA)An upcoming draft standard in the IETF is going to provide. The idea is similar to RPKI Root Origin Authorization (ROA) and ROV: create an ASPA object that defines a list of authorized providers (upstream) for our AS, and everyone will use it to invalidate root leaks over the Internet at different vantage points. Using a concrete example, AS6762 is a tier 1 Transit-free networks, and they will use the special reserved “AS0” member in their ASPA signed objects to tell the world that they have no upstream providers, only lateral peers and customers. Then, AS52320, the second provider to AS8048, will look at routes to its client containing “6762” in the path and reject them by performing the ASPA validation process.
ASPA is based on RPKI and this is what will help prevent route leakage similar to the one seen in Venezuela.
A secure BGP, built together
We felt it was important to provide an alternative explanation for the BGP route leakage observed by AS8048 on Cloudflare radar in Venezuela. It is useful to understand that route leaks are an expected side effect of BGP that has historically been based entirely on trust and carefully executed business relationship-driven intent.
While route leaks may be done with malicious intent, the data suggests that this incident may have been an accident caused by the lack of routing export and import policies that could have prevented it. That’s why for secure BGP and the Internet we need to work together and adopt RPKI-based ASPA, which RIPE has recently released object creationon the wider Internet. This will be a collaborative effort, like RPKI is for basic authentication, but it will be worth it and prevent BGP incidents like the one in Venezuela.
Apart from ASPA, we can all implement simple mechanisms like pearlock And pearlock-lite As operators, which sanity-checks the received paths for obvious leaks. One particularly promising initiative is to adopt RFC9234Which should be used to prevent route leaks with the establishment of additional BGP roles and a new Only-to-Customer (OTC) feature for ASPA. If you haven’t already asked your routing vendors for implementation of RFC9234 on their roadmap: Please to doYou can help bring about big change,
<a href