February 2022 - 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

Removing Apache Proxy Servers from DB Services
by Edward Shryane 02 Mar '22

02 Mar '22

Dear Colleagues, Next Tuesday, 1st March, the DB team plan to remove the Apache httpd proxy servers for the following services: * https://apps.db.ripe.net/ * https://rdap.db.ripe.net/ * https://rest.db.ripe.net/ * https://syncupdates.db.ripe.net/ This will allow us to simplify our production environment, reducing operational work and maintenance. Be aware that URL validation will be stricter after this change. For example, the following will return a 400 Bad Request: * Empty path segments (i.e. '//') * Encoded path separators (i.e. %2F for '/') * Encoded query separator (i.e. %3F for '?') Please test your client using the TEST environment: https://www.ripe.net/manage-ips-and-asns/db/ripe-test-database or the Release Candidate environment: https://www.ripe.net/manage-ips-and-asns/db/release-notes/rc-release-candid… Regards Ed Shryane RIPE NCC

1 1

Clear up of old issues - Whiepages
by denis walker 01 Mar '22

01 Mar '22

Colleagues The co-chairs recently had a zoom meeting with the RIPE NCC. One of the things we discussed was clearing up a number of old issues. We need to clear the deck and move on with new and perhaps more relevant issues. We will address a number of issues for the last time. In some cases the chairs will make a recommendation. As these are quite old issues, we will take silence as consensus for the chair's recommendation. The first issue is Whitepages. This is a feature from about 10+ years ago. It was intended to preserve the PERSON object in the RIPE Database and protect it from automatic deletion if it is not referenced from any operational data. It was to use the RIPE Database as a phone book for well known people in the industry who may not be resource holders. There are many other ways to provide such contact details today. It was only ever used by a handful of people. The RIPE NCC now has other ways to preserve ROLE objects if needed, for example if used by RIPE Atlas users. The chairs recommend removing this feature from the RIPE Database. If you need a ROLE object to be preserved, contact ripe-dbm(a)ripe.net to discuss. cheers denis co-chair DB-WG

4 8

geofeed issue: can't add geofeed attribute to PI /48
by Job Snijders 28 Feb '22

28 Feb '22

Dear all, Like all good netizens, I tried to align information I publish in the RIPE database to reality, but there is an obstacle: https://sobornost.net/~job/geofeed.png """Adding or modifying the "geofeed:" attribute of an object with a prefix length greater or equal to 48 is not allowed.""" No such restriction exists if you use the 'remarks: Geofeed' approach, as demonstrated here: $ whois -h whois.ripe.net 2001:67c:208c::/48 | grep Geofeed remarks: Geofeed https://sobornost.net/geofeed.csv I appreciate concerns about privacy, but I'm not wholly convinced restricting /48s from having a proper 'geofeed:' attribute is the best path forward. How does the working group feel about this restriction? Is it useful? Should it be lifted? If the latter, what would be the process? Kind regards, Job

14 52

Clear up of old issues - NWI-4 role of status: field
by denis walker 28 Feb '22

28 Feb '22

Colleagues The co-chairs recently had a zoom meeting with the RIPE NCC. One of the things we discussed was clearing up a number of old issues. We need to clear the deck and move on with new and perhaps more relevant issues. We will address a number of issues for the last time. In some cases the chairs will make a recommendation. As these are quite old issues, we will take silence as consensus for the chair's recommendation. NWI-4 https://www.ripe.net/ripe/mail/archives/db-wg/2016-May/005242.html This item has been 'open' for 6 years, and it was talked about before then. So we do need to come to a decision on how to move forward or drop it and just accept the constraints. To describe it in simple terms, it is about documenting an assignment the same size as an allocation. One idea that was put forward was to allow a twin attribute primary key for the INETNUM object: range/status similar to the primary key of a ROUTE object: prefix/origin. The RIPE NCC's impact analysis ruled out this option. This change would cut so deep into the software, changing core functionality of the data model with a ripple effect right across the system. The only other option currently on the table is one I put forward to allow the "status:" attribute to be 'multiple'. Business rules would then limit the use of this feature to only one use case. If the status is 'ALLOCATED PA' a second "status:" attribute would be allowed with the value 'ASSIGNED PA'. I don't think any other use case would require it. Where 2 status attributes exist, only the one with 'ASSIGNED PA' could be removed. This would be a relatively straightforward change to the software. Whilst "descr:", "country:", "admin-c:" and "tech-c:" are already multiple attributes, "org:" and "abuse-c:" are only single. They could also be made multiple in this one use case but that may have further consequences. It depends how far you want to go in fully defining an assignment or just documenting the fact that this allocation is also an assignment. Any change to allow a range to be dually represented as both an allocation and an assignment may break scripts people use to parse the objects returned by a database query. That is unavoidable. But it may affect some users' views on whether or not this is a sufficiently important problem that needs to be solved. Perhaps now there are so many /24 allocations, it raises the importance of being able to document an allocation as an assignment. There is of course an even simpler (pseudo) option, following on from the geofeed discussion, to define a convention to add: "remarks: status: ASSIGNED PA" Which throws us straight back into the debate on parsing "remarks:" attributes. The database software should not do so. But users querying this data can do whatever they wish. As Randy says, its interpretation is in the eye of the beholder. The chairs make no recommendation on this item. But if there is no discussion we will simply mark NWI-4 as cancelled. cheers denis co-chair DB-WG

1 1

Re: [db-wg] geofeed issue: can't add geofeed attribute to PI /48
by Jeroen Massar 14 Feb '22

14 Feb '22

> Hi Job, Colleagues, > > On 3 Jan 2022, at 13:36, Job Snijders via db-wg <db-wg at ripe.net> wrote: > > > > ... > > I appreciate concerns about privacy, but I'm not wholly convinced > > restricting /48s from having a proper 'geofeed:' attribute is the best > > path forward. > > > > How does the working group feel about this restriction? Is it useful? > > Should it be lifted? If the latter, what would be the process? > > > I will ask our Legal team to re-examine the prefix size restriction and keep you and the DB-WG informed. > Regards Ed Shryane RIPE NCC Hi Ed, Did something come out of this? It is a very silly restriction, especially for PI /48's but also for the simple fact that one can register very small prefixes (I've done IPv4 /28 and IPv6 /56) in the actual geofeeds file. Greets, Jeroen

2 1

update on draft-spaghetti-grow-nrtm-v4-00
by Sasha Romijn 04 Feb '22

04 Feb '22

Hello all, FYI, following up on various discussions and the BoF we had on this list about NRTMv4 and NWI-12, a draft has now been submitted. If you’re interested in discussing further details of the proposed protocol, do send your questions and comments to that mailing list. Sasha Forwarded message: > From: Sasha Romijn > To: grow(a)ietf.org > Subject: [GROW] draft-spaghetti-grow-nrtm-v4-00 > Date: Fri, 04 Feb 2022 13:04:48 +0100 > > Hello, > > We’ve submitted a draft for the Near Real Time Mirroring Protocol (NRTM) version 4: https://datatracker.ietf.org/doc/draft-spaghetti-grow-nrtm-v4/ > > This document specifies a one-way synchronization protocol for Internet Routing Registry (IRR) records. The protocol allows instances of IRR database servers to mirror IRR records, specified in in the Routing Policy Specification Language (RPSL), between each other. > > NRTMv4 is intended as a replacement of current synchronization methods mainly based on FTP downloads and NRTM version 3, which have many problems that are addressed in NRTMv4. > > The need for this originated from experiences by users of IRRD v4, and discussions in the RIPE Database working group, tracked under NWI-12: > https://www.ripe.net/ripe/mail/archives/db-wg/2020-November/006720.html > > The broad strokes of this draft were previously discussed in a BoF in the RIPE Database wg, which included several operators of IRR databases, and responses were overall positive. I am also the maintainer of IRRD v4, one of the most widely used IRR database servers, and will implement it in there. > > I’m proposing this draft for adoption by this working group. I would also be happy to present it in the IETF 113 session. > > Sasha Romijn > > _______________________________________________ > GROW mailing list > GROW(a)ietf.org > https://www.ietf.org/mailman/listinfo/grow

2 1