These are unedited transcripts and may contain errors.

Antiabuse session, 1st November 2011:

CHAIR: Hello. If I could ask anyone who is coming in to come in so we can get the working group started. Can we dim the lights a little. Excellent. Thank you very much. I can see. I can make sure all my speakers are in the room. Right so. Hello and welcome to the RIPE 63 antiabuse working group session. Those of you who are regular attendees might notice we're much earlier in the week than usual due to the vagaries of the trading session that take place to get all the slots between all the working group chairs, we ended up being one of the first working group sessions of the week in retaliation to Curtis's comments earlier, next door there's some other thing. If you are here to learn anything about IPv6 you're in the wrong room. It will be mentioned on occasion but not in deep technical detail.

So we have an agenda. First bit is to welcome you. My name is Brian Nisbet, my cochair is Tobias Knecht. So thank you all very much for coming. There is a wonderful scribe from the NCC. There is someone monitoring the Jabber channel and there's our wonderful stenographer, which is the gift that keeps on giving, all the comments repeated and held for eternity.

And this time I can see the screen which is a marked difference from RIPE 62. Anyway, microphone etiquette, please say who you are and where you are from. The agenda is there. We have the minutes from RIPE 62 which I think there was a comment on and we fixed. I'm not aware there's any comments anyone needs to make at this point in time. And the agenda is fairly finalized. The one thing that I should mention because I saw this yesterday is I found the perfect piece of apparrel for the antiabuse working group which I shall now model for you.

Yes we're not quite the network police, you understand, but  there's no law enforcements in the room, is there?

So to continue then, no additions to the agenda so we should move on to item B. Recent list discussion of which there was quite a bit. I'm not going to go into all of it, quite frankly because some of it was not terribly constructive. I think one of the most recent pieces of discussion was in relation to reporting abuse to RIPE and we very handily have a presentation on that very matter a little later during this session. So hopefully that will be addressed and that was one of the main things that came out. And I think it's been fairly recurrent and we've been discussing it and I'm hopeful the NCC are doing a lot of work to address that and we'll be going into that in more detail later.

So we have our first presentation then I think. Yes, your name is first. We have a presentation so thank you very much

Jaoa Damas: .

JOAO DAMAS: Thank you, Brian. I'm not as familiar with the slides as I wish I was, with you better now? I can hear myself. The talk is about passive DNS, maybe some of you have seen something about this in the past. It's a bit of a status update as well and some instruction, we'll go through that quickly. Or maybe not so quickly. (Passive)

Okay, it's the Microsoft to the PDF converter that is making the machine sweat. Just quickly, an introduction of what we do, it's better for the bind products and so on. One of the things we have is the SIE. Well, so much for the laser, which is the framework where this activity is housed. (SIE)

So just quick review of what we're going to be talking about. Let's see. A bit of history about passive DNS, maybe you've come across it. This was a technique invented in 2004, so almost seven years ago. There are some public efforts. There are also some private ones. It was to use PCAP tools, so you're probably familiar with, to capture packets and study them. The idea is that this is focused on DNS because malware, virus spam people use DNS most of the time, it's convenient, but not to do so in an active way, to listen to traffic by participants in normal DNS exchanges but not interfere, just listen and record it and see about what information can be extracted.

Imagine that, it was turned off. Works much better. So how does this whole thing work? When you start a new cache on the DNS system, you have clients, when you start the new cache it's completely empty, gets the first customer, it goes out, does the whole serve, DNS until it gets the information requested and answers back to the client. Normally it's recursing servers are also recaching servers, that means the next question that gets asked about the same data doesn't  the recursive server doesn't go through the whole search process just answers the question from the cache. When it comes to collecting the DNS data, the two sides of the DNS recursive server have different properties. On the lefthand side, the one between the client and the recursive servers, you have some properties you don't have on the other side, one of them is personally identifiable information. You know the address of who is asking which question, and you also have a lot of volume because everyone is asking different questions and there's no use of the cache. You don't want to capture the data there, passive DNS is not going to capture the data on that side because it's complicated, high volume and confusing. Between the recursive servers and the  you know longer really know who is asking the questions because all the source addresses are going to be the IP address of the recursive server and you don't have any additional information that you could use to tell who was asking the question. Maybe that will change in the future, there's this new proposal that Google initiated about including additional information to try to optimise the traffic for CDNs. They were having this problem that if people use Google DNS, then people are going to think that you're someone that's close by to where the Google DNS caching serve issers are and they're going to point you to conduit delivery networks close instead of being close to you. The only way to do that, to solve the problem is provide additional information to the content delivery networks and that includes some diffuse personal information.

The other thing is that the caching reduces the amount of volume data that you're going to be capturing because all the repeat questions you're not going to see between the recursive server and the authority server. That's much better place.

ISC started in 2007 because what was done and got all excited and got this thing running, and we basically have been learning as we go by implementing this stuff. We have seen evolution, how we do it, what tools, how we analyze and store the data. For instance, the basic capture of the data which is the first step, we started by using pick up then we moved to something that was DNS cap onwards and further was N cap tool and something more generic that can support transport for more than just DNS content which is NMSG tool, it has some properties. Of these three iterations, you can use them, there are some interesting properties like you can  automatic reassembly of the packets which is always a little bit of a pain with pick up to do the matching to get the complete messaging and so on.

So what do we want to capture? The messages, the responses that the servers are sending towards 000the recursive server. But there is much more to the DNS than just the perfect correct answers. So you want to capture that as well. But does it include as I said before, fragments, be there fragments of UDP transport or TCP transport, DNS has had for many years an extension to the original definition that allows transfer of big package information over BGP which was limited to 54  usually it was limited to bites. So it was extended and normally most servers these days can exchange DNS messages up to four kilobytes data. But that exceeds the NTU and you get fragments so you have to track them. You come across all sorts of broken behavior and they also get across people that are trying to pollute your cache, trying to attack you in different and imaginative ways.

What does the infrastructure that we have to provide this service look like? I have this network of sensors, passive listeners, that are located in the networks where collaborating recursive servers work. Usually they snoop on the traffic by using spam ports or these passive taps that Netopics and people like that do. And they basically these machines listen, capture the data and send it over the relays. The relay is played back to some analysis on the data is played back and they replay the traffic on to the network where reservers are located listening for these packets to do something with them. On top of that they are storing the database. The process data is available to the participating reservers through what we call channels. It is just the fancy name for labels for VPNs. So depending on which VPN you configure on the switchboard for your machine, you get to listen to different types data, access to the raw data. The first thing, the most trivial, is that duplicate the data so you don't get repeat messages. So that reduces the amount of data quite a lot. There's a separate channel for impassable data, you can't believe how much crap is out there. Some people have some interest in listening to it. And there's different stages of analysis, and eventually it gets stored in the base. You could listen on realtime or access the database for none realtime analysis. There's a lot of background on those URLs. The presentation is up loaded to the Working Group page. So you can look those up later.

How do we make this information that we capture available for use? Something we call the DNSDB, one is a web user interface. You can participate if you can show you have some useful interest for this information and there's some information on the web page, so you just engage with us, brief conversation with us and we give you a log in, you can go. Also API access for heavy users that I'll mention later. So what sort of information do you get from these? One thing that it allows you to do is cross regulation. I'm not sure this is all clear. It's a copy paste of a picture. If you have activity from a domain, you can query the database to see what kind of traffic associated with that domain has been seen lately. From that you gather IP addresses, and then if you take the IP address you can do another look up to see which domains are associated with the address and sometimes it's quite a lot of those that are used. You learn not only about the domain that was being used in the activity against you, the one that you observed, but you also get to see who else might be suffering from these and how they are making use of the DNS.

These, I think, is better to see. So this was a hack for registrar that the attackers basically entered the system and changed some of the name servers for existing domains. So for and we see more or less already an approximation of the time at which the change took place. Before they were served and then they got changed to some funky thing. And you look for the new name server, and you get this output. It gives you the list of domains that also have been changed to use that name server. So it gives you a quick run down of who else got hacked. And you have the list there.

Use malware has a tendency to use DNS as a communications channel. I'm sure a lot of you are familiar with that. If you can get, again, information about an IP address that has been detected and used you can query the database with that IP address and see the domains that have been observed in the field to be used by this malware program. And then you can take further views. You can also see the recording of the fast flux mechanism that these people use to try to go undetected. It's the same mechanism, you get the name, the IP, the list of other affected. This doesn't necessarily need to be restricted to security aspects of it. This is in the abuse working group. We have used this to measure IPv6 adoption in reality as people are using it, not what people claim to be doing, but what usage there really is, as reflected in DNS traffic. What can happen in some of these very creative users of DNS is you get a lot of domains in use, particularly when they resort to random generation of the domain names. And then what happens is you have things like this, whenever you use a DNSDB and you get an out put found 10,000 records, you have hit the limit on the user interface. We stop showing results over the web when we hit 10,000 because wouldn't make much sense to be honest. What you do, if you actually want to investigate cases like that, then you have the alternative user access and that's more restricted access. That's one of the mechanisms we use to finalize the expense that runs the whole thing introduces, the DNS API, it allows you to direct access with the query language to formulate whatever you want. So that's an example.

That's a small screen that queries the database. It's not that complicated. This is a list of other examples that could be used too. I mentioned the IPv6 one, basically the sky is the limit. The DNS is a very good reflection of what's going on in the network at a given moment and being able to observe it in realtime gives you a lot data and it gives you a lot of information. So certainly there will be more uses because people have imaginations.

As I was saying, who gets access? Any of you can get access to the web API. It's just an exchange where we get certain confident that you are going to use this for the good activitys and not for the bad activities, not one of these malware guys trying to use it to see how we're trying to detect you to avoid us in the next round. It's very easy. For the API it's a little bit more restricted. But there will be an email at the end where you can contact., the contact is the email you see at the bottom. Contributions: It don't necessarily mean money, though we like money. But data is value, if not even more than the money part.

And I think that's it. That's a very good overview.

CHAIR: Thank you very much. Does anybody have any questions?

AUDIENCE SPEAKER: Aaron Kaplan. I just wanted to mention that there are also in Europe a couple of passive DNS installations. We run one in Austria, and I believe there's one in Luxembourg. There's an effort undergoing at the moment which tries to make a common query Internet face for the passive DNS databases like a common API. So would you be interested in participating in that?

JOAO DAMAS: I think so. I'm surprised. The person that is responsible for the SI project now is Medico. I'm surprised she didn't mention the Estonians were already doing those, herself being Estonian. I'll definitely ask her to get in touch with you.

AUDIENCE SPEAKER: So the other question that I have is do you think about the whole collection data as a big collection actually as a whole being sensitive data protection wise sensitive? Because we thought about that. It's not an easy answer to that in my opinion.

JOAO DAMAS: I don't think we have an answer to that either.

AUDIENCE SPEAKER: How do you control who gets access? Do you do checks? If I'm an SP I would be interested in querying the domain names of my competitors.

JOAO DAMAS: So far the requests we have had are people we know directly or secondhand. We haven't come across the need to do that verification because no one has asked.


CHAIR: Anything else? Any questions? Thank you very much.


CHAIR: So by the way for the millions of you watching at home, I realised the camera is pointing there. I'm in front of the camera but I'm not going to the stage so you just have to wonder at the marvel of my voice.

So the next presentation is Laura Colby from the RIPE NCC discussing the NCC report abuse procedures.

Laura Colby: Thank you. Okay. Good afternoon everyone. My name is Laura and I'm the customer services manager at the RIPE NCC and I wanted to give you an update on reporting to the RIPE NCC I've noticed that invalid contact information particularly is of interest to this working group. We have looked at the process as a whole and how to report more than just that. But I hope you'll find it interesting, nonetheless.

So, first of all, we want to improve the process. And in order to do that we decided that we would want to put a web form into place as there are quite a few benefits from having a web form, both for us and for the users that we see. Firstly a web form gives us a single point of contact, whereas internally in the RIPE NCC different reports may be dealt with with different parts of the organization. The user doesn't need to know that, what they want to know is where can I report it. By having a single point of entry we enable that.

We also have thoughts that we would allow the user to categorize the report. By doing that we would get a clear indication of what is being reported and we would be able to quickly then redirect internally the report to the right department.

Some of the things that we want to implement in the form are a lot of questions about getting information from the user, but we also want to allow the user to obtain some information from us, and that's also something that our web form would enable us to do. In the case of incorrect contact information in the database, we do want to manage the communication flow a little bit differently than what we would normally do. So we've split the handling of the process into two. At the end of the day we hope that the process, when it's in place, will be much improved and will be consistent, transparent, easy to use and simple and helpful.

So we're going to handle the information in one of two ways. Incorrect contact information in the database we want to handle separately because one of the things we would like to do is facilitate the person that identifies that there's something wrong in the database getting in touch with the person that can then fix it. And then we have a lot of other things that can be reported to us, and at the moment that's everything else. I will start by talking about everything else actually.

So, yes, what is everything else, in a bit more detail, violations of policies and procedures, provision of untruthful information that could be either as part of the membership process or in the process of a resource request, for instance. Organisations which don't exist anymore or which never existed at all. Any kind of infringements to our copy writes, damage to the name of RIPE NCC and, of course, as we should be available to take reports of abnormalities within our own network if they should happen.

So in this case, with everything else, we want to manage the communication flow very closely. So the user would submit the report to us and we would keep the report internally, so we would not then pass it on to anyone else. Any information that the user submits will need to be clear, what is being reported, is there supporting information to show that the violation has occurred. And we will then tell the user, yes, this is one of the things we can investigate, or no, it's not.

And then what we will do with that is pick up either with the member or a third party, depending on what's been reported, we will open a case with them and investigate what's going on and what can be done about it. In some cases that may lead to an audit of a member. There are multiple possible outcomes of this check. But in any case, the results of the check would not then be communicated back to the user. We want to keep those two parties separate from each other. And likewise, the identity of the user is not then revealed to the third party or the member.

When it comes to incorrect contact information in the database, this is where we want to handle things a little bit differently and take an extra step to support the community in that. Initially our name is to bring, like I said, the user to notices the incorrect data in contact with the person who can update it. A lot of the information in the database is not maintained by us, but instead of sending the user back to the who is database to see who they should contact, what we envisage is the web form itself will have tools embedded into it so the people can enter the object they're looking for that has the incorrect data and we would use various tools like who is or abuse finder to provide contact information for them to use. So the first report would go directly to the end user. And the reason that I say that we do it like this is because it is very easy to assume that information is invalid in the database for a malicious reason, but more often than not, we find it's just naturally become out of date because of changes within an organization, a relocation or staffing changes and then there's either an oversight in making the update or lack of knowledge to update the information. And, of course, it may well be the information is deliberately incorrect, but that we intend to be able to find out.

So, like I said, first of all, the user to take it up directly with the maintainer of the object, or they may do this independently and then come to the web form, we don't mind. If they don't  if this communication doesn't work out for any reason, then we would allow the user to come back to the web form and state, yes, I have tried to contact the maintainer and it hasn't worked out and here is the information to show that I've contacted them and here is my information to support my claim that some information is out of date. And that information we will follow up on.

So the second time around, they submit the report again using the additional information, and we forward it through our internal contact information to our member. So if our member is the one that has the incorrect information in the database, they can update it, or they can get in touch with us and tell us they don't know how to update it, for instance. And if it's an end user that has the incorrect data, then the sponsoring LIR would then take it up at the next level and do the same thing. In either case, we will follow up on these with our member and check what the status is, check that  whether they need any help, whether there's some assistance we can give with updating the database or make some changes to other information, for instance, if one of our members has changed name, we can go through the name change process internally. We want to follow it up ourselves.

In this case the user will always be aware of what the outcome is because they will quite easily be able to check in the database, has the information been updated and because the user will already have been in contact with the maintainer, the identity  there's no question over the identity of the user that would also be public and that's where we have a split, the two processes.

To summarize, it's part of a bigger process improvement drive. We're looking one by one at most of our processes to make them more transparent, simple, easy to follow and more useful. This one in particular is a combined effort. The user also plays a role in gathering the information in the first place, reporting it. And then we play a role, along with our members in following up on those inaccuracies and investigating claims. I'm more than happy to come back next time and give you some feedback on the process as it is.

Does anyone have any questions?

CHAIR: Nobody?


MICHELE NEYLON: One very simple question: Where is the form?

SPEAKER: This is a proposal

MICHELE NEYLON: There isn't a form at the moment?


MICHELE NEYLON: Where can somebody go on the RIPE website at the present to report an issue?

AUDIENCE SPEAKER: At the moment you can use the email address and we can get further information and redirecting it. The process as it is, it can be improved a lot by the implementation of this web form.

MICHELE NEYLON: Is the abuse at address published on the RIPE website? I looked at this the other evening. I wasn't following up on the most recent discussion on the mailing list and I could find plenty of physical addresses and request all sorts of information about all sorts of things RIPE did, but I couldn't find an abuse contact point?

SPEAKER: If it's not there I'll check and make sure it is.

PETER KOCH: I had two questions. One was answered by question. Thank you for
The real question is: Are you envisioning any rate limiting or scrutinizing the reporter when forwarding this stuff to the members?

SPEAKER: Yes, we did contact that a web form could be abused and  as with email, just receive floods of reports. But we do want to take a step to verify who we're talking to so we don't just forward anything from anyone. And, yeah, we're think think of adding a step where the user would be sent an email to click to verify that they have submitted this report. But anybody can report anything. There's no  you don't have to be anybody to report that you found something. Peter Koch: That would include anonymous reports as well? Because if you have a random blah email address, as a reporter I'm not forced to review my identity, I just have to reach you by email, is that the case?

SPEAKER: We haven't planned to keep identities on record or check who you are, but we do need to be able to communicate at some level. Yes, this is also a first step and we may see that developments, further developments are needed in the future or changes when  if we release it and it doesn't work the way we want it to. It's not set in stone just now but this is the idea at least.

Peter Koch: Okay. Thanks.

AUDIENCE SPEAKER: Would it not be better in that case to link this web form from the LIR portal, in order to avoid  you could nearly call it denial of service attack with some people with too much time on their hands and throw away email accounts.

SPEAKER: It's a possibility but we limit the users to members only, that only members can report.

CHAIR: Speaking with my RIPE community hat, the one I'm wearing throughout this working group session, I would certainly not want to see the ability to report abuse to the NCC limited to members.

SPEAKER: The database contains information which is not members only, anyone can put information in the database. If it then comes back to a member, we'll discuss it with the member.

AUDIENCE SPEAKER: To answer the previous question, we have a list of email contacts for RIPE NCC on website. Also when the select  there's a web form for contacting, if you click on the. But it doesn't give all the options that were mentioned, but the improvements are coming.

SPEAKER: In the future there will be hopefully a lot of information about what to report and what kind of information to report. So that will be much clearer.

WILDRED WOEBER: Also with one leg half into the security and abuse thingy. I don't object against the user web forms to collect information about the complaint, but, first of all, I think there should be some very simple safeguard that the identity of the complainer is verified, not in the sense of having to submit a passport or something but to make sure that this entity is accessible, reachable, and there are simple technologies, this person has to submit by way of the web form his or her own email address, and then as soon as you push the send or hit or whatever button, then the magic harsh gets sent and unless this is verified like a reply or click on that particular link, I think you should discard this complaint because there are funny people around in real life. And while I do support the idea to provide a reasonably easy mechanism to submit complaints, at the receiving end we should try to make sure that the complaints that come in are real complaints, because some of those parties have to deal with dozens of complaints per day or hour. So adding on top of that it's not going to help anybody, neither on the receiving end nor on the complaining end because then this stuff will simply be discarded. And for implementation you would probably want to see some sort of proof that a contact attempt was made. You should probably also send in the context of this message to verify that you were the source of the complaint, probably send some sort of summary about the complaint or summary about the data that were collected by this web form, because web forms are one way the communication. But many of the abuse fighting folks do not use web form they use email, ticket systems. So something something which is preformatted, precooked in a reasonably well formatted format is more helpful for everybody involved because if things come in on one end it might need to be forwarded to someone else in the same organization. And having that in some well known format, this is coming by way of this platform of the RIPE NCC supporting interaction it makes it more credible than submitting something, a blush, and no one can track where it was coming from. Just an idea. It might be a little bit of work flow planning.

SPEAKER: It's a very good suggestion. Thank you.

AUDIENCE SPEAKER: I think it's a pretty good thing. One suggestion which is going in the same direction as Wilfred already said, there are email formats out there like R /PHRUBGS which can hope the exact same information as a web form can ask for. So for  for most of the abuse folks, it would be night to have kind of a form like that which is just able to be in a way automated or not completely automated but easier to create than going to a web sit, filling out everything, clicking a button. I can give you some information about some of the formats

SPEAKER: The formats of the form is not yet solid.

SPEAKER: That's exactly the point. There are formats out there which contain templates and you can say this is a template for us, we need this and this information and everybody can use, in the abuse community most of the people are using already these formats and for them it's easy, going to a new template, new information, going.

SPEAKER: We'll look into the different ways of handling the information. Yeah, definitely. Thanks.

CHAIR: I have a couple of questions for you: One of which is when this web form goes on line, what will happen to abuse at

SPEAKER: Abuse at is an email address which is published throughout the database for contacting us when somebody in our network is questionable. And that will remain so. The email address will remain open. And if somebody sends an email to it, we will just point them to the form.

CHAIR: Okay. And the next question, and I know you said you'd come back to us to give an update and again from the history point of view, thank you very much for presenting on this because RIPE 62, I forced dean /A into agreeing that there would be some update on this and she forced you into giving the presentation. When do you think this might go into production or when do you think you might know when this might go into production?

SPEAKER: It's difficult to give you a date just now. We are collecting a lot of information at the moment about  from the community, feedback, specially this week, which will help us to prioritize our work loads for the next few months particularly. So we're hoping that in the time following the meeting, we'll have a lot of priortyization happening and then a clearer idea of when we can do what.

CHAIR: Okay. Unless there's any other questions? No. Thank you very much.


CHAIR: So our next presentation is from


MICHELE NEYLON: Good afternoon everybody. I gave a talk a couple of RIPE meetings ago about abuse and I'm back hopefully to give some thoughts and suggestions for something practical you can actually implement. If you're really board and want to stalk me, there are my contact details. So moving on to the meat of this. What we're talking about is dealing with abuse and I'm talking about this some the perspective of a hosting provider, if you're not a hosting provider it might not be relevant to you but it would be impolite to run out the door. We're going to go through why it's important and I'm going to give you some of these best practices. And the cat always features, this is my designer cat, it's cheaper than plague to patic.

Security issues, abuse, these are issues that are coming up time and time again. They're not going away, if anything things are getting worse of the some of the statistics floating around, the costs, the levels of the amount of D Dos attacks, some presentations on that earlier today. It's something that is prevalent and you can stick your head in the sand but you can't really ignore it. So I would say apathy isn't an option for you. You need to do something, take some kind of action. The other side to it as well, others might be talking about this during the week, the government has woken up and realised there's this big bad thing called the Internet and they don't know what to do with it. And when governments don't know what to do with things they're not going to sit down and talk to people they're just going to introduce legislation and force us to change our business operations which probably isn't the best of things. I would encourage that we as an industry get off our asses and do something about being seen to self regulate. It doesn't matter whether you're actually doing something or not, it's a matter of whether the rest of the world knows that you're doing it. And of course for those of you from the more business side of the room, if you have issues on your network, it's going to impact your brand, impact your reputation which is going to cost you money. How many of you here in the room are involved with hosting in some shape or form? Okay, put your hand up higher, Sasha. How many of you in here run dial up, DSL, that kind of service? I'm trying to work out who I'm talking to here. Okay. How many of you deal with abuse reports on a Daley basis? Quite a few hands going up here because that's not on the screen. Are you taking proper active measures or letting it wash over you, dealing with it as it am cans along. Do you have processes in place? And coming back to the brand thing again, if you spent millions of euro or dollars or whatever currency you're working in, the last thing you need is to end up on one of these nasty reports, they gave a list of the top three worst hosting providers in the world, how about that, that's great PR.

Again, coming back to self regulation, it means you're in control, you control your destiny, you can have the impact. If you're seen to do that, government is going to sit back, okay, they're being addled, they're looking after themselves, not breaking the law. If you're not seen to self regulate, government is going to come and it's going to be top down shoved down our throats. Data retention directive is a prime example. It's been implemented in most European countries at this stage, how many of you would say you're happy with how it was trance posed into law? Any takers? Anybody know what I'm talking about? Okay, never mind. So, you know, the thing is, you can be scared, just cover your ears, but ultimately you should try to deal with it. It doesn't have to be that painful. I said in the previous presentation, abuse best practices, doesn't have to be complicated, doesn't have to involve extra costs, running an effective abuse desk, sure you don't make any money from it directly but I would argue if you don't look after it properly it's going to cost you money in the long run. So the practices I'm going to look at are the ones developed by the guise in stop bad wear. If you sign up, you can have one of these nice logos. And basically what they've done is broken down the entire kind of flow of how you're meant to deal with an abuse report into a number of steps, you get the report, you acknowledge it, good manners, I think. You study the report, evaluate it, decide whether the report is from a reliable source, not some random nut job who has nothing better to do all day. If it's suitable you might pass on the report further down stream or upstream, depending on what it's about. Take action to mitigate, if that's suitable. Resolve it if it's within your power and coming back to the person who reported it, go back to them and politely say I've taken action, or this is unsuitable or please get lost. Give them some feedback. Tracking it. If you keep seeing the same kind of issue time and time again, are you going to ignore it or use those metices to see maybe there's an underlying issue with your customer base or something else. And reviewing what you're doing. And I have a nice little flow chart which you won't be able to sense of thrown up there, but the idea being, depending on how it fits in, you take an extra action. And then if you  what I would say then if you can follow these kind of best practices, it will make your life that little bit simpler. You don't have to come up with complex flow charts. They've done it for you. They're not saying you have to take action on every single abuse report you get, you have to evaluate it, is that abuse report relevant to what you're doing, is it realistic, is it an a case of abuse, malware, fishing or something completely irrelevant? If it's just a conflict between two third parties you can politely say, look, go sort that out yourselves, this is nothing to do with us. And by taking this on board, this is what you want. You want to show governments and law enforcement that we as an industry have grown up, we're not petulant children, we're going to look after things. Then you can relax in the office, sit back and enjoy. And not scream too much, I would hope.

So that was very short and to the point. Sorry Brian if I ruined your timetable. Any questions or complaints, feel free.

CHAIR: I think that ran to a third about your listed time.

SPEAKER: You said I only had a short time and I usually overrun.

CHAIR: Thank you very much. Are there any questions? You all have all your procedures and you know exactly what you're sea doing every time an abuse report comes in?

Okay. Thank you very much.


CHAIR: Right, if we could get the agenda slide back up, that would be fantastic. Excellent. Thank you very much. There we go. So to move on through the agenda and there's a number of other things we'd like to cover. The first of which is the abuse contact management task force. This task force was formed roughly a years ago. Is that right? After RIPE 61. There was a number of policies submitted in Rome and we felt the best way to deal with them was to form a task force to look at this and the task force concentrated on the abuse contact management specific area of those, which was all of one proposal and about half of the other two. We asked for volunteers from the community and we got them, which was wonderful. And we've had  we had our fourth meeting on Monday as was reported in yesterday's meeting report which I'm sure you all read. It also have very nice things about me but that's an entirely different conversation. So, yes, we initially said our scope was we were hoping to have a proposal in place or ready to go for RIPE 63. That, for those of you paying attention, hasn't quite happened but we have done an awful lot of work and the task force is progressing nicely and we're almost to the point of having a proposal. Seeing as Tobias is the one doing the most work, he's going to tell you about it.

SPEAKER: Thank you, Brian. Yes, Brian already mentioned the passport is almost a year old. We have done a lot of work. We have discussed a lot of different possibilities. We had a lot of concerns which we tried to figure out how we can solve them. It was really, really short, so we would have been able to propose the proposal already in RIPE 63 so there's not much to do anymore at the end of the proposal, but we really want to make sure that the proposal is really behaving and is really good in what it's doing and solves most of the issues we are seeing at the moment. Therefore, we had yesterday a good talk about it. It looks like at the moment, if nothing, big changes will come up, something like an abuse contact like we have the admin C or text C things. It looks like we're getting stuff done in a way that it's easy for maintainers to maintain the objects and to administrate all these things. It's much easier than it has been before. We were looking at a hierarchical structure which is talked about at the moment. We were talking a little bit about the query, what's the end user needing and a little bit about the clean ups to clean up all the other things like the abuse mailbox spread over the who is database. I think we're in a really good way at the moment and hopefully we're getting everything sorted out. I have reworked a proposal today with people from RIPE NCC and got help with the wording and technical background on this. And hopefully we can do the discussion over the next few weeks and come up with a proposal as soon as possible. I think we're not promise but said we're come up with a proposal in RIPE 63. Didn't work so far, but I think we will have a proposal in place before RIPE 64 or much earlier. So...

CHAIR: Because the proposal will actually be said issued relatively soon, I don't want to have a discussion about the  what Toby has just talked about because that's the bones of it and the full proposal will be issued, assuming, of course, you all agree with it, the PDP timing should have it in place for RIPE 64 but we'll see how that goes. The task force, as he intimated does not feel  we haven't shut up shop at this point in time. We want to make sure that this proposal passes and if it doesn't, if consensus is not reached we want to make sure we can sit back down again and work on an alternative proposal. Once we have that done  once we have a proposal passed and it's hopefully going to be the one we'll be issuing next one, once Emeliio gets sleep after the RIPE meeting, we'll sit down, reexamine our scope and see if the task force has done its job and whether it can be wrapped up or whether there's six months more work that we can do usefully. We have no intention of going on for ever and ever. The mailing list for the task force is the archives are open, if you go to the RIPE mailing list archives they're all there so you can take a look. And indeed, if you wish, you can join in from the mailing list point of view. That proposal is sitting in antiabuse. We will obviously be sharing it with the good folks in database because, well, it's about the database and hopefully /HR will be some  compliance would be fantastic, but I suppose a robust discussion is is a more likely outcome. Once the proposal is sent out it helps the process if you express the opinion, even if the opinion is this is great, I love it, do tell us that, because the working group chairs find it immensely easier when a definitive point of view is given, rather than well, nobody's objected, it's probably okay then. So we don't have a lot of policies coming through antiabuse so it's nice to remind you all of what you can do when they do crop up. Obviously we will continue to report on the task force via the antiabuse working group.

So unless there's any specific questions on that, rather than anything discussed about the policy. No? Okay. Interactions, well, working group database, unsurprisingly, there has been interaction with the database working group for the task force. There hasn't been a lot else unless I'm forgetting anything, and we're  there really hasn't been anything in particular there. From the point of view of RIPE NCC governments and LEA interactions, again, as promised we will continue to update you via the working group. As was mention and had all of you should be aware the government in law enforcement have woken up, oh, my god, people are using the internet, and for several years now the NCC has been doing, in my opinion, an excellent job of getting the law enforcement and government people around the table, inside the tent and whatever other metaphor or reality you wish to use. The initially suspicious conversations have gotten more and more collegiate and we've gotten to a point where there is an awful lot of extremely useful dialogue going on. One of the groups most involved has intimated that if they're not around as much as they used to be it's because they think the RIPE NCC and the RIPE community are doing a pretty good job of things, so they're concentrating a bit more on other things, which is extremely encouraging. I see you shaking your head. I'm talking about numbers here, what you do in domains a different matter. It is all the same but we are just talking about numbers for the purpose of these conversations because that's what we do.

There was two particular events this year which I'd like to highlight, one of which was Joachim, Marco and Brian go to Europol in their big scary building in the Hague. There was more security than there was in the anticipate to fly over to there. We went there mainly to talk about IPv6 policies and abuse fighting in IPv6. We might have scared them just a little. Talking about the fact that we're going to issue everyone four billion IP addresses may have scared them a little but it has woken them up again a lot to something we know is coming and that we want the LEAs to become aware of. They've been focussing for some time other single host addresses, on finding them not politely on the door with an appropriate piece of paper and undertaking their criminal investigation. We're pointing out in IPv6 it's not the host, it's the subnet and it has to be because you'll go blind and mad trying to find a single v6 host out of a /64, must less a /32 or otherwise. This message has got through. And they've started looking at training for  to train their investigators in IPv6 and to give them some grounding, start getting them to realise what needs to be done. Those of you again who are regular readers of the mailing list, will have noticed that it was Eric from  must be from  yes, from France, who has recently signed on to the list, so you have people there who are reading that and are becoming more and more aware of it. There was also very recently last Thursday, a CCWP, cyber crime working party meeting which was coincident with the meeting in Paris, I had act itch democracy to undertake and couldn't go along. We have a president to elect and various referenda in Ireland but there were a number of people there and, again, a very useful meeting, lots more introduction, lots more conversation and lots more cordial conversation, and a growing awareness of what we do and the fact that we are actually acting to undertake good stewardship of those sources that we've been granted from on high. I don't know if there's any other particular points to raise. Big thumbs up. We'll be continuing to interact before the next RIPE meeting we'll certainly, or hopefully, be going to the serious organizationed crime agencies London meeting that they organise every March which we've been attending  the NCC has been running an event in coincident with that for the last two years and I'll continue to hope it doesn't take place on St. Patrick's Day so that interaction will be ongoing. So we hope to continue to foster that.

Some of the things that they're particularly interested in is v6 registration policy and abuse contact registration policy. This is something that unsurprisingly they want to know who has what and as much detail as possible. And one of the things we're doing is working with those groups to find an acceptable common ground. The views of operators and  operators and enterprise networks and the RIPE community and the RIPE membership and RIPE NCC membership we hope are being represented and fought for and the interaction is that we've managed to come to a common ground and work with people rather than having things imposed upon us.

I don't think there's a lot more to mention on that. I mean, there's obviously, as many of you aware there's all sorts of things in government levels, number of resources, crazy ideas like web filtering, which is admittedly not something the NCC or this working group are involved in but it's something we're trying to keep an eye on if possible and attempt to inject clue into policy making, if possible, which is on occasion a very difficult thing to do.

So I don't know if anyone has any points they want to raise, questions they want to ask about any of the interaction processes we have or would particularly like the NCC or indeed the chairs of this working group to raise anything on an official level when next we interact with anybody?


AUDIENCE SPEAKER: Aaron. I was wondering if somebody thought about the possibility to use this recommendation can right now which goes to the regulators saying that they need to collect statistics on number of instance on each country in Europe. If somebody thought about, like, sneaking in a possibility to have a requirement for the IIT object so that ISPs should really finally update their entries, is that out of the scope at the moment? Out of the question or is that just maybe a new idea?

CHAIR: It's certainly not something I had considered. Wilfred, any feeling on that at all? Web

WILDRED WOEBER: Okay, thanks for putting me on the spot here. No, my immediate answer is no, I don't have any point of view with regard to this idea in proposal. Just process wise, my feeling is that we should at the moment focus on getting the proposal from the task force at the door and inject it into the policy development process machinery. And if  as soon as we get the community sort of to read that stuff and to think about it and maybe providing them as a framework for this policy proposal, providing them with a little bit of background, what our outlines of thinking were, why the proposal is the way it is, we may want to revisit that. I do see where he's coming from and I would have no objection to increasing the population of the IIT object, but my feeling is that at the moment it is more important to make progress with the task force results and if we can sort of line that up all during the discussion it turns out this is something we can just, as he said, sneak in, okay, let's do it. But I would not try  I would not want to see the package opened again and sort of induce further delay into this process, because sort of as Toby said  I think you didn't want to do that, but you pushed the point of time line expectation as late as RIPE 64 for this policy proposal. And I would rather see the community converging to a wellsort out proposal by RIPE 64 instead of sort of  you know, I'm having a funny feeling here that we should not drag our feet for too long. We should really make progress. And then sort of clean up the bits and pieces.

CHAIR: Speaking as the chair of the task force and indeed this is what we discussed and agreed, that policy will be going into the PDP as soon as possible. So, you know, next week rather than next year by any stretch of the imagination. You don't have any plans for Christmas Emeliio, do you? Drop the policy on you then? That's fine. Cool.

AUDIENCE SPEAKER: I think somebody mentioned something about time limits. As Brian knows, I also  I'm primarily focused on domains, hosting that kind of thing, and the problem we've had in our interactions with law enforcement and government is as a group we didn't move quickly enough. We didn't make  take action that they could look at visibly and say, yes, you are showing yourselves to be good citizens, yes, you as an entire group, as opposed to individual companies are published contact details, et cetera. So even though a lot of the registrars would actually be doing stuff that would have made law enforcement happy, the fact that it hadn't been kind of publicly stated, put into a strict policy, something that was binding on all of them, has caused a huge issue. I just came back from a meeting and as the registrar they drew first blood on Sunday and they continued to beet us over the head for the entire week. You were working around like this, stop attacking me. I know in the number space, this might not be perceived as being much of an issue. But if they get bored attacking us with names they'll come after you. They are always going to be looking for something. It's not a hard thing to do. It's really not hard.

CHAIR: You make it sound so easy.


CHAIR: If you could keep them busy for as long as possible, that would be great.

Sasha: I'd like to know whether the content of this discussions with LEAs is actually available anywhere. I for one would be interested in what law enforcement would like to discuss with the RIPE NCC

CHAIR: In the majority of cases the conversations are as one might expect from law enforcement conversations, reasonably confidential. What we have undertaken to do and what we've agreed with the CCWP as part of the rules that we laid down for communication with that, which I wrote when we set it up, was that unless something was explicitly stated as confidential, that it would be something we could report back to our various groups. This doesn't mean that the minutes are necessarily public, but it does mean that this Working Group amongst other similar groups that are involved in that working party have the ability to report back and say this is what's been talked about, and that's what I mean what they're talking about is IPv6 registration policies, what they're talking about is abuse contact registration and that's some of the big things. Some of the things the Europol meeting, was a closed meeting, some of the other LEA round table conversations are closed. We as a community and this working group and indeed the NCC believe that things should be as open as possible and we don't do that. As you can appreciate when you're working with some of the most paranoid people on earth, that can be a difficult thing. And I fully understand why they're paranoid, investigations, I don't even want to think about the careful stepping they must do that something they're investigating is prejudiced by information going out to the public. So the short answer is, in most cases no they're not. The longer answer is, while they're not, where possible and we work to make it as much as possible, we'll be reporting back that information through the antiabuse Working Group as far as RIPE NCCs and RIPE community is concerned.

WILDRED WOEBER: With regard to this interaction or to these interactions with law enforcement, we have to see the fact that there is a long way to go to build mutual trust. And that was actually what I wanted to start with, sort of following up on the issue of Dakar, I had the pleasure to be there and the primary reason for going there was to be involved in the final stages of the Whois policy, and I do definitely see movement on both sides. And I do see people from law enforcement becoming actively involved in community exercises. And stuff being publicly available like, for example, the minutes and the meeting transcripts of this RT 4 team are available and there's a very nice lady involved actively in this review team. So I think this is something we should actually try to build on, to give them the feeling they are welcome and to give them sort of what they need in the sense of, okay, there is an issue, work on that. This is our proposal. We tried to get it out the door, tried to get it wrapped up, implemented within a reasonable time frame. Then we can expect them to again come back to us before it's too late sort of. And that was a little bit of report about this Dakar thing, we're converging and as I'm the delegate on this domain name thingy is because I was from the very beginning seeing the potential, not saying danger, potential, to learn and also to sort of be early informed and aware of things that might come our way because as soon as they are done with the domainees they're probably going to take us up with the numbers. And assuming that we have prepared the house already, this is probably going to be more comfortable in doing that.

AUDIENCE SPEAKER: I just wanted to clarify one thing, not that we are able to have the policy in place like at RIPE 64, it was more meant that it's already acknowledged by the community, so that's the goal. I want to have it as soon as possible in place. And exactly because of the reasons before.

CHAIR: Now, so I think that's that on that section. So is there any other business? Anyone has a burning desire to raise at this point in time? Okay. No other business. So my traditional reminder of agenda items for RIPE 64: The working group and the last few working group sessions, what we've tried to do is have a mix of policy  and by that I mean policy in general rather than a specific PDP, sort of amount of technical information and conversation, and then the feedback from our various interactions and the updates on that. That is what we were asked to do when this group became the antiabuse Working Grouping group a number of years ago now and during the meeting in Berlin which involved charter bashing the entire time. If people would like to see something different, think we're not doing enough of one thing, then, A you have the opportunity to volunteer and give a presentation or please let us know either to the working group chair's address on the mailing list, what you'd like to see and what you'd like to do. There will be a lot of activity on that mailing list, please, raise things, use it, talk about it. If you're not already on the mailing list, join it. And I think that is that for us. So thank you all very much. Thanks to all the wonderful NCC people who helped us, to our wonderful stenographer, to my cochair who has to get a plane. And thank you to all of you and we should see you at RIPE 64.


Data base RIPE NCC: