Cloudflare's post is pretty boring here in that regard. They dig into how BGP works and propose that similar leaks seem common for the Venezuelan ISP in question.

Sure they could be wrong or even actively hiding the truth of what happened here, but the article mentions nothing of Cloudflare being involved in the action and they're describing a networking standard by pointing to publicly available BGP log data.

What am I missing here that everyone else seemed to zero in on?

This could be a classic fat finger config error, most likely a route map intended to manipulate traffic engineering for their own upstream links that inadvertently leaked widely because of a missing deny-all clause. Neverthless, a good reminder that BGP is still fundamentally a trust based system where a single typo in a config file can cascade globally. Never attribute to malice that which is adequately explained by a missing export filter.

"NSA Network Shaping 101". Big descriptions of ASINs, and layer 3 shaping. Written in 2007.

I know this has always been the case, of course, but now I have lost trust. Whatever the reasons of this "leak" were, I am not accepting any information written in this message (search for the link to another coverage of the incident in the comments).

It is quite weird and quite logical at the same time: this is the end of an era.

I assumed it was a badly performing algorithm. But if it had instead routed me through a McDonalds drive through, I'd have assumed it was foul play.

I think the article makes a decent case that this was the former and not the latter, though it would be interesting to see route leaks visualized on a map over time. Too many odd coincidences could sway me the other way.

The mental model I’ve been using is: Intentional change (maintenance, policy update) Accidental leak (misconfig, partial rollout) Structural failure (dependency or upstream issue) I like to ask three questions first: Did the blast radius grow over time, or did it appear instantly? Did paths change symmetrically or only in one direction? Did things revert cleanly or drift back slowly? Some concrete tricks that helped: Look for AS-path prepending changes first. Compare visibility across regions rather than just globally.

Track “who benefits” from the new paths, even if only for a short time. I’m interested in how others approach this: What is your first indicator that things are indeed wrong? Do you prefer automated alerts or manual recognition of a pattern?

If BGP only really needed to represent three types of peers (provider, customer, actual peer), wouldn't BGP configuration and perhaps even BGP be massively simplified?

Does anyone have data on what the general frequency of these leaks is likely to be across the network?

At first pass you probably use HTTPS/TLS for the web, and you know that you shouldn't click through invalid certificate warnings. So the web, tentatively, looks pretty safe.

Email jumps out as vulnerable to eavesdropping, as we largely use opportunistic encryption when transferring messages between mail servers and an on-network-path attacker can use STARTTLS stripping or similar techniques. Most mail servers happily send using cleartext or without validating the TLS certificate. Check that you and your counter-parties are using DNSSEC+DANE, or MTA-STS to ensure that authenticated encryption is always used. Adoption is still quite low, but it's a great time to get started. Watch out for transactional email, like password reset messages, which virtually never validate encryption in transit (https://alexsci.com/blog/is-email-confidential-in-transit-ye... ; instead use multi-factor encryption).

TLS certificates themselves are at risk, unfortunately. An attacker who controls the network in-and-out of your DNS servers can issue domain-verified certificates for your domain; even removing protections like CAA records. DNSSEC is the classic solution here, although using a geographically distributed DNS provider should also work (see multi-perspective validation). Certificate transparency log monitoring should detect any attacker-issued certificates (a review of certificates issued for .ve domains would be interesting).

Ideally, we should build an internet where we don't need to trust the network layer. A BGP route leak would be a performance/availability concern only. We're not there yet, but now is a great time to take the next step in that direction.

There were BGP anomalies during the Venezuela blackout

https://news.ycombinator.com/item?id=46504963

What is a BGP?

https://arstechnica.com/information-technology/2018/11/major...

> Google goes down after major BGP mishap routes traffic through China

hah.

This is how I imagine Russian companies in Russia write about the Russian war on Ukraine.