This is RIPE 92.
Side room.
Wednesday, 20th May 2026.
OpenSource.
SASHA ROMIJN: Good morning everyone and welcome to the RIPE 92 OpenSource working group, thank you for joining us at this early hour here and also online participants.
Before we hand you over to the speakers, a few administrative matters. We have a scribe from the RIPE NCC CC. Thank you. It will be published afterwards.
We pass on your ratings an comments to the speakers so we can do, we can all improve even more.
The NomNet DNS is a development story with ContainerLab and finally how much of BIRD is actually vibe coded.
And then one lightning talk at the end. And also I want to mention that we are working on an improved chair selection procedure, which we have been working on for a while and that will come to the mailing list probably in the next few weeks I think I can hand oaf to the first speaker, so Barry.
Please join us and Barry O'Donovan on application security and IXP manager perspective.
BARRY O'DONOVAN: Thanks, Sasha, good morning everybody. Delighted to see so many people here bright and early. My name is Barry O'Donovan, I am from INEX and I am the IXP manager I suppose lead developer. So I am going to give you a little talk about web application security.
And why web application security, this is a conference of network engineers, so I think just to try and contextualise this a little bit. More and more we have web applications that give essentially access to our production environment, IXP manager it self generates route server configurations and feeds into automation provision of switches and it is our central source of truth for member data.
So the attacks services has grown and even if you don't have a public facing website or some kind of customer or member provisioning tool, you probably have some kind of APIs, you are you are probably using a public API to get data and you have staff and Sasha gave a presentation at the plenary which made me very nervous, but we now see that there are, you have internal threats as well in terms of your staff, just using your web application, not even being compromised directly.
And so we are in an era of unprecedented regulatory scrutiny. So a web application compromise is far more than just the sort of old fashioned egg on your face our website has been defaced. It is now a potential compromise of your production systems. I am not going to linger on the slide too long, I want to highlight the resource that OWASP, a top ten list, the top ten web applications issues they find, if you take for example the first one, broken access control, they say in their studies and their reviews of web applications 100% of applications have some form of access control problem, whether that is on the sort of lower end of the scale, maybe user numeration through lost password or maybe something more serious or something like not just implementing restriction by default and elevating permissions as you need them. So it's an excellent resource. It's very, very readable. Even if you are not involved directly in web application development, you are probably adjacent to a team who is maybe managing a team, it's definitely something you should read and it is very, very digestible. Just a quick bit of IXP managering for anyone who doesn't know what it is, it's a free and OpenSource platform for IXPs, it's been around for a time but we created it before 2005 and we did the first major upgrade of it in 2005 and we OpenSourced it in 2010.
The IXP manager website on IXP manager.org has lots of information and it has a very good community section, it lists all the users of the application that we know about but it also gathers statistics and does that every single night and it talks about the methodology on the website but suffice to say that it's an under estimation, so what we know is that there's at least 262 exchanges using IXP manager, which connect over 14,000 networks and of those, about 8,000 are unique. So that's a bunch of networks peering at multiple exchanges.
There's almost 500 terabits of connected capacity, not core capacity. And that's over almost 21,000 ports. So that kind of reminds us, it's something to be very proud of and remind us we have a significant responsibility in the software that we release.
So just talking about legacy, I did say that IXP manager is a 20‑year‑old application and that isn't to say that the code base is 20 years old, we get to that in a second. But it is to say over time you make certain assumptions and many years ago, not many years ago but ten plus years ago, the web was much more user friendly place, if you forgot your password and put your email address in a box, it would tell you we emailed a password reset or you used the wrong email, now if you, say if you entered an email that's registered, you will get an email, all these things change over time, what was acceptable in 2010 is a risk in 2026.
Rewriting isn't realistic. IXP manager a massive application, it's very broad and very deep, I remember one time someone said to me I am going to rewrite IXP manager in two weeks in Python because PHP is insecure. He came back to me six weeks later and said yeah I couldn't do that in six weeks, let alone six months, it is a very deep application.
And of course as I said in the last slide, success raises the stakes, there's over 262 exchanges using it, we have to be mindful of that in the changes we make, when we do framework upgrades, that also has knock on effects into operating system requirements.
So while IXP manager is a legacy application, the manager as it is today is a modern web application, has no real resemblance to the one we would have used in 205, we were using PHP4 and Pair if anyone remembers that, would huge amount of pearl tooling around it that the route server configuration and things like that, in 2007 we went on to what became the new paradigm of web applications, the model view controller system with Zen framework one and we had it for a long time, we didn't switch the framework two or three, they were very different, it wasn't, it was a rewrite rather than simple upgrade. And in 2015 over the course of four years, we dual stacked Zen framework in Laravel. It shows you how difficult it is to fully upgrade a web application.
[TECHNICAL FAULT ‑ 10 MIN GAP]
... it's a very modern web application framework used by tens of thousands of applications, probably the most popular web application framework today.
So it's just as a sort of a reassurance, in terms of having a legacy application where we keep upgrading it under the hood, we do have kind of what we would say layered defence in how we release code and how we test code. We have a very mature continuous integration pipeline, which uses static code analysis and it also also uni testing, hundreds and hundreds of unitests, including front‑end unit tests, so I think the entire front‑end is fully uni tested.
Supply chain security is probably the biggest current threat facing most web applications, whether you are doing something in node or ruby or PHP, when you require some third party application or third party library, that library has a bunch of requirements and then they have a bunch of requirements and suddenly you have add one library to your code base which it turn added 25.
So this is the problem with a supply chain. One of the things we try and do is not use third party libraries for simple stuff. There's a very famous node example of that from years ago where very simple one function library got compromised. So we only try and use it for stuff that's sort of broader. But we also use Github's DependaBot which is an excellent tool for keeping us secure.
Penetration testing we talk about in a sec, we do have a secure application development policy which is published on the IXP monitor.org web website and that allows other users of IXP manager to include that in their own I.S.M.Sprocess but how IXP managers developed and we use anything else that's available to us, two‑factor authentication, branch protection, there's only two people allowed actually push code to the release branches.
Independent security assessments, these are always kind of nervewracking when someone comes and says we have done a penetration test on your application and the first three of these we found out about about them after the fact, users of IXP manager shall the NCC group was one used in a non‑IX environment, it was in a government environment, it was given to us under MD A, I am trying to be careful here, it was used in a government network where we have the telcos of that country peer with peer each other their private exchanges.
So that supplier used the NCC group to pen test their entire solution and that pen test
In terms of the actual results of these pen tests, they were reassuring in a sense that there was no major red red alerts, what it was mostly about was that sort of legacy, it was OK once upon a time but it's not OK now. So user numeration through lost password, we didn't have good enforcements on passwords. One if one was disabled, it is only available to admin users anyway.
The EU created a programme called cybersecurity support action programme and the role of that programme was to get individual member states to get their critical and essential infrastructure into a better footing from a cybersecurity perspective, what they said from an exanti and expost capabilities. So in Ireland our national cybersecurity centre was assigned to oversee that programme, and in Ireland in 2021, our health service suffered a cyber attack, right in the middle of Covid, which took out the IT system of the hospitals for weeks and out of that the government created what they call a core group and the core group was to create these sub groups related to government functions, so health, education, transport, digital and to create these groups where they would pull people together from industry and create a shared space where you could share information on threats, you could pool resources for education and then if there was a cyber attack, you could pool resources to help fix it. INEX is part of DigiCore and they invited members of the DigiCORE to submit applications for one of three cybersecurity packages and one was web application test services to INEX applied to have IXP manager put into that as part of our application we did say that beyond just the benefit to Ireland and Ireland's digital economy, it would also be of benefit to about 60 IXPs within Europe plus over 260 worldwide. It used the latest versions of the framework, it was a pen test on the current version of IXP manager, they used a grey box methodology, which is where we create a production like environment of IXP manager and we give them access to it, user names an passwords. So rather than them wasting time trying to break down the door, we let them in and say have at it lads and see what you can do here. The white box methodology would have probably have been much better, a white box is where you have access to the source code as well and IXP manager being OpenSourced, that would have been easy but these were, this was sort of an off the shelf package and the company that did it was called S2 group /POE, they used a combination of AI and human penetration testing, I did, the AI stuff was kind of obvious, you would see 20,000 hits in the logs over the space of an hour and the human stuff was people just going in their trying to there trying to inject stuff in the database and stuff.
The results were kind of sweating the results before they arrived shall they were quite relieved when they did finally aarrive, there was no high or critical risks so the highest problem they found got a CV SS score of 6.7 and that was a cross eyed scripting problems.
They found the lack of headers, this goes back to Sasha's presentation in the plenary about content security policy, so we'll talk about that, the x‑ray options in a sec, they found, they called it user racial, X frame they found information disclosure they were 50/50 on including, it was an SQL query in an exception that was printed, they were like well look it's an OpenSource application, the stuff is obvious anyway but they are right to include it, we shouldn't be putting SQL queries in error messages.
So all of those are been addressed in 72 which we released last week, the only one we haven't done is the CSPwhich requires more research, it looks more complicated than something we can rush out the door but we did mitigate that issue with the X frame options, their shoe issue there, it's an all web application thing and that is that they are all vulnerable to high jacking if you are not using content security policy or this X frame options deny, so without these, it allows your application to be embedded in an I frame and then have someone put something over it which might be invisible on the website so that when you click on what you think is your application, you really are clicking on something else.
So anyone who has web applications, the easiest mitigation possible is simple deny. What have we done since, we have released 7.1 shortly after the pen test was done, before we got the results, one of the things that IXP manager has, it has a public facing website by default, I don't think this is feasible in the medium term, but we are where we are at the moment. So what he did in 7.1 is we moved over 70% of all URLs behind a /admin prefix, now in your web server you can use IP ACLs to restrict access to that.
In 7.2 which was the release of the that fixed all of issues, we have a new developer and he developed quite an innovative way of doing scripting, enstead of trying to inject cross eyed scripting code, he went into the database and put them into every column an browsed their website and figured out why we weren't escaping that stuff on preparation, he fixed many templates with that, there are no known proof of concepts but they are taken care of, my time is up, the key take away is penetration testing is good, don't be embarrassed by it but it's a very useful thing to do.
Our new developer is fully funded by sponsors so we thank them.
Many of them are here actually. And thank you for your time.
(APPLAUSE.)
SASHA ROMIJN: Thank you Barry, what you said on content security policy, it's powerful and can be a challenge, I heard it from more places. We have a little bit of time for questions.
SPEAKER: Hi, I am going to say I have a comment but there's more towards the room than towards you, if you have a small project and don't have the money for penetration test, you could contact like the servant tent fund to get a funding to get these tests in and I can highly recommend doing these kind of tests.
SASHA ROMIJN: Maybe if you have some organisation, you could send it to the failing list.
SPEAKER: I will see if I can compile a list, thank you. The line is closed also.
SPEAKER: Maria, developing BIRD, I'd like to say you are quite ‑‑ with those four years of rewriting two different frameworks, it's more than five years to update the back‑end to multi‑server it's a long time that's needed and it's always like you think in the beginning that this is for three months and then it's going to be five years because you didn't see how it looks like. But what I wanted to ask, how much time does it take for you to keep up with all of the dependencies updated, for us we don't have ‑‑ we don't do.
BARRY O'DONOVAN: It's very time consuming and there's a cost to that, when you are doing that stuff, you are not creating new features on the users. But tooling like Githubs DependaBot is really helpful for that kind of thing and we are we are doing new releases, even bug releases, we will always release the latest framework but it is challenging. Mat mat yes, thank you.
SPEAKER: I have two questions, I will start with... who is asking how many% of age securities whose reports you get, several false project received a large number of Hal use Nate Tore reports. Bar we have been very fortunate we haven't been struck by what I see in other project I am involved in, wide ranging LL M things, so we have avoided most of that, we get a couple but very few so far.
SPEAKER: Thank you and me ‑‑ this is speaking for myself, Marco Sanz, would you recommend if other OpenSource project to participate in this cybersecurity programme if the opportunity?
BARRY O'DONOVAN: Absolutely, and as the gentleman from par Dina said, there are multiple programmes, I think we are past the point where people should be embarrassed by what comes out of these and take them as an excellent learning experience because even if the findings aren't high or critical risks, you learn something from the low and medium one, I think I would absolutely recommend everyone to do it and don't be embarrassed by the results. Thank you all very much. (APPLAUSE.).
Rome next we have Amy and Dave talking about NomNet DNS response, the live transcription isn't working but it is being worked on and hopefully will be fixed as soon as possible.
AMY O'DONNELL: Thanks Sasha. Hello everybody we are delighted to be here and hello to everyone online, it's great to see to so many face after such a great social last night as well. My name is Amy O'Donnell, social impact lead at NomNet and this is my colleague Dave, say hi.
DAVE KNIGHT: Hi everybody.
AMY O'DONNELL: NomNet run the registry for the.UK domain and we are by our set up a public benefit company, it's in our articles of association and we are a company limited by guarantee so my role at NomNet is to look at that surplus funding that we have and think about what public benefit activities we can support. In the past that has looked at quite general things like digital skills, digital inclusion but we have really taken a strategic step to move those activities a lot closer to our core business. Hence we'd like to present to you very humbly with a very much learning hat on our DNS fund.
So this was launched in pilot in September last year to look at the Securities Sustainability and Resilience of OpenSource DNS project. We are very much on a journey, we are here to ask a question of you and that is are we doing the right things as we adapt to what we have learned and we really honoured a few of the applicants, the successful applicants that we are funding are in the room, so we are also going to hear from them and hear their reflections on how things are going.
So without further ado. And the first place that we started and I'd like to take you back to 2023 was that we commissioned r our research, it's something we always do, really understand the ecosystem in the landscape, we work with DEMOS, a London based think tank, while there were lots of things around digital skills and impact assessment frameworks, we centred on this idea of the maintainers of core OpenSource DNS. And they flagged to us that there were three key kind of problems in this space, in funding this space. You may or may not agree and we welcome your feedback as well.
But the first being that the majority of funding stems from corporates rather than foundations which can bias some of that development, we have seen funding not available to individuals, only project or registered organisations and single source funding so one funder, one project. That led us to launch our DNS fund. As I say we launched it in September of last year, the wind doe was open for about just over a month. And we had an application window, 370,000 GBP, and it was available to anyone who apply for up to 100,000 pounds but we could go as low as, there was no minimum amount because what we recognised was a lot of the developers and maintainers in this space aren't always looking for this significant amount.
And we really are delighted actually that we will be launching a second window next month which will be quite a substantial amount more money.
We'll go into more of the changes we are going to make. How did we end up in this place. Originally we were looking at our traditional funding model at NomNet, where we would do research, identify organisations operating in a space ahead of time and reach them rather than offering an open call but we decided that it was much sort of more of an opportunity to open that call up to anyone to apply but what we feel very conscious of is your time is really precious and really sacred so we wanted to make that application as tight as possible. And something our advisory panel really recommended us was to keep the application to the length of a coffee, so 20 minutes. Now, that might be ambitious, some people say they spent more or less time than others, but we really want to try and keep that application as what we called minimum vibal bureaucracy.
We originally went out to another third sector, a third partner as well to look at whether they could help us administer the fund, that didn't work out for a number of reasons. So we decided to take it in‑house and run it under the name of NomNet and we think it's worked out well that way.
Going back to my first slide to say we hope we have addressed the first problem because we are not trying to implement the development of these project, you apply and come to us with what you want to see funded. And while originally we did eligibility criteria that meant you had to be a registered organisation, we have made our way around this and we are looking at funding individuals so there's a few small administrative things that we are looking at, less money, and we are looking at things like liability insurance and how strict and stringent we can be on that, we are trying to be as adaptable as possible, that's one major thing that will be changing moving forward. On the third, I think it's just early days for us and we'd love to look at other funders and whether they can join forces.
What made this credible and feel like we were able to proceed and make the right decisions was our incredible expert advisory panel. We wanted to go people in the space that know their stuff. We had Mirco help that and a number of members and members of ICANN and Hannah what did that research for us, they were really influential in how we set up the fund which we did from a principle wayses and also inevitable selection and these are were the principles they ended up working with us to agree upon and we hope that this helps us to just be really transparent in what we are looking for and why we are doing what we are doing. Originally there was seven and one of our values is keep it simple, we have cut it down to five.
Really interested in your feedback on this, if you get a chance in the questions or later afterwards, particularly I see someone in a FosDEm t‑shirt, I was at FosDEM this year and people were really ‑ challenged us on this criteria three of proven use, that for us is really important we stick true to the idea that we want to fund maintainers of the core foundations of OpenSource infrastructure, we don't want to fund innovations or go for the sparkly new things. But some people are saying there are other things like maybe education, participation of young people in the processes of this or indeed making sure that some of the technologies being built now are future‑proofed or looking at the horizons. So that's one for us to unpack as we move forward.
That means a combination of all these things, we are changing three key things as we get ready to launch next year. You will see more money and also some new advisory panel members that we'll announce next month. But we have also got some guidelines for individuals to apply, maintainers that operating on their own, don't necessarily need to be registered but we need to work with them closely on their contracts and we we think that's really important, working on multi‑year grants, one of the feedback from DEMOS was sustainability is really important, while the pilot was for off grant, we are looking at up to three years of funding to you can apply for and see that into the future and assay, clarity clarity on proving use, I will hand it to Dave to just introduce some of our successful applicants for 2025.
DAVE KNIGHT: Yes, I get to talk about what the first awards are made by the fund and where they are going, so NomNet will support eight project this year, three of those, the process is still ongoing. So today we can talk about the five which are already being awarded. The slide here shows how the fund is supporting things across the DNS ecosystem. So going there from left to right, there's the OpenSSL foundation, which will support work on the OpenSSL library underpinning endescription, and so many technologies, not just DNS, QUAD 9 will be receiving funding, that will help their team tackle technical debt and the internet systems consortium, we use this to replace the BIND 9 scalability and performance test bed which will allow developers to spot problems earlier and this was a case where we hadn't originally intended to use this money to buy hardware, but in this case, that's where it's going, it's a change we will make going forward into next year.
Through owe ark, they will receive one in support of valid NS, licence validator and finally L net labs are receiving funding for cascade and new purpose‑built stand alone DNSSEC sign sear, we like to people to ask the general questions at the end of this, but I know there's some people representing some of these project in the room, it would be really helpful if you could come to the mic now and share any feedback you have on your experience and just to sort of set you up, we are kind of specifically interested in how did you find the process, are we making the right changes for next year and would you encourage others in the OpenSource community to. We have got John from QUAD 9. John John, I guess my comment ises in one of the easiest applications we have ever done for a grant, thank you for that, normally it's an extremely painful process with a whole lot of internal discussions, but this made it very clear what we needed to do, it's it was focused on software and operational code we are going to deliver so it was quite easy for us to put together and I think also then the metrics are actually really great so it's basically what's ending up in Github does good work. So we are an operations based organisation, we don't really have a development shop, our code base is widely distributed across a bunch of different project but each one of them for our own needs and what we think the rest of the community needs, there are a bunch of different patches and upgrades that we are going to work on to deploy for both visibility and performance areas of our own service but I think they will be useful for everybody in the community, not just /RAUFRS, I want to say it was really easy and I appreciate the fact that it was done thinking about this at the very low layer of people doing code rather than at the much larger organisational level.
AMY O'DONNELL: Thanks John, it's very kind but you can also be honest and what would you like to see us improve, are we changing the right things, have you got ideas for the future. John: Improve, actually. Well OK, there's one, so one of the things that we are going to be delivering as part of our grant is basically some test bed examples, best case user, best use case /KPAFPS of some of the code, vector is one project we are working on, I gave a talk at owe ark last time but being able to tell people that the code we are doing exists and how to use it, I think is really important because there are a lot of these monolithic code bases that are challenging to get understanding about and so I think one of the next things would be great to do would be get more education or training in some of these things so that not just the largest organisations but the next tier down have a better understanding how you use certain functions or features or code bases in general, I think that would be a really interesting next step for you.
AMY O'DONNELL: Thank you, Vicky, do you want to come forward?
Vicky, tell us about what we are funding for you and be really honest but we can improve and what you would like to see differently.
VICKY: Okay, well we had as a nine‑year, as a virtual organisation, we have very little of our own actual hardware so we are testing everything on virtual machines but for performance testing, you really need, you need actual computers, otherwise you are just testing the VM or AWS infrastructure, we had this test bed but it was ancient. Nine years old, you can't get support any more.
So they actually hadn't anticipated supporting hardware. I was really pleased how flexible they were to consider this. Because we have users all the time that ask us for recommendations on how to set up their operating system and they are running on computers that we simply didn't have the same kind of machine to test on.
So we have ordered some hardware, we have had tremendous struggles with delivery, but we have most of the system set up now and we actually have been able to begin doing some profiling where we just threw a lot of queries at BIND running on the system and measure every hundred milliseconds what is the system doing and we do have plans to do some other tests. In fact, we are interested in input from authoritative operators about what they think might be the performance bottlenecks that we can measure.
As far as the application process, I have applied for quite a few grants over the years. And this I thought was the most straightforward. Not a very complicated portal with lots of separate things you have to paste in, but I just recall sending one email ‑‑ I will say the salient thing to me about this process was how quick it was. If you need money, you really can't wait for six months to find out if you are going to get it. If you need to make another plan, so this, I remember it was about a month from sending in the application to hearing and that was fantastic.
AMY: Thanks so much.
BEN: Yeah, we are, where to start, I have a long list, so we were sponsored funding to develop Cascade, kind of a stand alone, as presented, a stand alone DNNSEC signer. We look at current develops an ideas in mostly the TLD area but also developments in the IETF, what's a common practice and put that in our software and it's also intended to be a success of open DNSSEC, it's some sort of maintenance but a rigorous maintenance and moving forward to a new implementation. And what's really good with collaboration with NomNet DNS fund is also well you are also active in the outreach so we kind of piggy backing on your outreach and that's really important. Getting contact with users, potential users, have the discussion, their input, what are their requirements so that's really great. And back to what Vicky said, the whole application process was super, very supportive, short turn around time, not much overhead and also the reporting is very close to our internal processes, good at pulling requests and with a milestone and a report which, not much overhead, very close to our own internal processes and very supportive staff so thank you all, and yeah, I think for time I will hand over to Phil.
DAVE KNIGHT: A question before you, go, one of the things we are interested in, what would you say to people who want to apply next year?
BEN: Yes, think about it and what triggered ‑‑ it's also maintenance and I might, that was the first trigger actually because it's very difficult to get funding for maintenance, new features, there are different funds to find or from industry you can get funding but for maintenance it's so difficult to get funding, you have to find internal funding, make reservations and in times of LL Ms, I don't have to repeat the presentation of Peter yesterday, in times of LL Ms, maintenance is essential, it's every day work, you don't get lost credit but it's investment for the future of the product and to our customers and users.
I forgot your question. Oh yeah, to you all think about indeed, it's easy to apply for a funding, think about also maintenance, small improvements, stability, because we need it. Definitely in these times. I think that's a good stop for me here.
PHIL: All right. Yeah well we are one of the smaller project in this whole space, so I got a few bullet points, I noted how this has really been a welcome surprise, we were not expecting this funding, this is timely in DNS Org I have been running for a number of years now has taken home some stray cats of the licence world in terms of software that was not being maintained but the people in charge didn't really have the resource to say take care of it and we had taken over a maintenance of L DSused by some authoritative operators to use DNS zone validation and we thought, how will we fund this and just hear about the DNS fund. So like John was saying, it was easy to apply, which doesn't mean the bar was so low that anybody could get it, but we could focus on the requirement specification for applying rather than paperwork, the compliance and did we have industry standard rubber feet and those things, the whole point was we could focus on the actual grant and not all the buzz words.
The funding itself is kind of critical in that it's a vote of confidence, getting the funding from a panel of qualified, when the review process going through panel of qualified engineers and knowledgeable people who work in this space, it's an endorsement for the community to say this software is not a vending ware, we can use it because it's actually being maintained and sometime there's a bit of a chicken‑egg where people are looking is anybody going to fund this before I use it, how about you fund it, I like to see if anybody is using it before I put money into this, that's the kind of thing we got.
And it does encourage others maybe to pitch money in, we like to do donation matching and trying to get several organisations to contribute.
There's other tools we have that could benefit, we found out about the DNS fund shortly before the deadline, we put together a proposal, we have other things, other projects that we know the community's using in terms of instrumentation and manipulation of data, DNS data, we are thinking of course of applying and for the other stuff we have got. Fellowship programme is one thing we'd like to do and all software isn't like wine, it doesn't get better the ability to do multi‑year maintenance is critical, we are happy and looking forward for the next one.
AMY O'DONNELL: Thank you. I think we are out of time, but just to say if you do have feedback, if we are making the right things, if you would like to see anything different, Dave and I are around and you can always email us at DNS fund at nomnet.uk. Thank you.
SASHA ROMIJN: I think we have one quick question.
JIM REID: It's not a question. Jim Reid speaking as an individual. I just want to say thanks to everybody to NomNet for putting this things together, this is a wonderful initiative and I am very, very grateful that this is underway and you deserve a great deal of thanks for putting this together and I would like to see more of this kind of thing going on so thank you.
AMY O'DONNELL: Thank you.
(APPLAUSE.)
SASHA ROMIJN: Next we have Gordon talking about ContainerLab, an OpenSource maintainer that's applied for funding, I am happy to see NomNet pay attention to the /PWAOUBG or see, I feel I need funding to find the time to apply for this funding.
Gordon.
GORDON GIDOFALVEY: Thank you, I am here in my day job of consulting systems and focusing on data centre fabrics over NAT Nokia, today I am talking as some of the developers of ContainerLab.
So what is ContainerLab you might ask. And I sort of asked the same question about half a year ago in Bucharest. And if you would like to see a complete overview what ContainerLab can do for you, I recommend you check out the RIPE 91 tutorial session I gave. In short ContainerLab allows you to spin up virtual container topologies you can use to run containerised network and provides programme interfaces to talk to this sort of topology and you can essentially use this for either learning or for testing or whatever you would like. And the real nice thing about ContainerLab is it runs anywhere there is a container run time, either Docker or pod numb.
Today I will be talking about the development aspect of ContainerLab's background. And I would like to first start with the question of where did it come from.
Back in the 2020s, we were working on our then unreleased data centre network operating system, SR Linux and SR Linux is based on unmodified Linux distribution, so we thought why we would spin up a complete VM when we can actually just do a container and we found that they were not really any tools out there for creating container topologies so we created this tool and OpenSourced it shortly after and we gave this tool to the community to give it a feature and one of the first early things that we realised was that if the tool was under specific, then it's destined to be only maintained by the vendor. So we made it multi‑vendor by design. And after release in March 2021, it spread by a combination of social media and blog posts.
And we had some talks. We first had a talk in July at a NANOG and then came a talk at NANOG 83 and finally we showed off the tool to some of our friends in the more system infrastructure part of the community. At the open networking NHsummit and interest exploded. But why?
The time the project had its first public release when we showed it off it had mature architecture due to a rewrite that we had in 2021, March, thanks to my very talented colleagues, we had multi‑vendor support, I mentioned, which was the fourth public comment, it had a comprehensive documentation website available, a very friendly, human friendly topology format that's actually backwards compatible to this day, if you are familiar with ContainerLab, you can see the topology description on the right of the slide is going to be very, very familiar to you and this was actually written back in 2021.
And finally when we released the tool we also gave complete examples on how to use the tool, we really gave you a zero‑to‑hero in one minute sort of topology where you could go in and clone it and ContainerLab deploy and you had essentially the full lifecycle of the tool documented for you.
So what did ContainerLab at the time bring to the table? It solved a niche problem but it was becoming not so niche, the ability to run containerised network did so with a fresh and novel approach and that fresh and novel approach was this labScode experiences gave, give a topology description and a YAML and you could reproducibly create the same topology over and over, which was a big change compared to the tools available at the time which were more focused on giving you a GOI where you could interact with the topology. It's CLI friendly, it's also automation friendly. And as I mentioned, these topologies are in text format, they are very easy to share so if you have a result that you have creed with ContainerLab, it's very easy to share it with your colleagues and the community and speaking of community.
We already had a discord server to chat about the use of ContainerLab set up before the first public talk we gave. So really the very first public talk we had, we already have people that hey, if you would like to talk about this tool, if you have questions, come in our discord and we can chat about it.
Now, ContainerLab in 2026. ContainerLab recently turned about five years old and coincidently, I myself am about to have my 31st release just tomorrow, funny coincidence but right now there are four projects that are sort of in the umbrella of the ContainerLab project: One is ContainerLab itself, written in go, the other one is a visual studio code extension that I will be talking about in just a moment. And we also have the vrnetlab lab to give it ContainerLab capabilities, it allows us to essentially encapsulate VM based network OSes into containers. And finally we have Clabernetes which allows you to run your ContainerLab topology across Clabernetes cluster, it allows you to go to the next level with your topology scaling.
And we see that we have a mix of go typescript and Python projects here in this ContainerLab umbrella so it really takes quite a lot of effort to maintain this.
So one thing we did was we have full CI/CD set up for ContainerLab and also for the visual studio code extension, we do automated testing and code analysis on every comments that comes in and support request, we can really see code quality ahead of merging any code into the project.
We have tests for core functionality, we use the robot framework which is a testing frame for smoke tests and also to do some very limited network OS basic feature testing, give some interface numbering on both sides and wrapping across. So very rudimentary, we are not testing the network OS themselves here. And we do code coverage and code quality checks using Codecov. And similarly to the actual checking, we have a release pipeline that is based on Github releases and every time there's a new release, we generate all the release artefacts, for example the packages for various Linux distributions.
And when one wants to use the tool, there is a built in command that allows users to essentially upgrade to the next version and this is something we can do because ContainerLab is shipped as a single binary, it's a single binary, it's also one of the fresh and novel things we brought to the table compared to contemporary tools which might require like a full installation or aligns VM and ContainerLab's releases are not based on a release schedule to so it gives us quite a bit of flexibility and we can release and carve a new release.
When we look at what's new in the project, we see a few changes in the last year that are major milestones, the first thing I want to mention is put splitting the fore functionality from the common line to a part of the project and this enables essentially a ContainerLab‑as‑library usage and it also helped other recent developments like ContainerLab's web server which allows for ‑‑ which allowed us to creat a rest API on top of the ContainerLab. We had a very, very recent function that was added thanks to the hard efforts of my colleague Florian Schwartz, was the individual node start functionality which allows users to start and stop nodes in running topologies on demand.
Another piece of work that we put in was the sudo‑less feature which allows users to run ContainerLab without running an as a route.
Right now we drop some privileges when we don't need it, so, for example, if we only do read‑only stuff like inspecting the topology, we don't really need the privileges that much, but right now we still use privileged containers. Some work is still needed there.
And finally the VScode extension I will be talking about in just a moment.
Now, community. We have a discord community with almost 500 members, that's a lot of people being active in the community. We have swag of course, for example, this shirt over here or the stickers, I will be giving out some stickers later today, if you would like one, then come find me. And we also have frequent talks at NOG events and interestingly enough, it's not just us ContainerLab developers going around and giving talks, but recently started seeing ContainerLab users themselves going out there and giving talks about our project and that's very, very humbling to see as one of the developers of ContainerLab.
But to get here, to this point, we had to go through some challenges and we would like to share some of the lessons we learned as part of these challenges.
First, I would like to open this can of worms, the fact that ContainerLab mainly supports network OSes and network OSes are not OpenSource or freely available as a rule of thumb.
And you sometimes have to accept a licence, you have to have an account, you have to have a licence to run it so you might ask somebody comes to you and says hey, here's a support request, this adds support for network OS X and you say OK, how do I test this? I don't have a contract with that vendor. I don't have that image. So really you have to rely on community testing, it's really important if you work with a close source tools and sometimes it's actually worth reaching out to the vendor. And in fact we saw that some vendors have started reaching out to us, which is very much appreciated, that vendors come to us directly and ask us hey, can we get support for this network OS out, we'll be releasing it soon, as a containerised or as a virtual version and we would like to have ContainerLab support there from day zero. And that's amazing to see.
And I invite more and more vendors to, you know, come to us and let's work together.
Now, users. Of course every single OpenSource maintainer would be much happier if there were no users, right? So at ContainerLab love ‑‑ a lot of users are not familiar with how OpenSource works, they are more number with the software offerings, sometimes they have mismatched expectations. Sometimes the expectations mismatch is on the features side so the they expect ContainerLab to do things that is not really something we can enable, for example emulate hardware data play features or do for example take a copy of your production network and create a virtual equivalent of it, that's not really what ContainerLab's core competences are about but it could be very much a valid component in the solution. So try to understand your users' use cases; don't tell them, hey, like you are holding the tool wrong.
And this also means that contributors will have sometimes issues reporting their issues and sometimes the reported problems don't really translate well to code issues and more pertain to, say, a misconfiguration on the network OS side. So a good trouble shooting flow is really a must to have when you are working with, say, network OSes or your project really interacts with network OSes. And I finally, sometimes, they come and say like, hey, why does ContainerLab not do X feature, the other thing does it. And sometimes it's by choice and sometimes it's by lack of contributors. But be open to feature ideas but don't be afraid to say hey, it doesn't do it today or hey like it's not really designed for this.
As a quick aside on this topic, I would like to talk about the VS Code extension. At the beginning ContainerLab is designed to be CLI only and GUI labbing, it wasn't really the use case. And we even said this in 2024 presentation that if you are an UI network engineer, ContainerLab is not a great fit, and this is by design.
But it's sort of changed less than half a year later when two GUIs were contributed for ContainerLab, one is the VS Code extension which is a VS Code extension, and the other one is Antimony, a web UI and it became relevant for this use case and it's really a success story, it unlocked ContainerLab for a lot of users that wouldn't have used ContainerLab otherwise.
And it's a major growth factor for ContainerLab usage so we saw about 17,000 unique installations from the VS Code app store and 16,000 downloads of the extension for VS Code. And it's a big, big, big undertaking to do a GUI on top of a tool, sometimes these things have to be their own project for your own sanity. Sometimes it's such a big feature to add that it's worth its own project.
And just as a sneak peak, this is how the VS Code extension looks like. And now for development.
Maintaining four projects at once is tough, so we really split responsibilities between each other, and we also have day jobs so it's tough sometimes to keep up with the requests and the issues.
And sometimes these features might have cross‑project dependencies; for example, one example is the event streaming that allowed for more efficient VS Code extension use. And these releases have to be aligned. And for when you get a new request for an addition for a new feature, as those users please make an issue to keep track of those features, it's very important to keep track of the features because those features that somebody asked for, somebody might have asked for a year ago and when you see that users are ‑‑ can go for that feature, you should consider whether that feature should be part of your tool or not.
What worked for us is that we maintainers and regular contributors are power users of ContainerLabs, so when there's an issue, a missing feature, we feel the pain as well.
We also found that Discord is a very, very good way of onboarding users for in the community, it's very easy to join and of course for your own project, you should consider your users are and go to those platforms so if you are more privacy focused, Discord night not be a good fit. We have extensive examples in the repository and documentation for using the tool, it's a requirement if you have a new feature, then you have to add the documentation as well.
And promoting your own communities, it's very important because this gives the users and your contributors the little boost to go out there and talk about the tool and show off what they have done with it and in fact some of the folks watching the live stream might be here from discord because this was announced on the discord, this little talk.
And if you would like to contribute to a ContainerLab or any other OpenSource project, I would suggest you to first use the project, become a power user, because then you will see where there's really a missing featured and what is not really a feature that should be there, and you will also get to see some of the issues that the tool has.
Before you contribute to larger feature, look for lower hanging fruit because this gives you a view of how the project handles contributors because OpenSource sometimes doesn't mean it's really open access for everyone to develop.
And finally, interacting with the community and the developers because your idea or issue that you come across might be already known in the community and good project to contribute to will be open for discussions and they will help you help them.
And finally it's not chores so don't feel the pressure to do it; have fun while you do.
As for the future of the ContainerLab, we are open for contributions, and you can see some of the topics that we would love to get some help with. Feel free to take a look afterwards.
And finally, you can find ContainerLabs' documentation on ContainerLab.dev and we have this amazing discord for both developers and users at ContainerLab.dev/discord. If we have any time for questions, I am happy to take some.
(APPLAUSE.)
SASHA ROMIJN: Thank you so much, we can do one question but very short.
SPEAKER: I have seen, I have used Discord for quick communications, Discord, of course, is never really good archiving system. When your users are on Discord and they have interesting questions or problems, do you then port whatever the answer is to your documentation? Or how do you deal with the lack of proper visibility there?
GORDON GIDOFALVEY: That's a good question, thank you. We like to keep the Discord organised, if there's a longer thread of questions, we like to create threads that makes things more compact and easily searchable within Discord. We have also tried to use this sort of solution that essentially joins our Discord and creates like this sort of Wiki based on the contents of the Discord with some help from LLMs. But I am honestly not so sure whether it's been a successful attempt at exposing the internal state of your Discord to like the documentation. But yes, we do take like these suggestions from Discord, for example, into Github issues or even into documentation if something is unclearly documented.
SPEAKER: That's excellent. Thank you.
SPEAKER: Very quick comment from Maximillian, a shout out to Aristry, it feels like it was made for ContainerLab or vice versa.
GORDON GIDOFALVEY: Thank you.
SASHA ROMIJN: Thank you very much for sharing this and other things that are involved in OpenSource that go beyond publishing the source and I am sharing what was so effective for you in building this project.
GORDON GIDOFALVEY: Thank you very much and I would like to thank the OpenSource working group for having me on.
SASHA ROMIJN: Next we hear from Maria: Do we need OpenSource developers into the future? Can we just vibe code everything on the spot? Those are questions I hope to learn from Maria's talk telling us how much of BIRD is actually vibe coded.
MARIA MATEJKA: Good morning.
I think you are almost awake now. So I'd like to start with a show of hands. Who of you has ever seen an LLM output?
That's nice. OK. Who have you has ever LLM for something?
Who of you has asked LLM to generate code?
Who have you has asked LLM to generate code in C?
And who of you has asked LLM to generate a code in C for lockless structures in multiple threads, were you successful?
Because I wasn't. It was completely futile. It was totally hallucinated and I ran out of tokens, very quickly.
(APPLAUSE.)
Well, OK, now the long talk. I am actually looking around, looking at new networks and machine learning as a hobbies for like 15, 16 years, something like that. It was induced by a university lecturer about new networks neural networks, I was trying quite hard with generating pictures, actually around 2014, 13, something like that and I very quickly found out that it doesn't work. That you need a lot of tokens, you need a lot of power, you need to harvest a lot of data to actually teach the network anything and you cannot do it on your own hardware without having a giant gigantic enormous data centre. So I basically ran into a brick wall, this is not a brick wall, this is a stop place of an abandoned railway. By the way, there is a mark at the very end of that railway thing.
I will jump into the future. I was looking at things like stable diffusion, it started to look a little bit useful but nothing, nothing really nice, like four years ago there was a ChatGPT, I am going to, this is an English abbreviation, because we are at RIPE, which is an abbreviation of French words pronounced in English, I am going to counterpoint by saying ChatGPT. And I hope, pardon my French, it started to look funny and we had a lot of creep experience with those early versions.
And after some time people started to talk about would they achieved about AI. And they were like, well, it starts to be good, first it was ridiculous but it's started to get in the ‑‑ it started ‑‑ there started to be people who basically became the LLM bros, the LinkedIn LLM bros as I say.
So we got quite fast into vibe coding, probably even before Anthropic made sort code and there were claims like making a web app or a mobile app.
Well, there is the survivor bias.
And this is the thing you don't see on LinkedIn.
You don't see the failed stories. You see only the success stories.
And only those flashy success stories.
In 2025, I started seeing advanced coding agents, people started orchestrating things, people are actually using co‑pilot to help them coding, people run some fancy agents, I have seen lots of funny things being done by agents, some money sent to various places. And we got LLM assisted HR, which meant you can no longer just send a CV and hope that it's going to be a person who would read it, which means we started getting different CVs. Because people started adapting.
And we got LLMs who started blackmailing people.
There was ‑‑ I don't remember the exact project but there was somebody who refused pages from LLM and the LLM started to blackmail them.
So I decided let's try it.
And after trying it, well I encoded some web apps and it's quite worked, quite. It was an easy web app, well, I spent sometime prompting, I spent some tokens and several weeks later I decided to make another app but that app was a little bit more complex.
And it started to look more like this. Than like a real house, it started to look like things glued together. And I found out that I can use LLMs to actually glue libraries together, somehow.
Until it reaches some complexity. And when it reaches the complexity, there is a drop and the drop is sudden. You go, it makes some working code and suddenly with just a little bit of added complexity, it drops and you cannot make it do anything more. There is confirmation bias. I asked the LLM to do something, I saw the code, I saw the message because I required the LLM to write a commit message to describe what's done, to describe the code and I expected the code to do what the commit declares so I read the commit, I read a commit message, it looked OK but I didn't check well. I didn't check as thoroughly as I would check if some of my people in my team would do.
This is not in BIRD, this was into my hobbies project.
But the LLM is vast, it generates a lot of code. A lot of commits. And the tests do what you want. You run it, you look at it, it does what you want. No need to record code review, it just works. Why not merge it. Well this works if it's my hobbies project because I don't care whether it crashes or not. It runs on my laptop and that laptop is just doing weird things anyway.
And I'm still checking it for obvious problems like sending data to third parties.
But it then starts to look like this. It just starts putting different things on each other without caring whether the previous feature is kept.
And this is my biggest concern. Are we going to get for, which are going to be claimed to be LLM fortified because I will refuse LLM assisted patches before actually accepting them, before ‑‑ I would refuse the patches if they are crap. But if somebody looks at BIRD as well, there is a bug, let's fix it and let's just publish the fix. How are we going to stop the future where everybody is running their own fork with LLM added fixes and then asking us to help.
So I tried with BIRD, I tried bug fixes BIRD. I asked almighty to LLM to generate a bug fix for a very well defined problem and the problem, the problem was quite easy. And the solution was obvious. On the first side. So it generated the solution, I came up first and it add admission leading commit message, which meant I had to not only do my reasoning completely, I had to do, I had to overcome the misleading commit message and find out that the LLM is wrong.
Bug fixings BIRD, well, it didn't work and this was a trivial fix.
Because most of our bugs need complex thinking. It's not making code which is slow, it's thinking. And when I write code, it's faster than I am thinking. No. I have no idea how to use it. The fix had ten lines.
The fix had ten lines and I had to type a lot of more things just to persuade AI to do what I need.
OK. LLMs are good in making text, aren't they, to ‑‑ so I asked it to make text about BIRD, but as long as you dive into a little niche topic, you find out that the only person who has written anything about this in BIRD was you and the result, which is coming from Claude code, which is coming from ChatGPT, from anything, very creepy early resembles what I have actually written; it just copies my own texts. It gave me nothing more. And if I asked about something which was never written, I just got the crap. No, nothing good.
So I write it, I gave it a set of commits, well give me release notes and the release notes were again looking good on the first sight, then I found some problems and I started fixing them, then I found out that the problems are more deep and then I ended up rewriting it completely.
It took me more time.
No thanks.
So I asked for slides. The slides looked nice. Then I found out that there are subtle mistakes. Then I found out that the LLM is actually right, but in a different way. So I had to rewrite it again and also I had to remove a lot of ad homynyms, that didn't work as well.
So I asked it to load my RFC database to do a review what's relevant and I will shorten it. No. No result at all. So the lessons are the documentation sucks and the topic is obnoxiously complex, the other lessons is I am more susceptible to confirmation bias than I thought. And we should be very much aware that confirmation bias is more of a problem than it looks like.
If you don't think you are susceptible, you are. Yeah, so we do vibe code BIRD, it leads nowhere. Maybe there is somebody who is prompting way better than us, please tell me. And there is also the LLM burn out. Which is coming from push. From all the push. Yeah, I crashed out several weeks ago just because I couldn't buy it any more, it was like LLM is giving us more work than we can do and it takes time, it takes energy, please don't send us crap.
But it tells you, just one more prompt, this is the link promise, just one more prompt. We do not vibecode BIRD.
(APPLAUSE.)
SASHA ROMIJN: Thank you. I am sorry to say that we really do not have time for questions; otherwise, we will overrun. We still have one more lightning talk, and otherwise I would have to bump that. So, yeah, unless you want to stay here throughout the coffee break. But maybe not, but you will be around and thank you for these reflections on LLMs and what it does to us and how we interact with this technology and our own technology as people. We do still have one lightning talk with Robert, I don't know if any of this tool is vibecoded.
Net scope, a network environment debug tool.
ROBERT KISTELEKI: Hello, I am Robert, daytime I am employed by RIPE NCC, this is a hobbies project, not associated with the NCC and I have five minutes, let's do it this. Some of you may have heard about a tool that was called net lieser, it doesn't exist any more, unfortunately. It did good things, it was coded in JAVA, some liked it and some didn't, it did good things in order to determine if there are local network problems right right now when you want to get out to the internet, is everything working fine or not.
But it's gone. It's gone for some sometime now and not everybody liked the fact that it's gone, they tried to ask whether it can be OpenSourced, we can still run it and the people who made this in Berekley politely said no, it's not going to happen. That left a little bit of empty space.
So taking one step back, what is a problem statement. Sometimes we are, we try to connect to the internet and it just doesn't work, something doesn't work. This could happen in a hotel, it could happen on a train, in a conference like this, at home, something is just off, maybe completely doesn't work, maybe some things don't work and you really want to know what the problem is. Now we kind of know what we are doing, we have a lot of tools in your hands, utilities on your Mac and laptop, you can run those tools and you have to know what you are doing and how you start, you have to have a suspicion of what's going wrong and use the tool to verify that.
The idea that I am presenting now is that there could be a tool like Netaliser was that just does everything, tests everything and then tells you what's wrong out of that. Some things work, some things don't work. Netaliser had the side effect they were also with an opt in fashion, they were also collecting results so they got a healthy dose of the network conditions from their users that were running the tool locally.
So introducing net scope, starting at the bottom, naming a hard problem, sorry about that, it is what it is, it's a personal hobbies project, started in 2020, a long time ago, sometimes I spend energy on it, sometimes I don't, it's written in Go, I will not entertain questions why is it not Rust.
It is OpenSource, go there and check it out. The one thing I like about it, at the end of the day, it compiles down to a single binary, just run it and it does everything, including the GUI I will show, all right, so what it does today, if you run it, it discovers these things, whether the local network interfaces with refined, do you have IPv4, V6, where your local DNS resolver do what they are supposed to do, can you ping them, ask them for a DNS query, then it tries to go out and talk to the public open resolver, does the same thing, try to resolve things and see if the expected answer is what is reasonable or not.
Does the same thing for root servers because why not. What I do like is the port filtering, sometimes you are behind a firewall, you don't know it, it does a variety of TCP connections and it sees whether those succed or not. They are not real, they will go against a test machine and the test machine does not run the SSH for example, it just says yes, you succeeded, great.
It does an SSH host key check, it can detect man in the middle for example and it will give you a warning if the key that you expect doesn't come back.
And then various other things. And recently I added IPv6 PM TU checks just because, I had that problem somewhere and it was easy to add. There could be a lot more tests ‑‑ I'm not going to list all of them ‑‑ you can imagine that anything you can do locally with a tool that you have at your hands can be built into such a thing, into such a tool.
I have written it in such a way, it's modular, it's possible to add a task, you need to write a module and then the whole thing just becomes a part of the report.
All right. And then one could write a summariser, it takes all of those tests and says well based on this, I can conclude that your real problem is this and give you a hint how to fix that.
It does have a CLI, most of us like CLIs, if you run it, it spits out a couple of thousand lines of good things and bad things and then there was someone who was asking can you do a GUI so I did, if you run it with minus GUI, it starts up and gives you basically the same controls.
All right. There is no results emission at the moment, it does what it does locally and there's no collection of data of any kind on any server side, there is no summariser, it would be nice to write one. Probably the big egg problem in terms of deployment, there's no app, you can't just go to the app store and say I want it, install it for me, at the moment it's a little bit of a barrier to install it.
But I do supply binaries for Linux an Mac OS, you can run me that.
It's written in Go, it should be easy to run it on Windows but personally I have no access to Windows, I didn't even try to compile it, I am pretty sure it would fail.
So, the reason why I am here is not because I want you to use this tool, I am here because I have been doing this on and off and honestly, it is time to maintain an OpenSource project, as you all know, and I would really like to see if there's any interest in this because based on the answers I might just stop doing it or put more energy into it and I am kind of on the fence which I should do, so that's the story.
I don't think we will entertain questions, but I'm around in the break and after that if you want to talk about it, I am here. Or you can just go there and try it out, that's it. Thank you.
(APPLAUSE.)
Maybe we will entertain questions, your decision.
SASHA ROMIJN: No questions, unfortunately, we are out of time, we have had a very full session, thanks for presenting the tool, I will be trying it next time I run into strange issues, so that concludes our session, thank you to all our speakers and our scribe and other support staff and I have been asked to remind you that the deadline for to register to vote or attend the RIPE NCC CGM is 2pm today, thank you for joining us, I am sure there's more interesting discussions you can have in the hallway with some of our speakers and joining us /HROPBL or in person and we'll see you next time or on the on the mailing list.
Coffee break.