- db-wg - mailman.ripe.net

A test on AFRINIC range announcing without RIPE route object
by Lu Heng 15 Jun '18

15 Jun '18

Dear colleagues, In the past three weeks, we have done some tests on 3 AFRINIC /24 which have been announced in the US, Europe, and Asia, by an ARIN ASN, APNIC ASN, and an RIPE ASN. Test results: If it is a direct announce to NTT, Telia, GTT as a small provider and without route object, announcement will not be accepted. All of them accept RIPE route object. If you announce to one of the telecoms, and that telecom happens to accept your announcement without route object, then all the other telecoms will have to accept the announcement without route object. This is simply because big guys trust each other. In the example we tested, we first announced to NTT directly and got rejected. Then we announce to CN2(next generation enterprise network of China telecom). After this NTT accepted the announcement from China telecom without route object created. Current situation: AFRINIC accepts foreign ASN with manual verification of the ownership of the ASN holder as stated by their hostmaster in the mailing list. If you don't own the ASN, they will not create the route object. Despite this, the process is long and unpractical in daily operation. Some providers do accept RPKI. One can create an AFRINIC RPKI that go though the filter, however, not all provider accept RPKI at the moment. 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. I am not opposing to the idea of cleaning up the database, but until things get fixed, the current process will only break networks. -- -- Kind regards. Lu

11 46

Re: [db-wg] A test on AFRINIC range announcing without RIPE route object
by denis walker 14 Jun '18

14 Jun '18

Hi All The co-chairs of the DB-WG are talking in the background to the RIRs about how this change will impact the holders of their address space. We are following the points raised here and checking some issues with the appropriate RIRs. The RIPE NCC Database team is also in the loop of these talks so any relevant points can be included in their impact analysis. As some have already said consensus is not unanimity and there is a consensus to close this security hole in the RIPE Database. Even though the security hole will continue to exist in many alternative and commercial IRRs and will continue to be exploited by abusers for some considerable time. cheersdenisco-chair DB-WG

3 3

query related to Open Source wg talk on blockchain
by Sandra Murphy 18 May '18

18 May '18

(A comment about the presentation that I’m asking here because I wasn’t quick enough in typing in the chat window - I was participating remotely.) There was a question at the mike at the very end of the presentation about blockchain, about the purpose for the work. The answer was that the purpose was to protect origin authorization. That got me thinking about the blockchain model vs the RIPE model. In times past, I’ve seen RIPE reminders to their members that they are responsible for their entire allocation, even if some of it is sub-allocated. And I’ve seen training that carefully instructs the members how to use mnt-by, mat-lower, mat-routes, etc., to retain control over the sub-allocation portions of their address space, but give some control to the recipient. And warnings that lack of care may result in losing authority, which would require correction by the database staff. I did find a FAQ for Sub-allocation that says some of this, so hopefully I am not totally off-base. Is that still the RIPE model, that authority over the sub-allocation is more shared than relinquished? If I understand blockchain properly, it presumes a model where control is given up entirely when an object is transferred. No two entities can have authority over an object. Nothing says I’m right about that, either, of course. —Sandy

2 1

Weird IRR entry
by Brian Rak 18 May '18

18 May '18

Seems like this shouldn't have been allowed to be created: route6: 2001:db8::/32 origin: AS10 mnt-by: EJU created: 2018-02-18T06:45:59Z last-modified: 2018-02-18T06:45:59Z source: RIPE

3 2

comment on comment at mic: database "purpose" vs not-globally-routed prefixes
by Sandra Murphy 17 May '18

17 May '18

(Sorry about this. typed the comment into the chat window, hit submit, got “disconnected” error, reconnected, but too late to comment.) The comment at the mic was that there are many IP prefix resources in the database that are not globally routed, and that those objects were not part of the RIPE database purpose as stated. So collection of personal data for those objects could not rely on the RIPE database purpose for justification. I disagree that the lack of current global routing for an IP prefix means the RIPE database purpose of facilitating coordination does not apply. An allocated prefix can be globally announced at any time. So there’s a need to have the data, anyway. In the current state of routing security, an allocated prefix can be globally announced at any time, not necessarily by the legitimate prefix holder. We’ve seen several examples of some ISP announcing a prefix that seemed not to be in use, sometimes even registering a route object for the announcement, and using that prefix for some unfriendly purpose. So there is still a need to have contact data for a prefix even before the legitimate prefix holder decides to globally announce the prefix. —Sandy

2 1

FW: Weird IRR entry
by Gunnar Guðvarðarson 17 May '18

17 May '18

Yeah, there is also a corresponding ASn aut-num: AS10 as-name: EJU1-RIPE admin-c: EJU1-RIPE tech-c: EJU2-RIPE status: OTHER mnt-by: EJU created: 2018-02-18T06:19:45Z last-modified: 2018-02-18T06:19:45Z source: RIPE AS10 is allocated to ARIN, and is in use by CSNET: as-block: AS8 - AS27 descr: ASN block not managed by the RIPE NCC I reported these objects to ripe-dbm, ops and abuse @ripe.net

1 0

<auto-dbm@ripe.net> is slow this afternoon.
by RIPE Database Administration 16 May '18

16 May '18

Dear Colleagues, Because of a very high level of use this afternoon, the response time of <auto-dbm(a)ripe.net> is longer than normal. I have made contact with those who are responsible and I expect the situation to improve as the machine works through the queue. Please be patient. Obviously we at the RIPE NCC Database Group are continuously working to make the performance of the database as good as possible. However, we cannot make improvements in zero time. We thank you for your co-operation up to now and we ask for your continued co-operation so that everyone receives the best possible service. If you have anymore questions, please contact <ripe-dbm(a)ripe.net>. Regards, Ambrose Magee ____________________________ RIPE Database Administration.

2 2

New on RIPE Labs: The GDPR: Amendments to the RIPE Database
by Mirjam Kuehne 14 May '18

14 May '18

Dear colleagues, This is our fourth in a series of RIPE Labs articles discussing the General Data Protection Regulation (GDPR) implementation. Here we're looking at amendments that will be needed to the RIPE Database in order to ensure GDPR compliance: https://labs.ripe.net/Members/maria_stafyla/how-were-implementing-the-gdpr-… Kind regards, Mirjam Kühne RIPE NCC

1 0

New on RIPE Labs: Out-of-Region ROUTE(6) and AUT-NUM Objects in the RIPE Database
by Antony Gollan 09 May '18

09 May '18

Dear colleagues, In a new article on RIPE Labs, Denis Walker provides some context around the changes being made to the way out-of-region objects are managed and represented in the RIPE Database: https://labs.ripe.net/Members/denis/out-of-region-route-6-and-aut-num-objec… Kind regards, Antony Gollan RIPE NCC

2 1

Re: [db-wg] RIPE database on ftp.ripe.net
by Paul Weiss 08 May '18

08 May '18

Hi Marten, In the directory https://ftp.ripe.net/ripe/dbase/split/ <https://ftp.ripe.net/ripe/dbase/split/> there are lots of "splits", is there an inventory guide so that we can understand which type of data each split contains? We need to access and search for; Company name, Org.number, Country, City, IP-range Can we also ftp download the complete IP Databases per country in Europe? Thanks, Paul Weiss

2 1