Re: [db-wg] out of region routing in the RIPE Database
Hi, I would like to have the IRR kept open, we have space from various regions and need to be able to make use of a single well known IRR in order to register our policies and be able to mix our ASNs with our space. It is very convenient to be able to use the RIPE IRR for that. I do see that authentication/verification against other RIR's Database is not done at the moment and can be abused and will support any simple mechanism put in place in order to fix that issue. But closing the IRR down for out of region resources far outweighs the negative side effects seen by typos and abuses that comes through from time to time. On 20 July 2017 at 15:41, Gert Doering via db-wg <db-wg@ripe.net> wrote:
---------- Forwarded message ---------- From: Gert Doering <gert@space.net> To: Sander Steffann <sander@steffann.nl> Cc: George Michaelson <ggm@algebras.org>, denis walker < ripedenis@yahoo.co.uk>, Database WG <db-wg@ripe.net> Bcc: Date: Thu, 20 Jul 2017 09:41:09 +0200 Subject: Re: [db-wg] out of region routing in the RIPE Database Hi,
its a broken process. it inherently permits things to be said, which should not have been said.
Time to set up a joint IRR database where only authoritative data from
On Tue, Jul 18, 2017 at 04:10:52PM +0200, Sander Steffann via db-wg wrote: participating RIRs is stored?
This might indeed be the way forward for "I have a customer in my RIPE AS which has APNIC space and wants to document that in a way that that provisioning tools can pick this with sufficient trust on data quality".
(And no, RADB is not)
Gert Doering -- NetMaster -- have you enabled IPv6 on something today...?
SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
-- -- Kind regards. Lu
I would like to have the IRR kept open, we have space from various regions and need to be able to make use of a single well known IRR in order to register our policies and be able to mix our ASNs with our space.
There are non-RIR registries out there that can meet your requirement with out of region resources while not feeding RIPE DB with dummy objects. Allowing object creation without authorization of the resources holder makes abuse much easier (DATASTAR-MNT is an example). It takes far more resources to shut down an abuser than abuser continuing with another mntner. If an object already exists in a mirrored registry, RIPE dummy object is more likely to reduce the data quality (outdated/abandoned objects, conflicting information). In short term (months), is there any logistical issue that prevents RIPE from implementing email authorization (aut-num PoC at issuing RIR) when creating an out of region object in RIPE DB? And if all non-RIPE address space were to be removed, what would be the timeline to stop accepting dummy objects? Yang
participants (2)
-
Lu Heng -
Yang Yu