Generally accepted BGP acceptance criteria?

Fri Nov 17 14:55:57 UTC 2023

Thus spake Tom Samplonius (tom at samplonius.org) on Thu, Nov 16, 2023 at 04:54:17PM -0800:
> 
>   In the world of IRR and RPKI, BGP route acceptance criteria is important to get right.
> 
>   DE-CIX has published a detailed flow chart documenting their acceptance criteria:  https://www.de-cix.net/en/locations/frankfurt/route-server-guide
> 
>   But I don’t see a lot of operators publishing their criteria.

An example another IX: https://www.seattleix.net/route-servers

Here's at least one provider example: https://routing.he.net/algorithm.html

>  I imagine there is a some sort of coalescing industry standard out there, but so far I can’t find it.  Of the upstreams I use, just one publishes a flowchart.  Another is basically refusing to explain anything other than they “use” IRR and RPKI, ad that RPKI is “good”.

I don't think there is a standard as there is a pretty wide range of
variance, ranging from "nothing" to static lists to `bgpq4` to whatever
you call what Hurricane is doing.

>   I assumed that everyone implementing RPKI validation, would skip IRR route object validation if the route is RPKI-valid.

Not at all.  While an ROA provides an attestation about the originating
ASN for a prefix, there are no claims made as to the path or that all
prefixes for an ASN have ROAs.

>  I assumed that everyone is doing this now, or would do this when they implement RPKI validation.  But I spoke to an operator today, which still expects all routes to pass IRR as well (and while they perform RPKI-validation, they effectively do nothing with the result).  To me, this seems like a different direction than most operators are going.  Or is it?
> 
>   The most surprising thing in the DE-DIX flow chart, was that they check that the origin AS exists in the IRR as-set, before doing RPKI, and if the set existence fails, they reject the route.  I don’t see a problem with this, as maintaining as-sets is easy, but it does prevent an eventual 100% RPKI future with no IRR at all.

There are some possible things in the works you should consider, as
OTC, ASPA, rpki-prefixlist (essentially like an irr route-set), and
even partial deployment of bgpsec are emerging tools in the toolbox.  

Before embarking too far, we must also consider this from an ecosystem
perspective.  With RPKI ROA's, the integration with IRRd v4 elegantly 
sunsets blatantly invalid prefixes.  Additional tooling (IRRd v5?
bgpq5?) would need to be considered to further transition our way out
out of the IRR system, assuming an analog in RPKI.  

Would we even want to?  Dropping non-RIR IRR source databases might go
much further to get to very similar goals with much less work than for
example reimplementing as-sets (I think essentially the inverse of
ASPA's ASProviderAttestation) in RPKI.

Dale