Thursday, 17 May 2018
At 11 a.m.:
BRIAN NISBET: Good morning to you all and welcome to the RIPE 76 edition of the Anti‑Abuse Working Group, that is who we are, yes, indeed. So welcome to you all. I see the sun has possibly come out, the flares from last night have died down. I am not sure if that counts as abuse of a network group, but certainly I think I was happier inside away from the tear gas. I am Brian Nisbet and co‑chair is Tobias next. And we will talk about co‑chairs in just a moment. So thanks to the lovely NCC staff who are scribing and monitoring chat rooms and thanks to our always wonderful stenographers. As always, I promise to speak more slowly than Richard Sheehan did yesterday, not that that's hard. I think we finally found someone who beat Kurtis. If you are saying something in the microphone, state your name and an affiliation. Make one up, I don't mind, we are not doing a test afterwards. So, what do we need to do? We need to approve the minutes from RIPE 73. These were sent out. Are there any other comments that people need to make about them? Are we all happy with them. Excellent. Great. The agenda is as displayed here. We changed it just last night. Are there any things that anybody in the room would like to add to the agenda at this point in time? I am not seeing 100s of people rushing to the microphone. First thing we need to do is deal with the Working Group chair selection which is why I am going to stand down here and Tobias is going to come up here.
TOBIAS KNECHT: Welcome from me as well, so as Brian already said, term is coming up, we reached out to the mailing list about five or six weeks ago asking if somebody wants to step up and put themselves into the position to become a Chair for the Anti‑Abuse Working Group. We didn't get any body that stood up and came to us, so is there any anybody here that wants to go and ‑‑ not go against, but, you know, wants to be a Chair instead of Brian? If not, I'm asking does anybody have any concerns about Brian doing another term? If that is not the case, I don't see anybody, then, Brian, congratulations. Another time.
BRIAN NISBET: Excellent. Nice and easy, democracy working as it should. So, thank you all very much. You are stuck with me for a while longer. Recent list discussion, most of the recent list discussion was about 2017‑02, regular abuse‑c validation which we are going to be talking about. But there wasn't a lot else, the only other thing was flagged, there was a thread about large companies and their potential or arguable abuse of networks, which there were some useful mails to, there was also some informative ones where I learned the Internet is still owned by America, and I think God got involved, I am not sure, but that was the other thread that has happened recently. I don't think there was anything else huge on the mailing list. Is there anything that anyone would like to discuss from that before we move on to the most substantive thing we have talked about in a while? If not, then, we are going to move on. 2017‑02 is now last call it has, what, eight days left of last call, it's happening on 25th May, which is last call ends 25th May which is also obviously the point at which GDPR comes in because every Working Group requires a GDPR reference. And if you are Irish it's also the day we are be voting on the referendum to repeal the 8th amendment, which I won't get into, but vote yes. So there is two parts to this presentation on this; the first is from the proposers, just going through some of the piece around the proposal, where we are and where we are now and then, so that is Herve and Sara and Marco from the NCC is going to gave chat about the implementation and what is that is looking like. And obviously, there is time for discussion, after that point. So, Herve and Sarah.
HERVE CLEMENTE: So, hello everybody. So, a lot about GDPR, on more time, but, abuse‑C policy proposal ‑‑ regular abuse‑C validation, so it's a policy proposal you have heard about, since quite a lot of time. I think perhaps you don't know Sara, who is from Europol and so support. So with Noah, the co‑author of this proposal so after Greg Mounier. There won't be be any specific additional news regarding the discussion you have read in the mailing list. If you are in the mailing list but just to recall, so the main proposal that was a discussion that was clarified during the review phase and what happens in mainly in the over regions. So perhaps it's that. So first, why this proposal? So of course I think it's common feeling for everybody, so our community is committed to improve trust and safety in the IP space, for many reasons and for security, for instance, for a lot of things. There was in 2012 so in the RIPE‑563 which is the abuse management, abuse management in RIPE database so in this document there was the introduction of a mandatory abuse‑c contact attribute so it was a policy proposal which was accepted. And since that time, this information has become an essential part of the accountability of the RIPE community. But what happened is that this document did not provide for the validation of a ‑‑ of this information, and we have said and the RIPE NCC observe also, there is several 100 reports of invalid contact information each year and the RIPE NCC again estimates that about 10 to 25% of the current ‑‑ so it was evaluated 70,000 distinct abuse contacts seem technically incorrect. So there are tools still exist and so I speak about that because it was mentioned during the discussions, there is existence of the ARC, the assisted registry check so helps member to strengthen registry data. The reviews of this ARC are carried for about 25‑30% of the members every year and it was not designed for the validation of this information. So we spoke about. So what is proposal exactly just to focus on what it is.
So it's the RIPE 563 document that the abuse information in management, RIPE database. So the purpose of this proposal is to add to the paragraph 1, so there is two lines, just above those RIPE NCC will validate the abuse mailbox attribute at least annually. Where the attribute is deemed incorrect it will follow up in compliance with relevant RIPE policies and RIPE NCC procedures. Nothing else added. It is that sentence.
Just to and to remark because there were question about that, about legacy resources, they are not directly impacted but as part of the community holder, they are committed to the objective of safety, accountability and trust in IP space but one more time, not impacted directly by this proposal.
Overview of the review phase. So nothing new, one more time, it's just what appeared, so in the discussion on and that was summarised at the end of the review phase. So by the Chairs of the abuse Working Group. There were some, quite some straightforward support and highlights. I wont' to turn to details about that in the mailing list. So request about potential escalation mechanism, that is a link that answers to that. Wish for more extensive set of checks. Why not? There is a policy but something else can be added in. Concern in relation to a potential liability to the NCC. There were confirmation of no further risks. And the risk of possible implications of an LIR failing to enter appropriate information to the database. Was clarified. And that proposal was greatly aid the ARC proI was talking about.
And to have the global context, there are a family, we will say a family of prosals, the contact is not exactly which is proposed here in that region, but we think to this family. In AFRINIC it's a little special, a little different because there is a proposal currently called the Internet number resource review by the AFRINIC. It's in first step to review the information and the way resources are used in the ‑‑ so for every member and this policy is not accepted yet, and so there is a reason why, there is no other policy so compared to this. Within ARIN region there are two like this one policy, it is 2017‑3 policy, the annual Whois POC validation and which entered last call so in April, last April, and there is also 2017‑12, which is called require new POC validation upon reassignment, entered last call in April also. And within LACNIC there is registration and validation of abuse‑c and abuse mailbox policy proposal and currently, because we count in that region the number of in favour and against, there are currently 7 in favour, 1 against and 1 neutral.
And I think it was conclusion of our presentation.
BRIAN NISBET: Okay. So are there any questions on any of that? Please.
SPEAKER: Julian, can you just elaborate a bit on what will be the verification process of the abuse contact, is it just check that ‑‑ stop you there because we are ‑‑ the next presentation is going to be about what the ‑‑ how the NCC will be verifying it.
Herve: You will have answers.
BRIAN NISBET: If you have more questions after that, cool. Obviously substantive comments to the mailing list over the next nine days. No. Okay. Thank you very much.
So now Marco from the NCC will talk about the understanding and what the implementation look like should the process result in the policy ‑‑ the proposal becoming policy.
MARCO SCHMIDT: I am the policy officer of the RIPE NCC, and I was asked by the Working Group Chairs to give a little overview on the RIPE NCC's understanding of this policy proposal. And that is not something that we to on a regular basis during RIPE meetings because normally this is something that we do in impact an illusive. However, in this case, as the actual change in the policy text is not so big but understanding of the RIPE NCC is very crucial and we have written a very long and extensive impact analysis, we agreed it's a good idea to use this opportunity and provide some additional clarification.
Looking at the proposed change in the policy text, the actually just two sentences, so the first one is that we will have to validate annually the abuse mailbox attribute and then in case they are deemed to be incorrect to follow up according to RIPE policies and RIPE NCC procedures. So when splitting these two sentence, so the first one is about validation, what does this mean? So if this proposal will reach final consensus, we will have to implement a validate method and the good news is that we already have an existing procedure to validate and to fix incorrect abuse contact information, because right now when you want to send an abuse report you can go to a website, there is a report form, you can let us know and we will investigate, we will contact the resource holder and ask them to eventually fix the incorrect contact information.
However, this is something reactive so we only do this when we get informed. And this is the main change of had policy proposal because this would if I have us a mandate to do something proactively, to check it on an annual basis. And the idea that we have for this one is automated solution. So that check the technical parameters, often abuse contact email address, and we will do this without sending an email, so and then we will check parameters like the syntax and domain and the serve configuration and the good news is there will be no action needed for anyone who has configured his abuse contact address correctly because this was one of the feed backs that was especially raised at the beginning of the discussion, that people said it's a good idea but please don't give extra work to all the people that ‑‑ who have done everything correctly.
Talk a lit about numbers, Herve mentioned them already, there are currently more than 70,000 distinct abuse mailbox attributes in the RIPE database and during impact analysis we were running a little test on small batch of them under this automated validation method, and we have indications that around 10 to 25% of the abuse contact email addresses that are right now on RIPE database will fail on those technical parameters. That is something interesting because during the discussion there was people raised the question, okay, what this proposal will solve, what will it be improving and then that is maybe the question back to you, that right now if you sent in abuse report you have one out of ten eventually, one out of four chance that your abuse report just rebounds.
Of course people will say that, yeah, but just this automated Valitation, always will be false and positives. So, for example, if a mailbox is full it might pass the validation test, you cannot send abuse report. We will keep and always have the option you will let us know, the report form is there that something isn't working and we will investigate.
Something that is also important to mention what is not in the scope, because it was mentioned during the discussion and also we have received, sometimes, some people are frustrated, that they sent in an abuse report and they are not getting an answer or get very late answer or the answer is not what they expected and although that is very frustrating it's not really something where the RIPE NCC can interfere if the internal procedures how providers handle abuse reports. And also it would be probably a very complex and difficult investigation to find out what has been sent and not been sent, which errors have been received and so on. So this is why we decided to focus on something tangible which are the technical parameters.
Moving on to the second part of the text, it's basically the one what happened.if contact deemed to be incorrect and what relevant RIPE policies and RIPE NCC procedures. And looking at the policies, they actually pretty clear. This is a part of the IPv4 policy, currently RIPE 680 and it says that registration data, including contact information must be correct at all times, so it seems they must be maintained. And it also says that the RIPE NCC has the right to close LIRs if they cannot be contacted for longer period or if they consistently violate RIPE policies. As a note here, there is nothing mentioned about close of email address for these rules. And something similar is in the policy about contractual requirements for independent resources, so PI resources, AS numbers, in those contracts that independent resource holders have to sign with the sponsoring LIR there are always clear statements that the registration data must be up to date, they have to follow policies and also that if they cannot be contacted, for example, the resources go back to the RIPE NCC. So the policy framework is pretty clear there.
What they know about the process. And again, I want to refer to something that was mentioned in the mailing list that people were afraid you might get closed because your email address is not working and suddenly you are in big trouble. This is not our aim. Our aim is to fix incorrect contact information. So we will contact the resource holders and we will ask to review the abuse contact email address and eventually correct it. And we are and always will be very sympathetic to the specific situation of the resource holder, so if we get a feedback that oh, the guy who was responsible for the database entries is in vacation or sick or left the company and we don't know the password any more we will provide extra time, provide support to maintain password and so on and so on. And this is all still outside of the closure, the registration procedure that was also also mentioned quite a lot of times, because we will spend reasonable amount of effort to really get in contact with those people and help them to fix it. If, however, we come into a situation that some people would say, to us, I know it's incorrect but I will not update it and I am completely refusing it or that we have tried to contact the people over longer period, several times, via multiple channels and we don't get any response, then it is possible that we can activate closure procedure because you saw before just the policy requirements that policy violation and longer unresponsiveness can lead to it. And of course this sounds a bit scary for some people I can tell you since we receive external reports on incorrect abuse contacts which is about five years we never needed to trigger that closure procedure, we always could fix and solve the problem together with the resource holder before. And even if ever this procedure needs to be triggered, it will be termination of the contract of three months period. So there will be an additional three months where the resource holder still can fix the contact information so we talk, all in all, about the time frame of several months before there is really ‑‑ that is probably considered to be sufficient time to fix something in the RIPE database. That brings me to my last slide, about actually implementation if this proposal will reach consensus at the end of this last call, we currently estimate that we will need about three months to implement this automated tool into our systems and procedures, and once this is done we will do a trial phase, because we don't know really yet how much time it will need to fix email addresses, so we will take a certain amount of abuse contact email addresses and run it through and see how many will fail on technical parameters and see how many get fixed immediately once we contact them for the first time, we will see how many need support from us and how long it takes to fix them. And once this is clear to us we will draft some recommendations to the RIPE NCC board to basically outline how many resources would be needed to get implementation done in a certain time frame. And then the RIPE NCC board will decide, and we will continue to validate all these 70,000 email addresses for the first time, which is considered really likely quite some workload but once we are done for this first round it will be much less, we estimate much less because later than for the revalidation we only will need to follow up with email addresses that became incorrect, technically incorrect within those 12 months.
So, that was the overview from our impact analysis in a nutshell. Thank you very much.
BRIAN NISBET: Thank you.
SPEAKER: Alexander. I am not sure I received an answer but I actually wrote in mailing list in discussion, could you go for the first slide, slide number 4. Slide number 4 had number 4. This one. RIPE NCC is all about register keeping, so you can say we have about 70,000 abuse‑c, you may say at this moment in time we had exact number of abuse‑c contacts, you can say 10 to 25% might be incorrect because, for example, email address correct because web validators and standard for email address and you can do this check, you can check exist domain or not. So, in mailing list I ask RIPE NCC to run kind of this check at least once. So on one of the later slides I think you need approval from the Board, you need three times for software development, actually I don't feel it's ‑‑ board may decide something but it's easy task, just get all abuse‑c from your mailbox, simple script, great programmeers are:do this in a minute. Apply email ‑‑ write a simple script, okay, this DNS does not exist in domain names, this email address vs. No mixed ‑‑ records, at least once easily it might be hackathon task if RIPE NCC board does not approve usage of programmeers for such things. We could not decide on this policy because we do not know exact numbers, this is all ‑‑ you my write 99% on this slide, should we believe you? No. So, I don't know how to react. I think that we should postpone any decision until we have exact numbers.
BRIAN NISBET: So, I mean, no, is the short answer to that one.
SPEAKER: I state my opinion, reasons not support this policy, having no exact numbers is a great reason just to stop any discussions, bring exact numbers, for today, for tomorrow, for exact time and get back. It might be 1% or 91%.
MARCO SCHMIDT: If I can say we took a representative batch of email addresses to get this number and of course if we would get, we could probably run the same for 70,000 but I think if you take ‑‑
SPEAKER: Here is long years chair for Database Working Group, ask him for advice how to work with database. Sorry, I think this is ‑‑ it's not very good presentation. Sorry.
BRIAN NISBET: Okay.
SPEAKER: For decision‑making.
SPEAKER: Just an opinion, but I think it's ‑‑ verification ‑‑ is a little bit like it should be ‑‑ we will make parallel with domain holder verification, we received one mail ‑‑ one mail per year to check email address is just valid and they didn't ‑‑ not ask for N square, only check mail is correctly received and ask to check if the details are correct. Why don't we go for such a verification, we don't need ‑‑
BRIAN NISBET: I am going to stop you there again because this is something that was discussed reasonably extensively and I don't want doing through the conversation again.
SPEAKER: It's just my opinion.
BRIAN NISBET: Absolutely and thank you for that. There were a couple of people on the mailing list who expressed an interest in a more detailed verification check. It was made clear from other parts of the community that they very seriously objected to a more serious validation check so the decision we made was, we would go ahead with, as described, on the basis of this policy. If somebody would like to put together a proposal that has a more extensive one, then that is a separate discussion.
SPEAKER: We can consider this as a first step and let's discuss ‑‑
BRIAN NISBET: I would tend to agree.
JORDI PALET: I am considering sending once this proposal reach consensus, I am considering sending an updated version. I am actually the author of the one at that has been presented before for LACNIC, basically that is what we are doing in the policy proposal for LACNIC. I will send a link in the ‑‑ for the English version of LACNIC now to the list so people can start discussing. That proposal has been also submitted to AFRINIC so that it's not yet in the policy process and I am going to submit also to APNIC, I have talked with people over there and they are in favour of that. So, I am just trying to be much big on this policy and making sure it's not just a technical verification but a human response to the email. And well, I will send a link to the mailing list so people can start reading and see what happens. Thank you.
BRIAN NISBET: I look forward many hours of discussion.
PETER KOCH: I was told I am behind those two gentlemen in in the queue and I will seize the floor because it makes me look like a diplomat.
Peter Strzyzweski. Let me introduce myself once again. So a couple of questions and comments, first of all what about legacy resource holder, I am not expecting you will discuss right now ‑‑
MARCO SCHMIDT: I can. It was mentioned also by Herve. I took it out of my presentation, but legally resource holders will not be part of that one, in the policy it says very clear any other policy will only apply to legacy resources if specifically mentioned.
Peter Strzyzweski: I was trying in the past to impose abuse‑c on them or at least on me because I am the legacy resource holder. It's a joke. That is my comment. The next question is, keeping technicallies apart, if checking email address is a really tricky question, all those second main servers accepting sometimes everything for every domain, that could be tricky but keeping that apart so if I put abuse at right net in for my resources that would be fantastically valid according to this procedure, yet?
MARCO SCHMIDT: Not to this procedure but it probably would pass the automated validation, but somebody would then report to say your abuse contact is in some object and ‑‑
SPEAKER: I have had that situation with the NCC back somewhere in time so I put abuse [at] ripe [dot] net and you guys were forced to fix something with the abuse contact finder tool, a few years ago, I can show you emails between me and you. That would be correct email address. How would it help to abuse at all ‑‑
BRIAN NISBET: We discussed all of this at length on the mailing list and again ‑‑ the point that was made at the ‑‑ at that point in time was that there are, in no small part, even if this catches the people who have got it wrong themselves as Job was saying in the plenary earlier in the week, letters on key boards are really close to each other. We know that there are a number of objects, details which are just incorrectly entered. This is not supposed to be, this policy is not supposed to be some amazing cure Youghal situation unfortunately because we haven't had one of them yet.
SPEAKER: We don't know how much money this will cost and what will be ‑‑ from that and the probably close to zero, at least at my point of view, if we want to correct few email addresses in the database and we are spending enormous amount of money and few ‑‑ the workforce of the few people that probably is something is wrong. The outcome of this ‑‑ of this policy is unknown, really unknown. We are just trying to, as you said, to correct some fat fingers. But at least I understand that. Because the key boards ‑‑ the key on the key boards are quite close, is it true? Do I understand you correctly.
BRIAN NISBET: I mean, personally I tend to think you will find more, you know.
MARCO SCHMIDT: I was referring to those numbers that if really up to 25% of these are technically incorrect there is quite a lot of frustration for people who want to sends abuse report ‑‑ to tills how many just are giving us up and this percentage of technical incorrect emails we expect doing down significantly and there will be always the cases like what you said, maybe ‑‑ that it might pass this test but I think it's mainly also for somebody saying it on the RIPE mailing list a lot of the people that have right now and not working abuse contact in the RIPE database are not doing this by purpose, it's just they forgot to maintain it and actually we notice it quite often if you contact them, they are very happy about us to tell them, thanks a lot I forget about it and I think this is what was on the mailing list, the benefit that many people see, to help those people to maintain the records.
PETER KOCH: I won the battle against Rudiger this time. I am procedurally confused a bit at the moment. Much of what we have been discussing in the last couple of minutes very much depends or heavily depends on the current interpretation of the policy text by the RIPE NCC. Now, while there is usual thing we can trust the RIPE NCC and so on and so forth the NCC might change their mind or might be made to change their mind. At that point in time, there is little community influence over what is actually executed and you can or cannot take that literally. I am feeling like one of these frogs, no offence, in the Luke warm water that is going to be boiled at a point in time where still I am able to jump out of the pot actually. This sounds so nice and be nine and it's also cosy. How much of this can be ‑‑ where is the guarantee?
MARCO SCHMIDT: Well, I might also give this to other people but the guarantee is that everything what RIPE does must be within the policy framework and that is why I pointed out the unresponsiveness and the consistent policy violation.
PETER KOCH: The policy text itself and the policy framework would allow for much harsher interpretation, I am not suggesting that you do that, exactly I would be advised if you did that. But yes, but things ‑‑ or circumstances may change. So, much of the motivation, much this is now in the interpretation of the ex queuetive branch and I am not really convinced that that is ‑‑ does well manufacture the policy making. I don't have a good gut feeling about that.
BRIAN NISBET: Okay. I mean, I think this was again ‑‑ this is a question, but the ‑‑ the NCC did say during the conversation that the impact analysis and the way they are going doing about it is as set as it can be.
RUEDIGER VOLK: Well, okay. The discussion that I'm hearing falls apart into three very distinct topics: One is the technical ‑‑ the technical question how email contact information can be validated, and actually I would not mind the ‑‑ I would not see any obstacle from the policy and legal side for the RIPE NCC running once in a while a validation on all the contacts that are relevant, in particular, in particular, when we look at the second topic, which is what are consequences if for some required address field there is the information is deemed not correct, insufficient? I think the policy quotes that you showed would actually ask more for if contact information for, say, the LIR organisation is bad to be a factor for invoking procedures to question the viability of that LIR. The third topic would be ‑‑ well, okay, and let me say, okay, what I'm ‑‑ yes, again, validating the mail information kind of, yes, that's a nice thing and we know it is not ‑‑ it cannot be done to be fully automatic and correct and complete, and much less expected processing on the far end. Now, fixing and checking the emails could be considered something that should be done in the D base ‑‑ that is the database content and database content validation. So, but we are not in database here. So, what is the actual help of having a formal check of whether there is a mail bot that can be reached for the ‑‑ for the goals of this group? I don't see any help on that. What I'm seeing is that installing this policy and these checks is creating the illusion that something has been achieved, where I think ‑‑ where I think the actually important things are actually skipped and not addressed in ways that are helpful.
BRIAN NISBET: Okay. And as always, people should feel free to propose other policies ‑‑ people should feel free propose other policies and other things, this is what we have on the table at the moment.
TOBIAS KNECHT: I am not speaking as the Chair of this ‑‑ or could chair of this Working Group, I am speaking as the persona non grata who came up with abuse‑c and as a company who is sending 5 million reports to abuse desks all over the planet. 10 to 25% is a correct number from what we are seeing on a daily basis, and we are sending to every single ‑‑ maybe I can come up with some more numbers that show from a live example in the real world at one point in time as well so I can check that.
The other thing, I think we have a policy in place and the policy says you have to have correct abuse contacts or you have to have correct contacts so I think the discussion about or it feels awkward to have a discussion about making sure that some other policies are enforced, and putting this, you know, putting this discussion on this level so we have the policy which says you have to have correct information in abuse database and Rudiger I am happy absolutely to work with you to do this all over the place, all over the Whois database, for all abuse emails and for all other email addresses as well, I am happy to write a proposal together with you and nought in database because that is what you said few minutes ago.
RUEDIGER VOLK: For doing that check there is no need for defining a policy. The RIPE NCC is charged with running a clean and valid registry and the definition of our registry includes lots of information and even the thing, well okay, kind of, kind of the question, well okay, should we exclude legacy space? Well, validating the contact information there is absolutely no problem. Going out there and saying because the legacy space has a legacy contact that doesn't respond any more because well okay, it's somewhere buried, well okay, is not a valid reason for withdrawing and removing the ownership of the legacy space.
BRIAN NISBET: Yeah, we need to move on. I think the point is, we are at this point, all of the things that have been raised from my point of view are things which have been discussed and have been addressed as part of the last call notification. If there are new things, then obviously we still have a period of time to discuss them, so please do, please do so on the mailing list. And we will see what happens over the next nine days. But as I said, from my point of view as Chair there has been nothing particularly new, thank has been brought up in this discussion but it only takes place formally on the mailing list so if there are comments people like to make and as always doing things in database, making new proposals, etc., etc., are all open, are all things that are open to everybody. So thank you very much.
So, now Tobias is going to talk about glow balance update on some abuse matters.
TOBIAS KNECHT: Yes, I am going to try to give you a little bit an update about what the abuse community in other organisations like MAAWG and AP WG and so on is talking about, I have been attending a few of the LACNIC meetings recently and I am aware of all the policy proposals that have been mentioned before. But I want to start with one thing first. One of the interesting things when we are talking about the abuse‑c is that there is a raising amount of companies, organisations out there that are taking the time and the resources and the effort in reporting messages back to the ISPs and hosting companies to help them see where badness from within their network comes so I think Erik Bais did a good presentation on Monday, which also went into that direction and said, hey, you know, in certain cases it's our own fault and what we are facing we need to clean up the networks and we can only clean up networks if people really know what is going wrong within their networks and we make this aware. So that is why I think abuse‑c and also the Valitation of abuse‑c is a very important thing. Another very important thing is for ISPs and hosting companies and we want to make it simpler and easier for them to be able to handle the load of information they are receiving today and we have been working for quite a while on a standardised format which is called XARF. We are working with a few big companies together, I am doing abuse handling for them and all over the companies we see we see about 7 .5 thousand different email formats hitting the abuse mailboxes on a daily basis, there is no point for hosting company to parse or try to parse 7 .5 different form mats, we are doing it because it's our job but in this case we don't want to force this on ISPs and hosting companies and we want to make it as simple and as easy to do so. So the idea of XARF and it's extensible abuse reporting format, there is an older standard which has been used only for email, the idea is to have extensible abuse reporting format that we can extend over time if new attacks or new patterns come on, we can more or less build the format in the way we can report these things in a very easy way. The old XARF from a while ago was also based on email, the nun one will be completely transport independent for whomever wants to fax email reports or abuse reports feel free to do so. It's JSON based so very easy to create and parse. So that is more or less what XARF will be, will be a very, very lightweight format compared to other formats out there and we have been asked why are we not using ‑‑ the industries and organisations that are sending these report and receiving these reports were against using IOTF because it's way top loaded and heavyweight and not to build 20 pages XML specification.
So the time‑line that we are looking at at the moment, the first time‑line was we wanted to release or launch the whole thing in Munich in a few weeks, at the MAAWG meeting, we decided to move it in the October because the MAAWG meeting there will not be a lot of people coming that have been working with that as well so the idea is to publish a new website before October we will under XARF.org, don't look at the old website, the content is horrible and the design as well. So, we want to launch it officially in October in 2018 and we want to move the whole process into the IETF standard and get an IETF standard together by end of this year or at least move into IETF. The idea of it is to more or less not build a format as we know like MAR F. To get a mime type that we can extend then based on the specifications of the mime type.
So who was part of the process, so this is not something that I came up and few people were sitting in a room and saying we are going to do this. We were talking to a lot of companies and players in the industry, and we were able to get Amazon web services, Google, Microsoft and about 20 other organisations including Spamhaus and all these organisations into the room, we were discussing this, we were moving pretty fast from the last meeting in ‑‑ or last mock meeting in San Francisco to where we are now and that is why we are getting this whole thing into the IETF. This is an open or we want to make it as open as possible, that is why I think last time or the time before last time when I was speaking here and mentioning XARF as well we have all the stuff is all in the top, here is the link, we have an open Slack channel, if you want to join that, let me know, I can send invites, and everybody is welcome to work on schemas and to contribute, to say what he thinks is God and what he his is bad. We are still looking for people that are building createers in different languages and libraries, so whoever wants to join in, whoever wants to help feel free, reach out to me or to the XARF community right away on info at XARF.org, that should work.
So that is about XARF. If if there is any questions so far?
RUEDIGER VOLK: One tiny question would be as I have been working on data, what schema language are you working with?
TOBIAS KNECHT: What?
RUEDIGER VOLK: What schema language are you working with? That is a nasty question because you are JSON based and that is known for letting that or having too many proposals. Well okay, I think that receipt or I can question is passed. Then okay, you are talking about creating a standard.
TOBIAS KNECHT: Yes
RUEDIGER VOLK: The interesting question, I think that this community should be asking or resolving is at which point in time will there be a suggested hints list about available tools for either creating reports or for plugging into that verified email box that was discussed with a previous policy?
TOBIAS KNECHT: Yes, I agree. That is why I am saying ‑‑
RUEDIGER VOLK: This was kind of two questions.
TOBIAS KNECHT: The first question is we are trying to keep the JSON schema as simple as possible, so kind of a YAML key value. Because we don't want to make it complicated. Abuse handling, actually, is not complicated, what you need to know what attack, what IP address, what time, that is the minimum that something is wrong within your network. If you get a lot of reports about the same IP address at the same time you know that something with the IP is wrong. If it's only one email maybe that is questionable but if you get 100 you know this IP has some kind of trouble. Then there will be fields and I can show you a little bit more information about, for example, URLs or also copy write infringement and so on. So there is different types of schemas, feel free to join in on the GitHub repository to look at them.
RUEDIGER VOLK: I am working on other parts of standards and security. I'm interested in the results and in the results being in a form that it can be ‑‑ that it can be easily tracked. And by the way, the notion that you need a mime type looks like ‑‑ looks like really crazy, you need a mime type that asks and defines some file format and the thing that needs and has to provide the flexibility is the schema.
TOBIAS KNECHT: I can't comment on the mime type part, this was discussed with other people and IETF people, so I can't really comment on that, I can't figure out why this is the decision. I trust the guy who is the messager here, for at least the mine type decision. The second part I agree we need to have tools, there is also tools out there for creation. There will be also ‑‑ I think there is people that are working on certain pieces to put that into mail boxes or use that in existing abuse handling tools and ticketing systems. Since it's a community effort, I think there will be, if somebody uses abuse handling or some other R T or whatever there will be people that will come up with that or we will help them from a community perspective with it.
RUEDIGER VOLK: And this Working Group since you are a Chair, will take care that this is collected and distributed?
TOBIAS KNECHT: No this has nothing to do with this Working Group. This is an effort that is driven by the community, that is aside from the community here at RIPE. We invite them to be part that have community but it's nothing that is driven by the abuse community.
BRIAN NISBET: We can say is we will send updates to the mailing list in regards to this.
TOBIAS KNECHT: Yes, as soon as we have something I will send information to the mailing list and I will also send the links and also the invites for slack and so on the mailing list later today.
RUEDIGER VOLK: My view is that if this community cares about improving abuse handling, which is done by mostly people who are not in the room, and do not consider me in the room I am just speak for the people outside, kind of, well, okay you actually ‑‑ you actually have to have to identify and provide the pointers to working tools, if you do not do that, you are not ‑‑ you are not entitled to make any demands on people that you force to provide email contacts.
BRIAN NISBET: Okay.
TOBIAS KNECHT: That is for the input, I think we will let it stand as it is for now. If anybody has questions, come later because we are now a little bit under time pressure. I will run through the rest of the presentation a little bit. So GDPR and Brian has already mentioned it, he could have waited for me so everything Working Group has mentioned it at least once, that will be a huge mess for security and abuse ‑‑ from abuse and security perspective. It will. And we have already seen, I would say, about 10 or 15 papers and open letters sent to ICANN from different security companies, from different organisations that are care about abuse so the Whois records for domain names go into ARC on 25th ‑‑ will lead to a huge spike in phishing, we have already seen the first things and security researchers have already seen the first indicators on that. It's just going to be curious on how this is going doing on. There is a lot of work being ‑‑ to be done on the ICANN side, and I can also invite ‑‑ Mark is working on some of these things as well at the moment to find some conclusion with ICANN and how we can more or less solve this problem in a way that we are not suddenly seeing and phishing about 500% or thousand% without any chance of doing anything about it. That is a general thing, as Brian said it's talked all over the place. So the last one, MAAWG. I am a regular at MAAWG meetings, Message Anti‑Abuse Working Group. MAAWG and also the chair of the Abuse Desk Working Group, there, we're working on the XR standards, at the moment, with a few people and we're also still working on the Abuse Desk best practices, this is still work in progress. One of the things, or the four main topics we are looking into at the moment and we have several people from several companies that do abuse and have an abuse desk, what is the business for business justification is one of the chapters there will be incident occurrence, how do we interpret it, where is data coming from and where can we get more data from, the enforcement of AUPs, acceptable use policies which is a big topic especially when we are not only going from the classic tellical abuse but also looking into the matters of copyright infringements and trademark and also the remediation process, what are best practices and how can an ISP and hosting company help their customers and get in contact with them and help solving these problems. One other thing at MAAWG, there was wide support for the 2017‑O2, just stating that, just the messenger here. So if anybody wants to get involved into these best practice papers there is annex MAAWG meeting around the corner in Munich between 4 and 7 June, if you are interested or anybody here is interested in attending, let me know, we might be able to get guest passes so you can attend and be part of that community and discussions approximate the best practice papers and within X‑ARF, but X‑ARF will also be open discussion. If you are interested in that, comes to me after the show. Otherwise, send me an email. And that is more or less it from my side.
BRIAN NISBET: Whistle stop tour and thank you for going through that. Is there any brief points that anybody has around that?
So, this has been a topic on presentation that myself and Tobias and Alexander have been discussing for the last little while. We must be very conscious of the fact that and I believe a and have said that close cooperation with law enforcement is very important, with governments is very important for this community, they are part of this community and vital part of that. However, that does not mean that we should blindly or otherwise just do whatever they want. Nor should law enforcement or governments just be able to do what they want in regards to the Internet, this open and free network that we believe that all of humanity should have access to, if you don't believe that I think you are at the wrong meeting. So we'd like to talk about this and to potentially to highlight some of the problems.
ALEXANDER ISAVNIN: Thank you very much. I really support what Brian said just now and I try to demonstrate you that something can go wrong.
So, actually, let me introduce myself, I was working for ISPs for years and once I had to interact with law enforcements, with regulators and actually move out of BGP world to this world of interaction with officials. So usually we are seeing that abuse is done by malicious people, and the law enforcements that actually kind of saying, well, something can go wrong. And a little declaration: English is not my native. I am not sure that I have translated all Russian legislation words correctly so, if you miss something, just ask me later.
So, originally Internet was not intended to comply law enforcement functions, it should survive in disasters and it was designed to be maximally simple in its networks. But later Internet develop and grow and take significant part in our life and crimes get to the Internet but also law enforcements get to the Internet, some get ‑‑ some criminal abuse it but also malicious law enforcements can use it for its purposes.
It's possible abuse but not limited to actually mass surveillance. Internet allows people to collect information and not going to anywhere so it brings data to exact place. Governments like to block content and perform something which could be called censorship. Law enforcements at least in Russia, showing we are doing a lot of things and protecting you but actually they are not protecting. Powers could be misused or even some very malicious law enforcement agencies could prove Kate crime and offences. Usually by very good intentions, protecting us, protecting citizens. Who of you would say no, doesn't need to protect, yes, no one. Who, of you, would say no, we doesn't need to protect people from terrorists? No one. But actually, very legislation and regulation can get enforced after this. Also, one of the Russian LEA motivations is that western LEAs cooperation does not cooperate with us, so we need to protect our citizens and our country, so that we report this. It's not very good legislation. Actually, we can talk about how Russian legislation, regulation and law practice can go wrong and harm Internet for about five hours we counted different aspects. I will try to speak only about what law enforcement does. Mass surveillance, Russia previously was Soviet state, mass surveillance was very ordinary practice, even since Soviet times there was saying like this is not telephone conversation, so meaning that surveillance could happen. So even in post Soviet Russia, we have wire tapping, but we have bulk wire tapping. Originally it was called SO R M1 and intended for telephone conversations. Any office being sold already equipped with bulk wire tapping and especially what differed interest other countries it's not controlled by operator, so the KB G can connect at Central Office and listen to any conversations and operator should know certification requirement, should not know what KGB is listening to. It had also good intentions could not inform criminal but actually that brings now possibility to control. Well Internet develops there was some two bulk wire tapping for Internet data, it was introduced this legislation, regulation, but actually it takes in full force some years ago. Why? Because Internet regulations in Russia, we have Internet regulation. It is kind of, it is regulated like a telephone network so the Internet in Russia is kind of public network so only very certified equipment could be connected to Russian Internet. Originally, as I said, Central Offices have straightforward certification methods and ministry ‑‑ but for data ‑‑ as ministry of tell communication wasn't able to produce the certification procedures document, so it takes years to certificate such equipment but now operators must install it. As a difference as a special agencies for this wire tapping operator must buy its equipment on its own account. So not as F SB presented ‑‑ they must buy it and install and then leave the channel to local KGB office. Later bulk data wire tapping was not requirement to have storage of selected traffic for 24 hours, just for special services to come back and read messages. Later and now it's certification procedures are being developed, was introduced in SO R M 3 operator must not provide traffic for selected IP addresses but also provide automatically user identification for billing. So we hope it takes some years to implement it.
Lately was introduced by so‑called Y A R O V A Y A package, our legislators are called crazy printer, so they introduced for the purposes of protection from terrorists for sure, that is operator must install equipment which for sure on its own account which will store traffic for half of year, for up to half of year so imagine you have gigabit channel how much you need to store, I will give you example because I have updated data. So account Connect Working Group there was presented €1,000 Internet Exchange, it's kind of operator. You can start telecom ‑‑ small operator business about €2, €3,000. So because you are aware ‑‑ pack Nagios start of storing this data takes in force on 1st July, some special companies start presenting their commercial offers and the minimal set of equipment cost half million. You can start business with €2000 but by request and requirement of law enforcement you need to spend another half million. Actually, for telephone ‑‑ for voice traffic for plain old telephone conversation this package is already in force, and when you are calling to Russia you should know that your voice call is stored for one month. Is such surveillance effective? No, I am not sure. The only possible control of this mass surveillance is actually ‑‑ data might be used later for investigation or in court case if the previous wire tapping order have been issued. So by statistics by Russian courts about one million of wire tapping orders are issued per year and to compare we have about quarter million criminal cases investigated per year, so just to see how much surveillance appears. A lot of criminal cases get to public law enforcement officials usually like police forces, related to cyber crimes, sells the records, all voice messages which they obtained using this services. Some of them ‑‑ businessman get blackmailed and it for sure very effective for fighting political oppositions because the yellow TV channels and news papers get voice records of opposition leaders.
So the next thing, I remember the conference of RIPE in Rome the first day we got our ID checked and got passwords for WIFI networks but on the last day of conference the requirement to publicly identify users was ‑‑ it was 2011, does not require identification of its users. Two years after that, the national legislator required identification of any wi‑fi users so you have to have at least Russian phone to use public wi‑fi just because later and ‑‑ to use your phone number your identification. Also a lot of legislation related to sales of SIM cards so that user of phone SIM card must be identified, actually doesn't work, I can buy SIM card with my idenification until until I go to public transport stop from my home. Another funny thing, all corporation must store information of who is using Internet in their corporations. It was a very funny thing about four years ago we got a request of who is using computer with this private address in some corporation. That corporation was shut down by Central Bank and there was external administration and that was closed, they closed contract after eight months of contract closures the police officer came and start asking who was using dedicated computer in that corporation. For sure, as a network operator it was not able to answer this question, but after some years we see that funny regulation appeared.
Another thing, it's very use ‑‑ Supreme Court court of Russian Federation issued if law enforcement have your smartphone enhance it doesn't require additional search order to search ‑‑ or warrant to see your communications on your device. So, if you get detained for drinking alcohol in a park, in Moscow, then the police officer or department is able to search your phone and read your messages and whatever else. Another thing: Imitation of law enforcement activities we call this punishment for likes and reposts because we have regulation which prohibits distribution of terrorist extremists content also well, something we call, can call, and it's really easy for law enforcers to find a criminal and get ‑‑ criminal because they can do this without standing up from their places, they need just social networks and for sure, some companies really easy with a law enforcement instantly providing information about their users. So, on the next slide, I can try to give you example how it works in Russia. So if you are really care about things which happened in World War 2 please close your eyes until we go to the next slide. So is this picture Nazi propaganda? What do you think, here is written add offal Hitler, what do you think it might be Nazi propaganda. Second World War was won by super man. This is from victory parade, any Russian definitely knows this is not propaganda but actually some people was accused of Nazi propaganda because it contains for posting such symbols. Like the ‑‑ and the one guy who was in Appeal Court, lower court solution was dismissed and there was a great campaign, everyone was riposting this picture exactly. But now you should very careful in posting Second World War pictures. It's easy for law enforcement, just find picture and Nazi symbol.
The TOR exit node operator at his home computer was arrested for spreading terrorism propaganda information. Before exact moments the community have their anonymised, their account was posting this messages and ‑‑ so it was identified as a physical person. But for investigators there was no other reasons, you have this IP address from this IP address message was posted on forum, you are responsible for that. Like Mr. Bogatov in this case, Mr. Putin was accused in one of interviews of ‑‑ of indifference to American elections and he was asked, there was a report published with IP addresses and something like and Mr. Putin in interview says oh, IP addresses means nothing. Mr. ‑‑ release jail ‑‑ this ‑‑ there is no court decision on this case yet.
Another one. Content blocking. Every country has illicit and illegal content. About a year, 2012 there was an invention for new regulations that we need to protect, and the inventors of regulations says we need to block three and only three kinds of content on the Internet, that is child abuse images of sexual, drug production and sales and suicide propaganda and methods because there was a wave of some suicides by children. So, it was decided that communications would provision entity held a list of such materials and make a decision for drugs, it's now ministry of internal affairs, which is drug control unit, for child abuse and for suicide methods is consumer protection entity. So sending this ‑‑ it must contact the host or resource owner and then we take down ‑‑ if is not successful be added to the list and list of to operators to block. So, at that moment there was no strict requirement for operators how to block information and there was no responsibilities. But there was requirement to download ‑‑ but late ‑‑ if the system of blocking is already implemented, why not to use it more widely? So any information considered illegal by Russian court was added to this list. Then counter feet contents, online piracy and whatever else. Previously Russia existed the list of federal extremist materials, it was ‑‑ it at that moment have about 1,000 entities, so that is information which strictly not very good. So then personal data protection so if a website of personal data or lately does not store it it in ‑‑ doesn't store personal data of Russian citizens in Russia it might be added to this list or LinkedIn by Microsoft is blocked because of this. Any forms of terrorist and extremist propaganda it was added later in legislation. Gambling and tax avoidance, for all this kind of information, different LIRs or law enforcement agencies could issue respective order. For terrorists ‑‑ such enforcement agency is general prosecutors office, for counter feet is Moscow city court ‑‑ but yeah. The funny thing, the ways to avoid blocking of content using Internet is also considered information to be blocked. So, it goes around and around. Especially important things that any ‑‑ that information that any court in Russia could block related information. Even without adding to such lists or changing legislation. For example there was a scandal where ‑‑ when a representative of Russian president was met on the I can't recollect with Russian oligarch and they were discussing ‑‑ UK legislation so when this information got published in Russia their local court of the city where oligarch was born immediately issued take down order for such kind of information. Local courts also try to ban any information, you know all religious books can have something like ‑‑ speech. The Bible never was banned by Russian courts but one it was done by Koran but released from the list of extremist information. On content blocking and imitation of activities. After such legislation was I can at that enin force WIKI pages related to ‑‑ got to this list and Wikipedia had to change Russian version a bit just to avoid accusations of drug propaganda. Humoured pages containing ‑‑ you remember the first information was kind of suicide, so humour pages saying that stop breathing and you commit suicide, also blockage list. LinkedIn refused ‑‑ well, they just don't respond to request to store personal data of Russian citizen in Russia so they get blocked. A funny thing Wikipedia humour site ‑‑ also was blocked for personal data law violation. The court order was needed to take down ‑‑ the funny thing that ‑‑ by Russian court Tonga TLD registry was considered as a valid state for process so not resource ‑‑ he was not able to get to this process.
Again, I will try to run fast. I have some more slides. So in the beginning of it this blocking processes there was no strict recommendation how to block content and there was no control method, but later there was introduced fines for operators not blocking properly so if operator is missing to block something he is fined for about €1,000, €1,500 and actually the recommendation on how to block content, does not match actual ways to control it. ‑‑ distributes small devices which looks like RIPE Atlas probe because on the same hard wearing engine must install it and these device blocked content if it's successful in accessing then operator get fine. Therefore operators try to overblock so not just domain name, not just IP address, so in some cases operator need to block the whole domain without IP address by ‑‑ try to resolve this domain name and block respective IP addresses but if the really malicious person behind this to main adds number of IP addresses and for sure operators try to ‑‑ to perform blocking by redirecting traffic to special filtering engines and routing tables overflow and they must ‑‑ they might ‑‑ and this bring issues to network routing so such abuses appear some of the times and now recommends to all operators to set up DPI for the whole bandwidth so there could be problems.
Also there are new legislation, why I am trying to talk to this, because our legislators try to introduce new ways of blocking. One of them is critical Internet infrastructure which enforce routing registry. Under the goodwill of having safe copy of RIPE database, as trying to enforce all operators to use their own ‑‑ registry in this case it's worked very fine. If you don't need to have Facebook on your country ‑‑ it no longer exists. Also they heard about BGP blackholing so one of the Russian companies is experimenting with how content could be blocked. I have to stop, download my presentation.
BRIAN NISBET: Go to the conclusion slide.
ALEXANDER ISAVNIN: We have no evidence that content blocking is bringing any success, no official data on this things but content blocking only works for political censorship. I have to skip very funny case related to tell gram messenger where huge amount like /10,/11, the whole networks got blocked. None from technical community say that such indifference to the network routing is really bad. So even you are not affected by such law enforcement abuse, first of all it might came to you and Internet makes our work much closer. So don't say it's a miracle first, European Union, BGP first and also don't say that we are just technical community, no one should ‑‑ we should only do technical things and not politics. You see politics came to technical community in Russia. Thank you very much.
BRIAN NISBET: Thank you. Unfortunately we don't have any time for questions or discussion.
ALEXANDER ISAVNIN: Feel free to ask me questions with more details.
BRIAN NISBET: So sorry for the speedy finish of that but thank you, Alexander for the presentation. Can we get the agenda back up there again, please. Not that there is much there. I don't believe there is any AOB? Is there any AOB anybody has? No. Okay. In which case I will remind people that we are always ‑‑ obviously there is more discussion to be had on the mailing list. Please, we are always looking for new and interesting things to talk about in Amsterdam in October, where maybe we will have new policies or something. As Jordi attempts to put a Working Group in every region in the global. Listen. Thank you all very much for your time this morning and this afternoon. For your input, please take other things from the mailing list and hopefully see you in October in Amsterdam, thank you very much.
LIVE CAPTIONING BY AOIFE DOWNES RPR