Closing Plenary Session
Friday, 18 May 2018
11 a.m.
BRIAN NISBET: Please take your seats. Good morning. And welcome to the final session of RIPE 76. So myself and Benno will be guiding you through this until we hand over to Hans Petter to close the meeting.
Before we start with our presentations this morning, we just have one quick announcement which is the results of the PC elections. So, there were three candidates for the election. Peter Hessler, Ondrej Sury and Dmitri Kisselev. We got quite a decent number of people voting. Thank you all for participating in this, and we will be publishing the full results on the website, but the two elected candidates Peter Hessler and Ondrej Sury. So thank you very much. And thank you for Dmitri for putting yourself forward and again we'll be doing all of this again in six months' time. You get your chance.
Anyway, on with the content rather than the administration.
So, our first presentation this morning is from Gilles.
GILLES ROUDIERE: Hello. Thank you for attending my presentation. It's going to be a little bit special because I am not from the industry, I am from laboratory, which is called the laboratory for analysis of architectures and systems. The last, from the CNRS, which is one of the main organisations for public search in France.
So, I work with Philippe, who is my adviser, and I work also, this work is done in partnership with border 6, so quite a small company, they were bought recently, and they are basically working on all in one solution called don't stop Internet, and since their clients suffer from DDos attacks, my Ph.D. was about detecting such attacks and we proposed a new algorithm to do so.
So, first of all, what's a DDos attack? The basic scenario for such attack is that we see that an attacker took the control of a set of computers spread over the Internet. Those computers called slaves or zombies, when that occurs, it decides, it can ask the machines to send a lot of fake requests towards victim server. Those fake requests exhaust the victim's resources, whether they are the network bandwidth, but also the computing powers resources or maybe some protocol implementation related to the resources.
Those fake requests, since the victim is, goes under saturation from these requests, the legitimate user cannot access any more the service which leads the victim to lose his money, obviously.
These attacks have major impact, they may cause a total paralysis of the victim's resources and service. I got a few example of these kinds of attacks. Recently in 2018, GitHub, the famous asked for repository, underwent an attack of 1.3 terabit per second. This attack was like ‑‑ we had another one recorded five days after of 1.7 terabit per second, which is basically like you would need 100, if I'm not mistaken, 100 high speed fibre slot to handle. Also according to a study made made in 2017 they asked a network administrator from the industry, they said like 85% of companies underwent at least one attack in 2016, and this includes 18 percent at least an attack once a month.
Also, these attacks are costly because according to the same study, 63% of those companies estimate the cost of the unavailability of their service to more than $100,000 per hour.
In average, an attack costs 2.5 million. So, obviously, as we see this, we can say, all right, this is something we want to prevent against, and mostly before that, we need to detect as soon as they arrive, they happen.
However, this detecting through such anomalies is really difficult. Obviously the first thing we can think about when we want to build an efficient detector is its ability to detect attacks, so we want a detector to detect all attacks but also we want it to detect snapshot, and we want the detector to be able the process the whole traffic in realtime. But these detection has a cost, a cost first from the work of the network administrator, that's why we don't want the detector to raise too many alarms and waste the time, so waste our money. We also want the network detector to ‑‑ the anomaly detector to be easy to set up. We want it to provide results that are easy to analyse for the administrator to take an appropriate decision on what happened, and we want also the detector to be able to adapt to the traffic changes. When you set up a new services on your architecture, you might ‑‑ you don't want to have to update everything on your detector.
But, aside from that, another cost comes from the material cost. Obviously if you are a small company running a simple website, you might not want to have a cluster of machines to run the detection, so, a lightweight detector might be useful. The last problem of the DDos detection are obstacles. The fact that since a consistent simple fake request towards the victim, it's really hard to segregate the normal traffic from the anomalous one. Indeed the attacker might use packet manipulation like fake a real packet when it's a malicious one. He can use IP spoofing which means you use a fake IP address when you send the traffic. And the distributed nature of such attacks make them hard to encompass the traffic that is responsible for the attack.
And also, in the context of my Ph.D., we had a few other problems that came, that were added by the fact we're in partnership with border 6. The first one is that the solution is run on a single device which is, which has limited computing power resources. Since the most common way to run traffic monitoring, we wanted the detector to be able to run on sample traffic. Also, since this is where the bugs are set up, we wanted the detection to operate on the victim's side. And finally, for privacy reason, privacy is pretty fashionable today. We needed the detection to run at the network level since we didn't want it to go into the paper load.
Okay. So, when we do our research the first step before trying to answer the problem is looking for existing solutions. And the first one that was created, and it's still very used today, it's what we call the knowledge‑based approaches. So, they consist of basically having ‑‑ we know a set here of attacks we already faced before. So for all of those attacks we know, we're going to create a model of this attack, what we call a signature, and the signature for each attack we know are going to be used to detect this specific signature. So this needs a lot of work, because each signature has to be done by hand, by experts and they have to feed your own traffic. The problem with such approaches, we can easily see that on the right of the slide, we can see that this little guy, even if it's quite of use is not really ‑‑ it is not really cool. He want to harm us. The detector is not able to detect the anomaly, since we don't have a signature for this tack. However, these approaches are advantageous. The efficient detection of known attacks, they provide exhaustive diagnose information since each signature feeds a specific attack. However, traffic signatures are hard to create since they require an expertise and they do not detect unknown anomalies. These are the common business how we are in business today, like, you ask them to monitor your network and they build a set of signatures by themselves and sell the signatures to several people.
So this is not enough for us researchers. So, when we want something to be more autonomous, more generic, we create obviously what we call a model.
So, after the signature‑based approach, we ‑‑ the approach consisted of having a generic model of the traffic and this model, we're going to train it with labelled traffic. So we have got this set of normal traffic that we know, we are sure it's normal and this set of examples that are attacks. The model is trained to recognise each kind of each class, and at the end, it understands what are the difference between the several class in the input. Here, it understands that the yellow traffic is normal, while the red one is a anomalous.
So that can attack unknown anomalies since you train them on normal traffic, if something differs from the normal traffic, it's an attack.
They can be trained again if the traffic evolves, you can do that easily if you get this level of traffic. But the fact is like building a mould of the traffic is really difficult and the traffic evolves a lot. And also we need a representative level of datasets that contained a variable in properties and when the traffic evolves when your new properties, you need to rebuild the representative dataset.
So this is not autonomous enough. We want something a lot easier to maintain.
So do so, a researcher should use the most recent approach, which is unsupervised anomaly text. This considers most of the traffic is a normal one and something that differs significantly from the normal traffic is considered as an anomaly. So, we feed the algorithm with the traffic in production and then it's going to try to understand the different classes of traffic by grouping the similar entities, the similar together. And it will segregate the one which doesn't look like anything normal.
It outputs dangerousness score. As we see, the ones are significantly different than the other, so in that case, do we consider that the anomaly is too dangerous to be kept in the traffic? And then the detector mate take the decision by itself to automatically set up a set of counter measures since we already partition the thing. So, we know what are the encompassing characteristics of those attacks and we can build filter autonomously.
Then, if we don't have enough information to filter the traffic autonomously, we ask for the administrator feedback and its decision is taken into account and we already have the decision for the bad traffic so it can be filtered easily.
So what is the difference between this one and the previous one, is that here we have got a proactive approach. Here we ask the feedback from the network administrator only when we detected something that is not normal. So, it's a huge gain in terms of autonomy and it reduces the cost.
So, this approach needs little or no intervention from a network administrator. In most cases they are autonomous. It can detect unknown anomalies, and they autonomously construct the distinctive features of each traffic class which allows to produce growth. However, these approaches are usually really need a lot of computing powers to run. You need to ‑‑ because in each step you have to compare each entity when it's a packet it's a lot, I mean you have to compare each thing to each other. So this takes a lot of time and it's not really efficient.
So, to solve this problem we wanted to create a new solution, a new balanced solution that helped us to use the last unsupervised detection approach in an industrial context, which means ‑‑ these are the characteristics we wanted to have.
A fully autonomous detection with a lightweight approach. We wanted to operate where sampled traffic, which is a constraint of the industry generally. We wanted to simplify the analysis stage by producing an easy to understand result. We wanted the algorithm to focus on DDoS attacks, but also it should be able to detect, since it's unsupervised, we can detect zero days. But if focus on DDoS and we wanted it to be compatible with industrial technologies, such as IPFIX and sFLow monitoring architectures.
And if you want the details of the algorithm, it's freely available. You can find it on this article on this link. It has been published to an international conference all CNNS conference on networks and management and the article is called the lightweight snapshot based on DDoS detector.
Regarding the valuation of impact of traffic sampling, we have an article that has been accepted to the ACM Sigcom workshop and should be published in August.
So how does it work. The basic principle of this algorithm is divided into two parts. A continuous part which is able to process the traffic in realtime. It extracts a set of features from the traffic and builds accurate characterisation of the traffic properties at any time really easily, really fast. So it uses a set of histograms and another set of a lot of properties of the traffic that are global to the whole traffic.
And at regular intervals, we execute another treatment, which is called the discrete processing. Which basically takes all the data structure created in the first part, extracts representation of this data, it's a lot simplified, and creates what we call a traffic snapshot. This traffic snapshot is then recorded into a set of previous ones, and then we use an algorithm to call the KNN, which compares the last snapshot created with a set of previous ones. And the last snapshot created is significantly different from the past. And if it goes above a threshold, we consider that we got a DDoS attack going on.
So, on the output, we got these kind of graphs. So basically it is used as a monitoring tool, but it allows you to, when it detects an anomaly, to understand the features of the traffic that rate the anomaly, what went wrong. So it helps the network administrator to take ‑‑ to make a good decision. And in our evaluation, we are able to plot a video of what was happening, that helped us a lot to understand what was going on.
So, obviously since we're doing research, we evaluated our algorithm. We did that by creating a dataset which is called a Synth/ONTS, which basically consists in 13 anomalies, including a lot of DDoS that were generated by emulation, we created a fake network. And we included them into real traces.
As a result, we were able to detect 83% of the DDoS attacks, we're raising a number ‑‑ so this is a number of false alarms raised ‑‑ and out on the number of tests ran, we're able to raise a false positive at 0.13%.
When we changed detection parameters, we still keep a good detection so it's not hard to find, and it takes less than 1 second to detect the attack.
Since we wanted to do the algorithm to be able to process the traffic in realtime, we also used traces from one of border 6 clients which included web traffic, it included a DDoS attack. As a result, we managed to treat one kind of traffic in 0.2 seconds, so that we can say it's realtime, on a simple machine. Also the discrete part of the algorithm, it takes a negligible amount of time, compared to the continuous part.
We also compared ours with the other one. The first one we compared it with was the FastNetMon, which is basically a signature‑based detector. It appears to be three times slower than our solution, it detected half of the attacks and raised one false positive, and we also compared with another technique, which is more advanced, which is called ORUNDA, a previous use detector of our team, it appears to be 10 times slower but detected all the attacks. So here we can see we have a balanced solution between the capability of the algorithm to run in realtime, and the accuracy of the detection.
Finally, for our evaluation on sampled traffic, we evaluated the algorithm on 5 sampling techniques, 3 that are account‑based, basically it means taking one packet every end packet or 10 based sampling, which means take N packet every one second. So there are different sampling techniques. In both cases, the attack algorithm showed good performances and it showed very good performances on time‑based sampling, especially when we had really high rates, like one of 60 packets, which is still quite a lot. And we saw that the sampling had little to no impact on the detection efficiency.
So this is the time we, like, plot the time required for the execution of the algorithm here. And on the bottom you have got the sampling rate. So, we can see that for the continuous processing, we have got execution time that is perfectly linear corresponding to the sampling rate. And while the scale is not really good on the right side of the slide, but in fact it doesn't move a lot for the discrete processing, like it's between, if I can read correctly, it's 95 and 80 I think. So it's quite constant.
So, to conclude this presentation. I presented you a new algorithm which provides an efficient detection that is robust and realtime. It's an autonomous detector. Since it's unsupervised, it's able to operate over sampled traffic, produces easy to interpret results. And for the future works, we wanted to have an autonomous creation of better traffic signatures. For the moment it's only a prototype and doesn't work well. And we wanted also to improve the characterisation of the traffic by using reinforcement techniques. It's basically when the administrator takes a decision, we use this decision to make the model better and to perform better.
So, that's it for my presentation. Thank you. And if you have any questions, if we have got time...
(Applause)
BENNO OVEREINDER: Any questions?
AUDIENCE SPEAKER: Hi. Ivan Beveridge from IG. How does it deal with sudden increase in traffic for events? How does your tool deal with sudden increase in traffic for events, like for example for a football match or a ticketing provider?
GILLES ROUDIERE: That's a good question, actually. That may be one of the most ‑‑ well in that case, I think it's better for detector to ask the administrator feedback in that situation. It detects the attack but it asks your feedback. But... well, in a smarter way of doing that, the detector would be able to detect that we already had a DDoS attack before and it looked like that so that's why we wanted to have reinforcement of techniques. So we can recognise something that we already said this is bad. In our technique we needed a trader feedback. So, yeah, if you got an event, a football event, for example, you will have the network administrator say, no, that's normal, because there is a football game. And it's easier to say than for an algorithm.
AUDIENCE SPEAKER: The other question was just about you said about sampling rates, but can you say what sampling rates you have tried?
GILLES ROUDIERE: Oh, the sampling rate I used? So I think the sampling rate I used was between 1 out of 500. From that to 1 out of 10,000.
AUDIENCE SPEAKER: Artyom Cavrichenkov from Qrator Labs. So you have been using ‑‑ to test this, you have been using 13 synthetic attacks. Can you briefly describe what the attacks were generated like, the type or just...
GILLES ROUDIERE: So we read the literature on existing attacks, so we had TCP inflows and TCP inflows and we took one or two attacks for each kind of well known kind of attacks. We also added two BruteForce, like FTP BruteForce, testing password on machines. We used all of that, so usually we had two different rates for each attacks and we generated them in and emulated that work. And that's it.
BENNO OVEREINDER: Thank you very much.
(Applause)
So, next person up is Sara Dickson. I know Sara is a very civilised person so ‑‑
SARA DICKINSON: Thanks, Benno. So, the topic that I wanted to cover in this lightning talk is the way that DNS is evolving between the stub and the recursor. I am going to use two acronyms in this talk: DOT for DNS over TLS; and DOH, for DNS over HTTP. Both of these are happening. DOT became standard almost two years ago, DOH is on the very active development. The draft is in a working group last call. I will point out that this draft is very narrowly focussed just on the protocol aspects. It really doesn't go into any detail about use cases or discovery models and in fact there is a separate group that's been spun up to look at that because there is so much there to understand.
So both are happening, and what I want to look at is what is the impact of this shift directly on DNS from end user devices.
So, to reinforce the fact that these are happening, a brief overview of the implementation of these protocols. DOT, if you want a client, there is a variety, there is the get DNS library, there is stubby, which is a proxy that uses the get DNS library. Unbound and knot resolver. The Android system, as you heard the other day, recently added an option to the developer version where you can do DOT opportunistically. I became aware last week of a pool request against system D to support DNS over TLS there. There is a browser which will send all your queries from the browser over DOT. So there is a big range of options there.
On the recursive resolver side, almost all the major resolvers now support this. BIND work is underway on it, but unbound, knot resolver and these support it.
For DOH, there's been a huge amount of work happening in the last 6 to 12 months. In particular, there was a lot of work done at the IETF hackathon in March. That generated about 8 different implementations just out of those two days of work.
Recently, Android has announced an AP called Intra, which let's you send all the queries from your device over DOH. Firefox 59 nows ships with a configuration option where you can drop in an URL and it will send the queries from that browser to that DOH server. They also did an experiment with Firefox Nightly where, by default, they did that with all your queries for two weeks and that got an interesting reaction in the community.
The next release of Stubby will support DOH. And so ‑‑ and this is being updated every week in terms of what's available.
In terms deployment. For DOT we have had about 20 test servers running in the last year we have seen two large scale deployment. So Quad 9 and CloudFlare. And for DOH, CloudFlare also have a large scale deployment working and Google have a small experimental service available for testing while the draft is under development. There is a handful of other test servers emerging as well.
So, the thing that this means is when you are considering doing DNS from a device, the expectation is it's going to be a shift from having a central system resolver to apps doing their own DNS. Now, this, of course, has also been perfectly technically possible, nothing was stopping them. But historically, apps have just called into a system library through a very simple API and not really bothered about what was going on under the hood. And that's true for DNSSEC and it's true for whether they were using an encrypted transport. But that's shifting now. The get DNS buy re was specifically designed so that apps could, that weren't in system libraries and DOH really pushes this use case a whole step further. The one thing is does say is one of the use cases in the draft is it's aimed at allowing web application to say access DNS information using existing APIs. I personally fully expect all browsers to ship with this DOH configuration option in the very near future. As a very interesting discussion to be had about whether they will suddenly start having sets of suggested servers and if everyone day they will ship with a default server configured.
There is also a lot of discussion with DOH about how you might do discovery to increase privacy. So, one idea is I have a tab in my browser open to my bank. If my browser can discover that my bank also has a DOH server, then I could choose to do all the DNS queries for the content on that tab to that server. And the privacy gain there is I'm not leaking those DNS queries to any third‑party resolver because the bank already knows the content I'm fetching so it doesn't hurt for it to see my DNS queries. That is still under evolution as a mechanism.
So, again we come pack to what will this really mean for the concept of one central system DNS resolver with one set of user preferences?
And the answer is, let's think about this. In a Cloud based world more and more queries are going to go through a browser, or through an app. And if the browser starts shifting to using encrypted transport, it's likely that apps will follow. Because you can imagine it's a nice selling point for an app to be able to say they protect their users privacy by using encrypted DNS.
So, there is going to be a shift of all these apps doing this. And practically forth user, what does this mean? Well, okay, reality check, the vast majority won't even notice or care. But the people in this room issued notice and care. And with this kind of big change there can be advantages and there can be disadvantages. The huge up side of course, is that it massively increases user privacy, huge win. On the downside of course, suddenly managing your DNS gets a lot harder.
So as opposed to having one simple system setting, I now have multiple configuration points. They can be doing different transports and connections differently. The most important concern for me is they will possibly be doing DNSSEC in completely different ways. And that's going to be a challenge, I think. Also, my careers could go to multiple resolvers. But what if some of those resolvers stop failing, getting attacked or get blocked? Then the failing mode I see as a user is going to be peculiar and very tricky to understand. If you want to go one step further and debug those kind of process, you are going to have to rely on the apps to expose the queries to a user, it's a big assumption that every single app will do that.
What it means that in this world the coordination of your DNS with end user device isn't obvious. Effectively DNS becomes no longer part of your infrastructure. I know the Android folks thought about having a system API to exposure preferences that apps could discover, but that's really in its infancy.
So, I think it's way way too early to understand what this picture will look like. But I think we need to be aware it's on the way and very soon DNS device also not resemble how it does today. We will an ecosystem of mini stub resolvers which will not necessarily be transparent to the user.
Thank you.
(Applause)
BRIAN NISBET: So, thank you very much. We have time for one very quick question, or comment or otherwise.
AUDIENCE SPEAKER: Gert Döring, current open VPN maintainer. We already have huge amounts of problems with systems not querying the DNS resolver that needs to be queried to find answers in a VPN context. So, I think that moving where is my DNS resolver logic into the browser is about the worst idea I have heard in the last ten years.
(Applause)
SARA DICKINSON: I largely agree with you. I think that it poses a huge number of problems. I don't think it's avoidable, though. It's already happened.
BRIAN NISBET: Thank you very much.
So, having determined that we have no idea where our DNS will be next year, the next question is will it break or not? So please...
PETR SPACEK: Thank you for introduction and brilliant talk, Sara. Sara was talking mainly about the future and I will be talking partially about the past and the now.
So, maybe, first of all, how many people in this room already heard deprecating EDNS? Oh, that's not enough. Okay. So DNS is wild west, let's admit that standards are just piece of paper, nobody is following them. So, in practice, when there is DNS software and you work around on top of another work around and then another layer of work around and it's just stacking up, and now we reached, I think, breaking point where the work around started to cause more problems than they solve. So DNS vendors agreed that this is too much, the maintenance is nightmare and it's time to rip off some work around. The thing is that most of the DNS servers just work and comply, but then there is like little percent of it, of them, which are not compliant and cause problems in the rest of the ecosystem. So, the bigger problem is that you have a new resolver and it sends an DNS query which contained EDNS extension and what happens? It gets dropped. So, the resolver has no way to say was it just normal packet loss, or was it crazy firewall, or was it non‑compliant implementation or what? So, basically, there is no way how to distinguish that, so for historical reasons, let's say, the resolvers were doing some heuristics and trying to guess what's wrong. So okay, first we tried to disable the DO bit, for example. Then, okay, try to change EDNS buffer size, they didn't help. Okay, drop EDNS, oh finally it works, or not. And of course all this takes a lot of time.
So, in the end, it's broken and users complain because the latency is a nightmare. It might take a couple of seconds because you are always waiting for time‑out and then another time‑out and then another time‑out, that's way too much. And of course, sometimes it's actually packet loss and not a broken firewall. But it triggers this heuristics and all bets are off.
So, the change here is, that the classic, I would say classical Open Source DNS when it is agreed among them that it's too much and starting from 1st February 2019, we are going to rip off work‑arounds for these kind of EDNS non‑compliance. Most people shouldn't notice because it's just fine, and I would say the worst offenders who break the ecosystem for the rest finally need to upgrade. Because believe it or not, the EDNS is with us for 20 years, so maybe it's time to read the RFC.
So, the thing is that everyone can test whether that particular domain will break or not. It's super easy, you just go to this website. Slides are available, so I will just go on. And on the website, there is a bunch of statistics that's not that interesting. The most interesting part for you is this link, test your servers here. If you click on it, there is a form which has only one interesting field typically and that is zone name. So if you enter something like nic.cz, and like sub‑net, it should take like a quarter of a second, or something, if everything is okay, it will be green, done, you don't need to do anything, it will just work as before or maybe a little bit better because the heuristics and work‑arounds will not create any problems.
If it takes longer to load the page with the results, something is suspicious. Typically you will end up with a message like this. And that was copy and pasted from the page. And in that case, you need to read the result and see what's wrong. It will show you a name of the name server, its IP address, name of the test which failed and description of the test. So, typically, it's either software wasn't upgraded for years or it's firewall, which is somehow misconfigured. Pick your poison. In any case, please, please, please, please, please test your domain, and see whether it is going to break or not.
This is the website. Please open your web browser. That's it, and now it's time for questions or tomatoes or eggs or something.
AUDIENCE SPEAKER: Matthijs Mekking. If I want to test my domain, obviously I can. I don't know for sure if it works all over the place, right, because basically you have to test it from the end point, from the resolver here, the resolver there. So... how to test my domain or is it more like the validators should run it for a couple of domains?
PETR SPACEK: This is a good point. It seems that most of the breakage is happening near to the authoritative server, because there is a load balancer or a firewall in front of the authoritative server, which is just mad. Usually the core network, the transport is kind of okay‑ish and doesn't cause these kinds of problems. So the assumption here is that most of the breakage happens on the authoritative end, not necessarily a server, but maybe load balancer before it, so this test is like good enough.
AUDIENCE SPEAKER: I just tested. It's actually if you just put the domain name test on your circuit several list. I tested rtld.ua and we have a little bit of tiny non‑compliance, and yes, I'm going to fix it, but yes it would be good to say test your domain automatically on a server or on your favourite resolver, but good work, and maybe you should just call it ednstest.net or something, or ‑‑ or EDNS now.
PETR SPACEK: The thing is that a source code is available so if you go to the page, I think that there is a link for the source code for the test and it's little C software so you can download it and work on it from your home network if you believe that there is some problem on the way.
SHANE KERR: I think this is a really good effort and I am glad that the DNS developers are getting together to work to improve the ecosystem. It's nice to see you kind of getting out of this race to the bottom where everyone has to implement it because someone implements it.
However, I think it's quite likely that this is going to cause problems for some operators somewhere. And it would be really nice to have a joint statement on the web pages or something that when my officer comes to me and says why are you breaking my Internet? That I can say well there is an effort to do this and here is the official statement that everyone has.
PETR SPACEK: Very good point. Thank you for it, we already have it on the web. And it's on block and a load of websites, who knows elsewhere. So, maybe we need to do more publicity, that's the reason why I am here.
AUDIENCE SPEAKER: Warren Kumari, Google. More of a statement of some of the open public DNS resolvers are also planning on joining or discussing joining the server.
PETR SPACEK: Yes, please. Thank you very much.
BENNO OVEREINDER: Thank you again.
(Applause)
STEPHANE BORTZMEYER: Okay. First, the question, how many of you do know the word 'fediverse'? Okay, let's see if I can...
As we know, the Internet that we manage and we use everyday is decentralised which means that practically no one can force people to do something at the level of the Internet. Sometimes this is something that we regret, for instance we would like to be able to push a button on everyone deploys IPv6 or RPKI or something like that. But as, you know, it doesn't happen this way.
There is no way to make everyone in the Internet do the same thing. It can be regrettable but it can also be a good thing because otherwise there would be a risk of capture of the Internet, and if it were possible to do something at the level of the Internet, it would be possible for good things but also for bad things. So it's a good thing that the Internet is decentralised. But there is a paradox. That users today very often, on the top of the decentralised network, use centralised system to communicate. Facebook, g‑mail, Twitter, etc., etc.. this is bad for freedom of speech because there is a risk of censorship by one of the actors. It's bad for user control of their own life. This is bad for resilience, if one of these big silo gets down, well a lot of things break. It's also bad for privacy and I think that at this RIPE meeting, it's we have GDPR mentioned at every talk, so here you should add GDPR on this slide.
So on the other end, using decentralised systems is not mandatory. I mean, we have been using decentralised way of communication a long time ago, e‑mail is a typical example, but use net for the really old people among us, use net was also a social network of communication which was completely decentralised.
So the idea of the fediverse is having a decentralised way of communication, particularly it's mostly a computer for Twitter but it can be used also for other usage.
Fediverse is name which is quite recent. The Wikipedia page is less than one year ago. And it's not a terminology that is completely used by everyone.
My personal definition is that the fediverse is a set of servers running the Activity/Pub protocol, so changing activity information. The best known implementation is mast owe done, and because of that many people mix fediverse is mast done, but actually there are other interpretable implementation such as peer tube, GNU social, etc.
So what do you do with the fediverse? Basically, you exchange short messages in the master domain world they are called toots, you can call them whatever you want. And, of course, because this is the Internet, the main usage is sending pictures of cats. Sometimes dogs, but not so common.
So here you have an example of one of the interfaces, the fediverse is not a software, it's a set of servers using compatible protocols so this one is just one software. People saying this things, reply to each other, discuss, post pictures or URL etc.
Some technical details, because probably it will interest you.
Servers in the fediverse are called instances. The last count there were around 2800 of them but of course it's very difficult in a decentralised network to know how many there are. The vast majority are [Mastodon], something announced typically 1 million accounts, but of course as you know it means something because some acronyms are there, things like that. They rely on the Activity/Pub protocol ‑‑ who knows about Activity/Pub? It's a W3 system, so I think the correct word is recommendation, something like that, let's call it a standard, well I don't like it, it's complicated. It's missed a lot of things. But it works. It works ‑‑ I mean, many implementations independently run Activity/Pub on they exchange message so it works.
One of the points to be reminded of is that cannot participate in the fediverse just with Activity/Pub. Activity/Pub is only there to get activity information. You need something like web finger to get information about people to subscribe to the timeline etc.
In a decentralised networks cannot have just one name space to you need some way to have addresses which depend on the instance, so, a fediverse address is user name at name of the instance. Here, you have my address if you want to subscribe to my timeline.
Funny is that it's one of the few place where is people actually use the new TLD like .pzl so you can see a lot of funny names in the fediverse.
Because all the software used for the fediverse have an API, you can develop bugs. This one is a DNS resolver bot. Another example of the DNS is trending. You send a domain name on the domain type to the bot and then it replies with information on some details, for instance, that this was authenticated by DNSSEC. This one is for DNS and I'm waiting for someone to develop the same for BGP. You send a prefix to the bot and it replies with information from RIPE Stat, Hurricane Electric, Curator, etc., etc..
Consequences of having a decentralised social network. Some are good and some are not so good. The good thing that cannot censor everything. There is no way to terminate conversations from people everywhere. Each instance is free to have its own rules. Also an important thing for network operators is that the traffic will become more symmetric. Many of the problems of the Internet come from the fact that there are very different actors, eyeballs and providers of content which create a lot of problems, for instance, with network neutrality. If the traffic is more symmetric, everyone sending and receiving there will be less problems. That's a good thing with decentralised social network.
Also, there are some bad things for instance. Instance admins, people who manage the servers are not by itself better than the tweet error Facebook admins. The fediverse is just a tool. People who use this tool, some are good, some are bad, some are really bad, anything can happen. But the good thing is that you can choose. The user can choose an instance which feeds his/her personal choices. Also the fediverse is a bit more complicated to explain to the user. So when you want to explain to the users what's going on, you have to explain first you need to chose an instance, then to create an account. It's a small political problem but it's no different from what we have done with e‑mail for instance.
And, of course, outsource some stupid thing. My favourite one is custom images, so you can create images that are not standard with a picture and then when your use use them, they are sent to every other instance of the fediverse with a picture, which allows people to do really, really stupid things.
But that's the price of freedom. Thank you. And if you ask questions, or criticism, etc.
BRIAN NISBET: Thank you very much. Do we have a quick remark, or otherwise?
AUDIENCE SPEAKER: Maxime. I have one comment and one question. The comment is that we are still looking for peer to peer social network. I hope it will be soon. Because of censorship, is quite good now and the government can censor just websites so it will be censored. The question is there a comments in the discussions, is it supported? Is there a possibility of three of comments in some discussions?
STEPHANE BORTZMEYER: Do you mean you want to moderate the comments?
AUDIENCE SPEAKER: No, tree, like a tree.
STEPHANE BORTZMEYER: Yes, Activity/Pub one of the message is a message and you have a thread and the software can organise a message according to this thread.
AUDIENCE SPEAKER: It's very good. It's that I miss in Facebook, actually. Thank you.
(Applause)
BRIAN NISBET: Thus ends the Plenary content from the Programme Committee for RIPE 76, so now we have the meeting technical review from Meno.
MENNO SCHEPERS: So, I'm not going to have a talk about GDPR, but a technical report.
We are the ops team: Brian, Colin, David, myself, Razvan, Marco, Sjoerd and Xavier...
(Applause).
All these pictures are complying to the GDPR.
So, I want to say, sum up some of the things we were doing.
We set up the technical part of the meeting, which includes the webcast, network and Wi‑Fi, and the presentation kit that's being operated over there, and we do tech support during the whole week. That is quite a lot of work, so...
There is a GM ‑‑ we had a webcasting issue during the GM, most of you didn't notice because you are here. People in Amsterdam and other countries, of course, were watching remotely and noticed that there was some stuttering in the webcast which made it actually difficult to follow. There was actually not a problem here with the webcast, but over in Amsterdam, where our server is, there were some network issues. There was a saturation of the network that caused the webcast not to work properly. The problem is solved but yeah, that was huge, of course, during the GM. It's solved now, but that was a pity.
Then, I want to thank our sponsor for the network, Jaguar Network, because as you have seen in the last week, we enjoyed a very good connectivity from them and together with our Wi‑Fi network, I think most of you guys had pretty good connectivity here. And otherwise, I'd like to know about it, but maybe you can send those in e‑mail or if you have any comments on that.
And then onto the Wi‑Fi. The Wi‑Fi actually we got new access points. These are Ubiquiti access points. We tested a couple at the last RIPE meeting in Dubai and we were quite confident about them so we decided to roll them out, all of them here in Marseille. This is a little bit the layout you see there, quite some in the main room here and the side room in the right corner. But this is ‑‑ it's all been running fine and we're quite happy with it. You have seen the RIPE MTT network. There is also a 2.4 gigahertz network for the people with the legacy equipment, and the NAT 64 network is there as well. I think lots of people have been using it. There is even people that want us to make a domain SSID.
So, we set up, during the start of the week we set up some Grafana graphing. We were just configuring this on the spot. Colin was doing that. And it started to look really really nice, but then we had a small problem. There were some rainy days, and actually, we suffered some weather damage and we got two servers that are running VMs so they are load balancing the important services and so this one, you guys didn't notice anything happening because the DNS resolvers are load balanced and critical services are running on both of these servers. But the Grafana graphs that we were setting up from on this server and so I can't show you any more than this picture, this screen shot we took.
Any ways... we had to protect our last server, you know. So during the day we decided to put this here, because we could not move the server during the day, and we did that later in the evening at the end of the day we moved the server to a safer location. But actually, it wasn't raining any more so we didn't have any more issues there.
I do have some graphs, two actually, showing some information. These are the IPv4 DHCP leases during the week. Friday is not there because I took this screenshot this morning, but as you can see, it's quite consistent over the last three days. Around 800 ‑‑ it's peaking at around 800, and that compared to our last RIPE meeting in Dubai, it was peaking at around 550, I think. So it's considerably more here, but I think it's also the attendance is higher here.
Also, you see this in these ‑‑ the traffic graphs. This is the uplink, and you see that usage, actually. Normally on Tuesday it's the most, and now you see that actually it's been growing every day. So... 270M is, I think it's a peak for our RIPE meetings.
And also, I wanted to show you a slide, it's my last slide, by the networking app. It's getting more popular. You see, compared to RIPE 75 and 76, I just wanted to show how much it has gone up, the usage. The web team who made the app would like to hear about your feedback, so if you have the app, please leave some feedback for them or if you don't have the app, install it, you can use it for RIPE meetings but also for other meetings we do.
That was my presentation. Any questions?
(Applause)
HANS PETTER HOLEN: Okay. So that means that we have come to an end of RIPE 76. It's been a long week. We have had long days. But we have had a lot of great presentations, and lots of good fun. So, it's another record meeting. Not only in quality, but also in quantity. We had 737 checked‑in attendees. And if you look at the last couple of meetings, that's a real increase even from RIPE 72 where we had 676. So, biggest meeting ever. If we grow by this trend, at least from the last two meetings, it will be difficult finding venues in the future. So I think we will have to find some more remote places in the future so that the barrier to get here is higher.
It's great to see that we have a lot of newcomers, almost a quarter of our participants are newcomers. Really good to see. It's also good to see that actually people come back. So, yes, newcomers are good but it's also good to see that you come back.
The mix between the participants, half commercials, so that's good. The people in the room actually making money from Internet and running network services. That's really great. And also a healthy participation from academics and even governments, we're not flooded by government representatives but at least they are present and participating, that's good.
Looking at the biggest countries in Europe, it's great to see that the US is not the biggest country in Europe as it's been in a couple of previous meetings. I am not sure why Germany is bigger than France. Maybe there are some Germans living in France, but it's really good to see that we had a solid and healthy participant from the host country. I'm a bit sad to see that Sweden is here and Norway is not, but I guess that's life. Sweden is twice as big as Norway, so, we are not able to be on that list I guess for many many years.
Thank you to the Working Group Chairs. Without the Working Group Chairs, this community would not have been what it is, because the Working Group Chairs are actually keeping us all together and doing work even between the meetings, so it's not only about getting here and doing stuff when we're here, it's also about pushing some of the work forward on the mailing lists in between the meetings.
And I would have special thanks to Sander. Sander, are you here in the room somewhere? Could you come up...
So Sander has been Working Group Chair for, I don't know how long, because I have forgotten when I stepped down as Chair of the Address Policy Working Group Chair.
SANDER STEFFANN: Eleven‑and‑a‑half years.
HANS PETTER HOLEN: Sander, thank you for everything.
(Applause)
So, I heard rumours in the Address Policy Working Group that he is not leaving us, he is looking for another Working Group but there are no indications on what.
We haven't had the results from the voting in the members' meeting in the general assembly yet so we don't know whether he will be elected as an arbiter but at least he has volunteered to continue as an arbiter, so that's great, Sander. Thank you for that.
Sander leaving, that means that Erik Bais will step in as new Chair of the Address Policy Working Group, together with Gert. And we also have a new Working Group Chair in the Connect Working Group, Will van Gulik, that joins Remco and Florence there. I think that's all the changes on the Working Group Chairs right now.
And, of course, with only the Working Group Chairs, we would only have had Wednesday and Thursday, so this meeting has been much longer, and then, therefore, I would like to thank the PC for their excellent work in putting together a really good programme. It's a long time since I have been excited myself, so I think that would be my personal thank you to you and I have heard a lot of positive things as well. So a big applause and come up...
Thank you very much guys.
HANS PETTER HOLEN: There has also been a PC committee election, and the changes are that the two members, Andre and Peter that was up for re‑election has been re‑elected. So congratulations guys.
And then who is the next ones on the thank‑you list.
Thank you for reading our minds when we don't know what to see. Thank you for being able to understand all the speakers no matter what dialect or language you are talking in. You are doing a much better job in understanding some of our ‑‑ I won't say native English speaking but that's correct but the dialect from the islands around Europe. So, without you, it wouldn't have been as easy to actually participate as it is.
We have had a new thing this time, we have had an on‑site childcare pilot and that's been a great success, I think I heard that there was in the range of five kids there and that meant that the parents, where both were interested in participating in the meeting, could actually do that while bringing their child around. So it was sponsored by ISOC, we had great feedback from the parents, and we hope to continue to do this at the future meeting given that we received sponsorship for this. This was an event sponsored by ISOC, so it didn't come out of the meeting money or the NCC budget. So this is one of the activities that's been put in place as a result of the diversity task force. It was actually suggested by one of the working group chairs that there should be a separate Lego room for adults, but that's another matter.
AUDIENCE SPEAKER: I have actually looked, visited yesterday with one, with Florence, the actual childcare, to see what they were doing and talked with the professionals that were actually attending there and taking care of it. I think it actually makes sense if we do a bit more advertising in it, with the next registration, give it a more prominent space on the website, because it might actually help because the next RIPE meeting is being to be in Amsterdam in a hotel so the venue will have proper places for where the kids can actually have some sleep as well. Other than that they do a spectacular job, so really liked it.
HANS PETTER HOLEN: Thank you for the feedback and we will make a note of that.
Diversity. Women in tech lunch. 100 participants, presentations about why mentoring matters, why there are so many women in tech in Bulgaria and hiring for diversity. So for the next meeting, how to be an ally. Quotas, yes or no? And there you go, the discussions come along. Yes, we're planning a women in tech lunch at the next meeting as well and make sure that you bring along your female colleagues not only to the women in tech lunch but to the whole meeting and especially make them submit offers to the PC because if you think that the diversity among presenters could have been better, the only way to make that happen is get more women to actually come forward with good presentations.
Then, there is the ongoing debate on how to replace me or what the process should be in the event that I were to step down. Anna Wilson had a very good summary of the discussion so far and facilitated a very good discussion here in ‑‑ before the break this morning. And I'm looking forward to seeing sort of a draft coming out of this because I think there is at least consensus on the direction that we're going in to make something up that can be presented to the list and be discussed and hopefully concluded in a not so far future so that we have at least a framework moving forward to select me if you want me to continue for the next period, and then eventually replace me if the community feels a need for that.
That's looking forward. Then, looking backwards. The previous Chair, Rob Blokzijl, was chairing this community for a long time and the RIPE NCC put in place a foundation, the Rob Blokzijl Foundation, that hands out a reward ‑‑ an award to recognise individuals that made substantial and sustained technical and operational contributions for the RIPE community and supported in development for the Internet. So, we did this by putting together an awards committee, reviewed, received ten applicants and there's been an award from the foundation at €10,000. And if you attended yesterday's dinner, you already know that the award went to Wilfried Woeber.
(Applause)
So, adding to what's up here, I can look at three or four persons that are personally responsible for putting me in this spot. Wilfried is one of them. When I showed up at my RIPE meeting he immediately put me to work as scribe in the Database Working Group. So, thank you, Wilfried, for participating and contributing over 30 years, sharing knowledge, mentoring students, bringing the next generation, over 30 years, into the community, that's really great work. Are you here Wilfried? No. We want feedback. What did you think of the meeting? This time, we made the shortest meeting survey ever, or RIPE NCC has. Five questions and there are prizes to win. Note down the URL and go in and give a response before you get lunch.
Prizes!
This is the one I can't forget. The only reason you come to this Closing Plenary is because of the prizes, right?
We usually draw the first two meeting registrations, and then I have detailed instructions here what to do. And in order to receive, to get the prize, you actually have to be in not only the first two to register but also be present here.
And then the first one is Sergey Myasoedov and the second one is Jerry Lundstrom. Come on.
(Applause)
And then in order to make it possible also for newcomers to receive a prize, we have a separate draw for the first one of the newcomers. And Jonathan Dupart? Somebody has lost something between ‑‑ no... you are coming. Great.
(Applause)
With all this photography going on, I'll make sure I comb my hair for the next meeting. Any meeting needs hosts, so thank you very much to the two co‑hosts, it wouldn't have been possible without you.
(Applause)
And, of course, to the sponsors.
(Applause)
And then see you at the next RIPE meeting in Amsterdam.
(Applause)
REMCO VAN MOOK: If you don't want to wait that long, there is an ENOG meeting in Moscow and a FC E meeting in Romania. Please welcome also to those meeting and then the meeting is adjourned, safe travels home and it's time for lunch.
(Applause)
LIVE CAPTIONING BY
MARY McKEON, RMR, CRR, CBC
DUBLIN, IRELAND.
