Hacker News Reader

Comment by betaby | Hacker News Reader

More details https://radar.qrator.net/blog/how_you_deal_with_route_leaks and some analysis https://www.ripe.net/ripe/mail/archives/routing-wg/2020-Apri... if RPKI ROA could help https://blog.cloudflare.com/rpki/

View on HN

>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?

This kind of manual override can also go wrong and cause traffic to be incorrectly dropped.

https://www.manrs.org/ would disagree with your reasoning.

There are no good reasons. Filtering implies opex, capex and man power. Also some customers are anti-filtering, basically accept everything or we wold leave to another uplink who won't filter us. I would say ~30% of organisations do not maintain their IRR data properly, notably this https://www.apnic.net/get-ip/faqs/route-management/ and https://www.apnic.net/manage-ip/using-whois/guide/as-set/ (same fotr ARIN, RIPE, AfriNIC)

They can be filtered via RPKI.

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.

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.

This is an interesting perspective. Do you have the same opinion of certificate authorities?

> 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.

> 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

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!

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.

There absolutely should be, RPKI validation of what your peers are announcing to you as their legitimate IP space.

No. Cogent are well known to be Not Very Good.

A portion of the IPs hijacked had ROAs.

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.

Reply on news.ycombinator.com