llm/52671bed-a32b-4001-8725-0574603461fb/topic-10-3f4d7285-4919-4131-a3f6-f81e243ab995-input.json
The following is content for you to summarize. Do not respond to the comments—summarize them. <topic> Network Infrastructure Security # Discussion of BGP insecurity, RPKI adoption, the role of transit providers like Sparkle in enabling route manipulation, and publicly available BGP monitoring data. </topic> <comments_about_topic> 1. > When BGP traffic is being sent from point A to point B, it can be rerouted through a point C. If you control point C, even for a few hours, you can theoretically collect vast amounts of intelligence that would be very useful for government entities. The CANTV AS8048 being prepended to the AS path 10 times means there the traffic would not prioritize this route through AS8048, perhaps that was the goal? AS prepending is a relatively common method of traffic engineering to reduce traffic from a peer/provider. Looking at CANTV's (AS8048) announcements from outside that period shows they do this a lot. Since this was detected as a BGP route leak, it looks like CANTV (AS8048) propagated routes from Telecom Italia Sparkle (AS6762) to GlobeNet Cabos Sumarinos Columbia (AS52320). This could have simply been a misconfiguration. Nothing nefarious immediately jumps out to me here. I don't see any obvious attempts to hijack routes to Dayco Telecom (AS21980), which was the actual destination. The prepending would have made traffic less likely to transit over CANTV assuming there was any other route available. The prepending done by CANTV does make it slightly easier to hijack traffic destined to it (though not really to Dayco), but that just appears to be something they just normally do. This could be CANTV trying to force some users of GlobeNet to transit over them to Dayco I suppose, but leaving the prepending in would be an odd way of going about it. I suppose if you absolutely knew you were the shortest path length, there's no reason to remove the prepending, but a misconfiguration is usually the cause of these things. 2. CANTV (AS8048) is a correct upstream transit provider for Dayco (AS21980) as seen in both https://radar.cloudflare.com/routing/as21980#connectivity and https://bgp.tools/as/21980#upstreams What most likely happened, instead of a purposeful attempt to leak routes and MITM traffic, is CANTV had too loose of a routing export policy facing their upstream AS52320 neighbor, and accidentally redistributed the Dayco prefixes that they learned indirectly from Sparkle (AS6762) when the direct Dayco routes became unavailable to them. This is a pretty common mistake and would explain the leak events that were written about here. 3. In principle, it means you could run multiple sites from the same IP and someone intercepting traffic to that IP (but not the client’s DNS path) couldn’t tell what site each connection was to. It mostly makes sense for CDNs, where the same IP will be used for many sites. If you don’t use a CDN at all, the destination IP leaks what site you’re trying to connect to (if the domain is well known). If you use a CDN without ECH, you send an unencrypted domain name in the HTTPS negotiation so it’s visible there. ECH+CDN is an attempt to have the best of both worlds: your traffic to the site will not advertise what site you’re connecting to, but the IP can still be shared between a variety of sites. It’ll be interesting to see how countries with lighter censorship schemes adapt - China etc. of course will just block the connection. 4. Not from the cloudflare dashboard, you can zoom out. The night of the attack doesnt even really stand out as abnormal when zooming out that far. 5. If you were not already entirely reliant on American tech before, this ought to convince you to put jump in with both feet. What could possibly go wrong? 6. There is not really any reason to conclude that "american tech" was responsible for this attack. If anything, given all the sanctions Venezuela was under and how friendly they are with china, i would be surprised if they were using american tech in their infrastructure. [Of course i agree with the broader point of dont become dependent on the technology of your geopolitical enemies] 7. It’s for sure another alarm signal for the EU to further reduce dependencies on our newest geopolitical enemy… the United States of America. 8. There are other attack vectors beyond infrastructure though when the population all have Android Smart Phones running Play Services and communicate using WhatsApp. 9. Most everyone in the world has a Google or Apple phone in their pocket. I'm not sure how much more reliant you can get. 10. It's pick-your-poison, really. Technology is notoriously expensive to develop and manufacture. One must either have native capacity (and thus, the wealth) to do so, or must get it from someone else. Other Western/US-aligned countries might have the ability to do so, albeit at geopolitical and economic cost, because the only thing you're likely to gain from kicking the US out of your tech stack and infrastructure is a tech stack and infrastructure free of the US. Meanwhile American companies will be developing new features and ways of doing things that add economic value. So at best, a wash economically. Maybe the geopolitical implications are enticing enough. Places like Venezuela? Nah. They'll be trading the ability of Americans to jack with their tech infrastructure for the ability of the PRC, Non-US Western nations, or Russia to jack with their tech stack. The geopolitics of technology are a lot like a $#1+ sandwich: the more bread you have, the less of someone else's $#1+ you have to eat. 11. What would be the result of this? I think it would route data through Sparkle as a way of potentially spying on internet traffic without having compromised the network equipment within Venezuela, but I'm not familiar enough with network architecture to really understand what happened. 12. The effect of this would be traffic from GlobeNet destined for Dayco would transit over CANTV's network for a period. I'm not sure why the author singled out Telecom Italia Sparkle. 13. BGP is so unsecure that almost anyone can create chaos. 14. Even by accident! 15. Most BGP peers have router filters in place. It's not 1996 anymore. I remember the days of logging into a Cisco connected to a Sprint T1 and seeing a coworker had fat fingered a spammer's route, sending it to null0. Oops. How did that happen? 16. I worked as a contractor for a IoT gig that sold sim cards services for buses, trains et cetera. The radio towers we used to access to obtain the accounting data (CDRs) all had the same very weak password. 17. Solid OSINT methodology here. The 10x AS path prepending is the most interesting detail to me b/c typically you'd see prepending used to de-prioritize a route, which raises the question: was this about making traffic avoid CANTV, or was it a side effect of something else? A few thoughts: - The affected prefixes (200.74.224.0/20 block → Dayco Telecom) hosting banks and ISPs feels significant. If you're doing pre-kinetic intelligence gathering, knowing the exact network topology and traffic patterns of critical infrastructure would be valuable. Even a few hours of passive collection through a controlled transit point could map out dependencies you'd want to understand before cutting power. - What's also notable is the transit path through Sparkle, which the author points out doesn't implement RPKI filtering. That's not an accident if you're planning something (you'd specifically choose providers with weaker validation). - The article stops short of drawing conclusions, which is the right call. BGP anomalies are common enough that correlation ≠ causation. But the timing and the specific infrastructure affected make this worth deeper analysis. Would love to see someone with access to more complete BGP table dumps do a before/after comparison of routing stability for Venezuelan prefixes in that window. 18. Symbolic link to the Cloudflare RPKI status for CANTV. [1]: https://radar.cloudflare.com/routing/as8048ref=loworbitsecur... </comments_about_topic> Write a concise, engaging paragraph (3-5 sentences) summarizing the key points and perspectives in these comments about the topic. Focus on the most interesting viewpoints. Do not use bullet points—write flowing prose.
Network Infrastructure Security # Discussion of BGP insecurity, RPKI adoption, the role of transit providers like Sparkle in enabling route manipulation, and publicly available BGP monitoring data.
18