January 2024 - db-wg - mailman.ripe.net

Phone number requirement for person objects
by Cynthia Revström 06 Aug '24

06 Aug '24

Hi, In the DB-WG interim session I mentioned that there's currently a discrepancy between person objects and role objects with regards to contact information. More specifically, person objects currently require a phone number while role objects require an email address. I think we should try to bring person objects more in line with role objects by removing the phone number requirement. Ideally I would want it to be mandatory to have either a phone number or an email address in order to not lose any flexibility but I'm not sure if that is possible. During the session I asked if anyone was opposed to the idea and no one said they were so I would assume that this is relatively uncontroversial but please let me know what you think. -Cynthia

4 6

Proposal to allow non-ASCII characters in "org-name:", "person:" and "role:" attributes
by Edward Shryane 28 May '24

28 May '24

Dear colleagues, Currently the RIPE database only allows a subset of ASCII characters in the "org-name:", "person:" and "role:" attributes, for a few reasons including: * These attributes are also a look-up key and the Whois protocol does not allow specifying character sets in queries. * RPSL names are ASCII according to RFC2622 * Using a normalised name makes the object easier to query * Reading a normalised name is easier to interpret However there are some drawbacks to forcing names to only use a subset of ASCII characters: * Organisations, roles and persons cannot use their actual name if it includes characters outside this subset. * Normalisation is not standard, but is an interpretation done by each maintainer, e.g. characters could be excluded or converted in different ways. Since we support the Latin-1 character set in the RIPE database, I propose we also allow non-ASCII Latin-1 characters in these attributes. Querying for a name can be done either using the latin-1 characters (proposed) or a normalised, ASCII representation (currently). The normalised version will be generated by Whois and stored in a database index for querying. The primary key will also be generated from the normalised version. Please let me know your feedback. Regards Ed Shryane RIPE NCC --- Whois attribute verbose description (copied from the help text). org-name -------- Specifies the name of the organisation that this organisation object represents in the RIPE Database. This is an ASCII-only text attribute. The restriction is because this attribute is a look-up key and the whois protocol does not allow specifying character sets in queries. The user can put the name of the organisation in non-ASCII character sets in the "descr:" attribute if required. A list of 1 to 30 words separated by white space. A word is made up of ASCII alphanumeric characters and additionally: ][)(._"*@,&:!'`+/- A word may have up to 64 characters and is not case sensitive. Each word can have any combination of the above characters with no restriction on the start or end of a word. person ------ Specifies the full name of an administrative, technical or zone contact person for other objects in the database. It should contain 2 to 10 words. A word is made up of ASCII alphanumeric characters and additionally: .`'_- The first word should begin with a letter. At least one other word should also begin with a letter. Max 64 characters can be used in each word. role ---- Specifies the full name of a role entity, e.g. RIPE DBM. A list of 1 to 30 words separated by white space. A word is made up of ASCII alphanumeric characters and additionally: ][)(._"*@,&:!'`+/- A word may have up to 64 characters and is not case sensitive. Each word can have any combination of the above characters with no restriction on the start or end of a word.

9 17

Preferred names in the database
by Harry Cross 22 May '24

22 May '24

Dear all (copying this to both the Diversity list and the Database list), I hope you’re having a wonderful weekend and recovering from Rome. I’d like to begin thinking about a proposal for preferred names in the database/on resources. Some may have noticed this week (and for a bit prior), I have begun going by Harri instead of Harry. At the moment there is no correct way for me to represent this in the database, as an LIR the details have to match my legal name. I may think about going through the legal processes to change this soon (albeit in the UK this is easier than a lot of places). I know a few people hold their resources under a shell company for this purpose, (e.g I could incorporate Harri Cross Limited to hold the resources and be in the database). This applies to end users who hold PI or ASNs alongside LIRs. It would be good for us to think about a way for these preferred names (and pronouns?) to be shown in the database alongside the process for changing the name of an end user. I know the preferred way a lot of people in this situation would like this to be handled is to totally mask the legal name in the database. The NCC could still validate legal names to know who they are working with - and we will need some compromise here I suspect. A complete lack of verification is of course a bad thing. I have experienced talking to the NCC when handling end users in these situations who have legally name changed and the process seems to be incredibly hard with the lack of understanding on documentation for name changes. Responses from the Registry have included “How can we be sure that <oldName> and <newName> are not identical twins?” (Which in my mind, is rather disrespectful). I also have another name change in process that is being stonewalled by a lack of understanding of documents in different jurisdictions for this. Kind Regards, Harri Sent from Outlook for iOS<https://aka.ms/o0ukef>

3 2

email's disappeared from RDAP output
by Ben Cartwright-Cox 05 Apr '24

05 Apr '24

Hi everybody, I was just re-running some tests internally within bgp.tools and I've noticed that the RDAP responses from RIPE no longer include the email address of the person object. For example I used to (and expected) to get the email address in the object for https://rdap.db.ripe.net/entity/BC6775-RIPE, but it seems to have been removed from the output at some point. That does not appear to be a way to log in to authenticate trustworthiness of RDAP responses, is there any other way to get this information? I can see this information on the RIPE website ( https://apps.db.ripe.net/db-web-ui/lookup?source=ripe&key=BC6775-RIPE&type=… ) but I do not want to scrape that, and this information is incredibly useful for helping users onboard ( with a trustworthy email address ) to services like bgp.tools. Is this an intended change? Have I done something silly? All of the above ;) ? By looking at the release info I can see it was added in November (#1333) Thanks Ben

7 18

DB WG interim session January 2024
by David Tatlisu 06 Feb '24

06 Feb '24

Hi, Picking up from RIPE87, the first interim working group session for the Database Working Group is planned for 17 January 2024, 15:00–16:00 UTC. The following topics are on the agenda right now: * Discussing the two possible solutions for NWI4 (multivalued status:) * Discussing the use of UTF-8 in the RIPE database * Following the recent breach, feedback on how authentication could be improved * Leo Vegoda and Dmitry Kohmanyuk would like to talk about alternative modes of contact in the RIPE database * Any other business Kind regards, Denis, William, and David https://ripe.zoom.us/j/99068479472 Alternatively, dial by your location • +1 253 205 0468 US • +1 253 215 8782 US (Tacoma) • +1 301 715 8592 US (Washington DC) • +1 305 224 1968 US • +1 309 205 3325 US • +1 312 626 6799 US (Chicago) • +1 346 248 7799 US (Houston) • +1 360 209 5623 US • +1 386 347 5053 US • +1 507 473 4847 US • +1 564 217 2000 US • +1 646 558 8656 US (New York) • +1 646 931 3860 US • +1 669 444 9171 US • +1 669 900 9128 US (San Jose) • +1 689 278 1000 US • +1 719 359 4580 US Meeting ID: 990 6847 9472 Find your local number: https://ripe.zoom.us/u/adsp2SzA80

5 6

geolocation purpose
by Maria Stafyla 24 Jan '24

24 Jan '24

Hello all, As you may have seen in the minutes from the RIPE NCC Executive Board's most recent meeting (on 6 October 2023), the Executive Board approved the amendments to the RIPE Database Terms and Conditions. The RIPE Database Working Group had reached consensus that the provision of geolocation information should be included in the list of purposes of the RIPE Database. Accordingly, the approved amendments to the RIPE Database Terms and Conditions include this new purpose and replace the pronouns 'he/she' with the gender-neutral singular 'they'. You can access the RIPE NCC Executive Board Meeting minutes at: https://www.ripe.net/about-us/executive-board/minutes/2023/minutes-168th-ex… And the updated RIPE Database Terms and Conditions are available at: https://www.ripe.net/manage-ips-and-asns/db/support/documentation/terms In the next whois release, we will remove the prefix size validation rules, which we had to implement to restrict unnecessary processing of personal data when geolocation was not yet a defined purpose of the RIPE Database. If you have any questions, please let us know. Kind regards, Maria Stafyla Senior Legal Counsel RIPE NCC

2 1

Re: [db-wg] [ncc-services-wg] Enforce 2FA for RIPE NCC Access account
by Daniel Suchy 04 Jan '24

04 Jan '24

Hi, Denis is right, the problem isn't only RIPE access and I aggre DB needs to be redesigned in terms of security - we're talking not only about LIR portal and RPKI dashboard, which caused issue with Orange. If you break objects in DB in similar manner (as-sets, route objects), you'll cause similar outage - just because many upstreams and IXP use these data to build their prefix filters. Maybe the destruction will not be so fast... For some methods (restAPI) you need password linked to maintainer object. And all passwords here are still stored in MD5! Yes, this is year 2023. There's no other option [1]... All this is one big ticking bomb... I don't want to guess what could happen if the internal in case of internal RIPE database leak. Just because we're still storing some passwords in prehistoric way. It's not only about LIR accounts, risks are also hidden in maintainer objects, which can be used outside LIR portal. And it's out of reach of one working group. Trivialization of risks is highway to hell. And there're more things, which needs better protection - not only RPKI ROAs. - Daniel [1] https://apps.db.ripe.net/docs/Authorisation/Authorisation-Model/#solving-au… On 1/4/24 21:24, Jim Reid wrote: > IMO, no. Your question is a bit like asking what colour the new carpets should be while the house is on fire. :-) > > The first priorities should be to plug the security issue(s), secure the exposed LIR accounts and do an audit/impact analysis. Discussions about next steps can wait until these have been done. Those next steps may well include a redesign of the RIPE database. Though I think other things would need attention before that: revising the RIPE Access requirements, introducing 2FA, assessing the report about the latest breach, etc. > > It seems premature to debate changes to the database when it’s not yet clear what needs to be done. That may well be clear to you Denis. But perhaps your thoughts will need a reassessment in light of this security breach. > >

1 0