Archives

Anti‑Abuse Working Group

27 October 2016

At 12 p.m.:

BRIAN NISBET: Right so. Hello, if I could ask people to take their seats and come in or not come in or otherwise, please. So, welcome to the RIPE 73 Anti‑Abuse Working Group session. My name is Brian Nisbet. Co‑chair, unfortunately Tobias is in Paris at the, I am going to be polite about this, badly scheduled MAAWG meeting, shall we say, so it's a pity that the two meetings are on at the same time, but there is little we can do about that. We must struggle on.

So, yes, welcome, everybody. We have, as usual, the wonderful stenography, recording everything you say. We have NCC people, both scribing for this and doing chat room monitoring, so thank you very much for to all of them. While we are not in the main room and you don't have to put your hands up, microphone etiquette is still very much of a thing so if you are speaking at the microphone, please clearly state your name and whatever affiliation amewses you most at that given point in time.

If it happens to have something to do with your day job, that would be lovely, but not necessary.

Yes, the session is being recorded, etc., etc.

One other thing I will say because I should with my PC hat on as well, you still have time to vote this the PC elections, until whatever time we decided it was today, 18:30, I think, so you can go to the front page of ripe.net, read the biographies and vote on the candidates for your PC which is obviously integral to the meeting.

I would, at this point in time, say we could approve the minutes of RIPE 72 but I only sent them out yesterday so that seems unfair to you all. So we are going to give it a couple of weeks and then we can approve them on the mailing list, if anyone has anything ‑‑ if they have read them and want to make any comments now please feel free, but otherwise we can handle that on the mailing list.

The agenda, are there any additions that people need to make to the agenda at this point this time? No. Cool.

And finally, I would remind you all of the RIPE meeting code of conduct which is not just the plenary by any stretch of the imagination, it's all of the pieces of the RIPE meeting and around the community, so please be aware and please be excellent to each other.

So, let us move on.

A number of people made slightly humorous comments to me when they saw the recent list discussion agenda item. During my three‑week holiday this year, which is lovely because I work in Europe, the mailing list slightly exploded, and there were all sorts of conversations about all sorts of things. Now, I'm not going to stand up here and represent any of those, because things like the definition of abuse were not my ‑‑ they are not my idea. I make no judgement on them but they're not my idea so I am not going to stand here and present those ideas. I did ask if anybody was interested in coming forth to speak about the definition of abuse, and unfortunately the person who had led a lot of that is on a plane somewhere so it is difficult to dial into the meeting at this point in time, although Internet in the sky is still something that fascinates me. So what I kind of wanted to say was, first off, in regards to the mailing list discussion, remind everybody yet again, and this is something that Address Policy were talking about yesterday, we are all colleagues in a global community and sadly the anti‑abuse community, again globally not just in the RIPE community, has a reputation for very strident communications when talking about something they feel passionate about. And it's a ‑‑ strident is good, what is strident then kind of washes over into when we start looking at add whom non‑attacks and playing ‑‑ no only diminishes, the conversation but it diminishes the community and it makes those people who we really want to be reaching out to hesitant about getting involved in conversations. I think there is still more, a lot more signal than noise on the mailing list and this is a very positive thing but I think we need to be aware of the fact that we live in a very different world now and we want people who may not be as used to this kind of strident conversation to be engaging in it and they will not do so if what they see is mud‑slinging and things like that. So please, again, bear this in mind. Make your points and you be make your points without having to attack anybody else on a personal level.

So yeah, I suppose to a certain extent is there anything that anyone wants to talk about in regards to recent list discussion? What I plan on doing, now that things have slightly quietened down, is going and looking at the document ‑‑ the definition of abuse document as it stands at the moment and seeing how the author of that wishes to proceed. What I think the most obvious way I suppose, is to see if there is consensus in the Working Group in regards to turning that into a RIPE document or otherwise. I am not ‑‑ right now, I am not proposing there is consensus; I am just saying that that seems, you know, that seems like the proper way of going forward with that, and then we can see what we want to do and see if that involves changes to the Working Group charter or otherwise. Because I don't feel that it is a good job of us just to leave it sitting there.

I suppose the other piece we were talking about was around RIPE NCC contracts and the conversation there, personally I feel that has been answered and completed, so unless anybody feels otherwise and needs to restart that conversation, which is of course possible.

Any comments on any of that? Are we broadly happy with the notion that I will go and I will see if Andre wants to push that forward as a RIPE document and see if there is consensus? And I have my only personal estimation of what is going to happen when we look for that but I think we should go down that road anyway.

PETER KOCH: DENIC. I would ask you as a Chair, taking into account the resources of the Working Group, whether you are in any way confident that there is an odd chance to reach consensus in a finite amount of time?

BRIAN NISBET: So, personally, I do not believe the Working Group will reach consensus. However, equally, I don't believe the question has been asked, and I think that there is a formal step there where we say, someone has brought this document in, there are things that I feel I should do as a chair which say this is the road this would go down and we can put some ‑‑ we can put some time bounds on that and there is a draft sitting there. I suspect personally, given the previous discussion, that the answer will be fairly clear on it. But I think that, again I think that that is the process we should follow and we will put some time bounds on it, I will figure out what they should look like. I don't really want to restart the entire conversation, but I think that there should be some formal conversation around it.

PETER KOCH: Okay, thank you.

BRIAN NISBET: Okay. Anything else? No. So, we had a policy, Peter wrote 2016‑01. We discussed it for a bit, Peter withdrew 2016‑01. This was a tricky one on many different levels and I think that it exposed the issues that were expressed with it, I tend to believe were issues with the broader question of applying policies to legacy resources, and points ‑‑ these points have been made and the policy was withdrawn on that basis, and it was not going to reach consensus at that point in time. There is a bigger question for the community to answer about whether we can apply policies to legacy resources and things like that. I do not believe it is the Anti‑Abuse Working Group's problem for want ‑‑ I don't say problem ‑‑ I will say question to answer, I think that is something that should take place else where, whether that is Address Policy, because you know we wouldn't the Anti‑Abuse Working Group making more secret policies that no one is looking at. But in all seriousness I don't believe that is a question for us to answer so I have no intention of raising it here. If anyone wants to make any comments about the withdrawn policy or that, should feel free to do so but I think that is a problem for other Working Groups at this point in time not ours, although obviously if a new policy comes out ‑‑ comes to this Working Group that does touch on legacy resources, we will have to consider it at that point in time and kind of try and reach some sort of, I don't know, community agreement elsewhere, but I don't know, get involved in that as an interaction. Anything else on this? No.

Interactions. With Working Groups, there really kind of hasn't been any at this point in time and maybe Ruediger, you want to comment on this, but the last piece we had was from the database Working Group with a request to supply some abuse handling information, information has been supplied and we have, as yet, received no feedback on it. So, at this point in time, I'm like, okay, we supplied a thing, the NCC supplied some stuff, we also sent out some MAAWG information so it's what is ‑‑ what is the status that have? I don't know because I haven't had any further comments on it. So, are we good for the moment? Are we ‑‑ is more work needed, this is the question? I am kind of ‑‑ you are the one who brought it up, Ruediger, so that is one of the questions I'm asking.

RUEDIGER VOLK: Sorry, can't comment, I had severe information overflow for the past weeks and I did not note anything.

BRIAN NISBET: No, no, so this is this would have been supplied, it was shortly before Copenhagen, it was information supplied and then post Copenhagen Tim put out more information from the NCC point of view.

RUEDIGER VOLK: Ah. Let me phrase it this way: I don't remember any time I really felt ‑‑ well, satisfied and I certainly felt unsatisfied many times.

BRIAN NISBET: Okay. Can I perhaps ask you or other members of the Working Group to look at the information that was sent out and maybe be a little bit more precise about why you feel unsatisfied with that. Because it's very difficult to work on things if we don't actually know more about the precise reasons why there are problems.

So the other piece of interaction is our interaction with the always wonderful NCC, so I am going to Athina to come up and talk about what information the NCC will and won't reveal in an abuse Working Group context.

ATHINA FRAGKOULI: Thank you. Hello, good morning. I am head of legal at RIPE NCC. There was a discussion in the mailing list, as Brian already mentioned. It was a lengthy discussion, it took place in August. And it was mostly about the way RIPE NCC's handling abuse cases by their members. It really started as a request for figures, like how many organisations have terminated their membership agreement because they have abused something that violated the law, and so on. And we did provide these figures. And shortly, it became a little bit more specific. There were concrete questions about who were these members who terminated their agreement because of a violation, and what exactly happened, what did you evaluate really, and what were the specifics? And the specifics we did not provide. And there is a reason for that: We have a policy and I am going to explain today this policy, what exactly we share and what we do not share.

We make a distinction in the information we have, we have publically available information and non‑publically information and when I am talking about publically available information, I mean the information that we maintain and we make public, not public information that are somewhere else publically available. So we do share information we publish, we point to them every time there is a question, yes sure, here is the information you are looking for. Non‑public information we have no right or no obligation to publish or to share, with the exception of legally binding Dutch order, we are a Dutch organisation and we have to comply with Dutch orders. We also have a mandate when it comes to fraudulent cases, to report those to the authorities, to law enforcement authorities so we do that.

When it comes to members' audit, we have a process when we ‑‑ where we receive reports from third parties about specific members. We do publish aggregated data, we publish how many reports we have received, and how many evaluations were successfully made and how many reports had to be dropped down because there was no substance to them. But the members, the names of the members that have been reported on, we don't publish and we do this for a very simple reason. If we start publishing the names of the members that are reported on, then the competitors will start reporting each other, just to create a bad reputation for each other so we don't want to have this kind of misuse of our reporting system. Also, we do not share the outcome of an audit with anyone, actually, with the person that reports in particular. If some things change people can see it in the registry or in our list of members but we are not going to report back to the reporter.

Also, we do not give any details about our evaluation process, and this is also very deliberate. If we start saying what exactly information we are looking into, what tools we have to make sure that this information is correct, we are pretty much create a guideline ‑‑ guidelines, a good book for those that want to abuse this system and don't want to be caught so we are very careful not to reveal our process, our evaluation process here. This is the way we are handling things right now, but if you have any impact or any other suggestions, we are happy to discuss this, of course. And I will be happy to reply to questions as well.

BRIAN NISBET: Thank you. Questions.

SPEAKER: Alexander, open net. Actually, there are two kinds of people who can ask the questions. First of all, general public, I do not disclose public information. NCC is membership organisation. I am not very confident with Dutch law but have an example from other countries: The members have a little more rights towards this information. So, how it's going in Dutch legislation. So, if okay, if a member to member use something like, this information, I hope, I am not sure, must be available for other members but because it's internal to organisation not to general public, not to database but it's certainly in organisations. So, it's question in general and there is a concrete question, actually, it's not anti‑abuse but with electronic votings we lost information on who is joining general meeting because we see a list of people who are attending meeting in person but we don't see who registers for or who casts votes or something like so I have feeling that this must be available under some conditions even in Dutch law. So it's just an example of different kinds of information which must be available, may be available.

ATHINA FRAGKOULI: Thank you very much for that. It's a very good point to make this clarification: In the presentation today, I am talking about members' information and we are not revealing each other's information of the members we have. Of course, because we are membership organisation, we have to report back to the members on organisational stuff, so RIPE NCC information, organisational information, indeed we may want to report back to the members, but not members' information ‑‑ but not information about other members, in particular. So, yes, it's a different question, the one you are asking, and I think the general rule is that as long as this is no like security problem or any other confidential issues, we usually we do mot ‑‑ we do reveal this information but this is something maybe yeah to bring back and to consider. Thank you.

SPEAKER: Thank you, but still more questions than answers.

BRIAN NISBET: Any other ‑‑ yes, please

PETER KOCH: Who is not paid by Brian to come to the microphone. So Athina, I very much appreciate the clarification and I think of course it's a reasonable approach with all the explanations given. Now, I wonder whether this is right now and here reaching the right audience and looking just at the slides and with the discussion we had before on the mailing list about terminology your slides say handling abuse by members. Could you give, without rehashing that whole discussion, but could you give a rough estimate of you would mean by that term "abuse" here.

ATHINA FRAGKOULI: I can give you a very concrete example. Sometimes we receive fraudulent document, fake IDs, I am talking about abuse of, in a contractual way, not abuse of content or anything else, I am not talking about that.

PETER KOCH: It's not their abuse of the network but their attempt of fraud or misguiding the NCC.

ATHINA FRAGKOULI: Exactly.

PETER KOCH: Let me ask a follow‑up question, if there is an LIR or maintainer and the maintainer maintains objects and it turns out in an object, the singular, has wrong information, is that abuse?

ATHINA FRAGKOULI: We have a process, it's called closure of LIR in the registration of Internet number resources, where we explain exactly what kind of incorrect information in the database we don't appreciate, let's say, so if you ‑‑ there is a responsibility for the members to have their information in the database in accurate and correct and so on. And in this procedural document we specify exactly which objects we want to be correct. If those are not correct, then we are following up.

PETER KOCH: Thank you.

BRIAN NISBET: Anything else? Okay, thank you very much Athina.
(Applause)

So, I am now going to ask Greg Mounier from EC3. So Greg spoke at the plenary on Monday, Tuesday, some day earlier this week, time, it's funny. And so this is a kind of a ‑‑ hopefully for some greater and more in‑depth discussion.

GREGORY MOUNIER: Thank you, Brian. Good morning everyone. So, for those who didn't attend my presentation in plenary on Tuesday, I am working for the European police Europol, cyber division, EC3. What I want to do is add up on and to delve a little bit more into details of what I presented on Tuesday about the Whois accuracy and the views from the public safety organisations we have about it and I think it's important because it's not only a problem of public safety organisations but it's also a problem of the wider public because nowadays everyone is using the Whois database for many different issues. And I think it goes beyond the network operators' community and I think it's really a mature interest to tackle this issue.

So the objective of the presentation, again to give you a quick update on the public safety use of the Whois and I explained the challenges we have in using it in our daily work, in our investigations. I have then two slides on the case study that I already presented on Tuesday, it's just a quick summary. And then what I want to do, and that is really main the you main purpose of that presentation, is to open the floor and to get your feedback and to explain also what we are planning to do over the next six months and requests for your help and for your expert advice and your input in a potential policy proposal that we might be presenting next year.

So, very interestingly, after the discussion we had after the plenary presentation with Alex and with others and the questions and the very timely intervention of Athina as well at the end of the presentation I just wanted to clarify that the access to the RIPE database is available to anyone providing that the terms and conditions are followed. So it is not restricted to one specific community; this is public information, and we are not talking about the non‑public information that RIPE NCC has or we are not talking about sensitive information, we are just talking about publically available information that is in the RIPE database so we have do have a right to use this in terms of usages, as I said on Tuesday, there is a traditional purpose for these databases of course and this is entering the uniqueness of Internet number resources usage and then the more important one for you guys, facilitating the coordination between network operators, a problem with resolution, troubleshooting, etc., but because the Internet has evolved and there are more users of the Whois nowadays, there is also an element of accountability, and it is clearly stated in the RIPE database terms and conditions and that is exactly the provision that is thank Athina quoted on Tuesday, providing information about the registrants, maintainer of Internet number resources, when the resources are suspected of being used for unlawful authorities to, parties who are authorised under the law to receive such information. There is to ‑‑ to look into the database and find information to seek redress. So in practice that means that the Whois is used by many different actors to combat abuse, fraud and secret address.

Public safety use, that is specific use or law enforcement entities but also consumer protection organisations, will use Whois lookups but it is only one of the many tools we have, we have different investigators can use different tools to find and combine different types of information so they get accurate pictures but in most of the investigations when you have an IP address the first port of call is always the Whois, it can be the RIPE database and also the DNS Whois but we always start from there.

The problem we have, and I think that is also a problem for you, is what we call the IP address chain of custody inaccuracy, so this is mainly related to suballocations and further assignments of IP resources, and we think that they are not properly documented and that leads to outdated data, misleading information and that is not practical for us and for you as well. The other aspect which is problematic for us is that each Regional Internet Registries tend to have different policies and requirement for what information needs to be retained regarding sub allocation so that is two aspects of the problems that we might be trying to tackle with eventually a potential policy proposal next year.

That is just a quick graph where we try to he will straight our points so. That is the IP address chain of cussty so you see that, for us, we might ‑‑ we have identified maybe an issue at this stage when LIRs or member of the RIPE community, if they are providing the resource directly to the end users, people that are using the IP addresses that is fine. In fact, our experience is most of the information that is maintained by the direct members of RIPE is most of the time accurate, and Athina has just explained that you have procedures to make sure that those information are accurate and up to date so we don't have any issue with that and most of the cases we are working on are case where is a range of IP ‑‑ a block of IP has been first allocated to LIR then sub allocated and further down the line, reassigned several times and then going through that chain of downstream assignments, then the information gets outdated, inaccurate and etc. And I think that is where the problem lies. And if you go through your different policy, we think that there is no clear requirements to keep accurate registration ‑‑ that are being assigned information. There is an explicit reference but we think that is maybe the compliance aspect is not there.

Just to recap a little bit: The contractual obligations for the direct members of RIPE are very clear, the policy framework is pretty clear. Section 4 of the IPv4 assignment and says that ‑‑ must be correct at all time. That is fine. In terms of the standard service aagreement, there is also a mechanism in case of non‑compliance, suspension, deregistration and so on. So that is pretty clear. For the direct members of RIPE it's very clear. When it comes to sub allocations, if you look at the Section 5 .4 of IPv4 address allocation and assignment policies, it says clearly that LIRs is contractually responsible for entering the address space allocated to it, is used in accordance with RIPE community's policies. It is recommended, therefore, that LIRs have contract requiring downstream network operators to follow the RIPE community policies when those operators have sub allocations. Problem: How do you implement that? Where is the compliance mechanism for this? So, again, I am just pointing at something, again not being part of your community and probably missing some aspects and that is where I'm expect you also to teach us and to educate us, maybe there are other aspects we are missing, nontheless we think this is a challenges for us, the first main big challenge for law enforcement agency seeking for an address of an ISPs who is allocating some specific range is that we can't ‑‑ we can't ‑‑ we are in the position where we can't serve legal process to get more information on the end users because can't find the proper address, that is providing connectivity to that end users. Inability to quickly identify resources used in abusive activities, that is very important. We had the discussion with Alex the other day, you know, you say that you are wasting the time of investigators. It's not only the fact that investigators are paid by public money and therefore they might be better off doing else rather than just browsing the RIPE database to get the information, if an abuser is abusing a victim the whole time you are wasting to find the information to serve legal order and to take actions, the victim is being victimised. Of course you are wasting your time because if you have doing to serve legal order to the first LIR and no, it's not us it's been sub allocated, so we go back to the judge and serve new legal order to next, the been reassigned and we go down. You are wasting time and money and it's really not optimal.

And then of course, when the information is outdated there is a bigger risk of IP hijacking and the criminal activities goes on.

So, what do we need? What would we need? We like to have clearly in the database, we want to know who and where in terms of ISPs to serve legal order on. That is very simple. We want to find in the database the real address of the last downstream provider in allocation of suspected IP address. In other words, we want to know the address of the ISP which is the closest to the subject or the person we are looking for. What we don't want, and I really want to clarify that because I had several discussions with some of you during the last few days and there is a lot of misunderstanding, we are not after end user data. This would be illegal, we can't get ‑‑ we want to have the registered address for any business, for any company, any ISPs who is providing connectivity. And I think that is clear, we can have a discussion and I can repeat that many times, that is not what we are after. Two slides to sum rice the case study I showed you on Tuesday. Supermarket chain whose IT system has been compromised, leakage, 7 .8 customer details stolen, you go through the log finds and you find out that there is one specific address which was reality to this attack.

What do you do as law enforcer? You need to find is ‑‑ to where ‑‑ you need to find an address so that you can serve legal process on the ISP providing connectivity in order to attribute attack to subscriber. That makes sense, you need to find the ISP, so you start ‑‑ you go in the database to try to identify the address of the hosting provider. The result of ‑‑ in the presentation and if you are interested you can go back to the slides of Tuesday, you will see after maybe 10 different steps and about 2 or 3 hours of research, the information and the provider in that case and that is a real case, in the RIPE database we found three different addresses in the UK, one address in Serbia, one in bellees, one US fun known and one Swedish and one UK phone number. We serve legal order to all those five addresses, you think we can go to judge and say we have suspicion that this address is linked to, but actually the provider has five addresses, can you fill in the gap and send it it, doesn't work that way. You can't expect business community and law enforcement community will do that. We need to have clarity and in fact if you look at your policy it is pretty clear that this information should be clear and uncontested. And there is nothing contentious about it, I think. So policy proposal: We don't, again, we need to be educated to your community and your requirement and your business requirement and your constraints so we don't really have a policy proposal yet. We just point doing a problem. What we would like to have is that you guys help us to develop something that makes sense, that is meaningful for us but also four. Something that is achievable. We don't want to spend years of going through the multi‑stakeholder government's process to have with awe policy had a can't be implemented. I have got a day job as well and coming to RIPE meetings is great, having great time but we need to be serious and if at the end it's not achievable I would rather go somewhere else, rather go to ICANN. So the policy principle we have, that is the bottom line. We would like to have, to require that registrations of all IP sub allocations and downstream assignments need to be registered in database, so that the entire chain of sub allocations are accurately reflected in Whois. That is the bottom line for us. We don't want to disclose end user information, I can that is clear but want to if he can you say on downstream ISP that is providing connectivity to the end users. I think it would be beneficial for the entire community it, would provide both public with effective incident response and then you can do your work.

We need to find a proper way to ensure adherence to that policy requirements so it can be incentive, community incentive, find a smart compliant system. We are very open to any types of proposals. Maybe we need to change the system bigger, I mean maybe a small patch won't work. Maybe we have to come up with something a bit more ambitious. So the way forwards: We are not ‑‑ I am not alone as Europol, Europol is engaging with RIPE, makes sense, other colleagues as well, but we are trying to engage because it should make sense that all the Regional Internet Registries are having the same discussion, of course we are not proposing a general policy for everyone because that is not the way it works we would like to have a reflection going on in the five registries. So what we have started, in fact, is that this year, we had a similar type of presentation at LACNIC in September, then I had colleague from, we went to APNIC and did more or less the same presentation to raise awareness, my colleague from FBI did same presentation in Dallas and he today in front of you for today and AfriNIC will be done in December or November by Mauritius police and Africa union. This is kind of a coordinated effort to try to raise awareness. What ‑‑ our goal would be to intro Tuesday individual policy proposals in May next year, probably at the next RIPE meeting, something that makes sense to RIPE, and it's not a global policy vie ‑‑ I think it's very important. We want the help of the five regional Internet communities to draft something that makes sense, and yes, we are seeking industry assistance, maybe if the ‑‑ in the assemblies some actors that are willing to engage, you can send an e‑mail to Brian or to me, we can brainstorm until May, come up with something that makes sense for you guys and then try to kick off the discussion. Thank you very much.
(Applause)

BRIAN NISBET: One thing I am going to say before we take questions, is in regards to the policy proposal, myself and Greg were talking about, it may not happen in this Working Group; it may happen in a different Working Group, we will obviously ‑‑ when ‑‑ if and when that goes ahead, one of the things I will be doing is working with other Working Group Chairs to figure out the appropriate place for such a policy. So just to say that out first.

But the request there is not just for people in this room, the for the community in general to try and get some people together to work on that. So just going to say that first. Now, please.

SPEAKER: In personal capacity. Very appreciated your presentation about especially your ‑‑ statement as you defined what is the goal of this idea, I fully support it. But I still worry because interpretation between law enforcement around the world absolutely different, and what is really happened with, for example, this new gTLD policies ‑‑ it's clear attempt to push registry to be network police and your statements are clear but even what was discussed during APNIC meeting was absolutely different. And I really worry that ‑‑ I don't want that RIR should become some new tools as network police ‑‑

GREGORY MOUNIER: I agree completely. That is one of the main problems, the different framework and different type of jurisdiction we are dealing with. The question is shall we not do anything because in some country that might be abused or the police don't have the same ethical practices than in others? I am law enforcement, don't ask me that, I will say no. We are going after the bad guys and I am sorry if it can be misused by others but anyway we are not trying to find ‑‑ to put the IRRs in the position of putting or blocking anything, getting some information in the database which is beneficial for everyone.

SPEAKER: Simply wants to stress again that what is keep on ‑‑ I know law enforcement care around global tools and they try sometimes to use us, reach the kind of registry, more success or less success but it's not our role to be involved in national legislations. And I want to remind you it's really ‑‑ a few bare walls inside community, be very, very careful, we will help you. Thank you.

SPEAKER: Hi, Tim Armstrong, this time representing myself. I am concerned that requiring LIRs to make sure that our clients are updating their clients' information in the database would end up exposing us to extended liabilities, that I don't think we should be. It's a dangerous path. If they don't keep their data up‑to‑date, what are we supposed to do? Cut them off? Thanks.

GREGORY MOUNIER: Thank you. It's a valid point, absolutely, and we need to take it in the reflection, absolutely. I understand.

SPEAKER: Alexander, also speaking for myself. So I would like to thank you presenting here at our community, and just to show you how warm our community, I can't imagine myself presenting at police conference without ‑‑ with data what police is doing, you see we are very good community. So, we are community, and our policies, members of our community and members ‑‑ members of NCC as members of community are following the policy on voluntary basis. We are not enforcement agency, as I said my ‑‑ there is no way for community, for NCC to enforce an operator what you do. So, but there is another example: I live in Russia, for example, and we have ‑‑ each ISP have such set of papers for each of its customers, because with current date, copy of ID ‑‑ because if one ‑‑ they have got problems with national ‑‑ financial authorities, but again, this data exists, there is no possibility to enforce adding this data of some kind to the RIPE database because RIPE database is not a tool for that, it's not your tool it's ours.

So, also, remembering your example from your presentation on Tuesday, I would like to say that nearly all data you presented with all the set of queries, different IP addresses, it's a valid data, actually, the Dropbox companies exist, the persons exist, somehow, maybe phone numbers also valid. Who is responsible? All that is valid, we can't say Whois database, but you are ‑‑ Dropbox companies, you are allowing for criminals to have real phone numbers and something like, it's also not our target to find, is it correct, should the Serbian phone number correlate to British mail address or something like ‑‑

BRIAN NISBET: There are other people in the queue as well.

SPEAKER: I would like to suggest to, find other ways to do your job better than you doing it now. Also, my question, which I asked on Tuesday, I still don't get answer object my question on Tuesday, and I think you don't have it yet. How much such cases appears? In general, global, in Europe, Europol, Interpol, what else, if not, please don't come with us with policy or some suggestions without statistics, saying, yes, incorrect data is a real problem, otherwise I will object. Thank you.

GREGORY MOUNIER: Thank you very much, Alex. We had a discussion already, yes, we are going to work on trying to provide, not evidence but at least quantifying, it's a bit difficult but yeah. As I said earlier on Tuesday when we had the discussion most of the cases we are working on are in that situation, sub allocations and not on the RIPE members but okay. As to it's the police responsibility to prevent people from stating ‑‑ I am not to sure, that is a bit of a simplification. I get your point and let's keep the discussion going and include that and factor it in the discussion, absolutely. You have got a good point.

SPEAKER: From the RIPE NCC. I have a question and a comment from a remote participant. Sasha speaking for himself. The question is: If a police force has problem unravelling a web of organisations behind a resource, what makes you think an ISP is any better at it? And the comment is: Yes, we can expect that LEAs do all the investigative footwork, we pay them for it.

GREGORY MOUNIER: Yes, we are not asking LEAs or LIRs or ISPs to do the investigation for us, just asking to get the right registered address of companies. That is it. I mean, I don't know, it seems that for the community having some unclarity and grey zone is something which is good, I don't think so, not for your community or the wider public. You have registered address everywhere, it's just standard information and this is nothing secret to anything. We are not asking the ISPs to do the investigation for us, we can do it.

WOLFGANG TREMMEL: Also speaking for myself, just want to make clear that this is not my argument but that it's an argument I had 12 years ago in a former position from salespeople telling I am not putting my customer list any publically available database because my competition would see who my customers are and would start browsing it.

GREGORY MOUNIER: Thank you. Your customers are ‑‑ the database, you can see the sub allocation, what you can't see is the proper address of those companies. At the end, it's not a good argument.

HANS PETTER HOLEN: RIPE Chair. I would like to thank you very much for a very good presentation and excellent analysis. My short reaction would be, oh, most of the mechanisms you need are actually in place, it's just that we don't follow up on them. So there isn't really that much policy that is needed. One of the RIPE NCC's core value is keeping an accurate registry so what you are asking us is to do that. And that is something we as a community should take and see how can we, as a community do that, and I think it's very good that you make the ‑‑ draw the line that you are not asking for the private persons in the database; you are asking for the ISP where you can actually serve the order. And personally, I think that is a reasonable request and the community should look at how do we do that and how do we do that without revealing competitive sensitive data and so on because maybe we have gone in some cases too far in putting too much stuff in the database so that there is too much that is inaccurate, maybe we need to reduce it and keep what is in there very accurate. Thank you.

BRIAN NISBET: We are going to stop after Peter.

SPEAKER: Nick, I come from the UK Government, thank you very much, Greg, for the presentation, and the presentation on Tuesday. Thank you very much to everyone here for your comments as well. And yes, certainly I'm sure law enforcement people would always welcome guidance from the community on how they can use the RIPE database better and I have submitted my application to be a road sweeper, which is great. Just, I think back up what Hans Petter said, I don't think this proposal is asking for anything new, because, yeah, the community already does a good job and has sort of stuff in place regarding sort of the ambition for accuracy. It seems to me just an issue of timeliness and how we maintain the accuracy of the database in a timely fashion and I think that is maybe where there is a bit of a gap that can be worked on. I don't think it's a huge amount of work and I don't think it's a shift in how this community looks at the information it puts into its database anyway. I think it's just a ‑‑ timeliness and clarity. Liability, I don't see there being any. You can sort of offset that within the contracts you have with your customers downstream. Anyway, thank you very much.

SPEAKER: The question is mostly for maybe RIPE NCC than to presenter. Is Val ‑‑ when you change someone in RIPE database, there is no element to the check of this data so, for example, sending kind of link that user ‑‑ that ‑‑ that he understands this mail is for RIPE NCC, RIPE database and maybe some kind of SMS or test call to their phone number, it changes in RIPE database. So this limited check can, from my point of view, increase the quality of database. So, is there any plans to install this checks or not?

BRIAN NISBET: I think that is possibly aimed more at the NCC than...

SPEAKER: This is not been planned yet.

BRIAN NISBET: State who you are.

SPEAKER: Andre de la Haye, RIPE NCC. There are no clear plans yet on this. If there are any clear requirements. Feel freely to tell us about it. There will be a database Working Group later on today as well so those are the areas to discuss that and address those kind of questions.

BRIAN NISBET: Are you sitting down Ruediger or going to the microphone? Okay. So, thank you all very much. What I would like to propose at this point in time, is, as Greg said, need some help looking at this, drafting whatever it ends up being over the winter, so as Greg said, you can e‑mail me if you are interested in helping out, as I said this may not happen in the Anti‑Abuse Working Group, we'll have to figure this out, but part of the community which is very interested and passionate about these ideas. You can tell me now if you are interested in helping out and we shall note it down and make reference there, or obviously at any point during the rest of the week. And then we will try and put something together and see who we are at that point in time. Okay. Thank you very much.
(Applause)

So, Gabi, our next presentation is website‑targeted false content injection by network operators.

GABI NAKIBLY: Hello, I am from the ‑‑ Technion, in Israel. And today I will be sharing with you some research results we have done that focused on website targeted false content injection by network operators, I had collaborators.

So, it's well‑known some network operators alter the users' traffic, in fact over the past several years some cases have been known in which ISPs have been spotted altering their users' traffic, here is a partial list of such cases. And on the right here you can see a snapshot of taken bay customer, an American ISP, taken back in 2013, of apple.com and at the bottom you can see the advertisement, which is not organic to the web page and it was simply injected by CMA communications presumably to increase their revenue. So did many ‑‑ in all the cases in which ISPs have been spotted altering traffic, all of those ISPs were edge ISPs, meaning the ISP which directly solved direct connectivity to the end user and direct hop to the Internet. We discovered not only edge ISPs practice content alteration but also some non‑non‑edge ISPs, well edge ISPs target only the direct customers, non‑edge ISPs actually target the specific websites which means that the potentially all Internet users may be susceptible to content alteration.

So, how exactly have we identified those content alterations, so actually we monitored http traffic of many thousands of clients residing in a handful of networks and then we just monitored all the http traffic coming in from many web servers, in total of web servers in total 1.5 million unique IP addresses, and then we, this allowed us to identify content alterations for specific websites, so how exactly did we actually manage to identify this content alterations. We did so by simply leveraging on the inside that some ISPs that altered content do so in out‑of‑band manner. Let me explain what that ‑‑ out‑of‑band content alteration. This is out inbound looks like, we have a middle box that sits in path and simply changes the packet in place. So this is a very clean approach. However, there is two drawbacks here: First, the middle box is a single point of failure so if the middle fails for some reason, then perhaps the network traffic will also fail; and it's performance bottleneck if the middle box is ‑‑ becomes too loaded and we might have the traffic may become slow. So it's probably all of, you know, network operators had single point of failures and performance bottlenecks in their networks so some of them like to change content ‑‑ do content alteration in out‑of‑band manner in which the injector simply passively eavesdrop on the traffic coming from the server to the client and when it's time to alter the content it simply sends out a new forged packet and sends it to the client. Now, the injector is ‑‑ on the traffic passively using a tap or port ‑‑ so even if it fails for some reasons or become loaded, then there is no risk for the traffic. But still, the valid packet coming in from the server will be received by the client. So now let me illustrate this for new more detail:

On the right here you can see the web server, on the left the client and in the middle we have ISP that tries to alter the content seen by the client. And let's say for the second example that indeed this ISP does out‑of‑band content ought ration and let's say nor the sake of example he wants to alter content residing within the third packet the server is about to send to the client. So the serve sends the first two packets to the client, of course the sequence number you see there is actually the TCP sequence number, and then the ISP simply crafts the third packet with the forged content and of course the forged packet has to have the ‑‑ has to have the expected TCP sequence number as expected by the client, which is supposed to be aligned with all the sequence number of all the other packets. And it simply sends it to the client and of course, the serve as well sends the valid third packet to the client as well, which is not dropped by the ISP, again due to the out‑of‑band manner ‑‑ out‑of‑band approach. So, actually, the client now receives two packets: The forged packet and the legitimate packet, having the same sequence number, so we have here what we call a race, a race between the two packets, the first packet it will reach first the client will get processed by the TCP stack and its content will be delivered to the web browser, the second packet that reaches the client will lose the race and will simply be the discarded as unnecessary by the TCP stack.

And this is exactly the point in which we monitor the http traffic, very close to the client. So actually, try to identify cases such as races in which we have two packets, thank belong to the same TCP session, have the same TCP sequence number, but carry a different payload. This is the most crucial part here. Packets having the same sequence number but different payload should not really have been normal TCP session, and it's usually very indicative that the third party injected log content into the TCP session.

So, we identified those risk cases.

And here is the bigger table that summarises all the injection we have found. We have grouped the injections into 14 groups, based on the injected resource. On the left column you see the name we are giving to the group, the site and then the destination site, the site it was injected, the content of which was altered, the type of the site, the location of the site. As you can see here, most of the sites are located in China, which gives us the first clue as to the identities of the ISPs that actually practice content alteration. And the purpose of the injections, out of the 14 groups, seven of them are aimed to inject advertisement, presumably to increase the revenue of the ISP; five of them had some malicious indications, probably most of them were aimed to compromise the client machine; and two of them aimed to block content but they were not ‑‑ on top of those injections we also discovered or identified many injections that were related to censorship but we do not report on them in this work because censorship is already well researched subject.

So, let me give you some examples of those injections. The first one aims to inject advertisement. Here you can see http request going to ‑‑ Chinese service, for user analytics much like Google, so many Chinese embed resources of ‑‑ in response to that request the user got two http responses, the left one is valid and the right one is injected forged response, which is located to another JavaScript in entirely different domain, and this JavaScript simply redirected the user through a series of affiliate ad networks until it reached Google's and then the user was simply served with an advertisement.

Yet another example of an injection again for advertisement injection, it's for resource at JiaThis.com, a Chinese website for social sharing toolbox, presumably many Chinese embed this resource. On the left here we see the valid response and on the right the injected forged response the user got. And again, as before, this is another redirection but this time it's not a ‑‑ it's a redirection using a refresh tag and here the user is redirected to, by ‑‑ a Chinese search engine, the fashion store. What the user sees is search results from by ‑‑ for the search team which is presumably advertisement for euqiloom. Here you can also see the parameter TN, which is a referral tag which allows to show revenue with the ‑‑ with the entity that referred the user to make that search. This is how the injector actually made money out of this injection.

Another example of an injection this, time for American website, and it is, had some malicious intent. This injection victimised the users of many gambling websites across the world. And let me just give you some background. The GPWA is acronym for gambling portal web masters association, association of the web masters of gambling sites around the world and runs a certification programme so when a gambling sites meets the standard of the certification programme of GPWA it is approved and the gambling site gets to brag about it and show approval seal on its website. There are 2,500 such approved sites and here is one of them, online /KAS even know city.com, and there is the approval seal at the bottom of the site. Now interestingly, in many cases the seal is not stored locally as an image on the website but it is referenced to a resource the GPWA, like so, here is the example of URL. So, this means that every time a user visits on line /KAS even know city.com it fetches a resource from GPWA.org. Here is the example, such example of http request to such a resource, and here is the injected response user got. It is essentially JavaScript code that refers the user to another JavaScript code which resides within a domain called QPWA.org which is suspiciously similar to GPWA.org, completely different domain, not affiliated with GPWA and after we turned with this to the GPWA folks, indeed it turns out that compromised one of the routers or load balancers were compromised by an attacker which then utilised the compromise the router to inject those forged responses. According to the GWPA folks it was supposedly to inject advertisement and spoof affiliate attacks.

After the initial analysis of the injections we have seen, we wanted to identify the injectors, who actually did those injections. So actually identifying those injectors, it's a hard task, there is little identifying evidence of the injectors in the injected packets, so instead we tried to identify the location from which the injected packet was originated and/or more specifically the autonomous system from which it originated. Since the injections were not easily reproduceable we could not simply repeatedly send the http requests that triggered the injections with increasing value of TTL until we got the injected response so instead we had to resort to the following based on the TTL value of the injected packet and it is based on the following well‑known insight in which major operating systems has default TTN values which are 32, 64, 128 and 225 and if indeed the attackers' machine uses one of those values we can calculate how many Ops the packet, the forged packet traversed. For example, if we see a forged packet with a TTL value that equals 59, then we can most probably assume that the initial TTL value of that packet was 64 and we can calculate the number of hops this packet traversed, which is five, 16 ‑‑ minus 59. If we know the path from the server to the client then we can simply pinpoint the exact location of the injector by simply just counting 5 hops from the client back to the server and pinpoint the location of the injector. Mind you we don't have to be really exact about it, we just want to know the autonomous system of the injector, not the exact location.

Now, knowing the path from the server to the client it's not very easy, we can trace route from the client back to the server but as you probably all know, Internet routes are not always symmetric. So instead we utilise the RIPE Atlas which probably many of you know. RIPE Atlas is a global network of probes that aims to measure connectivity and reachability. So we selected a few probes that were in the same autonomous system as the injected websites we have seen, and then we ran the trace route from the probe back to the client allowing us to approximate the path between the client and server, still approximation, but a close one. So this is the results of this analysis, which were remarkly consistent in all of the cases. The injector resided two to five hops away from the injected websites, which means in all of those cases the injector resided within the autonomous system as the injected website. And here you can see the operators which are in charge of those autonomous systems, China telecom, the operate ‑‑ very large operators in China, the American ISP relates to the GPWA case, it is not directly responsible for the injection, as I said, one of its router were compromised.

So, to conclude, following a large scale survey of http traffic we have discovered not only edge ISPs practice content alteration but also non‑edge ISPs, in many cases to increase the revenue. We also discovered some numerous incidents of malicious intent. And we also in the paper, in our work, suggest the clients side mitigation in case http cannot be used and we publish samples of injections, the link is actually in the paper, so all of you can check it out and if you are interested, look in the injections. So, with that. Thank you very much.
(Applause)

BRIAN NISBET: Thank you very much. Questions. Points.

SPEAKER: From MD networks institute here in Madrid, Spain, thank you for the exciting presentation. So since we are in the anti‑abuse session, so my first question is, how do you see this injection of advertisements by, say, edge networks, is it kind of an example of abuser ‑ see it's legitimate business model to use to support ‑‑ to support the extenses.

GABI NAKIBLY: Not at all, I think it's illegitimate for ISP to inject ‑‑ to alter the content of users in any way. It's illegitimate business practice. Period.

SPEAKER: Also, you mention at the various last slide about non‑edge networks. Can you comment a little bit more, is it ‑‑ can it provide some fake traffic to customers to get more in the traffic revenues or it's along the content injection that you talk about?

GABI NAKIBLY: By non‑edge ISP refer to autonomous system that is not directly attached to the end customer, and it sits along the path between the user and the server. It sees all the traffic between the user and the server. Okay. So this is what I mean by non‑edge ISP.

SPEAKER: Martin ‑‑ the first I should think about maybe some of this injection was not done by transit ISP so I believe some of them can be done by injected route as well as /32 through some kind of Internet Exchange point or private peering console, so maybe it's good idea to analyse these cases for this kind of injection and to prevent it just ask this Internet Exchanges and so maybe points where this can be injected to deny this. And the second is a question: Did you analyse, is it legal to do this on the different countries, so in which countries it's legal to do and which uncountries it's illegal and a crime?

GABI NAKIBLY: Good point regarding the first point, maybe it was due to, you say maybe it was due like a BGP hijack of /32?

SPEAKER: Yes.

GABI NAKIBLY: Perhaps, perhaps, I cannot rule this out entirely. And regarding the legality of those injections, well, most of the injections, as you have seen, are coming from China. I haven't looked at the legality of such business practice in China. I know that the China telecom are government ISPs, ISPs that are handled by the government, so my short answer is, I don't know.

SPEAKER: Will, https user. This case reminds me something I saw in the past on some of the servers I was managing where the injection was happening directly on the server so it was on Daemon that was actually injecting stuff in the http request directly on the machine so that is like similar case but I think it's really interesting. And the other thing I was wondering is, where do you see cases where https could not be used?

SPEAKER: Simply when the web server ‑‑ website do not support yet https for some reason. The site owner was still ‑‑ was too lazy to issue a certificate ‑‑

SPEAKER: Can you expect those people use let's encrypt for instance.

GABI NAKIBLY: According to recent surveys, I think ‑‑ it was 200 from ‑‑ two years ago, still many sites regretfully do not support https.

SPEAKER: Alex. I still have no data for Russia where it's quite widespread practice, some major sellers spoofing to sites but that is not what I was going to ask about. Mcknack is it legal in Russia?

SPEAKER: Illegal but they are trying to insist it is. I was going to ask if there was a kiss where you succeeded in ping down the compromised router which was injecting and like conducting their own ‑‑ taking it out for this action or whatever? That can knack pinpointing the exact router?

SPEAKER: Yes. And contacting the owner and asking him for some help to, well analyse what is ‑‑ what is happening inside there.

GABI NAKIBLY: We did contact GPWA case and we also contacted the Chinese ISPs, but I don't know what they did with this information. And that is it. GPWA did ‑‑ came back to us and in terms this was an actual attack, but with regard to the other ‑‑ with regard to the other ISPs, especially the Chinese ISPs, I don't know what happened there, we just ‑‑ they didn't come back to us on this point.

SPEAKER: So.

BRIAN NISBET: We are running very tight on time at this point.

SPEAKER: So no one has public ‑‑ what exactly is happening in this routers how it was compromised and what ‑‑

GABI NAKIBLY: You are correct, I cannot rule out that perhaps the Chinese injections were based ‑‑ were because of compromised router within the Chinese infrastructure, for some reason, and it was not the fault of the ‑‑ those ISPs. I cannot rule this out. I don't really know. I know the forged packet came from their infrastructure. This is it.

BRIAN NISBET: Thank you very much.
(Applause)

So, AOB. The one thing I would say is, obviously there is a very large elephant in the network abuse room at the moment, has been for some time, but got even worse in regards to the denial of service attack and the compromised IOT devices and the sheer amount of traffic that was involved. You see, we don't have time to discuss all of that here today. There will hopefully be some lightning talks in the plenary sessions tomorrow about this, but I think it's something that we do want to potentially look at having some content on at the next meeting.

Is there any other AOB that anybody needs to raise? No. In which case, I will mention we are obviously already looking for agenda items for RIPE 74, and DDoS may well be part of that, who knows, we will have to look at at that thank. Again I would remind people in regards to please, if you are interested in working with Greg on the proposal, please make contact, mail him self, mail me, my mail address is all over the list and we will see where we go from there. Other than that, thank you all very much for your time and hopefully I will see you in Budapest in May. Thank you very much.