'Suspicious' BGP event routed big traffic sites through Russia A Border Gateway Protocol (BGP) routing incident saw a bunch of high-profile Internet destinations mis-routed through Russia on Tuesday, US time. In what BGPMon called a “suspicious” event, “Starting at 04:43 (UTC) 80 prefixes normally announced by organisations such Google, Apple, Facebook, Microsoft, Twitch, NTT …
BGPMon doesn't name its suspicions, but recommends that major ISPs filter their customers to avoid such events.
Bingo. The list is "whom you should not buy from" - people who do not know what they are doing.
It was sort-a excusable to not compute filters out of routing registry info and apply them 15 years ago because of router config space limitations. However, in this day and age?
It's been a while since I was on the sharp-end of BGP, but there are/were some issues with that. It wasn't so much a router limitation given the route filters would be generated off the router. Not sure if Cisco/Juniper include tools to try and do that automagically now though. But the biggest challenge is assuming there's a reliable route object registered to build filters from. In RIPE-land, or anyone but ARIN, that was vaguely doable. In ARIN-space, often route objects didn't exist, especially for retail users. They often had no idea what a route object was, or how to go about creating one.
But for route filtering to work, it really needs to be applied at the upstream, so-
aut-num: AS39523
as-name: DV-LINK-AS
org: ORG-VII2-RIPE
sponsoring-org: ORG-ATS13-RIPE
Megafon
import: from AS31133 accept ANY
export: to AS31133 announce AS39523
Vimpelcom
import: from AS3216 accept ANY
export: to AS3216 announce AS39523
So Megafon's one of DV-LINK's upstreams/transit provider, and has a corresponding entry in it's AS object rather than a more specific to only accept DV-LINK's assigned address space. That's the first line of defence against advertising bogus routes from your downstreams. The report doesn't mention the specific routes that were advertised, but if those don't have route objects defined, auto-rule building wouldn't work.
DV-LINK looks like a Russian ISP though, so this may just have been some fat-fingering rather than anything malicious.
> He’s doing enough damage to the US all by himself.
That's unfair. I think he's doing a great job.
So great I want to buy him a nice Christmas present and send it to the Whitehouse.
A jumper would be nice.
In fact, I think we should all buy Donald a nice jumper.
(One that wouldn't mess his hair up when he took it off.)
#TurtlenecksForTrump
Is there any kind of historical 'misrouting analysis' which gives a list of these types of events and the locations that data was misrouted through? It would be interesting to see the misrouting events organised by country of 'wrongful route'. e.g. How many misroutings went through the USA or UK?
Maybe tin foil hat time, but a connection from France to the UK went pretty damn slowly on the day of 9/11, while France to Germany was fine. Unfortunately it was a kiosk box so I couldn't run a traceroute to see if the traffic was going via Langley...
Traceroute would sorta work for fat-finger issues. So tracing to one of the IP addresses that was wrongly advertised might show it resolving some unexpected hops along the way to it's new blackhole. Because traffic ends up routed to something that can't respond.
Unless of course you're paranoid, in which case traffic was briefly directed to faked websites, and evilness occurred. Because Russia, obviously. It's much like the good'ol Internet hijack when Florida stole EVERYTHING!. Possibly due to some previously unknown NSA site there. Ah, AS7007, I still remember you..
Or it was just another in a long list of routing errors that propogated due to BGP making that easy. As for sources of Internet mysteries, try Team Cymru (who aren't in Wales), CAIDA, or even NANOG-
https://mailman.nanog.org/pipermail/nanog/
> Because traffic ends up routed to something that can't respond.
Traffic interception doesn't require re-routing. Maybe it did in the 90's - and even that is doubtful too - but not today. That's the whole point of traffic interception.
Even today, traceroute will show hops that won't respond. That's normal, and it doesn't mean these hops are NSA's or GCHQ's. Quite the opposite: if they show up in traceroute, then they are definitely not NSA or GCHQ. Which makes using traceroute for detecting packet interception completely useless.
If a traceroute shows a hop, then by definition it's responded. If you're tracing to www.nsa.gov and it shows hops via .ru, then something's.. not quite right. Which is also the problem with this story, ie if it were some state-level interference, it wouldn't have been so obvious. Which is where the story drifts into conspiracy theory land. Plus anyone who's ever applied for a telecomms licence in Russia would know the conditions applied. I suspect this was the usual BGP error, with a slim chance of it being malicious. By 'cant respond', I meant a web/login server created to spoof the official versions and try to capture logins.. Assuming traffic ever managed to get beyond the edge router.
Problem with the modern Internet is more topology information gets hidden behind MPLS, which doesn't respond to ICMP. But you may be able to infer some topology changes just by looking at the latency. Which is why it's common to use it to poll for reachability or link/routing problems.
I thought they needed a special tank behind a special john in a special facility to capture that sort of thing.
Oh, and hopefully rubber gloves to do the actual packet capture.
>> thanks, it's the perfumed one on the end with the used rubber gloves sticking out of the pockets.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
