>The route leak was distributed quite well through Rascom (AS20764) , then Cogent (AS174) and in a couple of minutes through Level3 (AS3356) to the world.
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?
> 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 challenge is with scale. If I'm a network who has many networks downstream of me I might have 50 to 100 prefix changes in a month. None of my upstream providers are going to like manually vetting all of those - and none of my customers don't want to wait days before their announcements propagate. So there is this sort of state you can land yourself as a "you're a big customer, we seem to trust you".
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.
Back in the 90's, nobody did LOAs. I remember reading prefixes over the phone to a guy at InternetMCI when I was moving an ISP from a 56K line to a T1. Fun times!
IRR already contains all the data. Cryptographically signing it can't increase the rate at which people will use it (one could argue throwing crypto into the mix decreases adoption). RPKI is just crypto nerds trying to math their way in to a human and financial problem.
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.
> RPKI is just crypto nerds trying to math their way in to a human and financial problem.
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.
IRR contains data - question is can you trust it? RIPE has cleaned up their stuff, sure, but the rest of the IRRs out there haven't. Next question is which IRR once you get past the RIRs? AltDB? There's a few out there. Lots of crap objects and proxy registration, that said there are a lot more things in IRR than ROAs out there.
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.
Some of them, where origin didn't match ROA. The rest can be filtered by bgp filters based on IRR data. IRR filtering would cut more that 80% of that leak.
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?