Large-Scale BGP Hijack
twitter.com
twitter.com
Meanwhile in EMEA we've been using IRR (and recently RPKI) for automating filters for years now. I couldn't do a BGP hijack through my EU upstreams even if I wanted to.
As a bonus, my US upstream doesn't care if I have RPKI/ROA/IRR - even if I do, they ask for dead tree LOA anyway.
When I sent a dead tree to one of my EU upstreams out of habit they were like "what do I need this for?"
Take credit cards. As an end user you perceive some fairly heavyweight albeit imperfect security, but in reality there are two parallel systems and only one of them is using those security features.
Authorisation is the part that ties your good name to your transactions. The bank doesn't trust you, so considerable technological effort is used in Authorisation. Chip cards, PINs, extra passwords and codes for web transactions, that's all Authorization.
Settlement moves money between your account and a merchant account. This isn't secured at all, it's just based on trust. Any merchant can assert that you used your card to pay them any amount and by default the bank takes it on trust.
Authorisation is abuse resistant. If you try to replay the same authorization multiple times it doesn't work.
Settlement doesn't care. If a worker messes up and puts a big merchant's daily settlement transactions through twice, every single one of those transactions just happens again. Paid $80 for groceries leaving $38 in the account until pay day? Sorry, now you're $42 overdrawn. This really happens.
If you complain they'll fix it. If hundreds of customers complain they'll realize the error and fix it for everyone. But this is why you have to check your credit card bill. Sooner or later there will be errors, and if you don't check you'll never see them which can get expensive fast.
ISPs have noting of the kind. One routing mistake (or "mistake") and all of your customers' data suddenly went through China, Russia, US (you name it), for better or worse. What's worse, in a manner of speaking that data is now devalued. There's value date equivalent in the ISP's world. As a customer you have no avenues, the thing isn't even between you and any ISP you may work with. The bank will never get away with telling you "well we accidentally made this extra payment, it got routed thorough this extra bank, so now you lost 25% of the money".
As for Level 3 the world wonders.
But...
AS12389 announced them to Rascom (AS20764), who accepted them and sent them on to Cogent (AS174), who accepted them and propogated them on to Level3 (AS3356), who, unfortunately, then accepted them from Cogent.
The AS path would've been much longer than if Level3 had accepted them directly from AS12389 so, at the least, the actual effects of the hijacking weren't as bad as they could have been.
RIP can't cope with the scale of the internet today, but to say BGP is essential to interconnecting networks is not right
If you take away BGP, there is no Internet!
No other protocol in existence/use today can scale the way BGP has.
TCP connection setup is the lowest layer that makes it nontrivial to spoof a sender.
Trust has been broadly effective, but also quite damaging at times. It's part of why I'm glad https is nigh universal - http's trust allowed stuff like Firesheep and all the hotel shit-injection that used to be so prevalent.
Is there a reason why these can't be filtered at the ISP level? eg. Cogent knows that Rascom shouldn't be announcing those prefixes, and refusing to route traffic to them unless there's manual verification?
I run a large production BGP network. With two exceptions every provider needed a Letter of Authorization from me to send to their upstream that authorized the announcement of my IP space (the exceptions being India where they wanted to charge extra for filtering announcements, and Russia where they offered to not do filtering for an extra charge).
This "manual verification" already takes place. It just doesn't apply to large transit providers interconnecting like what happened here
The reality is that RPKI Origin Validation solves this (but not as path spoofing, we need ASPA for that) and people need to publish valid ROAs.
Until routing vendors start shipping sane IRR based route filtering in default configs and make it hard to turn off, this is something we have to deal with.
Well-designed cryptography lets us tilt the odds violently on these human problems so as to give us greater confidence to take action when appropriate.
If you say maybe your technician typed 185.42.16.0 when they meant to type 158.42.61.0, that they uploaded last month's data instead of this month's, they wired a patch incorrectly - these are not implausible accidents. But cryptographically signed records don't happen by accident. You can't "typo" a 1-in-billions-of-billions chance.
I do agree with you that routing vendors have made this difficult to easily ingest prefix list data for easy import into inbound filters. There have been NANOG presos from last decade showing the performance hit when you try to do this at scale. It is much easier to enable RPKI OV than it is to build a robust IRR filtering system.
This is an interesting perspective. Do you have the same opinion of certificate authorities?
The real question is how many networks doing RPKI Origin Validation (OV) weren't accepting the ARIN TAL (ignoring ROAs from ARIN) due to their license to provide them indemnity. Remember that RPKI validators require a network to manually add ARINs TAL.
https://www.ripe.net/support/service-announcements/accidenta...
Last week a large BGP routing leak (>20k prefixes) occurred in Russia briefly impacted internet traffic around the world.
See the interactive 3D visualization of the incident here: https://map.internetintel.oracle.com/leaks#/id/20764_12389_1...
It would literally be more useful if you just screenshot it and posted that, as at least it would last longer, not to mention add detail.
> Probably won't be able to read the tweet in the future when it gets deleted, no real context or other information in the tweet. I find the tweet helpful. I didn't know about BGPmon, for instance.
Screenshots, on the other hand... They're not accessible, and they don't provide easy links back to the author, nor access to the tweet's reply context. I find all of those valuable.
The problem is that these announcements are made by third parties, and accepted by fourth parties, both of which Facebook has no control over.
While it's possible for Facebook to implement some controls over what routes THEY accept and therefor what routes Facebook sends traffic TO - it cannot control where others send traffic. If a third party advertises Facebooks routes to a fourth party, and they accept them, Facebook cannot do anything directly about that. And then those fourth parties accepting the routes will send traffic TO Facebook via the third party.
Disclosure: I used to work at WhatsApp, including while it was part of Facebook. Everything in this message is armchair routing policy though.