Thursday, 21st May 2026.
Side room. Database.
9am:
PETER HESSLER: Hello everyone, welcome to the RIPE 92 session of the database working group. If you are interested this IPv6, that's next door. Otherwise we are here to enjoy our lovely database.
I want to welcome you and give a few bits of information. Today will be scribed by Hans Becker for the NCC, we, of course, have our lovely stenographer. Our co‑chair, David, has been selected for another term, so congratulations to David. The minutes for the RIPE 91 meeting were published last week and they are on the mailing list. We ask that the working group review them and send the ‑‑ comment and respond by May 31st, approximately two weeks from now. Sorry, a little over a week, you have the rest of the meeting and next week to handle that and we'll send a reminder email later today to the mailing list.
Piotr and Neil found some of the missing minutes from RIPE 70 and RIPE 72 and they have been uploaded and put on the website in the archives and the only missing minutes are from RIPE 73, so great work for that.
The agenda today is after this they will be talking about the NWI update and then Ed will give the world famous NCC operational update on the database and the database team and then Sasha will talk about mirroring with NRTMv4 and we'll do our closing. And with that, I'd like to invite David up to talk about the NWIs.
DAVID TATLISU: Hi everybody. It was ago interesting six months since the last NWI update, we have closed NWI‑2, just relayed to removing or adjust arbitrary limitations, Denis has put in the database quite a long time ago, related to the retrieval of historical database and NWI 17 which was created to implement the recommendations from the database task force but due to legal concerns and overall just dying interest about this specific topic we decided to close both of them. NWI‑12 has been in the database for about a year now. Even though the RFC and IETF process isn't finished, we can effectively say the NCC part of the implementation is already finished.
I would suggest that we consider closing this NWI and after maybe after Sasha's presentation we can discuss this in further detail in the AOB.
NWI‑20, Leo has put in a lot of work to overhaul the contact methods, it's a larger NWI overhauling how contacts can be used in the RIPE database, this has been shipped already, thank you a lot because this allows users to for example specify URLs for signal contact or WhatsApp contacts and just make finding people, finding the people or contacting the people you want to find much much easier.
With NWI‑21, there's some internal tasks that need to be continued within the NCC, but the implementation is ongoing and over 32,000 organisational objects already have the new registration number attribute making finding identifying organisations much easier. That has been the last six months. So if you have any questions or anything, please come to the microphones.
That is what I expected. So I welcome Ed on the stage with his operational update.
(APPLAUSE.)
EDWARD SHRAYNE: Hello, good morning, and thank you David. So my name is Edward Shrayne, I am a product owner at the RIPE NCC, working on the database team.
Here are my colleagues who contributed to all of the work that we did in the last six months. Progress since the last RIPE meeting. We produced, we released six who is releases highlights since the last RIPE meeting, we implemented NWI‑21, the registration number, we added support for UTF 8 in free tax attributes and implemented NWI 20, which is contact requirements and adding new methods as Peter ‑‑ as David just mentioned.
First up, sink updates requests vulnerable to X cross‑site scripting attack, and that is something that Sasha presented on Monday. And firstly, my thanks are to Sasha for bringing this up and being persistent in chasing us to get this fixed. It was raised as a responsible disclosure in February last year. The disclosure text pointed to a cross set scripting issue, since fixed, specifically the DNS check that ‑‑ yeah, could be escalated, potentially, to a RIPE database cross‑site issue.
And Sasha included a no‑course fetch example. Unfortunatley, we took the disclosure to mean we needed to improve our cost implementation, we did some work in approving that; we added an allow‑list of permitted sites and thought that it was job done. Sasha came back to us and pointed out, in fact, the example supplied still is broken, we made two releases on the 16th and 18th March to first to add an origin header but as the example shows, in some cases browsers can send cross origin requests with no origin header, there was no way for us to tell where it was coming from and these requests are sent with a secure cookie, which could potentially cause a problem. What really helped this time was to talk directly with Sasha and it was really helpful to get to the bottom of the issue and we fixed it on the 18th March.
The consequence is that now a sink updates get requests are no longer supported, this is a historical feature that was add add long time ago back in the days when it was difficult to script HTTP requests, the mechanism was to euro a link code the update and accepted it in a simple get request but it's difficult to secure that and looking at the usage traffic, only one maintainer using this and they stopped doing it in January with the password, when we removed passwords the script stopped and that was the end of that.
It was easy to retire that mechanism.
Lessons learned in upcoming work from that, we are shortly going to switch from the RIPE.net cookie that allows this cross‑site authentication of logged‑in users, we'll be starting to use OpenID connect which will just authenticate you for the RIPE database. And this is already being done in RIPE state and RIPE Atlas and shortly it will be stand in the RIPE database as well. That will close that loophole of cross‑site security cookies; and secondly, adding a contents security policy to restrict injection in java script as pointed out in Sasha's presentation, a straightforward way to protect our site and the use of HSTS to tell the client they should be connecting securely. Right now we allow insecure connects, we redirect to HTTPS but this is a way to tell the client, use HTPS only from now on.
Unfortunately there were some RIPE database outages since the last RIPE meeting, I will give more details, you may have seen an unexpected error occurred at certain times of the day in February and March. It was hard to find the source of as everything was mostly fine in our monitoring and statistics, we saw a handful of reset packets around the time of the issue, but thankfully our ops team were able to get to the bottom of, it was caused by traffic spikes for the load balancer exceeding a single leg of the link aggregation. Set up that we have.
And the solution was to switch to a larger link aggregation bundle switch, which will handle any expected traffic that will have ‑‑ will solve the problem.
Secondly, we did see some intermittent connection errors, you may have seen some intermitent connection errors last week caused by the handling of many RDAP queries at the same time; specifically, the RIR search feature, it can return a lot of data and be very time consuming. So for now we have limited the response size to deal with that, we are going to go back to it and look at it in a little bit more detail, so we can serve these requests to our clients but reduce the impact that they are having on the service as an a whole.
Finally, occasionally you may see authentication failed, even though your API key is still valid, we were looking into that, it happened a little bit more at the beginning of the month.
But we have now looked into it and it's, we are investigating the root cause, we are looking to improve that so you shouldn't be seeing authentication failed in that case.
And apologies if you were affected by any of those issues.
A few statistics, and some changes since RIPE 91. Firstly, we have seen a lot more dramatic increase in the number of the use of allocated assigned PA in INETNUM plus 42% since RIPE 91. Clearly, this is useful, our community finds this useful, and it's a useful feature to combine an assignment and allocation together into a single object. We have slightly more PC addresses, 83% remain to be validated this year but as usual, the registry team are busy at the beginning of the year with billing. So as the year goes on, we spend more time to address this, to validate it, to make sure we do validate all be abuse C addresses yearly.
Thirdly, we see there's slightly more uptake in synchronising the LIR portal users to the default maintainer, this is a useful feature maintaining both the RIPE database and the portal, it's check box you can check in the portal to synchronise your RIPE end users and regular users from the properly to the RIPE database so you don't need to keep a list of users in two places. But I'd enencourage you to have a look at it, only 10% of our LIRs are using it right now but it could be a time saver for you.
There's been an increase in aggregated by LIR, that's RIPE 822. That change happened a few years ago.
There was a little bit more uptake, the idea was to reduce LIR efforts in registration and maintenance by combining assignments togethe. It's already used a lot on the INET6num site, there was over 70,000 of them but it looks like there's a little bit more uptake for IPv4 but I think given the number of assignments in the RIPE database, there's four million of them, this could be a useful feature to combine your similar assignments together so you don't have so much data in the RIPE database to maintain.
And a question for the community, should we encourage maintainers to aggregate IPv4 assignments like already done in IPv6.
Next was the MNT ref feature to there's been some uptake in that, it's already done across the board on organisations objects but it's possible for you to use this for maintainer person in role also. Sasha will present on this later, but it was interesting to see that the uptake on NRTMv4 is already very good. I see something like threee times the number of clients. Maybe Sasha can explain why I am seeing all this traffic but it's great to see this feature getting a lot of use.
And finally historically in the past the uptake of RDAP has been pretty low between 5 and 10% but I had another look this year and in the last year it's dramatically increased, now about 20, 22% of all of our database queries are evidence through RDAP.
Next up is hash passwords, after a long period of phasing out hash passwords, we finally can say they are no longer supported, they no longer exist in the RIPE database.
MD5 was a security risk and we had to remove it, many thanks to the community for their help in the smooth transition in the end.
Most maintainers had already switched to switched to an alternative by the time it came to turn it off and we checked, there was no significant drop in successful update volume thankfully and most affected maintainers, less than a one of them, they switched to an alternative within a week. So it was nice to see that there wasn't a huge disruption to operations by doing this.
We also removed MD5 hash passwords from all IRT objects on the 4th March; this affected a couple hundred IRT objects. Related to removing passwords, we also added API key expiry warning to the update responses so every update that you make with who is, if there's less than two weeks remaining on your key, we will notify you in the response, it's time to take action and generate a new key and replace the existing key in your script.
And in addition to the email warning that you get from RIPE NCC access.
Secondly something we promised during the discussion phase of the proposal was to add a flag to the users page on the portal so you know which users have created an API key.
And maybe scripting changes on your behalf.
And then finally we updated the documentation to reflect the changes that we need.
What are the alternatives to password authentication, so mostly we have seen that API key authentication has replaced the use of passwords. Although the use of BGP seems to be slightly up as well. There's an opportunity to use X5 now. It's not just for email updates, you can use it for client certificate authentication for HTTPS so you can use it on rest updates too. And the remainder of the SSO is interactive updates through the website with a logged in RIPE NCC access account.
As I said we now support UTF 8 in the RIPE database. We know from previous meetings and discussion, Latin 1 encoding is very limited. It only supports western Europeans characters, users, we have a huge service region and users who should be able to use their own language, own script in the RIPE database and we can see UTF 8 is supported... we follow ICANN guidelines for implementing international lied domain names, any code point allowed in an international lied domain name will allowed in these attributes. The standard allows domain names to use characters outside the basic Latin alphabet, we have implemented this using the Unicode I C U library which uses UTS46 mechanism, it's compatibility transition mechanism that supports ID N 2008 but also 2003, the previous standard.
Here's an example. My own database object. In addition to the first few remarks there at the top, which are all valid Latin one characters, there's a couple of additional rows now, we tested with Cyril lick, Arabic and Greek for example, this is what you will see on the modern interfaces we support, the web application, the west API, you will see these characters, what you see on the legacy interfaces you will see substitution question mark for remarks if the character cannot be represented in the Latin one character set so we didn't make any encoding changes to any of the interfaces, so port 43 remains a Latin one, and NRTMv4 version 3 the existing dump files remain Latin one and you will see substitutions made for UTF 8.
A couple more details, our colleague Ondrej found an issue with decomposed Unicode code points. They are not correctly normalised, for example, and can be represented as two separate Unicode code points; they should be normalised to a single code point but they are not.
So that represents the, you can see, you can end up seeing some denormalised formula response and this is why, we have already fixed it, we chose NFC normlisation as part of the IDNA transformation and that will be fixed in the next WHOIS release.
Secondly the version flags are returning inconsistent encoding, it should be returning Latin one of course, along with the other flags. We will fix that in an up coming who is as well and we should allow the minus... flag to be used with those version flags, you will have the choice, you can chose the encoding yourself.
Unfortunately, emojis are in the supported, it's for discussion, we could ‑‑ if there's a strong feeling that we need to support this in the RIPE database, we can make an exception.
And to say again that description and remarks, these free text attributes are not intended for storing personal data, we are not filtering them and they don't count towards the daily limit for accounting. So yeah, please use it for operational information and keep personal data in address person as usual.
Next steps, I think this is only the beginning. We have shown we can successfully UTF 8 in the database. Should we support UTF 8 in other attributes, I would be happy to hear your feedback.
And just point out lastly we did already conduct an impact analysis on the use of UTF 8 and the impact on operations in the NCC and interoperability with the community, also important things to keep in mind as we start using UTF 8.
ISO‑27001, the NCC committed in the activity plan to work on achieving ISO‑27001 compliance including software engineering and the database team, we have worked on improving development and release process, vulnerability scanning, this has been standardised across the different software engineering teams, we have written a business continuity plan, we have a risk management plan that we are keeping updated as part of this process, we are reviewing that.
The good news is we have already done an internal audit, we haven't found any issues and there will be an upcoming external audit later this year.
Going back to contact types. NWI‑20, we have now implemented, what changed due to numbered work item 20, the two major works were harmonise the personal role objects and add a new contact the four things, the email attribute becomes mandatory in person, the address attribute becomes optional on both person and role and the phone attribute becomes optional and and new contact is optional attribute, it's giving maintainers more flexibility in how they prefer to be contacted.
And since go‑live at the end of April, now our maintainers have ‑‑ it now allows, because address is optional, it's now not there on 80 roles, it's already had an effect. A question we were wondering, was there an increase in creator update errors in failures for persons due to the missing email, and thankfully not. You may have seen a mandatory email attribute missing that will be now report onned, the email is mandatory but it only effects 20 or 30 failures out of five to 10,000 failures for persons daily, so it's really small change.
NWI‑21 registration number, it's ‑‑ we are now publishing the organisation accompanying the company registration number in the RIPE database in addition to the organisation company name and country because if you only rely on the name and the country, it can be a big risk and it can can hard to identify the resource holder. My colleagues Marco Schmidt made a presentation at the last RIPE meeting with all of the details, we are now publishing the registration numbers, if the ‑‑ we do, we exclude natural person or government entities, we will publish not applicable for those types of organisations.
In the implementation, it's been going on this year. The registry team validated and normalised the data so you should see consistent data per registry, per region in the database. Our colleagues in the software engineering department implemented synchronisation, like already happens for organisation name changes, the registration numbers is also synchronised from the internal registry and we added to the registration number as a managed attribute and that's visible in the web application.
And on the deployment. Yeah, we sing analyse that data on at the end of last month.
Future work: This is the initial implementation. The data is now in the database but for now the registration number attribute is not included in the daily dump and split files, there's dock documents we need to update before we can do that. Secondly, on investigation there is currently no link from registration number attribute to a registry website, that turned into a bigger problem, a lot of more work than we expected and it's not a part of the initial implementation but it's something we would like to do to make it easier for users to interact and use this information.
And finally this information should be added to RDAP responses but it will need an extension to RDAP 2 in order to do that.
So we'd love to hear back from you, please report any issue you find with the data quality, your own registration number, for example, or others. And one final thing that came up on the list, Denis pointed out, I'd like to hear if there's any confusion around the name of the attribute name. And I promised an update at the RIPE meeting and I talked to my registry colleagues and found that so far there hasn't been any reports from our users of any confusion with the registration number, the naming. And it's something that we do use ourselves internally along with the registration ID, but I'd like to hear from you if, your comments on that.
My resources and IP analyser, this is an existing feature in the portal, but it hasn't been ‑‑ it's been there for many years. We decided to move it over to the resources part of the website. The data is already in the RIPE database so it made sense to move it to resources so the database team could also maintain it from front to back. It means that the those features are now integrated in the resources page. If you, in particular, if you want to automate this information, if you want to retrieve this information from script, even resource information or IP analyser reports, you can now do that using new types of API keys that we have created.
The IP analyser page also available under resources. There's no need to create an API key to see that. You will get that report by default when you go to the page.
And yeah, as I said, the authentication is now using this new API key method that it's tied to your RIPE NCC access account. But also to your organisation. Something that was a ‑‑ that this was not case in the old implementation so now if the user leaves the organisation, their key will stop working since they are no longer associated with the organisation.
RDAP, we made improvements in the RDAP implementation in co‑operation with the other RIRs, we were already redirecting IANA administrative blocks and now for ‑‑ we are now redirecting those for ‑‑ to the authoritative RIRs for those blocks.
And secondly, we are now returning the allocation for domain queries, we already do that for resources for IPv4 and IPv6, we are now also doing it for the domain type, either if we are authoritative, we return the information from the RIPE database or we will redirect domain queries to the authoritative RIR.
Undeliverable and unsubscribed email addresses, this is an ongoing topic. Considering how important it is that we, that our maintainers are contactable, that we can send notifications for clean‑ups and changes to their data and as of the middle of May, there are just over 8,000 undeliverable and 69 unsubscribed email addresses, the unsubscribed users themselves opted out of getting these notification emails, it affects a small number of the total notifications daily. But having our maintainers contactable is very important. So we do strive to reduce the size of those undeliverable addresses as much as we can. We periodically revalidate those email addresses, using a third party service, the same as we do for Abuse‑C addresses. Typically, when we do this manually, we run it across all of the 8,000 undeliverable addresses typically it only changes about 10% of them so typically we find if they become undeliverable, they generally stay undeliverable. We also have a schedule job to check in cases where there's an SMTP, we will re‑try and make it deliverable and see if it continues to fail.
So hopefully recovery is automated, so if there's a temporary issue, but unfortunately a lot of these errors are permanent so we don't mark them as deliverable again. We send warnings to the other recipients on notifications if any of the addresses are undeliverable but clearly it doesn't help if all of the recipients are undeliverable. Only if some of them are.
So a question to the community would be, it would be great to hear if there's any some other way we can reduce the amount of undeliverable addresses.
And should we investigate a better way of notifying users of events, that doesn't rely on an email?
Upcoming work. Just to let you know in the APNIC region, this Proposal 162 has been approved, it was approved last year. There is some impact on the RIPE NCC since we download the APNIC database dump daily, to mirror in the APNIC DNS source. We already filter our personal data in the APNIC dump, personal objects are not visible in our mirror. But there may be changes to other attributes we are not aware of yet so this is moving forward in the APNIC region, we are paying attention to it and once it's available, we will be assigning a new data sharing agreement with APNIC so we can continue to have access to this data and we can continue to have the mirror available.
My resources, we are making some improvements to the resources page, you can already find your resources there, but there's some improvements we can make. There's two areas we'd like to improvements. There's ongoing user research, we are getting feedback from users on how they are using the resources page, we'd like to implement some of those improvements to help with that.
Secondly we'd like to facilitate self service ark project, it's already done in other areas for contacts but we'll be starting to look at resources as well so we will want to make it easier for you to review and correct your resource information in the RIPE database.
We'd like to hear from you, please give your feedback during this RIPE meeting to the user testing team or please signed up to participate in user research.
Object history. This is something that we already make available on the command line. It's also available in RIPE state. But we'd like to integrate it into the database query page, the history of objects to see what has changed, it's important for our users to be able to see that. We'd also like to simplify access to this for our internal users, we have separate internal tools for allowing our users to query history of objects, but we'd like to integrate this into the query page as well so we don't have to write and maintain this feature twice.
And it's currently only available in port 43, so we'd like to make it a bit more visible.
And the various things in RDAP, we continue to improve our RDAP implementation, we participate in the standard setting and work with the other RIRs on making improvements to RDAP, one thing that came out transparency report for two years ago on the list, we looked at differences between who is and RDAP an what was holding back RDAP adoption in a region. The main thing that is missing from the spec right now are IRR object types and we'd like to fix that, we are working on a draft RFC and we'd appreciate your comments on that.
And there is various upcoming work. We are implementing RIR search, this allows you to use flags that are available in WHOIS and are already available across RIRs but to apply them to RDAP, and there's one section of this spec that we have to finish, which is called relation search, we plan to work on that in the next six months.
Secondly as I said, we need an extension for the company registration number, we had this issue last week with limiting large RDAP responses, we need to think about how we can better handle that. And finally there's been a lot of discussion this week already on the future of the e164 arpa zone, it's not supported in RDAP, but that's future work we can do to close that gap.
And some quick proposals just to point out in implementing NWI‑20, the contact numbers work item, we found that we need to support the fragment separator in URIs as part of the spec, but it clashes with the RPSL spec, it's a common reserve character in RPSL. For now we have made a work around. We made an exception for contact attributes, only contact attributes will treat the hash character as a fragment separator in a URI, not as a comment but we would like to do this in a more generic way to be able to properly support URIs in contact in other attributes that they could appear and yeah, we are open to suggestions how to handle this. Two ideas we have is to firstly require a space for a tab before comments, combine the two, if you have a space or a tab, it means it won't be part of a URI, it must be a comment separately, we could also look for a URI fragment identifier and tell OK, this hash character belongs to a URI, it should not be marked as a comment, there's a couple of ways to deal with it. But I'd appreciate your feedback on this.
I previously proposed some clean‑ups not NONAUTH database, there's objects in the RIPE non‑ought database were not authoritative, they were created over many years anonymously with a well known password. In 2018 we closed the database, we prevented new objects from being created but existing objects that already in the database can continue to be maintained and unfortunately we don't know for what purpose these objects are being used and the existing clean‑up mechanisms are only slowly reducing the size of this database, we are down to about 44,000 objects.
The automated clean‑ups are to clean up objects using un registered space and delete objects conflicting with an RPKI ROA with notifications. So last year I made some proposals to delete NONAUTH objects with a matching valid ROA, to delete objects with a matching RIR database, this would significantly reduce the size of the database, but it's uncertain what the operational impact is. We did reach out to the maintainers of these objects last year but very few of them responded. So I would welcome your feedback on this and whether there is merit and value in continuing with the proposed changes to help reduce the size of the NONAUTH database and that's it, my presentation is done, I welcome your economies questions and comments. Thank you.
PETER HESSLER: Please state your name and affiliation at the microphone and short be short and concise.
SPEAKER: My stated affiliation is Job Snijders on behalf of Job Snijders and I will try to be short. You go back one slide please. It is my professional opinion that we should definitely proceed with deleting matching valid ROAs and deleting matching objects in other RIRs databases. Both those approaches adhere to the principle of there is a higher source of truth, one that is either confronted for us cryptographic signatures or confirmed authenticity by placement in other more authoritative database, if we contrast this with a few years ago, like five six yearsing ago not all RIRs had a strict authorisation model who could create what route objects in what database. But nowadays all RIRs do perform strict authorisation checks on the creation of new route objects so by definition the route objects in the other RIR database have gone through more checks and balances than the ones in the RIPE NONAUTH database. My personal preference ‑‑ but it's not a hill I'm going to die on ‑‑ I would wait with not returning the objects by default until sometime has passed after we did the first two steps deleting segments of the NONAUTH database so I think deleting matching valid ROAs and matching and other RIR database is low hanging fruits and I would encourage the community to proceed in that direction. Thank you.
EDWARD SHRAYNE: Thanks for your feedback.
SPEAKER: Dino Strzyweski speaking for myself. I missed one important thing, we used to use the well known passwords for the for objects and this has been also replaced with the... private key. This has not been mentioned. Or I was sleeping.
EDWARD SHRAYNE: You are correct, thanks for pointing that out, we have replaced the well known passwords for limericks. ..to use both, there's an option to use X 519 or PGP key in the database, I will send an update to the mailing list to point out what they are and explain, I think we have it in the documentation as well.
SPEAKER: Yeah, I think so. The other thing is NWI‑21, two things were mentioned on the slides and I already exchanged a couple of emails with Marco and it's for more the others, the first one is the government organisations, and there was a statement that for these, the NA will be used as the registration number. I have done my homework and I went back to the discussion from the last year and I was unable to find any reason for this except that it was mentioned, I think, by Cynthia that some of the government organisations in certain countries do not have such a rescission number. So except for that cases or these cases, I see no reason to make government organisation any special, if they have rescission number, please publish it because it doesn't make any sense for not publishing it in my ‑‑ let me quote Job Snijders ‑‑ "Professional opinion".
The other thing is the confusion that was on the second slide, Denis mentioned confusion and I actually was confused by the other thing, as I said I already had a discussion about this with Marco, the number of places starting from the solution definition, the word co‑maintained is used and I was under the impression that co‑maintained means that the RIPE NCC is maintaining it or it's put next to mine. I was wrong apparently. It means that you also do that for the objects which you have data for and you take care of this data so maintaining, RIPE NCC's maintainer doesn't need to be, hence the confusion, my understanding of co‑maintained means maintainer, your definition means co‑maintained means you take care of the data. And that was not clear first of all from the solution definition than from the email, not even from the article on the RIPE Labs, I would encourage someone from the RIPE NCC to make it more clear what co‑maintained in that context means because, yeah. I think it's confusing.
And that's it, thank you very much.
ED SHRYANE: Thank you.
SPEAKER: Good morning, Ed, Stavros from... regarding the previous topic for the RIPE NONAUTH, I want to fully express my report on that, exactly, I want to express my support on this actions, they make total sense to me. And regarding your concern about the operational impact, I would be happy to give you the example of the AmSix route servers they do not ruse RIPE non‑database for filter creation, it's been man years we don't mirror RIPE NONAUTH, we don't use it at all and nobody complained, nobody is expressing any concern or feels like we need to do it. We don't do, everything is happy. Actually I would support the idea if you would like to shut it down, are you going to shut it down, I may be the first one to vote green on that, that's my preference.
EDWARD SHRAYNE: Just to be clear I am not suggesting we shut it down completely.
SPEAKER: Unfortunately. I hope you do next time.
SPEAKER: Leo Vegoda speaking for myself. I am happy with the progress you are making on internationalisation and I hope you continue to move forward on that in the future. Commenting on your question from Denis about the reg number name, I don't think that's the core problem with this, I think the fundamental problem is that if you are not someone who attends this working group, you probably don't really understand what is ‑‑ what in any of this, and so what will be really helpful for naive users who could be law enforcement, they could be working in intellectual property rights or they could be, you know, just someone at home who is looking stuff up, is to annotate what is presented to the user and say things like this is data that the RIPE NCC maintains and we have a contract and we check it on this period and so on. This is data that is maintained by this user and this is when it was last updated. And they can go and click on an attribute in an object and they can go and see this is what it means. This is when it was updated. This is who updated it. And they don't need to guess. And I think this would be super helpful, I know that's probably a huge amount of work but it would be a lovely improvement to the user experience.
EDWARD SHRAYNE: Thank you Leo. In fact, we already support the help text on attributes in the query response. But it's short text and we can improve it further I think. We rely on the verbose text from the who is.
LEO VEGODA: It would be great if you could make that much more visible because at the moment it's not as brilliant for a new user.
EDWARD SHRAYNE: Thank you, maybe it's not hard to see ‑‑ it's hard to see it at the beginning, you have to hover over the attribute name to be able to tell, it will pop up some text to show you.
LEO VEGODA: If you could dynamically go and say, this is when it was changed. This is when we did this contrast verification, that kind of thing, you have got a whole registry of data, and if you could go and bring some of that richer data elements into the user experience, then you will be making it so much easier for a lot of people doing who's queries.
EDWARD SHRAYNE: Thank you.
SPEAKER: Good morning, thank you. ... speaking in my personal capacity. First of all, thank you for sharing the update and I have two questions. The first question is regarding to abuse contact. And in APNIC region we also have something similar policy, we have abuse of contact and we all need a validation every six months to make sure everything will be valid in every six months. But that general feedback from the community is this policy seems not very effective to comply with our general proposed intend to do, so I'd like to get some feedback from RIPE and also yours experience regarding to that abuse contact, second question regarding to geofeeding information in the who's or other data field because some of our members request in supporting for geofeed information, right now geofeed already accrue in the who's and RDAP, but we don't have any support to encourage members to... I would also like your opinion regarding this issue. Thank you.
EDWARD SHRAYNE: Thank you. I think who the NCC side, the Abuse‑C validation process has been very successful, we see year on year the number of tickets open is reducing, the number of issues we see and the data quality seems to be going up. Which is very positive. And secondly, for geofeed, I see in the database, there's at least 50,000 objects in there, it seems to be very popular also and widely adopted. So yeah, I think it's working very well. At least for our region. Thank you.
SASHA ROMIJN: IIRD maintainer, one slide back, the hash marks comments, your fragments, it may be my bias but I feel people already add white space around hash marks and maybe that is, it's not what 262 says, I think we could collect some data on where do people use hash marks and where not and see what the actual practice is and whether we should change this.
EDWARD SHRAYNE: Thank you, Sasha, it's really difficult to find, there's no right answer because there's no way of escaping the hash character either in RPsell or the URI. But I looked in the database generally comments are preceded with a space or tab already in the vast majority of cases. So I think it's fairly safe thing to suggest to do.
SASHA ROMIJN: I think we could look at some of the other IRRs, at least the data that isn't filtered out for privacy, and see whether that applies over the entire IRR system, I expect it does, there has been white space so we can look at some more data and find a way.
EDWARD SHRAYNE: Absolutely, not this a new issue. It's already been an issue in the free text attributes, it's more an issue of contacts. Thank you.
PETER HESSLER: Not speaking as a working group chair, on my own personal capacity. Three comments:
One, there are other languages that allow the hash mark as a comment and generally the behaviour you will see there is the hash mark, if it's part of a word, it's considered part of that word and if there's white space before it, it's considered a comment. That's reasonable popular.
Secondly, on your question about the historical data, some of my colleagues at work have found it difficult to use the existing mechanisms to look at historical data in the database; it would be lovely to see an easy access to this on the web.
And thirdly, to actually answer the question about geofeeds as a network operator, we find this incredibly useful, incredibly helpful to publish this within the RIPE database. The geofeed question has always been quite difficult to deal with and a lot of the geofeed vendors, for lack of a better word, have been difficult to impossible to get a hold of to correct your data and utilising the geofeed attribute is only of the only mechanisms we have found that actually works. I strongly encourage you to use it in your region and for everyone else, it solves a lot of the problems that you have been experiencing.
EDWARD SHRAYNE: Thank you.
DAVID TATLISU: The mic doesn't work.
EDWARD SHRAYNE: I will see myself out then!
(APPLAUSE.)
Were there any further questions online?
DAVID TATLISU: No questions online, thank you. You and your team are making the world turn. Next up is Sasha with reliable IRR mirroring using NRTMv4.
Thank you, Peter, I was about to set up everything.
SASHA ROMIJN: There we go. My name is Sasha. I have been waiting a while to do this talk because open and database keep being shared at the same time so it was never possible.
Who here runs IIRD? Anyone who is part of that 900, wow, quite a few people, it's nice, you are part of the 900 people maybe that query NRTMv4. I only run like five instances myself so it was not me.
So my name is Sasha Romijn, independent developer no routing standard infrastructure and I have been the original developer and maintainer of IIRD version 4. And I am also one of the authors of NRTMv4, which is the new ire mirroring protocol. First what is the purpose here of ire mirroring, people do it to aggregate multipling IIRs in a single source, you can query all of them through a single query, low latency copies of ire data and also people do a lot of custom analysis and research project, if you run IIRD and imimportant the data, you get a nice database that's done the parsing and indexing for you and people use it for research as well. So NRTMv3, how it works, you download a file classically from FTP, nowadays we do HTTPS, it has a number just a plain text number and then you download the dump file which is usually G ISPed, you anything another some of the entries that were weirdly formatted because they were deleted while the dump was made, something like that. Then you take your current serial file and that's the serial which you think you have downloaded the dump, then you connect over an entirely different method to port 43 or something or who is like protocol with who's like queries and say I want to hear from this serial to the most recent and that's how you get the last changes that the dumps were made once a day or sometimes a bit more often.
And it's a plain text format that shows you all the changes.
And that's what we have been using for IRR mirroring for quite a long time. How do you know in IRR mirroring if are up to date? You do not. There are some hints you could use but it is very difficult to actually determine if NRTMv3 is working, especially when the database is a little more quiet, if you ask a based server for cereals that it doesn't have yet, the typical thing you would do, I am up to serial 10, I am going to ask for serial 11 and whatever they have after. If you do that on the RIPE database, it will say oh I don't have that, I have this range to this range, if you do it an AfriNIC, it depends if you ask for a serial that's too early in what it knows, it will have a separate error which current RIPE database does not, if you ask IIRD based servers, on RD version 4, we have a small variation, we have a slightly different warning if you are asking for one version to new. Hello? I think my microphone cut out. I don't have the voice range for the entire room but I can try. So it's back, thank you.
So if you were asking what, it gives you a warning, if you are multiple to new, it gives you an error and there's double hash marks, this isn't well defined, I think the double hash mark type for fee. If you ask NRTMv3, there's no real proper consistency here, you cannot say everything is fine, we are up to date so NRTMv3 can cause interesting synchronisation issues because we don't have good signalling to say what is the state, are you up to date, it's a little bit better with IIRD V4 and what serial 12 means is contextual to a particular server implementation, server instance, and if you are on the wrong server instance, then serial 1 might be something different but might also exist and you end up with a completely random copy of the IRR, although they mostly work, people have for example done that, made their dumps from one instance of IIRD and served NRT from a different instance and there's no way to correlate the two.
Security in NRTMv3 does not exist, we use HTTPS transport so that's something, it's better that we use FTP, the actual updates on NRTMv3, if someone answers on a TCP circuit, I guess authentic IIRD mirror it, there's no authentication and no integrity checking, just plain TCP server.
So NRTMv4, this work started in 2022. With the first draft and the goal with this was integrity and thinksity verification, has to be published by the authentic IRR as the data arrived without being changed, you have to be able to know that you are up to date, everything is fine. The repository still running, we will receive updates if there are any and as automatic recovery in some synchronisation is lost, a proper specification, NRT V3 is a page on RIPE's website, I never find any standard, also earlier versions I couldn't find good standards.
And also it had to be scalable, people have been restrictive with NRT 3 access, you have a live server that answers these dynamic queries. So NRTMv4 we took a lot of inspiration from RDPP and it's a repository files on HTTPS three times miles, update notification files and index. Snapshots which are complete dumps, they are quite large and then very small data files generated up to every minute.
So in IIRD version 4, the mirror server that has the IRR database, it will periodic ally produce snapshots, it will regularly produce Delta files, if there are any changes and the update notification files or the index, the manifest that tells you which delta files and which snapshot files are available and if there's new data, you only need to fetch the update notification... as a client you start with a snapshot, it has the data and you read it in and from there you can follow Delta files to keep up with changes. Notification file, a lot of it is JSON based, it lists a session ID which is dimensionalist but if it changes you need to assume all your local data is no longer up to date, it lists which dealts with available and which snapshots are available, deltas are kept for 24 hours. If you are more than that 24 hours behind, then you have to start from a snapshot, the snapshot have a small header and and they list the objects, the index, this is on purpose, we don't take a part of the object attributes, this is almost JSON text see sequences, you don't have to log the whole file at once.
Delta files, can do two things, they can add or modify. We don't distinguish or delete things, it modifies the same as in a snapshot. Deletions are identified by primary key which we have defined a little, mostly defined already, how do you know the primary key. And so delta files can contain all of the changes for a one minute timeframe. Sometimes a little longer, you are allowed to catch up with them.
And every time someone makes a new delta, they make a new version and every once in a while they publish new snapshot that version, one of the ideas is clients can can recover, they might do that by reinitialising from snapshot, they are no longer sure if they are up to date, maybe they have been offline for 24 hours, maybe the server changed the session ID which is a way of saying we no longer have a consistent change log. Of course it can also, we can do this for a re‑try for transient failures and there'sHsignature check as well, I saw this working head by accident when it turns out I deleted some files from one of my NRT 4 testing publication points, which the server picked up and realised it's not supposed to happen, we lost delta files, and then all the clients picked up it as well. There's a lot of scenarios in which NRTMv4 clients will recover, and if they can't, at least they know what happened, they can tell you this update notification files, this doesn't have a valid signature and that will allow you to debug because with NRTMv3, I get a lot of emails from people saying it doesn't work somehow, we don't know what happened, that's because I'd doesn't know what's going on, this is help a lot with that.
For security, there's a bunch of layers, the update notification file is a JSON web signature exact serialisation document. That's a lot of works, it basically means the contents are signed by a public, with a private key, you get the public key and you can verify and this is all shipped at one packet, initially we had a signature file and update notification file, that requires making sure they are updated at precisely the same time and you have got weird synchronisation issues if I pulled precisely and RIPE published precisely at that point also.
And we want something that was a standard ‑‑ with standard implementations, library is already available in a ton of languages. So basically you get public key and with that you can verify the update notification file is authentic and from there the files hashes for all the remaining files so if you trust the update notification file, you can check the snapshot you down loded authentic as well, there's a key rotation process in here as well.
RPSL is sort of a patchwork over time of RFC and NWIs, we have seen a few come up just now in the presentation. So we were not planning to entirely define RPSL, which is why we use text blocks but we did define a few things to have common framework which is that it's always UTF 8, object classes, primary keys are also case insensitive. We also defined primary keys, many are clear, we know what the prime key key of an AS set is, for example a route, is it the prefix, the origin, which image order, do they contain any characters in between, that's a lot more defined to match the started we were already doing informally.
If you get objects and attributes you don't sustain, you got to try but you can discard them so that allows compatibility to remain if definitions of objects are slightly different, but mostly we left it opaque to intentionally leave this problem out of scope and not grow in standard infinitely.
We now have five interoperable implementations, of course RIPE NCC is running this in production, IIRD supports this as client and server and there are a number of other client implementations and they all work, we have an extensive implementation report, it went through ISG and it's in the RFC editor queue.
The NWI‑12 was mentioned earlier. In my opinion, it's not unreasonable to close it, but what I would ask the NCC so do is that during ISG review, we made a number of changes, there were some clarifications, none of those are incompatible, but I think it would be worthwhile to go through the latest draft again and make sure that the implementation aligns; it's things like error recovery, what should a client do, what should a server do, if this is inconsistent with this, nothing major but still significant changes.
How do you use NRTMv4 if you are not running IIRD? On the server side it's just two settings for clients and servers, you define register files and give it a private key, we have helper commands to help you do that. You serve those files over HPS, you give your client the URL and public key, they are good to go, there's much less moving parts than NRTMv3, on the client side you give it a path to the update notification file and the initial public key.
The purpose there being that there may be key orientatins, or you need a public key to start and from there it will pick up key rotation in band itself. This is all you need to do for to, say, mirror. For RIPE NCC this is already documented. For other implementations, for other deployment, I think they are still ongoing to at NRTMv4 as well.
My work on all of this over the last four years was funded by the RIPE NCC community project fund which is now no longer and LACNIC, important to mention because this is not a paid job for me, I need to find funding sources like this, if you want to this kind of work to happen, we need to have funding project like that.
My co‑authors were Job Snijders, Edward Shrayne and Stavros Konstantaras and particularly thanks to Job for guiding me through the whole IETF process, I had never done this before, this is the first draft I worked on and also many thanks to 25 reviewers we had and all the other implementers that should us this could actually be done. Also working on this in together with the RIPE NCC and building our implementations together but separately from each other was incredibly valuable and found a lot of pretty bad flaws in the early versions of the draft which I thought I had written one thing and wrote IIRD to do that things and then complain to the RIPE NCC they were wrong and no it's actually me who wrote out something very different to what I thought I wrote, it's very useful and solid so and my particular thanks to the very last reviewer in IESG review who pointed out we had a route object, not a route six listed with an IPv6 address, which would be embarrassing if our examples were RPSL invalid.
This is ready for use, to mirror RIPE NCC if you run a recent enough IIRD documentation is online, draft should be published sometime, yeah, however long the RFC takes. Thank you so much.
(APPLAUSE.)
PETER HESSLER: All right, thank you very much, if anyone has any questions or comments, of course please come to the microphones and state your name and affiliation. If you have comments online, please use Meetecho. We have the text Q&A and we can patch you in with audio or video if you prefer.
OK, that was probably the most comprehensive update we have got about IIRD and clearly everybody understood you correctly, so one more thing. If you would like. Please go ahead.
SASHA ROMIJN: Yes, I have one more presentation now that we have time.
So more draft coming, now that I have done one, I am like, this is actually quite fun, I want to do more.
This is early work that I have been doing with James Bensley, we have been ‑‑ you may have seen some of it on the mailing list already. Which is improving member resolution in RPSL. Because a big thing that IRRs are use are expanding AS sets, if you have an AS set, it contains other AS sets and you want to figure out who do the full expansion all the way through. But sometimes it's a little ambiguous, you might have an AS set that includes a member called AS included, that and then there are two with that name and they include different things.
So who is actually in here, should it be both, should it be one, which one did AS route actually intend? This is a simple example but this can go quite deep, depending where they are in the chain of AS sets, this can cause very significant changes. When I was developing RD version had comparing it to V3, this was one of the sources we had sometimes oh using this AS set is a thousand prefix and it thinks it's two because someone in the middle was in this situation. It's not super common, but enough to be an issue. I had yesterday 70,000 different AS sets in my local IIRD, 68,000 unique keys which means 2,000 are doubled at least once.
It's a little biassed towards some people. AS‑S despite the name, not mine. So this is the number that I found in the most common AS set names. A bunch of these are very clearly intentional. Basically they are squatting on the name in multiple IR database and multiple RIRs to prevent someone from doing it intentional or by accident. But I saw even among the ones that were put in here or purpose, some of them had become slightly inconsistent; so they have five copies and one of them is actually a little different so even if they try to do this themselves, sometimes they introduce new inconsistencies, so that's not great.
The solution we propose is registry scoped members for RPSL set objects which is a draft that's been adopted by the IETF global routing operations working group. Because the first idea might be we can use double colon RFC 2725 mentions it and it's sort of of the convention we have already, 10% already do this, RIPE::AS included, it fits neatly with the single colon we used to scope into an AS.
But of course if we change ASes this week, that's going to break every old client because they are going to think RIPE::AS included is the full name, look up that and they will fail. So this is cool but it breaks all existing implementations.
We could put it in a new attribute and make a new one that is scopes to a specific source but that of course breaks them in a new way, because now other clients and servers will not see any members.
So instead of what the draft does, it does both. We keep members as it is currently because we need it for backwards compatibility, add a new one that's scoped by source. That sounds like a lot of work to maintain. But that is accounted for as well, there's a number of things how IRR servers and clients should handle it, it must include anything that says source members as well, but then without the scope. So we keep them as close as possible, the IRR server must enforce this, clients must also read members as fall back, the purpose here being you might not know the IRR source for everybody, so we want you to be able to add scope to some of them without having to do a full switch over. And also servers are recommended to try to generate one from the other, if you know the IRR registry for all of your members, the IRR server can fill in the rest and we can derive and the point here is old clients keep bringing members as and we guarantee it as close as possible, it has issues and also existing issues and we are not making it worse and if you have old object that hasn't been updated, that keeps working and you can do gradual upgrades, as soon as anyone is interested in any objects and you say update it IRR service for resolution, you will benefit from reducing this, this reduced ambiguity right away.
Second draft, slightly smaller one, is explicitly excluding objects from RPSL sets, this would move it into the owner of the AS set, which is usually the person who is most aware of this and interesting this one cascades down, the previous one doesn't, you include one AS set and say it's in RIPE, we look at that one from RIPE and from there we resume as normal, maybe with scope, maybe out, this one cascades down, you can basically manipulate how should this AS set be resolved all the way down and remove members.
What is next with this? One of these adopted ‑ I want to do a bunch of updates based on various feedback received since in both drafts and then try to get implementation going in IIRD. Why I am bringing it r here is because, of course, it would most benefit if the RIPE database would adopt it as well. Do you think this is good? These are early drafts, of course. There will be more discussion on their particulars. Do you think the RIPE NCC should work with us to also look to towards adoption? And I would just welcome your comments on the drafts here or at the IETF.
Thank you.
(APPLAUSE.)
SPEAKER: Hello Sasha... yes, yes, yes, yes to all of these questions. I think this work is fantastic. We are missing those features for a long time of discussing those things with other members in the RIPE community, we are missing this functionality, I am happy to see drafts on these ideas. I would like to encourage RIPE NCC colleagues to work with this and also consider adoption as soon as possible with this draft. Happy to support that, I like it. Keep up.
SASHA ROMIJN: Thank you.
DAVID TATLISU: It looks like we don't have any comments or questions online, so, Peter?
PETER HESSLER: Ah so it appears there are no more comments, so Sasha, thank you very much.
(APPLAUSE.)
And now we come to the AOB session. Is there any other business that somebody would like to bring to the attention of the working group? If so, please come to the mic.
And as per usual, name, affiliation, etc etc.
SPEAKER: Hello again, just one correction. You mentioned a Neil ‑‑ you mentioned ‑‑ it was with Nigel's help, Nigel is with us, it was with Nigel's help that we have right now minutes from RIPE 70 and 72 and yes you are correct, we are still missing 73, but I will dig for that. Let's see what will happen.
PETER HESSLER: OK, apologise for missing the name, I just wrote it down wrong in my notes. But thank you for the correction. Yeah.
SPEAKER: No worries, thank you for the correction.
PETER HESSLER: OK. And then just before we close, there's a few announcements they would like us to make. The RIPE Programme Committee election voting will close at 17:00 local time today. Please remember to vote, all you need is your RIPE NCC access log in.
And RIPE NCC members who have registered for the General Meeting can vote until 9am local time tomorrow morning, you have all day today and, of course, we encourage you to use your rights and responsibilities as members to vote.
And with that, I would like to close the database working group session for RIPE 92. Thank you very much and we'll see you next time.
(APPLAUSE.)
Coffee break