Fit for purpose? Task Force presents first draft of future RIPE Database

2020-05-14 Blog

By Monika Ermert, eLance journalist - The first RIPE database came into being in 1992. It started as a contact database for the then limited number of Local Internet Registries, but has gradually changed over time. With new EU data protection rules entering into effect in 2018, it is time for yet another iteration. Bijal Sanghani, EuroIX, presented the background and a proposal to move forward at the RIPE Virtual Database Task Force BoF on 6 May.

A database of databases

A six-person task force has been set up to produce the “RIPE Database Requirements”, which will make it clearer – and more legal – to process data in future. Peter Koch (DENIC), Shane Kerr (former Ripe Database manager), Nick Hilliard (INEX), Bijal Sanghani (EuroIX), Sara Marcolla (Europol) and James Kennedy (Liberty Global) listed the Internet Number Resources (INR) database and the Internet Routing Registry (IRR) as core parts of the RIPE Database.

The draft states that the INR shall “ensure the correct availability of information related to the resources and their holders and maintainers and the uniqueness of Internet number resources usage through registration” while the IRR shall allow operators to publish routing policy information for AS objects and “show how a particular network is routed on the internet. Announcing routing policies in the routing registry gives network operators an opportunity to configure their routers and filters accordingly”.

However, the INR and IRR are not the only database features the task force found. The task force highlighted the Reverse Domain Name System (rDNS) mapping, which helps to map IP addresses back to domain names and “enables the use of the core address registry for provisioning authorisation purposes (reverse mapping follows inetnum: and inet6num:)”. Furthermore, the Resource Public Key Infrastructure (RPKI) is an integral part of the effort to secure the routing system through proof of resource holder authenticity, with the RIPE NCC acting as a Root Certificate Authority (CA), the central trust anchor.

No helicopter view? responds the community

The first draft has received tentative criticism for its detailed treatment of various specificities. RIPE NCC Chief Scientist Daniel Karrenberg said during the BoF that he had hoped for a more high-level perspective.

Examples would be what parts of the RIPE Data Base should be public, and whether there is actually “a need for ANY personal data in the RIPE Database?”, Denis Walker, Data Base Group Co-Chair, suggested before the BoF. Mapping the status quo is interesting, but a purpose statement should start from questions like “as a public registry, what data is needed by which stakeholders for this to be a useful registry?” he continued.

Focusing on the privacy tussle, Walker also stated that the community had to address whether Dutch law would permit postal and legal addresses to be handed out from RIPE NCC at the “request [of] any relevant party or only to/via the Dutch police or Dutch court?” Would (or should) (pan)national LEAs (such as Europol) get a special status?

In search of purpose

An attempt to establish the need for data types by surveying the RIPE members was indeed made by the task force. Results indicate a community interest in looking for the “main” and “other” customers of the existing databases.

According to Sanghani this survey offered some rather unexpected results, for example that around half of the members who answered the survey (206 members) did in fact use the RIPE Database for their IP address management (IPAM). The result was mirrored by a quick survey of the three dozen BoF attendants.

Peter Koch (DENIC) argued that the result should trigger additional research into IPAM practices and how they used the database. A different suggestion was the development of new RIPE NCC tools oriented towards RIPE Database-facilitated resource management.

Also surprisingly, around a quarter of the surveyed members said they rely on the RIPE Database for geolocation information and as many as 32 members preferred to keep it as a data point, despite the known weaknesses of geolocation.

Tahar Sha, who consults for the German Ministry of the Interior, stressed to BoF participants that if this data is kept, its accuracy becomes the responsibility of the RIPE NCC and RIPE members. “If you declare it as a source for this information, it has to be accurate. Inaccuracy could quickly lead to regulation”, he cautioned.

The accuracy issues have also been raised by one of the newer “customers” of the database, law enforcement agencies. They are represented in the task force by Sara Marcolla from Europol, and have championed some of the recent policy proposals by law enforcement agencies over additional data points and enforcement of RIPE contractual obligations for members (“Publication of Legal Address of Internet Number Resource Holder”).

Way forward

Both the high-level purposes of a RIPE Database of databases, and issues of accuracy remain to be discussed. If legal addresses and geolocation data is required, whose legal address and whose geolocation should be included? And why? The end-users’, the AS holders’ or someone in between? After the BoF, both questions and answers remain to be formulated.

The draft requirements for a RIPE database 2.0 will be a topic at the virtual meeting. The looming question remains how to establish the purpose of data collection, and how to decide if original and new customers - all of which have been listed in the most recent Database Terms and Conditions document (from 2016) – can request that the database works for their needs and should reflect this purpose accordingly. A final draft was promised for the RIPE81 meeting.