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.