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
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
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)
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
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
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
participants (7)
-
Christopher Morrow -
Dale W. Carder -
Frank Habicht -
Mike Hammett -
Pierfrancesco Caci -
Tom Beecher -
Tom Samplonius