- db-wg - mailman.ripe.net

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

FW: #79981 - Re: RIPE database tool
by Aviolat Romain 10 Aug '18

10 Aug '18

Dear RIPE DB WG, We coded a tool to manage RIPE objects as code in my company, we're using it in production for almost a year and so far it's working great. We're not dealing with a ton of objects (quite a small LIR) and there's probably use-cases that aren't met yet but the tool is quite simple and opensource so feel free to play with it. Let me know ! https://github.com/xens/ripeinator +++ Romain From: RIPE NCC Support <support(a)ripe.net> Sent: lundi, 16 juillet 2018 13:11 To: Aviolat Romain <Romain.Aviolat(a)nagra.com> Subject: #79981 - Re: RIPE database tool ##- Please type your reply above this line -## Ticket (79981) has been updated. To add additional comments, reply to this email. Gabriel Ajabahian (RIPE NCC Support) Jul 16, 13:11 CEST Dear Romain, Thank you for your email. Unfortunately the email was missed in the communication and took us long time to reply. As Software Engineering department at RIPE NCC does not use Python we wont be able to use it but for sure I'm passing it to the other departments who has Python in their stack. I see the tool as very useful, and you can always announce it on the database working group so other community members can know about it and use it and you can get a feedback. The link to the database working group: https://www.ripe.net/participate/ripe/wg/db Good luck, and thanks for the great work. Kind regards, Gabriel Ajabahian Software Engineer RIPE NCC Romain Aviolat Mar 19, 20:22 CET Dear RIPE support, just to inform you that I coded a tool to talk to the RIPE APIs: https://github.com/xens/ripeinator with it you can define your objects in a yaml structure and let the tool talk to RIPE APIs, it's a nice way to manage ripe-objects as-code. Let me know if it's useful, +++ Romain This email is a service from RIPE NCC Support. [WV7LYZ-X3E8]

1 0

WG Chair Selection
by William Sylvester 31 Jul '18

31 Jul '18

WG Members, This email kicks off the chair selection process for the open seat vacated last fall. With the new chair processes agreed to by the working group this will be a single chair seat for three years. This will migrate us into the new process where we will select one chair per year to maintain continuity and consistency for the chairs and prevent a situation like we have encountered previously where we were selecting chairs out of a drawing from a hat. As a reminder, chair terms are staggered yearly. The working group will select the chair by consensus. The process is as follows; This is the call for interested parties. Interested parties have two (2) weeks to make their interest known on this mailing list, or directly to the chair(s). After two weeks, the chair(s) ensure that all candidates are announced on the mailing list and issue a call for discussion. All members of the community are encourage to make a discussion and express their approval or otherwise of the presented candidates. Two (2) weeks after the call for discussion, the chair(s) declare a decision, based on mailing list discussion, as they would do for a policy proposal. All candidates please post to the mailing list at this time or contact the chairs (db-wg-chairs(a)ripe.net<mailto:db-wg-chairs@ripe.net>). Kind regards, William & Denis DB-WG Co-Chairs

4 3

Implementation plan and dates for NWI5 - Out-of-region ROUTE(6) objects and removal of ASN authorisation for ROUTE(6) object creation.
by Nathalie Trenaman 24 Jul '18

24 Jul '18

Dear colleagues, In February 2018, the RIPE Database Working Group reached consensus on NWI-5 - creating out of region ROUTE(6) objects in the RIPE Database. We will soon be making changes to the way out-of-region objects are handled in the RIPE Database. It's important that database users are aware of these changes and what they mean: 1. The RIPE Routing Registry will no longer support the creation of out-of-region ROUTE(6) and AUT-NUM objects 2. Existing out-of-region objects will have their "source:” attribute changed to "RIPE-NONAUTH” 3. The creation of ROUTE(6) objects will no longer need authorisation from the ASN holder We will implement these changes in the Release Candidate environment on Thursday, 2 August and go to full production on Tuesday, 4 September. Our 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…> The RIPE Database Working Group chairs also wrote a RIPE Labs article that describes the background of NWI-5: 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…> <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…>> Please contact ,ripe-dbm(a)ripe.net <mailto:ripe-dbm@ripe.net>. if you still have questions after reading the implementation plan. Best regards, Nathalie Trenaman Product Manager RIPE NCC

6 7

Source GRS vs RIPE
by Aftab Siddiqui 18 Jul '18

18 Jul '18

Hi, I would like to understand the difference between these 2 results for the same prefix. Source: GRS https://apps.db.ripe.net/db-web-ui/#/query?bflag=true&source=GRS&searchtext… Source: RIPE https://apps.db.ripe.net/db-web-ui/#/query?bflag&searchtext=188.64.224.0%2F…

7 17

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