Closing Plenary
28 October 2022
At 11 a.m.:
.
STENOGRAPHER: On the home stretch!
FRANZISKA LICHTBLAU: Would people please start finding their seats. We would like to get this started.
DIMITRY KOHMANYUK: This is a first talk.
EMIL KOSVIC: First of all, it's an honour to be here to present to you. My name is Emil Kosic, I am from Croatia, and I will be presenting to you today a short overview of the Linux build systems and, at the end, I will talk about the replica 1, so the replica 1 is an open source system that we developed in‑house, and that helps us to build firmware for our customers and to share it with the community. So we can now continue.
So, we can start with the ‑‑ we are at a network conference, we start with explaining how the Linux firmware is being built, so this is a general idea of the firmware image based build system, so if we take a consideration of any embedded device, either used for networking or used for any embeddable purpose, there are generally a few steps that we need to follow in order to build a functions firmware image, so obviously we're working with open source projects, so, the first thing we'll need to have is the, either to generate a tool chain, a tool chain is a sort of a set of tools, set of compilers for building for the target platform. So if we have, let's say, a network switch, and we want to build a firmware image for that switch, first, we would have to either work with the SOC provider, either the SOC developer are or we would have to pick one that already exists. The tool chain comes in in many form factors, there are open source tool chains, there are cross‑compiled tool chains and the first step is to obtain that tool chain, and then when we have the tool chain, we can proceed and build either our own software or the open source software or the Linux kernel, maybe add in a boot loader of some sorts, and then we we compile all the packages, either open source packages or the ‑‑ our cast and build software in‑house and the Linux kernel and other utilities, if we choose to do so, we can integrate those into the firmware image. And then the firmware image is ready for flashing on to a network switch, for example.
Well, there are some examples of a firmware build systems that are used today. I am sure all of you have heard about Gentoo, for example, or Buildroot, so these are systems that are actually pretty built in, into the community, and they are being used as the primary open source sort of an open source sources for building firmware. However, there are many problems with them. They are good for, let's say, general purpose building. There are problems which I will mention in the next slide. There are many problems related to the compatibility issues and the existing platform compatibilities and actually the limitations of them, which I will explain next.
So this is actually the image representation of the ‑‑ so you can understand the last slide better, the process of making a firmware image. The Linux kernel is, let's say, the main part. So, some generic Linux distribution and the Linux kernel are actually the platforms that we build on, and are actually used in so much devices that I don't ‑‑ there are other platforms besides Linux. However, the Linux actually is the best example why we need open source communities, and why we need to actually develop and contribute to the open source ‑‑ the upstream projects, especially for the embedded world.
So if you see ‑‑ we have mentioned before that after we generate this so‑called tool chain, this tool chain is actually a set of compilers and tools, so it's actually an SDK of some sort so help us build further and build our own software that we either made in‑house or to build other open source software that we pulled from community repositories or similar.
The configuration is actually a pain point for many existing build systems that I mentioned, some of them being the Yocta [phonetic] project, the BitBake and embedded, open embedded, the configuration is the pain point and the point that where usually the development stops or slows down in the process of developing consistent firmware images for your devices, for your customers.
We have explained this before, so we have the tool chain, we build the Linux kernel, and we build our packages, either they are open source or they are our in‑house build packages like, maybe some custom management systems, etc., such as my company develops. And integrate all of that into a firmware image and put it on a switch, on a router, on a Cloud switch or anything in between, a wireless access point and a server, even.
So, when we talk about the open source build system, we usually don't go much into the proprietary sphere of things. We used to use a, let's say, indoors developed patches for the Linux kernel and then patch things that we needed on our hardware. However, we strongly discourage the use of our own build trees on our own GIT trees and the patches because we diverse so much from the mainline, let's say, Linux kernel code, that we simply can't keep up with the latest changes in the kernel because we have diverged so much we can't go back, at least not easily go back.
So, one thing to note is that companies do tend to use open source build systems, and then integrate their own software into it. So, if you were developing a management software in‑house, and then you are trying to integrate that into your firmware image, so for example, you would have a wireless access point and you would like to incorporate your C programme into the firmware, there is actually ‑‑ you have to build it yourself and then somehow incorporate it into the image. However, our open source build system circumvents that in a way that I will explain later.
One thing to note here, when using open source as the backbone of your firmware build system and your firmware image, you are actually benefiting from all the communities, so all the Linux distros, all the Linux packages, all the routing and switching software, you are actually benefiting because you are using well‑proven code that was proven to be a reliable and secure that is developed by many, many people. So that is actually a well suited backbone to build any kind of a build system and firmware image for your devices, even if those are your turbo proprietary hardware, it is to have such things as open source backbone, open source build system for your firmware.
Some of the challenges I already mentioned before is, for example, diverging from the branch that you used to fork from, let's say, Linux kernel. So, if you develop your own drivers firmware and other software in‑house, you might actually diverge from the mainline or the upstream of the kernel so much that you just have to break at some point and continue to fork something that is more mainline, more upstream, and then continue from there. That usually breaks a lot of things that is your versions jump very often. That is actually the main reason why we want to keep to the open source upstream as much as possible, and still develop our own value added features, sort of like management software and similar.
Another issue with the embedded, I will say embedded firmware world is hardware incompatibility. So, how do cover as much ‑‑ as many devices as you can by using one build system and using it, let's say, in a programmable manner. So the smallest portion that you would have to consider, let's say, custom, is your own software, your own in‑house produced software, and everything else, from the drivers, from the Board support, from the firmware build system, should be mainline open source, because then you ensure that you have as little possibility to make a mistake, because you are developing only your own. You are not developing some ‑‑ I mean, you could develop your own kernel driver or kernel module, but keep everything else, keep the largest part of it open source, because this is not a team of ten people, this is a team of thousands of people. So, they are less likely to make a mistake and keep it there, than your own company or your own team.
As I mentioned, Linux distros are also a pain point, because many Linux distros have their own configurations, and their own build flags, their own C flags etc. So, because communities like to do it their own way, of course. This is not actually a big problem because you can keep a configuration fork in your own GIT repo and just edit as we go. But it would be nice to have also an open source version of let's say support for many known SOCs or boards or hardware, so we would like to benefit as much as possible from all these smart people from the open source community, and use as much as of their guidance as we can so we as a company only give this added value as our own management software, our own Cloud, something like that. So we'll leave the important things, let's say ‑‑ let's call them important things, the backbone things, we'll leave them to the people that are in the community for over ten years. We just have to trust them because their support is huge either on the boards, either on the embedded side, either on the kernel side or the Linux custom software side. So we kind of have to work with them and use as much as we can from them, to avoid these issues of course.
There is actually a funny story with Sartura, we are a company from Croatia. We started off by developing firmware images and supporting some wireless access points. So this is the company that was providing software for some of the known access points. We had an attempt, I would call it, to become an Internet service provider. However we needed a build platform that would be used to build firmware, one firmware, one firmware build platform to use to build firmware for all of our devices, so switches, core rows, access points, etc., so we wanted to not diverge into the having multiple build systems but to have one build system, and to use it, to actually one build system that is consistent and we just have to develop our own software, our own management software and deploy it onto the devices. However, of course, we didn't go further as an ISP, obviously. We, rather, went in a direction of covering as much as we can in the embedded area, in the embedded world, and we went to develop an open source build system that would actually ‑‑ that would cover this problem that we had, but also would benefit the community and our customers for the embedded world.
So, our idea of this so‑called tour boat build system was to have everything actually ‑‑ just use everything that the open source community gives you. So we used the kernel, we used the boot loaders, we used the software, so everything that is publicly available now. The only added value is our custom in‑house made management systems and software.
So, this service based ecosystem is actually an idea of having everything from the open source community, so all the important parts, so the kernel, the boot loader, the system software, everything you might find in a regular Linux distro. However, the added value was also sort of a, let's call it a package, for our Linux distros package manager. So we would just add our own package to the whole stack.
This is where Replica.one comes in. The Replica.one is actually a pretty proudful project of ours. It is a build system. It is open source, you can find it on our GitHub. This is a build system that incorporates Gentoo as the backbone of the Linux distro part. However, it rather doesn't use the Gentoo, let's say, flavour of doing things but it uses its portage, so the portage is its packaging system. That is very interesting, I will explain it in a minute.
So, as I said, Gentoo has a pretty interesting packaging system. To you that don't know specifically, Gentoo is portage, so‑called, is a packaging system ‑‑ for all of you that didn't use Gentoo for example, Gentoo is a Linux distribution that allows you to sort of enforces you to build everything from scratch. So to build all the system software, even the kernel and the packages in the user space, to build them yourself. So during the instillation of this distro, you actually are compiling everything. So you are compiling your kernel, you are compiling your systems software, you are compiling your ‑‑ everything that that you would just ‑‑ APT gets from a Debian, a repository, you have to build your own on your machine. So, this is actually a pain point for regular Linux users because if you are running a think pad laptop, you are going to force it to its limits because you are going to compile for hours, especially something big like a web browser, you would have to spend hours in compiling the software. But the beauty of this, the beauty of these packages is they have custom so‑called use flags. So this portage, this Gentoo packaging system, has a great interest in using customisable build for their packages. So, for example, what are these use flags? These use flags are very similar to C flags. So you have the make file when you are compiling something. And you choose what to compile or what not to compile into your software. So let's say I am sure you are all familiar with the Netcat, so it's a software, it's a small Linux software that allows you ‑‑ it's sort of a networking Swiss army knife. You can send requests, you can become a server, you can send bare bone HTTP requests, etc. So this is a sort of a low level Swiss army knife, and if you choose that you need Netcat on your router, or your switch, and you choose that, for example, you don't need IPv6, or you don't need, let's say, OpenSSL, you don't need it, you don't need a library, you don't need anything it from it because your switch only works IPv4, let's say. So these use flags actually enable you to easily sort of say I don't want to use IPv6, I don't want to use OpenSSL, compile the Netcat without it. So, these use flags are, let's say, they are simplified C flags, sort of compile flags that you would use when compiling literally everything. You would actually take advantage of those use flags and you would just compile the things that you need. So this is the Gentoo's portage use flags in our builds systems. So we saw this, we saw this as a perfect opportunity, actually the Gentoo is not sort of ‑‑ some people will agree that Gentoo is not for desktop usage and it's actually great in embedded world because it allows you to compile the only things that you need, the whole community is behind you because they developed these packages, these so‑called recipes, they developed them, they tweaked them, they enabled them to be actually good so you don't have to make files yourself.
So we saw this as a great leverage point into making an embedded build system which is Replica.one.
Some of the issues with this would be what about the Board support? What about the Boards that are not supported by the Gentoo community?
.
Well these are the things that are actually being done even as we speak, because there are more and more developers working on the embedded world in Gentoo. If you didn't know, Gentoo has a pretty solid backbone in the embedded world. There is a whole bunch of documentation on where to get started, etc. And the community of the Gentoo embedded world is actually our backbone, as I said before.
The portage system is actually ‑‑ you don't have to get the whole Gentoo distribution, you can just use the portage, and use it to leverage those delicious use flags that I mentioned before.
And as always, for example, we, as a company, we always try to benefit from the community, and we try to push things back to the community. For example, the Board support, the efforts of making Board bring‑ups, or any kind of Board support would be tremendously appreciated by the community and we give that back because we have taken so much from the Gentoo community, for example.
Replica.one is actually in production. We used it for years, we use it to build our own firmware for, let's say, a couple of years now and it's been in production on many routers, switches, Layer3 switches, even you can build whatever, you can build for arm or you can build for 8664, you can build for servers, etc. So it's a pretty versatile system actually. And I encourage to you check out the GitHub, actually. So it's under Sartura replica, and I encourage you to even contribute to our GIT repo and bring up some boards.
These are some of the hardware. You might recognise the Raspberry Pi, you might even recognise the EIE puzzle. So we have pretty serious customers, I would say. The upper right is a clear fog sort of a development board, so we are into the development boards also. Because it is important to have replica and to feel the replica, how it works on the bare metal. It can also work in the virtual machines etc., but it's being used on many routers and switches today.
.
So, about the maintenance. The maintenance is, as I said in the beginning, the maintenance is done majorly by the Gentoo community and their packages and of course the Linux kernel community, but the value added features are made by us. So our own, let's say, Cloud, our own services, our own management software, etc., added to this firmware build system, so we can build our own ‑‑ so we can satisfy our own customers.
For example, we have we have many people that are working in the company that actually support and commit to the upstream for the Gentoo, for the Linux kernel, and for some other, like OpenWRT, we have pretty interesting people working, and we repeatedly try to give back to the community as much as we took from it.
So, this is about everything on the replica system. I imagine you will have some questions. This is it from me. I am an engineer at Sartura. So if you have any questions...
.
(Applause)
FRANZISKA LICHTBLAU: Thank you very much. We have one question on the Q&A panel but it's not related to the presentation, so I would ask anyone who has questions to the presentation to come forward or write it to us.
I have one question from Roba Khek [phonetic]: "How do you actually ensure integrity of your firmware images and build artifacts? So how do you handle cryptographic signatures for your firmware images and/or build artefacts also during run time of the image of the device itself and verify that there is no tampering?"
EMIL KOSVIC: This is a great question. The question is about integrity of the firmware image. The integrity of the firmware image in Replica is being made in sort of a ‑‑ so the only actual signature that you have to worry about is your own value added software. So, everything else is backed, let's say, by the upstream, by the communities. The only signature you have to manage is ‑‑ we're talking here about the reproduceability of the firmware image from one state, when you compile it in this time or in five minutes, so we're talking about these signatures, and replica is solving this by keeping sort of a snapshot of the current build system state and the current recipes of the Gentoo's portage system. So we keep track ‑‑ we actually keep track of this internally with our customers because there is no point of having ‑‑ because the firmware image at the end is sort of a ‑‑ it's sort of a proprietary binary blob because it is used on the switchers and routers that I showed you. So the reproduceability is only a concern of our customers and we do that by sharing the snapshot and the recipes of the build system.
FRANZISKA LICHTBLAU: Thank you. So, do we have any other questions regarding this presentation? I don't think so. So thank you very much.
Give me just a second because we have one question and that was, I think this person is really interested in this. Maybe that goes a little bit in the direction of the Chair team if they could ‑‑ thank you.
Raza Kazeem [phonetic] is asking: "How can we join on site? We want to join the meeting on site but there is had no Serbian embassy in our country or in the nearest country. Can you help us?"
.
I would say the next meeting is not going to be in Serbia and the whole team is caring and trying to make sure that all these requirements are met as simply as possible, and, if not, reach out to the Chair team. The Chairs are nodding. Perfect.
Okay. So let's continue with the Plenary programme. The next presentation is Peter Hinrich from SURF and he will talk to us about the quantum future.
PETER HINRICH: Good morning, everyone, I work at the innovation department of SURF. And SURF is a partner in the quantum Internet alliance.
I am very grateful to have the opportunity today to tell about our plans and ambitions to build a quantum Internet in Europe.
A little bit about SURF. SURF is a cooperative. It's the collaborative organisation for IT in Dutch research and education. Our members are universities, universities of applied sciences, academic medical centres, research statutes and secondary vocational institutes, institutes.
Our activities include areas such as high performance computing, data storage and management, security and identity services, and of course our network. We operate our own network in the Netherlands with over 12,000 kilometres of fiber and 360 locations.
SURF is a partner in the Quantum Internet Alliance. Our innovations, we do with our members, but also in European projects such as the Quantum Internet Alliance. This consists of 40 partners in Europe, out of eight countries, coming from both industry and academia. Together we have the moonshot ambition to build a quantum Internet in Europe for the next seven years and, for that, we received funding from the European quantum flagship. A couple of weeks ago we had our kick‑off, so we are about to start off with our work.
So the objective of the project is to build a prototype for a fully programmable quantum network, connecting two Metropolitan scale networks by a long distance fiber using quantum repeaters. Before I go further with that, I will tell a little bit about the basics of quantum communication.
In a quantum network, information is sent in the form of qubits. And many of you may already know what a qubit is, it's the quantum mechanical analogue of classical bits and whereas classical bit can have either discrete values 1 or 0, a quantum bit can be in the super position of both the states 1 and 0 at the same time. However, if we perform a measurement on its state, the super position is disturbed and you only get the measure of values of 1 or 0.
An interesting feature of qubit is that they can become entangled and what it means is if two qubits an entangled the outcome of the measurement of vary values are correlated, even if those qubits are separated by a long distance.
And importantly for quantum communication or networking is another phenomenon and we call it entanglement swapping. If you have multiple sets of qubits in entangled states you can swap it and create an entanglement between our qubits. Let me explain this in an example.
If we would have three independent nodes in, let's say, Alice, Bob and Charlie and there is a direct link between Alice and Bob and there is a direct link between Bob and Charlie but no link between Alice and Charlie, we can first create entanglements between Alice and Bob. Then we can create entanglement between Charlie and a second qubit on Bob, we now have two pairs of entangled qubits and by swapping the entanglements of these qubits, we can create an entanglement between Alice and Charlie even without a direct link between them.
Now this has been shown in the laboratory between two laboratories on the campus there in March 2021.
So now back to the objectives of the Quantum Internet Alliance. In order to build this network, we of course need these repeaters, quantum repeaters by the principle I just explained, but we also need other hardware and devices such as platonic clients, hubs and processing nodes.
In order ‑‑ and we also have to develop a software stack to programme and control this network. And in order for such a network to be usable and to fulfil a specific task, all these devices have to meet very strict parameters, and these parameters, hardware parameters, these requirements come often as a tradeoff.
Therefore, we have chosen two test protocols to inform the technical requirements. These are the deterministic teleportation and blind quantum computation. In these examples, you can see, for instance, the trade‑off between parameters such as the rate at which entanglement is achieved and the coherence time which is the time that entanglement stays intact.
Now, to assess these parameter requirements, we can assimilate and model them through our core blueprint simulation. We have a dedicated modelling simulation team which works closely together with the device experts in the network architecture experts. They will make the hardware models available as software modules in the core blueprint simulation. So, we are able to assess these requirements.
We also have an innovation and outreach team that will be responsible for the translate the technology development into future products in Europe. And they will engage, reach out to the European Communities such as RIPE, and others, mainly via the quantum Internet licence technology forum. The QIATF, by the way, next year in March, there will be a conference in the Hague on this, there will also be a meeting of the QIATF. So if you are interested, come to the conference in the Hague and join the QIATF.
Collaboration with potential users is important because we want to take use cases into consideration in developing the system and when having to choose when there is a trade‑off between parameters. So therefore, we have a use case team, consisting of community specialists, which I am one, I hope, and application of protocol experts. We will engage and interact with potential users and identify their high level use cases. These will then be analysed and described in more detail. We will find matching applications and protocols and, if necessary, develop them or adapt existing protocols.
When we have developed code in the software development kit in our system, we can do the simulations and the results of these will be validated again with potential users in order to improve them and understand better what your relation is between the user requirements and the hardware parameters.
So, in order to engage with these potential users, we will organise events such as workshops, brainstorms and hackathons. And at these hackathons, the participants can work on challenges and for instance use the quantum network explorer which is our simulation tool kit containing different software packages which is also available to the public via web platform. It's already contains ‑‑ ready to go applications, so that participants and users can already start at a relatively easy level. For instance, by simulating entanglement rates over separate links with different fidelities.
So, I would like, finally I would like to draw your attention to the next coming hackathon, which will be organised by RIPE in collaboration with a couple of partners, among others, SURF and Kea and... this hackathon will be from 1‑2 December in different places in Europe, among others, in Amsterdam, and if you are interested look at the website of RIPE Labs and I want to conclude this lightning talk with thanking the RIPE and Vesna by being so cooperative and organising this hackathon and giving me the opportunity to present our ideas with you. And hope to meet and engage with you in the future. Thank you.
(Applause)
FRANZISKA LICHTBLAU: Thank you very much. Do we have any questions for this one, because in the Q&A I don't have see anything new?
AUDIENCE SPEAKER: I am no technician and I might ask a very stupid question. So would that be performance improvement in terms of quantum Internet? Will there be significant performance improvement in quantum computing compared to the current Internet? Because, you know, I read all these entanglement between ‑‑
FRANZISKA LICHTBLAU: Keep it short, it's a lightning talk. So did you have something to reply?
AUDIENCE SPEAKER: Sorry, can I finish my sentence, please? Just a second. I heard all these quantum entanglement and all that and it seems this came above the light speed and the light speed is speed limit for the current Internet.
PETER HINRICH: This is a very fundamental discussion, I cannot comment on it but what the specialist assured me is that there is no communication faster than light speed because entanglement also has to build up, so this is what I can say what the specialist told me, who are really bright people.
FRANZISKA LICHTBLAU: Thank you very much.
DIMITRY KOHMANYUK: Thank you. It's our second quantum related event. So, our next speaker is virtually present, and he is presenting about VPN generator. Okay, you are on screen, so please pick up.
OLEG BASISTY: Thank you so much. It's awesome you are talking about the future of the Internet. It's so amazing as a quantum engineer, I am afraid I am going to have to take you a little bit to the ‑‑
.
Honestly, I cannot see what's on ‑‑ what is being presented. Is anything being presented at all?
DIMITRY KOHMANYUK: We see your slide deck now.
OLEG BASISTY: Thank you. So, what we are going to talk today is about freedom of the Internet and the recent ones concern Russia and Ukraine. That eventually made us to to what we are talking about today. This is a lightning talk, indeed.
Me, I am COO of VPN Generator, and basically what we are is a group of people who left Russia after the war began, who decided that wars are not usually won by weapons and we actually can do a lot by working with the people inside Russia, and after we will manage the problems with the Russians, we are going to scale this idea to the whole world.
At this moment, you might be thinking, oh, my God, this is 2022 and somebody is still talking about VPN is something new. Yes, that's our thoughts exactly. That's why we came up with something a little bit different.
You see, Russia is now one of the most experienced countries in terms of censorship and blocking, and it is very easy for it to block, for example, commercial events. We have seen them blocked every week or two. And there is an amazing ‑‑ there are amazing solutions like PSIPHON and lantern that are working hard day to day to find new ways, no back doors to sneak in some traffic into the country. And we would not even think of challenging them.
So we came up with an idea that maybe we could actually do ‑‑ go a different path, a more decentralised path that might allow us sneak beneath the radar of a heavily centralised entities like Russia or any other censorship authority in any country.
So, what we came up up with. You see, we might as well create a lot of visions that would look just like any usual corporate VPN over a small business. That is tremendously hard to block, not because it's difficult, it's because there are too many of them and blocking all of them would cause way much more than trying to block lantern, for example, or any other centralised VPN that has a century point that can be targeted and blocked.
So, what we are doing right now? We are creating an MPP version of this product. That is going to be distributed freely among the people of, first, Russia and then I hope around the globe. And by the end of the year we expect to have 100,000 people connected to the system.
.
Continuation 1,000, more or less 1,000 of small VPNs that are going to work separately and are going to be connected to each other in any way that is possible to monitor.
Well, that's the point. So basically we are doing a lot of small VPNs are easy to manage and the main way of distribution of it is free friends and family. So we just have to be one person that is more or less interested in IT and have read the news about us, he downloads the thing and then starts sharing with people around him.
Simple, easy and it seems it might just get through the bubble of oppositionally‑minded people, because everybody wants to go to Instagram, which is blocked in Russia, or somewhere else.
But another part of the organisation is what we need. Basically, we have one idea right now that is mainly focused here is this RFC Captive portal 8952, which specifically says that to maximise universality and adoption, solutions must not be specific to any particular access technology. Obviously it has been told by the ways to connect the Internet. But the thing is that in the world where countries the size of a continent are considering an DNS culture, billions of people in other countries are using the VPN day to day to work, to study, to live. VPN is an access in 2022. So what we would be working on, except for the product itself, is to either create a new RFC or make an addition to it. To make a VPN an assess to closure, to ensure the capability of using captive portals on it, to provide information how to use it via this captive portal.
When we are going to motion for it? I honestly hope you guys will be able to support us in that.
Obviously, as any non‑profit organisation, and we're serious about going non‑profit with this, even though most of the team are on the back of it have business experience, we are absolutely positive that this project specifically should stay non‑profit. You know, like, state medicine, everybody got to be saved.
So, what we are going to need anyways is IPv4 addresses, obviously. And then we are going to have to ‑‑ we will be looking for hardware and virtual machines and stuff. Of course, we will need money and what does most interests is partnership in tech both big and small. This, we're going to talk a bit later about because this is another thing that we are looking for right here.
Everything else, honestly, we're going to get because the product itself seems to be kind of an easy win in terms of acquiring the market share. As a project manager myself, it's kind of hopeless to me, but we're not struggling only against the environment. We are struggling against the specific people working ins offices and in bigger countries that are willing to spend money on censorship.
So we have to think what's going to happen next. What's going to happen if all the protocols, for example, in Russia or in any other country like, I don't know, Iran, are going to be blocked, what are we going to do next?
.
So, basically, the guys can block everything, they can block ‑‑ create a white list for VPNs, which is kind of a solution to get rid of ‑‑ well, to beat us on some level, or maybe there is even an idea of VPN tax to make a specific list of people who are using VPNs. Those solutions are possible. We are working to overcome them.
Well, basically there are different versions that are on the way for ready approved, for censorship. It's obviously DNS over HTTPS. You know about this, I presume. Also, there is encrypted ClientHello and QUIC and MASQUE solutions. I honestly hope that you guys might as well root for them when you have the chance.
But still, those solutions are not ‑‑ well, kind of also is a block in one way and then the other way are not yet adopted. So, praying on something to happen is not our way; we prefer to act.
So, another idea is that we might jump to such a thing called refraction networking. What's it all about? Well, what happens if you find enough partners both in big and small technology companies that would be able to refract a little bit of traffic from the known reachable website from the oppressed country do a blocked one. In this way, we would be able to increase the stakes of blocking for senders on, up to the level of closing the whole Internet for the country, which costs like a lot. And in my ‑‑ and I hope that if we will be able to find these partners to find companies that are going to refract some traffic for us, we would be able to increase the sustainability of our project even further.
So, these are the ideas that I came with today. Might as well ‑‑ we might as well jump to questions, I presume. Thank you so much.
(Applause)
DIMITRY KOHMANYUK: Thank you. We are a bit short on time than we should be, so I guess I have got a couple of people saying what they want to ask you. I think I have to close this queue. We still have one more speaker. Please go ahead.
AUDIENCE SPEAKER: We had experience with some Internet censorships in different countries two years ago when the pandemic began and some are in place, got stuck in the application countries or somewhere and could not return back to Germany because of travel limitations and they had to work, they couldn't because VPN didn't. So the question is much of countries with Internet censorship that I observed, they don't ban specific IPs or subnets or specific services. They ban protocols using deep packet inspection, and if some foreign network operators help to ‑‑ if some network operators try to help to get all this ban, they ban the whole subnets or autonomous systems. So how do you propose to work with this? Thank you.
OLEG BASISTY: Work with what, exactly?
FRANZISKA LICHTBLAU: Sorry, maybe you guys can have this discussion offline, we are really running out of time. I am sorry.
OLEG BASISTY: I will show the presentation for one second to ‑‑ to show my contact, if it's possible. So we could continue the conversation. So you can contact me via mail or via telegram, I will ‑‑ please write something and chat and I'll contact you, okay.
FRANZISKA LICHTBLAU: We have one more speaker on the microphone. We cut the queue after him.
AUDIENCE SPEAKER: Well, I run a large VPN network to pass censorship many years ago, is this essentially trying to stop a political problem with a technical solution. So here is my quick question, I know everybody is running out of time. Is, number 1, do you concede there is a diverse of the solution because in terms of censorship, if you have one single apparent with your website and one single solution it's very easy for the political body to block you, and then there is another effort which you might consider to do is large amount of content, which is a blog, is not a politically related topic, for example Google, academics, the research papers, and do you have a plan to make cache available locally in the country where there's censorship, so it's not political related so it's easy to catch it locally but most of time it would become casual damage. Getting over censorship is one big topic and it requires a lot of solutions and we get around it. Technical probably essentially a short‑term solution and I think the way to go is that non‑political‑related content, like research papers and other human stuff related should get through the censorship, have a content cached locally that's probably the ultimate solution then fighting the political body directly with a technical solution which always a cat‑and‑mouse game.
OLEG BASISTY: Okay, so ‑‑ very quick. There are a lot of ways to fight the censorship. Your one also may exist, and if you would be able to make such a thing, it would be awesome, I would partner with you and be friends. So I encourage you a lot to do this. That's awesome.
AUDIENCE SPEAKER: Since there was no technical solution in your presentation, I didn't get your solution at all, but having a lot of IPs doesn't ‑‑ is this not the solution? Because usually we see that the blocked protocol and they see the patterns and the traffics that are for example equal, and also, well they can't filter all of IPs that you can see right now, for example, if you see the traffic of some big data centres, they face a huge degrees of traffic from here. And also having ‑‑ we have a lot of free VPN connections that goes through some people's network that it's not secure, it increases the security risk because they can see the traffic, they can inject some certificates etc. Thank you.
OLEG BASISTY: Okay. So basically, yes, the blocking goes through protocols and that is why our solution seems to be about greater collateral damage, what I was trying to show at the very beginning. What's the idea? Right now the governments are trying to fight the specific companies, basically, so the websites, the domain names, something else. And out here, when we are using just ‑‑ so something looking exactly like I don't know, IP Sec, personal DN, you are going to have it block it all, including, I don't know, if you are talking about running some nuclear programme VPN and something else and something else and something else, the collateral damage to it is exceedingly high, at least for the time being, and until the those countries are not totally blocked by the economy. So, in my perspective, our solution is exactly about making them pay more to achieve the same, pay so much more that they will not want to be able to do it at all.
FRANZISKA LICHTBLAU: Thank you very much. Thanks for the great presentation, you gave us a base for discussion and thanks for joining us remotely on this meeting.
(Applause)
.
Our next speaker is Massimo and will talk about RPKI and BGP monitoring.
MASSIMO CANDELA: Thank you very much. So, this time I got one of the last presentations in the last slot of the RIPE meeting and I am going to help and make it really quick and also because I know that together with Sjoerd, who is going to do the technical presentation later, we are keeping you away from a working group that cannot be mentioned and that doesn't exist.
So, super fast, I am going to talk about, explain how you run out of excuses and it's time for you to monitor about your BGP and RPKI operation.
My name is Massimo Candela and I work at NTT, I am a senior software engineer, this is a picture of our global network, we're a tier 1 and a large network, we need software to control it. Among these softwares in 2019 I developed a cool called BGPalerter for BGP and RPKI morning, you can download and run it. Basically, you can monitor your AS from hundreds of vantage points, distributed in the world getting form about hijack, loss of visibility, if one of your peer appears out of the blue, RPKI invalids and various other things we will see in a bit. And you can receive these alerts, whatever you want on mails, SLAAC, telegram whatever.
I developed it for NTT inside NTT after we decided to open source it, it is kind of a success story because now we have hundreds of installations worldwide, we have people install it worldwide, and there are some important operators that are using in production. So this is actually pretty good.
And the idea behind releasing it open source was that more operators would probably monitor, if they will have a tool like this, and we will all achieve a more stable Internet, we will also benefit out of it as a tier 1, but everybody could benefit out of it.
However, while the number of people monitoring is increasing the need for monitoring is never ending, and last year, well last RIPE meeting, I showed how, for example, there are autonomous systems that they announce RPKI invalid for around max length for months before they do something about it.
So, what's new about this? Well, what's new is PacketVis.com. So, as you see there is a balloon ten years ago when I started doing presentation at RIPE meeting I thought it was fun to put a balloon when I present something new. Now I am a bit stuck with this. But anyway, this is a balloon moment. PacketVis.com is a BGPalerter as a service is not an NTT product or an NTT service, it's run as a personal initiative. Basically you go on this website, PacketVis.com, there is a red button that says 'start monitoring', you click there and it shows you this box where you put your autonomous system number, and after DB, once you have the autonomous system number we do the entire configurations for you and in addition ‑‑ at some point we start monitoring, we notify you we are monitoring. And there is a page where you can start receiving all your notifications. So, basically you have a list of all the events, for example, hijacks that they happen, so in addition to the usual email and SLAAC you have this page. When you click on one of those events, you enter in the page related to the event; in this case, it's a hijack. So you have the huge summary but also more data that you can see so they can help you with the troubleshooting. But in particular, important is this action span that for example this a hijack, but the action box says is this autonomous system allowed to do that, to announce this prefix? If you say yes, it is allowed. From that moment on, the system PacketVis will not alert you any more about that. So, basically over time, by acting on these others, you will make the system more silent and more suited for your type of monitoring.
There is a page where you can go and set the type of alerts, there are 11 types of alerts inherited from the BGPalerter. So, hijack, visibility, you have for example RPKI invalid, when your ROAs are expiring, monitoring upstream and downstream AS to check if they are the one that you configure they should be. And you can configure this at global level and a single prefix level.
There is also this page where you can integrate it with other stuff in addition to the mail which is by default. You can use pager duty, telegram, SLAAC, syslog, whatever you want, with this interface. And of course, if you want to go classic, there is RAAPI that you can go and query and there are some more advanced things to filter by severity and stuff like this.
So, my presentation is over. I made it really quick. I hope you appreciate that and I don't think there is time for questions, but anyway, you have my contact and you can mail me and you can go try ‑‑ and especially, last one thing ‑‑ I am expecting feedback, so, please let me know how we can improve it to make it really suited for your use case. Thank you very much. Thank you for your attention.
(Applause)
DIMITRY KOHMANYUK: Thanks. I think this is a tool every BGP operator should use. We don't have time for questions, I think, but ‑‑
FRANZISKA LICHTBLAU: There is one thing that the PC still has to do before we hand over to the tech report. I am happy to announce that Antonio Prado and Moinur Rahman will join the PC for the next RIPE meeting, so looking forward to work with you.
(Applause)
SJOERD OOSTDIJCK: So. I'll keep this brief as well. Welcome to the technical report. I have got some statistics for you about what we have been up to this meeting.
The main thing that is actually changed for everybody is that the main wi‑fi changed and that it's now IPv6 mostly. Depending on your machine, or basically the version of your operating system, you will get IPv6‑only if it's sort of modern. You can still get dual stack if you wanted, and Ondrej, who is at the tech desk now, did a lot of work on this, so I think that's very great.
We have had about 60% IPv6‑only and 40% dual stack, and unless anybody is going to speak up in the questions, I think it went pretty smoothly.
Also, 2.4 gigahertz seems to be finally dying out, probably except for microphones and things like that.
That's the network we built up. We got 2 LACP 10‑gig lines from SOX. They wanted to offer us 100 gig but we didn't have the equipment, so we went to 10 gigs, and actually, 10 gig is plenty as well. As you can see from this slide, I mean you guys only went up to maybe 300 Mbit on a good day.
The green stuff here is IPv6, by the way, and the red stuff is, of course, bad, that's IPv4.
So this is the wi‑fi network layout that we have put together. This is Menno, and as you can see he is like very strategically placing all the access points on the floor and making a little map with tape, and then he actually put them in the building and on the map. And we have gone with fewer access points than we did in the past. I think it's actually more stable that way. It looks good as well to me.
The Meetecho stats. They are not very pretty, I admit, but I was in a rush. So the interesting thing here I think is that if you look at the percentage joined over IPv6, it's actually higher. I am not sure whether etc. Up to Ondrej's good work with, you know, getting more people on to v6 on the wi‑fi and then they basically joined the Meetecho from here over IPv6, which is sort of cheating, but I am just going to, you know, think to myself that it's actually more people having IPv6 at home because you can dream, right.
.
So, normally I would have coffee statistics here, but the barista got Covid, so, instead, I have music stats for you. You know that happy French tune, right, we looked it up and apparently on one we have four Macs in our setup, two in each room and only one of it has played it already 4,000 times since we got it for a grand total of about 16,000 times. Happy French tune. If you want to play it at home because you can't get it out of your head, that's the URL you can get it and you can find the slides online, of course.
The only issues that we have had is, when we got here, there was a wedding happening on Saturday night, and the AV guys really pulled it all together. So thanks very much, they worked the half night through, together with the hotel, to clean everything up, set up almost everything, and when we got here Sunday morning very early, most of it was just as it should be.
The only other hiccup network‑wise was that the access points in the lobby went down at some point because the wires are in the baggage storage area and packets are limited to 45 degrees and that picture is basically what we found, so a bag killed your Internet.
Then when I got to the side room after the whiskey BoF, my tables had been stolen. So I got them back, but, you know, I mean it was interesting.
And, you know, I really have to thank the tech team. I mean, I think we made a great meeting, and I hope you all agree.
If you don't agree, they have been working on basically alternative careers. You know, we have ‑‑ they are trying to make sure that they have an income after this meeting.
Of course, also we need to thank the web team, the Meetecho team and, of course, the stenography team, and I think that's it.
(Applause)
AUDIENCE SPEAKER: I am will, I am Internet user. Thank you very much, the technical team, the steno and Meetecho, that was amazing. Just a short one, you might want to go and look at the hotel wi‑fi router at the port 88, because there is the graph of the traffic that was used for the hotel and it seems weird that we had some spike of traffic on Wednesday evening around 10.
SJOERD OOSTDIJCK: When the tables got moved somewhere else.
AUDIENCE SPEAKER: Something like that, yeah. Thank you again.
AUDIENCE SPEAKER: Great job with IPv6, mostly. I think it was great that was set up here to get sources and information how that possible, in practice, I have a question about the IPv6/IPv4 stats. So is that IPv4 that goes from a RIPE meeting out or is that also things that go to NAT64? So is it internal v6 or what goes out?
SJOERD OOSTDIJCK I am pretty sure it's only the external line that I am showing here.
AUDIENCE SPEAKER: Okay. Would it be possible at some point also to get numerical how much IPv4 it was?
SJOERD OOSTDIJCK: Yeah. Drop me your mail address or just mail me at that, and I'll get it to you.
AUDIENCE SPEAKER: Okay. Perfect. Thank you.
DIMITRY KOHMANYUK: We missed one remote question from the previous session. How another prefix list in PacketVis or should you add it manually? It's for the previous speaker. Please go ahead.
AUDIENCE SPEAKER: Andrei. It was just small remark. There is some rumour surrounding this RIPE chat that, for this airport in the city, you need to print a boarding pass, so I would like to remind you that there is still a printer at the registration desk, which is called Terminal Room printer, so you can use it to print your boarding pass, but do it before lunch because after that the printer will be gone. There is also a hotel print, by the way.
SJOERD OOSTDIJCK: There is a little business centre here next to the reception that has a printer as well.
DIMITRY KOHMANYUK: We are good with the questions. Thank you, technical team, you are wonderful. Thank you.
(Applause)
FRANZISKA LICHTBLAU: And with that, we happily hand over to the Chair team for the closing. I would like to remind you to please rate the talks for the entire meeting. The PC really appreciates your feedback on what we did here. Now, Mirjam, and Niall, obviously.
MIRJAM KUHNE: Thanks to the whole PC, you did a fantastic job.
Right. I'll try to be quick, because there seems to be the theme for this morning to be quick, quick.
Right. So just a few statistics. That the RIPE NCC meeting team has put together here for me. So we have totally checked‑in attendees, 748, of which 493 on site, and 255 online.
About 350 participants per day on Meetecho, you already saw that.
202 newcomers, which is great, a high number. Also really happy to see the high number.
And we had six children here in childcare on site and also a high number and 14 online. Somebody is asking yesterday about what does that mean, online childcare? But I think we started this during the pandemic, that we actually have a company who does kind of online coding for kids, which is really cool; actually, I want to participate in that as well.
And so I am really happy we were able to provide childcare again.
I just want to add also reports here from the trusted contacts. Actually, we have a slide for that, no? Did we add that in the end? No. I think we have a slide on that. I don't know why it's still on there. Remind me if I forget. This is just a participation across countries online. Let's go first on‑site. So, still we see a lot of high numbers from Germany and the Netherlands, as usual, if you will, but also, of course, a high number from Serbia and also, again, a lot of ‑‑ we see a lot of different participants from different countries here at this meeting, which is great.
.
For online, quite similar. We see a very high number from the Ukraine also participating, not only here on site but also remotely.
There is one new activity that the RIPE community has started, and that's a new task force that was agreed yesterday during the Community Plenary that will set up, it's an initiative by the DNS Working Group, the Cooperation Working Group, and the BCOP Task Force has offered them help, and the goal is to draw up some guidelines for running a public resolver, DNS resolver, and there will be more information sent to the RIPE list and to the relevant Working Group lists there as well. So you will find out more. If you are interested, talk to the DNS Working Group Chairs or the Cooperation Working Group Chairs.
We also had NRO, so the Numbers Council election for the Number Resource Organisation going on, there was one seat became available after James Kennedy filled the last term for only a year, and so there were two candidates, and the elections came out with James Kennedy as the next member for. I don't know if he is here. There he is.
So, now James will start a full three‑year term on the ASO AC elections.
We have one outgoing Working Group Chair, that's Shane Kerr from the DNS Working Group. Bye‑bye, Shane, and thank you very much for the great work.
Instead of Shane we have William Toorop, who will be the new co‑chair for the DNS Working Group, welcome William, and then we also had two terms renewed for Rob Evans in the RIPE NCC Services and for Raymond Jetten in IPv6. They were standing again ‑‑ their term ended, and they were standing again and they were selected again by their Working Groups.
This is the whole set of Working Group Chairs now just to give you an overview. I am not going to go through all of them here.
And of course, we have the old PC, obviously, because they did all the work for this meeting and the two outgoing members are still on this slide and thank you very much for a great programme you have put together here. I thought we had some gifts for you. Can I ask the PC members that are here in the room to come up and stand here with me for a short while and so we can give you a token of appreciation from the RIPE meeting team and the RIPE Chair team.
The slide is actually not correct. This is Max, this is not Peter, so, sorry about this, somehow we got mixed up there at the last minute, there is always kind of last‑minute changes, sorry about this.
Thank you, guys.
(Applause)
And then for next time we will have two new members. So a special thanks to those two or going out at this RIPE meeting.
And these are the two new members that have been elected that have been announced.
SANDER STEFFANN: I just want to make a comment on the Working Group Chairs. Because I heard some people comment, like, well, sometimes there is only one candidate available so there is not much of a choice. So, this is by design because running a working group is hard, so often if people are happy with the current Working Group Chair, they often get reselected, but I do want to remind everybody that everybody is welcome to become a working group Chair. So, also newcomers, it doesn't matter how often you attended, so I just want to make it clear that this is really something run by the community. So, if you feel like it, please step up.
MIRJAM KUHNE: Thanks for the reminder, that's absolutely true. And while I think the Working Groups, you know, of course if you are not happy with the current Chairs and select the outgoing Chairs or the incoming co‑chairs, and I am really glad that, you know, Ray and Rob are running again. It's definitely also good to get new, you know, new blood into the team and I would like to encourage you to all think about in the Working Groups that you are active in, maybe next time a term comes around you would like to participate more actively and take on a role as a co‑chair. I do remember now that Ulka, who prepared these slides for me, actually put the trusted contacts report kind of on there as a reminder, so I just wanted to go back and tell you what I have heard from the Trusted Contacts Team during the week.
They have received two reports. One report was submitted by mail, but the person has decided to take it elsewhere. And there was no further action required from the Trusted Contact Team. And then there was one other report in person, and that has also been resolved directly internally. So it was a relatively quiet meeting for the Trusted Contacts, they said, which is, I hope, good news, but I also hope that people feel encouraged to do report things to the Trusted Contacts if something goes wrong.
Then, we come back to more prizes, and the winners here, these are the prizes for the presentation, so these were the presentations that rated the highest. I don't know, help me out here, do we just congratulate them and they will be sent something, I think.
I have all the notes here, I don't know why I am struggling. The Events Team will contact you and get your details and we'll send you your gifts. That's what I am supposed to say.
And the same for you, there is also a prize for the newcomers on‑site registration raffle. That's Eric West. Again, we will contact you, you don't have to come up here now. And for the online and for the onsite raffles, they are two different people, Erik West, Thomas Kerly [phonetic], and there is a Kahoot winner, Robert Scheck, who I think is participating online, and he won the Kahoot. You can, of course, participate in Kahoot both online and on site. So congratulations to you all.
.
(Applause)
.
It's always fun to have winners. Last but not least, share your feedback about us, here is the QR code and also the feedback form. I gathered a lot of feedback during the week but we'd really like to hear from you, the feedback form covers all kinds of topics, venue and the meeting overall. So that would be really helpful for us.
And now, really last but not least, I would like to thank the specifically the two hosts, can you please come up here, do we have a representative here from SOX and from RNIDS, to come up, and I believe Alex has also a gift for you, and you have done a fantastic job in hosting us here, specifically the party last night was a real success, I really enjoyed it and I think many of us did.
(Applause)
.
An, of course, also thanks to all the other sponsors who made this possible here.
And this is a bonus slide of the beautiful photo of the tech team that Sjoerd has just represented here on stage. Just to show you a more serious picture. And I hope to see you all ‑‑
Somebody has asked for a specific lightning talk, I just want to remind that you all the videos and all the talks are archived and they are in the RIPE meeting archives, and this specific video has been requested during the week and that's actually a presentation by the stenographers, who have explained how they are doing this, and it's really interesting and it came up in a couple of sessions. So, here is the link, you can find it there.
See you all, hopefully, next time in Rotterdam. We have been there before, we are going back, it's an improved venue, improved hotel, so hopefully I'll see many of you there.
And just in case you have anything, you talk to me or Niall directly, here are contact details. That's all from me, and that's adjourning the RIPE 85 meeting here in Serbia. I had a wonderful time. Thank you all.
