RIPE 93. Side room. Thursday, 29th October 2026. 9am
PETER HESSLER: Hi everybody, if you want to be in the database you are in the correct room. If you want IPv6, that's the main room over that way.
Hello everyone. Welcome to the RIPE 93 session for the database working group. My name is Peter and together with my colleague David, we will be chairing the session.
First I want to thank Hans for being the scribe and Tina for being the stenographer ‑‑ you see we have an action‑packed list of presentations and discussions for the session.
First we have posted on to the mailing list the minutes for the previous working group session at RIPE 92, there have been no comments and it appears that everything was good. I am going to give the audience a last chance to raise any connections or concerns? And I see nobody. So I declare the minutes as accepted, thank you very much.
And with that I would like to ask Ed to come and up and give us the always delightful NCC operational update.
EDWARD SHRAYNE: All right. Good morning and thank you, Peter. Here's the operational update from the RIPE database team at the NCC.
Meet our team, so I am presenting on behalf of the database team. We have a new face, this time Sofronie is our intern working with us until next February, they have been doing great fork on the version history page on the website so we are very happy to have them them as part of the team.
What I have been working since the last RIPE meeting, in addition to the operational work and support work, there's three main project we have implemented, that's my resource usability and OIDC authentication and version history on the database website.
Firstly we have had three Whois releases since May, lots of small changes you can see in the Github repository, but in particular version 1.123 in June, we made improvements to the handling of UTF A characters, we handle it properly with the version query and we support the character set flag watt version history properly because you are going to have objects in your history that contain UTF8, you might want to confer to that, the character set flag works with that.
Thanks to Ondrej, my colleague who found we are not handling decomposed uni code properly, you may have multiple code points for the same character, now we have implemented an FC normalisation form which is part of the spec, we didn't have that in there initially but it doesn't do any character substitution, it won't change the meaning of your data in those attribute but lied into a common form. In August we will we released 1.123, added support or OID in the background and Sasha reminds us about bug reporting and presentation, we implemented a policy which would help mitigate across scripting attacks and script transport security headers to force browsers to use HTTPS and also we added next plain and informative responses to the versions API, this capability is also in the rest of the interface but it's important to add to it to versions also, in particular AS‑Sets; you may have unformatted attributes that lined up with with each other and it's important for readability to see inport export lines are lined up with description attributes, they are more human readable
The last release in August, we had a bug report we were not handling the Signing certificate properly in client certificate authentication and as part of the TLS negotiation you can accept, you can see more than one certificate and they may not have any relation to each other, you can add multiple certificates into your request.
But it's only the first certificate that is the signing certificate so we fixed that bug in August. Unfortunately we had three Whois outages, mail updates in July, we had an issue with the mail server, temporary mail was not delivered, we don't believe anything was lost, secondly in August we had I think a pretty major failure with NRTM mirroring, a combination of factors but the root cause we accepted a syntaxi ally invalid RPSL object, we were decoding escaped characters where we would add an extra new lines into the object and that's syntaxically invalued in RPSL, we fixed about not unescaping character and we leave them as is and check the actual content of the response and go back over the last thousand objects in the stream and make sure that they can be read properly and we have a correct footer so we get a consistent end response from NRTM.
And finally we had an issue with the web application following the OIDC deployment, the back‑end ran out of sockets, the web application back‑end we were not fully closing connections; thankfully the fix was already done we just needed to deploy it and the work around was restart the application but there was a few minutes were users were affected and thankfully other DB applications running alongside were not affected because the web applications containerised, the blast radius was contained in that container. And apologies to users affected by these outages.
A bunch of database statistics, since RIPE 92, we have consistently had about 8,000 undeliverable mail addresses, we periodically revalidate to those to make sure any deliverable again we can mark them so and undeliverable mail addresses effect about 1%, a small amount of update notifications daily but it is super important that this mechanism works because this is the mechanism that we let our users know that something has changed in the database, so it's something we are keeping an eye on.
Abuse‑C address validation, something we need to do yearly and thanks to the good work of the member services team, they moved a lot of this validation forward, we only have 1% of Abuse‑C addresses remaining to be validated for this year. That's really good.
And it means that there's not as much work left towards the end of the year, it's nice to get this done already.
We see again that about 20% of all ‑‑ queries are using RDAP which is really nice, RDAP is a modern replacement alternative to using Whois, a standard based and across RIR support for it and it looks that there is a consistent level now of support and use out of it.
And finally update authentication and thankfully adoption of API keys has continued to increase, now almost two third of all updates are authenticated with API keys or interactive users using SSO.
And there's other statistics, I won't go through them all, but the nice to see that a number of work items and policy implementations have continued to see adoption.
So our first major thing, the project we have been working on, authentication coming out of work by Sasha Romijn who sent us a bug report and also the presentation at the last RIPE meeting. We have been using star.RIPE.net cookie for authentication or a long time but it's vulnerable to cross‑site attacks. It's a vulnerability we needed to fix, thankfully now the database is using OIDC authentication to replace this cookie, it's only for the database web application and not for the entire domain.
We aim for the site to work as before with no visible changes to the user, so we rolled it out in mid September. So things like displaying a banner on session expiry, it's important if the user is logged out, they see they are logged out, we have back channel log out, if you log out from one tab, all tabs will be updated properly, we want to make sure it works, that users can switch between applications because the navigation at the top of the page it's easy to switch between NCC applications. We want to make sure that log‑in status is handled properly. And finally application deployments must not interrupt users sessions. We do session handling in the backend as well, we want to make sure when we do deployment, it should be a routine operation we don't interrupt our users. And yeah we made backend changes in Whois to support the session scope and there's upcoming changes to supporting other NCC applications like the RIPE portal who will be moving to OIDC also.
Second major project is to improve the my resources page, if you notice on the navigation when you use the website, it sits between the portal and the RIPE database. It's maintained by the database team, two major changes is to adopt some author usability feedback that we got from previous rounds of user testing that Antonella and Patris have been working and secondly adding automate checks to resources, it's clear where there's an issue to be investigated, this functionality would also be adopted in the self service ark that we come into the LIR portal.
And I'd like to ask you to sign up this week for to accept out with user testing that is being done, there's a QR code on screen, you can download the slides and click on the sign uplink.
So I just to point out I am not brave enough to do a live demo, you have to make do with some screen shots. But just to point out the major changes. If you see on the left‑hand side of the page, you now will see a tree view of all of your resources, this is how your resources look into the RIPE database.
And you will be able to more easily see the relationship between resources, you will be able to navigate more easily using the tree and right‑hand side you see resource details for anything you have clicked on the left‑hand side, we have tidied that up a lot and added some labels and we have also added ASN announcements, BGP information is in there.
And to show we are using it ourselves as well, this is the view the NCC will see for our ops network, and you will see that in orange, there's a couple of things that need attention, for example resource check doesn't mean that something is wrong, it just means that you need to take a look. For example, here we have an AS number we used in the past for disaster recovery, we are not currently using it. We are going to review it as part of the infrastructure project next year. But this is an example of how useful the resource checks are that highlights things that you need to pay attention to and may come up during an ark.
Another project we have been working on, we were asked to implement version history on the query page, it's directly available on the ‑‑ website. Including list versions, show version and DIFF version. Up to now you had to use the command line, our friends in the RIPE Stat team have a database widget which uses our version history API, but now it makes it easier for you to find version history directly on the database page.
And there's still a link to RIPE Stat if you need to see more details.
So this would appear in query responses if you look for something on the database query page, we have only initially added support for just a small number of object types shall it's easy to add more later, that button will appear in more of the response now.
And I think it will also a goal for ourselves was to simplify queries for internal users so our internal staff currently use a command line equivalent to look for version history, it's something we don't want to write this feature twice and we want to make it easy for our internal staff to look up database information, we making it easy for them.
So as you will see if you click on the button, you will see object history now with a label for the latest version of an object, you will see that bedefault when you go to the page, you can select from the drop down different olders versions and there's a comparison between two versions of same object. And we have managed to reuse the DIFFing code that we had for the modified page so it's very clear to see additions an deletions for between different versions.
ISO 20001, we are busy with compliance and working to achieve the ISO 27001 compliance along with the rest of software engineering, we have some controls we are complying with. We have worked on business continuity management, updated our risk register, which is something the board is paying attention to and is reviewing. So we are ready for the board review in November. And test reports, this compliance comes with a lot of documentation, we have created test reports for restoring from database back up and database switch over to make sure those operations are working, something we do regularly. But now we have also documented it, so it can be audited. We have an external audit coming up next month.
OK a few proposals. We want to, we noticed there's a gap ‑‑ Leo in 2024, asked us to examine the gaps between RDAP and Whois, we produced a transparent report but the major missing piece functional is support for RIR object types and we are working with the community to produce a draft text for a standard here to create an RDAP extension to add to those object types to the standard and we are planning to submit to the IETF I think today we'll be sending an email, we'd like to hear your feedback on that and there's a link to the draft text in the slides.
Something the registry team was looking at, reviewing their internal processes, currently we have the phone attribute is mandatory in all LIR organisations. But for end user organisations it's optional, so this is a part of an internal procedure that the registry team have been doing but we propose now to make this phone optional, we'll' Lao the member to choose themselves how they want to be contacted and that they do no longer will need to publish their phone if they prefer a different contact type. So the NCC we still need a contact phone number, the member still needs to be contactable but we can make an option to publish it.
What we'd also like to do is make a new contact read and ask the user to optionally add a WhatsApp, telegram, signal, whatever you were contact and new if you don't want the phone number published, maybe you are a sole trader and you don't want the number on the database or you are a large organisation and the single phone number of contact doesn't make sense for you, you can decide not to publish it.
To be clear, that's a proposal so I'd love to hear your feedback on that. Secondly the NONAUTH clean up, something going on on the list, also mentioned at the last meeting, we proposed two cleans up and wrote a problem statement, again we'd like to hear your feedback, feedback so far has been really positive, I would like to follow up with a solution definition following the RIPE meeting and I will get your feedback and proceed to an implementation, it's a major change to the NONAUTH database, it will, the combination of these clean‑ups will reduce the size of the database by about 60%. But we have previously contacted all the affected maintainers last year and as part of the solution definition, we plan to do this again, there will another round of notifications and updates to the mailing list so informed.
Upcoming work, we had a release in the pipeline, we ran out of time before the meeting, we planned to release this right after the meeting, the major change to add bulk support in the dump files, you will see a registration number in bulk for all organisations. Secondly we are going to add further support for OIDC to allow other NCC applications to authenticate as themselves from those applications, so they can make changes from the other applications directly and we made some under‑the‑covers changes to full text search, particularly with matching an auth number on AS‑Sets, we are parsing and matching better on those strings.
Planned work on RDAP, that was mentioned at the last meeting, we wanted to creation an extension in RDAP for the registration number, we want to complete the RIR search and search and limit large responses, we had some operational issues where the relation search in RIR search is returns a lot of information and we had a hard limit on that at the moment, to mitigate that but there's I am sure there are smarter ways of doing that, we'll be looking into limiting that in a better way.
And finally there's been some progress on supporting e164.ARRPA, there's been discussion between the ITU. The NCC is the e154.arpa zone operator. Vand also secondly we also want to encourage use of RDAP so combining that it makes sense to support e164.arpa, on the other hand it's hard to query for in Whois, I would like to the ask to the community should we proceed with the implementation, it feels like we are ready to do that but I'd like to hear your feedback. I think it's something we will also email the mailing list to get a wider opinion.
But we are ready to proceed with implementation if the community are happy to do that.
Cleaning up references to this contact object, so there are some objects that are special in the database that are contacts that we are using, NCC are using but until M N T ref was added, anyone was free to make a reference to them. It's something Xavier in the registration team have been looking into. So we propose to clean up references. This is an example of a contact that should not be used by end users but it's listed in 166 jobjects, we want to add it to all NCC contacts. This contact is only meant to be used in place holder objects so we are going to email the working group and contact affected users, asking them to replace the reference themselves, otherwise we will replace it with contacts from the object maintainers and adding M N will mean future references won't work unless you are an NCC maintainer.
Whois privacy, something to be aware from the APNIC region, there's a policy now to limit the personal data in bulk dumps, it's something we make use of, we host a mirror of APNIC data along with other regions and we will be signing a new acceptable use agreement, so if you query for, if you make use of this mirror, be aware there will be upcoming changes, we are not quite sure what exactly will be changing so far but we'll keep the working group informed.
Draft activity plan and budget, this has been published, talked about yesterday at the Services Working Group session and at the general meeting, please have a read through it, there's a session in there for the database, just a couple of points. The budget is unchanged for this year for the team and ongoing work is mentioned there, including improving authentication, improving resiliency, deployment of management, a lot of this work could be done as part of the infrastructure improvements next year. And you business as usual, we'll continue working with the IETF and other RIRs and continue work on ISO27001 and planned work, cleaning up the NONAUTH database and technical infrastructure work that was mentioned yesterday at the Services Working Group.
At the end and I have one minute. Any questions or comments? Thank you.
(APPLAUSE.)
AUDIENCE SPEAKER: Thank you very much, I am very pleased to see there's finally a draft out for RDAP objects for RIR data. If you submit it please ask for... as fast as possible. As an operator, this is the final thing that I am waiting for in order to finally get a to put Whois to rest, so to the operators, please review this draft and see if all the objects you are using in your daily operations are now included in other queries so we can finally put Whois to an end.
EDWARD SHRAYNE: Thank you.
AUDIENCE SPEAKER: Stavros... thanks Ed, great job, I am in full support of the clean up of RIPE NONAUTH, I think I said that in the mailing list, I will recommend please go ahead, you mentioned the amount of objects you cleaned up based on RPKI invalid and also based on real data that are duplicated actually. So there's the second one, does it also include more specifics or is it exact amounts? Is it a /23 NONAUTH and maintainer or the operator created, two /24s in ARIN?
EDWARD SHRAYNE: It's just exact match, I tried to be conservative and just where there's a precise match in other RIR because I am not sure more specifics it may be a different scenario that we ‑‑ it might be not a good idea to disturb if there's a different set up in other database. So only where there's an exact match and it should be the same data in theory.
AUDIENCE SPEAKER: Same pre‑prefix, same origin.
EDWARD SHRAYNE: Exactly. We ran through the exercise last year and notified everybody, we notified using these two criteria and we did get some responses so these will form the base of the of the implementation going ahead, we are proposing the implementation of what we discussed last year.
AUDIENCE SPEAKER: OK, I would be interested to see that exercise as well; you don't need to do, you can stick to the plan, but I would like if possible to have some numbers to get an idea.
EDWARD SHRAYNE: Sure that makes sense, we run that...
AUDIENCE SPEAKER: Just to see how things...
EDWARD SHRAYNE: Those numbers are from last year, I will update them.
AUDIENCE SPEAKER: Continue with the plan, let's do that.
EDWARD SHRAYNE: Thank you Stavros.
DAVID TATLISU: I don't see anybody rushing to the microphone and nothing online. So thanks, Ed.
(APPLAUSE.)
Next up is Kaveh Ranjbar talking about optional RDAP references for more specific objects.
KAVEH RANJBAR: I will be quick because this is basically an ask to the room and I the idea is basically on optional RDAP. Just a quick background, fifteen years, I was at NCC, most of that time the database. I'm running exactly the gap that I'm going to show you.
(Sound is very bad)
So the RDAP basically works from IANA and stops at allocation, you look at any name, there is the bootstrapping but it gets to RIR and it stops, basically at RIPE you get to the prefix, the most specific prefix the idea is basically should be you covering objects and send the data for more specifics to the actual operator, we have already do that for DNS, I think this is even more lean case because DNS is a different scope, which back users in RDAP, here it's... for registration information and basically, the register, the RDAP base would be in the RDAP covering object, the clients will do the redirect if it chooses to and if the holder has that link so redirecting. And basically link would be for clients discovering the delegation, more in the delegation and validation is something that we need to discuss, basically checking if the links keep working, what happens if they go still, that's an open issue, I have some ideas how to manage it, RIPE NCC have a lot of experience with that, I think that's an open item for the list.
So standards exist, most of that... as you can see, the RFC 9910 for the RDAP is basically the way back, if you look up... like the two examples I have the first one, we run RDAP and if you look up one of our resources you actually get the RDAP which is basically RDAP related up so any clients talking... can go back the full layer allocation chain up to 0 /0, the chain back doesn't work right now, if you look up our address, it basically goes to a /32 and it stops.
So that's basically the thing I am trying to change. And yeah the question is there support in the room to ask the RIPE NCC for impact analysis and discuss it as a database working group item, I think that's it. I have a bunch of slides if you have particular questions, I think this is too much for that, I am more than happy to discuss all of these on the list. So the ask is back.
PETER HESSLER: Thank you very much,Kaveh. If anyone has any questions or comments they want to make, please come to the microphone, please state your name and affiliation.
LEO VEGODA: I am Leo Vegoda. I am broadly supportive of this, I think it could be a nice idea. The check that it still works is really important and also just from a security perspective, I would also like to have a check that everyone who asks the delegated RDAP server gets the same answers because there is the possibility that when the RIPE NCC queries it, they get the legitimate answer or whatever and then when someone else queries it, they get a misleading answer, and I want to have some sort of protection against that happening. But other than those two things, I think that's a nice little feature and it sort of already exists, it's just got to be turned on.
KAVEH RANJBAR: Yes, thank you very much, Leo, basically no RPZ rule for Whois, I fully agree and let's discuss those details. Thank you for your your support. Yes.
PETER HESSLER: OK. Any other comments? Do we see any online? No. So Kaveh, thank you very much, great to see you again.
KAVEH RANJBAR: Thank you.
(APPLAUSE.)
And next up is James Bensley talking to us about removing AS‑Set ambiguity.
JAMES BENSLEY: Thank you very much for your time and listening to me and having me, my name is James, I work for a company called inter.link and we have been on a bit of a mission to do something about the problems with AS‑Sets and ambiguity in AS‑Sets for the past few years because they affect us and affect many operators. I have been turning my hair grey prematurely trying to do something about this and we have made good progress, we have made a bunch of changes, not just us but other people in the room, us as an industry, we have made changes in different places in a disconnected format. I want to bring them together and present them in one place so everybody knows these are the changes that are kind of affecting us all so we have got it all in one place, like a public service announcement of what's going on in different groups.
The decades old question is which AS‑Set are we talking about, AS Apple ‑‑ I looked them up, they exist in RIPE and they exist in RADB, the same AS‑Set name can be used in multiple database and if I try to resolve AS Apple in the RIPE database, the zero prefix is back, if I do it in the RADB, I get 244 back, this is a problem, I may generate a prefix peer which is empty, which is I just reject all the prefixes while looking at the wrong database and potentially accept a route link through them, because I accepted ‑‑ the whole thing is a bit of a disaster.
So the way we some years ago in fact right back to the first RPSL, we created the concept of hierarchical AS‑Set names so instead of having AS‑Set F AO OI put my AS number at the start, AS 65000, it means that AS‑F00 must to be the one for me, it's got my AS number and just to add an extra layer of implicit authentication there, IANA allocate AS 65,000 to RIPE and then only I inside RIPE ask create an AS‑Set that starts with AS 65,000, it's definitely mine, only I can create one that has my AS number at the beginning. If anyone doesn't have a hierarchical AS‑Set, I strongly suggest you create one, this takes two minutes in the RIPE portal, they have done a very good job of making this very easy. If you have AS‑F00 and you have some members under it, create your new hierarchical AS‑Set, just copy and paste your old members on to the new one and make your new one a member of the old one, now you tell everyone your new AS name, for anyone still using the old AS‑Set name, your new one is a member of the old one, you only update the old one and you are still getting all your updates because the new one... it takes two minutes, it costs nothing and it's like a little step forward in your own security. So you have got nothing to lose, it's super easy to do.
So none of what I just said was new, it's status quo, baseline stuff, the question is what's changed. The first thing is APNIC, LACNIC and RIPE, they already enforce that if you create an AS‑Set, it must have a hierarchical AS number, they already enforce this but ARIN and AfriNIC were not doing this, last year we submitted the request to ARIN to bring them in line with the others, they accepted the request and now it's on their backlog and this year we accepted the same, we put the same request to AfriNIC and they have put it on their backlog, soon all five Rs are only allow the creation of hierarchical AS‑Sets, if you have one, an existing AS‑Set with none hierarchical name, nothing changes, if you try to create a new one, it must be hierarchical and it takes literally minutes, costs you nothing, you get a bit of added security, just do it.
Something else that's changed is then in MANRS, there was a presentation from Ondrej earlier in the week he was talking about the updates for MANRS actions for network participants, when I wrote this side I wrote MANRS is considering to require network participants to have a hierarchical AS‑Set, that is now a must. At least the wording, this part changed, so when you have a create to AS‑Set being debated, we are still defining but it will have to be a hierarchical AS‑Set if you want to be MANRS compliant.
But we still haven't solved the question of which AS‑Set, we have got to the part of who is AS‑F00, belongs to AS 65,000, we got to this part, we know this AS‑F00 belongs to AS 65,000 but like I said earlier, if I look up AS Apple in RIPE or RADB, I get two different results, so just anecdotally, we personally mirror that's data sources, thes are, NIRs and RADB that doesn't exist anywhere else. We occasionally have a new examiner come and say my AS‑Set is RADB, move it into one of these and they never complain because they just recognise yes, I should really have my stuff in an authenticated database, we are talking about a copy and paste delegation, not a big deal.
These are the data sets we use but we are not alone in this move to reIRR data sources down, there was three great RIPE labs articles that came out, I strongly suggest you have a look at them. I just cherrypicked three bits that relate to the concept of data sources the first one explained that we do really need to include RADB, some people question why do we use it, there's a tremendous amount of important information that is only in RADB.
AUDIENCE SPEAKER: Plus a lot of garbage.
JAMES BENSLEY: Yes, I put a footnote on my previous slide, database in priority order, so IRR will search the database in your preferred preference, we look through the IRRs first and then the NIRs and then RADB last. So yeah, the RIPE lab articles kind of ‑‑ you can go and read them and see for yourself, there's been some really great work being done there about how the auth DBs are more up to date, the auth DBs have more... so anyone who is running cautious tried to use the auth sources plus RADB, anybody with data scored in a database move it in there, you will be doing your yourself a favour.
And so a PeeringDB is always possible instead of just putting your AS‑Set, use this double code on r notification and say, for example, there are multiple Googles, there's one in RADB and one in RIPE and somewhere else. The one in RADB is Google's AS‑Set, they prefix if in their PeeringDB record, this syntax of database double code on goes right back to the earliest ... some people aren't aware of it but it's valid syntax, it's always been there.
But I would suggest you go one better. Put put the correct database where your AS‑Set lives and have a hierarchical AS‑Set so we know where to get the data from and we know it's definitely your AS‑Set and not someone using the same name.
But again all of that that I just explained is the current status quo. So what's changed?
The wonderful people with the PeeringDB, we have been working with them and they have now implemented a new feature all AS‑Sets must require a data source at the start, in this screenshot I put in AS ‑‑ Inter.link and you can see the green button at the bottom, they found the AS‑Set in RIPE, they suggest did you mean this address. And they won't let me not have a data source. I have to now put a data source on my entry so there can be no ambiguity there and the second thing is MANRS. Again when I put MANRS is considering because I wrote the slides a couple of months, this is now a must in the upcoming managed changes. The AS‑Set you put in your Deering ‑‑ record must have a data source specified so changes affecting people, AS‑Set field in PeeringDB, managed accreditation if you are MANRS acredited but which AS‑Set are we talking about, we still haven't fixed the problem, I go to PeeringDB I can see the data source I need to look into and I can be sure this is your AS‑Set because it's got your AS number in the start. But there's another problem.
So these numbers are from a few months ago. But they are at the time I took these stats, there were about 37,000 networks in PeeringDB, about 20,000 of them have something in the AS‑Set field, so not empty, and of those that have something in the AS‑Set field, about 304 of them have more than one, 0.8% of all the networks in PeeringDB had more than one AS‑Set listed and this creates a problem, there's nowhere to flag which AS‑Set is the one we should be using, some people have an AS‑Set for customers and some for their peers and upstreams. If I want to use PeeringDB's API to set up peering sessions with you, how do I know which is the correct AS‑Set to use if you put multi tip in your PeeringDB record and there's no flag to say which is and only 0.8 networks have done this, virtually none so what's changed, PeeringDB are limiting your records, you can only have one AS‑Set in your PeeringDB record, you can only publish one AS‑Set, if you have more than one AS‑Set, we can't programme atically know what to do with that, we have to email you and say is with the right one and if we have to email you there is no point in having a... they are limiting to the exact one, the previous slide will have the data source, one AS‑Set with the data source, MANRS has updated their requirements so again the AS‑Set you put in your PeeringDB if you want to be MANRS compliant must be your customer code, not upstreams, it's customer code but we still haven't fixed the problem. I can see the database your AS‑Set is in, I know it's yours and I know it's your customer AS‑Set, it's not going be to the wrong prefix for us to pier, when I pull your AS‑Set, if I pull your AS‑Set which is RIPE AS 65,000 AS‑F00, there will be members in there, members you have got AS‑BAR and AS‑BAZ, where do I get those from? The problem starts again.
So myself and Sasha have been working on a draft to add a new field to the AS‑Set which allows you to define the registry source that those members live in. And it will be, it's an additional field, we are not modifying the existing members field, because any existing RIR implementations which are not updated wouldn't know how to how to process the new syntax, we add a new field and it takes priority over the old field, if you find AS‑BAR in the source members field and find it in the regular members field, source members take priority.
So we have backwards compatibility without breaking anything, people can slowly migrate to new source members and we kind of then finally we have the full end to end chain from discovering you on PeeringDB to resolving your AS‑Set to resolving your members and all the way along the ambiguity is gone. I want to say that the document we are working on is on Github, please have a read, the link is in the slides, please have a read, give us some feedback, comments, we submitted it to the Grow Working Group. So if you are on grow, please when we have a call for adoption and feedback, please give us feedback and support. So we got it, we kind of got to the whole thing, this is the AS‑Set we want and this is the contents that we want. This is the contents that we want, but not those ones. We have another problem. This is our AS‑Set, AS 5405... if you resolve our AS‑Set it expand to 76,000 ASN and 1.3 million prefixes because somewhere downstream our customers customers customers, they are imported Hurricane Electric and Google and all manner of things they are not an upstream for and we have been trying for years like other people in the room to stop this from happening, we contacted networks, please remove the stuff from your AS‑Set and they they just say who are you, they are not our customer, they are our customer's customer, go away, they don't care, we don't speak English, all manner of responses, yeah we'll get around to it, they don't. We tried to put pressure on your direct customers, we have told some of our customers we will shut you down if you don't fix this because our peers cannot generate prefix filters towards us and that affects our entire cone. So your impacts affect our entire cone, do something about it or we'll shut you down and they say go for it, we don't care, we have half a dozen other upstreams, do what you like and it turns into a conversation that you absolutely lose between engineering and commercial which is how do you feel about losing this revenue because they aren't cleaning up their AS‑Set, you aren't going to win that conversation so here we are.
We can't force them to do anything about it, we contact people and they don't care. So we have another draft that we are working on, similar to the source members draft, we are adding an exclude field as well. Basically if somebody is trying to resolve my AS‑Set and way down my AS‑Set is Hurricane Electric, I can add them in here as an exclude option I can say when you see Hurricane Electric, ignore it, they are nothing to do with us and I have made a mistake here, the exclude members also accepts the database source so database colon colon must have that syntax.
So again there's a link to the Github where the document lives, please give it a read and give us some feedback. This is also going through the Grow working group so please when you see it on the grow mailing list, give feedback and give support. Myself and Sasha are working on both documentses, Sasha is working on update RIR to implement this, we will deploy this RIR. If people are interested in another way to help is update your RIRD, how is it working out for you and we did have a brief chat with Ed I think back in Bucharest, if it's something the members want and agree with, RIPE would also update their database to support these features, they kind of serve the members, it's just a case of members telling them do you want this or not.
So yeah, I think that's it. I just want to make you aware there are changes coming to MANRS, so PeeringDB, there's drafts being worked on to try fix these issues, yeah. So I hope it was helpful and thank you for listening.
(APPLAUSE.)
RUDIGER VOLK: OK. Since 1995, I have been dealing with all of that actually as an engineer and as an operator and kind of, I find it very surprising that almost 30 years after the RPSL as such was defined, the design flaws from ‑‑ or well OK, the aborted design are being picked up and one wonders what life span we expect for changes that you are proposing now since in the meantime kind of a new generation of tools for defining routing policy based on security in the first place are being deployed these days, they are not compete yet but kind of already for many years I have been pleading with people who were starting to well OK, we are setting up an IRR. And I told them well OK, maybe it would be wiser to actually expand your effort in development at the moment on the new stuff and even more important, spend the effort in teaching the community how to use those tools on the new stuff because if you spent effort on developing stuff that will have some lifetime but kind of educational investment, kind of ‑‑ well OK, fixate people to stay with that stuff forever because you will have additional effort, not only to teach new stuff but to, how to transform, how to migrate from old to new.
So, you are proposing to essentially extend the RPSL schema and the question how long is it going to take that the database implementations all support this. I wonder does any of the database implementation so far support the source notation, the source notation was done in the very beginning in drafts that we were trying to say, well, OK, we want to do this as a multi‑database distributed system and, well, OK, they did not really continue the work because they figured out that's really hard, and I think none is actually doing it and quite obviously none of client implementations is supporting this.
So kind of what's the timeframe? When will all the pieces in the game actually support and what lifetime should we expect for that to be actually the useful thing and until it is succeeded by something new? In fact before I retired and Covid set in, I had essentially all these things done in a manner , well, ok, some limited that could be done on my local client ‑‑
DAVID TATLISU: Sorry to interrupt but this feels like more of a comment than a question.
RUDIGER VOLK: Well, ok, there were a couple of questions and yes, I would like to hear answers. At that time.
JAMES BENSLEY: Thank you for the questions. I think there are two major questions I got, the first one is essentially what is the lifetime of this work that we are doing. Because I also gave a talk yesterday about how we are looking at dropping prefix filters but we are keeping AS path filters and relying on the RIR data because ASPA coverage is not there yet and I think getting to the point where we as an industry get rid of our RIR based filtering is in the dreamiest scenario a decade away, that's why I think this has work is worth the effort because we are in the very best scenario, at least a decade away from that, so I think it has worth.
And the second question you are asking is about updating all the clients in the database to support this work.
So there's basically only two database implementations, IRRD and the RIPE software, Sasha who is helping me, they help maintain IRRD, we have been in conversation with Ed about getting the RIPE update, the two preliminariations that exist are both being kept in the loop and actively working on this, I have personally already with a pull request in for IRRD so the clients are being updated as we speak.
So we kind of hopefully got all of our bases covered.
RUDIGER VOLK: One follow up question, I heard you claim that AS‑Sets are used for enforcing AS paths policies. Is anybody doing this?
JAMES BENSLEY: Yes.
DAVID TATLISU: Yes.
RUDIGER VOLK: Yes, is that as a kind of a response to getting completely unusable data when you resolve the customer cone... (Inaudible)
I could give advice on getting the customer cone data.
DAVIDS TATLSU: Please give in an advice in the coffee break.
AUDIENCE SPEAKER: Tim... RIPE NCC, thank you for this presentation, also just drop you an email actually because I wondered if you are aware of an effort early days in the cider ops working group in IETF where aspra is designed but they are talking about other object type... which is essentially an AS declaring these are my piers and customers so that may be of interest to you as well.
JAMES BENSLEY: Thank you for pointing that out. That is interesting so thanks for pointing that out. There was an another comment, yes comment, by Ruediger that I forgot to answer which is about the education thing, why don't we just educate people to move, create ROAs and create ASPAs and updates... something we have been discussing like an ton knows in the MANRS working group is should we require that MANRS participants have a hundred percent ROA coverage and it created a debate because there are legacy resource holders who can't create ROAs and one of thigh points was you can educate the people so I'm for this proposal, right, that people must have 100% ROA coverage for their prefixes. And one of the reasons I just, this is my personal view on this, this issued be a must is that you can educate people all you want, it doesn't mean they will do anything about it. And the problem is in the early days, if someone small number of networks don't create ROAs or ASPAs that, doesn't doesn't affect anyone else, when the industry gets a high‑level of adoption, we can't because this small group of networks haven't create the ROAs or ASPAs and we have to keep the legacy and the simple rule of the world is people will continue to use windows 7 and IP version 4 unless Microsoft r deprecates windows 7 and unless people like let's encrypt give free certificates or browser vendors make it difficult for you to browse to a non‑HTTP website. At some point you have to put your foot down and push the status quo forward, otherwise a small group of companies or individuals will hold back the greater mass and so I am not obviously not against educating people, of course we should but in my opinion, it isn't enough, so we have to do the work. Yeah.
AUDIENCE SPEAKER: Stavros... I couldn't agree more with everything, both with the work and what what you said and the results that you have presented, I have seen exactly the same and as well I had not with you but I had a similar discussion with Ed last year, with to maybe have something similar with excluded members in RIPE DB, we had a brief discussion because I have seen the same problem, my route server configuration blows up every hour and inter.link is one of the guys that I guess, gets thousands of line as a prefix filter. And I know you do a great job, not customers of you do good job so yeah, I would definitely like to support this. Regarding the PeeringDB that is going to mandate the one AS‑Set, not against but I have seen very few, a handful of good citizens of internet that actually have separate AS‑Sets based on the direction, they have different export rules very well documented and including having different AS‑Sets based on the direction which is great, I totally agree. Maybe it should be also this documented in PeeringDB, if you got to mandate only one AS‑Set this guy has to choose where I put my piers and my downstreams and enterprise customers and fixed line customers, I do like this operation, that's how it should be done from the very beginning of rpsl, not putting everybody is bun bucket and blow up the internet and know that's acceptable, these good citizens with these rule are going to be given only one option and not the best option. I don't know if you guys have thought about this possibility and what you are going to do.
JAMES BENSLEY: Yes it's a really good point, we did discuss it with on the PeeringDB issue and raised a feature request, we discussed it a bit. So I showed in my slides where it was like 0.8%, less than 1% of networks have more than one AS‑Set in there and there are, a small number of valid use cases, they do exist, for those people it's not fair we can say ‑‑ but what we came to the conclusion was basically like I said earlier, with the existing schema in PeeringDB, there's no way to programmically tell which is the AS‑Set used for different things, you can't label them, some people are multiple AS‑Sets for different regions, my European one, Asian one, there's no way to label in in PeeringDB and since it only applies to 50.8% of networks, we will limit it to one AS‑Set, if we want to do something more like label AS‑Sets or something, we need to a kind of separate feature because we couldn't kind of do that with the existing schema and fields that they had, it's kind of we need to raise another feature request and think about how to model it.
AUDIENCE SPEAKER: Maybe extend the schema to allow good practices.
LEO VEGODA: (Inaudible)
RUDIGER VOLK: Well...
DAVID TATLISU: Please keep it brief.
RUDIGER VOLK: I am avoiding rephrasing a question on what is actually a constructive suggests to suggestion to enable moving forward, you should actually support drawing in all the ROA information that is out there when you are resolving ASes. So that for parties that are actually supporting everything is ROA, do not need to maintain the route set in the IRR.
SPEAKER: (Inaudible) when was the last time you did a which isser, it's already in there!
STOVE ROSS: RPKI knows not... (Inaudible).
RUDIGER VOLK: Well the question there is which client are you using and which database.
DAVID TATLISU: Wasn't there something about staying brief please.
JAMES BENSLEY: It's a valid point you make, Ruediger, so maybe one thing is it comes a little bit down to your network and your implementation so we have two different things, first we check the ROA status then we move to IRR prefix filtering first.
RUDIGER VOLK: Kind of negative filtering was Job's intervention and I envy him for that, the actually constructive positive addition is something that actually has been discussed also long ago but for most part has been forgotten and it should be certainly there, it is actually effective. And in my practice, I even could incent people to do their ROAs because doing a ROA with a max length is much nicer to do than to enumerate all of the more things for having exactly matching route objects.
PETER HESSLER: I'm speaking on my behalf on and my behalf and as a comment to you, Ruediger, anecdotal evidence shows when you add a customer to our AS‑Set, in your experience it's about 7% increase in traffic. Even though we are a Tier 1, so this is it's surprising there's that that large and that measurable, secondly your idea of being able to reference I want the ROAs for this AS in my RPSL, it's it's very interesting and it's a great thing to add right now or modifying the schema even though the actual utilisation of it today may not be interesting; in a year it will be interesting. So moving forward, make one change.
JAMES BENSLEY: I want to make sure I understood correctly there is a feature in IRRD, IRRD has the possibility to import the entire ROA set and when I query it for an AS‑Set, get me the all the prefixes in the AS‑Set, it only returns the ones that are ROA valid.
PETER HESSLER: Kind of, I want to be able to say, is it... members and other ones refer to the AS‑Set object of the database, I think it's interesting which is based on the route objects and I think it would be interesting and if I understand Ruediger correctly his suggestion is a similar type for instance the ROAs for that AS.
RUDIGER VOLK: Kind of no need for a schema extension, it is just enhancing the resolution mechanism. Kind of at the point where the resolutions as I have an AS that I want the route set for, I can query the database and I can actually look into my RPKI ROA set and just include that and actually I did that for my client before retirement.
DAVID TATLISU: I am going to cut you short here.
PETER HESSLER: I think we should move it on to the mailing list.
JAMES BENSLEY: Thanks for the feedback.
PETER HESSLER: Thank you extremely much more the negative do not include syntax because we get all sorts of crazy stuff.
AUDIENCE SPEAKER: Stavros again, a last comment on that discussion and your comment, it is possible in IRRD before to create... you can take the whole... database and IRRD will create automatically route objects or route six depends and in theory it retains a source RPKI, you can also pump up the priority so it can be higher in the priority for responses, compared to whatever the resources you have and you can resolve AS‑Sets and then it will look first based on RPKI data that gives you route objects that are pseudo route objects based on RPKI, that's what we did in two articles that you quoted successfully and that's how I saw networks that I get now more route objects and my filters expand because I source RPKI DB RADB level three and all this... so those, but that is a work around, based on Sasha's ideas and maybe some recommendations from entity who sponsored the whole database, it's not official, it's not any idea for big corp or anything, we are going to update our PCP that we have in connect and has been, you know, working to include this recommendation and then we can move forward.
JAMES BENSLEY: Cool, thank you.
DAVID TATLISU: All right, we don't have anything online so thank you, James.
(APPLAUSE.)
JAMES BENSLEY: Thank you for listening.
DAVID TATLISU: Next up is me. I know I am standing between you and your coffee, this is going to be super quick, we have one new NWI, we open up today which is for additional new of clean‑ups so I am not going to waste your time going through everything because little has changed. What I would like to do closing the session is remind everybody about the PC election, ballots close at five today. Please remember to vote for the general meeting if you are eligible until nine tomorrow, the ballots are closed then and no complaints will be heard.
And also I'd like to ask you to rate your talks. The feedback is immensely valuable and helps us or helps the Programme Committee put together proper agendas.
PETER HESSLER: And I guess is there any other business that anyone wants to bring to the working group? .
DAVID TATLISU: All right, see you in half a year.
Coffee break.