A closer look at a BGP anomaly in Venezuela (opens in new tab)
The post examines a January 2 BGP anomaly involving Venezuela’s CANTV network (AS8048). Although the event prompted speculation about government-directed surveillance, the broader pattern—eleven leaks since December—more strongly suggests inadequate BGP import and export filtering. The affected routes, provider-customer relationships, and heavy AS-path prepending are consistent with a configuration or operational error rather than clear malicious activity. ## Background: How BGP Route Leaks Work - BGP directs traffic between autonomous systems (ASes) according to business relationships: - **Customer-provider:** Providers advertise broad Internet routes to customers; customers advertise their own and downstream routes. - **Peer-peer:** Networks exchange their own and customer routes without payment. - These rules produce “valley-free” paths, where traffic generally moves from customers toward providers and then back down toward customers. - A **route leak**, formally defined in RFC 7908, occurs when routing announcements are propagated beyond their intended scope. - A typical leak happens when a customer receives routes from one provider and incorrectly advertises them to another provider, causing traffic to take an inefficient or overloaded path. ## The AS8048 Route Leak - Cloudflare Radar identified AS8048, operated by Venezuelan ISP CANTV, as the leaking network. - CANTV learned routes from AS6762, Italian telecom Sparkle, and redistributed them to AS52320, Colombia’s V.tal GlobeNet. - The leaked prefixes were originated by AS21980, Dayco Telecom, and belonged to the same `200.74.224.0/20` subnet. - Since AS8048 appears to be a provider for AS21980, the leak may reflect incorrect route export policies involving a customer’s prefixes. - The post emphasizes that route leaks are common and are usually caused by mistakes or weak routing controls rather than deliberate attacks. ## Evidence from Routing Relationships - Cloudflare Radar, bgp.tools, and BGPKIT data all indicate a provider-customer relationship between AS8048 and AS21980. - BGPKIT’s relationship analysis showed: - AS8048 was identified as the upstream provider in 9.4% of observations. - AS21980 was almost never identified as upstream. - Although only 9.9% of route collectors saw the two ASes as directly adjacent, the available paths strongly supported AS8048 being AS21980’s provider. ## Significance of AS-Path Prepending - Many leaked routes included repeated instances of AS8048 in their paths. - AS-path prepending is normally used to make a route less attractive and shift traffic away from a particular connection. - A path such as `52320,8048,8048,8048,...,21980` does not mean traffic physically traversed AS8048 repeatedly; the repeated entries are routing-policy padding. - The heavy prepending would have made the leaked routes less preferred, which weakens the case that AS8048 was intentionally trying to attract large volumes of traffic for interception. - The available evidence therefore points more toward poor routing configuration or operational practice than a purposeful man-in-the-middle operation. CANTV’s repeated route leaks and apparent lack of effective routing policies should still be treated as a serious reliability and security concern. However, the post’s evidence supports interpreting this incident as an example of recurring BGP misconfiguration unless further data demonstrates intentional manipulation.