February 2018 - db-wg - mailman.ripe.net

<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

Getting fraudulent entries removed
by Brian Rak 07 Apr '18

07 Apr '18

Hi, We've run into an issue where an unknown malicious party appears to have hijacked some of our IP space. They created entries in the RIPE database that they are using to actually get this space announced. What's even worse is their carrier is trying to say these announcements are legitimate because they have IRR entries (which is a whole other issue) What is the process like for actually getting this fraudulent entry removed? I've been in contact with RIPE NCC Support, and they have been super unhelpful (ref case #14523) The fraudulent entry is: https://apps.db.ripe.net/search/lookup.html?source=ripe&key=198.13.32.0/19A… route: 198.13.32.0/19 descr: 2nd route origin: AS39967 mnt-by: ADMASTER-MNT created: 2017-10-13T00:20:08Z last-modified: 2017-10-13T00:20:08Z source: RIPE I should also note that this ASN suspiciously appears to be announcing other people's space as well, but I can only confirm that this particular entry does not belong. I would suspect that their other IRR entries are fake as well. You can verify my request by reaching out to any of the POCs associated with this network: https://whois.arin.net/rest/net/NET-198-13-32-0-1 Thanks, Brian Rak

6 13

Whois release 1.91 in Release Candidate environment, production release planned for 7th March
by Edward Shryane 14 Mar '18

14 Mar '18

Dear Working Group, RIPE Database release 1.91 has been deployed to the Release Candidate environment. If no issues are found, we plan to deploy to production on 7th March. Release 1.91 includes the following main changes : - Removed "abuse-mailbox:" attribute from person,mntner,organisation,irt object types (as part of NWI-7 abuse-c implementation) - Don't allow multiple spaces, tab characters, or multiple lines, in the organisation org-name attribute. - Exclude certain email addresses (such as mailing lists and ticket queues) in abuse-mailbox,e-mail,irt-nfy,mnt-nfy,notify,ref-nfy,upd-to attributes - Added "end of stream" comment to NRTM responses - Fixed inconsistent newlines in --list-versions response The complete list of changes in this release can be found in GitHub: https://github.com/RIPE-NCC/whois/blob/master/changes.txt Please let us know if you see any issues with this release in the RC environment. Regards Ed Shryane RIPE NCC

1 2

NRTM replication inefficiencies
by Job Snijders 21 Feb '18

21 Feb '18

Dear all, There may be some improvement opportunity for NRTMv3. The problem with the RIPE NRTMv2/NRTMv3 format is that it has no 'end-of-stream' indicator, thus making the only way to know that the output has ended (vs. hung/stalled/server dead) is either by observing a time-out & reconnect & compare last serial, or by using single-command connections to the NRTM server - which means even worse performance. When connecting to the RIPE NRTM service and issuing a command like: "-g RIPE:3:11012700-LAST -k" It would be good that when the RIPE NRTM server is done sending its inital blurp of backlogged data, the end of that phase of the stream of objects is marked by the server sending something like: "%CURRENT $TS You are now up to date" ($TS can be a unix timestamp) after this server message the client knows that it can stay connected and that it has received all information so far. I would also welcome an investigation into alternative approaches, (some not-via-WHOIS replication mechanisms), perhaps something over HTTPS can be done? Either way, something more robust would be useful. Kind regards, Job ps. An analogy can be made between BGP route refresh as described in RFC 2918 and Enhanced Route Refresh as described in RFC 7313. One first one didn't have an "End of blurp" marker which negatively impacted its usefulness, the later RFCintroduced the End-of-RIB marker which is very useful.

5 14

Clean up unreferenced maintainers (after 90 days)
by Tim Bruijnzeels 15 Feb '18

15 Feb '18

Dear Working Group, In the light of data protection we already clean up unreferenced organisation, person and role objects, and also mntner-role and mntner-person pairs, 90 days after such objects become unreferenced. So-far unreferenced maintainers are not cleaned up. We have about 8k such objects in the database. These objects are often syntactically incorrect and poorly maintained - so we would like to clean them up automatically 90 days after they become unused. Please let us know if you see any issues with this. Kind regards, Tim Bruijnzeels Assistant Manager Software Engineering and Senior Technology Officer RIPE NCC

6 8

NWI-5 Out of region ROUTE(6)/AUT-NUM objects implementation request
by William Sylvester 14 Feb '18

14 Feb '18

DB-WG Members, Support was shown for the proposal NWI-5 and no objections were raised after this round of discussion. At this time, the chairs request that the RIPE NCC schedule implementation of NWI-5 as described. This request is to remove “origin:” and flag “route:” objects as specified. The db-wg therefore ask the RIPE NCC to prepare an impact analysis, followed by an implementation plan and timeline for this request and the other issues raised in the problem solution of NWI-5 as follows: 1) Remove the "origin:" authorization requirement. 2) Flag "route:" objects for non-RIPE-managed space with "source: RIPE-NONAUTH" to identify non-authoritative data. Thank you all for your work on this proposal! Kind regards, William & Denis DB-WG co-chairs

11 21

Implementation of NWI-5 out of region ROUTE(6) objects
by denis walker 12 Feb '18

12 Feb '18

Colleagues Based on the proposal by Tim for NWI-5 and the following discussions, the DB-WG co-chairs would like the RIPE NCC to schedule implementation of the following actions: -Remove the ASN authorisation requirement for ROUTE(6) object creation -Deprecate the "mnt-routes:" attribute in the AUT-NUM object -Remove the 'pending object creation' functionality for route creation -Create the source 'RIPE-NONAUTH' -Move all ROUTE(6) objects relating to non RIPE managed address space to this new source (pending eventual deletion after further discussion) -Move all non ripe managed AUT-NUM objects to this new source (pending eventual deletion after further discussion) -Adjust the query service as suggested in Tim's proposal -Disallow creation of any new AUT-NUM or ROUTE(6) objects in the RIPE Database for non RIPE managed resources, but allow existing objects to be modified or deleted -Remove the "mnt-routes:" attribute from all the placeholder INET(6)NUM objects in the RIPE Database for non RIPE managed address space -Delete the MNTNER object with the public password ('fixing' any other database objects that may refer to it) -Update all documentation to reflect the new processes -Ensure that the inter RIR transfer process for resources moving into the RIPE managed address space does not allow the transfer of ROUTE(6) objects from source RIPE-NONAUTH to source RIPE without the agreement of the resource holder cheersDenis & Williamco-chairs DB-WG

1 0

Creation of new out of region ROUTE(6) objects
by William Sylvester 12 Feb '18

12 Feb '18

Working Group Members, Following the last call for comments about creating out of region ROUTE(6) objects in the RIPE Database: https://www.ripe.net/ripe/mail/archives/db-wg/2018-January/005807.html There were a few comments to discontinue this service. There were no comments supporting the continuation of this service. The DB-WG co-chairs therefore draw a consensus on discontinuing this service. William & Denis DB-WG co-chairs

1 0

New on RIPE Labs: How We're Implementing the GDPR - the RIPE Database
by Mirjam Kuehne 01 Feb '18

01 Feb '18

Dear colleagues, This is our second in a series of articles discussing the General Data Protection Regulation (GDPR) implementation. Here we are looking at the purpose for which personal data is collected and publicly accessed through the RIPE Database, as well as other aspects of the data protection legislation, such as the legal basis for this processing, data removal procedures, and so on: https://labs.ripe.net/Members/Athina/how-we-re-implementing-the-gdpr-the-ri… Kind regards, Mirjam Kühne RIPE NCC

1 0