RIPE 83
.
Open Source Working Group
.
Thursday, 25 November
.
14:30 (UTC + 1)
ONDREJ FILIP: Hello, the Open Source Working Group will start in two or three minutes.
.
The Connect Working Group is in the other room, but I recommend you stay here, this is a much better Working Group.
Good morning everyone, this is one the best Working Groups that you can see during the RIPE meeting, this is Open Source Working Group. Again a reminder for those who are interested in Connect Working Group, that's in another room, so, if you are interested in that topic, please go to the other room.
I am Ondrej Filip and I am here with Martin Winter, we are co‑Chairs of this Working Group.
Let me present the agenda.
Of course housekeeping first. You know, I think after a few days and fourth virtual meeting you know Meetecho very well but just a reminder, you can either ask your questions in a Q&A sections or you can request audio and video if you are interested. You can use the chat but the chat is not modern so if you have really a question, please use the Q&A section. And of course the session is recorded, and we all expect you to fully comply with the common rules of discussion and normal behaviour rules. So, that's for the housekeeping.
I will give the floor to Martin and he'll introduce the agenda.
MARTIN WINTER: Okay. So we have a bunch of interesting talks, so first of all the minutes from the previous Working Groups, they were mailed out, they were actually posted, I hope the ones who are interested got them, those who missed it I suggest you go and read them.
Action list. I don't think we had anything. We had this Working Group Chair re‑election just after, myself and Ondrej were standing, but as we had a spot for a third one, we are happy to announce that Marcos Sanz wanted to become a what I remember and we were happy to elect him, there will be three Working Group Chairs starting from the next RIPE meeting, on the Chair officially starts at the end of the RIPE meeting.
And he will talk a little bit at the end of it.
Then from the talk, we have first a talk from Ondrej from the RIPE NCC, by the virtual IPv6 security lab environment. N
.
Then we go on from the looking glass, we have Annika, the looking glass which works with multiple BGP backends. Then we are building the modern TCP stack on the high performance network layer on Linux basically, it's a kind of a something to some of the other like extensions for like high speed data performance.
And as I mentioned before, we will introduce Marco Sanz as an additional Working Group Chair.
With that basically let's go back and not waste much time. We had one quick comment from Kurt Kayser, I just want to bring that up, he said like:
"Just to comment beforehand, many people are afraid to use open source due to unclear licence rules. It will tell ‑‑ it will help to tell about this, or I suggest that whenever, like, the talks, are if there is specific licensing, please mention that, that's mainly for the speakers. Otherwise maybe that will be an interesting talk for the future, in a future RIPE if somebody wants to talk about some of these issues and problems."
And with that, let's and over to Ondrej from the RIPE.
ONDREJ CALETKA: Hello everyone, I am not sure whether you can see me. I tried to turn on my camera, but of course after so many tests, it doesn't work at the moment hen it should.
So let me try to change the devices. That's embarrassing. Now no, that's embarrassing. Okay, I will unplug the camera that I use and maybe it will start working.
ONDREJ FILIP: At least we can see your picture Ondrej, it's no so bad.
ONDREJ CALETKA: It's almost better to see the picture, but still...
ONDREJ FILIP: I didn't want to say that.
ONDREJ CALETKA: Let me refresh my browser window, so I will be there in a minute.
.
I am back, hello. So, we can start and now my talk is here. Okay. Hello everybody. Welcome to my talk which I will introduce the virtual IPv6 security lab environment that I have been working on the past month, let's say.
First of all, let me quickly introduce this department of RIPE NCC called learning and development which maybe you are familiar under its old name which was training services of RIPE NCC, because it started providing mostly face‑to‑face trainings to LIRs, to our members, and we still do these face‑to‑face trainings but of course we suspended them due to Covid‑19 and last year, and we haven't restarted them yet. But we also did other things, and that's why we are now learning and development. Mostly we do webinars which are live interactive sessions similar to what everybody now does because of Covid, but we did it before it was cool. And so we now have one or two hour long webinars, which are live always and then we always have a ways that you can learn yourself, so we have RIPE NCC Academy, which is an e‑learning platform which is accessible to completely everyone, and anyone can use it for learning themselves in their own pace, and with this, academy, if you get the skills, well if you need the skills either way, you can now get certified on the that for we have this programme called RIPE NCC certified professionals where you actually prove your skills by doing an online proctored exam and then you get a badge and you also get some T‑shirts like this one I'm wearing, and things like that. So you can actually get certified that you know the stuff, how the RIPE NCC works and that you now how IPv6 security works and things like that.
And our latest addition to this portfolio was actually IPv6 security e‑learning course, we only had IPv6 security face‑to‑face training and webinars, and now we also made an e‑learning course, and for that e‑learning course it's always good if you can actually ‑‑ if it's not just reading, but it's always like you can actually practice yourself and do some examples, try it yourself, have some hands‑on. And for that, and for this course, the new thing that I am actually presenting now is that we have such a thing and we have hands‑on lab environment that anybody can download and install and then play with it. On this picture you actually see the map of the environment, so it's very simple in this way.
Basically three computers running Linux, connected to one network segment, where IPv6 is deployed, it's not the real IPv6, it's just like demo, and there are lots of tools for trying different, let's say, attack scenarios and protecting against them, and similar things.
There was this thing: How to do it in this RIPE NCC academy if it's like open to anybody, that means that anybody can use it and delivering to the labs for literary anybody is something that gets a little bit challenging because it should be ‑‑ there shouldn't be a hard limit of how many users can concurrently run the labs and because we are offering it for free, it should not cost us too much money. It can cost some money but not too much, and we also would like to offer people a solution that they can play as long as they like to. So, nothing like time limited. And also it should be easy to use.
So out of all these requirements, we decided to give a try to deliver virtual machine image, so basically computers are now very powerful, so the idea was that you download a virtual machine image, this virtual machine image will help you ‑‑ you will run on your computer in your own time, as long as you wish.
But of course, it does have its sort of challenges. First of all, that we have like three major platforms, Windows, Mac OS and Linux. All of them support virtualisation but there is no ‑‑ the virtualisation technology is different on every single platform and the only common solution is Oracle built a tool box which is a little bit not the best thing I would say but at least it's on all three platforms and looks similar.
The other thing with virtual machine is that if you run virtual machine you always have problems with scene resolution rand keyboard level because there is no uniform screen resolution and universal keyboard layout and if you are used to a keyboard and you now are presented with a QWERTY keyboard, it has some issues, so we are solving this issue by delivering headless virtual machine that only works via web interface, so you basically use your own web browser to access the lab running in the virtual machine.
And the third problem that is, we are facing is that deploying a virtual machine image is hard. For that we are utilising another tool called Vagrant.
So how does this thing actually work? If you want to run this labs, you of course have precise how to do it, which is part of the RIPE NCC academy, so if you follow the IPv6 security course in RIPE NCC academy, you will actually get like six hands‑on tutorials and the first one is actually install the lab environment. So what you have to do, you have to install VirtualBox and install Vagrant, these are like readily available tools for all three major platforms, and then basically what you do is you open your terminal and type those two commands that are on the slides. After a minute or two, after it downloads it, and you run it, you will get a local host on port 8080. You will get the lab environment which you can use in your web browser and there are basically consoles of three virtual machines and those machines come with pre‑installed tools that are taught in the RIPE NCC academy course, so you basically just use those tools, let's say attack each other maybe in those computers or also protect against some attacks, and you can try that you put there the protection and whether the protection works or not. So I think it's pretty, like ‑‑ even though it's not something very advanced, it's basically three Linux computers connected on one network, you can actually play a lot with that and we tried to offer lots of space for playing with that.
If you look under the hood, how everything works, it's based on open source. It's based on Ubuntu 20.04 L T S base image and to deliver those three virtual computers that you play with we actually use containers by LXD, that's like something that is native for Ubuntu.
Then we pre‑install all the tools there, and to make the consoles easily accessible via the web interface we use ttyd, which is a small web server, and lots of JavaScript that makes the Linux terminal accessible over a WebSocket and in order to be able to, you know, because http is not stateful protocol, so in order not to lose your state when you refresh the browser, there is DMAX which is actually multiplexing several connections to the same screen from different browser Windows.
There is also some static web page around it to make it nicer which is served by NGNIX. And everything is put together using Ansible and the Ansible play books, together with background file, everything is publicly developed and publicly accessible on the the RIPE NCC GitHub account. You can look how it works, you can use it as a base for other, for other projects similar, I am definitely going to use it as a base project for other labs for other E learnings and so on.
Then maybe I am just like ‑‑ yeah, there is also a Labs article which I went a little bit deeper into how the things work, but I'm not going to talk about it here.
What I'm going to talk about is one particular thing that I figured out and that may be interesting like completely outside of this topic and is that we have a lab about ICMP v6 and how they can easily abused if you are on the same segment to do some man in the middle and stuff like that. It turned out that our lab worked very well with Linux kernel 4.17 or lower, but from version 4.18 it didn't work. Linux, in 4.18, seems to ignore ICMP no matter how you set it up. It is, at least with Ubuntu, also turned out if you actually use kernel level auto configuration, so the default things if you just kernel and just turn on another interface and it will configure itself for IPv6, it works, but this is not how the distributions are operating, they usually use some user space management in order to set up also things like DNS. So for instance, if you want to use a ‑‑ but the same story with DHCP CD, and with those daemons running, the redirects are not accepted any more, which is pretty strange. I tried to report it to Linux kernel developers, but unfortunately I failed to make a simple enough test that would fail that would prove that something is wrong there. And after all, you know, they are not recommended. Most people don't need it so nobody noticed there is such a feature, let's say of Linux kernel.
So, four or lab environment we need them, so actually what I did was I reverted to the external level auto configuration which works.
That's basically it. Of course, we would like to have something back from users, whether they find this environment like working or whether they have some issues with installing or running it. Whether there is ‑‑ whether like it's a viable way or we should scrap it and do something else, like some Cloud based labs and things like that. We are also going to have an open house on labs on 8th December, so feel free to join if you are interested in this topic. And yeah, the future plans would be for other labs, we will not use only Linux but we would like to have also some working gear which is now already available as containers, so it should be doable, but there may be some licence issues which I haven't looked through yet. So, I'm not sure whether it would work like this.
Anyway, get this also as an invitation to our why you IPv6 security e‑learning course which is accessible on academy [at] ripe [dot] net.
And with that, I would be happy to accept any questions.
ONDREJ FILIP: Thank you very much Ondrej. I like the approach that everything is on GitHub, so everybody can use it. Do we have any questions? Or comments? Or whatever, remarks?
.
Brent Carr asks ‑‑ Brent. I will allow you...
.
BRENT CARR: Sorry for the delay there. Ondrej this is really good. I don't really have a question, more an encouragement. This is really good work. It's nice to see the technology you are using as well, I think this is really good. I think my only ‑‑ I think the only concern I have got slightly is that, and some people have mentioned this in a chat as well that some of this won't work on newer Macintoshes with armed CPUs. If you are going to use one macs you are not going to be able to run VirtualBox. Maybe you can vet Vagrant connected up to VMware fusion on an M1 Mac, or something like that. Maybe it's doable but it's not going to work as easily as others.
ONDREJ CALETKA: Yeah, thank you for that comment. Yeah, of course, this is something, as long as current computers will start being X86 based, doing virtualalisation will be much worse, but in the end, yes, the idea is here, like everything we do is actually open source and the address amendment for different architecture for instance shouldn't be that hard. The problem is that yes, somebody has to do it and somebody has to maintain all the versions. So we are not doing now because I'm not capable of maintaining everything, but if it turns out that there is like significant user group that would use this, yeah, we can try to put it. It should be easy job, but it would need some work.
SPEAKER: That's the beauty of open source, right?
ONDREJ CALETKA: Exactly.
ONDREJ FILIP: Thank you very much for this comment. I do not see any other comments. So thank you very much Ondrej, thank you.
And I would like to ask Annika to join. Annika Hannig from DE‑CIX and she will speak about the looking glass, so Annika.
ANNIKA HANNIG: Hi. So, let me quickly grab my slides. Welcome to my talk. I am Annika, I am a freelance software developer. I write mostly open source stuff, but I work for Internet exchanges, mostly in Europe, like for example, DE‑CIX, and yeah, one of the things I do is writing an open source looking glass. It's called "Alice" and I am doing this for well five years now, and I'm going to talk a bit about this.
So, this is Alice. Well not really. But she has a new dress since this year, but you are not here to talk about this, you are here to talk about the looking glass which is this one.
All right. So, what is a looking glass? A looking glass is basically a small tool you can run on your servers to present a way to your, for example, customers, to reflect on the current state of your route servers you are having and show routes, so prefixes, show the neighbours on the route servers and show maybe why a specific prefix was rejected because, for example, some filtering mechanism just rejected it.
All right. So, a little bit of history. It was like ten RIPE ago, at the RIPE 73 hackathon in Madrid that we started this little project, Barry O'Donovan, back in the days, pitched a small idea for providing a small HTTP interface for Bird, for actually getting information out of this, and coincidentally, a couple of days prior to this, I was ‑‑ I was approached by a copy worker and we had a look at our looking glass. I was working at ECIX back then, and I saw the old looking glass and I thought well, sometimes well, sometimes things ‑‑ yeah, sometimes things crash and so on. But yeah...
.
And so there was a hackathon and we were then thinking yeah, okay, let's do this, and after a short two days of hacking, Barry managed to come up with HTTP API for the Bird route server, and at the same time, I build the Birds Eye looking glass, because yeah, we called the entire project Birds Eye. However, well as captain Birds Eye turns out to be a bit of already taken registered trademark, we later decided to rebrand this.
But yeah, back then, at ECIX we did presented this to my colleagues, Stefan, and we had a good look at the source and I involved a colleague of mine, Fitella, and we ported the initial version of the source of the API from PHP to Go, and this is now living as the Bird watcher.
Well obviously, we changed the name to Alice, and this is what it's now called.
Okay. Some technical stuff.
Alice is built quite modular, and you have ‑‑ you can put in various kind of backends there, for example Bird, Bird 2, open BGP, since recently, and go BGP, they are right now supported. It's basically built as a small application providing a backend, where the application is consuming this backend and rendering everything so it's easy to use for example in scripts and so on. It's open source. Check it all on GitHub and yeah, please contribute.
So a bit about the architecture.
.
As you might know well, it's route servers, route servers connecting route servers directly to the Internet might be not the best thing to do. So it's a bit like okay, there is always something between like for example the Bird watcher actually interacting with the routing daemon, or for example, a go BGP looking glass daemon providing or serving for example in the case of open BGP the structured output directly.
Features:
.
What can you expect when you are using Alice? So, one thing I'm quite proud of is, you can turn this pretty much into this. So, it's completely themeable, and you can nicely integrate your corporate CI, and other cool features are for example, related peers, you can see for example what your inspecting a particular neighbour, and this neighbour is present on other route servers you are having, you will see this related peer directly as a tab there. You can ‑‑ you have a nice visualisation for example for best route and for example this route is blackholed and so on. And of course, our BGP communities are human readable and can be colourised and so on, but yeah, these are all the things I think you already know if you have already seen the looking glass at some point. Maybe you have. It's adopted through ‑‑ it's adopted widely throughout the Internet exchange bubble worldwide. And, yeah, what pretty much happened during the last two years.
Well, this doesn't look impressive but bear with me for a second. So, GBGP support was improved. I added a timeout. Bug fixes were introduced. Well the IRR link to the IRR explorer were broken and well then I fixed. Bird 2 support was improved. I added another timeout, but not only that, also the main table is now configurable.
But there is more!
.
Well, when you are working as long as I did on open source project and sometimes well an open source starts a bit smaller and then it grows over the years, all of a sudden you are ending up having a repository where you pretty much have everything in a single folder and not really good structure, and so I spent quite some time actually doing some maintenance work and refactoring this victim of entropy a bit to a modern project structure including GitHub work flows and having a dedicated command and everything is now nicely structured in packages and so on.
.
Speaking of GitHub work flows, I see Alice was added so right now you can use your favourite containering tool to pull Alice and run it, and as I already mentioned, open BGPd was introduced add a feature at the backend and I really have to thank the route server support foundation for supporting me with this feature and sponsoring this feature.
So now we have not only Bird at the backend, go BGP at the backend, also we can use open BGPd, which is nice.
But yeah, what's next? What am I working on right now? Let's have a short look at this maybe.
So, as I already said, it's a 5 year old code base and some ideas just did the age that well. And I already spent the last I think three weeks on and off always sometimes in the evenings sitting on my couch, ah well, let's go over the source code, let's run static check and let's fix it. Well the language has morphed. We don't write Go like we did five years ago, and so well, yeah, we fixed ‑‑ there were quite a lot of things to fix. Also, for example also, for example, you learn things. This is an example where I learned quite a lot of things, for example, in the old version, I had a lookup route which was basically a copy of a normal route just with additional information about the neighbour, where the route was announced from, and the route server, the route is present on. And the first naive implementation I thought okay, how do I exchange between these routes? But then I learned something across the last five years or so, namely that you can actually use composition in go and all of a sudden this code just boils down to a much more nicely readable version.
These are, like, tonnes of this right now going on, and one of the things is I'm doing a complete overhaul right now. Internal state and the internal caching of for example routes and neighbours. So, I abstracted it all right now, and right now I am rewriting this to reflect ‑‑ or to first, use a parallel refreshing strategy, and I separated the storage of the routes from the accessing and refresh of routes and neighbours. So, yeah, this allows me to introduce in the next step that I can introduce a pulse egress or some other backend for actually keeping this application stage which should alleviate two pains which are ‑‑ well if you are running a large instillation with a lot of route servers, you might run into the problem that well a crash recovery will take a while until all the routes are present there again in the store. This will be no longer a problem, and the memory fingerprint especially with large installations is a lot.
Moving the application state out of the memory and into some application actually designed for holding state like, of course the database should alleviate this.
And plans for next year are pretty much taking this, taking a good look at the client application, because, well what I added was primarily migrating a five‑year old old code base into the future and moving ‑‑ and did tonnes of refactoring, but the world in JavaScript land didn't sleep and nowadays writing react applications is a completely different thing like you did for example five years ago. Five years ago doing your state handling with ReadOx was all the rage, but nowadays, you come so far with just react hooks and have so much more cleaner code base, so next year all the classes based components will be gone they can be replaced by a pure functional react front end, and this should already ‑‑ and I hope I can win with some the patentses. Yeah, these are kind of my plans for Alice and the next coming years and the next year pretty much.
Okay. Please check it out. If you have any questions, feel free to ask. I am a bit ahead of time I think, but all good. Right. Are there any questions?
MARTIN WINTER: There are a few questions. Let me read them out. The first question came from Gordon, Gidofalvy from Tucows; he asks: "Is the Alice looking glass specifically made for use in IXPs?"
ANNIKA HANNIG: Well, it's not. You can use it whenever you are using a routing daemon like for example Bird and open BGP and so on. It's not especially built ‑‑ the thing is, it's primarily used by IXPs and so focus on IXP functionality like for example this related peer trend and so on are ‑‑ well may be something which which are not required in other constellations, but yeah...
MARTIN WINTER: I think the second question goes if the same direction from Dirk Myer:
"Can it be used to monitor border routers instead of route servers?"
I think the answer is what you use for the border router, what daemon.
ANNIKA HANNIG: Exactly. If you are using Bird for your edge or for your border router, then you should be good. If you are using a Cisco or Juniper, well, no worries, just create a source, create a fork and create a pull request and it will be merged.
MARTIN WINTER: Okay. Then we have a question from Vasilis:
"It seems that it is hard to find available looking glass servers. Is there a place or can Alice looking glass API help to find up to date looking glass servers?"
ANNIKA HANNIG: Em... so, it's not a universal looking glass. So, it's just providing the looking glass information, or the prefixes and route information for a single IX or a couple of IXs but it's not meant as a single source of ‑‑ okay, you can go here for occurring for example AMS‑IX links, DE‑CIX and so on, which would be a nice project though, but it's not a meta‑looking glass in that sense. Maybe ‑‑ or maybe I didn't get your question correctly.
MARTIN WINTER: Okay. Then we have another question from Vesna From the RIPE NCC:
"What kind of contribution, help or support from do you need from the community?"
ANNIKA HANNIG: All right. So, I always love to see when there is participation, and participation in the project has gone up. Yeah, what do we need? Of course, seeing pull requests is always a good thing. I really love to get together again at some hackathon hopefully and maybe work together with other people on this and have a nice community meet up again at some event, and maybe we can see each other sometimes in person. But, other than that, no, the project is funded and it's going very well, and yeah, but I am always looking for contributions. I hope I could lower the entry barrier a bit by modernising the layout and make this containerable and so on. But yeah...
MARTIN WINTER: Okay. Thank you very much for your talk.
ANNIKA HANNIG: All right. Thank you.
MARTIN WINTER: Okay. Next speaker up is Libor Peltan. He is talking about a building modern TCP stack.
LIBOR PELTAN: I am CZ.NIC, the Czech national domain registry, and I am the developer of authoritative DNS server, open source implementation. For those who are interested, it's to build ‑‑ and today, I will talk about XDP again because I have already did it at other meetings, but the novelty here is that for the first time I will talk about XDP with connection on it TCP protocol.
But, yeah, I will talk about all of these in connection with our DNS server, but I hope there are somehow useful also in general for other kinds of networking daemons and applications.
So, let me start with the introduction by what is XDP. XDP is new technology which is separated by recently Linux concerns and this allows to filter the incoming traffic and the selected part of the traffic for example in case of a DNS server it will be the DNS affected arrives on port 53, and the cited traffic will then bypass the Linux kernel processing completely, and will go from the wire directly to the user's base application, so in our case, the DNS server.
This is good for performance, because this way there are packet processing doesn't stand in the way, and the application, the server do it directly answer all the queries. There is some interesting consequences like anything that is in the kernel, waiting for the traffic, will not see this part of the traffic. Association some traffic noises, or some advanced routing tools will not see this traffic at all.
So, this technology was not designed primary for DNS, but it appeared that it's a good match for DNS over UDP for the simplest way of DNS, because for DNS over UDP there are high numbers of small packets and the packet processing overheads in the Linux can now take ‑‑ takes much time, so bypassing this kernel is really useful for DNS over UDP. So we implemented this in DNS Knot DNS 3.0, more than a year ago, I think it was a bit sexist. It has improved several times, at least according to our own measurements and for independent measurements, I heard that there will be a talk next week about an independent measurements of the improved platform with XDP. So I am looking for to that.
And since the version 3.0, we made only some small improvements like reroute slightly routing in connection with this XDP.
So, when this DNS over UDP process was a success, we decided that the next step was to try the same for DNS over TCP. So the first motivation was research, and experimentation, we wanted to try and see if there was there any ‑‑ or if it's viable at all or if the performance was affected. But we had a motivation for longer term usage of DNS over TCP over XDP because we struggled with the performance of TCP as such. It's not that TCP stacking can never be slow, it's pretty robust and it's wonderful, but for the specific DNS traffic where each TCP connection transfers just very little data, the kernel is not optimised this way.
.
Like the slow loris on this is ‑‑ because as you know in Linux kernel, whenever you have a TCP connection, you a final step is created for this and creating the final step is an ex IPv operation and it is unit multi‑threaded application because there is some mew telecommunications that locks each type a value carry is created and this really hurts.
And also saw that for the, our implementation sitting on top of
.
Can be better in mitigating slow loris attacks and DDoS attacks. And we need better security and performance of TCP for increasing use of DNS over TCP in general. It's because increasing is of the DNSSEC and the reflect reflecting the size of the data that fits in the UDP packet.
My personal idea is that also I have no, ma'am concerns in the DNS community that we are not able to switch from using DNS over UDP whatsoever, because the servers will not be capable to handle other TCP connection. For example, the route servers have many numbers of requests, and for DNS over UDP this is okay but if all those requests came across TCP, then they may have some difficulties. But I think that powerful enough TCP stack, this argument can be withdrawn, and some features for example DNS cookies that makes sense only for UDP could be withdrawn for the future as well.
So, we decided in the end to indeed implement some TCP stack for DNS over TCP over XDP, and to re‑look on existing open source DNS stakes around I W TCP if they are usable but it showed they are mostly designed for IoT and the API is suitable for operating with the kernel itself or with specific device diverse but not with XDP unfortunately. So we decided to implement one more TCP stake ourselves which would be designed with DNS specifics in mind and it will also have the diversity because well obviously the Internet is running almost exclusively on just Linux kernels, right.
So we implemented something the TCP stack is implemented to some degree, but it showed that it's not so simple like that. It's not only ever parsing the TCP had accumulated options and implementation the hand shakes of the stake machine. But the TCP has many kernels. For example, when designing, we had to take careful design decisions about connection stability, because the requirements recommend often require that the server shall try hard to keep any connection alive. This means it shall store some incomplete received data in some pathways, or some unacknowledged sent data and resend them occasionally, and this all takes memory, but the kernel can use this send as affects surface when he triggers the server to start many many data into buffers, and he takes memory. So one should care about the design of the TCP stack so that it's ‑‑ that it's safe, secure, but it's working in general.
So, we implemented some limitations. Some of them are temporary. And some of them are more permanent. For example, the limitation of current implementation is there is no congestion control at all. For DNS over TCP we are not sending any important amount of data, so, this doesn't care at all. The only thing is its own transfer for router zones, congestion control would be necessary.
We also, for now, do not receive out of order packets. We consider them lost because it's easier, but this can be improved in the future. And we do not perform path MTU discovery, because by examining closed packets it's not viable for short‑lived connection by DNS over TCP, and for ‑‑ and by using ICMP, it has many other security issues and it is difficult to make it safe and solid.
So, we implemented TCP stack, but it's already clear which like general properties it will have. It is not yet so much company that it's safe and usable in any conditions. But it already can be measured. So, we measured the performance of this stack in our conditions. And the first test case was simply open the connection and query and receive the answer and close the connection. And this way our XDP implementation was roughly ten times faster than the conventional Linux stack.
For the normal SYN attack, it was just a little bit faster, but still okay.
And the third test case was incomplete query, where we opened the connection, send a query, but with the last bit missing so that the server has to stall this incomplete query and the first time it times out and for our state, it was constantly managed to receive 2 million of such incomplete queries per second, and for the conventional TCP it was difficult to measure because the figures differed. So unfortunately I am not able to provide exact numbers, but in any case, they were 1 or 2 magnitudes over.
And one of the good outcomes of this work and project is also the kxpdgun tool, which is the debugging measuring tool it's using the same routers that the server uses for communication or XDP. And obviously with this TCP functional, it's also complements a TCP stack so it's able to creat DNS over TCP traffic and measure how the server is able to answer it and imwhat rate and also has some advanced options for performing query attacks. So for example the SYN attacks and the denial of service attacks and DDoS attacks that try to deplete the memory.
So in this case the tool is ready to use in general, maybe also with internal implementations and other co‑locations of DNS servers. And let me conclude with the few into the future. So our requirements are to finish this work. We have already released some working TCP stack in DNS 3.1. But we are going to release much better and improved version in 3.2 next year. And after that, it will obviously, we need to keep managing it and see slight improvements but I think the 3.2 will be the last one in this area. And we also need to find some users, for example there were some that were concerned about slow loris attacks and DDoS attacks who are already using XDP over ‑‑ ‑‑ they might be already turn on TCP for them, it's easy, just a few configuration options.
And maybe most important thing is that we can use all those versions for future DNS over QUIC implementation of the XDP which might be for the future. One of the killer features of NAT DNS. So that's it. I welcome any questions.
ONDREJ FILIP: Thank you very much. I think we have one question from Vesna. Let me read it.
"Can you point to some links where I can learn more or would you write about this for RIPE Labs? Thanks."
LIBOR PELTAN: We are not yet written any articles about this DNS over TCP over XDP because it's very fresh and it's not completely finished yet, but we will definitely in the future. So far there are just articles about DNS over UDP over XDP and they are easily readable, I hope. So, please wait for the feature and you can definitely read more about this.
ONDREJ FILIP: Thank you so much. I see one more question from Benno.
BENNO OVEREINDER: Thank you. Thank you very much for this interesting presentation. Also, kind of answer to Vesna, so, in the past year, William Tor low and Tom occur pie also did some work on XDP with DNS, not specific for a DNS server, so it was kind of annotating or ‑‑ kind of annotating a DNS server XDP, so what Tom, Luuk and William did is kind of implementing XDP functionality or DNS functionality in XDP to track cookies for example, or to do response time. So actually do some work for the DNS server. And that was also quite successful. So then you have some kind of generic framework you can put in front of a name server like our own NSD or knot of course. I think it's been published as a RIPE Labs article also, or an APNIC Labs. But it's very interesting technology and NL labs will also look into using this technology in our software. Thank you very much. Very inspiring.
ONDREJ FILIP: Thank you Benno. So we can look forward to some future presentation from you.
BENNO OVEREINDER: Yes, you can put us on the list.
ONDREJ FILIP: Okay. Excellent. And we are going to the close of the meeting so I apologise I need to cut the mic queue off. Thank you very much Libor, and we have one more point which is the introduction of a new co‑chair, Martin, we want to ‑‑
MARTIN WINTER: Yes, we have an election of Chairs, we have a maximum of three and we are happy that Marcos was interested to become the new Chair, so that will be at least ‑‑ the idea there will be three Chairs and then next year there is another election again. And with that, I want to give over to Marcos he can introduce himself and maybe bring up a few ideas and stuff.
MARCOS SANZ: Thank you very much. I really don't want to take much longer because we are already over time. My name is Marcos Sanz, I am 45 years old I am an engineer at heart and I work at head of software at DE‑CIX. And when Martin and on the Rye asked me why I was stepping up, then I answered that I wanted to give back to the community by serving. And so I started numerating open source products that I have been working in the past, and then I went to the first one and it was like a failure because it didn't fly and I went through the second one, and that really didn't take off, and then I went to the third one, and then it started downing on me like I am a failure with open source. Okay, that I break everything that I touch is some kind of anti Midas spell, and then started feeling blue and crying and then Martin came and said Marcos, you are learning so much from failures and then you really can do it better.
And then, yeah, he cheered me up a bit and I thought okay, I think I am going to do it, okay. With my current employer, I also support open source projects. And they have already been presented here at the RIPE and they will try keeping you up to date with those projects. But I'm certainly not here to talk about my products or the products of my employer, I am here to help Ondrej and to help Martin because they have done a magnificent any of sent job, and I want to bring my energy, my chairing expertise, and I want to foster development of open source, usage of open source, discussion, giving feedback to developers to help them guide their projects, especially those projects that are relevant to the RIPE community.
And while I talk a lot about failures, open source failures in the beginning, the question stands: What makes an open source project successful? And I think it has an easy answer. I think it's when good software meets real needs of users. And I think this Working Group is the meeting room for both of these to meet, and for this to happen.
And yeah, it's a pleasure to serve. It's an honour to serve. And that's it. Thank you for listening.
MARTIN WINTER: Okay. If there are any questions to Marcos or any of us about that whole thing, you have a few seconds to speak up. Otherwise we are basically done. Again, we welcome Marcos, it will be interesting one more person with contacts who have may have good ideas and what makes a successful open source project, like I say the first thing is a community who basically supports it.
ONDREJ FILIP: I don't see any questions, so I think with that, we can close our session. Thank you very much. We had more than 200 participants, so that's a great attendance. Thank you very much. And fingers crossed that, you know, next time we could be able to make it at least hybrid if not completely physical, because we can see that encouraging people to present through video is much more complicated than encouraging or asking them to speak on stage. So let's hope we will be able to meet, it would be perfect. Thank you so much. And see you next time.
.
MARTIN WINTER: Thank you everyone.
(Coffee break)
