April 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

New Website Template Deployed to Release Candidate Environment
by Edward Shryane 03 May '21

03 May '21

Dear Colleagues, We have deployed a test version of the new website interface to the release candidate environment: https://rc.db.ripe.net/db-web-ui/query We have reorganised the left-hand and top menus, and modernised the template so it's more mobile friendly. Please let us know what you think. We plan to deploy to production next Monday, 3rd May. Keep in mind the interface is provisional so expect some changes before we go live. 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… Regards Ed Shryane RIPE NCC

1 1

Re: [db-wg] Cleanup of route(6) objects in the RIPE NONAUTH database using unregistered space
by denis walker 26 Apr '21

26 Apr '21

Thanks for the input Cynthia. As you are one of the few people who regularly comment on DB issues at the moment, maybe you could take a look at the request for feedback from the DB Task Force recently. Any comments would be appreciated, who knows it may even start a discussion :) cheers denis co-chair DB-WG On Sun, 25 Apr 2021 at 13:03, Cynthia Revström <me(a)cynthia.re> wrote: > > imo an NWI seems unnecessary unless we want it for purposes of referencing back to in the future. > > -Cynthia > > On Wed, Apr 21, 2021, 04:02 denis walker via db-wg <db-wg(a)ripe.net> wrote: >> >> Colleagues >> >> How do you want to proceed with this suggestion? Do we have support >> for deleting these ROUTE(6) objects for deregistered space and where >> the objects were created before registration? Does anyone have any >> objections to this as an ongoing cleanup? >> >> Do we even need an NWI or can we just ask the NCC to go ahead with it? >> >> cheers >> denis >> co-chair DB-WG >> >> On Thu, 11 Mar 2021 at 15:07, Edward Shryane via db-wg <db-wg(a)ripe.net> wrote: >> > >> > Dear colleagues, >> > >> > In response to the recent discussion on "196.52.0.0/14 revoked, cleanup efforts needed", I'd like to propose a regular automated cleanup of route(6) objects in the RIPE-NONAUTH database using unregistered space. >> > >> > Regards >> > Ed Shryane >> > RIPE NCC >> > >> > >> > >> > Problem Definition >> > ------------------ >> > When an RIR deregisters IPv4/IPv6 address space, any route(6) objects in the RIPE-NONAUTH database using that address space are not cleaned up (deleted). >> > >> > >> > Solution Definition >> > ------------------- >> > Once a day, compare route(6) IPv4/IPv6 prefixes in the RIPE-NONAUTH database against the combined delegated stats from all RIRs. >> > >> > Only route(6) prefixes that are "allocated" or "assigned" in any RIRs delegated stats should remain in the RIPE NONAUTH database. If a prefix is "available" or "reserved" then it is considered to be unregistered, and any associated route(6) objects will be eligible for deletion. >> > >> > If a prefix is partially "available" or "reserved" then it is also considered to be unregistered. >> > >> > If a prefix is not listed in any RIRs delegated stats, that prefix is skipped. >> > >> > The origin AS status is not considered, only the IPv4/IPv6 prefix. >> > >> > If a newly unregistered prefix is discovered, first allow a grace period of 1 week. This allows time for mistakes in the delegated stats to be corrected. >> > >> > After 1 week, contact the route(6) maintainer(s) to notify them that the route(6) object will be deleted. >> > >> > After a further 2 weeks, delete the route(6) object. >> > >> > A maintainer can request the RIPE NCC to exclude a route(6) prefix from deletion (for example, the deregistration of the prefix is being disputed). For any excluded prefixes, any associated route(6) objects will not be deleted. >> > >> > >> > Impact Analysis >> > ------------------ >> > There are approximately 738 routes (out of 56,230) in the RIPE-NONAUTH database using a prefix with status "available" or "reserved" in an RIRs delegated stats, which will be eligible for deletion. >> > >> > There are approximately 94 route6's (out of 1,564) in the RIPE-NONAUTH database using a prefix with status "available" or "reserved", so also eligible for deletion. >> > >> > There are approximately 64 routes and 37 route6's with a prefix not listed in any RIR's delegated stats. These will not be affected. >> > >> > When this cleanup is implemented, the backlog of route(6) objects eligible for deletion will be processed at the same time, leading to a large amount of emails to affected maintainers. Once this backlog is processed, the number of route(6) objects affected is expected to be low. >> > >> > >> > >>

1 0

input from community???
by denis walker 22 Apr '21

22 Apr '21

Colleagues Over recent months several important issues have been raised on this mailing list. We have seen comments from maybe 1 or 2 people to some of them. No comments at all to others. We appreciate that covid issues affect many businesses in many ways. So perhaps some of you have far more important issues to deal with than the RIPE Database. It is very difficult for the chairs to see consensus with only a couple of comments. The DB Task Force has also asked for feedback on a number of issues to help them finalise their recommendations. With 3 weeks to the RIPE Meeting and 2 weeks to the DBTF bof, if any of you have some spare moments to review any of the issues raised over the past months it really would help if you can offer some feedback, even better if that promotes some real discussion. cheers denis co-chair DB-WG

1 0

Call for Presentations / DRAFT Agenda RIPE82 - Database Working Group
by William Sylvester 22 Apr '21

22 Apr '21

Dear Working Group Members, Below is the proposed agenda for the Database Working Group for RIPE82. 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 – XX mins Edward Shryane, RIPE NCC C. Geofeeds – YY mins Massimo Candela, NTT D. YOUR PRESENTATION HERE – ZZ mins Community Member, RIPE Community E. NWI - Open Proposals – 5 mins Z. AOB (open discussion)

1 0

Whois Release 1.100
by Edward Shryane 22 Apr '21

22 Apr '21

Dear Working Group, RIPE Database release 1.100 has been deployed to the Release Candidate environment. We plan to deploy to production on Thursday 22nd April. This release includes the following main changes: * Separate email address and leading/trailing space during Punycode conversion (#782) * Use status index during update validation (#725) * Fixed aut-num attribute managed flag in lookup and search response (#749) * Added client flag to API for proxying requests (#728) * RDAP nameserver not implemented (#711) * Fixed delete object bug (#723) In addition to other small improvements and bug fixes. 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

Cleanup of route(6) objects in the RIPE NONAUTH database using unregistered space
by Edward Shryane 20 Apr '21

20 Apr '21

Dear colleagues, In response to the recent discussion on "196.52.0.0/14 revoked, cleanup efforts needed", I'd like to propose a regular automated cleanup of route(6) objects in the RIPE-NONAUTH database using unregistered space. Regards Ed Shryane RIPE NCC Problem Definition ------------------ When an RIR deregisters IPv4/IPv6 address space, any route(6) objects in the RIPE-NONAUTH database using that address space are not cleaned up (deleted). Solution Definition ------------------- Once a day, compare route(6) IPv4/IPv6 prefixes in the RIPE-NONAUTH database against the combined delegated stats from all RIRs. Only route(6) prefixes that are "allocated" or "assigned" in any RIRs delegated stats should remain in the RIPE NONAUTH database. If a prefix is "available" or "reserved" then it is considered to be unregistered, and any associated route(6) objects will be eligible for deletion. If a prefix is partially "available" or "reserved" then it is also considered to be unregistered. If a prefix is not listed in any RIRs delegated stats, that prefix is skipped. The origin AS status is not considered, only the IPv4/IPv6 prefix. If a newly unregistered prefix is discovered, first allow a grace period of 1 week. This allows time for mistakes in the delegated stats to be corrected. After 1 week, contact the route(6) maintainer(s) to notify them that the route(6) object will be deleted. After a further 2 weeks, delete the route(6) object. A maintainer can request the RIPE NCC to exclude a route(6) prefix from deletion (for example, the deregistration of the prefix is being disputed). For any excluded prefixes, any associated route(6) objects will not be deleted. Impact Analysis ------------------ There are approximately 738 routes (out of 56,230) in the RIPE-NONAUTH database using a prefix with status "available" or "reserved" in an RIRs delegated stats, which will be eligible for deletion. There are approximately 94 route6's (out of 1,564) in the RIPE-NONAUTH database using a prefix with status "available" or "reserved", so also eligible for deletion. There are approximately 64 routes and 37 route6's with a prefix not listed in any RIR's delegated stats. These will not be affected. When this cleanup is implemented, the backlog of route(6) objects eligible for deletion will be processed at the same time, leading to a large amount of emails to affected maintainers. Once this backlog is processed, the number of route(6) objects affected is expected to be low.

2 1

RIPE Database Requirements Task Force BoF, 5 May 2021
by Bijal Sanghani 15 Apr '21

15 Apr '21

Dear all, The RIPE Database Requirements Task Force (DBTF) will organise its third BoF on Wednesday, 5 May 2021 from 16:00-17:30 (UTC+2) via Zoom. During this BoF, the DBTF will present its latest recommendations and discuss open issues. More information and joining details are available at: https://www.ripe.net/participate/ripe/tf/rdb-requirements-tf/bof-5-may-2021 Kind regards, Bijal on behalf of the DBTF

1 0

RIPE Database - Historical Information
by Bijal Sanghani 14 Apr '21

14 Apr '21

Dear colleagues, As part of our work in the RIPE Database Requirements Task Force (DBTF), we are trying to understand if providing historical data is one of the requirements the RIPE Database must fulfil. Currently some attributes are filtered out to limit the exposure of unnecessary personal data. If providing historical data is a requirement the RIPE Database must fulfill, we will recommend the RIPE NCC to examine if additional filtering can be applied to limit further the unnecessary exposure of personal data in attributes that are not meant to contain personal data. We are looking specifically for arguments pro or against this recommendation. We’ll then discuss each argument with the task force and make a decision. Kind regards, Bijal on behalf of the DBTF

3 3

RIPE Database - Legal Address
by Bijal Sanghani 14 Apr '21

14 Apr '21

Dear colleagues, As part of our work in the RIPE Database Requirements Task Force (DBTF), we are trying to evaluate if we should recommend that the RIPE NCC publish the legal address of resource holders in the RIPE Database. It will include everybody that is directly receiving resources from the RIPE NCC. This information is already stored in the RIPE Registry but not available in the RIPE Database. However it’s good to note that since the implementation of NWI-10, a new attribute was added to the ORGANISATION object with the Country Code for the country in which the resource holder is legally based. As a reminder, this is our current recommendation: “The task force recommends that the legal address of resource holders who are legal persons be published in the RIPE Database. This will clarify which organisation holds which Internet number resources and ensure quick action from incident responders such as CSIRTs and LEAs in case of abuse.” The task force is aware that there are legal and technical constraints attached to this recommendation. The main challenge is to find a system that can clearly separate natural and legal persons across our service region, so that the privacy of natural persons in the RIPE Database is respected. This also includes corner cases such as SMEs using their home addresses as their legal addresses. We are looking specifically for arguments pro or against this recommendation. We’ll then discuss each argument with the task force and make a decision. Kind regards, Bijal on behalf of the DBTF

3 2