November 2017 - db-wg - mailman.ripe.net

<auto-dbm@ripe.net> is slow this afternoon.
by RIPE Database Administration 17 May '18

17 May '18

Dear Colleagues, Because of a very high level of use this afternoon, the response time of <auto-dbm(a)ripe.net> is longer than normal. I have made contact with those who are responsible and I expect the situation to improve as the machine works through the queue. Please be patient. Obviously we at the RIPE NCC Database Group are continuously working to make the performance of the database as good as possible. However, we cannot make improvements in zero time. We thank you for your co-operation up to now and we ask for your continued co-operation so that everyone receives the best possible service. If you have anymore questions, please contact <ripe-dbm(a)ripe.net>. Regards, Ambrose Magee ____________________________ RIPE Database Administration.

2 2

Getting fraudulent entries removed
by Brian Rak 07 Apr '18

07 Apr '18

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

6 13

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

16 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

Validation on "org-name:" syntax (double spaces and newlines)
by Alexander Stranzky 01 Dec '17

01 Dec '17

Am 12.11.17 um 12:00 schrieb db-wg-request(a)ripe.net: > Out of 114181 ORGANISATION objects, 112 objects use multiple consecutive whitespace in the ?org-name:? attribute and only 1 uses a multi-line value. While this is a tiny fraction these objects are a bit problematic to us when we verify that the ?org-name:? matches the name of the organisation that we allocated or assigned resources to in our records. We also believe that this is highly confusing to users and tools parsing these objects. While currently not an issue, you should include other non-spaces whitespace (i.e. Tabs & NULL-Bytes) in your blacklist. Regards, 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

4 3

Validation on "org-name:" syntax (double spaces and newlines)
by Tim Bruijnzeels 23 Nov '17

23 Nov '17

Dear Working Group, Out of 114181 ORGANISATION objects, 112 objects use multiple consecutive whitespace in the “org-name:” attribute and only 1 uses a multi-line value. While this is a tiny fraction these objects are a bit problematic to us when we verify that the “org-name:” matches the name of the organisation that we allocated or assigned resources to in our records. We also believe that this is highly confusing to users and tools parsing these objects. Therefore we like to clean these objects up and remove any multi-whitespace or multi-line occurrences. We can of course follow up with these organisation individually, but the reason that I bring it up here is that we also want to have stricter syntax rules in place to prevent this from happening again. We can do either of the following: 1) replace multi-whitespace or multi-line occurrences on input (warn, but just strip the additional space) 2) reject multi-whitespace or multi-line occurrences on input I am leaning towards option 2, but I would value your input. Kind regards, Tim Bruijnzeels Assistant Manager Software Engineering and Senior Technology Officer RIPE NCC

6 6

Proxy proposal large communities
by Tim Bruijnzeels 14 Nov '17

14 Nov '17

Dear Working Group, As discussed at RIPE 75 I want to forward a request by Job Snijders on GitHub: https://github.com/RIPE-NCC/whois/issues/410 Job is asking to add a “large_community" keyword to RPSL dictionary where applicable. And provides the following example: Suggestion: name the keyword large_community mp-export: afi ipv6.unicast to AS13105 announce AS-RCNET-V6 AND NOT large_community.contains(21414:0:570) export: to AS6777 action large_community .= { 6777:0:6777 }; announce AS-FORTHNET mp-import: afi ipv6.unicast from AS8631 msk-rs2.ripn.net action large_community={31376:0:2}; pref=100; accept AS-MSKROUTESERVER import: from AS35082 95.128.51.234 at 95.128.51.233 action pref=500; large_community.append(29527:0:35082,29527:0:60000,29527:0:61200,29527:0:61210); accept AS-VIBUS-LONDON filter-set: fltr-as21229-export descr: Filter for AS21229 exported prefixes filter: AS-TVNETWORK AND large_community(21229:0:1) From our end I do not see any issues implementing this on the server side, but I can’t speak to how this will be treated by scripts that may parse RPSL today. Please discuss. Kind regards, Tim Bruijnzeels Assistant Manager Software Engineering and Senior Technology Officer RIPE NCC

5 24