Skip to content

CLOUDFLARE 2026-01-08 Tier 1

Read original ↗

A closer look at a BGP anomaly in Venezuela

Summary

On 2026-01-02 between 15:30 and 17:45 UTC, AS8048 (CANTV, Venezuela's state-run ISP) leaked a set of prefixes in the 200.74.224.0/20 subnet — originally originated by its customer AS21980 (Dayco Telecom) — from their upstream AS6762 (Sparkle) to their other upstream AS52320 (V.tal GlobeNet). A cybersecurity newsletter flagged the event on Cloudflare Radar and hypothesized "BGP shenanigans" around the U.S. capture of Venezuelan leader Nicolás Maduro (which occurred ~12 hours later). Cloudflare's post argues the leak was almost certainly mundane — a policy-hygiene failure, not malfeasance — and uses the incident as a vehicle to explain BGP route-leak forensics, how to distinguish origin from path anomalies, and why ASPA (and not RPKI ROV) is the mitigation that would have prevented it.

Why it's almost certainly accidental

Five forensic signals, taken together, make the malicious interpretation implausible:

  1. Recurring pattern. Since the beginning of December 2025 there had been eleven route-leak events with AS8048 as the leaker. "AS8048 is no stranger to Type 1 hairpin route leaks." A one-off intelligence-collection event would not reproduce weekly for a month.

  2. AS8048 is already AS21980's provider. Cloudflare Radar, bgp.tools, and BGPKIT monocle's as2rel confidence score all show AS8048 as upstream of AS21980:

➜ ~ monocle as2rel 8048 21980
╭──────┬───────┬───────────┬──────┬──────────────┬──────────────╮
│ asn1 │ asn2  │ connected │ peer │ as1_upstream │ as2_upstream │
├──────┼───────┼───────────┼──────┼──────────────┼──────────────┤
│ 8048 │ 21980 │ 9.9%      │ 0.6% │ 9.4%         │ 0.0%         │
╰──────┴───────┴───────────┴──────┴──────────────┴──────────────╯

If AS8048 is already on-path for AS21980's traffic, a leak that re-exposes AS21980's prefixes through other providers does not give AS8048 any interception it didn't already have — the MITM motive is absent.

  1. Heavy AS-path prepending makes the leaked routes less attractive. Observed paths: 52320, 8048, 8048, 8048, 8048, 8048, 8048, 8048, 8048, 8048, 23520, 1299, 269832, 21980 — AS8048 prepends itself nine times. An attacker trying to steer traffic would do the opposite (fewer prepends, more-specific prefixes, shorter AS path). Prepending is a classic traffic-engineering tool; its presence here is consistent with CANTV trying to push traffic away from the leaked path, not attract it.

  2. Multiple separate announcements spread across two hours. Leaks were not a single contiguous window but recurred on a ~hour cadence between 15:30 and 17:45 UTC, consistent with network convergence / routing-policy flaps on CANTV's side.

  3. Timing precedes the Maduro capture by >12 hours. The leaks began well before the U.S. military action in Venezuela. South American route leaks are extremely common and happen daily.

Mechanism (how the policy hygiene fails)

A route leak is defined in RFC 7908 as "the propagation of routing announcement(s) beyond their intended scope," where intended scope is defined by pairwise customer-provider and peer-to-peer business relationships:

  • In a customer→provider relationship: the customer advertises only its own routes + its own customers' routes. It does NOT advertise routes learned from other providers or peers.
  • In a peer↔peer relationship: each peer advertises only its own routes + its own customers' routes.

Valley-free routing is the property that emerges from consistent application of these rules: a path should never traverse customer → provider → customer (a "valley"). The 01-02 event is a Type 1 hairpin leak: AS8048 (a customer of AS52320) took routes learned from one of its providers (AS6762) and propagated them to its other provider (AS52320).

Cloudflare's alternative hypothesis: AS8048's outbound export policy toward AS52320 uses a coarse filter — probably just an IRR-generated prefix list matching AS8048's customer cone — and does not additionally require that each advertised prefix carry a customer BGP community tag proving it originated via the customer-BGP session rather than via indirect learning from a provider. When AS8048's direct customer session with AS21980 briefly dropped but AS21980's prefixes were still visible through AS6762, the loose export policy advertised them to AS52320 anyway — producing the observed leak. This is the customer- community-tag export policy pattern, absent.

Why RPKI ROV wouldn't help

The newsletter's other claim — that AS6762 not having full RPKI Route Origin Validation deployment is "notable" — conflates two distinct anomaly classes:

  • Route misorigination (BGP hijack) — someone falsely originates a prefix they don't own. Fixed by ROV (reject paths whose origin ASN is not a valid ROA signer for the prefix).
  • Path-based anomaly (route leak) — the origin is correct (AS21980 is the legitimate originator), only the path violates policy. ROV cannot help because it checks only the final AS in the path.

This is the origin vs path validation distinction. The Venezuela event is purely path-based, so even perfect ROV deployment at AS6762 would not have prevented it.

(Note: Sparkle (AS6762) did complete RPKI ROV deployment and was marked safe on isbgpsafeyet.com on 2026-02-03, per the post's update — commendable but not germane to this specific leak.)

What would help — ASPA + OTC + Peerlock

The forward-looking mitigations Cloudflare names:

  • ASPA (Autonomous System Provider Authorization) — an IETF draft standard (draft-ietf-sidrops-aspa-verification) for path validation. Each AS publishes an RPKI-signed ASPA object listing its authorized upstream providers. A Tier-1 transit-free network like AS6762 uses the special AS0 member to declare "I have no upstream providers, only lateral peers and customers." Then AS52320 can reject any route it receives from its customer AS8048 that contains 6762 in the path — because AS6762 could never have been AS8048's customer. RIPE recently released ASPA object-creation support. patterns/aspa-for-path-validation is the canonical pattern.

  • RFC 9234 Only-to-Customer (OTC) — a complementary BGP attribute (RFC 9234) that couples BGP more tightly to customer-provider / peer-peer roles via an explicit BGP Role capability negotiated at session setup + an OTC path attribute set on routes advertised to non-customer peers. Requires vendor support; APNIC's 2025-09-05 writeup shows Juniper's early implementation. Cloudflare's advice: "ask your routing vendors for an implementation of RFC 9234 to be on their roadmap."

  • Peerlock / Peerlock-lite — simpler operator-side mechanisms to sanity-check received paths for obvious leaks, e.g. rejecting routes from a customer whose path contains a known Tier-1 ASN. The Peerlock repo has Junos templates; Peerlock-lite (NANOG) is the minimal version. patterns/peerlock-sanity-check captures this shape.

Key takeaways

Systems and concepts introduced or extended

Introduces: systems/cantv-as8048, systems/sparkle-as6762, systems/vtal-globenet-as52320, systems/dayco-telecom-as21980, systems/aspa, systems/peerlock; concepts/bgp, concepts/autonomous-system, concepts/route-leak, concepts/valley-free-routing, concepts/customer-provider-relationship, concepts/peer-peer-relationship, concepts/bgp-export-policy, concepts/as-path-prepending, concepts/bgp-community, concepts/rpki, concepts/route-origin-validation, concepts/path-validation, concepts/only-to-customer, concepts/irr-prefix-list, concepts/hairpin-route-leak; patterns/alternative-explanation-forensics, patterns/irr-prefix-filtering-export-policy, patterns/customer-community-tag-export-policy, patterns/as-path-prepending-for-traffic-engineering, patterns/aspa-for-path-validation, patterns/peerlock-sanity-check.

Extends: systems/cloudflare-radar (route-leak anomaly pages as forensic data source), systems/bgpkit-monocle (canonical AS-relationship-inference workflow), companies/cloudflare (new shape: public alternative-explanation forensics — the blog's instinct to publish a long-form alternative when a third-party narrative has run ahead of the evidence, sibling of the 2025-08-04 Perplexity public-attribution post but in the deflate the claim direction rather than the make the claim direction).

Operational numbers

  • 11 route-leak events by AS8048 since December 2025 leading into 2026-01-02.
  • 01-02 leak window: 15:30–17:45 UTC (~2h 15m).
  • Affected prefixes: all within 200.74.224.0/20, originated by AS21980 (Dayco Telecom).
  • monocle as2rel(8048, 21980): 9.9% connected, 9.4% as1_upstream, 0.0% as2_upstream — high-confidence AS8048 → AS21980 customer-provider direction.
  • AS-path prepends: 8048 repeated 9 times on the leaked advertisements toward AS52320.
  • Leak detonation offset vs. Maduro capture: leaks started >12 hours before U.S. military strikes.
  • Sparkle (AS6762) RPKI ROV: marked safe on isbgpsafeyet.com on 2026-02-03 (update footnote) — orthogonal to this incident.

Caveats

  • Cloudflare's hypothesis about AS8048's loose export policy is plausible but not confirmed — they explicitly say "it is impossible to determine definitively what happened." The underlying CANTV config is not public.
  • The 9.9% connected number in the monocle query is low (only ~1 in 10 public route collectors see the AS8048↔AS21980 adjacency). The 9.4% / 0.0% ratio between as1_upstream and as2_upstream is what carries the confidence in direction, not the connected count itself.
  • "Heavy prepending" is evidence against MITM intent but not proof. An attacker could prepend intentionally to avoid detection, though the cost/benefit doesn't pencil when they're already on-path.
  • Peerlock and Peerlock-lite are operator-side mitigations, not internet-wide protocols — they do not scale to arbitrary ASN pairs the way ASPA is designed to.
  • RFC 9234 adoption depends on routing vendor implementation roadmaps, not just operator will. A follow-up blog post on RFC 9234 is promised.
  • The post is a forensic-commentary piece, not a primary incident write-up; Cloudflare is not the affected party and does not disclose its own policies' interaction with the event beyond Radar-as-data-source.

Source

Last updated · 200 distilled / 1,178 read