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/[email protected]/
[db-wg] [routing-wg] Solving the issue of rogue ROUTE objects in the RIPE Database
- Previous message (by thread): [db-wg] [routing-wg] Solving the issue of rogue ROUTE objects in the RIPE Database
- Next message (by thread): [db-wg] [routing-wg] Solving the issue of rogue ROUTE objects in the RIPE Database
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Job Snijders
job at ntt.net
Thu Nov 12 16:57:36 CET 2015
On Wed, Nov 11, 2015 at 02:52:36PM +0100, denis wrote: > From what I understood from Gert and Randy's comments it is a user's > choice where to put a ROUTE object and there seem to be some reasons > why they sometimes choose to put it in the RIPE Database. Be that as it may, I am not convinced (yet) that non-RIPE objects really have a place in the RIPE db. Given that today there _are_ non-RIPE objects in the RIPE db, we need to find a way to deal with those. All of us hate rogue objects and want to nail down security in such a way that the RIPE db no longer is a 'free for all to exploit' database. An example of a functional IRR does not allow foreign objects: APNIC. I've not heard of that policy leading to any issues. Randy has asserted in the past that some parties (IXPs?) require people to exclusively register in the RIPE database, but I have not found data supporting that idea so far. Even if there is an IXP who operates a route-server for which filters are build exclusively using RIPE's IRR database, that is a local choice made by that IXP to not look at other databases. I won't take a single IXP's decision to not look any further as a strong incentive to put the whole world's IRR in the RIPE database. Gert indicated that it might be beneficial for a single ASN to register all their routes (including non-RIPE space) in a single database. Gert's remark is a single datapoint, it is my personal opinion that there is no operational issue if networks spread their route-object registrations over multiple databases (e.g. APNIC space in APNIC IRR, RIPE space in RIPE IRR, etc). The benefit of pushing users to the most authoritve database is that 3 out of 5 RIRs can offer strong guarantees about the validity of a route-object if it covers space managed by that respective RIR. RIPE cannot offer the same strong guarantees as APNIC & AfriNIC can in their own IRR. Why would we not encourage the community to exploit those guarantees, and direct users to create those 'foreign' route-objects in the more authoritive IRR? > Is there some specific policy now that prohibits ROUTE objects in the > RIPE Database for AFRINIC resources? "IRR Homing" was influenced by two ideas: Nick Hilliard's "why don't we change the 'source: RIPE' line to something like 'source: RIPE-NONAUTH' for objects covering non-RIPE space" and the observation that there are 30.000 route-objects covering AfriNIC space in a database which _does_not_ offer guarantees on their validity, while at the same time there is a perfect IRR which _does_ offer those guarantees: AfriNIC's own IRR. At the time I thought it safer to first migrate AfriNIC's objects and then consider changing the "source:" attribute for non-authoritive objects. So, no such policy exists, but the IRR Homing proposal (which is in the making) will include the suggestion that creation of route-objects covering AfriNIC space at some point is no longer allowed, and instead people are referred to the AfriNIC IRR. As Tim mentioned, this is a proposal and the DB-WG will be tasked with reviewing the plan. Kind regards, Job
- Previous message (by thread): [db-wg] [routing-wg] Solving the issue of rogue ROUTE objects in the RIPE Database
- Next message (by thread): [db-wg] [routing-wg] Solving the issue of rogue ROUTE objects in the RIPE Database
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ db-wg Archives ]