- db-wg - mailman.ripe.net

Authenticating References to Objects
by Edward Shryane 04 Jun '19

04 Jun '19

Dear Working Group, as mentioned at last week's DB-WG meeting, I'd like to propose extending authenticating references to other objects. Currently, only references to organisation objects can be protected with the mnt-ref attribute. However, we could extend this protection to other types of objects: - Abuse-c role - Technical contact, admin contact, zone contact etc. (person/role) - Organisation maintainer(s) This would prevent unauthorised references to an organisation's objects (e.g. to impersonate a third party or mis-direct abuse email). Please let me know your feedback on this proposal. Regards Ed Shryane RIPE NCC

8 10

NWI-9 In-band notification mechanism - proposed Solution Definition
by Edward Shryane 28 May '19

28 May '19

Dear Working Group, given the Problem Definition for NWI-9: "There is a need within the routing community to have changes to all/nominated routing data objects in the RIPE Database pushed out to them, regardless of membership status." As presented at last week's DB-WG meeting, I'd like to propose a Solution Definition: (1) The current NRTM service is not suitable. The current NRTM is a member-only service, with a separate agreement: https://www.ripe.net/manage-ips-and-asns/db/nrtm-mirroring The work needed to change this (including technical changes to open the service) is greater than providing a re-implementation. The existing service will remain available on the same terms. (2) Implement a replacement NRTM interface The current NRTM is a custom protocol, which is complicated to use, and not easy to extend without breaking existing clients. Instead implement a replacement NRTM interface, based on modern standards. - The interface is generally available without needing to be a member, or to sign an agreement. - The protocol uses HTTPS and WebSockets, with object data in JSON format. - A client can request the current available range of updates, and also request a closed or open range of updates. - A separator comment is inserted between updates, with an 'end of stream' comment after each group of updates. - All object updates are returned, except for person and role objects. - Personal data is filtered from all object updates, consistent with the other query interfaces. - A client can optionally request filtering updates by object type. - A client can optionally identify themselves by providing credentials. - The interface can be extended later by adding more request parameters. Please let me know what you think. Regards Ed Shryane RIPE NCC

3 2

Suggestion further validity-checking
by Jens Ott - Opteamax GmbH 28 May '19

28 May '19

Dear DB-WG, I am newly subscribed to this mailing-list although I am already active in RIPE-community for quite some time. Some of you might know me in person. To be honest, I am not sure if this is the right place to send my mail to and if it's not I'd be happy to be told who to address better. For debugging our prefix-list-generator I increased verbosity of the tool a little. As side-effekt I was also pointed to a route-object in the ripe-database which contains a "hole"-definition where the netmask doesn't match (X.Y.226.0/21) and actually is the same size as the entire route-object. I already contacted the maintainer of that object but think it might be a good idea to add a validity-check on adding new objects to prevent this kind of faulty objects in the DB. Best regards -- Jens Ott Geschäftsführer Opteamax GmbH Simrockstr. 4b 53619 Rheinbreitbach Tel.: +49 2224 969500 Fax: +49 2224 97691059 Email: jo(a)opteamax.de HRB: 23144, Amtsgericht Montabaur Geschäftsführer: Jens Ott Umsatzsteuer-ID.: DE264133989

6 10

NWI-8: LIR's SSO Authentication Groups - Implementation Plan
by Edward Shryane 27 May '19

27 May '19

Dear working group, here is the RIPE NCC's proposed implementation plan for NWI-8: LIR's SSO Authentication Groups. Scope - To simplify the implementation, synchronisation will be done using the existing SSO authentication method. - Authentication groups (and any new authentication method) will be deferred until later. Introduction - The synchronisation of non-billing users with the RIPE database will be done with a default maintainer. - Setting a default maintainer for the organisation is a pre-requisite for synchronisation. - A default maintainer is already able to maintain the organisation object and top-level resources. - Extending this existing mechanism simplifies the synchronisation of users. Implementation - A new checkbox will be added to the Account Details page in the LIR Portal, in the Maintainer section. - "Synchronise non-billing users with the default maintainer". - If no default maintainer is set, the checkbox is disabled. - The synchronise checkbox is not checked by default (the user must confirm this action first). - When the user enables the synchronise checkbox, they must first authenticate with the default maintainer. - The user must prove they control the maintainer before user accounts are added to it. - If the user's account is already present on the maintainer, this authentication is automatic. - Otherwise if the maintainer contains any password credentials, the user will be asked for a password. - Otherwise the user is asked to first add their credentials to the maintainer separately. - Once the checkbox is enabled, synchronisation is performed. - Any existing user accounts are removed from the maintainer. - Any non-billing user accounts are added to the maintainer. - Any other credentials (passwords or PGP keys) are not affected. - After synchronisation is enabled - Whenever a non-billing user is added or removed from the organisation, the default maintainer is updated accordingly. - A default maintainer can only be synchronised with a single organisation. - If a user is removed from one organisation, but remains in a different organisation, this would create a conflict when synchronising. - If synchronisation is disabled - Users are no longer synchronised with the default maintainer, but existing user accounts are not removed. - Notifications - To receive email notifications when the default maintainer is updated, use the notify: and/or mnt-nfy: attribute(s) on the maintainer itself. Regards Ed Shryane RIPE NCC

3 3

Agenda RIPE78 - Database Working Group
by William Sylvester 15 May '19

15 May '19

Database WG Members, Please find the attached agenda for the RIPE Database Working group meeting in Iceland. Regards, William & Denis A. Introduction - 5 min * Welcome * Scribe * Jabber * Agenda B. Operational Update RIPE Database – 20 mins Edward Shryane, RIPE NCC C. Personal Data in the RIPE Database – 15 mins Denis Walker D. Cleaning Up Locked Persons – 10 mins Edward Shryane, RIPE NCC E. Country Codes Proposal – 10 mins Nikolas Pediaditis, RIPE NCC F. NWI - Open Proposals – 5 mins Z. AOB (open discussion)

1 0

Whois Release 1.94
by Edward Shryane 08 May '19

08 May '19

Dear Working Group, RIPE Database release 1.94 has been deployed to the Release Candidate environment. If no issues are found, we plan to deploy to production on Wednesday, 8th May. Release 1.94 includes the following changes: * Notify the user in the abuse-c comment if address validation has not been completed. * Improved email address validation. * Perform daily limit accounting for personal data in the Full Text Search interface. * Do not remove an abuse-mailbox attribute from a role object, if that role is referenced in a resources' abuse-c attribute. The complete list of changes in this release can be found in GitHub: https://github.com/RIPE-NCC/whois/blob/master/changes.txt The release notes have been published: https://www.ripe.net/manage-ips-and-asns/db/release-notes 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

NWI-9 In-band notification mechanism? ???
by ripedenis＠yahoo.co.uk 15 Apr '19

15 Apr '19

Colleagues Problem Definition There is a need within the routing community to have changes to all/nominated routing data objects in the RIPE Database pushed out to them, regardless of membership status. Last week Aris was the only person to confirm that he wants this feature. If we are to move forward with this feature can a few more people wave their hands in the air, or send a +1 email. cheersdenis co-chair DB-WG

6 5

NWI-8 LIR´s SSO Authentication Groups
by ripedenis＠yahoo.co.uk 15 Apr '19

15 Apr '19

Colleagues I think we have now agreed on these problem and solution definitions: Problem Definition LIRs would like a mechanism to easily add/remove users to centralised SSO authentication groups for maintaining objects in the RIPE Database. Solution Definition Stage 1 -Non billing Users listed in an LIR´s portal account will be contained in a default authentication group -Non billing users added or removed through the portal UI will be automatically adjusted in this group -This authentication group can be referenced in MNTNER objects by a new authentication method -These authentication groups for LIRs will be stored in a way that updates to the RIPE Database is not dependent on the availability of the portal service Stage 2 -Non billing Users listed in an LIR´s portal account can be added to and removed from user defined SSO authentication groups -Each User can be a member of any number of named groups -The authentication groups can be configured using the portal UI -These groups can be referenced in MNTNER objects by the new authentication method The chairs will now ask the RIPE NCC to work from these definitions in preparing their implementation plan. cheersdenis co-chair DB-WG

2 1

NWIs update
by ripedenis＠yahoo.co.uk 10 Apr '19

10 Apr '19

Colleagues We would like some feedback on the following NWIs and their current status. I would also like to remind colleagues that we have posted a couple of questions on the Address Policy WG mailing list about policy requirements for contact details. We would appreciate some feedback on those questions on that mailing list. cheersdenisco-chair DB-WG NWI-7 abuse-c implementation If the RIPE NCC can confirm that the cleanup of PERSON, ORGANISATION, MNTNER and IRT objects has been done to remove any "abuse-mailbox:" attributes and the 'person' keyword has been updated to take account of the "abuse-c:", we would like to mark NWI-7 as 'Finished'. NWI-8 LIR´s SSO Authentication Groups We agreed on this problem definition: Problem DefinitionLIRs would like a mechanism to easily add/remove users to centralised SSO authentication groups for maintaining objects in the RIPE Database. Do we agree on this (staged) solution definition?(Draft) Solution Definition Stage 1 -Non billing Users listed in an LIR´s portal account, who have an SSO authentication account, will be contained in a default authentication group -Non billing users added or removed through the portal UI, who have an SSO authentication account, will be automatically adjusted in this group -This authentication group can be referenced in MNTNER objects by a new authentication method -These authentication groups for LIRs will be stored in a way that updates to the RIPE Database is not dependent on the availability of the portal service -(Non billing users who did not have an SSO authentication account who then create one, will be automatically adjusted in this group - NCC, is this feasable?) -(Non billing users who are listed in the LIR's authentication group who then delete their SSO authentication account, will be automatically adjusted in this group - NCC, is this feasable?) Stage 2 -Non billing Users listed in an LIR´s portal account, who have an SSO authentication account, can be added to and removed from user defined SSO authentication groups -Each User can be a member of any number of named groups -The authentication groups can be configured using the portal UI -These groups can be referenced in MNTNER objects by the new authentication method NWI-9 In-band notification mechanism? ???Is there a wish to create this issue as an NWI with the following problem definition? Problem DefinitionThere is a need within the routing community to have changes to all/nominated routing data objects in the RIPE Database pushed out to them, regardless of membership status.

9 25

Call for Presentations / Draft Agenda RIPE78 - Database Working Group
by William Sylvester 08 Apr '19

08 Apr '19

Dear Working Group Members, Below is the proposed agenda for the Database Working Group for RIPE78. 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 – 50 mins Edward Shryane, RIPE NCC C. Proposed Presentation HERE – 10 mins D. NWI - Open Proposals – 5 mins Z. AOB (open discussion)

1 0