March 2020 - db-wg - mailman.ripe.net

Whois Release 1.97
by Edward Shryane 01 Apr '20

01 Apr '20

Dear Working Group, RIPE Database release 1.97 has been deployed to the Release Candidate environment. We plan to deploy to production on Wednesday 1st April. The major change in this release is to open the NRTM service (regardless of membership status). 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

4 4

Re: [db-wg] API keys for database maintenance
by Gunnar Guðvarðarson 23 Mar '20

23 Mar '20

Hey, My main issue with API Keys is them being attached to SSO accounts. What about when the employee leaves the company? He gets removed from auth on the mntner, all the apps he set-up break? Making admins hesitant about removing user access. API access needs to be bound to the mntner in some form imho. Additionally, would api keys allow querying the API and getting unfiltered data? Or would it just be for `post`ing updates to objects? -- I suspect the signed updates have little usage for two major reasons: * Figuring out if the update succeeded requires receiving and parsing emails * Figuring out if the object is up to date on the ripe database is practically impossible* due to filtering (auth: SSO# Filtered) Sending requests with x509 client cert auth means you know who is sending the request and you have no need to filter data (like the auth sso entries) out for objects the mntner has permissions for, making idempotent api clients so much easier to make. -- The logic i might want to implement, in pseudocode: while true mntners = database(mntners) foreach mntners as mntner objects = rest api request for all objects with mnt-by = mntner foreach objects as object if object not in database notify admin .... or delete it continue if object == database(object) continue rest api request to update object with data from database sleep for a while -- p.s. sorry about my earlier, mangled email, my email client seems to have gone a bit nuts... * okay not "impossible" but really annoying, you'd have to store the last updated timestamp from ripe, for all objects, and if it changes in the ripe db, then we'd have to post the object to see if it changes? ________________________________ From: Edward Shryane Sent: Wednesday, March 18, 2020 15:29 To: Gunnar Guðvarðarson Cc: Tore Anderson; db-wg(a)ripe.net Subject: Re: [db-wg] API keys for database maintenance Hi Gunnar, We're indeed also working on Client Certificate authentication (we have tested it, and now it's pending a security review). However, to make use of this, a user must: - Generate an X.509 certificate - Extract the certificate as text and create a key-cert object from it - Associate the key-cert with a maintainer in an auth: attribute - Configure the Whois client to send the client certificate when connecting to the REST API (or Syncupdates). This is not trivial to do, and we can see that although signed updates are supported in Whois, it has low usage. It is still worthwhile to support this, as the credential (secret) is only stored locally on the client. Hopefully API keys will be more "user friendly" and can be used in preference to MD5 hashed passwords. Regards Ed Shryane RIPE NCC > On 18 Mar 2020, at 09:45, Gunnar Gušvaršarson <gunnar.gudvardarson(a)advania.is> wrote: > > Hey,I think that if we get x509 client certificate authentication for the API working, it might even be easier. > All the UI to add certs and auth them on mntners is already there, the web services just need endpoints that request and use client provided certs. > https://github.com/RIPE-NCC/whois/issues/534

3 2

RIPE Database Requirements
by ripedenis＠yahoo.co.uk 19 Mar '20

19 Mar '20

Colleagues The RIPE Database Requirements Task Force recently published notes on their last meeting showing some of their current thinking and progress so far. This can be read here:https://www.ripe.net/ripe/mail/archives/ripe-db-requirements-tf/2020-M… I am going to play devil's advocate and make a few comments and raise a few questions on this and throw in some issues that may not have been discussed. Some of you may wish to make other comments or discuss some of the points... cheers denis co-chair DB-WG public - should all/some/none of the RIPE Database data content be public? As a public registry, what data is needed by which stakeholders for this to be a useful registry? It is clear from the recent survey that the RIPE Database is used for other purposes, like IPAM. It was suggested in the notes that this could be offered as a separate service. The RIPE Database involves a considerable amount of infrastructure to provide a very reliable and resilient service. Why duplicate that for another service or provide a lesser service if it can be incorporated into the RIPE Database as non public data? So a requirement could be that the RIPE Database will provide a range of IPAM (and maybe other) services to resource holders using non public data. Or perhaps a mix of (non)public data. RPSL - whether or not the RIPE Database stores data internally in RPSL format is a design/technical issue, not a requirement concern. The requirement could be that the RIPE Database uses a common, simple format for managing the data content. This format will be reflected in the user interfaces. Where RPSL is required, a conversion of data content into/from RPSL option will be provided. geolocation - This and the "language:" option were originally added as an experimental service without any concrete requirement. Although it has been discussed several times since, no decision was ever made about it. There were always a few people who liked it, a few who didn't, most had no opinion. Some questions that perhaps need to be answered are:-Once you have a definition of what geolocation means (in the context of the RIPE Database), can the RIPE Database provide a viable and accurate service within that definition?-Can it provide a service with additional/complementary benefits to existing 3rd party services, or will it simply replicate or conflict with existing services?-Is such a service of sufficient benefit to the community/public to justify the effort to maintain it (as an optional/mandatory service)? Postal and Legal address - The RIPE Database T&C says in Article 3 one of the purposes is:"Providing information about the Registrant and Maintainer of Internet number resources when the resources are suspected of being used for unlawful activities, to parties who are authorised under the law to receive such information."Article 10 says the governing law is that of the Netherlands.-Does Dutch law permit such information to be given directly on request to any relevant party or only to/via the Dutch police or Dutch court? In particular other (pan)national LEAs?-The purpose in the T&C does not define the process. Does the Dutch law require this to be with a subpoena or will a formal letter be sufficient? person/role - I don't see the bigger questions being asked:-Is there a need for ANY personal data in the RIPE Database?-If so what, how much, for what purpose, which stakeholders need access to which parts of it?-Should personal data be public? irt - Perhaps we shouldn't get too hung up on numbers of objects or queries. They have a clearly defined role in a specialist area. The numbers are never going to be high. The main question seems to be:-is it a useful service to the (security) community? UTF8 - Something that may not have been discussed yet, but perhaps it is crying out to be considered at a requirement level. The technical aspect has been looked at several times by the RIPE NCC, but it never moves forward because of the social/political/registry/legal issues which cannot be resolved at the technical level:-Should we allow all/some/none of the data content to be in non Latin characters?-Is there some data content that must be in Latin characters (for the correct functioning of the registry?), some that can be duplicated in Latin and local characters, some that can be in any format chosen by the resource holder?-Who can make these decisions (this is the bit that has been missing ever since the subject was first raised)? RIPE Database Purposes - The DBTF preliminary list of purposes does not cover all the currently defined purposes in the RIPE Database T&C. Were the ommisions intentional?

1 0

API keys for database maintenance
by Tore Anderson 18 Mar '20

18 Mar '20

Hi WG. In the LIR Portal, at https://lirportal.ripe.net/api/, it is possible to issue API keys for use with several different RIPE NCC services. However, it is unfortunately not possible to issue API keys for the two APIs that are used for database maintenance; Syncupdates and the RESTful API. The documentation implies that the only authorisation [sic] method for those APIs is MD5-PW. I propose that the API keys mechanism is extended to Syncupdates and the RESTful API. The already existing default maintainer concept could be leveraged to accomplish this (similar to how NWI-8 was implemented). That is, using Syncupdates or the RESTful API with API keys will simply authenticate the client as the LIR's default maintainer. Authorisation should remain handled by in-band mnt-* object attributes, as is currently the case. It would be an acceptable limitation that API keys for database maintenance are unavailable for LIRs without a default maintainer. Assuming the WG agrees that this is a good idea, I request an NWI. Tore

6 12

RIPE DB V2 (Perl) code
by Joao Luis Silva Damas 17 Mar '20

17 Mar '20

Does anyone have a copy of the Perl version of the RIPE DB code. I am looking for some code that I know was there and worked well (was fully debugged) but the RIPE FTP site no longer has v2 or v3 code that I can find (while it still has a copy of the WAIS source code!) So, does anyone have a copy that they can send around, please? Joao

1 1