[db-wg] A test on AFRINIC range announcing without RIPE route object

Dear Denis,

On Wed, Jun 13, 2018 at 11:45:24AM +0000, denis walker wrote:
> >> In conclusion, If you employ a non-Afrinic asn for announcements
> >> (which means a foreign asn), using RIPE’s route object will be the
> >> only choice for you unless you are one of those big telecoms which
> >> has the liberty to announce anything as they wish.
> 
> > This is not correct, you can also use RADB, NTTCOM, LEVEL3, or
> > ALTDB, etc. RIPE is/was not an exclusive provider for this type of
> > service.
> 
> (wearing my devil's advocate hat)...  So are you saying all these
> other databases offer the same service with the same security risk
> that we are about to remove from the RIPE Database?

That is (currently) correct.

> None of these databases have any authorisation link to any of the
> RIR's address registries. So can anyone create bogus ROUTE objects in
> these databases for any address space? Suggesting that people can use
> these databases implies that their contents are taken seriously,
> including any bogus ROUTE objects.

Correct. But you may recall my presentation from RIPE 76 that NTT is
sponsoring a full rewrite of IRRd to be able to extend IRRd. One of the
possible (and desired) extensions is an authorisation link to the
authoritative RIR. Progress can be tracked here https://github.com/irrdnet/irrd4

Another aspect related to third party IRRs is to leverage RPKI data to
clean up stale/rogue IRR entries, or prevent creation such not-validated
route-objects. I'm very excited about having a modern IRRd and being
able to innovate in this problem space. We've received commitment from
multiple third party IRR operators that they'll switch to the new code
bsae.

In summary, the third party IRRs are insecure, and work is being done to
address that issue. I love talking about those road maps but I feel this
is somewhat out of scope for the RIPE database working group.

> So by closing down this service in the RIPE Database are we solving a
> problem (closing a security hole) or just moving the problem somewhere
> else? 

No, we are not "just moving the problem". "Moving" would mean that the
problem currently does not exist the other place and would be opened up
if RIPE makes its move.

The problem exists in multiple places, these must be addressed one by
one. Closing down this security problem in the RIPE database is
literally just that: it removes one of the security problems from the
eco-system. When this is done, we move to the next problem until there
is nothing left on the list.

> Ideally all 5 RIRs should operate an IRR with authorisation linked to
> the address registrations and not required from any ASN.  Then we
> would have a place to put ROUTE objects that can be trusted.

This literally already exists and is called RPKI. :-)

Kind regards,

Job