September 2021 - db-wg - mailman.ripe.net

New NWI for geofeed?
by denis walker 14 Apr '22

14 Apr '22

Colleagues [Apologies for the length of this email...] The chairs would like to suggest creating a new NWI for the "geofeed:" attribute and suggest the following draft Problem statement and Solution definition. If there is agreement on this the RIPE NCC will do an impact assessment including legal review and summary of what the other RIRs are doing. There has already been quite a discussion in the WG on this issue with a lot of support. So hopefully we can reach a consensus quickly, at least on setting up the NWI and starting the impact assessment. Having read the latest draft IETF docs, there are some outstanding questions. Comments and changes are welcome... cheers denis co-chair DB-WG Problem statement Associating an approximate physical location with an IP address has proven to be a challenge to solve within the current constraints of the RIPE Database. Over the years the community has chosen to consider addresses in the RIPE Database to relate to entities in the assignment process itself, not the subsequent actual use of IP addresses after assignment. The working group is asked to consider whether the RIPE Database can be used as a springboard for parties wishing to correlate geographical information with IP addresses by allowing structured references in the RIPE Database towards information outside the RIPE Database which potentially helps answer Geo IP Location queries The IETF is currently discussing an update to RPSL to add a new attribute "geofeed: url". The url will reference a csv file containing location data. Some users have already started to make use of this feature via the "remarks: geofeed: url". It is never a good idea to try to overload structured data into the free format "remarks:" attribute. This has been done in the past, for example with abuse contact details before we introduced the "abuse-c:" attribute. There is no way to regulate what database users put into "remarks:" attributes. So even if the new "geofeed:" attribute is not agreed, the url data will still be included in the RIPE Database. Currently there are 24,408 INETNUM and 516,354 INET6NUM objects containing a "remarks: geofeed: url" attribute in the database. These have 7,731 distinct values in the INETNUMs and 1,045 distinct values in the INET6NUMs. Solution definition Implement a new "geofeed:" attribute according to the IETF's definition. Although the IETF has not yet concluded discussions on this attribute we can still implement it in the RIPE Database RPSL data definition. The RIPE Database already has many local differences to the RPSL standard. As expressed in the Problem statement, users are already using the geofeed data by overloading the "remarks:" attribute. That is a dirty hack which should be avoided. An invalid formated url will be a syntax error. The RIPE NCC will perform a one time conversion of the existing data to convert "remarks: geofeed: url" to "geofeed: url". If an update then contains a "remarks: geofeed: url" attribute, the update will be successful and the response should include an appropriate Warning message. At some point in the (near) future, this could be changed to an update failure as a syntax error. An update containing a "geofeed:" and a "remarks: geofeed:" attribute or more than one "remarks: geofeed:" will be a syntax error. The resource holder should be able to create, modify, delete the "geofeed:" attribute in allocation objects. Questions: -Should the database software do any checks on the existence/reachability of the url as part of the update with an error if the check fails? -Should the RIPE NCC do any periodic repeat checks on the continued existence/reachability of the url? -Should the RIPE NCC do any periodic checks on the content structure of the csv file referenced by the url? -Should the Solution definition define how this will be adopted into RDAP or should we simply ask the RIPE NCC to define this in their impact assessment? -The RIPE Database contains hierarchical address space objects. Should it be acceptable for "geofeed:" attributes to exist at multiple levels within a specific hierarchy? -Suppose a geofeed csv file referenced by a /16 INETNUM object contains location data for the whole /16. Then a more specific /24 INETNUM object references another geofeed csv file that contains conflicting location data for this /24. Should this be a concern for the RIPE Database? -Should geofeed data be inherited? If you query for a /24 that does not contain a "geofeed:" attribute, but a less specific /16 does contain a "geofeed:" attribute, should this data be returned? In other words could it be used in a similar way to "abuse-c:"? -Thinking ahead to how people will actually deploy this data and what short cuts they could make. It is said that when reading a geofeed csv file, consumers of the data should ignore all data within that file not directly concerning the address space queried in the RIPE Database. Could you therefore create a single csv file with location data for all your address space and reference the same file in all your RIPE Database address objects? The address space owner could rely on the data consumer to pick out the correct piece of data for the relevant address space. The manager of the csv file then only has to work with one file. If this is possible and does happen (which the IETF doc 'Finding geofeeds' seems to suggest is possible for unsigned geofeed data), would it therefore make sense to apply "geofeed:" hierarchically as with "abuse-c:"? Allow a single, default "geofeed:" attribute in the ORGANISATION object to be applied to all that organisations address space, with the option of specific localised "geofeed:" attributes in address space objects. That could be a neater solution, and easier to setup, than applying thousands of references to the same geofeed file at a more specific level in the database. -Relating to the above 3 questions, should geofeed data only be considered applicable if returned by a specific geofeed locater application which takes into account the hierarchical nature of address space in the database? Otherwise do the standard database query mechanisms have to take into account this hierarchy and locate the most specific "geofeed:" attribute from the less specific objects? -Should/could the RIPE Database return the csv file as part of the query? If so should the file be cached (for how long?) to avoid too many downloads? -Should we only allow HTTPS urls? (Which the IETF doc 'Finding geofeeds' seems to suggest) -Should the RIPE NCC go ahead and implement this now, with our own set of RIPE rules? Or should we try to coordinate this and agree a set of common rules between all the RIRs before any deployment in the RIPE Database? -For the legal review, there are 2 statements in the IETF doc 'Finding geofeeds' which may be of concern: *[RFC8805] geofeed data may reveal the approximate location of an IP address, which might in turn reveal the approximate location of an individual user. Unfortunately, [RFC8805] provides no privacy guidance on avoiding or ameliorating possible damage due to this exposure of the user. In publishing pointers to geofeed files as described in this document the operator should be aware of this exposure in geofeed data and be cautious. All the privacy considerations of [RFC8805] Section 4 apply to this document. *It is significant that geofeed data may have finer granularity than the inetnum: which refers to them. It is clear that the RIPE NCC cannot prevent this data being referenced by objects in the RIPE Database. It is already being referenced from "remarks:" attributes. Perhaps the RIPE NCC should require (as part of their service agreement) that it's members obtain written consent from their customers to publish this location data, or at least inform the customers in writing that it will be published. Also, although RFC8805 says postcode is deprecated it is still provided for in the csv files. So anyone can still enter location data to this detail. -The IETF doc 'Finding geofeeds' suggests that geofeed information 'will be' available in bulk accessed whois data. In view of the privacy concerns above, is this likely? -The IETF doc 'Finding geofeeds' says "To minimize the load on RIR whois [RFC3912] services, use of the RIR's FTP [RFC0959] services SHOULD be the preferred access." Is the RIPE NCC expected to download all the geofeed files and make them available through their FTP service? -The IETF doc 'Finding geofeeds' states that consumers of the geofeed data MUST NOT access this data in real time via the RPSL servers 'too frequently' or at 'magic times like midnight'. Some users will do whatever they want to do if they are able to do, regardless of any statements to the contrary. Should the RIPE NCC enforce such access rules by some means? References The IETF doc 'Finding geofeeds': https://datatracker.ietf.org/doc/draft-ietf-opsawg-finding-geofeeds/?includ… geofeed file format: https://www.rfc-editor.org/rfc/rfc8805.html

12 53

Bogon route object cleanup
by Ronald F. Guilmette 08 Oct '21

08 Oct '21

It seems that we never really settled the question of route objects that make reference to the following reserved IP blocks. 192.31.196.0/24 192.88.99.0/24 2001::/32 2002::/16 2011:4188::/48 Note that route objects referring to these IP blocks are *not* present in the route registries of any RIR other than RIPE. I am in favor of including route objects that reference any of these reserved blocks in the ongoing cleanup. My recollection is that Cynthia Revstr�m also expressed support for including any and all such route objects in the current ongoing route object cleanup. Are there any objections at the present time to including such route objects in the ongoing cleanup? Regards, rfg

6 6

RIPE Database Requirements Task Force – Draft Report Published
by Bijal Sanghani 04 Oct '21

04 Oct '21

Dear colleagues, The RIPE Database Requirements Task Force has just published a draft report for your review: https://www.ripe.net/participate/ripe/tf/rdb-requirements-tf/the-ripe-datab… In this third draft, we’ve added new recommendations and edited our document based on feedback received via emails, survey and during our third BoF in May. Please review this draft and share any comments on the ripe-list before Friday, 13 August 2021. The task force will reconvene in August to discuss the feedback received and work on its final report that will be published ahead of RIPE 83. We look forward to your feedback. Best Regards, Bijal Sanghani

5 9

Two Proposals
by Ronald F. Guilmette 01 Oct '21

01 Oct '21

PROPOSED 1) RIPE NCC shall be tasked to begin updating the following file on a near real-time basis, as number resource assignments are transferred either into or out of the authority of RIPE: ftp://ftp.ripe.net/pub/stats/ripencc/delegated-ripencc-extended-latest 2) RIPE NCC shall be tasked to begin making the above file available for incremental remote update via the rsync protrocol. RATIONALE Background At the present time the most reliable and up-to-the-minute information indicating which RIR any given number resource is being administered by is contained within the so-called "daily stats files" that are generated and published by the five RIRs: ftp://ftp.arin.net/pub/stats/arin/delegated-arin-extended-latest ftp://ftp.ripe.net/pub/stats/ripencc/delegated-ripencc-extended-latest ftp://ftp.apnic.net/public/apnic/stats/apnic/delegated-apnic-extended-latest ftp://ftp.lacnic.net/pub/stats/lacnic/delegated-lacnic-extended-latest ftp://ftp.afrinic.net/stats/afrinic/delegated-afrinic-extended-latest Additionally, a single file representing the union of all of the above five files, along with additional data relating to (some but not all) IANA reserved number resources is also available: https://nro-extended-stats-from-rpki-team-prod.s3.eu-west-1.amazonaws.com/n… Note however that the data in this (NRO stats) file lags behind the contents of the five RIR daily stats files, and the content of this file is therfore often less fresh and up-to-date than the information contained in the five RIR stats files. Problem Statement (Proposal 1) Because the five RIR stats files are only updated once a day, and at different times for each RIR, and because number resources are, with increasing frequency, being transfered between regions, it is nowadays frequently the case that there will be, in effect, instances of "version skew" between the five RIR stats files. Instance of such inter-RIR stats files version skew can render it impossible to know, based on the stats files, which RIR currently administers a given number resource. Instances of internet-RIR stats file version skew can arise, and in practice they actually do arise as follows: *) RIR 'A' transfers a number resource `R' to RIR `B'. *) RIR `B' records its administration of `R' in its stats file which is then published within 1 hour. *) RIR `A' records the fact that it no longer administers `R' by removing the associated line from its stats file, and RIR `A's stats file is then published 23 hours later. Under the above scenario, the union of all five of the daily RIR stats files will indicate that *both* RIR `A" and also RIR `B' are the responsible RIRs for the resource `R' for a period of 22 hours. An actual example: As of approximately 07:13 (-0700 / PDT) on 2021-09-17 the following blocks were listed in *both* the stats file for ARIN and also the stats file for RIPE: 140.228.32.0/19 140.228.64.0/19 (Evidence indicates that these 2 block have just been transferred from administration by the ARIN region to administration by the RIPE region.) The problem of version skew between the various daily stats files that are currently published by the various RIRs could be largely or entirely eliminated if all five RIRs henceforth began to update these files on a near real-time basis. RIPE can and should begin doing this as an example to the other RIRs, which may then follow suit. Problem Statement (Proposal 2) The RIR daily stats files, including the one that is generated and published by RIPE NCC, consist of plain text files which are themselves composed of a sequence of plain text lines. As a general matter, very few of these lines change, even over time scales as long as a month. Changes to these files, if any, are entirely minimal when viewed over even shorter time scales, e.g. a day or less. The rsync protocol and rsync servers and clients are especially adept at keeping remote copies of exactly such plain text files up-to-date and synchronized with a master copy stored elsewhere on the Internet. They do so while minimizing bandwidth usage by transfering only those portions of a given file that have changed since the last time a local mirrored copy of the file was updated. Publishing RIPE's stats file via rsync would thus be beneficial to all concerned by minimizing bandwidth usage on both the sending and receiving end. Ideally, RIPE NCC could and should take the lead in making its stats file available via rsync. Once it has done so, other RIRs can be encouraged to follow suit and do likewise with their own daily stats files. Regards, rfg P.S. On a personal note I find it nearly unfathomable that these "daily" stats files are being updated and published only once a day. This seems to me almost reminicent of technological solutions considered appropriate in the prior century.

3 5

Upcoming Usability improvements to the RIPE Database Web Search page
by Edward Shryane 01 Oct '21

01 Oct '21

Dear colleagues, In the RIPE NCC's Activity Plan 2021, we planned to make usability improvements to the RIPE database, including the web search feature. My colleague Rehan Syed Muhammad has now published a RIPE Labs article detailing some upcoming improvements: https://labs.ripe.net/author/rehan_syed_muhammad/four-ideas-for-quicker-que… We plan to make incremental changes to the search page in the coming months. We will keep the community informed, and we welcome any feedback. Regards Ed Shryane RIPE NCC

1 1

RIPE Database Planning Q4 2021
by Edward Shryane 30 Sep '21

30 Sep '21

Dear colleagues, We are now publishing our quarterly planning for the RIPE Database: https://www.ripe.net/manage-ips-and-asns/db/quarterly-planning Our goals here are to make it clear what we are working on in the coming months, and also to get discussion around those plans so we can make developments based on community input. If you have comments or questions around this, we hope you'll let us know on the list or you can always contact me and the team directly at <ripe-dbm(a)ripe.net>. Kind regards, Ed Shryane Senior Technical Analyst RIPE NCC

2 1

Cosmetic changes to the RIPE Database
by denis walker 19 Sep '21

19 Sep '21

Colleagues There have been a number of cosmetic changes to the RIPE Database in recent months. There is no agreed procedure for making these type of changes. In particular the extent to which the community is informed. Examples of the type of changes we are talking about are: 1/ When the ORGANISATION object addresses were synced with the internal registry the address lines were entered in the wrong order. The RIPE NCC did a cosmetic update to reverse the order of the address lines. It had no operational impact at all. 2/ Capitalisation of status values. Again this had no operational impact at all. We would like some feedback from the community about how you want these type of cosmetic changes announced. We see four possible options: 1/ individual notification in advance to all affected maintainers plus general announcement on the mailing list plus update notifications (full disclosure) 2/ general announcement on the mailing list plus update notifications 3/ general announcement on mailing list and silent update (no notifications) 4/ no announcement, no notifications, just do it without disturbing anyone (totally silent) Some points to note: -In all cases the object history will show the changes. -There is also an option to not change the "last-modified:" attribute if you don't want that to reflect cosmetic changes. -The full disclosure option (1) can sometimes lead to considerable extra work load for the RIPE NCC. If people are individually told in advance of a change they don't always realise it has no operational impact and ask questions. Every question opens a ticket that needs to be manually addressed. -Perhaps options 2 or 3 are the most practical? Your feedback is welcomed... cheers denis co-chair DB-WG

4 5

running in whios-circles...?
by Frank Habicht 18 Sep '21

18 Sep '21

Hi, so on my self-hosted MTA I got an email [unsure about good intentions, thus checking origin] from 82.156.114.62 Whois directed to ripe, ripe said it's iana, iana said it's ripe [ BGP said ..... 4134 23724 45090 ] and ..... there's a route object in APNIC: route: 82.156.0.0/15 origin: AS45090 descr: Tencent Cloud Computing (Beijing) Co., Ltd 309 West Zone, 3F. 49 Zhichun Road. Haidian District. mnt-by: MAINT-TENCENT-CN last-modified: 2020-02-24T07:34:42Z source: APNIC and also "inetnum: 82.156.0.0 - 82.157.255.255" (in APNIC) So, I tend to believe that I'm on the wrong list here, because my question turns out to be: can I trust whois.iana.org ? It seems to tell me something different from what APNIC is saying. PS: a prefix containing IP in question is not seen in https://www.iana.org/assignments/ipv4-recovered-address-space/ipv4-recovere… am i right to be confused by the iana answer? who should get 'encouraged' to change something? Thanks, Frank [frank@fisi ~]$ whoisiana 82.156.114.62 [Querying whois.iana.org] [whois.iana.org] % IANA WHOIS server % for more information on IANA, visit http://www.iana.org % This query returned 1 object refer: whois.ripe.net inetnum: 82.0.0.0 - 82.255.255.255 organisation: RIPE NCC status: ALLOCATED whois: whois.ripe.net changed: 2002-11 source: IANA [frank@fisi ~]$ whois 82.156.114.62 [Querying whois.ripe.net] [whois.ripe.net] % This is the RIPE Database query service. % The objects are in RPSL format. % % The RIPE Database is subject to Terms and Conditions. % See http://www.ripe.net/db/support/db-terms-conditions.pdf % Note: this output has been filtered. % To receive output for a database update, use the "-B" flag. % Information related to '82.156.0.0 - 82.157.255.255' % No abuse contact registered for 82.156.0.0 - 82.157.255.255 inetnum: 82.156.0.0 - 82.157.255.255 netname: NON-RIPE-NCC-MANAGED-ADDRESS-BLOCK descr: IPv4 address block not managed by the RIPE NCC remarks: ------------------------------------------------------ remarks: remarks: For registration information, remarks: you can consult the following sources: remarks: remarks: IANA remarks: http://www.iana.org/assignments/ipv4-address-space remarks: http://www.iana.org/assignments/iana-ipv4-special-registry remarks: http://www.iana.org/assignments/ipv4-recovered-address-space remarks: remarks: AFRINIC (Africa) remarks: http://www.afrinic.net/ whois.afrinic.net remarks: remarks: APNIC (Asia Pacific) remarks: http://www.apnic.net/ whois.apnic.net remarks: remarks: ARIN (Northern America) remarks: http://www.arin.net/ whois.arin.net remarks: remarks: LACNIC (Latin America and the Carribean) remarks: http://www.lacnic.net/ whois.lacnic.net remarks: remarks: ------------------------------------------------------ country: EU # Country is really world wide admin-c: IANA1-RIPE tech-c: IANA1-RIPE status: ALLOCATED UNSPECIFIED mnt-by: RIPE-NCC-HM-MNT created: 2019-01-07T10:49:20Z last-modified: 2019-01-07T10:49:20Z source: RIPE role: Internet Assigned Numbers Authority address: see http://www.iana.org. admin-c: IANA1-RIPE tech-c: IANA1-RIPE nic-hdl: IANA1-RIPE remarks: For more information on IANA services remarks: go to IANA web site at http://www.iana.org. mnt-by: RIPE-NCC-MNT created: 1970-01-01T00:00:00Z last-modified: 2001-09-22T09:31:27Z source: RIPE # Filtered % This query was served by the RIPE Database Query Service version 1.101 (ANGUS) [frank@fisi ~]$

11 28

Re: [db-wg] running in whios-circles...?
by Lutz Donnerhacke 16 Sep '21

16 Sep '21

* Ronald F. Guilmette wrote: > Gert Doering <gert(a)space.net> wrote: > >Ideally, IANA should point to the final RIR right away. > > That would certainly be more helpful than the present state of affairs, > within which the IANA WHOIS server is not merely failing to give out > correct referrals, but is actually giving out demonstratably incorrect > referrals. > > Functionally and operationally, the portion of the IANA WHOIS service that > provides referrals for IP addresses is, at present, worse than useless > due to the innumerable incorrect referrals it provides. If IANA does not > wish to correct that, then they should at least configure the thing so that > it will stop providing *any* responses at all when queried about IP > addresses. Did you ever tried to correct wrong entries in the IANA whois? I did and the entries were fixed (within a period of about a year). It's certainly possible to have correct data in the IANA server. OTOH if the problem is serious enough, an IANA review can be triggered.

3 4

What do you think of our new UI?
by Edward Shryane 02 Sep '21

02 Sep '21

Dear colleagues, We have created a short survey to get your feedback and comments on the new user interface (UI) we have deployed across RIPE NCC’s services, including the RIPE DB website. We kindly ask you to take part in the survey and help us improve the user experience for you. You can access the survey at: https://www.surveymonkey.com/r/RIPENCCservicesUI The survey is anonymous and will remain open until 30 September 2021. Regards Ed Shryane RIPE NCC

3 3