RIPE 82
.
Anti‑Abuse Working Group
.
19 May 2021
.
10:30 (CEST)
.
BRIAN NISBET: Good morning. It is 10:30 UTC plus 2. And this is the RIPE 82 session of the Anti‑Abuse Working Group.
.
So, I am Brian Nisbet, one of the co‑chairs of the group and the other two co‑chairs are Tobias Knecht and Alireza Vaziri. So good morning to you all. Obviously this is another virtual meeting of this Working Group. We look towards brighter days, of course, but that is where we are right now, and so we'll be using this platform to run the Working Group session.
.
We have roughly 90 minutes this morning, and we have a bunch of things to get through. Depending on how things go, I might try and have a brief break in the middle because 90 minutes is a long session, we appreciate, but we'll see how that goes.
.
So, first of all, thank you to all of the support staff, who are scribing, monitoring the chat, and the steno, obviously you have the Meetecho platform here, we also have this being sent via livestream. I would remove you ‑‑ remind you all that the chat is just chat, but it is recorded and is an official record of this meeting, so, only say things that you would like to have going into the official record.
.
If you have any questions, or you wish to speak at any point in time, you can request voice and video via Meetecho, or you can put things in to the Q&A session and one of the Chairs will read them out. So, both options there.
.
Erik, important point, the Eurovision semi‑finals results were a travesty, obviously. I have no other words for them. Ireland cast out yet again, utterly ridiculous, just have to boycott the whole thing by watching it all on Saturday evening, very strange, but a nation shocked.
.
Chat etiquette. Remains as it is, please; you know, please say who you are, if you have an affiliation, and be polite to your fellow Working Group members.
.
The talks can be rated via the RIPE 82 website. It's always useful to get information back on that and what the Working Group is interested in.
.
Moving through. Minutes from RIPE 81 were circulated, I think. They were sent out there for people. Are there any comments, questions, objections, etc.? Hearing none. In which case, are there any additions that anybody would like to make to the agenda at this point in time or are we happy to proceed with what we have?
.
(No reply)
.
And again, no, hearing nothing, and seeing nothing, we shall continue.
.
The first item we have is the Working Group Chair selection, and given the Working Group Chair in question whose term has ended is me, I'm going to hand over to Alireza at this point in time to manage this particular piece of things. Are you there?
ALIREZA VAZIRI: Can you hear me clearly? So, basically, we will talk about the Working Group Chair selection. This is the end of term for Brian, so, we set a deadline that was 7th May ‑ last Friday ‑ and the only one candidate was Brian obviously, and if there is no ‑‑ there are no objections, we are going to re‑elect, or it's better to say receive Brian as our new co‑chair. So we will talk about it in the last minute of this session. Brian?
BRIAN NISBET: Okay. I think that means I am back. Thank you all. You have me for a while longer anyway, I think. After Gert stepping down this week, I think it would have been a little too much for more than one of us to do that.
.
Anyway, we will have another both Alireza and Tobias will be up for their selection in October, so we will be doing all this again ‑‑ it seems to all happen in one year and then we have nothing for a couple of years, so...
.
Okay, let us move on then into the agenda.
.
The standing item of recent list discussion:
.
There's been ‑‑ there's been some, I think, you know, there is a number of things around, obviously the core of it was around the proposal, which certainly ‑‑ which, you know, we discussed in October. Some information ‑‑ useful information, some sharing of information. I think, today, there is an interesting cross‑post from Erik in relation to a discussion he started at Connect Working Group yesterday, which I would encourage people to look at, around abuse filtering on IXPs. That mail only arrived this morning, I'm not expecting everyone to have read it or otherwise, but are there any other points or anything else that people would like to discuss here?
.
And again, I would encourage people to take a look at the mail Erik sent this morning, and indeed the various mails that people have sent. We tend to go through patterns of a bunch of discussion and then a bit of a quieter period, we seem to be in that at the moment, but that's fine.
.
Okay, in which case we'll move on.
.
So, really, this is an open question to the Working Group, and I don't have, you know ‑‑ the co‑chairs don't have a proposed answer here. Peter, I can tell you, largely, exactly why that was done, but anyway, I'm not going to get into that right now ‑‑ so we had a discussion on abuse validation and next steps, and, you know, we had a proposal in the Working Group which didn't reach consensus, 2019‑04. So this is kind of an open question to people about whether the Working Group wants ‑‑ whether the members of the Working Group want to look at this again, whether we're leaving this kind of fallow for a little while, whether there is work that we want to do on abuse validation at the moment, or if there are other areas of policy. Michele.
MICHELE NEYLON: Morning, Brian. I think we should let sleeping dogs lie on this particular one. I don't think there is any benefit for anybody's sanity or use of time to continue to flog proverbial dead horses or continue any further discussions. If somebody comes up with something super‑duper exciting and new, then fine. But otherwise, I think our energies could be better spent elsewhere. I think the discussion around the "Bad hosters and bad traffic" and things like that is something which is probably more interesting overall, and that's something I personally would prefer to spend my time and energy on. Thanks.
BRIAN NISBET: Thank you. And I see Jordi ‑‑ thank you, Jordi, I am working on an alternative but it may take some time, and that is fine, we will be here for some time. And, yeah, I think I need to read Erik's mail properly and I think it's something that really is an important piece for the community.
.
Any other comments on that? In which case, hearing nothing, I am happy to move on. And that gives us a bit of time for a variety of things.
.
Okay. So, in which case, we will move to the first presentation, which we described certainly as an interaction. So the DNS Abuse Institute, a fairly recently setup organisation, Graeme is going to talk about it himself. Graeme Bunton, the director of the Institute, is here to tell us what they're doing and, you know, potentially we can see what we can do together between the Institute and the Anti‑Abuse Working Group and the RIPE community in general. Thank you very much for joining us at whatever ungodly hour it is where you are, and I'll let you take it away.
GRAEME BUNTON: Thanks, Brian. Can you hear me okay? Yes, was the answer to that.
.
The ungodly hour is ‑‑ it is 4:30 in the morning here in Toronto, where I am located, but that's okay, my job is global, here I am.
.
So, thank you, Brian and the Anti‑Abuse Working Group, for having me, I appreciate the opportunity to talk to you guys.
.
This conversation is happening actually thanks to our previous interjector, Michele Neylon who introduced me to Brian probably a couple of months ago now, to sort of say, hey, you guys should chat about the different things you are working on. And so Brian and I had a conversation with, I think Alireza was there as well, about what I'm up to and what this group is up to, and, boy, it really seemed like there was some overlap in our interests. So, I am going to talk to you guys a little bit today about the Institute, what we're going to work on, some of our focus, and hopefully, out of this, what we're going to have to find is that there is some really interesting areas of overlap and we should figure out ways to collaborate going forward.
.
So, let's dig in a little bit.
.
DNS abuse, and we'll come to the specific definition that we use for that in a minute, has been a real growing concern within the DNS community and the ICANN community over the past few years. Really strong call for more action in this space, and not a lot of coordination inside the registry and registrar community. Actually, maybe that's a good point for me to introduce a little bit about myself.
.
So, I am Graeme, I am the director of the Institute. The Institute was created in February now, and I came on board to lead it then. I spent the previous ten years working for a large Toronto‑based domain registrar called Tucows, I can see there is Alex from Tucows on this call, it's a member of RIPE as well as other naming communities because it's a, you know, a large organisation. Anyway, I spent a lot of time at Tucows involved in the ICANN space and working on Internet governance and DNS policy. I spent four of those years as Chair of the registrar stakeholder group within ICANN, so ostensibly leading the registrar community, and, you know, had this broad purview of issue areas to be concerned about, including DNS abuse.
.
And it was clear to me at that time, you know, so I'm leading the registrars, DNS abuse is coming up a lot in conversations, that no one is dedicated to tackling this problem at least for the naming community. And there is some real gaps, some real substantial issues that aren't being worked on, and some of that is just the structural impediments of the way that community works. Within an ICANN context, people often see registrars as a relatively uniform group of similarly interested parties, but the day to day reality of that is that's not true. There is a lot of variety inside of the registrar community, and, for the most part, registrars are pretty fierce competitors with each other. It's a very high volume/low margin business, and registrars spend a lot of time trying to essentially get each other's customers because there is only limited growth within the market place, and so the idea that everybody is going to work together to find collective solutions to a collective problem just doesn't really happen.
.
So there is a real lack of, like, coordination and really being able to work together on these issues.
.
And so ‑‑ maybe another piece of that is also that it was no one person's problem to really do that work of trying to bring people together. ICANN has some role in the community to do this, you know, they have the compliance function, but they are contractually limited in their purview, and even as Chair of a stakeholder group, I didn't have the time or resources to really dig into this, I had other things on my plate at Tucows and so did everybody else within the community that cared about this but didn't have the time and resources to really dig in.
.
So structural problems to really getting going here, no one dedicated to it.
.
PIR ‑ Public Interest Registry ‑ who run .org, they are a not‑for‑profit and have this thing in their mission where they are serving the public interest. They had done some work on something called the Framework to Address Abuse, which was a document I worked on back when I was working for Tucows, to try and address ‑‑ to do a couple of things: So set a definition for DNS abuse; to prescribe very broadly action on it, you know, what we think a responsible registry or registrar should do. It also carved out some really harmful content issues, CSAM, human trafficking, sale of opioids, that it also thought responsible registries and registrars would act on, should act on, but I will say that the Institute is not concerned with those, what I would call content issues; we're really concerned with the other component
.
So the history of this document, and so out of that, PIR was really well positioned to create the Institute and fund it and so they are behind it entirely right now. The Institute is not a membership‑driven organisation. I don't need funds to go do what I'm going to go do. I have them already. We're going to go do wonderful things, to make the Internet better, and I don't need anybody else's money to help me go and do that, which is great. So I get to come in, have no commercial interests, just show up, understand what the problems are inside the community and then go make a difference.
.
In my conversations with Brian, and others from the numbering communities, it seems like there is a lot of overlap in the issues with technical abuse as they impact us. Similar issues with coordination. Similar issues with standards of evidence. Similar issues with standardised reporting, so that everybody is getting the right information at the right time to the right place so that the appropriate people can do something about it.
.
And so part of this conversation, I think, is to sort of say this is what we're up to and maybe find some opportunities in the future, plant the seed in your heads and say, right, those are the same problems on very similar types of abuse, maybe there are ways to keep working together.
.
So, the Institute was created around three pillars:
.
Education, collaboration and innovation. Should be relatively straightforward.
.
Education is going to be resources for registries and registrars on what is DNS abuse, what are best practices for dealing with DNS abuse.
.
I suppose resources for people who are reporting DNS abuse which is going to be intellectual property, law enforcement, Internet security experts, making sure that everybody is on the same page about what these things are and how to deal with them and ensuring that that's also tailored to the DNS community. And I don't think it's a big stretch to adjust some of that stuff as we produce it for the numbering community as well.
.
Collaboration: I think it's two things. One, it is essentially what I'm doing right now, it's reaching out and making sure that interested parties are talking and communicating and sharing ideas. It's also, I think, going to be something I try and bake into the way the Institute works which we will try and offer comment periods to our work, where we will propose an initiative and we will get interested parties' feedback so that we can ensure we're, you know, responding appropriately to the needs of the community we're trying to serve, and so, to me, this is like an output where we are helping people collaborate and we're building tools for collaboration, but it's also a process by which we operate.
.
Innovation: This is the fun one for me, this is the one that got me to join the Institute. And this is really where we're going to do things like fund research, but also build tools, we are going to ‑‑ I don't think, you know, any fundamentally new technology needs to get created, but I think there is an awful lot of integration that can happen to make this space better. This could be things like centralised abuse for tools, it could be aggregated abuse feeds, it could be lots of things, but this is really where we're going to put our money where our mouths are and make sure that the community has the tools it needs to combat abuse.
.
Definition: This is fun.
.
Almost uniformly every time I have a conversation about DNS abuse, we end up in an argument about ‑‑ or a discussion, disagreement ‑‑ about what DNS abuse actually is. So, the way that we have defined it for the Institute is that DNS abuse is malware, pharming, phishing, botnets and spam, but spam only where it serves as a vehicle for the preceding four.
.
What we are trying to do here is constrain the definition of DNS abuse to technical harms where the domain name is integral to the abuse that it's appropriate to act at the registry or registrar level. There is of course a weakness I think to this definition, it's quite categorical and when you are digging into some of these examples, you end up with some grey areas between what is a content issue where it might have intellectual property issues surrounding it, and what is the sort of technical harm that we're trying to go after here.
.
I have got some sort of long thoughts on this and in fact I should mention here, and I'll ‑‑ once I am done talking, I'll put a link in the chat. We're running ‑‑ the Institute is running a webinar, online forum, discussion, something kind of like this, next Tuesday, a week from today at 11 eastern, 1500 UTC, where we are really just going to spend an hour and a half talking about the definition of 'DNS abuse'. It promises to be pretty entertaining.
.
So, if you are interested in this topic, please join us for that.
.
I should also add, this isn't intended to be like the only types of harm that registries and registrars and potentially people like yourselves should action. There are other types of abuse that you might feel really compelled to do something about, and that's great, go do that. This isn't trying to be a ceiling. It's a floor, if that makes sense. And I think I have got my metaphor right. It's 4:30 in the morning; I might be a little fuzzy.
.
Right. So hopefully that's a reasonably clear definition, although I have got some food for thought around this on my last slide, if I have enough time to get there.
.
How is DNS abuse reduced? You know, we have those education collaboration pieces, that's what people are working together, they are discussing, they understand what these things are, and they understand the best practices. But what I'm really talking about here is, what are the things that we could do to actually reduce DNS abuse?
.
I think that falls into two categories: proactive measures at registries and registrars and potential, you know, within a numbering community; and so proactive means something like you are detecting potentially harmful domain names upon registration, you would use something like a machine learning model for this, and, you know, flagging domains that have registrants that are, you know, have some sort of history or their information looks sketchy, it could be some attributes of the domain name itself. Often you see anything that includes a dash com inside the domain name is often used for phishing and there are common attributes that you could flag, not necessarily to like, you know, delete the domain right away but add some friction into the registration process.
.
And registration friction, in general, is another proactive method and you could do that in a number of different circumstances; for example, someone is registering 100 domains at a time. Well, maybe that, then introduces some friction. The domains don't resolve right away. You know, there is some sort of delay there. Maybe there is a heightened level of registrant verification where you are not just ensuring that they have a valid e‑mail address, maybe you are giving them a call too. And all of that is just to where you think you have a reasonable basis to do so, introduce a little bit of slowness in that process so that those domains aren't online right away and potentially causing some harm.
.
There are also reactive measures, and that is things like improving reporting so that the people actioning abuse, it could be at the registrar level, it could be at the hosting company, for example, they are getting faster reports of abuse. Those reports of abuse are well‑evidenced in that it's not just a domain name or an IP address; it's something that includes evidence for you to act on. They are deduplicated ‑‑ this was a real problem for registrars, where you are potentially getting thousands of abuse complaints a day, but many of them are duplicates, so you are spending huge amounts of time going through a long and elaborate queue of, you know, abuse tickets and there is an awful lot of overlap. And so people are using their time really inefficiently. Being able to clean that up frees more resources for more meaningful action.
.
We could also improve the action, so it could be a faster response, it could be more thorough, so once you have flagged a domain as abusive, you are now looking at who the registrant is in your information and seeing if that links them to any other domains. You are looking at these problems a little bit more holistically. Hard to do when you are triaging a ticket queue of, you know, a couple of thousands duplicative unevidenced useless complaints.
.
Responsive. One of the complaints that I have certainly heard from especially intellectual property, but many submitting abuse complaints, is that the expectation management is poor, and that makes people really bonkers where they have sent in an abuse complaint and then they don't hear anything for too long and then the response I get is unsatisfactory. Improving that responsiveness, even if they are not getting the answer they want but having some clarity there, can really reduce the tension in come of these processes.
.
So this is a slide about the things that I'm thinking about, and as I'm trying to decide some initiatives for the Institute, where are we going to spend our time and energy.
.
And I am sort of spoiling my roadmap a little bit, and I will say that my roadmap is mostly done, probably launching and sharing that publicly and looking for feedback on our sort of key initiatives and what we're really going to be focused on, in the next couple of weeks, probably before the ICANN meeting in June, but I'm really focused on maximum impact with least implementation, and I say this because I have worked at a registrar and I have seen the backlog that that registrar has and I have worked in the industry for a long time, and I have seen everybody else's backlog, and they are years long. That industry is consolidating so registrars are sort of buying each other and there are sort of less and less of them. Most of the platforms that they are trying to consolidate on were written in the early to mid 2000s, so pretty old and pretty clunky, and so registrars, and registries to a lesser extent because there are some new ones there obviously, are trying to generate new revenue, they are trying to consolidate platforms, they are trying to keep these old platforms up and running, and if what I'm proposing to begin reducing DNS abuse are things like super cool machine models or friction inside of registration processes, those are things that require integration into existing platforms, and my hunch is that getting people to write the code that needs to be written and prioritise writing that code, you know, putting Institute success on the work of others to go in and do that, I think is really folly. I just don't think anybody is going to make it as urgent as a priority as I think it is to go do that work, and so I think I would say: Here are some models, please go do those things and the adoption will be really low and it will be extremely slow.
.
So I'm really focused on, at least initially, so I think there is those are good things, I think we'll get there but my initial focus is really around the abuse reporting and mitigation processes,because I think there is a lot of low‑hanging fruit there. I think I can build tools for cleaning up reporting and best practices for mitigation, and I can provide those to frontline compliance and anti‑abuse people, and they can just go use them and they don't require these sort of elaborate integrations inside of ageing management platforms.
.
And I think there is a lot of wins there and I think we could really make the Internet cleaner and better without having to get a bunch of engineers to write code, take away from potentially revenue‑generating activities.
.
Boy, if you disagree with that, I would love to hear about it, but my sense is that's reasonably true across the industry.
.
This is a slide that I have sort of included mostly just food‑for‑thought‑wise, which is we talk a lot, going back to that definition of DNS abuse, around what is phishing? You know, where does it lead from a phish into just where, like, it's fraud? Where it copyright infringement and such? So we spent a lot of time of looking at the attributes of these different types of harms and I have been trying to think a little bit, instead of thinking about the attributes of the types of harms, what are the attributes of mitigation and so I'm trying to flip that definition a little bit around. And so what happens is, or what I think happens is, we don't speak with any sophistication ‑‑ at least within the DNS community ‑‑ about how we mitigate DNS abuse, or online harms. And the mitigation at the different layers of the Internet, as I'm sure many of, you know, you know, has different implications, where you are acting at the layer of the ISP or the CDN or the hosting company or the Cloud services provider or the registry or registrar. And so from the community I'm historically from, you know, registrars and the DNS, it is generally pretty quick, and pretty simple to address harms at the layer of the DNS.
.
You turn off a domain name, you put in a (something) and it no longer resolves. That whole domain goes dark. However, that is rarely very precise, and it's often not proportional, so that you could be impacting many other services. You know, you wouldn't turn off Twitter for a single harmful tweet. So it's not precise and it's not proportional. There might be other tools that are available to mitigate that harm, it might not be cost effective like to resolve some sort of online harm by getting every ISP around the world or in a geography to go ban a website. And we need to be a little more thoughtful in where we put this harm mitigation, at which layer of the Internet, and the way we get, I think, more thoughtful about it is to consider those attributes of the mitigation and to consider them by layer of the Internet and figure out just what it is we're trying to optimise for: Are we going to the DNS or the IP address provider or the hosting company or, you know, whatever combination that is because we think it's fast and effective, or is it, you know, simple? You know, and I think we get this wrong a lot, and I think the people that want us to act on abuse get this wrong a lot, and making sure that they are a little bit clear in what they want, I think, would be helpful.
And, really, it's about being transparent where they are saying: Go do something about this and we're saying ‑‑ and they should be upfront and say: I want you to deal with this at the domain name level because I think this is simple and quick and I know who you are. The best mitigation might actually be somewhere else, it might be at the hosting layer, but that's too complicated. And I think being a little bit more upfront about that is helpful.
.
So I am going to stop there. I am going to leave you with the slide of me looking just ridiculous in a suit jacket that the marketing team put on the slide, so you are welcome, everybody. That's my e‑mail address and my Twitter handle. If this is interesting to you, please reach out. I will continue to share with Brian and the Anti‑Abuse Working Group our initiatives as we're getting them up and running. And then I think what we're going to find is that there is some interesting places for a collaboration going forward. The sort of standards for abuse reporting and methods for reporting abuse, I think are going to be helpful for this community. And maybe we can work together.
.
I think there is maybe a question, and some things in the chat that I haven't been paying any attention to. So I'm going to turn off the slides and ‑‑
BRIAN NISBET: Leave the slide up there. Just it's good to, you know, good to leave the contact slide up there for a bit, albeit, obviously, all of it is there. Graeme, thank you very much for that, and now we would indeed open it to questions and we have got one already. So we'll read that out.
.
So, Nigel Hickson from UK DCMS asks: "Within definition, assume that a site that is pretending to be legitimate and then directs users to pornography is included."
GRAEME BUNTON: I don't know what this do with that Nigel. How is pornography not legitimate in some way?
BRIAN NISBET: Is it about the bait and switch aspect of it?
GRAEME BUNTON: I guess so. I would not put that under my definition of DNS abuse. I don't think that's a very nice thing to do, but I don't find that as really one of the technical harms that would be considered for the DNS Abuse Institute. You know, if you are registrar or a hosting company that wanted to enforce that in your terms of service, I think that's perfectly fine for people to choose to do so, but that ‑‑ maybe ‑‑
BRIAN NISBET: Nigel is asking to maybe come in and clarify.
NIGEL HICKSON: Good morning, and thank you. Perhaps I should be clearer, I do apologise and thank you, Graeme. It's not so much that it's directed to pornography, but, I mean, the examples that we're getting into the UK media at the moment whereby people are asking what the government is doing about this is where you have a legitimate site that's been phished, so to speak, say, you know, like Woman's Weekly, or it doesn't matter what ‑‑ a magazine or something like that, and then you ‑‑ people click on it and you get directed to other forms of content, it doesn't really matter, it could be abusive content or whatever, it's just that site is being fraudulently sort of impersonated to link people to some other site. Isn't that abuse in the technical sense? I mean, it doesn't matter that whether it's linking to something illegal or not. It's just ‑‑ it's being used to divert someone from what they should be seeing?
GRAEME BUNTON: I think it depends on how that is happening because that's very close to what I think people would define as pharming where you poison the DNS, so that the request for one site are being redirected somewhere else and that requires something like malware on a machine or control of the DNS infrastructure between that user's device and the rest of the Internet, and that would fall under the definition of DNS abuse. It's also the sort of rarest and weirdest of the things that we tend to include in that definition. So in the circumstances where you have what is considered pharming, yeah, we could include that. But just sort of like stock standard redirection, it would not be. There is a lot going in the chat that I haven't been following.
BRIAN NISBET: The chat is not expected ‑‑ as I said, it's there, it will be recorded, but if people have questions or otherwise ‑‑ I see Michele wants to come in.
MICHELE NEYLON: Thanks, Your Lordship. Morning, Graeme. Just I think picking up on this thing from Nigel, you have to be very, very careful about what you try to wedge into definitions of DNS abuse. Like, the whitehouse.org example somebody cited on the chat, is that nasty? Is it unpleasant? Yes, or at least I would say yes. Is that DNS abuse? I would say no. You know, I mean, there is a lot of things that people can do in the DNS that are not pleasant that might lead people to go to unexpected places, that might lead to an unpleasant end‑user experience, but it's not up to us as operators to ‑‑ I mean I would say not just police the Internet but to have some kind of PG13 version of the Internet. You know, that's not our role. So I think, you know, we have to be very, very careful. If you want to talk about, you know, something like, say, a website being hacked and then legitimate users are being redirected somewhere else because the website is hacked, that's one thing. But, you know, somebody registering nigelhickson.org.uk and sending it to Pornhub, isn't really a problem for us, or shouldn't be anyway.
BRIAN NISBET: I mean, it might be a problem, but not a problem for this particular discussion and piece. Okay, cool ‑‑ so we do have ‑‑ we don't have an infinite amount of time, but, Graeme, if you have a comment, because we have some more questions that I do want to ‑‑
GRAEME BUNTON: I think we can move on from that. I will say on the pharming issue, I guess, you know, and as I look at the things in front of the Institute that we can act on, probably pharming is a little rare, it's a little weirder, we have got plenty to do on the distribution of malware, dealing with Botnet command and control infrastructure and phishing, before we get into the sort of edgier understanding of how pharming is being used. So, as it fits the definition, yeah, but, like, probably not right away. I have got bigger fish to fry.
BRIAN NISBET: Okay. So we have three questions from Sia Saatpoor, so I'm going to bring those up and that will ‑‑ we will close the virtual mic lines at this point in time.
.
So, I am going to take these one at a time. I'm not going to ask you to remember them all.
.
Question 1 is: "How much and how far has your organisation delivered services or products to combat DNS abuse?"
GRAEME BUNTON: Not very far at all. We are three months old, give or take. We are still doing the research to figure out exactly what is going to be useful and valued by the community we're trying to serve. So we have a roadmap. We have got an Advisory Council now. We are going to be reviewing that roadmap with the Advisory Council and then really starting June I think, maybe as late as July, is where we pivot from planning to action and that's where we'll see the educational initiative start to come out. We'll really begin ramping up the collaboration, and we'll begin the long, slower work of building the tools and resources under that innovation pillar.
BRIAN NISBET: I think that probably addresses a lot of question 2 as well, but I'll just read it out:
"Talk about the roadmap and the ambitions you have, when can we expect the first or at least the prototype of the tools you want to make to combat the DNS abuse?"
GRAEME BUNTON: So, my hunch is ‑‑ I am spoiling the roadmap but that's okay I have talked about it in other places, I think the centralised reporting tool where people can go there, they can submit a report ‑‑ an abuse report and that tool figures out which registrar or registry that domain name belongs to, what type of abuse it is and therefore what information is required and it sends that to Michele, you know, to the right place, I think we'll probably able to get something like that up and running in, I would say six months to a year. I think there is a very basic v1, but, you know, probably the sort of more robust version is probably a year out. I will say that PIR, who created the Institute, are delightful, but they are not a particularly technical organisation, and so, you know, I come from a place with hundreds of engineers and there are none at PIR, and so I need to build some of this capacity in‑house or find it elsewhere to get some of the stuff done and figuring out just how tricky that will be is going to be fun.
BRIAN NISBET: And finally: "The overlap are VeriSign, ICANN and other organisations that have the same mission. How does the cooperation with these organisations go?"
GRAEME BUNTON: I have a meeting with VeriSign this afternoon. They have a very different mission, and, historically, VeriSign, without trying to cast aspersions, has been very hands‑off on things like DNS abuse, and ICANN doesn't really have a mandate here. So they have contractual requirements inside registries and registrar agreements. There is very little contractual requirements on the registrar side. There is a little bit more robust requirements on the new gTLD registry side, you know, and they certainly care about DNS abuse, and ICANN wants to, you know, interact with people to make it better. They have these sort of contractual requirements and relationships that make their ability to act in this space a little bit limited. And I also think, to focus only on gTLDs which is the purview of ICANN, is a mistake, as clearly we need to be addressing the ccTLD community, so I am certainly in some discussions with Center and other organisations that, you know, where they have conglomerations of ccTLDs and others in their naming space. So it's really about being collaborative there.
BRIAN NISBET: I said I was going to close the mic lines but Niall O'Reilly, with his hat firmly off, has, hopefully, a question you can answer very quickly, which is: "Will the tools be open source?"
GRAEME BUNTON: Good question. That would be close to my heart, I think, to do that, and appropriate to do that in a number of circumstances. I think there is going to be ‑‑ so transparency is going to be super important to me, so when we're building tools we need to show exactly how. It may not necessarily be that the code becomes open source, but I think we need to be very transparent on how things will work, and so TBD, I think.
BRIAN NISBET: Okay. Cool. We're a little bit over the amount of time I had allocated but that was interesting and important. Graeme, thank you very much ‑‑ unfortunately, we're done ‑‑ we need to move on on the agenda, but, please, there are ways of getting in contact with are Graeme, I would encourage you to do so, and, Graeme, please, if you can keep the Working Group informed of things you are doing and areas for collaboration, I mean e‑mail is obviously ‑‑ we have, in theory, infinite time for e‑mail; we do not have infinite time for this Working Group this morning. Thank you very much for coming to talk to us and I look forward to working with you in the future.
GRAEME BUNTON: Thank you very much. Thanks for having me. I appreciate it.
BRIAN NISBET: Cool. So we're not going to have time for a formal break, but obviously I would encourage people to stand up at their desk as needed, move around ‑ we haven't got cameras on you ‑ to make sure that the blood does flow.
.
We are going to move on because we have another interesting presentation. So this one is from Daniel Kopp of DE‑CIX, and it's 'DDoS never dies, an IXP perspective on DDoS amplification attacks'. Daniel. You should be able to get your video and audio up working there. Welcome to the Working Group and we'll let you take it away there. Your audio is coming through but I can't hear it. Possibly change the device and come back in again. I can hear that you are speaking, but it's basically not functional for a presentation, unfortunately.
.
There we go. Got you now. That's much better. So whatever you have done there.
DANIEL KOPP: I switched off the video. I couldn't find the slides, so we will try with our video for that.
BRIAN NISBET: If you share pre‑loaded slides there.
DANIEL KOPP: The slides are missing there. It's only the DNS slides.
BRIAN NISBET: Hopefully the ops folks are here and they can sort it. They should be there. We have them.
DANIEL KOPP: All right. Thank you for having the talk. This is actually from a paper that was sent into the Passive and Active Measurement Conference in the beginning of the year with the title 'DDoS never dies, an IXP perspective on DDoS amplification attacks'.
.
And this work was done together with Christophe Dieter, he's head of products and research at DE‑CIX, and Oliver Wofled [phonetic], he is chair of computer networks at the University of Technology.
.
And so now it looks a little bit strange with the ratio of the slide but I hope it works better for you.
.
So, yeah, maybe you ask yourself the question why we need more research on DDoS? The topic has been there for a while but I think also in the last NANOG meeting there was a discussion about why we still have DDoS attacks, so I think the paper fitted quite well into the time, and I think discussion points there were pretty good. It was that the problem was that the victims, they don't have enough view what is happening in the Internet with DDoS attacks because they are just sitting on the end and so it's kind of better for the core networks like IXPs to help them to give a view on what's happening in the Internet, basically, and do research, of course, and develop tools and mitigation tactics for them.
.
The targets that are at risk at the moment for DNS attacks are mostly gaming and e‑sports, online businesses. We see a lot of really small and short DDoS attacks which are most probably because gamers attacking each other, kicking them out of the games. Then we have more high professional targets like finance and stock market. And also political targets and critical infrastructures and of course, even in a time of a pandemic, critical infrastructures become more and more widespread, like VPN connections to companies, online exams, of course, and food delivery.
.
Of course, all the DDoS problem relies on the spoofing problem that we may all know about. I will not talk about that, but I will talk about amplification protocols that are used for generating bigger DDoS attacks.
.
There is one more detail. What is our viewpoint? We have the data from a large IXP in Europe with more than 900 networks, I think it's around 1,000 at the moment, with peak traffic at 10 terabits, and the paper gives all the details about the protocols that are used. You find a lot more in the paper. For example, there is table 1, there is all the details like average packet size, maybe you can even use them for defending against DDoS attacks.
.
Furthermore, the presentation will also talk about like the infrastructure perspective at the IXP, looking to the members that are attacked, some interesting attack patterns, and brief comparison to a honeypot dataset like it's a completely different dataset, it's like the passive dataset where they monitor the abuse of their honeypots or amplifiers.
.
So, DDoS amplification attacks, I am pretty sure I don't have to recap how it works. But just to be clear here, we just talk an amplification attacks, not about DDoS attacks that are directly coming from botnets. So this is different. So, the DDoS amplification attack, an attack I would misuse some publicly available amplifier, like an NTP server or a DNS server and then use a lot of them that have a flaw and generate huge amounts of traffic towards the target.
.
Normal client traffic would look different, because we now have to detect the DDoS attacks at the IXP, so we look into how normal client traffic would look like, so here you have a client and he receives a lot of traffic from different services, server ports. Of course it generates a lot of traffic at a single client, but from many different kinds of sources and ports and services.
.
For example, NTP traffic would be that someone would ask a few NTP servers about the time, so it would just be a really low bandwidth.
.
What we do now with the classification within our dataset, we say for known amplification protocols, we want to have a big amount of traffic at the target and specific more than 1 gigabit and for more than 10 sources and, as I said, it has to be an amplification protocol, somehow known amplification protocol that the traffic is coming from. So if this is the case, yeah, we detect that DDoS attack.
.
I mean, this is not completely free of false positives. But we did some manual inspection and we didn't find any cases where it really didn't work, but, I mean, open for discussion.
.
This is the protocols we included. We did this from our knowledge what is usually happening in the blackhole at the IXP, what kind of protocols are blackholed, and what we could find in blog posts or in reports from security companies, so there is a few old protocols like NTP, we have known from that for a while and thre's a few newer ones like arms, and discovery ‑‑ device discovery is new, or OpenVPN. And OpenVPN was just mentioned in a view forums or blog posts, that there is maybe something happening with amplification factors, so our goal was just to include them and see what is happening in the Internet like in the real world.
.
This is our dataset, we have six months and in the six months, we recorded at last more than 60,000 attacks with at least 1 gigabit of traffic. This is one plot from the paper. You can see the traffic size on the left axis and you see it spans from at least 1 gigabit to at least 100 gigabit and from the right side you can see the attacks.
.
As I said the validation was ‑‑ we also tried to include non‑amplification protocols at that time we included QUIC, at the time it was not known to be an DDoS amplification protocol but later on it turned out to be also misused, as I read, but at that time we didn't find any bigger DDoS attacks with QUIC, so this was an interesting insight. Also we took a look on to possible false positive like route DNS servers and we didn't find any route DNS server in our DDoS attacks and we manually inspected some DDoS events, just looking at the customer port rate and what was happening at the time of the DDoS and you could really see some really spiky pattern for a short duration and then it went down again. So in every point we looked, it looked really, really good with 1 gigabit of threshold is already really high for DDoS attack, because also at the IXP, we just see a few parts of the traffic. Depending on where the target is, we might not see all the traffic. So 1 gigabit, if it's just part of the traffic, it's pretty huge already.
.
So what we found first inside was that all the well known protocols are used the most for DDoS attacks. So, NTP, DNS and CLL are almost used for 90% of the attacks. There is also part of the story of the paper. All those old protocols are still there and used for a long time and they really don't go away.
.
So otherwise what we also notice and what's interesting is this memcached is again kind of a POP amplification factor. From what I saw over the time and also before the paper, it looked like that memcached was just there for a short time because it really criminals networks because the amplification factor is so huge and network that admits an memcached traffic might get problems so they shut the problem down pretty quick, but as it's seen, it's already some kind of ‑‑ moreover, what we notice is SSDP seems to be used for more sophisticated attacks. It is able to generate high packet rates, and it seems to be used for really longer in duration attacks. This was also interesting.
.
Then we have a lot of less frequent protocols. If you look at table 1 in the paper, you see that they are not used a lot but they are still able to generate a lot of traffic. So the potential is there for attackers that they use these protocols in the future.
.
It also depends on how many reflectors are in the Internet. We didn't look into that, but from the dataset we see that it is used and the table also gives insight how many reflectors on average have been used for the attacks.
.
So, then we looked into the timeline of the protocols, and, yeah, here is this very prominent number that I put in here. It's also a little bit for the paper and the conference because you have to provide also really high interesting numbers. In the beginning of our ‑‑ in the time of our study at that time, we saw OpenVPN to rise by 500%. It was also the time of the beginning of the pandemic so it's part of the question of why and what is happening here. I will also show an update about OpenVPN after that time frame on the next slide.
.
But if you look on the scale of the axis, here there is new protocols, we see ‑‑ by the way, this is attacks in one week, a number of attacks within one week ‑‑ so you see counts of attacks for OpenVPN, like 100 in peak times for one week. And if you look at the well‑known older protocols, they go up to more than 1,000. So, the old well‑known protocols, they are used in the majority of the attacks.
.
And we see, over time, DNS is pretty popular and NTP is mostly used.
.
So an update after our paper. I crunched the data again. So here you see the time frame from the paper and what happened after that. You see also what's my experience from DDoS attacks over time. It seems to be like a rollercoaster ride. Sometimes it goes up, sometimes it goes down, it depends in the time frame you look into, and maybe it will be interesting to have a time ‑‑ a really long time frame, like years of statistics, but it's really difficult to have the statistics for that amount of time. It looks like that after that, NTP traffic was ‑‑ NTP attacks had gained more popularity and DNS went down a little bit.
.
And now for the interesting statistic but OpenVPN attacks, it seemed that they gained a higher level. But of course again, OpenVPN or VPNs are used more often ‑‑ and, I mean, I am also open for discussion about false positives about OpenVPN. OpenVPN was the most difficult protocol for me to to understand. And I checked some OpenVPN connections and also the one of our company and it doesn't seem that we had false positives there, but ‑‑ or a problem with that, but again, I am open for discussions here.
.
Now, I would like to do a little poll. I would like to use the opportunity of this virtual meeting here, and on the left side, where also a check panel is, you can find a little poll and I would like to ask you the question about:
.
If you have experience with DDoS attacks, what is the most interesting for you, or what cripples you the most; is it traffic volume, packet rate or both?
.
I think in the history, packet rate was reported more often in the DDoS attacks. Before that, I think it was more traffic volume. I think the shift is because there is more DDoS mitigation companies now reporting DDoS attacks and, for them, the packet rate is of more interest. So where can we find the answers now?
.
Okay, almost most people answered it's both. Okay. And otherwise, it's almost the same, like traffic volume 70%, packet rate 30%. I think it depends really in the first point that would be probably packet rate and at one point when the line is getting full, then it's probably the volume that is the problem. So ‑‑ but that's an interesting insight. Thank you for your participation here.
.
We also take a look on to traffic volume and packet rate at a different level or different site which we painted this plot here which shows some interesting features. So we have on the one axis, we have the megabits per second and on the other axis we have the packets per second for each attack that we saw.
.
And now you see this really beautiful colours and lines, so what have we here? We have linear relationships for the most obvious attacks, like for NTP, you send some ‑‑ attacker send some packets to the server and he replies with a fixed size, or almost fixed size of packet rate back. So you always get this really linear relationship here.
.
Then more interesting we have linear relationships here for VS discovery. This seems to be the case because this protocol or this service, we have two design flaws, so you can generate two different types of replies that have different sizes. So this is why you see this linear ‑‑ two linear relationships here.
.
Then we also find non‑linear relationships. This is the case for memcached, because that depends on what is in the cache that is be replied. You have different sizes of packet rates that come back from the reflector. This is also interesting. What you also notice here for OpenVPN, OpenVPN is way on the right side of the packet rate axis, so this means that you are able, as an attacker, to generate really high packet rates, but keep the volume really low here. So ‑‑ that may be an interesting detail for OpenVPN if it's used for DDoS attacks.
.
So, then we took a look into the infrastructure perspective at the IXP. So here, we see a plot over time with all the DDoS attacks again and we have this red line, which is the customer's port capacity. So, we laid the attack to the customer port capacity but we didn't take into account if there is already traffic on this port.
.
And now we see the size of the DDoS attacks for the port capacity, and we see most attacks are ‑‑ only a few attacks are over that limit. It's just 0.18%. This also shows that this core backbone networks are ‑‑ they don't really have a problem with these kind of DDoS attacks. But if you take into account that maybe there is already 50% of port utilisation, you already end up with 26% of attacks would have crippled some networks.
.
We also asked ourselves the question what was the biggest peak time for DDoS attacks at the IXP? And we found that to be 3.6% of the IXP's peak traffic at one point in time because the IXP had to transmit the DDoS ‑‑ the combined DDoS attacks that happened at that time.
.
I mean, it's not a really high number, but it's something someone has to keep an eye on, probably.
.
So, interesting view on targets. And we found an interesting temporal attack. Here you can see in this plot on the Y axis, you see the IP addresses, /23 IP addresses from a victim's network, and you see on the X axis, you see the timeline and you see that the attack is traversing the network in the loop. So, every attack just took one minute, and then the attacker switched to the next IP address. And what is also interesting, if you take a closer look into the plot, is these little gaps that seem to be time dependent in the attacks, so there has to be something going on with maybe a script or manual intervention from the attacker or something like this.
.
So this is probably done to avoid mitigation tactics as I assume some mitigation tools need some time to react for a new DDoS attacks and maybe take a look on to IP addresses and then it takes a few seconds and then the attack was only affected for the few seconds.
Also what we noticed, that we can find high professional attacks when we look onto the IP address space that is attacked from networks. So, we checked for targets that have about around 10% to 28% of their announced IP space attacked, and then we find networks like insurance companies, banks, Cloud providers, so, yeah, this really seems to be a thing here to attack a big IP space.
.
Also, like, where you spread the take over more IP space but we wouldn't see that with our detection tactic because we need 1 gigabit to just one IP address.
Because it was also the start of the pandemic, we had a look on to VPN infrastructures under attack. For that, we used DNS dataset where we had 1.2 million unique VPN end points within a DNS dataset and then we checked that against our DDoS attack dataset and we luckily just found 39 attacks on two VPN end points. We did this just to raise awareness that, now we are working from home, we need VPN and we really need to be careful with VPN end points and that they are not attacked.
.
Same is true for my job here.
.
So then, at the end, we had a honeypot dataset that was available to us from a security company, they have like more than 10 honeypots, and we compared our datasets for the same time frame to see how many attacks are the same. And what we found is that only 8% of the attacks were visible at the honeypot that we had at the IXP. This is 33% of the targets. And the other way around, we just found 0.95% of the targets in the honeypot that are visible at the IXP dataset.
.
The explanation to that, I mean, it's interesting to look into that in more detail, but it was just the end of the paper and we didn't have the time there and we planned to do it in more detail in the future, for future work, but here our explanation was the law of visibility in the IXP dataset for the honeypot, this may be due to that we had this ‑‑ we see the attacks that is bigger than 1 gigabits, and the honeypot sees a lot of smaller attacks, and traditionally the honeypot also has scanning events that we didn't raise there, so of course it's a lot bigger dataset at that point. And the other way around; the likelihood to choose the honeypot is at some percentage, and also, the IXP has also not a full visibility of the Internet. So it's just a part, and we missed some stuff here mand also if the traffic is lower than 1 gigabit, so this is the explanation for that, but probably more potential here to gain more insight into that.
.
This will bring me to the conclusion.
.
As I said, we found that the legacy protocols are still heavily used and it would be really great if we could do something against that here.
.
Then we found this threat about new protocols with OpenVPN, but I wanted to make clear that this number, OpenVPN is not used a lot. Maybe it's just the beginning and it's not a big problem of DDoS, but something that we wanted to raise awareness.
.
Otherwise, we didn't find any severe impact on core Internet infrastructure, otherwise you'd probably have known before.
.
And we found this really different picture depending on the source you look from on to this DDoS problem. Also something really interesting to look into more detail.
.
With that, that brings me to the end. Here is the QR code if you want to look into the paper, and otherwise, yeah, I am open for questions.
BRIAN NISBET: Thank you very much, Daniel. Very interesting. So we have a few questions already. And we have a few minutes to talk about them, again not an infinite amount of time, but we'll look at them.
From Erik Bais: "Hi. I have done multiple presentations at RIPE meetings in the last years in regards to amplification DDoS attacks. As most of the larger DDoS traffic sending BGP peers are not patching their systems, did you have a look at the impact of cleaning up the peer list or asking the peers to clean up their number of amplification abusable advices to IP address ratio?"
DANIEL KOPP: No, we didn't talk to the networks ‑‑ or we didn't look into which networks had what kind of reflectors or talk to them. Maybe it's something to do. Maybe we could check for that and approach them. At one point I found one of our customers way back in the time to have a lot of memcached traffic going on, but I checked later for that, it was gone, you also need some time for them to react probably, otherwise not every of this network is connected to the IXP itself. They are sometimes further away. I think you see a lot of NTP traffic coming more from Asia and ‑‑ so this is not really that is connected to the European IXP here. But, yeah... maybe also something to look into.
BRIAN NISBET: Erik gives a link there which should be in the ‑‑ you can see it possibly in the Q&A, for you to have a look at.
DANIEL KOPP: Thanks.
BRIAN NISBET: The next one is from Gert Döring, OpenVPN developer. So two comments on the use of OpenVPN as DDoS reflector.
So: "This is mitigated by using TLS‑Off or TLS‑Crypt in your server conflict. This is recommended anyway to protect the server against crappy packet attacks. That said, we have seen this spike in May 2020 as well and I started to work on rate‑limiting patches for old configs without TLS‑Off. Since then, OpenVPN seems to have fallen out of favour with the bad folk so we're seeing far less attempts at reflection abuse. Not exactly sure on the why, though. It's not everybody has fixed their configs but even older systems do not get abused any more."
DANIEL KOPP: I think it's not a real question.
BRIAN NISBET: It's only a comment.
DANIEL KOPP: Thank you for that. Yeah, as I said, I'm not really in the detail of all this amplification protocols. I mean, we had all this list and, I mean, I really tried to check that I am really sure that there is no false positives going on, but as I said, I mean OpenVPN was the least that I'm familiar with. But maybe ‑‑ I mean, it's not a big problem, but maybe something ‑‑ if you want to, we can talk about this as well in more detail about OpenVPN, I am also interested in that, but, you know, maybe just ‑‑ I mean, it was way on the scale for packet rate, it was way on the right, so maybe it's something for interest for attackers if they are interested in generating a lot of packets without a high bandwidth. So...
BRIAN NISBET: Okay. So, from Sia Saatpoor, with no other affiliation.
.
"As you say, DDoS never dies, in fact it's getting worse and worse, what we have been doing for decades to come up with solutions to counter this and we do that again and again. Perhaps it's time to admit we are not going to win this battle and we are trying to regulate the Internet as we know to this day differently, or allow the openness of the Internet to slowly move to a closed community with members who trust each other. I am curious about how you look at these issues for the long term."
DANIEL KOPP: So I think it's important to share the insights here, that's also what we did and that's also why like our interests at the IXP right, we build in the research department and we build also tools to defend against DDoS attacks and that's why we want to gain knowledge about the problem and I think it's important to share what we know and what also security companies know about it and when we were talking about the company with the honeypots, they were also interested in what we see and what kind of protocols we see. So this is important.
.
I think it's not good to say, okay, we lost the battle here. I think what we see is DDoS attacks in one term are getting like more commercialised with booter services where you can buy them, but I think it's important to help the targets to defend to get a better defence against these kinds of attacks and I think we have opportunities to do that.
BRIAN NISBET: Yeah, absolutely. I mean, I am a hopeful kind of guy. I'd like to be hopeful. I say this ‑‑ over the course of the last week and a bit, a number of Irish ISPs have been the target of DDoS attacks, they seem to be moving through our particular piece of it, but ‑‑ yeah, we're ‑‑ it's an ongoing ‑‑ I mean, anti‑abuse, and it has been for as long as I have been involved in it, has been an arms race, and will continue to be.
.
I'm going to take one last question that's there, which is from Marek Zarychta from PWSTE.
"What about encouraging ISP to widely deploy BCP 38 enforcement for their networks?"
.
And I think this is the second ‑‑ the first bit is a question for you, potentially. The second piece is, can RIPE NCC motivate them, is not for you, but we will address that in a moment.
DANIEL KOPP: As I know from that problem, there is ‑‑ it's not that easy to deploy PCP 38. If you have different links in your network. So this is how I know it. So you try to limit the IP addresses that are sent to the Internet so that no spoofing it possible any more. So I think most of the networks know about this. I didn't do any research about what kind of networks accept or allow IP spoofing. It would be interesting to take a look into that. I am doing a bit more research on to a bullet proof hosting lately. So maybe this could be something also to include into that and take a look into that.
BRIAN NISBET: And I think the NCC motivating them, I think the NCC would ‑‑ quite apart from whether it's a solution or not, the NCC would ‑‑ I don't want to speak for them, but say it's not up to them to do that. But I would say, if you are not already familiar with the MANRS project, that that is something that definitely should be, you know, looked at and promoted across the Internet.
.
Okay. I'm not seeing any more questions. So, I will say thank you very much, Daniel, and again, you have your details there, and the QR code for it, and if people want to carry the conversation on elsewhere, then I would encourage them to do so.
DANIEL KOPP: All right. Thank you.
BRIAN NISBET: Thanks. So, I'm going to try just to bring up the ‑‑ my last sides. I like this slide mover.
.
Anyway, okay, so we're reaching the end of our slot and indeed our agenda.
.
Is there any other business that people wish to bring up?
.
I am not seeing anything. So, okay, and finally, just before we say thank you and good‑bye, just as always, we will be having a session virtually or physically, who knows what that will be, we'll see, as the year progresses, I would have confidence, he says, that definitely this time next year we'll see what RIPE 83 looks like, but certainly I'm looking forward to enhancing the hybrid meetings that RIPE has always run, that we take the lessons that we have learned from this period and use them to continue to increase participation in our meetings, both physically and virtually. But, I will just, on behalf of Alireza and Tobias, I would like to say thank you for all of you ‑‑ especially to Graeme and Daniel ‑‑ but to all of you for your participation this morning. Please do look at the mailing list, a very interesting conversation potentially started there this morning. And if there are pieces of work, if there are things you think the Working Group can do, please do, you know, e‑mail us, start the conversation, we'll look at that, it is a working group again, remember, which is very important to look at ways we can fight abuse on the networks we run and the networks that influence our networks as well.
.
So, thank you all very much. Have a great day, the remainder of this and the remainder of this meeting and we will talk to you again at RIPE 83.
.
(Lunch break)
