This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/db-wg@ripe.net/
[db-wg] Further cleanup (was: RIPE NONAUTH route(6) objects using unregistered space cleanup - deployment *today*)
- Previous message (by thread): [db-wg] Further cleanup (was: RIPE NONAUTH route(6) objects using unregistered space cleanup - deployment *today*)
- Next message (by thread): [db-wg] Further cleanup (was: RIPE NONAUTH route(6) objects using unregistered space cleanup - deployment *today*)
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Job Snijders
job at sobornost.net
Wed Jul 7 14:18:16 CEST 2021
Hi Ronald, It is a matter of feasibility. In this context, at this layer of the technology stack it is up to the database clients to filter out information they do not consider of interest. The database is merely a conduit between an authorized internet number resource holder and the database clients. I'll share a practical example of 'client side' filtering. Back in 2016 I helped coordinate an industry-wide efforts to rid the public BGP Default-Free Zone of private ASNs. https://ripe72.ripe.net/archives/video/193/ https://ripe72.ripe.net/presentations/151-RIPE72_bogon_ASNs_JobSnijders.pdf I consider the campaign a success because nowadays private ASNs are by-and-large unusable in context of public BGP routing. The creation of easy to copy+paste config examples has further solidified the separation between 'public' and 'private': https://bgpfilterguide.nlnog.net/guides/bogon_asns/ Drawing analogies between IRR and RPKI ====================================== The expectation is that RPKI will assume most functionality of IRR databases over time. Thus, before proposing changes to any IRR system, we have to consider the rules of its cryptographic sibling, the RPKI, as that is the successor to IRR. In the RPKI authorization model the equivalent of the "origin:" attribute is defined as a positive integer [1] known as the 'ASId'. The issuer of the ROA decides what numeric value the ASId is set to. In many RPKI deployment scenarios it is *** technically impossible *** for the RIR to impose restrictions on the content of the ASId field, because the RIR is not involved in the issuance or publication of said objects. It is up to the relaying party (aka the 'database client') to discard objects which are not of interest because of local policy. Do I tell people they might have misconfigured an IRR route object or RPKI ROA when I see it? Yes Does IRRexplorer show warnings when private numbers are found in objects? Yes Should RIPE NCC point out private values in objects during Assisted Registry Checks? Yes Should BGP Default-Free Zone operators configure their routers to discard BGP UPDATE messages with private ASNs? Yes Should the database server software impose brittle restrictions on that field? No, not worth the headache. Kind regards, Job [1]: https://datatracker.ietf.org/doc/html/rfc6482#section-3
- Previous message (by thread): [db-wg] Further cleanup (was: RIPE NONAUTH route(6) objects using unregistered space cleanup - deployment *today*)
- Next message (by thread): [db-wg] Further cleanup (was: RIPE NONAUTH route(6) objects using unregistered space cleanup - deployment *today*)
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ db-wg Archives ]