- db-wg - mailman.ripe.net

PERSON objects in the RIPE Database
by denis walker 07 Oct '18

07 Oct '18

Colleagues, I will start with a blunt question, then give some arguments for my concern. In May the RIPE NCC told me there are more than 2 million PERSON objects in the RIPE Database. That is almost 25% of the objects in the database. Who are these people and why do we hold so much personal data? At RIPE 76 the RIPE NCC legal team gave a presentation on GDPR and the RIPE Database. The basis of that presentation seemed to be that Article 3 of the RIPE Database Terms and Conditions defined one of the purposes of the database as: Facilitating coordination between network operators (network problem resolution, outage notification etc.) It was argued that this justifies the inclusion of personal data in the RIPE Database so that these people can be contacted in the event of network operational issues, even by people who have no business relationship with these contacts. But this Article makes no mention of 'personal' contact information. It was also mentioned that some personal data is included for policy reasons. The IPv4 Address Allocation and Assignment Policy makes a couple of references to contact data. In 4.0 Registration Requirements it says: All assignments and allocations must be registered in the RIPE Database....Registration data (range, contact information, status etc.) must be correct at all times This clearly associates contact information with the necessary registration. But this does not specify that it has to be 'personal' contact information. In 6.2 Network Infrastructure and End User Networks it says: When an End User has a network using public address space this must be registered separately with the contact details of the End User. Where the End User is an individual rather than an organisation, the contact information of the service provider may be substituted for the End Users. This clearly has the intent of avoiding the need to enter 'personal' data as contact information. In the IPv6 Address Allocation and Assignment Policy it is even more vague saying in 3.3 Registration: Internet address space must be registered in a registry database accessible to appropriate members of the Internet community. This is necessary to ensure the uniqueness of each Internet address and to provide reference information for Internet troubleshooting at all levels, ranging from all RIRs and IRs to End Users. The goal of registration should be applied within the context of reasonable privacy considerations and applicable laws. 'Reference' information and concerns about privacy again clearly indicate that the intent is to avoid using 'personal' data for the contacts. This does raise a number of questions: -Should I believe that we really do have more than 2 million individual people in this region who can seriously address technical or administrative questions on Internet resources or network operational issues? -Why is it considered necessary for contacts to be identifiable people rather than roles? -Abuse-c was intentionally designed to reference a ROLE object, which no longer needs to have any referenced PERSON objects, to avoid the need to enter personal data, why can't technical matters be addressed in the same way? The purpose in the Terms and Conditions may define a reason for holding contact information, but it doesn't justify this level of personal data being held in the database. Perhaps it's time to review what is meant by 'contact information'. What is really needed to satisfy this purpose? For example, why do we need an address for a technical contact who may need to be contacted in the event of an operational issue? No one is going to go to that address or post a letter. As always your thoughts and opinions are welcome... cheers denis co-chair DB WG

4 7

Re: [db-wg] WG Chair Selection - Call for Discussion
by William Sylvester 05 Oct '18

05 Oct '18

WG Members, Congratulations to everyone on the success of NWI-5! With the deployment behind us and everyone back from holiday in August we are moving to the next step in our chair selection process. This email opens the two (2) weeks of chair selection discussion. All members of the community are encourage to make a discussion and express their approval or otherwise of the presented candidates. The candidates are as follows and have either made their interest known on this mailing list, or directly to the chair(s). I encourage each candidate to reiterate their qualifications to the mailing list. Piotr Strzyzewski Sean Stuart As members of this working group please discuss your approval or otherwise of each candidate. Best regards, Denis & William DB-WG Chairs

4 3

"key-cert" objects - emails listed as "owner" even thou id has been revoked
by netravnen＠gmail.com 03 Oct '18

03 Oct '18

Hi db-wg, Was updating my key-cert object in the database. And was wondering if it is by design revoked key id's is listed as owner of the key? (I would normally expect revoked id's not being listed inside key-cert objects.) The Explanation =============== I have several gpg id's as part of the key. Half is active. Half is revoked id's. All id's; even the revoked ones; is being listed as "owner:" when viewing the key-cert object in the database. -Netravnen

2 1

alloclist.txt
by nusenu 01 Oct '18

01 Oct '18

Hi, before I start parsing the alloclist.txt [1] file (with multiline context) I was wondering if there is a more parse-friendly version of that? (one record per line?) thanks, nusenu [1] https://ftp.ripe.net/pub/stats/ripencc/membership/alloclist.txt -- https://twitter.com/nusenu_ https://mastodon.social/@nusenu

2 2

RIPE Policy Proposal 2018-05 Aims to Publish Legal Address Information
by Marco Schmidt 27 Sep '18

27 Sep '18

Dear colleagues, We just published the RIPE Policy proposal, 2018-05, "Publication of Legal Address of Internet Number Resource Holder", to the RIPE NCC Services Group mailing list. The goal of the proposal is for the RIPE NCC to publish the validated legal address information of holders of Internet number resources. As the publishing of such data likely will happen in the RIPE Database, we want to notify the Database Working Group. You can find the full proposal at: https://www.ripe.net/participate/policies/proposals/2018-05 We encourage you to review this proposal and send your comments to <ncc-services-wg(a)ripe.net> before 26 October 2018. Kind regards, Marco Schmidt Policy Officer RIPE NCC Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum

1 0

Re: [db-wg] Draft Agenda RIPE77 - Database Working Group
by William Sylvester 25 Sep '18

25 Sep '18

Dear Working Group Members, Below is the DRAFT agenda for the Database Working Group for RIPE77. If you would like to present please submit your content as soon as possible to the chairs. 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 – 45 mins Edward Shryane, RIPE NCC C. Discussion: PERSON objects in the RIPE Database – 15 mins Denis Walker D. NWI - Open Proposals – 15 mins Z. AOB (open discussion)

1 0

PERSON objects in the RIPE Database
by Alexander Stranzky 21 Sep '18

21 Sep '18

On 20/09/2018 15:04, denis walker via db-wg wrote: > Colleagues, > > I will start with a blunt question, then give some arguments for my > concern. In May the RIPE NCC told me there are?more than 2 million > PERSON objects in the RIPE Database. That is almost 25% of the objects > in the database. Who are these people and why do we hold so much > personal data? Hello, I suspect that many of these objects are old (pre-API) and/or duplicates. Before RIPE had a REST API (and I can't tell how many ISPs still use emails to create their resources) automatically fetching, linking, and updating a RIPE object was a pain (as is the current situation with APNIC) and likely involved someone to create the email personally. Hence going the easy route--making new entries every time. Regards, Alexander Stranzky -- velia.net Internetdienste GmbH * Hessen-Homburg-Platz 1 * 63452 Hanau Geschäftsführer: Franz G. Köhler, Arek Akilli * AG Hanau * HRB 7588 Tel: +49 6181 1898119 * http://www.velia.net

5 7

Re: [db-wg] PERSON objects in the RIPE Database
by Cynthia Revström 20 Sep '18

20 Sep '18

Hi, I am not sure how the best way to do this but maybe check the database for person handles with identical name, address, phone number and such things. Also maybe if we could take a look at the amount of person handles that are not used at all in any other object, and potentially delete them. Kind regards, Cynthia Revström On 2018-09-20 14:57, Alexander Stranzky via db-wg wrote: > On 20/09/2018 15:04, denis walker via db-wg wrote: >> Colleagues, >> >> I will start with a blunt question, then give some arguments for my >> concern. In May the RIPE NCC told me there are?more than 2 million >> PERSON objects in the RIPE Database. That is almost 25% of the objects >> in the database. Who are these people and why do we hold so much >> personal data? > Hello, > > I suspect that many of these objects are old (pre-API) and/or > duplicates. Before RIPE had a REST API (and I can't tell how many ISPs > still use emails to create their resources) automatically fetching, > linking, and updating a RIPE object was a pain (as is the current > situation with APNIC) and likely involved someone to create the email > personally. Hence going the easy route--making new entries every time. > > Regards, > Alexander Stranzky >

2 1

Whois release 1.92.6 deployed to Production
by Edward Shryane 20 Sep '18

20 Sep '18

Dear Working Group, we have deployed a bug-fix release 1.92.6 to production that fixes a bug when updating an object with a lowercase source value (e.g. "source: ripe"). The release notes have been updated: https://www.ripe.net/manage-ips-and-asns/db/release-notes/ripe-database-rel… Regards Ed Shryane RIPE NCC

1 0

avoiding RIPE IRR vs. RPKI ROA mismatches/inconsistencies
by nusenu 14 Sep '18

14 Sep '18

Dear DB Working Group, when looking into RPKI and RIPE IRR coverage I stumbled on prefixes that are covered by a RIPE route object and a RPKI ROA, which is great, but there are cases where these records make conflicting statements about the origin of a prefix. example: 185.46.20.0/22 origin according to ROA: AS199785 origin according to route object: AS61952 origin according to RIS: AS61952 (matches route object) Note: this is just an example to better illustrate the issue. (I didn't do a comprehensive analysis to be able to tell how often this is the case but for a sample of ~1900 prefixes I found 3 such occurrences.) Since route objects and ROAs are created by the prefix holders this is possible (human mistake). Are there any measures in place to prevent or at least warn about the inconsistency when the IP holder creates/updates route objects and ROAs that would result in inconsistencies? What do you think about an UI feature that says something like: "You are about to change/create the route object for prefix ... would you also like to update the existing ROA to match the route object and help avoid inconsistencies?" [ ] yes [ ] no, I know what I'm doing, I'll fix the mismatch manually similarly for updating/creating ROAs. Should there even be a 'No' option? Should the question even be exposed to the user or should records simply be synced automatically once one of either is changed by the IP holder? and simply showing an info like: "We took care of updating your ROA/route object to keep in sync." In case there are well established best practices for an ASN change of a prefix these best practices should be incorporated (i.e. delete the route object and ROA, change the actual announcement in BGP, create new route and ROAs that match the announcement) kind regards, nusenu -- https://twitter.com/nusenu_ https://mastodon.social/@nusenu

2 3

Whois release 1.92.5 deployed to Production
by Edward Shryane 11 Sep '18

11 Sep '18

Dear Working Group, after deploying the NWI-5 changes last week, we found an issue preventing out of region transfers (the top-level placeholder template still referenced the RPSL maintainer). We have now deployed a bug-fix release 1.92.5 to production that fixes this issue. Regards Ed Shryane RIPE NCC

1 0

Re: [db-wg] WG Chair Selection - Call for Discussion
by Erik Bais 10 Sep '18

10 Sep '18

In case of 1 chair this time, my vote would be for Sean Stuart. Piotr already got selected for the RIPE exec board last meeting, I’m sure he has enough to deal with on that ‘WG’ 😉 Sean has been looking for a way to volunteer for a while in the community and his background could provide a good fit for the role imho. Regards, Erik Bais From: db-wg <db-wg-bounces(a)ripe.net> on behalf of William Sylvester via db-wg <db-wg(a)ripe.net> Reply-To: William Sylvester <william.sylvester(a)addrex.net> Date: Wednesday 5 September 2018 at 22:32 To: "db-wg(a)ripe.net" <db-wg(a)ripe.net> Subject: Re: [db-wg] WG Chair Selection - Call for Discussion WG Members, Congratulations to everyone on the success of NWI-5! With the deployment behind us and everyone back from holiday in August we are moving to the next step in our chair selection process. This email opens the two (2) weeks of chair selection discussion. All members of the community are encourage to make a discussion and express their approval or otherwise of the presented candidates. The candidates are as follows and have either made their interest known on this mailing list, or directly to the chair(s). I encourage each candidate to reiterate their qualifications to the mailing list. Piotr Strzyzewski Sean Stuart As members of this working group please discuss your approval or otherwise of each candidate. Best regards, Denis & William DB-WG Chairs

2 1

Re: [db-wg] WG Chair Selection - Call for Discussion
by Andy Davidson 06 Sep '18

06 Sep '18

Hi, William Thank you kindly for working on this process. Please could you confirm how many seats are open for selection this time? Are we selecting for one seat or two from this list of people? Andy

2 1

Status Update on NWI-5 Deployment: Completed
by Nathalie Trenaman 06 Sep '18

06 Sep '18

Dear colleagues, On 4 September, 21:55 UTC+2, we completed the following changes needed for NWI-5: Out of region ROUTE(6)/AUT-NUM objects. - Removal of mnt-routes from AUT-NUM objects - Removal of the RIPE-NCC-RPSL-MNT - Update the source attribute for out-of-region ROUTE(6) objects to RIPE-NONAUTH On 5 September, 04:32 UTC+2, we also completed the new database dump and split files at: ftp://ftp.ripe.net/ripe/dbase/ <ftp://ftp.ripe.net/ripe/dbase/> We have updated the release notes accordingly: https://www.ripe.net/manage-ips-and-asns/db/release-notes/ripe-database-rel… <https://www.ripe.net/manage-ips-and-asns/db/release-notes/ripe-database-rel…> Of course, we will keep monitoring the impact on operators. We would like to thank everyone who contributed with valuable input during the test and deployment phases. Kind regards, Nathalie Trenaman Product Manager RIPE NCC

2 1

Implementation plan and time line for NWI5 - Out-of-region ROUTE(6) objects and removal of ASN authorisation for ROUTE(6) object creation.
by Nathalie Trenaman 05 Sep '18

05 Sep '18

Dear colleagues, On Tuesday, 4 September, we will make changes to the way out-of-region objects are handled in the RIPE Database, as directed by the RIPE Database Working Group. We will implement the following changes in this order between 09:00 and 15:00 UTC+2. 1. The RIPE Routing Registry will no longer support the creation of out-of-region ROUTE(6) and AUT-NUM objects 2. The creation of ROUTE(6) objects will no longer need authorisation from the ASN holder 3. Existing out-of-region objects will have their "source:" attribute changed to "RIPE-NONAUTH” For users of NRTM, these changes will be reflected on the FTP website after 00:00 UTC+2 on Wednesday, 5 September. You can find our implementation plan at: https://www.ripe.net/manage-ips-and-asns/db/impact-analysis-for-nwi-5-imple… <https://www.ripe.net/manage-ips-and-asns/db/impact-analysis-for-nwi-5-imple…> We also published an article on RIPE Labs with some background and additional context: https://labs.ripe.net/Members/denis/out-of-region-route-6-and-aut-num-objec… <https://labs.ripe.net/Members/denis/out-of-region-route-6-and-aut-num-objec…> We will inform the Database Working Group once all changes have been implemented. Kind regards Nathalie Trenaman Product Manager RIPE NCC

2 2

Status Update on NWI-5 Deployment
by Nathalie Trenaman 04 Sep '18

04 Sep '18

Dear colleagues, We are currently deploying the changes for NWI-5 in the RIPE Database. At the moment, we have successfully rolled out: - the removal of mnt-routes from AUT-NUM objects - removal of the RIPE-NCC-RPSL-MNT The rollout of updating the “source:" attribute to RIPE-NONAUTH on out-of-region ROUTE, ROUTE6 and AUT-NUM objects is taking slightly longer than expected. This means that the source will gradually be updated on out-of-region objects for the rest of today as the script runs. Kind regards, Nathalie Trenaman Product Manager RIPE NCC

1 0

Increasing the Limit of IP Addresses Used for the NRTM Service
by Theodoros Polychniatis 30 Aug '18

30 Aug '18

Dear colleagues, We would like to increase the limit of IP addresses used with the NRTM service. The limit of two addresses per member was set eight years ago and we might be able to handle up to three times that amount now. We are in the process of determining the new limit. If you are interested in helping us test the capacity of our NRTM servers, please open a ticket with us to add more IP addresses to the ones you currently use: https://www.ripe.net/contact-form?topic=ripe-dbm&show_form=true Kind regards, Theodoros Polychniatis Manager SW Engineering RIPE NCC

1 0

improve --list-sources query to display latest serial?
by Job Snijders 30 Aug '18

30 Aug '18

Hi all, It appears there currently is no easy way to retrieve the current serial from the RIPE DB. We're implementing some software to monitor whether our local mirror is wildly out of sync with the RIPE DB or not. I kind of expected th serial to be listed in the --list-sources command, but that field is set to 0. hanna:~ job$ whois -h whois.ripe.net -- --list-sources | grep RIPE % This is the RIPE Database query service. % The RIPE Database is subject to Terms and Conditions. RIPE:3:N:0-0 RIPE-GRS:3:N:0-0 % This query was served by the RIPE Database Query Service version 1.91.2 (HEREFORD) In comparison, IRRd will display the current serial when the !j query is issued: hanna:~ job$ whois -h rr.ntt.net -- '!jNTTCOM' A25 NTTCOM:N:0-978492:978492 C hanna:~ job$ I came up with a really ugly oneliner: $ whois -h 193.0.6.135 -p 4444 -- \ "-g RIPE:3:$(curl -s https://ftp.ripe.net/ripe/dbase/RIPE.CURRENTSERIAL)-LAST" | \ grep -v : | sed '/^$/d' | tail -n 2 | head -1 | awk '{ print $NF }' 42486238 Depending on the time of day that oneliner may be quite quick, or take several minutes to complete... obviously not ideal. Can --list-sources perhaps be improved to list the current serial? Kind regards, Job

2 2

improve --list-sources query to retain history
by Erik Bais 30 Aug '18

30 Aug '18

If the WG is going to look at improving the --list-sources code base, I have something that I would love to see on the wish list to be implemented.. Maintaining history (upto the point where a prefix is leaving the RIPE DB, due to an inter-rir transfer. ) is helpful to see who the previous holder was or where the prefix came from. This is particular the case with Legacy prefixes that are being split up.. as it is current practise to delete the parent prefix after a prefix split and transfer. Once the parent is deleted, you can't list or request the history of the parent prefix anymore. If the historic --list-versions and --show-version could be preserved somehow (on the original prefix size.. instead of them being deleted..), that would be very helpful. Regards, Erik Bais

2 1

NWI-5 changes deployed to RC (Release Candidate) environment
by Nathalie Trenaman 30 Aug '18

30 Aug '18

Dear Colleagues, Following the implementation plan for NWI-5 (Out-of-region ROUTE(6) objects and removal of ASN authorisation for ROUTE(6) object creation) we have now deployed the NWI-5 changes to the RC (Release Candidate) environment. The RC environment allows you to test the impact of the changes before we will go to production on 4 September 2018. Changes include: - removal of mnt-routes from aut-num objects - updating the source: attribute to RIPE-NONAUTH on out-of-region route,route6 and aut-num objects - removal of the RIPE-NCC-RPSL-MNT In this RC release, the FTP split files, the database dump and the NRTM stream will contain objects with the sources RIPE and RIPE-NONAUTH. In the next release (in the coming weeks), there will be two NRTM streams, two database dumps and also two sets of split files, one per source. We will separately announce this release to the Database Working Group. We encourage you to test the impact of the NWI-5 changes on your scripts and tools and report any issues you may find to ripe-dbm(a)ripe.net <mailto:ripe-dbm@ripe.net> Information about Release Candidate can be found at: https://www.ripe.net/manage-ips-and-asns/db/release-notes/ripe-database-rel… <https://www.ripe.net/manage-ips-and-asns/db/release-notes/ripe-database-rel…> The full NWI-5 implementation plan can be found at: https://www.ripe.net/manage-ips-and-asns/db/impact-analysis-for-nwi-5-imple… <https://www.ripe.net/manage-ips-and-asns/db/impact-analysis-for-nwi-5-imple…> Kind regards, Nathalie Trenaman Product Manager

2 2

Incorrect RDAP response
by Brian Rak 25 Aug '18

25 Aug '18

https://rdap.db.ripe.net/ip/24.235.22.0/23 This will just infinitely redirect between ARIN and RIPE: $ wget https://rdap.arin.net/registry/ip/24.235.22.0/23 --2018-08-24 14:00:05-- https://rdap.arin.net/registry/ip/24.235.22.0/23 Resolving rdap.arin.net... 2001:500:a9::160, 2001:500:31::160, 2001:500:13::160, ... Connecting to rdap.arin.net|2001:500:a9::160|:443... connected. HTTP request sent, awaiting response... 303 See Other Location: https://rdap.db.ripe.net/ip/24.235.22.0/23 [following] --2018-08-24 14:00:06-- https://rdap.db.ripe.net/ip/24.235.22.0/23 Resolving rdap.db.ripe.net... 2001:67c:2e8:22::c100:68e, 193.0.6.142 Connecting to rdap.db.ripe.net|2001:67c:2e8:22::c100:68e|:443... connected. HTTP request sent, awaiting response... 301 Moved Permanently Location: https://rdap.arin.net/registry/ip/24.235.22.0/23 [following] --2018-08-24 14:00:06-- https://rdap.arin.net/registry/ip/24.235.22.0/23 Connecting to rdap.arin.net|2001:500:a9::160|:443... connected. HTTP request sent, awaiting response... 303 See Other Location: https://rdap.db.ripe.net/ip/24.235.22.0/23 [following] --2018-08-24 14:00:07-- https://rdap.db.ripe.net/ip/24.235.22.0/23 Connecting to rdap.db.ripe.net|2001:67c:2e8:22::c100:68e|:443... connected. HTTP request sent, awaiting response... 301 Moved Permanently Location: https://rdap.arin.net/registry/ip/24.235.22.0/23 [following] --2018-08-24 14:00:07-- https://rdap.arin.net/registry/ip/24.235.22.0/23 Connecting to rdap.arin.net|2001:500:a9::160|:443... connected. HTTP request sent, awaiting response... 303 See Other It seems to be a RIPE issue though, because RIPE has valid data when I query via the web UI: https://apps.db.ripe.net/db-web-ui/#/query?searchtext=24.235.22.0%2F23

2 1

The Ongoing Summer of Hijacks: MNT-SERVERSGET / dnsget.top
by Ronald F. Guilmette 23 Aug '18

23 Aug '18

The entire set of objects in the RIPE WHOIS data base that are currently registered with mnt-by: MNT-SERVERSGET is listed here: https://pastebin.com/raw/GiYWxHMh Among this set of objects there are 235 separate route objects. Evidence indicates persuasively that some sizable fraction of these RIPE- registered route objects are fradulent and are simply there to provide cover for multiple IPv4 address block hijacks. The presence of these objects in the data base permits the following set of ASNs to claim that they are acting "legitimately" even as they route these hijacked blocks: AS9009 M247 Ltd (UK) AS43350 NFOrce Internet Sevices (Netherlands) AS57129 Optibit, LLC (Russia) AS197328 Istanbuldc Veri Merkezi Ltd. Sti (Turkey) AS202287 Men Danil Valentinovich (Russia) AS204895 Santa Plus, LLC (Russia) The total amount of IPv4 space encompassed within the set of route objects registered with mnt-by: MNT-SERVERSGET at the present time amounts to eight hundred and fifty nine (859) /24 blocks. Of these, only three hundred and five (305) actually have correctly functioning and properly delegated reverse DNS at the present time, and even among those, only two hundred and two (202) have functioning reverse DNS delegations to the prefered name servers of MNT-SERVERSGET, which is to say the name servers ns5.dnsget.top and ns6.dnsget.top. The bottom line is that it appears that, at the present time, something less than 1/4 of all of the IPv4 address space currently registered in the RIPE data base (via route objects) by and to MNT-SERVERSGET is space for which a plausible case could be made that the blocks in question are actually legitimately assigned to and/or under the legitimate control of whoever or whatever is MNT-SERVERSGET. The other 3/4ths of the IPv4 space in question has provenance which is, at best, dubious. Due to its use of little country-of-registration flags for each IP address block, the web site bgp.he.net provides the most visually obvious indications of at least two of the specific block hijacks in this case, specifically the hijacks of 27.103.192.0/19 and 36.0.192.0/19 by AS57129: https://bgp.he.net/AS57129#_prefixes Based upon the foregoing, I hereby respectfully request RIPE NCC to undertake an immediate and conmprehensive review of all objects in the data base that are currently registered with mnt-by: MNT-SERVERSGET. Additionally, I also respectfully request RIPE NCC to publish the results of this review to the mailing lists of the Database Working Group and the Anti-Abuse Working Group. The charters of both of these Working Groups are directly relevant to this issue, and there exists neither need nor reason to simply sweep this issue quietly under the carpet, as has been done in previous and similar cases. Cases such as this, and the two others of similar magnitude that I have publicly disclosed just this summer, affect the operation of, the stability of, and the continued enjoyment of the entire planetary Internet and its billions of users. Despite its status as a strictly private corporation, RIPE has a public responsibility, not only to handle such incidents responsibly and competently, but to show the world that it is ready, willing, and able to do so. The responses of RIPE to prior instances of this exact type of bad behavior have been largely or entirely cloaked in secrecy, presumably to protect the guilty. This longstanding and antiquated tradition of omerta within the RIPE community is unambiguously counterproductive to the goal of a well-managed and properly fuctioning Internet. Just as importantly, it naturally gives rise to unavoidable questions about the actual competence of, and capabilities of RIPE NCC staff as they attempt to deal with such incidents. I personally feel that RIPE NCC staff are doing the best they can when responding to incidents such as this, but the tradition of playing "hide the ball" with respect to their actions in such cases reflects badly on them, and badly on RIPE generally. It certainly raises doubts about RIPE's claim to authority over even its own data base. Lastly, I respectfully request both the RIPE Executive Board and the RIPE membership to make plain and explicit their respective intentions with regards to the various bad actors that have been caught, and that may in future be caught red handed engaging in the deliberate and premeditated corruption of the RIPE data base. To date, the policies an actions that RIPE applies, or which RIPE may apply to such bad actors have been shrouded in apparently deliberate secrecy and mystery. To put this request in more concrete terms, I would like to know if RIPE and the Executive Board actually and deliberately intend to take no action whatsoever with respect to the ongoing RIPE memberships of clearly identified bad actors, specifically, in this case, whatever persons or entities are currently hiding behind the RIPE WHOIS handle MNT-SERVERSGET (aka AS202287 and AS202275), which would appear to be this specific entity / RIPE member: https://www.ripe.net/membership/indices/data/ru.danil.html Is it the express intention of both the Board and the RIPE membership to simply deprive this bad actor of just those fradulent data base entries that have effectively legitimized his/her/its fradulent routing announcements? Is it the express intention of both the Board and the RIPE membership to simply make this bad actor give back what he has stolen, and to otherwise take no action, just as the response has been in the two other and similar cases that have also arisen in the RIPE region and that I have also publicly reported on this summer? https://mailman.nanog.org/pipermail/nanog/2018-June/096034.html https://mailman.nanog.org/pipermail/nanog/2018-July/096437.html My question is prompted by the following simple facts. In the two prior cases cited above, and also in the one I am presenting here today, the bad actors involved were seen to have not only hijacked large swaths of IP address space that clearly didn't belong to them, but also, as in the case I am presenting today, these same bad actors additionally acted to corrupt the RIPE data base with premeditated and deliberately fradulent entries. Nonetheless, and regardless of these attacks on the reliability and trustworthyness of the RIPE data base, to date it appears that no action whatsoever has been taken which might affect the ongoing RIPE memberships of the relevant parties and bad actors involved, and they are all still members in good standing of RIPE at the present time: https://www.ripe.net/membership/indices/data/pt.bitcanal-pt.html https://www.ripe.net/membership/indices/data/ua.d2investukraine.html https://www.ripe.net/membership/indices/data/bz.universal.html This is, to say the least, puzzling. I would like to know when, where, and how the Executive Board and/or the RIPE membership reached the altogether dubious conclusion that the best possible way to deal with bad actors such as these is to make them give back -just- the stuff the stole, and then to otherwise impose no penality of any kind, thus allowing them to live on, so that they may hijack another day. Whether this policy is a result of either deliberation or default, it *does* appear to be the policy, based on the evidence. Without intending to be rude, I feel that I must ask the obvious question: In what Universe does this otherwise admirable and generous Christian policy of "turning the other cheek" with respect to such verified bad actors have any effect other than encouraging the next hijacker, and then next one, and the one after that? Has either the Board or the membership even ever seriously debated what penalties should be imposed upon those members who are caught red handed deliberately corrupting the RIPE data base? Is the present RIPE policy of "forgive and forget" with respect to such travesties a product of anyone's intentional design, or is it instead merely the result of utter apathy and indifference on the part of the entire RIPE community? In either case, I believe it to be self evident that the time is... ummm... blooming, blossoming, burgeoning, flourishing, and flowering for this policy to be reexamined and revised. From where I am sitting it is self evident that the current policy of turning a blind eye to these events, and to the bad actors behind them is quite clearly encouraging others to follow suit and to themselves undertake the exact same sorts of travesties. Why shouldn't they? There is no downside. At the very worst, one is simply made to give back all of the stuff that one has stolen, and one is then allowed to go on one's merry way. Regards, rfg P.S. As incensed as I am at the fact that the above named bad actors have been allowed not only to retain their RIPE memberships, but also, apparently, 100% of their legitimately-allocated number resources, this is not even nearly as utterly appalling and inexplicable as the fact that two of the bad actors with direct and provable connections to the prior instances of hijacking that I have reported on publicly this summer have been allowed to remain as officially recognized RIPE IP brokers: https://www.ripe.net/manage-ips-and-asns/resource-transfers-and-mergers/bro… I am referring here specifically to Ebonyhorizon Telecomunicacoes Lda (aka Bitcanal) and also to NetAssist LLC (AS29632), which conveniently continues to maintain its association with, and peering arrangements with both AS57166 aka D2 International Investment Ukraine, Ltd. and, indirectly via D2, AS205869 aka Universal IP Solution Corp., both of which apparently continue to this day to try their best to hijack, either directly or indirectly, via AS Path fraud, a number of IPv4 blocks that clearly do not belong to any of these three Ukranian entities: https://bgp.he.net/AS57166#_peers https://bgp.he.net/AS205869#_peers https://bgp.he.net/AS29632#_peers What IP blocks are these two officially recognized RIPE IP brokers, Ebony Horizon and NetAssist brokering, exactly? Are they blocks that have been successfully hijacked? Does either RIPE or RIPE NCC even know? Does either RIPE or RIPE NCC even care? (One cannot help but wonder what might occur if RIPE were put in charge of distributing meat supplies within Europe. Would RIPE officially designate the McDonald's "Hamburglar" as RIPE's officially recognized agent for said distributions?) I guess that, in the end, all of the questions I have raised above can be boiled down to just one simple question: Who exactly does one need to either kill or maim or seriously wound in order to get kicked out of this organization (RIPE)? Regards, rfg P.P.S. Among the set of six companies / ASNs listed toward the top of this message as possible facilitators of the current hijacks of MNT-SERVERSGET, three are already fairly well known... at least in anti-spam circles... as being among "the usual suspects" when it comes to facilitating spamming and spammers. And no, I do not care to publicly specify which three. It may be true, as the saying goes that "On the Internet, nobody knows that you're a dog", but memories are long, and people don't forget if your company has been repeatedly caught acting like one.

3 4

Re: [db-wg] [anti-abuse-wg] The Ongoing Summer of Hijacks: MNT-SERVERSGET / dnsget.top
by Ronald F. Guilmette 16 Aug '18

16 Aug '18

In message <8A9C974B-FFA9-421C-B5ED-90E95624A8FE(a)a2b-internet.com>, Erik Bais <ebais(a)a2b-internet.com> wrote: >So the question that I have with all the information that you stated here. >- Are they doing something (Other than 'probably' leasing IP space) wrong?? The answer to that question is a clear "yes" and indeed, the events that have followed in the wake of my posting of only a few days ago have actually proven that to be the case, beyond a reasonable doubt. There are two key facts that support this view. First, China is not in the habit of allowing mysterious Russians to route their IP space for them. Call it a matter of national pride, or a matter of national security, or something else. It doesn't matter. The Chinese simply don't allow this sort of thing. I challenge you to find an example, i.e. _any_ example, that will prove this assertion wrong. Second, and even more convincingly, someone somewhere (perhaps someone within RIPE NCC) clearly understood that some or all of the route objects that were in the data base as recently as last week, and that were associated with MNT-SERVERSGET were in fact fradulent, and as a result, _many_ of these route objects have now been quietly removed from the data base. In my prior posting, I specifically called out the following two route objects for special attention: ======================================================================== route: 27.103.192.0/19 origin: AS204895 mnt-by: MNT-SERVERSGET created: 2018-07-02T07:30:29Z last-modified: 2018-07-02T07:30:29Z source: RIPE ======================================================================== route: 36.0.192.0/19 origin: AS204895 mnt-by: MNT-SERVERSGET created: 2018-07-02T07:30:55Z last-modified: 2018-07-02T07:30:55Z source: RIPE ======================================================================== Since my posting, these routes objects, *and numerous others* (full list available upon request) have been withdrawn from the data base *by someone*. By your question Erik, are you attempting to deny that these objects existed in the data base, as recently as last week? By your question, are you attempting to deny that these routes have since been removed from the data base? By your question, are you attempting to assert that these routes... and the several others that have now also been quietly and mysteriously disappeared from the data base... were anything other than blatantly and obviously fradulent? >- Are the leased or used prefixes used to send out spam or host malware or >do something else that is frowned upon ? or even illegal.. ( And is there >proof of spam source or hijacking etc.. ? ) I believe that to be the case, and I could even marshall some compelling evidence of that, but as I am sure you know that is entirely irrelevant here. Do I really need to say what has already been said innumerable times in the past, i.e. that RIPE is not the Internet Police? The issue I have raised has nothing to do with spamming, which RIPE and all of its members have elected not to concern themselves with. The issue I have raised also has nothing to do with the hijacking of IP address space via the BGP announcement of fradulent routes. This is also a topic which, I am told, RIPE and all of its members have elected not to concern themselves with, because once again, RIPE is not the Internet Police. So, please Erik, do not attempt to confuse the issue by injecting these irrelevancies into the conversation. Let's try to stay focused. The one issue that RIPE and its membership _have_ generally asserted a serious interest in is the quality and accuracy of the data base. The clear evidence, from both last week and today, and particularly the comparison between the two, show quite clearly that *somebody* knows that one hell of a lot of fradulent route objects were inserted into the data base by the party or parties associated with the MNT-SERVERSGET handle. And as a direct result of my posting of last week, *someone* has now mysteriously "disappeared" most or all of the fradulent route objects that had been put into the data base by MNT-SERVERSGET aka Alexander Samuilov. (I say that these route objects have been "mysteriously disappeared" because whoever did that did not see fit to mention who was doing the disappearing or why it was being done, exactly, on any of the RIPE mailing lists to which I posted my message of last week. Nor have I received any private messages explaining why these route objects were being removed.) Try as you might Erik, you cannot make these inconvenient facts go away, e.g. just by introducing a bunch of irrelevancies into the conversation. People... even people here in the relevant RIPE mailing lists... are not all stupid. They can see for themselves that there were in fact *numerous* fradulent route objects in the RIPE data base last week that have mysterious disappeared since my posting of last week. (If anyone needs to have me generate a side-by-side comparison showing the set of fradulent MNT-SERVERSGET route objects that have been disappeared from the data base over just the past few days then I will try to create that sort of side-by-side listing so that any doubters may have a clear view and a clear understanding of what has happened, over just the past few days.) How do you explain this Erik? How does RIPE NCC explain all of these sudden disappearances of route objects from the data base? Does it not seem, even to you, that the rather sudden and unexplained disapperances, just since my posting last week, of so many of the MNT-SERVERSGET route objects may be somewhat more than just purely coincidental? Somebody somewhere knows that those route objects were unambiguously fradulent. Perhaps it was only the perpetrator, Mr. Alexander Samuilov. Perhaps it was some member of the technical staff inside RIPE NCC. Whoever it was, it cannot now be denied that the route objects in question were fradulent, or that this pollution was deliberately inserted into the data base by *some* RIPE member. So the only remaining question is: Is RIPE even willing or able to "police" its own data base? What sanctions, if any, are going to be imposed, by RIPE, on the crook who engineered all of this crap? RIPE has a bad habit of just looking the other way when its members spam massively, engage in massive hacking attacks, and even when they use BGP to hijack IP space that doesn't belong to them. Will RIPE also now look the other way and do nothing when the one and only thing that all RIPE members actually hold dear, i.e. the data base, is used like a toilet by certain specific and easily identifiable members? >If you want to get the exec-board to take action to a listed broker, that >should be take up with the exec-board and the NCC. >It is my experience that they are very responsive Your experience is apparently unique. Since my posting of last week, which was CC'd to exec-board(a)ripe.net, and which clearly and unambiguously called for the investigation of, and the expulsion of several very specific RIPE members (and also the deletion of certain entities from RIPE's list of officially recognized IP brokers), I have had not a single response of any kind from *any* board member. None of them have even had the courtesy to send me a FOAD message in response. Their silence on these matters is deafening. Regards, rfg

4 6

NWI-5 NRTM changes deployed to RC (Release Candidate) environment
by Nathalie Trenaman 14 Aug '18

14 Aug '18

Dear Colleagues, As per request of the RIPE Database Working Group, we have now created two separate NRTM streams, two database dumps and two sets of split files, one per source (RIPE and RIPE-NONAUTH) This has been added to the RC environment for you to test before we make the changes in production on the 4th of September 2018. We encourage you to test the impact of the NWI-5 changes on your scripts and tools and report any issues you may find to ripe-dbm(a)ripe.net <mailto:ripe-dbm@ripe.net> Information about Release Candidate can be found at: https://www.ripe.net/manage-ips-and-asns/db/release-notes/ripe-database-rel… <https://www.ripe.net/manage-ips-and-asns/db/release-notes/ripe-database-rel…> The full NWI-5 implementation plan can be found at: https://www.ripe.net/manage-ips-and-asns/db/impact-analysis-for-nwi-5-imple… <https://www.ripe.net/manage-ips-and-asns/db/impact-analysis-for-nwi-5-imple…> Kind regards, Nathalie Trenaman Product Manager

1 0

Broken RDAP response
by Brian Rak 13 Aug '18

13 Aug '18

We hit issues with: https://rdap.db.ripe.net/ip/37.246.0.0/16 It looks like someone added multiple country: fields in the RIPE database inetnum: 37.246.0.0 - 37.246.255.255 netname: MD-SHATRANS-20120417 country: GB country: US org: ORG-TS151-RIPE How did this even get into the database in the first place? I'm not sure returning an error via RDAP is really the best way of handling this.

5 7