- db-wg - mailman.ripe.net

stat.ripe.net down?
by Ronald F. Guilmette 20 Jun '18

20 Jun '18

I've come to rely on the services provided by the stat.ripe.net WHOIS service. Thus it is rather disappointing to find that today, it's down, as least if one is an ordinary sort of bloke like me who is confined to IPv4. % telnet stat.ripe.net whois Trying 193.0.6.150... telnet: connect to address 193.0.6.150: Connection refused Trying 2001:67c:2e8:22::c100:696... telnet: connect to address 2001:67c:2e8:22::c100:696: No route to host telnet: Unable to connect to remote host Did I just miss the memo? Has the stat.ripe.net IPv4 service been taken down deliberately, or is this just a transient sort of outtage? More to the point, what email address should I be writing to in order to make further inquiries about this apparent outtage?

3 2

IRRd re-write
by denis walker 19 Jun '18

19 Jun '18

Colleagues During the current discussion on out-of-region ROUTE objects, Job announced that IRRd is being re-written and will have some 'potentially' fantastic features including 'possibly' authentication against the RIRs number registries. The alternative/commercial IRRs have also been heavily promoted at many points in this discussion as 'the answer' to the current problems. I personally, and some others, have some issues with this. So I thought it appropriate to open a discussion on this issue as it does impact on, or is influenced by, the operation of the RIPE Database. Firstly it is unfortunate that all the RIRs that operate an IRR may not be in a position to accomodate all routing requirements that are currently provided for by the designed security hole in the RIPE Database at the time this security hole will be closed. To push operators to switch to commercial services as the answer simply monetarises routing which, as Randy pointed out, may affect smaller operators more, as perhaps the IPv4 market has done. I looked at the github details of this new IRRd. I get the feeling that this is simply trying to re-invent the RIPE Database software in yet another language. This is being done without the decades of experience, knowledge and understanding that has gone into developing the RIPE Database software on which all 4 IRRs are based that are operated by the RIRs. Job also pointed out that "One of the possible (and desired) extensions is an authorisation link to the authoritative RIR." This suggests some form of cross registry authorisation with/between the RIRs. During the years of debate about these out of region ROUTE objects this has been discussed and virtually dismissed on several occasions. If the RIRs, and certainly the RIPE NCC, are going to devote time, effort and members money to develop some form of authorisation system for a remote IRR to connect to each of the 5 RIR number registries to authorise ROUTE creation, then I personally would prefer to see the development of a single, global IRR operated by the RIRs. This cross registry authorisation is probably the main element of having a single IRR. Currently 4 of the 5 RIRs operate an IRR and they are all based on a version of the RIPE Database software. So we already have a common IRR database format. Add in this cross registry authorisation and we have a global IRR. I don't see the point of putting in the effort to develop a multitude of alternative/commercial IRRs when we can go the other way and have a single, authoritative, free IRR service. We have one internet, one DNS, why not one IRR? I know the first comment is probably going to be, "we already have this with RPKI". But for whatever reason, not all operators use, or want to use, RPKI. That is a reality, just as much as everyone switching to IPv6...not. Since RPKI is not the complete answer, we still need an IRR where the ROUTE objects are validated and trusted. I think the RIRs are in the best position to each develop a trusted IRR linked to their own number registry, then take the leap to create a single IRR. I personally think this is the better way to go than develop secure authorisation modules for IRRd. cheers denis co-chair DB-WG

4 4

Fwd: [ETISALAT DOMAINS TICKET #ZZH-628-73999]: Re: IRRd re-write
by Randy Bush 18 Jun '18

18 Jun '18

could someone unsub these <bleep>s sorry for spamming the list, but the headers have no list whinee address randy

1 0

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 09 May '18

09 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

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

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 15 Feb '18

15 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