Understanding IRR route objects vs RPKI ROAs without an existential crisis

So I spent like 4 days tryign to make both IRR and RPKI work on the same prefix and almsot lost my mind. The documetnation is basically scattered acrss 5 RFCs and 3 differnet RIR wikis that contradict each othr. Heres what I figurd out so you dont cry.

IRR route objects are the old way. You put yr object in whois and peopel filter based on the maintner. Its "trust on first lookup" basically. RPKI ROAs are the cryptographc way. Signed by yr RIR. Validators check the chain. Both can coexist and most big transit now checks BOTH.

Key thing: ROA has maxLength. If you make a /24 ROA with maxLength 24 and annouce a /23, fail. Route object doesnt care about length just prefix. So you need both to match yr actual annoucement or you get "partial valid" which is basically "invalid" in practice.

I made a ROA for /22 with maxLength 22 but my route object said /24. 3 hours of debugign later I found the typo. The existental crisis was real. This guide is how I justify thsoe 3 hours to myslef. Dont be me. Check both.

Anyway IRR is legacy but still requierd for many peers. RPKI is future but not universal. Run both. Keep them syncd. Or youll be the one crying at 3am when yr prefix drops from half the internet.

You figure it out

Teh typo aside, this is a solid writeup!

One thing I'd add: did you test your restore? Not for RPKI specifically, but for your IRR data and ROA private keys. If your signing setup goes sideways, do you have:

• 3 copies of your ROA private key (HSM export, offline backup, encrypted cloud)
• 2 different media types for those copies
• 1 offsite location for at least one backup

The 3-2-1 rule applies to routing security too. I've seen operators lose their RPKI signing capability and have to scramble for days with their RIR.

Also, great point about maxLength. That's the #1 gotcha I see in postmortems.

Mano this guide is very good!!

I am make a test last month with both in my ASN and is work nice! Before I have only IRR and some peer in europe they filter me, now with RPKI too is more fast to propagate

One thing: in LACNIC the interface for ROA is... caramba! Not good. But we manage. Kkkkk

Thank you for write this, I send to my team!

"solid writeup" allegedly

"trust on first lookup" is basically "trust forever because nobody updates these things" in practice. Source: trust me bro

Ive seen "partial valid" prefixes from "reputable" upstreams that allegedly check both. In reality they check whichever is easier and ignore mismatches. "secure routing" is doing a lot of heavy lifting there

The real existential crisis is realizing both systems are "cheap" band-aids on BGPs "unlimited" trust model. But we keep building "support" layers on top instead of fixing the foundation

Still, useful guide. "thanks" for the maxLength warning, saved me some debug time probably

¡the guide is excelent, tomhider!

I have the server red in my network and the prefix it drop for the filter bad. Now I understand the maxLength is the problem, not the server red. Before I think the hardware is fault, but is the ROA the fault!

In my RIR the interface is bad also, same same. Vos tenés reason with the 3am crying, I am live it last week. ¡much thanks for write this!

Same 3am crying here, maxLength got me last month

More fast to propagate how? BGP convergence doesn't work like that.

Not the convergence time, the filter time! Before with only IRR, some AS in europe they have manual process or only update 1 time per day from RADb. With RPKI they check automatic with validator. My prefix is accepted more fast in new peer, not the BGP itself.

But you are right, I write wrong. Kkkkk

Ah fair enough. IRRdb polling intervals are a real thing. Some of those databases are basically batch jobs from the 90s.

Still, "propagate" means something specific. Words have meanings etc etc.

Mate you are not wrong. I found route objects in RADb from 2003 still being used. The maintner password was probably set by someone who left the industry before covid.

But "trust forever" is still better than "trust nobody" which is what you get with no filtering. Half these transits would accept a hijack from AS1337_SkR1pT_K1dZ if it looked plausible enough.

At least with both you need TWO things to go wrong.