Mailing List Archive

>
> I imagine there is a some sort of coalescing industry standard out there,
> but so far I can’t find it.
>

There is not, and won't be for a long time, if ever.

There isn't a one size fits all solution.

On Thu, Nov 16, 2023 at 9:31?PM Tom Samplonius <tom@samplonius.org> wrote:

>
> 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. 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 assumed that everyone implementing RPKI validation, would skip IRR
> route object validation if the route is RPKI-valid. 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.
>
> I also thought there may be an informational RFC on this, but I couldn’t
> find anything. Has there been anything published or any presentations
> given, on generally accepted BGP route acceptance criteria?
>
>
> Tom

If you need to support RTBH you need to check prefix list (thus IRR) first, then the RTBH , then RPKI. Otherwise blackhole route gets dropped before executing.

Also, you don't want to accept Google prefixes from your customer, even
if they are ROV valid.

i.e. you want to restrict what you accept to customer and customer's
customer prefixes...

Frank

On 17/11/2023 08:38, Pierfrancesco Caci wrote:
> If you need to support RTBH you need to check prefix list (thus IRR)
> first, then the RTBH , then RPKI. Otherwise blackhole route gets dropped
> before executing.

Thus spake Tom Samplonius (tom@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

> On Thu, Nov 16, 2023 at 9:31?PM Tom Samplonius <tom@samplonius.org> wrote:

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

I don't think the future is ever really 'no irr'.
* RPKI provides: "a cryptographically verifiable method to determine
authority to use ip number resources"
* OriginValidation provides: "A route origin authorization
'database' for use eventually on BGP speakers"

IRR filters provide control over whom is provided reachability through
a particular peering/path.
(dale points this out as well, particularly the part about paths he points out)

Everyone thinks they're a unicorn and they're special and it's a secret... other than those that don't. ;-)




-----
Mike Hammett
Intelligent Computing Solutions
http://www.ics-il.com

Midwest-IX
http://www.midwest-ix.com

----- Original Message -----

From: "Tom Samplonius" <tom@samplonius.org>
To: nanog@nanog.org
Sent: Thursday, November 16, 2023 6:54:17 PM
Subject: Generally accepted BGP acceptance criteria?


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. 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 assumed that everyone implementing RPKI validation, would skip IRR route object validation if the route is RPKI-valid. 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.

I also thought there may be an informational RFC on this, but I couldn’t find anything. Has there been anything published or any presentations given, on generally accepted BGP route acceptance criteria?


Tom

> On Nov 17, 2023, at 6:58 AM, Christopher Morrow <morrowc.lists@gmail.com> wrote:
>
>> On Thu, Nov 16, 2023 at 9:31?PM Tom Samplonius <tom@samplonius.org> wrote:
>
>>> 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.
>
> I don't think the future is ever really 'no irr'.
> * RPKI provides: "a cryptographically verifiable method to determine
> authority to use ip number resources"
> * OriginValidation provides: "A route origin authorization
> 'database' for use eventually on BGP speakers"

Those both amount to the ability to originate a prefix though.


> IRR filters provide control over whom is provided reachability through
> a particular peering/path.

How does that work? IRR import: and export: parameters are poorly implemented. Is anyone actually validating more than the origin with IRR?


> (dale points this out as well, particularly the part about paths he points out)


Tom

Thus spake Tom Samplonius (tom@samplonius.org) on Mon, Nov 20, 2023 at 07:02:52PM -0800:
> > On Nov 17, 2023, at 6:58 AM, Christopher Morrow <morrowc.lists@gmail.com> wrote:
> > IRR filters provide control over whom is provided reachability through
> > a particular peering/path.
>
> How does that work? IRR import: and export: parameters are poorly implemented. Is anyone actually validating more than the origin with IRR?

I think "validating" is the wrong verb for IRR. "Provisioning" may
be more accurate.

As an example, my AS293 peers with AS6509. In the AS-SET that they
publish, AS6509:AS-CANARIE, the "members:" field for instance lists
AS271:AS-BCNET-MEMBERS which then lists AS271 in it's members. An
inverse query to an IRR whois server from such a tool as 'bgpq4' walks
this tree to generate a list of prefixes applicable to in effect, a
given path presuming you know what IRR object to start with. That is
where import/export typically comes into play.

RPSL's 'import:' and 'export:' (and the mp-variants) are problematic
at best to use programmatically. Our provisioning system for example
doesn't bother and uses the IRR object specified in PeeringDB for
filter generation by default.

Dale

> On Nov 21, 2023, at 7:42 AM, Dale W. Carder <dwcarder@es.net> wrote:
>
> Thus spake Tom Samplonius (tom@samplonius.org) on Mon, Nov 20, 2023 at 07:02:52PM -0800:
>>> On Nov 17, 2023, at 6:58 AM, Christopher Morrow <morrowc.lists@gmail.com> wrote:
>>> IRR filters provide control over whom is provided reachability through
>>> a particular peering/path.
>>
>> How does that work? IRR import: and export: parameters are poorly implemented. Is anyone actually validating more than the origin with IRR?
>
> I think "validating" is the wrong verb for IRR. "Provisioning" may
> be more accurate.
>
> As an example, my AS293 peers with AS6509. In the AS-SET that they
> publish, AS6509:AS-CANARIE, the "members:" field for instance lists
> AS271:AS-BCNET-MEMBERS which then lists AS271 in it's members. An
> inverse query to an IRR whois server from such a tool as 'bgpq4' walks
> this tree to generate a list of prefixes applicable to in effect, a
> given path presuming you know what IRR object to start with. That is
> where import/export typically comes into play.

I get the data structure, but are there are any tools that implement the above and allow paths to be validated?


...
> Dale


Tom