Archives

Anti‑abuse Working Group session
Thursday 23 May 2019
9 a.m.

BRIAN NISBET: Hello. Good morning. Welcome to the anti‑abuse Working Group session for RIPE 78. I am one of your co‑chairs, Brian Nisbet, one of our other co‑chairs is here. Unfortunately the third co‑chair alley could not make it to the meeting. The difficulties of geopolitics. So we have quite a lot to talk about this morning. I hope you are all well caffeinated. And you have tested your standing up from your seats to get to the mics, all done your exercises this morning.

Before we start and get through the agenda, the one thing is it's been 11 years since we became the Anti‑Abuse Working Group. Really got the charter done in Berlin years ago, and the co‑chairs we have been very busy with lots of things. The co‑chairs thought maybe it was time to reevaluate the Working Group. We thought maybe is Anti‑Abuse Working Group still the right name for the Working Group at this point in time? Is our charter the right charter?

So, we talked about this. We had a few meetings, we came up with a couple of possible names. We thought always talking about Abuse‑C Working Group. It's the gift that keeps on giving, we thought maybe this was a better idea, but then we thought no, we talk about BGP hijacking as well and a whole bunch of other things, maybe that's not the right name. So, more consideration and then we thought maybe Jordi's proposals and other stories Working Group was an appropriate name for us. But then we thought, no, you know, Carlow has co‑authored 2019‑03, maybe we'll have proposals, maybe that's not the right name either. Then we hit on the perfect name, which will give us content forever. E‑mail Quoting Styles Working Group. This is clearly perfect. But then we thought we're going to need five sessions at every meeting to discuss this and the proposals, the NCC will have to higher another ten people for their policy development group in order to deal with all this. So, maybe not. Maybe that's not the best idea.

So we work‑shopped it a bit more, may we should have had a competition. In the end we decided where we started was probably the best place, so welcome ladies and gentlemen to the Anti‑Abuse Working Group session for RIPE 78.

So, what have we got to talk about today? So, we did the welcome. We have just to say obviously this is all being recorded, it's being stenoed and minuted so anything you say can and will be remembered forever while the Internet keeps going. Thanks to the NCC staff and the scribe and the chat room, thanks to our wonderful stenographers keeping all of the 50 different voices they are going to hear today all in order. If you do feel the need to say anything and it's not like there is going to be anything controversial talked about today. State your name and some sort of affiliation at the microphone.

So, minutes from RIPE 77 which I'm pretty sure I sent out to the mailing list. I don't think there was any comments, are there any comments in the room now? So I'm going to consider those minutes approved. Thank you very much. And finalising the agenda.

We're going to make a small change to the agenda in that after C1, Angela's update on 2017‑02, we're then going to talk about 2019‑04 because it will keep the Abuse‑C stuff together and then we'll move on to 2019‑03. So if you suddenly feel the need to run upstairs to catch a bit of the IPv6 Working Group, you have about 15 minutes. Run!

So any other things that anybody would like to add to the agenda before we kick off? You are all satisfied with what's up there for the moment. Okay, let us move on in that case.

So, recent list discussion. A kind of covered an amount of that in my introduction, I feel. Obviously the big pieces we have been discussing are the policies which we're going to be talking about now. One thing I will say, and I have said a number of times, I realise these topics are very dear to some people's hearts, that they're passionate about dealing with abuse in the appropriate manner that they see fit on the Internet. This is really cool and important. However, I'm going to say again that the community has a code of conduct, that we are all adults living and working together on an Internet together. And I would remind you all before you post, to pause, to think and go: Does this add light to the discussion or does it just add heat? Does it in fact ‑‑ you know, are you just insulting someone who is trying to work towards the same goal, maybe via different routes but towards the same goal as you are? The recent discussion has actually ‑‑ it's not been the worst discussion we have ever had on the mailing list, which is not exactly ‑‑ it's an interesting metric. But I'm going to say it again, I am going to keep saying, it we have these discussions, people are all working towards the same goal. So please discuss the point, discuss the argument, discuss the proposal. There's been a bit of behaviour which I posted about yesterday around people replying off list with either sarkey or just insulting comments, and it just doesn't help anybody. So please don't do it. Think about it and post in useful ways. So that's ‑‑ I'm not going to get into the rest of it.

AUDIENCE SPEAKER: Good morning. I think you have touched on ‑‑ Mikhail O'Neill on from Blacknight. Long suffering member of the Anti‑Abuse Working Group which I think might be renamed to the Let's Abuse Everybody Via E‑Mail Working Group. So the mailing list, I have huge issues with the mailing list personally, I think it's become so hard for anybody to engage constructively via the mailing list that in some respects and it's no reflection on you as a co‑chair, I think you have been doing your best in a very awkward set of circumstances to try and shepherd that mailing list and thank you for your work on that, but oh my God, I mean if the mailing list is the way to interact, then I do wonder is it fit for purpose? Because the level of discourse has degenerated to a level that just leaves me scratching my head. I now from e‑mails from that list filtered on to a little corner and I go through that ‑‑ I have a look at that little corner from time to time, but most of the time I do control A delete. Because if I look at them it will drive me crazy. If we can agree that bad stuff happens on the Internet and we don't like it, that would be a basic premise for people actually joining the Working Group. If we can agree that being civil and productive and as you say contributing to the discussion is why there is a mailing list, then that would be helpful. But if the mailing list is just a place for people with far too much time on their hands to spend throwing insults around, then I'm not sure if I or other people can really continue to be members of the Working Group. So I have reached the point now where I really do feel that my time is better spent elsewhere. And that does not make me very happy. An entire thread about the posting style on a mailing list, really! I mean ‑‑

BRIAN NISBET: The point is made and taken. We do have a lot to move through. Look, I said what I said for a reason. I think that people need to look at how they are interacting with the mailing list. We don't have another method. There is a whole huge ‑‑ and we're not spending a lot of time talking about this folks, if they are short points, cool, but we're not spending time talking about this. The way the Working Groups and the RIPE community operates is the decisions are made an the mailing list and that is a community decision to change should we ever get to the point of changing that.

So, while I accept the point that you're making, and we need to improve that discourse, I am pretty sure if these policies were in another Working Group there would have been also been an awful lot of discussion and not all of that would have been ideal. So, I think we as a Working Group need to improve how we interact on that mailing list and there is reasons for what we do there. But right now, given the agenda in front of us, I don't want to open up a whole discussion about how wells we might operate. That's something we need to think about and the community needs to continually reevaluate to make sure it's the right way of doing things. But right now it is the way of doing things so we're not going to try and solve that in this Working Group.

RUDIGER VOLK: Yes, continuing on the question of using the mailing list for this kind of discussion. I was actually happy that at some point in time, when I was expecting a huge DOS attack coming via this distribution list, somehow a glitch in my mail server turned ‑‑ well, okay, resulted in me being taken off the DOS attack vector. Actually if the mailing list is consisting to an extreme large part of what should be considered politely noise, kind of it is not appropriate to consider that mailing list working tool for getting consensus and actually keeping people who can contribute and who are stakeholders and so on, to be there. What actually has to be considered are there. Check points where some summary about the process can be presented and checked by people who have ‑‑ can only spend limited time on reading and evaluating the stuff

BRIAN NISBET: There is perhaps there a piece where in those situations the co‑chairs, along with the NCC, need to look at where we are and give a better summary of points. And look, again, the point is ‑‑ no, we're not ‑‑ we're not having a discussion about the mailing list for ages, we have a lot to talk about folks, we can talk more about that. There might well be a better way of summarising. There is always I would love to see some of the comparative numbers of posts between some of the stuff we have discussed on things like 2019‑03 and 2019‑04 and some of the more controversial policy proposals that have taken place in other mailing lists and I'm not convinced that the number of mails we're seeing in anti‑abuse are actually that much different to some of the number of mails you would see on some of the other policy proposals that have happened elsewhere. Especially some of the address ‑‑ the Address Policy proposals over time. So, so noted, and I think we can look at better ways of dealing with that and better ways of making it more legible for people.

AUDIENCE SPEAKER: Alexander Isvanin, Internet Protection Society. What I have noticed in this mailing lists there was Working Groups that a lot of anonymous security experts participating in this mailing list. When discussions have started at the beginning of RIPE, everyone knew everyone, so it was kind of trust and like in other Working Groups this mailing list is crowded by people we have never seen in person and well who are pretending they are really expert on this. So that's a real difference. I don't know how to solve it but I need to mention it.

BRIAN NISBET: It's the nature of the beast, and currently the mailing list do not require you to have your passport scanned in before you participate.

AUDIENCE SPEAKER: That's bringing us a lot of issues.

BRIAN NISBET: So we're not going to change that either.

Right. That was longer than I was expecting but hey... discussion is important. The mailing list is important.

So, we're going to kick on. Because we'd all like to be done at some point today. The first thing we have is an update from the RIPE NCC from Angela on the implementation of 2017‑02. Thank you.

ANGELA DALL'ARA: Good morning everybody. I am Angela from the RIPE NCC. I am here to give an update about the implementation of the policy that was approved last year about the regular validation of Abuse‑C contacts. I was not expecting actually to be here with an update already because when we announced last year what we were going to do, we said oh we're going to be ready around the end of 2019 and I'm pleased to bring you today some better news.

What happened is that we had to validate all the abuse contacts in the database. We had almost 70,000 objects, just 67,000 more or less. They were spread between LIR organisation objects and user organisation objects and Zorz, where the different Abuse‑C was specified. And those who took the commitment to validate the new abuse contacts that were reduced by new members, new objects and to keep an eye on the updated contacts.

What happened until now, is that we validated already all the LIR organisation Abuse‑C contacts. We have more or less 22,800, because in these case things are going very fast so we have already 300 LIRs more than last week when I prepared the presentation. You can see that in total, we had to validate more than 18,000 addresses, and this generated 3500 tickets of which 1,500 ‑‑ 1400 were manually handled in why only 1,500? Because we tried to minimise the disturbance for our LIRs, so only the tickets ‑‑ only the Abuse‑C contacts that were invalid generated a ticket. And at this moment, we are left only with 60 tickets that are still open. So, this means that we can assume that only 60 of our LIRs have an organisation with abuse contacts that still appears to be invalid. Of these 60, remember more or less 40 LIRs that still or forgot to pay the membership fee, so it's possible that it is not relevant if their abuse contact is not valid because probably they are going to leave us further this year.

Still, another good update is that the Abuse‑C contacts that were registered in the LIR resources, so specified in the LIR Resources as different from the LIR organisation contact have also been completed in the validation. We had more or less 1,200 LIRs with specified contacts. We opened 200 tickets and we are now left with more or less 100 addresses that are still failing the validation. We will see in a bit how we handle differently these kind of tickets.

We are now still busy validating the end user resources abuse contacts. We have more than 13,000 addresses to check. 1,200 tickets, but how can I say, you have to imagine that also here this means that in one ticket we can have more addresses because we opened one ticket per LIR telling them you have this list of contacts to update. So, we don't know yet with how many invalid we will end up but we're almost at the end of the process so I am confident to give you an update pretty soon.

And in the meantime we are still trying to keep pace with what is new in the database, and we are checking everyday if there are new members, new data and modified data to validate and we open a ticket within 24 hours.

When we have ‑‑ while we are chasing really our LIRs to validate their organisation abuse contacts, when we have abuse contacts that are left invalid after three weeks, we add a comment in the database asking the user to refer to the sponsoring LIR or to the LIR that created the resource with a specified abuse contact for further information, because they have direct contact with that third‑party that is owning the address. The challenges for this project, as, you know, was ‑‑ were to create the minimum disturbance, so that's why we did not.open tickets for everybody but only for invalid abuses. There was a bit of a difficulty in using a very clear communication that went beyond language barriers, technical, how can I say, lack of knowledge, and the biggest problems were resource holders that were unresponsive and to detect new issues in a timely manner.

Also, handling so many tickets all in one go was pretty hard in being accurate in reporting exactly which address, when was it validated and so on. We are still working with our third‑party that is providing the automated tool because we have some issues and thanks to many of our colleagues, our LIRs that helped us to find out to spot the issues, we still have to optimise the response of the automated tool because it's very sensitive for redirection and for slow responses, so we get this network transit error that created we'll say many tickets and some of them were actually false positive, I can say something like 20% of these transit network errors were recovered spontaneously without any intervention.

We still have to tackle grey listing in an optimal way. We corrected in some cases the list of the provider of the tool about the disposable e‑mail addresses and we solved the 250 response codes.

We had nice feedback; not nice feedback. It was all good feedback in the sense that it helped us very much in working to improve our tools, and the result is that we are ahead of schedule with our implementation. We have now better updated registry. We had many resources that returned to base, many sponsoring LIRs could clean up their registry giving back resources. So many changes were implemented, thanks to this work.

What is going to come next? We hope to offer our LIRs the possibility to send a validation from the LIR portal to themselves and to the third parties. We hope to find a some to have a realtime validation in the database that is not stopping people to create objects while they are creating new assignments in the database and getting new end users. And I don't know if this is going to be welcomed because I have heard that there is discussion about a new policy. So we will see what happens.

And this is for me all. I don't know if you have any questions.

BRIAN NISBET: Okay. We do have some time for questions on this one.

AUDIENCE SPEAKER: I am very interested of course by definition about your presentation and thank you very much, it was very clear and very happy that you are very good feedback and saw this type of results. Just a question about the RIPE NCC work load, about this work of checking. I can imagine that the work load will decrease, so, year‑by‑year, because most of the work has to be held in the first year, but what's your perception of this work load is something like one year, two year, etc.? I don't realise exactly.

ANGELA DALL'ARA: For us ‑‑ so we needed external help, so we had some temporary colleagues that came to help us, three people. That really worked hard full‑time to call people, to send e‑mails, to help them update the database and I must say we were very lucky to have people that got it very fast. So, let's say that we started on the 11th March with with them and we're still busy.

AUDIENCE SPEAKER: Okay. Thank you very much.

AUDIENCE SPEAKER: Gilt, speaking for myself. First of all, thank you for that quite nice presentation. And could you go to slide number 9. So, I'm on my daily basis representing quite moderate Internet LIR and just a few minutes ago I counted how many abuse contacts are provided by me to the database, it was 70, seven zero, and all those things, all, I mean literally everyone hit my RIR. We discussed that with Angela a number of times, and I am quite happy that Jordi is standing to the mike, Jordi, keep in mind that this thing makes a lot of burden to people, and seriously, keep that in mind before proposing things which will be much, much more in terms of dealing with them.

BRIAN NISBET: We're going to be discussing that next.

AUDIENCE SPEAKER: I know. But I was quite happy to see both Angela and Jordi at the same time so that was my comment. And the other thing is that as I promised you Angela, I will try to make sure some cases just to make this tool work better just for the future releases.

ANGELA DALL'ARA: He really helped us because he had all these issues and it took time indeed to solve them and we saw that in some cases, as you see, there is still to work on on this.

JORDI PALET: Actually, I have a different question than the previous one. Is from those contacts that are validated, I mean have passioned the validation, how many are actually real contacts for the relevant abuse people in the organisation? Do you have a figure of that, even a percentage?

ANGELA DALL'ARA: No, because it was not requested by the policy to verify if the contact was exactly ‑‑

JORDI PALET: So if in my abuse contact I use contact at RIPE NCC.net it will work?

ANGELA DALL'ARA: Yes, but the ripe.net should also check in the full search where his own contact is configured just to be sure that it's not somebody else is not using his own contact. This is something you can all do in the database, you can all use the full text search to find out where your e‑mail address is registered as abuse contact.

BRIAN NISBET: I'm taking that time off the time you had to present your talk.

AUDIENCE SPEAKER: Rudiger Volk. Angela you were mentions that you put some effort into shape the communication in good ways, you were mentioning different languages and all of that. What ‑‑ the guys who are working in our company on the responses here were seeing and reporting to me, I think we did not really see good effect on that. One of the things that our LIR department reported to me when I was asking well, okay, how about the long list of problems reported, they told me ah, the mention that were prompting for the verification looked to some of the users actually like a very bad done abuse mail, I am getting everyday something like ten invitations to click somewhere for avoiding that my mailbox gets closed down or my account gets closed down, kind of I then ‑‑ I asked for an example and the example that I was shown did actually not look like a good explanation who is asking for what, for what reason. It actually looked like please click on this dubious mysterious URL and kind of the explanation why was this necessary useful, what it means, and why this can be trusted seemed to be missing to me quite a lot. Let me add to another part of what you were telling. You were telling that on the creation of new contacts, you are seeing a very high rate of not working initial data, no?

ANGELA DALL'ARA: No, no, no, that we are checking that all the new created abuse contacts are valid, so if we find an invalid, we open a ticket within 24 hours.

RUDIGER VOLK: Okay.

ANGELA DALL'ARA: It's not a high rate anyway. The new ones are not very high numbers ‑‑

RUEDIGER VOLK: Okay. What is the percentage of things that do not work there on the first spot.

ANGELA DALL'ARA: I think we have 10%.

RUDIGER VOLK: Okay. That's considerable. Kind of in the same track of asking for ‑‑ figure out what the the perspective of the recipients of stuff and what useful help is provided to them for doing the job they are supposed to do, what useful information are you providing for those who are initially setting up new contacts?

ANGELA DALL'ARA: So, I answered the first part first. I agree with you that the first validation e‑mail was a bit how can I say, bold in the sense, please click here and it was sent to the end users or the holders of the resources in parallel with an e‑mail to the LIR that was explaining everything. So now we corrected the validation e‑mail and there is a reference to the policy and a researches to the lab article in the last ones. I agree with you that in the beginning this was not done. So now it should be also more clear to the end user where the e‑mail is coming from, who is requesting and why, to click on the validation link.

Secondly, for new LIRs that are creating new, a new account, there is, in the membership form, the request to insert in the Abuse‑C a valid contact saying please be sure that this e‑mail address you insert as Abuse‑C is valid, and I think it is helping to open a ticket immediately while the request is still fresh to tell the new LIR, listen, you should validate this address because it appears it is failing our test. This is ‑‑ we see it more as a help than as a threat

RUDIGER VOLK: Okay. Kind of I certainly agree that checking immediately makes a lot of sense. Coming back three years later, obviously, is going to be not that useful. I would have ‑‑ I would request two pieces of information. One is I really would like to see assembled and example of the revamped new validation mail ‑‑

ANGELA DALL'ARA: Yeah, I can send it. We have it.

RUDIGER VOLK: And for the new stuff, my stupid question would be, you say you are pointing out that the e‑mail has to be valid. Are you explaining what that means and providing any help so that people can actually ensure that it is valid in your sense?

ANGELA DALL'ARA: No, actually not. But eventually we can add it in the description and just say that to be an e‑mail able to receive mention, a mailbox able to receive mention. I wouldn't go into too technical explanations because you know there is also another issue ‑‑

BRIAN NISBET: We absolutely have to stop now.

ANGELA DALL'ARA: I want to specify that it is difficult to give a clear communication in a short message, especially when people are not all English as mother tongue, because people with just not reading the messages, it is a challenge.

RUDIGER VOLK: URLs can be used.

BRIAN NISBET: It's a continuing process, we'll have to work to achieve that.

So, right, 2019‑04, validation of abuse mailbox, it's a thing.

JORDI PALET: Okay. So, summary of the proposal for those that didn't read it. The question that I raised just a few minutes in the mic, how many abuse contact e‑mails validated by the current policy are actually able to respond to a real abuse e‑mail? I think that was the target of this policy proposal, and for whatever reasons, we reached consensus in a slightly different thing. That means that we can have fake e‑mails, we can have random e‑mails that you find in Internet from another person that obviously is not related to the organisation, mailboxes that are never read, full mailboxes, non‑existing employees because they left the company, so, there are different situations, sometimes it's unproposed, many times probably it's not unproposed, but it means actually that the existing validation process is not useful as we should expect.

So, an automated process is fine, and I think it's providing good results but again the key question is: How much useful it is to have an automated process that when you really want to send an abuse ‑‑ when you really want to contact or reach an abuse contact, it's not reacting. So, what I am proposing is: Let's still keep some kind of automated process, but there must be at the end some human intervention.

So, what is the procedure that I am describing is basically when you start ‑‑ when the NCC starts the validation process, in a maximum of 15 days the Abuse‑C must have a response from a human, so it's still fine that the help desk has an automated process but they will detect that the mail that they are receiving is not spam, is not a DDoS or something like that, and they will forward it to a contact to a real person to respond to it. And I think 15 days is more than enough. When I initially proposed this to APNIC, I was talking about three days. So, I think 15 days is really, really sufficient time to be able to solve that.

If within those 15 days the contact responds, then it's finished. Otherwise, there are additional 15 days to escalate that response, this can be done still automatically by the NCC to other contacts of the organisation. Again, if there is a response, process is finished. Otherwise, in the middle of these two validations, the contact will be provisionally invalid, very similar to what is being done today, and if after the two periods of time it's not validated then it's declared invalid, exactly the same as we have today. The real difference is we want to make sure that it's not just verified technically, but somebody is really responding to that abuse contact. We are not saying you should respond to real abuse cases, that's an operational thing. We are saying the abuse contact must be really persisted somehow.

That's it basically. By the way, one of the things that Rudiger mentioned is having a single male. In the process I am suggesting, I am suggesting actually two e‑mails because I understand, and this comes from the discussion in the mailing list, when the previous policy proposal was discussed, that somehow you are not able to click a link, so I'm looking for a process that really avoids people thinking oh, this may be a phishing or something. So that is for the process.

So status of the other RIRs. This has been submitted to all the registries, the first one that reached consensus was APNIC. I think it was about a year‑and‑a‑half ago and they are already implementing the proposal. I think they are doing it in two phases. Phase One until June this year, for the main contacts let's say, and phase two for the assignments. I am speaking out of my memory, so, not looking into the real data of the implementation but I saw this in the presentation in the last LACNIC.

Something else very quickly. I saw the presentation from Athina yesterday, and it was very nice to see some of the points, so I just want to show you that what I am actually asking is nothing that is not already there. And we should consider that. So, it's part of the registry scope, let's say, to look into this, and if we don't have valid contacts, it's nothing. Today, we don't really know if the contacts are valid.

Thank you.

BRIAN NISBET: You're done. There is no one at the mics. So that's a good start. We have time, but let's also remember we have other things to discuss as well. I am going to say ‑‑

AUDIENCE SPEAKER: He is Telia, so orange again on the proposes for 2017‑02. So, again, thank you very much for this presentation. So, you note that we both advocate for information etc., and we are not the only ones to do that of course. Just perhaps remarks through the 2017‑02 was accepted in June. Perhaps to go further, I would perhaps have waited a little more perhaps a complete year etc., just to see the impact of the first policy proposal for the RIPE NCC in terms of work load, etc., etc. And so if we decided not to go into I suppose the details you presented the last time, it's because the RIPE NCC has a specificity, is a number, the number of members and the increasing number of members, so it's a very hard job to check. So that was a reason why. Also, on the last one, so I saw your proposal, the 2017‑02 proposes to add just one line, one sentence in the policy, yours, it's four paragraphs. Could be a good thing but I think it could be a complicated thing to analyse if it will be implemented.

JORDI PALET: I have been discussing this policy with the chairs and the staff for about one year I think. So, we agreed somehow that we can ‑‑ we need to wait for some results from the previous policy proposal. But then I realise that there is no need to wait any more, because the results of the previous policy proposal is not telling us how many contacts with really, really, really valid. That's the thing.

AUDIENCE SPEAKER: Petr Spacek, speaking for myself. Two comments. First of all I had the perception of boiling the frog. We started with 2017‑02, I have heard ‑‑ I am pretty much sure that I read the comment made by Carlos during the discussion of 2019‑03 and the comment was like, let's wait a year or two and we will see what happens after the policy will be accepted and so on. So, at that point of time, I think that this boiling frog syndrome is like clearly visible. We are doing small steps, you know, just to extend the burden put on the mailing list, so that's just one comment.

And the other thing is that, you said ‑‑ I think I understand you correctly ‑‑ you said as a comment in the previous presentation that right now it's, we are unsure if the abuse contacts is mine or the not, and I'm pretty much sure that if I put Rudiger's contact on my objects, probably that would not be noticed, because the e‑mail will be sent just once. In your proposal as well, this proposal is not going to solve this problem you mention. I don't believe that the RIPE NCC will be insane to send e‑mails to validate the Rudiger's abuse contact for every single object in the database. So if I put Rudiger's contact in my object, your algorithm will fail as well. So you are not proposing anything to resolve the problem you have mentioned. And that's ‑‑

JORDI PALET: I think that depends on the implementation. I was providing more and more and more data on the implementation and the staff told me don't put so many details, just let us know what you want to validate and that's what I'm doing.

AUDIENCE SPEAKER: Because that would be micromanaging by the RIPE NCC.

AUDIENCE SPEAKER: Michele Neylon from Blacknight. I hate this proposal. I really do. I don't see what this is actually trying to solve. I think you are covertly trying to get to something else but I haven't actually proposed that. Instead, you are proposing something that makes ‑‑ gives everybody collectively a massive headache but doesn't actually solve anything. And to say that it's not appropriate to wait to see the results of the other policy change is disingenuous, bus realistically speaking if the other policy proposal which was to do with the basic technical validation of abuse contacts were to show that if there was a very large percentage of abuse contacts he that technically did not work, then you would be getting to the same place. This, however, is creating a lot of work for the RIPE NCC. It's creating needless headaches for lots of third parties, but doesn't actually move the needle on what you are actually probably trying to get which is responsive abuse contacts. So if you want to put forward a proposal to force some form of responsiveness from abuse contacts, then put that proposal forward, tailor it, make it narrow enough in focus that people can support it, but this does not serve any purpose apart from creating headaches and I cannot support it.

JORDI PALET: There is some specifics text in my proposal about that. So I think I am covering that as well.

NICK HILLIARD: Michele has made my first point very eloquently. The proposal completely loses sight of the bigger picture which is to say that we are all very interested in trying to manage abuse within the RIPE NCC service region, but this proposal does nothing to actually do that

The second point I wanted to make concerns, what is a policy proposal? Fundamentally, there is a single policy item in this proposal, which is to say that there must be an abuse contact which is reachable by a human being, and if there isn't, then the RIPE NCC is going to close down the registry. And that's effectively what the policy proposal is. Okay.

All of the rest it have is niggling micromanagement of NCC staff, telling them exactly what this do, telling ‑‑ just telling them how to do their jobs. It's actually somewhat demeaning and disrespectful to the RIPE NCC to have to man plain their jobs for them. This is not our business as a Working Group to tell the RIPE NCC in this level of detail what they need to do. The policy proposal should contain policy which is to say a broad outline of what you want to achieve. And if your policy proposal is that you must have abuse contacts and if you don't, sorry, that those contacts are ‑‑ must be reachable by e‑mail and that if you don't we are going to close down your registry, that is fundamentally an unfair and inappropriate policy to have, which brings me to the third point which I am going to make very, very quickly.

Alex made the point on the mailing list already which is to say that if you have a policy like that, it could be taken to the courts and if it were found ‑‑ he made the point that this is disproportionate under law and any attempt to close a registry under these circumstances would be simply thrown out of court.

JORDI PALET: The response is on the screen.

NICK HILLIARD: The response is not on the screen. This refers to acts of dishonesty with which relate to the RIPE NCC and organisations which have a direct contractual relationship to the RIPE NCC. This is not about micromanagement of other people's businesses processes.

BRIAN NISBET: Do you have a response?

JORDI PALET: No.

BRIAN NISBET: We have no more than five minutes more, we have 15 minutes for discussion of this. We'll see where we have. I think Hans Petter was next...

HANS PETTER HOLEN: Speaking as Chief Information Security Officer of if I say ma a large software company. I fully agree with the big picture goal. We need to handle abuse in a responsible and efficient manner. In today, or the future, that doesn't necessarily mean having a human response. I mean, my people that have to work with a lot of stuff, they work with automation, they work with machine learning and so on. So, if you put something like this on them and it becomes a nuisance it's going to be automated. It's not going to help on handling abuse.

Now the other question I have is: Why do we need a policy to tell the RIPE NCC that they should implement what's in their mission, what's in their contract? This is a response ‑‑ this is a responsibility of the RIPE NCC. They have said we must have valid contacts. How do they implement that? Right. So what you are describing is technical implementation details. And I don't think that belongs in policies. Thank you.

AUDIENCE SPEAKER: Peter Koch, first of all this is not a policy proposal. You are not proposing policy. There is no clarity in what you really want to achieve. You are wiggling around with contacts that should be valid or really really valid. So there is complete lack of clarity and precision. It is not a policy proposal. We can argue whether it's micromanagement or not. What I consider this is an abuse of the policy process, because the bigger picture is that you try to repurpose the database here and I am completely agreeing with with what Peter said regarding the boiling the frog issue, and this is a repeated patter problem, we need to stop this on higher grounds. We can have a discussion about the purpose of the database, but the slice by slice changing of this is not the way to go. What we're missing seriously here is a common sense on what the purpose of the database is and what the policy process is for. This is an abuse of the policy process.

Regarding what's on the slides here, there is no obligation or power for the NCC to enforce random RIPE policies. If we decide or some random Working Group decide that as of tomorrow we all have to wear red T‑shirts, there is no mission for the NCC to enforce that, and I am pretty sure we'd find a working group that will come to that conclusion.

And finally, I have no interest in your success stories about forum shopping. The chain is always as strong as the weakest link and I hope this link is going to be strong and maintains its strength. Thank you.

BRIAN NISBET: Okay. I think Martin and then Rudiger.

AUDIENCE SPEAKER: Martin Levy, CloudFlare. As interesting as this is, as was said a bit beforehand, in a world of automation, the previous speaker, this goes nowhere. Our company deals with an enormous amount of abuse e‑mail, whether it be right or wrong, and it is dealt with through an automation process, and this policy existing RIPE methodology does not handle that.

I also note as a side note, when reviewing our abuse contact, because I felt that was the right thing to do at this point in time, I have removed the phone number and the fax number because it clearly isn't needed, based upon where this is going. So, I have updated my contact appropriately.

So, I throw it back at you and say no, this does not work, and that it depends on whether it's meant to be in policy or not, deal with automation, don't deal with it this way.

AUDIENCE SPEAKER: Rudiger Volk. First, let me plus to Peter and Peart and Hans Petter and so on. Then let me point out, I can see a purpose in wanting to improve the abuse processing as it is available in the wild. The Abuse‑C, at best, is an attempt to support this, but the Abuse‑C per se is not the goal that we all are after.

Now, let me turn and kind of improving the process actually is something where helpful information for people who may have to deal with abuse reports should be provided, and I'm seeing not that much of that, and stuff like that. So, let me then look ‑‑ take a nasty look at the technical details. So what you are asking ‑‑ what ‑‑ it's short ‑‑ what you are actually proposing is that we will depend on a two‑ring test implementation, and the two‑ring test implementation with this framework can actually be defeated even if you implement that truly by hiring Amazon's mechanical turk.

BRIAN NISBET: Thank you. Okay. So a lot of comments. Some questions. We're still where we are in discussion phase with this. So, thank you for proposing it. I think ‑‑ I have certainly received a reasonably clear message from the room. I don't know what it was like from the podium. So, with all that, that's one of the proposals. So Carlos is here to take the other one?

JORDI PALET: Carlos ran away. He is actually presenting this in another fora.

BRIAN NISBET: Simultaneous webcast. And this will be a lot less controversial than the one we just talked about. 2019‑03, ladies and gentlemen.

JORDI PALET: Okay. When we submitted this proposal, we made a mistake. We make a mistake because we used BGP. It's just about the the title, it's nothing else on the title. So by using BGP instead of resource hijacking many people understood that we are talking about managing your routers, and this is not about this. We agree that the NCC, or any registry, is not the routing police, but the proposal is not a matter of routing. The proposal is a matter of respecting members exclusive rights on the allocated resources. I think it's obvious if that if a member is receiving some resources from the NCC, those resources cannot be used out consent by other members. And of course, under policy compliance, so I cannot also say this is the resources I got, I give them to another member unless, for example, I am looking at the transfer policy, right.

So, we are excluding explicitly any operational mistakes. That must be very, very clear. We are not looking into that. And we are looking just for continued cases of intentional hijack. Some people discussed it in the mailing list. Just go to RPKI, MANRS, and yes, those are good. But not sufficient.

Another difficulty we have is, we sent version 1 ‑‑ I think it was middle of March or something like that ‑‑ and then we got a lot of input in the mailing list actually was really really useful, and we developed a Version 2. The problem is that we didn't realise that cannot officially publish Version 2 until there is an Impact Analysis. So, what I am actually discussing here is basically Version 2, not Version 1, and to facilitate that we have to publish this morning a difference between both versions is not so easy to look at the different because there are many many changes, thanks to the discussion.

So one very relevant point is here is whatever is the decision that we have on this policy proposal now or later, I think the discussion is useful for everyone, I think we need to understand that.

So, in Version 2 we tried to avoid use the BGP. We are talking about resource hijacking. Cannot officially change the title because that will generate a confusion which with what actually the NCC is already calling resource hijacking which is when somebody hijack your LIR account or whatever, so that's the reason we didn't change the title.

In the Version 2, we are better explaining of the process, so we explain, which a lot of data, how we go to the selection of the ‑‑ the daily verification of the cases, we decided that only victims can actually file a report. That they are only valid if in the previous six months. We have also a new transition period and avoid bogons to be part of the investigation, and we changed the way that the decision of the address is validated, is ratified so we are not any more looking to the NCC, but we look into a public consultation, so if somebody in the community say hey, you have a mistake, the case is dismissed, and we are looking also to unanimity, so just to make sure that the process is very, very very, warrenter well to warranted.

In addition to that there are different points in the process where the report will be dismissed. Okay. So, there is no possibility of making a mistake because there must be a hundred percent verification that it was intentional, and even if it's not intentional it's up to the NCC with the existing policy to revoke resources, so it must be a continued action from a member to get into the recovery process.

I was warned that I have only two minutes, I think, or already nothing.

So, the big question here is: Should we keep self‑regulating or we want someone else to come to do that job? That's the question here. Again, from Athina's yesterday presentation, I looked into different points and I am going to skip that, but I guess the slides are published already, so... so there are different aspects that were mentioned in yesterday's presentation about all this that I think it makes evident that we can go in this direction.

And Impact Analysis. Marco is going to do a draft thing on that. I need to rush because I have a flight to catch ‑‑ no, it's a joke ‑‑ I was not expecting the Impact Analysis before, so, this doesn't make any sense any more.

BRIAN NISBET: Marco is going to give a quick presentation on the very draft Impact Analysis. A very quick presentation. And then we will take comments and questions.

MARCO SCHMIDT: Good morning. Just a quick explanation. This presentation, normally when a proposal has finalised a version that he wants to put forward to the review phase, the RIPE NCC has four weeks to create an Impact Analysis. This version was finalised about four weeks ago, but we need more time. As you can imagine it's a quite complex one, it's a new topic. So we need a bit more time to estimate, probably two or three weeks more.

However, to contribute to this discussion, we want to give you a few high‑level observations and positions that we have so far.

Again, it is preliminary, and details might still change but what we want to say that in general it would be possible to implement such policy change in our framework. I'm not saying that the Version 2 is ready for it, but in general, it would work. What also is important to say that only reports that where there is suspected hijacker has resources from the RIPE NCC, he would fall under our policies and the whole system with policy violation would even work.

Such ‑‑ if ever such BGP hijack policy violation would be ratified, so it would go through the process, we will not combine it with any other reasons that could lead to termination or deregistration, so if somebody would have warning submitted misleading information that would not be combined with such constituted policy violation. And also, a single confirmed hijack meaning going through the process from reporting it, evaluating it and ratifying it will also not need to that process.

The RIPE NCC, as Jordi said, is just administering the process. The decision of all this lies with a pool of experts and there we want to put out a couple of points, that actually if such pool effects were to be created, the quantity and the quality will be very, very crucial. We looked at some numbers, it's a bit difficult to find but there is one page, it's BGPStream dotcom, that identifies about 400 events, not necessarily hijacking, but 400 events where in the last six months where ASN numbers should by the RIPE NCC were involved, so, in theory, up to two reports could be sent to the RIPE NCC, and then each report would need three experts to look at it and so on, so it could be a big number. The qualification of those experts, because many people internally and externally say look how do you define a deliberate hijack from an accident, a fat finger? Time constraints, these people will have to do this voluntarily besides their regular work, they have six weeks and they would have to take a very important decision, where somebody could sue them and so on so we have to make an insurance with all the liability issues.

And last but not least, all this thing would actually put the test to the capability of the RIPE community to self regulate so. If that pool of experts works fine, great. If it has problems with quantity and quality, there might be a Cheng.

That's it and I'll give back to Jordi.

BRIAN NISBET: Okay. So we have about ten minutes, maybe 11. I see a very similar selection of faces at the mics. If you all agree ‑‑ Daniel, you can be different. You haven't spoken before. If you all agree with each other, you can just plus one in this instance by the way, I am very happy with that.

AUDIENCE SPEAKER: Daniel Karrenberg, who hasn't spoken before. Member of this community. First of all, ten minutes is not enough to discuss this.

BRIAN NISBET: We have a mailing list to discuss this as you are well aware.

DANIEL KARRENBERG: But what I want to do is go back to very basics here. And that is take two minutes.

BRIAN NISBET: We don't have two minutes, Daniel, I am sorry.

DANIEL KARRENBERG: If you say the discussion is on the mailing list on the details, I think we should have at least some time here to discuss the fundamentals and the fundamentals are really very ‑‑

BRIAN NISBET: Go for it...and we'll see.

DANIEL KARRENBERG: This is a fundamental distinction between top‑down and bottom‑up regulation, what we're doing here. When we were very new, the RIPE NCC and this whole self‑regulation stuff was very new I was talking to a lot of governments who had a very top‑down attitude and said basically you get the authority from the IANA and you can turn off the Internet if you want, we are concerned about that. And what I responded to them at the time was that's one way of looking at it. The other way of looking at it is that the real power here is with the operators because they agree to use this particular number of pools that we use, they agree how to exchange traffic and if they decide at any one point that what we are doing is no longer serving them, they might go and have another registry system.

What we're doing ‑‑ what I'm seeing here is a fundamental shift from the model of where the operators are responsible for what they are doing, they agree on norms for what they will be doing, and that way the Internet is operated in a responsible way. I am seeing a shift from that to a top‑down attitude that will breakdown. So, I think rather than doing all this, you know, tweaking things and trying to use a crowbar to use the ‑‑ our self‑regulation as a crowbar for particular interests, we should think about how we as a community, the well meaning part of it, by individual action rather than by this crowbar thing, eliminate or at least suppress the ill intention, the malicious part of it. And we wouldn't have this problem if people would do just basic route filtering, RPKI and things like that. So, I think if you don't want this routing police stuff to happen as an operators, I think you have to make some investments there. If not, I think the future is very, very black.

(Applause)

BRIAN NISBET: So you don't just all agree with Daniel? I was not looking, so someone can tell me who was first at the mic.

AUDIENCE SPEAKER: Rudiger. Well, I'm not going along the fundamental lines of Daniel. I just cannot avoid saying I had several hicks of oh this is insane as you were going through your presentation. Quite obviously, it is not reasonable to do proposals that suppose that some process will work perfectly a hundred percent. That's a very easy thing to get alarmed. The ‑‑ well, okay, with the fundamentals I quite certainly think instead of investing into strange processes, actually more investment in actual routing security implementation and work is needed. But let me go to more insanity points where, well, okay, I have absolutely ‑‑ I do not understand why you can't change a proposal's title, well, okay, if the process doesn't allow it, just withdraw the old one and submit a new version. And ‑‑ well, okay, one point where I wonder whether actually our PDP has insanity in it because if it is true that changing the proposal text requires the NCC put in lots of work into ‑‑ what's it called ‑‑ Impact Analysis before we can actually ‑‑ before we actually can reflect on the outcome of the community discussion before getting a consensus on something. It is insane to wait ‑‑

BRIAN NISBET: Yes, the fundamental ‑‑ and that is a thing for the PDP and I totally agree, it's not that you can not change any aspect of the text. It is the ‑‑ and Marco will nod or disagree with me ‑‑ there is possibilities to change, there is a level of change which is a complete and other version of it. Your points ‑‑ I'm not disagreeing with your point I'm saying it's not quite as black and white as what you are saying. I am going to go around in something vaguely approximating fairness.

AUDIENCE SPEAKER: Michele Neylon, Blacknight. Okay. So how do I put this politely? I originally supported this proposal, and at this juncture I have to vocally withdraw all support for it. And the reason for that is that if you are incapable of articulating clearly what it is that you are proposing, then the proposal in of itself is flawed and needs to be withdrawn. Now, I agree with some of the points made by previous speakers, that at a high level, meta level, that there is ‑‑ there are issues that we as operators need to deal with, with we need to address and with we need to agree on. So, at a fundamental kind of ethical, moral standpoint, yes. What you're proposing is not a bad idea. However, the way that you have gone about this, as per your other proposal, is is fundamentally flawed. At a high level, we agree that hijacking resources is bad ‑‑ but if cannot articulate that clearly enough and narrowly enough, then the proposal is of itself problematic, and should be withdrawn. You should redraft it and then look at how to even frame it in a way that there can be agreement, or maybe take it off the table completely, and look at it more in terms of rather than a policy which can impact contractual relationships with the NCC, look at it as more of a charter that some of us might, you know, sign up to voluntarily saying in the spirit of blah, we agree to these ideas. Thanks.

JORDI PALET: I think this is the full proposal of the PDP. Are you willing to put a new proposal? We withdraw this one and start a new one?

MICHELE NEYLON: If you want my help. Sure, fine.

BRIAN NISBET: Are you withdrawing ‑‑

JORDI PALET: No, No, I am just making sure to ask.

AUDIENCE SPEAKER: Peart speaking for myself. I think that you made a false alternative about self‑regulation versus government. Treating us with the governments or other regulatory bodies doesn't make any sense. Let me remind you that apart from being this falls alternative, this community is super inclusive, governments are the part of this community. It doesn't matter if you like that or not. This is the community including governments. So treating us with the our colleagues from this community, it's a nonsense. So, that's ‑‑ don't use that kind of arguments please. And as a side note, try to look more carefully at the responsibilities for the RIPE NCC and try to find an analogy about the amount of time and other means of ‑‑ how the process works, how ‑‑ what kind of burden is there, and then find an analogy to a panel of experts. Thank you.

AUDIENCE SPEAKER: Anna Wilson, HEAnet. Jordi, thank you for bringing this forward. I do disagree with your use of the slide from the service Working Group yesterday. There are things that every business needs to do to understand what its dealing with and I think that does not clearly apply to this situation, it's a different context.

Brian, thank you for doing the best you can with a difficult and complex agenda in a 90‑minute slot and I do want to say to everyone else, we all have a lot to say about this. We know that we all have ‑‑ will have every opportunity to do so before this thing goes further in the process, that's why we have this process. Let's not spend so much time talking with our, or arguing about how the situation is chaired or how much time we have here. Thank you very much.

PETER KOCH: Jordi, relax. I'll tame my temper this time. I have a clarifying question first. That is, it is unclear to me which version was subject to the NCC impact review. If that was Version 1, is that the case?

JORDI PALET: It was Version 2.

PETER KOCH: I think it's a failure of the interpretation of the process that the Version 2 cannot be made available and it should be made available in the right place immediately.

BRIAN NISBET: It is now being made available. So there is now an e‑mail in the mailing list with the ‑‑

PETER KOCH: No, I want it in the right place now.

BRIAN NISBET: We will get that up yes, as soon as possible.

JORDI PALET: Just to confirm, that was the wish of the authors, but we could not make it officially available.

BRIAN NISBET: The proposal issue has been noted absolutely and we'll work with the NCC to see what we can do about that as soon as possible.

PETER KOCH: Okay. Fine. What Peart said about the regulation, in addition, just because we "Self‑regulate" maybe out of scope of our mission, doesn't make it necessarily better than what governments can come up with. That said, attribution on an international level has been subject to a variety of, so far, failed attempts within UN and other fora. I find it very brave to believe that this can be dealt with in passing in a policy proposal in the RIPE region without the necessary involvement of legal expert and especially experts in international law and international treaties. Thank you.

AUDIENCE SPEAKER: Nick Hilliard. Two brief comments.

First of all, the RIPE NCC is a registry in this regard and needs to steer clear of attempting to dictate what the address resources are used for, because if it becomes a stick with which to beat people, then control of that stick will be taken away from the RIPE community and put in the hands of civil law enforcement authorities. We do not want to do this.

The second thing is an entirely practical matter, and that is that you're creating a sledge hammer to try and chase mosquitoes. This is not a good idea. You can create a company for £50 or €50 or whatever, and you can get resources to do your BGP hijacking and then you can disappear, and you can do that by API if you want to, and you can do that hundreds of times per day and by the the time that the, that this proposal would have actually spun into action, you're gone, you have done all of the damage that you need to do. It is going to be completely infect you'll from the point of view of actual practical management. This is not the way to do, to deal with BGP hijacking.

JORDI PALET: We have some text in the policy about that specific case, but I don't think we have the time here to discuss it.

BRIAN NISBET: We absolutely do not unfortunately. I wish we did. This is one of those moments where I'm like, two sessions would have been a good idea.

NICK HILLIARD: You need to understand that if someone is going to be criminal enough to hijack resources, they are going to be criminal enough to avoid the mechanisms that you have put in place to try and stop them.

BRIAN NISBET: I should have been clear. We need to be done on the mics. We have got two people here and we're well over time.

AUDIENCE SPEAKER: ARIN DeLong. I think there is a fundamental misunderstanding of the role of the registry incorporated in this policy proposal. Registries do not grant rights to use resources. Registries grant registration of resources for uniqueness and operators choose to use registries and issue rights to use resources according to the registry. And that distinction underlies most of the problems of this proposal. And it is not well understood by I think a large fraction of the community that that is the case. But once you have that understanding, I think it becomes very clear just how impossible implementation of this policy would be and just how harmful it could become.

AUDIENCE SPEAKER: Randy Bush, I will not waste your time further discussing this proposal. I would underline a point Daniel made. If you want to fix the root problem, routing security, if you want to work on routing security, come talk to me.

BRIAN NISBET: One of the things I was going to say was ‑‑ and thank you ‑‑ was Michele's comments, a framework things like this we have MANRS, we have people, they are working on these things and so some of that exists. Okay.

JORDI PALET: Thank you very much.

BRIAN NISBET: Thank you for proposing this and going forward with this.

(Applause)

I think, again, some fairly clear mention there. Again, please do put some of this on the mailing list as well. I know some you have, it's great. That's where the decision will be made but it's very important, and the co‑chairs have heard what the room is saying, there is no question there.

So we do have some presentations which have less time than we thought they were to have, but I think are going to be very interesting. So sorry about that. You all talk too much.

But now the curious case of fake British LIRs.

GAITH TAHA: I was hoping for 40 minutes, I'll start off at ten. So the title as I said, let me test this, I am a security researcher, consultant now. I started 15 years ago, worked for a networking vendors as a testing engineer for security products. Moved to malware engineering. Most recently I have been wording on the telecoms industry, wired and mobile network operators around improving the defensive capabilities of operators. So, I'm both involved in the improved tooling part and also the investigation part.

The agenda for this presentation is just to highlight some operational cases where abuse of resources have happened. I think most of the discussion here is very high level on the macro aspect of how resources are managed more on the policy level and there is a lot of missing details of what really happens in real life.

This is for lawyers, I'll be mentioning names and stuff, I am not implying any guilt or any party. It's up to you to interpret the data the way you want really.

So, this started about nine months ago, I was analysing some firewall logs for events. On the X asix this is a range of IP addresses. On the Y I object axis is just a range of port numbers. So, I was looking in the firewall logs looking for who is conducting scans and for what purpose, what the most common port etc. Looking at this picture all ports are legitimate targets, they seem. So, while looking at the different LIRs where the traffic rejecting from, I noticed there was a few UK ones, I thought this is interesting, it's unusual I see traffic coming from UK registered LIRs or user organisations. So my first impression was they might be infected and part of C NC and I'll probably try to reach to them to help them to advise them to help them fix this problem.

So, I picked one of them, just by random, and the pattern was quite obvious. It's the scanning quite a lot of number of ports but they are also being selective for specifics services. So, the first thing came to my mind is to find the contact details, try to reach them. The name is quite general, cable come, data cabling services, blah blah, so I find it impossible to find the website just based on these key words. So went to the RIPE database, tried to find the contact details. The address was very interesting to me, because I know the area quite well as the back of my hand, so I thought interesting, someone I know where they live really, or where they are registered. And that just raised my interest from 0.1 on a scale of 10 to 2, and then found the contact details, well the abuse mailbox, the website, name. So went to the website, unfortunately it's been taken down and I haven't managed to capture any screen shots since it happened.

So, just to summarise it and say a generic website, someone is providing cabling services for data centres, if you have a DSL modum, you want to extend the range, all these things, there is no contact details for the business, which is quite strange, because they try to be helpful to people, they need to publish their details. The only thing which was a web forum, you send them the details, submit and it goes in a black hole.

So, the next step I tried to find their phone number. The phone number was registered for a company called Voxbone in the UK phone numbers, mobile phones, they start with 07 and then there is a regulator called off‑com they allocate these to different operators, the registry is public so you can find the allocation of who owns what. However, this mobile portability issues so it's not really accurate if you consider that aspect. So you have to be switched on. So this was a phone, so someone ‑‑ now my interest raised from 2 to 3 maybe, it's getting more interesting now. What's going on?

So, I looked up the WHOIS data for the website. Someone in China registered this domain name, and the registrar did not have any English interface, I was like, so someone must know Chinese, they went to register their website, then they obtained resources based on this. The interesting part is they also run their nameserver, so if you have a very low level operation, you probably not very included about running name servers and maintaining the resources, so it's getting more interesting to me.

And then went to the a website called Companies House where it's a public register for all companies registered in the UK. Prior to 2015, when the Panama papers were published, all these records were kind of secret. A lot of the details weren't available publicly, post this, the government decided to make these records available, I think for the rest of the EU, this is coming towards the end of this year.

So, I found Mr. Roy Bray and found his address. I probably don't remember the address from the previous page, but it was different to the current one. And it pretty much moved one mile down the road to a different location. So, between the time the register for the RIPE resources they moved things then. What's going on? So again another question I had in my mind.

So, I did find the place. So this is the first location they registered. It's a very nice, leafy suburb. I managed to find the contact details of the people who live there and they are from African heritage, there is definitely no Roy Bray amongst them. The names are very different. They are all medical professionals. The profile did not match the guy who managed to obtain the resources. And the location which moved later down the road, a mile away, it's more of like a social housing area, so, probably someone who has tried to obtain LIR resources they won't be able to afford this. I am generalising, I am being very overreaching in my judgement, but probably, again another suspicious aspect to this.

So, just to give you the process of how to register for a company. The the body is called the Companies House, you go and pay £12. You can do it online or by post. If you do this online you get the certificate online as a PDF, if you do it by post‑it gets posted to your home address. You register within three hours someone will review it, they will click, will approve. Now you have a company you can trade on and you can go to the RIPE NCC to obtain your resources. You send them the certificate. And then they also review these, if they are happy and content with the legitimacy of the data they will send you a contract via recorded male and to your address nominated address. It doesn't have to be the same address which is on the companies registry. So, fraud can happen. So, they send the contract to you, sign it and you post‑it back. So they know your location somehow. And then happy days, now you're registered LIR, you can apply nor resources, you pay the fees, and everything is ‑‑ music is playing.

So later on I realised this wasn't a fully registered LIR. It was an end user organisation, because with Anna signed PA coming from another LIR which is the Peter's burring Internet network. This name becomes quite prompt in my research further on. Every time I check, there is a few more of these registered users organisation. I checked lots now, there is a new one every few weeks there is more and more, it just keeps going.

If you track the history of this prefix, which the capable come data guy managed to achieve, there are the usual suspects where it used to be announced from. I have to rush through this now. This is the second prefix which was announced from the same ASN, so solar invest UK limited was the owner of that AS and it announced its prefix as well as the CableCom guy. They have been more prolific. Scanning on wider range of ports, something is going on. This company is actually a legitimate company so the identity has been stolen, it's running and they have been filing their accounts.

Something I didn't mention before. When you register for the company you have about 12 months where there is no contact between you and the government as such. So it's a free rein for twelve months and there is a few more warnings like notification you get given in order to file your accounts. There is a third strike, second strike and the company is resolved if you don't respond. So you have about 18 months of apparent leigitmacy where you can run some shoddy business around. With the solar investment company. It's a legitimate company, they have been filing their accounts. Again it was registered in China and I think it just Dunne seem right.

This one in this case they did not have any website and it was difficult to get to them and find any other like activities on them and their business. It's not a suspicious thing per se, there are a lot of companies which are other companies and the gist is holding like structure, it's made for legal purposes, not for trading under their name. So again, another Russian LIR called net art which have delegated this PA section to them. And in both scenarios, the announcements were coming from a different country. So sometimes the Czech Republic, Bulgaria, different places.



So, I was ‑‑ if you remember a website ‑‑ they list every different IP address and what services is, are available. So, web servers, all these things. So which I went to through just checking the whole range of who is providing what at every IP address. So, there were loads of these web servers which are apparently doing nothing. I think later on I came to realise probably they are Tore enabled server. If you reach them from the regular Internet, they won't give you anything, but you have to come through a Tore DNS name.

So, if you remember about the structure of the AS which advertised these two prefixes came this way and I suddenly got lucky, I have to admit. So, there is a service called Redis, I think somebody mentioned it yesterday, if you are not familiar with it's very similar to elastic search or Mongo DB, it's a queue system, you send some data and it just manges your data. In Redis it does it in memory so it's not on disc. It's being used as a proxy server. So some IP address in China was running a registry server. The registry server wasn't secured enough. So if you opened a socket on the Redis port, it will list all the current connections currently contacting that IP address in order to provide data. Later on that was secured. But initially it wasn't. So I was extremely lucky, managed to find another port which is running on this server, and my Chinese is limited to two words and I probably can't read them. I definitely can't read that. So translated the part in the middle, it's a public security video image information comprehensive application platform. So someone in China is gathering information across this hijacked addressees, or whatever you want to call them, and relaying the information to the address.

So, the logo is the next part. I had to do a reverse image lookup on Google and it came back to the ‑‑ it's the Government of the Ministry of Interior. It could be fake. I mean, again back to my disclaimer, I can't verify all this information. It could be fake, but...

I'll probably ‑‑ I'll go to the conclusion, you are free to view the slides. I will be around. I'll be attending the dinner if you want to come to talk to me.

There is more prefixes. There is ones which are dedicated to this infamous organisation with different forums running on these prefixes, they are currently be fronted on CloudFlare. CloudFlare refusing to take them down because of freedom of speech blah, blah, blah. It's a card inform, they are selling accurate details so I don't see the point.

More of these prefixes. This is a person whose identity was stolen. He does exist. Someone took his name. I think the food chain comes from a network called a quasi‑network which is probably very known to some of you. They changed their name last week, they rebranded to IP Volume and currently they are registered in the Seychelles. They are a RIPE LIR. And throughout their history they have been changing their name over and over again. I think they are cautious in trying to use their resources so they are currently being used as a transit point, sometimes they spin another LIR and use it as a transit point instead of using their own resources fearing they will be blacklisted.

Another one which was ‑‑ they took themselves down last month. There is some statistics about the IP addresses I haven encountered ‑‑ I did not publish everything, there is too much data ‑‑ is this a UK specific problem. I come across other ones across different countries but because I am familiar with the UK legal system, I kind of see this and they just pop into my eyes very easily. So there is another one here.

I think the conclusion is probably there is a lot of work needs to be done trying to take down these networks. I am talking from an operational point of view. I work for a mobile network operators, sometimes we get millions of users targeted on phishing campaigns coming from these IP addresses. If you can't reach to anyone to take them down immediately, our capability is quite limited. We block the DNS names, they spin under a different domains and it's just a losing battle really.

And that's the end. Sorry for the rapid fire...

(Applause)

BRIAN NISBET: I wish to apologise to you and so Sam an about the time constraints we are under today and we do have to get out of this room to let another Working Group come in at some point in time. I am so sorry about that. If it's really quick ‑‑

AUDIENCE SPEAKER: You may be remember an emotional discuss about closed LIRs during NCC Services Working Group. During your presentation, I think maintainer is object from that LIRs. So, I feel that even you can find those people who are actually preparing malicious things, RIPE NCC made some Russian LIRs responsible for that. I think the discussion should be continued. Thank you very much.

BRIAN NISBET: You will be around and I think you are talking to the NCC as well.

GAITH TAHA: I had some engagement.

BRIAN NISBET: So this information is not going into a void. We have one last presentation. We have one more presentation. And again, apologies for the truncated time. It's on domain abuse activity reporting, so...

SAMANEH TAJALIZADEHKHOBB: Hi everybody. I will try to be very quick. So, today I'm going to talk about an abuse activity reporting system which is addressing the problem of growing need for dealing with abuse and abuse concentration in providers network. As I said, the system is called domain abusetivity reporting or DAAR and it reports on domain registrations as well as abuse across registries and registrars.

In a nutshell, the system collects three data sources, the DNS zone files from different sources including the ICANN's centralised zone files for new TLDs and individual zone files from other sources. Registries information ‑‑ registrar information or the ID from WHOIS and reputation feeds from different commercial reputation providers.

This is a brief overview of how this system collects and aggregates the data. Basically, the starting point is a domains from the zone files and we collapse that with WHOIS registrar information from WHOIS and abuse information from reputation lists. And then different kinds of metrics are generated and aggregated.

There are four kinds of abuse threats that are used at the moment in DAAR: Phishing, malware, spam and botnet comment control. These are the lists of the current RLs to be used or expanded based on continuous evaluation of the feeds.

Here are some examples of the kind of analytics that can be done with this collected data. These are just examples and since we are short in time I'm not going to go in‑depth into them. There is, you can ‑‑ the first very basic thing is to see the distributions of the domains in the zone files. This is one way of aggretating them per type of TLD, but there are several ways.

Next, you can see how abuse domains are distributed over legacy and new gTLDs and in the right plot you can also see that around 90% of the abuse is is caused by only 25 or so new gTLDs so this is a point of action where if the abuse needs to be tackled, it's only to focus in a handful of providers ‑‑ operators.

You can also ‑‑ the data also allows to see historic analysis per abuse type. This is from August 2018 to April 2019. And this is again just one example.

It also allows to look at how the size of operators influences the amount of abuse they have. Very briefly, the plot on the left shows the non‑normalised distribution of abuse, so on the X asix, you see the number of domains that are in the zone file per operators. Each dot is an operators. And on the Y axis you see the number of abuse.

The right plot is the normalised version of the left plot. You see how different it is if you take the size of the provider into account. So basically, anything here in this line shows that operators with a same size have varying level of abuse, so why is this operator having around 80% abuse, whereas this operator with the same size is having very few. These are the questions that needs further studying and digging into the data. But it's interesting to know. What are the properties of these operators that make them different in terms of abuse performance.

Next we are planning to add a feature into RIPE NCC's RIPEstat platform. The initial steps ‑‑ this feature would be both domain level, IP level, prefix level, ASN level, depending on how the the users wants to aggregate it.

It would also include similar to this diversity of abuse types and it would allow for aggregation and longitudinal analysis for abuse metrics.

The initial steps towards this goal is to develop rigid criteria for evaluating abuse fits, and next would be more operational developing and maintaining the metrics ‑‑ the data and then creating infrastructure for storing in the data and creating the metrics and continuously update the methodology based on the feedback that we receive from the RIPE community.

That's it. I'm happy to receive comments or questions if there is any.

BRIAN NISBET: Thank you very much for coming and presenting this. Again apologies for the truncated time. You are around for the next, for the day and tomorrow, and the slides are on the website. We don't really have any time for comments or questions at this point in time. I have eaten vast amount of your coffee break already. So if you want to come and talk to Samaneh, then she is around ‑‑ we are going to finish the Working Group session if you can stay a bit longer, but thank you very much for that.

(Applause)

BRIAN NISBET: Is there any other business? Does anyone want to stay here longer? So, with that in mind, thank you, that's good AOB. Thank you to everyone for a very robust discussion today. It's really important. Please remember to bring things to the mailing list as well. You know, we have obviously the next meeting in Rotterdam. If you have things you wish to raise, then please let the co‑chairs know. In general, thank you all very much. Have a good day and we'll see you in Rotterdam. Thanks.

(Applause)

LIVE CAPTIONING BY MARY MCKEON, RMR, CRR, CBC