- db-wg - mailman.ripe.net

Re: [db-wg] Draft Agenda RIPE76 - Database Working Group
by William Sylvester 26 Apr '18

26 Apr '18

Dear all, Below is the agenda for the Database Working Group for RIPE76. If you have any questions, comments, or requested changes please let the chairs know. Best regards, William & Denis DB-WG Chairs A. Introduction - 5 min * Welcome * Scribe * Jabber * Agenda B. Operational Update RIPE Database - 20 mins Tim Bruijnzeels, RIPE NCC C. Current State of RDAP - 20 mins Andrew Newton, ARIN D. General Data Protection Regulation (GDPR) - 10 mins Maria Stafyla, RIPE NCC E. A modern chatbot approach for accessing RIPE database - 10 mins Laurenz Wagner, Janus Cloud F. NWI-5 Out of region ROUTE(6)/AUT-NUM objects implementation - 5 mins G. NWI - Open Proposals - 10 mins Z. AOB (open discussion)

1 0

Draft Agenda RIPE75 - Database Working Group
by William Sylvester 17 Apr '18

17 Apr '18

Dear all, Below is the draft outline for the Database Working Group agenda for RIPE76. If you have any questions, comments, or requested changes please let the chairs know. Best regards, William & Denis DB-WG Chairs A. Introduction - 5 min * Welcome * Scribe * Jabber * Agenda B. Operational Update RIPE Database - 40 mins Tim Bruijnzeels, RIPE NCC C. NWI - Open Proposals - 10 mins D. General Data Protection Regulation (GDPR) - 10 mins Maria Stafyla, RIPE NCC Z. AOB (open discussion)

1 0

Updating the database via HTTP API - best practices
by Alexander Stranzky 12 Apr '18

12 Apr '18

> What is the current best practice for handling Auth on HTTP API updates to the RIPE database, and is there a roadmap for change that I can consider as I write my tools to publish and maintain objects? Same situation here on my end. Anyways, I'd love to have an authentication method that uses one of my existing RIPE DB key-cert objects (maybe something like an HMAC). Cheers, Alex -- velia.net Internetdienste GmbH * Hessen-Homburg-Platz 1 * D-63452 Hanau Geschäftsführer: Franz G. Köhler, Arek Akilli * AG Hanau * HRB 7588 Tel: +49 6181 1898119 * http://www.velia.net Follow us on twitter: https://twitter.com/velia_net

1 0

Updating the database via HTTP API - best practices
by Andy Davidson 11 Apr '18

11 Apr '18

Hi, I would like to publish information in the RIPE database based on what my single-source-of-truth configuration management system knows and not what I sort of remember when I kind of get around to updating RIPE. Fortunately, there is a splendid looking API for this. The most recent and complete documentation that I can find with support from a search engine is https://github.com/RIPE-NCC/whois/wiki/WHOIS-REST-API. On the subject of Authentication, the document says: "Currently only passwords are supported to authenticate updates”. Is this still up to date and entirely true? Does it mean MD5 password or does this mean I should be able to use something based on my SSO authentication pair to generate a password field? I thought that MD5 had been deprecated in circa. 2015? https://www.ripe.net/ripe/mail/archives/db-wg/2015-June/004666.html What is the current best practice for handling Auth on HTTP API updates to the RIPE database, and is there a roadmap for change that I can consider as I write my tools to publish and maintain objects? Thanks for your help, database-wg & NCC experts, Andy -- Andy Davidson Asteroid International BV https://www.asteroidhq.com @asteroidhq @andyd -------------------------------------------------- Local interconnection. Where you need it.

1 0

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

Getting 'responsible organization' out of RDAP
by Brian Rak 22 Mar '18

22 Mar '18

I've been attempting to use RDAP to verify our customer's IP information, however I'm running into some difficulties due to differences between ARIN's implementation and RIPE's. For example, I'm trying to get the organization name for a particular IP. On ARIN, this is easy. I look through the provided vcards for one where the kind is 'org', and that gives me the information about the organization. (ex: https://rdap.arin.net/registry/ip/66.55.158.27 ) With RIPE's RDAP implementation, this data does not seem to be readily available. For example, if I look at https://rdap.db.ripe.net/ip/195.66.225.160 I'd expect to find the string 'London Internet Exchange Ltd.' somewhere within the response. If I look at the web UI: https://apps.db.ripe.net/db-web-ui/#/query?searchtext=195.66.225.160#result… , this information is easily available. Would it be possible to expand the RDAP results to include organization information? This seems like it would just be another vcard entry, so there really shouldn't be any backwards compatibility issues. Apologies if this isn't the correct list, I can't really find any information about RDAP on RIPE's website.

3 6

Whois Update Server Migration
by Edward Shryane 21 Mar '18

21 Mar '18

Dear Working Group, on Wednesday 21st March, we plan to migrate the Whois Update Server to a new configuration. This will cause a short downtime for Whois updates. Queries will not be affected. We will also create a Service Announcement on the RIPE NCC website. Regards, Ed Shryane RIPE NCC

2 4

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

New on RIPE Labs: Legal Grounds for Lawful Personal Data Processing and the RIPE Database (GDPR)
by Athina Fragkouli 06 Mar '18

06 Mar '18

Dear all, In our third article on the GDPR, we are looking at the legal basis for processing personal data in the RIPE Database when it refers to an individual resource holder or contact person. We will also outline the relevant obligations of the responsible parties. https://labs.ripe.net/Members/Athina/gdpr-legal-grounds-for-lawful-personal… Kind regards, Athina Fragkouli Head of Legal RIPE NCC

1 0

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