- db-wg - mailman.ripe.net

consensus on AS23456
by denis walker 13 Jul '21

13 Jul '21

Colleagues Whilst part of the discussion continues, there does seem to be a consensus on adding AS23456 to the reserved list maintained by the RIPE NCC. This would prevent anyone creating a ROUTE(6) object with AS23456 as the origin. The chairs also recognise the consensus to not delete or modify any set objects that reference AS23456. This is in line with past views not to purge set objects when an AUT-NUM object is deleted for any reason. The chairs therefore ask the RIPE NCC to add AS23456 to the RIPE Database reserved list. Regards William & denis co-chairs DB-WG

3 2

Re: [db-wg] Further cleanup (was: RIPE NONAUTH route(6) objects
by Ronald F. Guilmette 13 Jul '21

13 Jul '21

Job Snijders <job(a)sobornost.net> wrote: >Should the database server software impose brittle restrictions >on that field? No, not worth the headache. I never suggested any changes to the data base software. I have merely suggested that *existing* route objects that make reference to bogon ASNs should be deleted from the data base, just as is already and currently being done in the case of those route objects that make reference to bogon IP space. The overwhelming majority of these "bogon-ASN" route objects are quite obviously leftovers that just never got cleaned up... some having languished unattended in the data base for as much as 20 years or more (and even some of the people who put those there originally are no doubt dead by now). We are in agreement in our (idealistic?) hops that someday RPKI will make all of these issues moot. By for today, there is no good reason not to remove the decades long accumulation of rust. It isn't doing anybody any good, and I fear it is an active enticement to mischief makers, of which the Internet has an over-supply these days. Regards, rfg

4 7

RIPE NONAUTH route(6) objects using unregistered space cleanup - deployment *today*
by Edward Shryane 08 Jul '21

08 Jul '21

Dear colleagues, The implementation of the cleanup of RIPE NONAUTH route(6) objects using unregistered space is now complete, we plan to deploy to production *today*. This means that the cleanup job will run for the first time tonight. * Each night, all RIPE NONAUTH route(6) objects with an unregistered prefix ("available" or "reserved" in delegated stats) are selected. * If a prefix remains unregistered for 1 week, notify the maintainers of any related route(6) objects. * The maintainer can ask to make an exception, not to delete a route(6) object. * Otherwise, after a further 2 weeks, delete the route(6) objects. See the solution definition for more details: https://www.ripe.net/ripe/mail/archives/db-wg/2021-March/006876.html Note for now, the AS origin status is *not* considered. Please discuss further whether this should be included. If you have any feedback, please let us know. Regards Ed Shryane RIPE NCC

9 31

Whois Release 1.101
by Edward Shryane 01 Jul '21

01 Jul '21

Dear Working Group, RIPE Database release 1.101 has been deployed to the Release Candidate environment. We plan to deploy to production on Thursday 1st July. This release includes the following main changes: * Switch RIPE database to UTC timezone (all timestamps will be in UTC and all timestamps specify the 'Z' timezone) * Display an error on NRTM if client is blocked by ACL limit (#812) * Added rewrite rules to embedded Jetty (#801) * RDAP nameserver queries always return Not Implemented (#811) * Updated dependencies *Additionally* some operational changes will also be made to the production environment on 1st July: * Remove support for TLS versions 1.0 and 1.1 on HTTPS connections * The IETF has formally deprecated these TLS versions, now only versions 1.2 and 1.3 are recommended. * Remove insecure TLS cipher algorithms * TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA * TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA * TLS_DHE_RSA_WITH_SEED_CBC_SHA * TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA * TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA * Remove HTTP redirects for whois.ripe.net and www.db.ripe.net * HTTP requests to these hosts will no longer redirect to https://apps.db.ripe.net but will return 400 Bad Request. * Remove HTTP redirects for the legacy Whois REST API * The legacy Whois REST API was retired in 2015, a temporary redirect to https://rest.db.ripe.net will be removed. * HTTP requests to the legacy API at http://apps.db.ripe.net/whois/lookup/ripe will return 400 Bad Request. Please check your Whois client in case you are affected by these changes. The release notes are on the website: https://www.ripe.net/manage-ips-and-asns/db/release-notes/ripe-database-rel… More information on the Release Candidate environment can be found on our website: https://www.ripe.net/manage-ips-and-asns/db/release-notes/rc-release-candid… Please let us know if you find any issues with this release in the RC environment. Regards Ed Shryane RIPE NCC

1 1

Removie ALL bogus route objects from BOTH data bases
by Ronald F. Guilmette 21 Jun '21

21 Jun '21

I guess I'll try this again, since I don't recall seeing either any ascent nor any pushback the last time I tried to raise this point here. Al long as those bogus route objects that refer to bogon IP address space are being removed from the data, why not also remove all of the equally bogus route objects that refer to bogon AS numbers? I hope that I'm not actually the only one who sees the wisdom in cleaning up the whole mess that currently exists in the RIPE data bases. There are, at present, on the order of about 80 or so bogus route objects in the "regular" data base that refer to bogon AS numbers, and there are, give or take, about 1,500 of such bogus route objects currently within the (separate) RIPE-NONAUTH data base. Is anyone passionately in favor of keeping all of this useless and potentially fraudlent or misleading garbage in the data base? If not, then why not clear it all out? I mean seriously, the RIRs data bases are *supposed* to be the definitive guides to who has what and who may use what. And yet RIPE is, in effect, tacitly -appproving- of the use of bogon AS numbers. So I need to ask: Why? Regards, rfg

1 0

Removal of bogon route objects
by Ronald F. Guilmette 15 Jun '21

15 Jun '21

Friends, As previously discussed, the decision was made awhile back to remove from the data base all RIPE-NONAUTH route objects which refer to currently unallocated IP space: https://www.ripe.net/ripe/mail/archives/db-wg/2021-May/006952.html In recent days I stumbled upon one such object that was still present in the data base. Upon seeing that object, I necessarily assumed that it was most likely not a "one off", and that it probably had siblings. In the spirit of trying to help out, and after a fair bit of fooling around on my part, I managed to concoct a rather simple method for finding all such bogon route objects that remain in the data base, and I wrote a small Perl script to do that exact thing. A copy of the script may be obtained here, for anyone who may be interested: https://pastebin.com/raw/LsvZ05tX Notes: *) The script assumes the presence of two external programs and their presence on the user's current $PATH, i.e. the widely used wget progarm, and also John Levine's version of a thing called grepcidr, sources for which may be obtained here: https://github.com/jrlevine/grepcidr3 *) The initial line of the script may have to be adjusted depending on the location, in the filesystem, of your local Perl interpreter. *) The script computes its results based upon the following two input data files, both of which are automagically fetched by the script using wget: https://www.nro.net/wp-content/uploads/delegated-stats/nro-extended-stats ftp://ftp.ripe.net/ripe/dbase/ripe-nonauth.db.gz (It is my understanding that each of these is updated on a daily basis.) *) The script DOES NOT verify that the entirety of any given RIPE-NONAUTH route object in fact refers to bogon space. Rather the script only checks to see whether or not the first IPv4 address of each current RIPE-NONAUTH route object does or does not refer to current bogon space. If it does, then the entire IPv4 CIDR of the route object is printed to stdout. *) Assuming that the script is installed as "ripebogonroutes" and in one's path, it may be invoked simply as: ripebogonroutes > bogon-route-cidrs *) At present there are 55,964 RIPE-NONAUTH objects in the data base. Of these, the first address of 857 of them refers to current bogon space. It is my fervent hope that the corresponding RIPE-NONAUTH route objects will be removed from the data base as soon as reasonably practical. Regards, rfg

6 18

RIPE-NONAUTH route object anomalies
by Ronald F. Guilmette 14 Jun '21

14 Jun '21

It appears that, by and large, the route objects currently present within the ripe-nonauth.db.gz file refer either to bogons (which I've already provided a list of) or else they refer to out-of-region IP address blocks. The latter group seems at least explainable. The former group I am hoping will disappear from the data base soon. Checking now however I find there are a very small number of anomalous route objects within the latest edition of the ripe-nonauth.db.gz file, i.e. ones that refer to in-region IP blocks: 192.124.252.0/22 192.70.0.0/17 192.76.32.0/21 192.108.160.0/20 I'm not sure how these should be made to go away, but I wish they would. They offend my personal sense of fastidiousness, and I don't like unexplainable mysteries. Note that the RIPE-NONAUTH route object 192.76.32.0/21 appears to have some counterpart route objects for sub-blocks of that /21 and these sub-blocks route objects are *not* marked as RIPE-NONAUTH, suggesting that there is no compelling reason for the 192.76.32.0/21 route object to be marked as RIPE-NONAUTH. The same sort of syndrome appears to apply also in the case of the 192.124.252.0/22 RIPE-NONAUTH route object, i.e. in this case also there appear to be valid non-RIPE-NONAUTH route objects in the data base for sub-blocks of 192.124.252.0/22, which begs the question: Why is the 192.124.252.0/22 markes as RIPE-NONAUTH? Regards, rfg

3 5

Issue creating new AS-SET
by Denis Fondras 09 Jun '21

09 Jun '21

Hi all, I am trying to add a new AS-SET but I get an error : as-set: Syntax error in AS201376:AS-MEMBERS:DIRECT Here is the object I try to create : AS-SET: AS201376:AS-MEMBERS:DIRECT members: AS60983 TECH-C: DF5400-RIPE ADMIN-C: DF5400-RIPE MNT-BY: AUVERNIX-MNT MNT-BY: DF39378-MNT SOURCE: RIPE AS201376:AS-MEMBERS already exists in the database. I cannot see what I do wrong here. Can anybody help ? Also I tried to do some tests on the test DB but I get a 404 error when clicking 'submit'. I don't know if it is me or a bug. Thank you in advance. -- Denis Fondras / Liopen

4 6

NWI-4 - role of status: field in multivalued status context - reprise
by Carsten Schiefner 08 Jun '21

08 Jun '21

Dear all - after a quick chat with Dennis on this, he encouraged me to toss this into the seemingly stalled, but not yet dead debate: Right now, only the "inet[6]num:" attribute is the primary key to, of or for inet[6]num objects. I wonder if it would be possible to make the tuple ("inet[6]num:","status:") the primary key instead: that should solve the challenge to have an assignment that shall have the size of an allocation. In case this has been exhaustedly discussed here already, please excuse my ignorance - I then obviously have failed to spot the respective contribution in the archives. All the best, -C.

6 7

Re: [db-wg] "status:" attribute values in the RIPE database
by Edward Shryane 07 Jun '21

07 Jun '21

Hi Carsten, > On 7 Jun 2021, at 12:57, Carsten Schiefner <carsten(a)schiefner.de> wrote: > > Ed & all - > > makes sense to me, too. > > However: Instead of forcing this on the creator/updater of an object - > how about the NCC to be as liberal as possible (John Postel's law, the > robustness principle) and to accept any case combination, e.g. "aSSigNED > pi", but very conservatively keep the attribute sored in the DB in > uppercase only? > I agree, apologies I wasn't clear, by force the "status:" attribute value to uppercase, I mean that the value should be automatically changed to all-uppercase, and we should still accept the value in any case. Also, we should perform a cleanup on currently inconsistent values (affecting less than 1% of total inetnum and inet6num objects). Regards Ed > ATB, > > -C. >

2 1