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
