4pm. Side room.
RIPE 89. Security working group
BRIAN NISBET: Right. Hello. Hello and welcome to what is you know, a first. You are excited and lucky enough to be here for the first physical session of a new working group and you know, there's that whole thing in the IT industry about having sat at the same desk for a long time and worked for multiple different companies and I find myself and it's not having a slightly similar feeling today as we launch off on a new endeavour, what once was anti‑spam that we rechartered as anti abuse and is now the new RIPE security working group.
So welcome one and all to the security working group. I am Brian Nisbet with me in person is Marcus de Brun and unfortunately Tobias is not well, he will be fine but not well enough unfortunately to fly and to join us. We are half hoping he might be online but I am not sure if he will manage that or not.
So yeah, this is all very strange and new. Some things will be very similar because I am lazy and if you have been to anti abuse working sessions and anti‑spam, you will find the slide deck looks remarkably similar because again it seems to work.
So we are going to, there's a slightly strange kind of pattern through this, we are going to stake with some of the administer stuff we normally do, we are going to come back to the recharter, I am not just going to mention it and wandering off.
As I said, welcome, thank you to all the NCC staff and indeed the venue staff, the AV folks and the wonderful stenographers, indeed the Meetecho team all of whom come together, a huge number of people working in the background to make this whole meeting happen, the plenary group and working group sections, it's all awesome and thank you to all of that for you. This is a hybrid meeting. If you are in the room then there are microphones if you wish to ask questions, do things, if you are on Meetecho, you can also request browser permissions for, you can request voice or video permissions to answer your question or type into the Q and A and we'll read it out here. We should probably put a character limit how long a question we'll read out as chairs or indeed programme committee people but that's a different conversation for a different time.
This is a part of the RIPE meeting and therefore it falls under the RIPE community code of conduct, just to be aware of that. All good and positive.
There isn't a possibility to to rate the content as there is in the working group as it is for all, if you have feedback, you know, that's a way I have giving as the same way as giving it in person to us after the session or if you really have an opinion at the Mick phone, at any point in the session. That's absolutely fine.
So we have minutes from RIPE 88 that draft minutes have been circulated sometime ago. If there are no comments in the room at this point in time, I am going to consider them approved.
Seeing and hearing nothing. They are approached, thank you very much.
Approved
We updated the agenda as recently as a couple of hours ago but are there any other points anybody wants to add on the agenda, if not, we will continue with the agenda. Cool, what's the big update you ask.
Well we have rechartered, we may have mentioned this. We got a bunch of conversation in Krakow, the working group chairs went away and considered this and made a couple of tweaks to the charter, issued on the mailing list, I think I will say less discussion than we had hoped but the discussion we did have was positive so we have after consultation with the RIPE chair team gone ahead with the charter.
We are going to have a new mailing list, there was a mail sent to the mailing list during the week last week by mar Rita, we are actually going to make the hard cut over next week because I mean I am fundamentally an operations person at heart and I feel making changes like that in the middle of a meeting when everybody is distracted is a bad idea.
So the old mailing list still exists for the moment but we will make the full cut over to use the security‑WG mailing list next week once Marita and the ops team in RIPE have had a chance to rest after a busy week and the working group chairs will also have a new mailing list for people to communicate with us as well at that point in time.
You know, the names will be very obvious.
So, the charter has been there for a while, we put it up there, this isn't really an opportunity to discuss it, other people have feedback, cool. It's more just to really say it out loud and make it known and also just to address one of the points that was made in the mailing list which is the charter that we have published does not any anyway stop this working group working on policies, as with all policies in RIPE, we find a right working group for a policy, we don't just go oh we said it first. So we fine the right place, but the important point is this is still a working group making policies is part of the work that we can possibly do with you we are really hoping it will make it a bit clearer that we are talking about all areas of security, still includes network abuse, still includes improving the end user experience hopefully and stability of the internet infrastructure as we say. And we will give it some more scope and make it a bit more obvious to external stakeholders as well that this is a place, there's lots of the Venn diagram is very interesting, someone was like if I have a routing security question, who do I come and talk at that can routing exists but so do we, there's different places we can talk about things and it does depend but the working group chairs all talk to each other and we'll find the rate way there, it's not incumbent on the person who wants to bring the presentation there, I am not going to talk more about that only to say I'm happy, Marcus and Tobias and are are happy we have got to this point and we can hopefully move forward.
So again, unless there's any comments, we will indeed move forward through the rest of the agenda.
Maybe a little round of applause? Maybe a little round of applause for that. (APPLAUSE.)
It's a thing! I want to say, so thank you.
So, now that we have a working group, we also have to have working group chairs for that working group and the mere act of rechartering doesn't stop our working group chair selection process and timings haven't changed. That part remains identical from the previous working group an anti abuse so he we ran a working group chair selection process because Tobias and Marcus's terms both expired, Tobias and Marcus are the two people who put their hands up to work at working group co‑chairs along with me for another term. There was support on the mailing list, there was no dissent on the mailing list so again unless there's anyone wants to say anything in the room right now, we will consider that a done thing and congratulate them on once again being willing to volunteer and thank you for that. So yeah. Thank you very much. (APPLAUSE.)
Yeah, I mean I think recent list discussion, there has been some, we'd like to see more but it was about the charter and there was some about the charter, about the other piece, the working group chairs didn't really feel there was anything we wanted to talk about here from the list discussion but again if anybody in the room wishes to, this is your opportunity to do so.
Seeing nobody else standing up, I am going to keep talking.
But that is the end of the update part. So now we are going to move into other people talking and we are going to move first of all into our interactions piece so Hisham who I think I saw in the room somewhere, he is at the very back, so Hisham from the RIPE NCC, this is a lightning talk version of something that will be talked about more in the meeting but I will let Hisham talk about that so... you don't have to run up the steps, it's dangerous, cool.
HISHAM IBRAHIM: Hello everyone, my name is Hisham Ibrahim, I work for the RIPE NCC and I have been given five minutes of fame during this working group to do a shout out to a talk that I'm actually going doing in the co‑operation working group on Thursday.
So I don't have slides for this because the only five minutes. But just the gist of the talk would be post Covid, we have seen a lot of interest from governments in the internet that could have different reasons, either geopolitical tensions or advancing digital agendas of different countries. Now part of the work that I do in the RIPE NCC is we have a team that specialises in dealing with public policy internet governance, that team deals directly are governments and gets a lot of requests from information.
Now by governments, it's a broad term. That could be LEAs, that could be regulators, competent authorities, ministries and so on and what we are seeing is a lot more questions related to how they see and interpret the work that we have been doing here in the community to just give a quick example. The use of country codes in the database, the way that they see an interpret this, these are national sovereign resources and they want to understand why resources went down or went up because of a closure or because of transfer of stuff. Now we work with them and we explain how this works and that's usually quite useful.
However, what we are seeing more and more is increasing these kind of questions. Now one of the things that is changing as making this and until now like I said, the conversations have been useful and constructive and we are not seeing weird requests coming in for information, nothing that we can't share so we are not sharing any private data, we are only talking about publicly available data.
However, things are changing with new regulation coming in to Europe. A few things that we are still assessing the impact on the RIPE NCC like analysis two that looks into the supply chain and be Rs organisation as part of the supply chain for all our members, things like e‑evidence which will allow for more sharing of information across EU countries, however our service region has 70 something countries. 50 of them are not European. And one of the things that my team and I are looking into and trying to understand is what does it mean when we start sharing a little bit more within Europe and European countries.
What does that mean for the non‑European countries. And the idea that I would like to have some discussion about if you have time here but also in co‑operation and probably on the mailing lists is what are the principles we would like to see, some kind of information sharing like this. We are never going to give out personal data, we understand GDPR and we understand our members are in jurisdictions that also have data protection laws, how does that play out for them.
These are things that like I said I will be covering in the talk, I am happy to cover if there's any initial thoughts or suggestions here and I am not coming in with a solution but rather hopefully we agree on a direction and understanding of what we want to be doing and seeing moving forward, ahead of having to be regulated. I am happy to take any questions or thoughts at this point if there are any?
AUDIENCE SPEAKER: Speaking for myself. You are under Dutch law I think. So I think the discussion from my point of view is very easy, that the Dutch people are more or less regulating which should or must or can share or I am completely wrong.
BRIAN NISBET: So this is where like I said as currently stands, we actually have a RIPE document, 675 if I remember correctly that actually speaks to that. So under what kind of conditions do we share especially information with law enforcement agencies an and that covers you need to get a court order from the Netherlands to get that done so and that is like I said practised until now. With e‑evidence, it opens it up not just within the Netherlands but 20 something countries within the EU. Which changes the equation so everybody else was at a disadvantage, they had going through MLabs and Dutch courts, now you have twenty something countries in our service region versus fifty something that do not have that privilege, right, and as a team that looks into potential risks and understanding what this might mean for potential regulation, that we are members might be hit with, we need to look into all these options and have this discussion with our community, do we need to look into ‑‑ that document will be revised any ways and we want to add more principles or more thoughts in there an that's the discussion I'd like to have.
BRIAN NISBET: I hear the Seychelles is nice at this time of year... any other, I mean again this will be discussed, this is not something that's going to be suddenly done in the course of the next five to ten minutes. But if there are any thoughts now, obviously you speak to Hisham and the team at coffee breaks and things like that as well.
So cool. Thank you, we look forward to seeing this in co‑op tomorrow and continue to talk about and please keep us in the loop.
HISHAM IBRAHIM: I am very interested to hearing more thoughts from the group, thank you very much. (APPLAUSE.).
BRIAN NISBET: So, if we could bring Antonio's slides up please. Yeah, excellent, so we have Antonio Affinito from the University of Twente who will be talking to us about unveiling domain blocklist performance so four years of analysis. Please Antonio.
ANTONIO AFFINITO: OK. Good afternoon or probably good evening at this point. My name is Antonio Affinito, I am assistant Professor at the University of the Twente and today I will present something about domain blocklist performance and analysis over fours year, it's a working collaboration with the university in Italy.
So I think that this is like a security session so I suspect that many of you already know what the blocklists are but for the few of you who never used this blocklist so I will say that these are collections of malicious sources or suspicious domains that are used to for example block malicious websites an also to protect in this way the users in order to avoid cyber threats.
This kind of lists are basically created and maintained from a server, we can talk about companies, companies basically are creating these list and providing this list to the users in order to protect the users or to protect the companies.
Usually they require users to pay a fee but also institutions or individual contributors are creating and maintaining this kind of blocklist. It usually in this most of the cases these blocklists are provided for free so like for example institutions, are you seeing, we are using these blocklists for we fine malicious domains in our data. This is my main research interest focus on detecting cyber threat and so we were using these blocklists for our research purposes and by that we were wondering what are we using, what is blocklist can contain. Which kind of domains, how do we detect these domains and we saw that they basically differ in the detection speed, update frequency and domain overlap so then we were wondering OK, but can we analyse what they include. For this reason, we provide characterisation of the main blocklist and this was over a four year period, in particular we want to understand if the end visitor including in this blocklist are updated or are they still domains still valid domains and for this reason we use also external validation tools and we try to understand and figure out some prominent characteristics in this dataset.
We use like we analysed and collected like 13 domain blocklist for four years, so in particular it was from March 2020 until August 2024 so a little bit more than four years.
And we decide to analyse different kind of blocklist in particular this blocklist called the different kinds of categories of cyber threats, for example like the most used ones we saw are for example open phish, they include the domains associated with phishing and spam house contains different types of categories of malicious domains and cyber crime tracker contain domains that are basically related to malware or common control activities.
Of course, we are not the first ones in analysing these blocklist in general because of course there are not just the main blocklist but more in general they are like IP blocklists URL and many other blocklists, usually like the ones that we found out, they use for example honeypots in order to figure out like simulate attractions, trying to collect these to understand if they are malicious and still valid but those are, many of these works try to compare blocklist that contain the same type of category.
In this kind of work we decide to not focus on one particular category for two reasons, the first one is because of course like a particular domain name can be also used for different cyber threats at the same time so, for example, phishing domains can be used for spam and also because we were wondering like a specific blocklist, for example, Phishtank isn't including just phishing domain names, are they sure they are just phishing domain names or can we find other kind of categories. So it's research we have just started and we are still figuring out some results, we'll show you our result and in particular here we see that we started by looking at the number of domain names including in this blocklist because we collected this list for four years, so the idea was to understand how they expand or how they reduce the number of domains in response to new cyber threats because of course we know there are cyber threats every day, new kind of cyber threats every day, and it's like trying to understand their evolution.
In particular here we see like we calculated three different metrics, the total number of domain names, the second, the number of second level domains including this blocklist but also the domains with sub domains, the idea of analysing also the second level domains an also the domains with sub domains was to figure out also if this blocklist create a problem of over blocking or under blocking.
And starting from this red plot, we can see there is a decrease of number of domains over time but it's nice because we see that there is an increase of number of domains with subdomains with a number of second level domains, this is just an example of plots but another interesting aspect is relating to this one, it's also reported in other blocklists but this is just for an so the number of domains that remain constant over time at this point in the research we said OK probably because this kind of blocklist they want a specific number in their data but also because actually they never change their entries in the blocklist and actually we figure out from our study that this kind of blocklist was also like used a lot in research purposes.
But then we see also blocklists where basically that are the most used one, the Phishtank, Phishingarmy and DBL, we see increase over time, especially in DBL for the first years they were providing subdomains but focusing on second level domains, at the end of 2023 we see an increase also in the number of subdomains.
From this plot basically we saw there were some blocklists that were hiding a constant number of domains over time, some were increasing over time so then we were wondering how like how in fact they update their entries so then we calculated... in order to understand how often these domains are updating in this list, in this case I reported just three of the examples but it's of course we can expand to the other list and we see that for example in the last case, the co‑efficient is low, meaning the entries in this WHOIS are changed very often. In the second case instead we see basically the yellow crawler means that the similarity co‑efficient is very high evening that probably these domains are not updated so often or maybe because these domains are malicious over four years. It's like possibly that these domains are malicious for four years or they are and they are not detected for removed.
And in the first case for example in the case of Phishingarmy, an example we see also in other blocklists, we see a sort of, it's basically in the middle. So we see that there are like some, for some days where the similarity co‑efficient is high and for other days, basically it's low, meaning that some... remain in the blocklist for a longer period than the one of the last case but of course these entries are updated, if we compare with the second case.
So like summarising, we saw that basically there are some blocklists that are the co‑efficient is very low, for some others it's very high, so then we were wondering OK, we need to analyse this kind of domains, that they include. And for this reason, we have used the DNS data, so we have used DNS in order to get the lasting of these domains so are these domains still active or are these domains updated. And here I put like some red and green arrows and in particular with the red arrows, we can see that there are some blocklists that contain domains that are ‑‑ that were like active up to 4,000 days ago, so like their expiration date was 4,000 days ago, that's ‑‑ basically it means that this domains were never removed from the blocklist over time. In the green one, basically there's the higher probability of including at domains even though Spamhaus and Phishingarmy are the most used blocklists, in this case they contain a higher number of domains that are active but we saw are domains that are basically on the blocklist for a long period.
What about the overlap. Basically we decided now OK, if we use a particular blocklist, are we blocking all the main names related to phishing, are we safe and in this case, the overlap co‑efficient is very low in other cases, we Val waited 66 combinations of all the blocklists we analysed and only among like up to 66 combinations, only the 70% this combination exceed like 0.5 for this co‑efficient event and it's interesting because in the first case, we see basically an overlap of these two blocklists that makes sense because they include domains belonging to the same category but in the second case, so Phishtank and Phishingarmy is like very interesting because from the documentation, the second one is getting domains from the first one, but and also from other sources but actually the overlap is like very low, we were expecting something higher.
But at this point we said OK, the overlap is very low, why. It's because some other blocklists are lower, or just because they are not able to detect these domains and so from our analysis, we saw, we tried to understand the detection delay of this blocklist and it's interesting because cyber crime tracker basically is the blocklist that includes the highest number of domains with the highest number of domains internal activity more but in this case we see that the detection delay is very low, some domains are renewed after some years but they never got removed from this blocklist so basically it was they were already detected from this blocklist while some other blocklists that are more used like they never, they got it after a few days so for example after ten days or after 11 days even though they use similar methods for detection, user reports are like lower colours.
So in conclusion. What we saw is that making a comparison of the domain blocklist that we basically use a lot for our research purposes and trying to understand what is malicious over the network, this kind of blocklist of course the ‑‑ including domains that are updated or so like for many years, that's also like our interesting aspect of this domains and also the overlap is very low and especially it's low not only among the blocklist with different categories that can be something expected but it's also very low among blocklists that included the same category so we saw the example of phishing.
And so probably it's important that when we try to detect and when we try to protect ourselves as users with these kind of blocklists, we should use multi lists in order to increase our security.
That's it. Thank you for your attention.
(APPLAUSE.)
BRIAN NISBET: OK, thank you very much. Comments, questions? .
AUDIENCE SPEAKER: There is one in the Meetecho queue, we'll just grant him speaker rights I guess.
AUDIENCE SPEAKER: Hi, that was me.
BRIAN NISBET: The lights are very bright, I was pretty sure it was you.
AUDIENCE SPEAKER: Thank you for your presentation and thank you for all the good work you have done, it's very interesting.
BRIAN NISBET: Can you say who you are.
AUDIENCE SPEAKER: Sorry, my name is Roy Adams, I work for ICANN. What is the reasons I find it interesting, we have done some very similar work, we have ‑‑ I actually don't agree with the statement of work because it has been explored before but that aside, are you aware of the information of reputation blocklist in paper that we presented last year?
ANTONIO AFFINITO: No, but it's something I can for sure consider.
AUDIENCE SPEAKER: Because what is interesting and basically confirms your search and confirms our search, the conclusions are basically the same, interestingly we have used 11 blocklists and overlap only three, so it's basically a difference of sources that we use, we didn't do it over four years but a couple of months. What I will do is send you their presentation, work from sham nay and Sean Boyd from the research, from our research team at ICANN and I will introduce you.
ANTONIO AFFINITO: Thank you. Actually we check like communications of the blocklist because as I said the idea was can we identify also the means over others that belong to other types of cyber threats in blocklist are basically using for example just one category, that's why we did it but then we focused also on the overlap of the same category and also that case is like.
AUDIENCE SPEAKER: But also what's surprising is DD4 terms, we use slightly different terms, we mean the exact same thing, they overlap and I think we use churn and frequency and speed so those four terms are using the same methodology just slightly different terms. So good work.
ANTONIO AFFINITO: Thank you.
BRIAN NISBET: Please?
AUDIENCE SPEAKER: Hi... thank you for the talk. We also did research into that quite a big time ago so I think we looked at the larger number of lists and if you want to talk later, I can share what kind of sources we are aggregated and what we did analysis on. I looked at conclusions and obviously I think we have a smaller number of services, you are seeing a less overlap as you probably would increase the number that overlap with increase and from our point of view, it's not necessarily the fact that there is overlap is not a disadvantage because as long as there's some unique value, it's not a problem that two sources say the same thing. We tried to look at and this valuation was more from the quality and usefulness and we found it pretty tricky to evaluate equality of those lists in quantitative fashion, have you kind of tried to look at it from this perspective.
ANTONIO AFFINITO: You are talking probably about false positives?
AUDIENCE SPEAKER: For example, that's one.
ANTONIO AFFINITO: That's something we are still working on an the idea is to use external validation tools to check if, for example, you consider... to 260 detectors, we are trying to understand for other tools that these domains are malicious and regarding your first part, I hope if I look and bigger number of blocklist of course I can see that the overlap is like higher but some how from our analysis we see if I focus, for example, on the blocklist of phishing and the documentation, I also see this should include documentation of Phishtank, but still there are like a number of differences between this but for sure we can talk about this later. I am curious about your work.
AUDIENCE SPEAKER: Also like we also try to consider the usefulness of ‑‑ and the relevance of those lists because there is like one just because objectively the information on our list is true, it does not make it useful for us for, say, protection purposes or filtering purposes and also it might be maybe worth taking into consideration when you, for the valuation, but yeah we can talk again
ANTONIA AFFINITO: Thank you.
BRIAN NISBET: Cool. I think I meant to say of course you are here as part of the RACI project as well so thank you and that's great to see more of this and I think again the more of the interaction between the academic and where research is being done and more sharing is a very positive thing. Thank you very much
ANTONIA AFFINITO: Thank you. (APPLAUSE.)
BRIAN NISBET: So someone turned around to me and went as we were discussing things like piracy? That's what your group is getting into these days. So I would like to introduce Lee Kent Andrew Willatt from the Premier League to talk about the host of of live piracy, the good bad and not so ugly. Please gentlemen.
LEE KENT: Should have worn the mic. In the interests of time, I will just go on. So yes, brief overview, mainly this is what we are here to ask and to put to the community and the story behind all of this we are going to go into. So from BeIN's perspective, we are not just a small organisation as you can see, we have got quite a global reach, several languages and a very broad spectrum of sport content, we also do movies and TV series as well. An the reason that we are here to talk to you today is to look at this ecosystem and as you can see, digital services providers for us are the key in order to prevent the theft and criminalisation of copyright, intellectual property crime. I am going to pass over to Andrew now who will do a little bit as well.
ANDREW WILLATT: Good afternoon everybody, I am Andrew Willatt. I work in the content protection department at the Premier League in London in the UK. The Premier League is the organising body for the top 20 clubs in the competition. We broadcast our matches via broadcast partners such as BeIN media group in 189 territories in the world. And well thank you I would like to say first of all for inviting us here today to speak to the security working group at RIPE 89. So we are primarily here to let you know the issues that we face relating to IPv4 addresses that are initially validated by RIPE. We want to listen and learn and spend time with you to see if you can help us at all.
So to go back to the slides you can see. As Lee says, each week, each Premier League match what we are seeing are the same IP dresss, IPv4 addresses announced by the same AS organisations infringing our rights by delivering unauthorised live Premier League streams again and again and again.
Now there are some instances where we do know who they are, the contact information is available is sufficient and we can enter into communication with those entities. However, there are instances where the repeat infringement on a sustained basis continues and the contact information is not sufficient for us to know who owns those IPv4 addresses, what jurisdiction they are in and therefore we end up at a loose end. So those streams may be available in open websites, IP TV services but the IPv4 address delivering that media is the same underneath.
Whatever that may be and we do obviously also contact our infrastructure providers part of that delivery chain for the end user, for the viewer, but the key to it all is that media which is delivered through the IPv4 address.
And as you can see and I will pass to Lee shortly, what we are seeing and this is the data is that the vast, vast majority of the owners, the ASNs that announce those IPv4s are either RIPE members or are sponsored by a RIPE member so if we do trace those IPv4s back to the roots, it is in terms of the rears, we see it as a RIPE issue right now which is why we want to come and spend time with you and listen to you and hope that you can help us.
LEE KENT: Thank you. So the good element is that as an organisation and working with Premier League, is we have a very good reach programme and we are more than willing to talk to operators, whatever, wherever they sit in the ecosystem. Basically so we can have that good conversation. We want to understand what we are doing wrong, why those notices on reaching you and why they are not being acted upon. And some examples we have had is just because they want it in a very specific language and they want it in a very specific format and we are more than willing to accommodate that. I think as it stands from BeIN's point of view, we are delivering take‑down requests in about six or seven different formats and nine different languages, it's not beyond our capability to be able to do that, and even if that was to escalate into the tens or hundreds, we would still be able to accommodate it.
So these are good processes that we are happy to go through, we also like to work with organisations that have good repeat infringer policies as well and making sure these bad actors stay off the network. The greater issue we have is this element of DSPs, we see the same IPv4s week on week, the same domain names sitting on there, week on week, and we can't speak to anybody despite extensive research, on ground research, going to actual physical addresses and just nonexistent and we have no form of communication with these organisations at all.
The not so ugly, yes we accept that there are some traffic that passes through and they can be huge amounts of content, it's passing through. The difference is we have somebody to talk to. There is an out reach programme, we can work with those organisations and understand their challenges, big or small, and also depending on the organisation as well. More than willing to sit down and help write policies and processes in order to facilitate the take down of infringing content.
So, back to you guys, back to the community. Back to RIPE NCC. We are hoping that we are not asking for the impossible or over reaching and we simply would like a process or a level of communication that helps facilitate the protection of copyright and intellectual property on the internet.
And I think we are good for any Q and As.
BRIAN NISBET: OK. Closer to the camera, the other room gets three cameras, we just get two! So I think that is a fairly straightforward kind of statement and are there thoughts? Questions? Objections? Discussion? Please.
AUDIENCE SPEAKER: Just a little question, could you give us ‑‑ could you give us an example of what you do to find out who is responsible, maybe ‑‑ unfortunately, there's some techniques to make it difficult to find the responsible person who is request for example, if you show us what you do, it might be able to give you input into how you do better.
LEE KENT: Most clear, that's the sort of feedback we are looking for, are we doing the right thing and going through the right processes, we will do an IP look up and use the various open source databases available to us, including RIPE and RIPE state, we'll use BGP as well and basically any organ source database that we can get our hands on and that's the information we have got available. There is another session on Thursday where I will go in a little bit more detail for data base working group but if we are doing something wrong, please tell us, we would love to change it and make our lives a lot easier, to be fair.
HANS PETTER HOLLLEN: Hello, Hans Petter Hollen, I have nothing to do with RIPE and I don't know much about IP... so I just want to make sure I understand your goal or request correctly. You mentioned that it's hard for you to get names of IP address owners. Is that the goal because it seems to be PII and well, I don't know like maybe it's better for all of us to understand how you would imagine an organisation like RIPE helps exposing that information? It seems like it could be difficult for RIPE as well to do so is that what you are asking or asking something different
ANDREW WILLATT: Thank you for your question, I think it ties in the first question as well in terms of being as clear as we can about how we operate and what exactly it is we need. So essentially when we are detecting IPv4s being consistently used, when we do various look ups within the existing data base facilities that are provided, if that contact information comes back that is not as we would see it true contact information for the operator of that AS or the place of business, then we hit a dead end. Now in terms of how that changes, maybe that conversation is further down the line and what that looks like, again that would be a community decision of course, but I would hope it's in everybody's interests to, if there's IPv4 misuse that contact information could be provided in a suitable way that would allow organisations like us to have a conversation with the owner of the IP and not have to be in situations where you are taking your time like this. I hope that made some kind of sense.
AUDIENCE SPEAKER: Totally. And I would be surprised if it was legal that RIPE would just give information to people who request it.
ANDREW WILLATT: It comes under "defined contact information" obviously, of course, that's perhaps another conversation for another day, exactly what that would constitute.
BRIAN NISBET: I think you are possibly answering the question directly, Hans Peter.
HANS PETTER HOLLEN: Hans Peter Hollen, just to clarify something the previous speaker said, in the RIPE data base, there is contact information for all the registrants of the IP addresses so that is not a matter of personal information or privacy, there should be contact information, I think that's clear. What I hear you raising is regarding the accuracy of the database, it's divided into two areas, what's the registry, the responsibility of the RIPE NCC, we have just about 20,000 members and we match those automatically through a third party to business registries and we have a match of I think right now 86% of our members so we know that we can match those to a business registry, of course we don't know if that information is correct but at least this is a strong indication it is. The remaining 4% if we take out all the natural persons because we also allow natural persons, we have a match of 99%. So we are left with like 180 organisations that we are investigating. So I am pretty confident that we are able to make sure that the contact information for our members in the database is correct. Now there are two other groups of information there. One is provided independent which are PI space, that's assigned directly to end user organisations through a sponsoring Lir, they are required to have a standard contract with the LIR and we are checking that but we do not have automatic matching of all those 20,000 yet.
But we will get there.
That's the responsibility of our members. We need to check those against in order to be sanctions compliant so the reason we have a very high automatic accuracy on this level is actually a side effect of compliance, what we do not have and what the RIPE NCC cannot unfortunately help you with is the customer information for all our members.
So take your random France telecom or small ISPs somewhere up in northern Norway, they register, maybe their business customers, definitely not residential customers, and whether or not you do find accurate information there in the database that will up up to them, if we discover they are not compliant with RIPE policies to keep their registrations up to date in the database, we will follow up on that, if you find inaccuracy in the database, you can report them to us and our investigation department will investigate that.
That will be very generic answers to your questions, I am confident we will processes the place and I am confident you will find holes and that's legacy address space, while we have done a lot of clean up and have assured a lot of, we have an amount of that that is not to that level of accuracy yet an the reason RIPE Labs article on the ‑‑ articles on the details of that, there's deaf nil more work to be done.
The short version the content information for our members should be accurate if it isn't, report it to us and we will follow up with our member to make sure that it is. But the end users out there, whether that's a teenager on their PC or a small company doing a hosting service as a customer, that may be much more difficult but then you need to go through their upstream through their ISP, I hope that clarifies a bit.
ANDREW WILLATT: Thank you, thank you for all that information, it's really good to know. And as I say, we do want to learn as much as we possibly can and obviously work with you or around the best practices for content information to learn things we might be missing or to highlight the instances we had already with the security group where we still believe the content information is false or misleading but thank you.
BRIAN NISBET: More work for the lovely NCC staff who are here, there are registration services staff and on the team here at the meeting who I am sure will be very happy to talk to you as well about this.
It's built for Dutch people, it's OK.
AUDIENCE SPEAKER: Maybe I am just too short. Hi. I have a digital medusa which aims to protect the internet and defend the open global inter connect and one of the reasons that we try to avoid take downs at the IP level and network level is that because it's a very disproportional measure and could have an impact on innocent people that have not actually infringed on content. So I am wondering how much of this are you doing through UDR, this is why we came up with the domain name resolution because that is kind of a little bit less disproportionate, how much of this can be done through UDRP and processes like that and why do you have to rely on taking the IP addresses down or going through them. Thank you.
ANDREW WILLATT: Perhaps going into more detail another time how we verify the packets of data that are received via IPv4 but with kind of the multi faceted complex world of online piracy, whatever the format of that live stream is, that IPv4 address that delivers the media to the viewer is the single point of failure so one piece of action can the greatest amount of impact and that owner of the IP address, whatever server that's placed on can have that impact but obviously we are aware of the significant of proportionality and not over blocking ever but yeah, it's one we can discuss outside afterwards perhaps. Thanks.
LEE KENT: Just on UDRP, where filing on average probably ‑‑ we are filing on average ten a week, it's an expensive process and to say least, because it's linked to trademark and you have a streaming website that says hello, I want to stream, BeIN's point of view, we can't file that, we can't take that domain and we can't file a complaint against that domain. So it does come back to having the contact and being able to reach out to whoever is responsible for the IP address and say look, we are not necessarily have an issue with the IP but what you are hosting on that IP we do and therefore it comes back to that two way communication, what's your processes, what can you do about it, what's proportionate in order to make sure that other users of that IP address aren't being impacted and with you need to get to that point in the first place and that's where we are stuck.
AUDIENCE SPEAKER: Leo Vegoda. So it wasn't clear to me while you were speaking and so maybe you can clarify, are you looking for information about the subscriber or user of an individual IP address? Or are you looking for information about the operator of a network?
LEE KENT: The operator, whoever is ultimately, if you have got this subscriber to the IP address and there's a ‑‑ again, I am more than happy to be corrected and there is a contract between whoever is using that IP and actually who owns or has taken at least that IP from RIPE NCC, and the focus for us is being able to speak to the organisation who can actually do something about that. Whatever way that is, you know, if it's a case of the responsible organisation for that IP writing to their customer to say we have had numerous complaints, please do something about it and then come recourse from that, more than happy with that.
Coming back to the PII question, do I need to know who that is? Not really, I just need to know something is going to happen, if some form of action isn't going to be taken.
AUDIENCE SPEAKER: OK, that's very helpful. Thank you.
BRIAN NISBET: I think a lot of this touches on things that this working group under a previous guises has discussed, this is why we brought the abuse C contact into place. I mean there's also and this is me just speaking as me, you know, it's, will there ever a point at which there is complete accuracy of these things and that's the world we live in of people doing things and moving addresses and all of the fun an games that go with that.
LEE KENT: I am just skipping back, our aim really is to change this. And this is just the instater for one month and we'd like to change this ultimately, a small number of operators who were creating a fairly big headache for us. We can switch that around that will be really great.
BRIAN NISBET: Please.
AUDIENCE SPEAKER: Regarding the ‑‑ I was just wondering regarding the slide you are just showing, is this an indication of people actually only being from the RIPE NCC IP address space that are abusing your service or is it more the case maybe that the English football league has more of an interest within Europe.
LEE KENT: No, this is BeIN's data so this covers all of this.
AUDIENCE SPEAKER: I see. Thank you.
AUDIENCE SPEAKER: So Hans Peter Hollen again, since I love numbers and Brian mentioned Abuse‑C, this working group put in place a policy for the RIPE NCC to invalidate Abuse‑C numbers and I will talk a bit about that in the Services Working Group, but in 2019 when this started Abuse‑C project we did a manual follow up of more than 6,000 Abuse‑C contacts, this has been dropping now to around 2,000 follow‑ups a year, to verify that Abuse‑C contacts with correct.
Now of course we are then validating that they are correct but that's not any guarantee that anybody would answer those emails, right. So we can only go so far. We know that 20,000 members actually pay so the billing address or one of the other email addresses must be working if somebody sends them a question they do not want to deal with, well there is a problem on the human interaction level. Of course accuracy of the registry is important to us, we have done a lot of work both manually and all mated to automated to validate Abuse‑C content and we will continue to that and continue to do this, our goal is to complete the registry so you can get in contact, it's their choice whether they want to communicate with you or not
ANDREW WILLATT: Thank you for that again. And obviously we understand the email addresses, but in terms of if there's a physical address or location so we actually know where the entity is that we are trying to elicit a response from, again it's another conversation that we can have.
BRIAN NISBET: OK, any other comments, questions? No. I mean I think, yeah, it's a similar, it's another ‑‑ it's a variation of another similar problem but look, I think hopefully this week will be useful to you and again one of the things that we talk about and is around bringing more groups into the community into talking about this an the more conversations we can have and more input the better it will be for everybody, so thank you very much
ANDREW WILLATT: Thank you for your time everybody.
(APPLAUSE.)
BRIAN NISBET: So I think it's almost a tradition that the meeting after we recharter is shorter. Based on, you know, this being the second time we have done it so clearly it's tradition now.
Is there any other business? Anything else people want to talk about. Please, yes, absolutely.
AUDIENCE SPEAKER: Brian, can you clarify so it's clear that this working group is about security... so I am wondering where we can fit copyright infringement under this framework.
BRIAN NISBET: I mean I think it's one of those things and one of the reasons we looked at rechartering was because when we move from anti‑spam to anti‑abuse, we very much continually talked about abuse of internet resources but over time we had as anti‑abuse, we had a number of conversations, we did have presentations an conversations around copyright abuse, around pharma, around a number of things this that area, as far as myself and Marcus and Tobias are concerned, this is the place to do it within the RIPE community framework. There's obviously lots of overlaps but copyright is one of those things that copyright abuse and how you are doing it tends to end up being abuse of internet resources as well when you are doing that but as far as we are concerned, yes it is part of that and we are happy for to talk about it and if, again, the charter is not owned by the co‑chairs, the charter is owned by the working group. And the activities of the group are owned by the working group so we are here to facilitate.
So if that's something that the working group wants to talk about, then yeah.
AUDIENCE SPEAKER: Yes we should definitely talk about it. I had the impression this was the technical security issue and it would otherwise if we expand this at ICANN we see this all the time that they want to expand the mandate and include other things so yeah, I think we should definitely talk about it.
BRIAN NISBET: OK, cool.
AUDIENCE SPEAKER: I give you ‑‑ we are not done talking about security issues, we are not talking about network abuse either because while I am not special sympathy for the criminal gangs that are illegal streaming, they are paying customers badly and network abuse is something else.
BRIAN NISBET: Yeah, I mean again there are multiple over simple working group, I should have picked a different one. There are multiple overlapping pieces and look we have had on mailing list, we have the discussion of well what is, what does consensus look like when there are people who are potentially involved in the conversation who profit or are have vested interests in activities that other people disagree with and I mean very high level and you know, don't at me. The what is abuse alarm has just gone off!
So look, absolutely but we want to try and make this as broad, I think part of the thing we do at rechartering is trying to acknowledge the fact we weren't just talking about abuse of resources, we weren't talking about some of the things that I put in a charter, a while ago, not the most recent Berlin meeting but the one before that.
So evolving is important and I think the ability to talk about that. So again, you are the working group, you tell us.
We are ‑‑ it's not to abrogate responsibility, we are here to facilitate and if there's things people want, we are but an email away and I think in the times that we have been co‑chairing this, the number of times we have said no to something is extremely rare. So let's have those discussions.
Anything else, folks?
In which case, I mean this segue is beautifully into the agenda for RIPE 90, RIPE 90, Jesus! Time, linear time! Yeah, so again we will be sending out emails looking for content, discussions, policies, all of these things but that's reminder in the future, if there's something you want to talk about, the mailing list is there, it will be very new and shiny by next week, also you can just talk to myself and Marcus, we will work with you and bear in mind if you want to do a policy and discuss a thing, it's not that you have to figure it all out yourself, that's why the co‑chairs are here an the NCC folks especially around policies are here, it's not safe to go alone, so actually am aallowed to say that, is that copyrighted, who knows but seriously, the support structures are there, we want to make this community bigger, we have been doing a lot of work, we are doing more work to bring them inside and it's been talked about already, governments are there, what Hisham was saying was around what do we do before people make regulations and this is a service region unlike any more. There are 72 countries which are very different in a lot of ways and that's a conversation for over beer but it exists and no, absolutely no offence to our good north American friends but I have had people from Erin go it's simple you just do that and it's simple, you just do this, let me show you our service region, it's not just EU, even the Eurovision area, it's so much more than that and that brings complexities to of itself but I think building that community and bringing more people in, we have to keep talking and working together. On hopefully that positive note, you all get an early coffee thank you very much for coming, talk to us about more things you want to talk about and lots of things you want to do and I will see you hopefully on the mailing list and in Lisbon next year. Thank you very much.
(Coffee break)
