Anti‑Abuse Working Group
26 May 2016, at 11 a.m.
BRIAN NISBET: Right. Hello. Good morning still in this time zone. Welcome one and all to the Anti‑Abuse Working Group session for RIPE 72, I hope you are all having a wonderful time in Copenhagen and that your week is going well. So we have a lot to get through this morning, and we are going to try and keep it ticking along nicely, there is a lot of very useful content and thank you for all who have provided it and hopefully we can get some good discussion were the room as well. Unfortunately my co‑chair Tobias can't join us. He has told me he has marked out RIPE 73 in hisical /TKER already with "do not touch or do not send me to America," et cetera, et cetera. We will hopefully see him then. It's just me for today.
The welcome, we have done that. The session is being minuted, the session is being recorded, the chat room is also being recorded, this is the RIPE NCC's version of mass surveillance, so please consider anything do you near a microphone will be kept forever unless you tell us otherwise. So thank you to the scribe, thank you to the NCC scribing and jabberring, to the stenographers, I genuinely do not know what I would do at a RIPE meeting without them at this point in time. If you are speaking at the microphone, please state your name and some sort of affiliation, pick one. The minutes from RIPE 71 were circulated, I think we had one change which we edited and recirculated. Are there any other comments on the minutes from RIPE 71? No, excellent, approved, etc., etc., passed into record.
The agenda again has been circulated. Is there anybody who needs to add anything to the agenda at this point in time? No. We will stay with our packed agenda.
One point we don't have here: You now have the ability to rate the talks in a Working Group as do you in the plenary sessions. It's a bit funny rating Working Group content but it does give me and Tobias a very useful feel for what people find useful and interesting and what people would prefer so if you are of a mind, you don't get any prizes for this unfortunately, it's just the Plenary content, you get the prizes for. If you are of a mind, you can log on to the meeting pages and rate the content we have. And finally, there is the code of conduct and enjoying a RIPE meeting, which was talked about by Hans Petter on Monday, please note this extends to the Working Group. This is, we need to be ‑‑ especially in an Anti‑Abuse Working Group, we need to make sure that we are very good to each other and we have reasonable and constructive conversation.
So, onwards. Mailing list discussion, primarily has been around 2016‑01 which we will be talking about in just a moment, so I won't go into that. There is been conversation about data verification and abuse‑c contact methods. Again, I don't think there is anything particularly huge, to talk about right now, in regards to what has been talked about on the list. Yeah, we probably need some more of them but I don't think we are at a point of anything coherent and as yet nobody has sat down to start writing a policy, so, if anybody wishes to say anything about that now, then they are more than welcome to but I would suggest that we move on to discussion of 2016‑01 as the substantive matter in front of the Working Group at this point in time. We could talk about the spam and the RIPE 72 hash tag if you want to, I found that quite interesting, but that's a different conversation. So, if that is where we are, move on to policies, so again 201601 which is extending abuse‑c to legacy resource holders, as you will have seen this new version of the text up there now, version 2.0, and the discussion period has been expended until June 21st but because we are here and there is a Working Group we will have a suspicion live discussion of 2016‑01 so if you want to come up.
PIOTR STRZYZEWSKI: Thank you, Brian. My name is Piotr Strzyzewski. I am the proposer of 2016‑01 and I will briefly describe what it's about. I am surprised there is no line next to the mike, yet. Abuse‑C was introduced in late 2012 after some months of work in the abuse content measurement task force, I see some members of that task force here. There are quotations from the policy so it's mandatory for all *out nons and it's at least every direct allocated INET num and INET 6 num needs to have abuse‑c. Right now we have that situation part of our resources have to have abuse‑c attribute. And legacy Internet resources are exempt from RIPE‑563 and what I mean exempt, they are not mentioned, exempt is in quotes. And RIPE‑639 confirm this exemption and confirms in the way that this policy says that any other policy need to precisely state that it's also mot just legacy resource holders and Internet resources so the exemption is confirmed some way.
So, because of these exemption right now we have more complicated database business rules because some innet nums do need to have abuse‑c and the others do not but can have one. We have two different approaches to abuse contact finding, if we have abuse‑c that's easy and straightforward and nothing to do of all fancy algorithms but if we do not have one NCC still provide two tools, one is abuse finder, the RIPE Stat abuse contact finder and the fancy algorithm and looking in the description fields and other places to find out who possibly could be abuse contact for the results.
And sometimes this algorithm fails and this leads to the inability to find a proper abuse contact for some legacy Internet resources.
So I came up with the proposal, it was given the number 2016‑01, the first version was quite strict, it says that mandatory abuse‑c will be for all resources including of course legacy Internet resources, but basically means that I would like to extend abuse‑c to all resources. And after some weeks of non‑discussion on the mailing list, there was an extensive post made by Ruediger, thank you, also a huge kick up of the discussion, and the heated discussion then started. I realise that maybe this is ‑‑ this was not a good idea to make it mandatory to contact all guys to invent what automatically ‑‑ invent what abuse‑c address put by NCC ‑‑ whatever, I changed my mind and proposed second version a few days ago and so it's still mandatory but the policy ‑‑ policy is applied only when creating or modifying legacy Internet resource objects in the database. So, if legacy resource holder is happy with the data right now in the database, we are not going to do anything about that and in the case that legacy resource holder will try to change legacy Internet resource objects like INET nums basically and then he or she will receive friendly looking error message like with this description, what is going on, why the update was not possible to be done without abuse‑c and so on and so on, so, I understand that this is a long‑term process probably without an end or visible end, unless v4 will die, which is not going to happen, I think. However, this will lead out at the end of that process to the more consistent data model with single business rules and no exemptions and, I already mentioned this is dedicated friendly looking message because right now when you submit something to the database all you get it's an error, not explaining anything, and the guys who doesn't have any contact with the database for long time like 15, 20 years, they will probably not have an idea what is going on, what the hell the update was not OK'd for the database.
So, during the course of the discussion, I think it was you,Peter, that ‑‑ someone, probably you ‑‑ mentioned that welcome message should be sent to the legacy resource holders to invite them to ask them to put abuse‑c in the database. I am not sure who was that but ‑‑
PETER KOCH: Probably not me.
PIOTR STRZYZEWSKI: This idea of welcome message is very good because we can encourage people in a friendly way and we can describe the case and can or let them think about that and decide what to do if they want to or not want to put abuse‑c in the database.
OK. And right now, there is a start of the heated discussion on the mailing list, if ‑‑ few supporters, few people against. And I see Ruediger standing next to the mic.
BRIAN NISBET: Sorry before you begin, I want to make a couple of points, I know you know this but just to say, discussion on policies primarily takes place in the mailing list, that is good moment too far bit of a chat about this, if you don't say say it in the mailing list it doesn't exist as far as the archive is concerned, if you make a point here send a mail about it later. One other point I would make: Regardless of your point of view of it, the Working Group got consensus on abuse‑c and it now exists, so, the fact that abuse‑c is there is a thing, it exists, let's not go back and try and discuss had a in the context of 2016‑01. If you want to discuss abuse‑c that is a whole other conversation.
RUEDIGER VOLK: Deutsche Telekom. Actually, thinking about your question who suggested, anybody who read my objection might have figured out that this was a constructive attempt and it definitely said we could actually send out friendly messages with documentation to people without even doing a policy.
PIOTR STRZYZEWSKI: Please excuse me. I forgot that.
RUEDIGER VOLK: In the heat of the argument obviously a lot of people didn't get that and well OK, kind of, kind of have you asked the NCC whether they would be prepared to send out this kind of friendly thing right now or whether they actually need a policy for this?
PIOTR STRZYZEWSKI: I don't think they need a policy for that.
BRIAN NISBET: We can ask the NCC. Non‑binding answer but just some sort of indication, I don't know if that is you Marco or somebody else or Tim. Apparently, it's you, Tim, you win a prize.
Tim: RIPE NCC. I think that would ‑‑ OK. A friendly message saying you may want to do this and this is how do you it, I think is something that we can do fairly easily. If there is an action required on the RIPE NCC to be more let's say persuasive then I think a policy is in order.
RUEDIGER VOLK: OK. So kind of, that kind of confirms my note that, yes, OK, this could be done without policy and quickly and would serve to a large extent the purpose. However, doing that, the Working Group obviously needs to come up with text and statement that can be used for this. So far the thing that the RIPE NCC has been ‑‑ has been doing when they were asked about it, was, the formal argument, the policy is ‑‑ has defined this as mandatory and there is no documentation, piss off. So, kind of, what I am saying is, if you are actually interested to get good data, give helpful information there is no obstacle in the way except that you actually have to explain to people and I think it's useless to discuss this policy with higher priority than doing a document.
BRIAN NISBET: So noted. Are you going to answer that Marco?
MARCO HOGEWONING: RIPE NCC external relations. We are more than happy to work with this community in better documenting what is needed and finding easier manuals that we are happy to spread amongst our membership and our resource holders. So let's consider this and invite the community to help us narrow down compass exactly needed and we are willing to discuss this.
AUDIENCE SPEAKER: Wolfgang, speaking for myself. Can you give us an indication of the size of the problem, how ‑‑ how big is the percentage of legacy resource holders that don't publish abuse contact.
PIOTR STRZYZEWSKI: Please excuse me, I didn't put the numbers in my presentation, Marco do you have them in your mind? A moment, yeah. In the meantime can I ask Peter for ‑‑
PETER KOCH: So I sent a message to the mailing list today asking for some clarification.
PIOTR STRZYZEWSKI: I have read it.
PETER KOCH: In your updated suggestion likely as in the previous one, you say well one of the reasons is there is a difference between legacy space and RIR space and they are treated differently and you have different database models and so on and this is not a big, it's a feature. The community decided that regularly space is different and I am really asking for justification which obviously has to be something else but it is just different, justification for receipt actively changing or making this policy apply there. That is the one point. The other is addressing your updated suggestion. That is really strange. We have heard many complaints about justified or not, about lack of correct data in the database, and you are actually suggesting to increase the barrier for changes to registration data. So I am wondering whether that suggestion is not actually detrimental to data quality. You are saying only if you put MP U you will be allowed to update your registration data, I think that is the wrong approach.
PIOTR STRZYZEWSKI: Can I? Addressing your first, I didn't assert this is a bug or future; I just described they are treated different way. I stated the fact. So I do not want to treat it as a bug or a feature or whatever else. I think that numbers are numbers, so in that way, we can try to make some kind of uniformity, as it was described in on the mailing list. However you can disagree with me.
PETER KOCH: Lets not play the wording game, whether you call it bug or feature. The point is they are different and I said this is intentionally so and I hear you saying let's make this difference go away.
PIOTR STRZYZEWSKI: No if I want to say ‑‑
BRIAN NISBET: I am just going to say, there is a couple of things I want to point out here. One, we have a limited amount of time today and that is ‑‑ but, one of other things; I take the point you are making,Peter, about legacy resources and the mail you sent today about whether we should be able to put a boilerplate on which then says this applies to legacy resources and whether they are different or not, and part of what I am saying while it is integral to this policy, I am also not sure that the Anti‑Abuse Working Group should be the test case or otherwise or try to address that issue. You referenced the point that is it now that any policy can have this boilerplate in there and, therefore, take away the ‑‑ the difference.
PETER KOCH: The whole point is it ought not to be a boilerplate thing. Can needsor a considerate decision and I am missing that.
BRIAN NISBET: One, you are missing that and we need to look at that and talk about it. The other point is there is a bigger point there which is, OK, is that an even bigger thing that the community ‑‑ is that something that we didn't envisage or otherwise a bigger thing, the community needs to look at in regards to what is considered sufficient justification or what is considered enough to actually try and bring the legacy resources in under a policy rather than ‑‑ it's a general question rather than the specific question of 2016‑01, which I don't think is up to the Anti‑Abuse Working Group to answer, is my point.
PETER KOCH: Thus it follows that you are sending back the policy ‑‑
BRIAN NISBET: Thus it falls that we need to think about it more. It's a point I read half an hour ago, I am not suggesting that I have a fully formed thought on it. What I am saying is I don't want to spend the rest of this Working Group session discussing something we need to think about more deeply. But it may be a point that we go, actually this has opened a bigger can of worms.
PETER KOCH: As long as we mark that as to be considered and open, I am fine with that.
BRIAN NISBET: That is what I am saying, yes, the points you raised in the mailing list are very good points we need to consider and I don't think we are going to up to a answer right now.
PIOTR STRZYZEWSKI: The second, I see this as opposite way to you, I don't think it's barrier and inability to have better data in the database because right now as Brian said abuse‑c is for the other data, for allocations and direct assignments, it's there, and no one raises the point or at least I don't know about anyone who raised the point that the making abuse‑c mandatory for those kind of resources leads to the lower data quality for allocations or direct assignments, I see this in the other way, I understand your concern, I can agree with it to some extent but I think in a different way. Is it OK?
PETER KOCH: Perfectly OK do you have different view, yes.
AUDIENCE SPEAKER: Marco Smith RIPE NCC, how big is the problem or how many legacy resources right now have abuse‑c and not. Currently in the RIPE database we have about 70,000 INET num objects with legacy and of this a bit less than 4,000 have, which is about 5%, have an abuse‑c contact so we talk about 95% without an abuse contact currently.
BRIAN NISBET: OK, thank you.
AUDIENCE SPEAKER: Christian RIPE NCC, this is actually not a question, it's more a clarification. You mentioned there RIPE Stat abuse contact finder and using some ‑‑ that is true, that was case but since more than a year we don't do that any more, right now we only return the abuse‑c contact and that is why you always get this.
PIOTR STRZYZEWSKI: A few days ago I see the web stage is still working so I assumed it's still heuristics.
AUDIENCE SPEAKER: It should not. If you are going to find me something like that lease send me.
PIOTR STRZYZEWSKI: I will send you a link.
AUDIENCE SPEAKER: With a resource, right.
BRIAN NISBET: OK. So, conscious of a number of things: Conscious of the fact that obviously the second version of the policy only just went out and we have four responses to it. Two supporting it, two opposing it, so nicely balanced at the moment. The ‑‑ I think we are in a discussion phase, there is more discussion to have on this. Very much encourage people to respond on the mailing list with meaningful input, this is all been discussed on Address Policy a lot, this is not a voting system, that is conversation and a discussion about the policy, so please respond with meaningful input. I think that I need to have a conversation with Marco about the broader piece around legacy resources and boiler plates and all of that, and I think that is going to be an input into it.
RUEDIGER VOLK: This is into the question for the policy, but related to processing this policy. Is there any commitment of this Working Group to produce documentation?
BRIAN NISBET: In general or in the specific?
RUEDIGER VOLK: Well kind of in the general I would hope too but we are on the specific issue, yes. And on a specific issue where the question who is taking care and doing this has been open for many years and kind of because of that background and of the consideration that well OK, if you force input into a database, of course you will get some part of garbage if you are not providing helpful documentation, kind of even the number of how many legacy objects are related, I think are not really the interesting question, but kind of, is there any commitment?
BRIAN NISBET: So, yessish. What I will do right now, and I will undertake and take the action point to talk to the NCC again about ‑‑ I mean, yes, there is a commitment in the charter to produce appropriate documentation for abuse related matters. If it is felt as it is felt that the documentation around abuse‑c is insufficient then we need to work on that and there will ‑‑ and I'll ‑‑ I am agreeing with you, Ruediger.
RUEDIGER VOLK: Again we know on abuse‑c the official statement has been there is no documentation, and the first policy was passed in full conscience of not having documentation.
BRIAN NISBET: So we have realised that's a problem and we'll ‑‑ you know ‑‑
RUEDIGER VOLK: How many years does it take to take it?
BRIAN NISBET: Hopefully fewer than would if we didn't. So as I said, I will talk to the NCC about that and about the policy in general and we need to continue the discussion on the mailing list about this anyway, we are mot going to ‑‑ I am not going to put a pause to that because I think that would be foolish.
Tim: I do want to comment on the documentation thing. Two things: I believe we do provide documentation and if we don't, please lets discussed off‑line how we can improve that. We have the documentation on our website regarding this. Also, we have done an effort to improve the user interface of web updates to make it easier for people to set abuse‑c, and also if people have comments on how that can be improved even more, I am all ears but we don't have to discuss it in detail right now.
BRIAN NISBET: We are not going to discuss it in detail. One of those things and suggest come up against. One group believes they have documentation, they may be correct; another believes there isn't sufficient documents they may also be correct. We need to figure out where the gap is there. Thank you very much.
(Applause)
So, almost running to time for a while. So one of the things that this Working Group undertakes to do is to provide updates on NCC activities, one of the most important of which is law enforcement agency interactions, so we have Dick leaning external relations NCC to talk about that.
RICHARD LEANING: From RIPE NCC external relations, I want to have a quick ten minutes to talk out about our outreach to the law enforcement government community.
You can read the slide, we do have a strategy how to deal with law enforcements ‑‑ we do have a strategy for it and we do have many around tables as you have heard Paul Rendek speak about yesterday and we do also go to law enforcement dedicated events and we bring law enforcement to our dedicated events as well. And in this room today, I am not sure because they don't like like cops as I did when I was a cop but we do have law enforcement here from FBI, from Europol, national cybercrime unit in the UK, they are now wanting to participate in the RIPE community and participate in these work groups and in these workshops.
Why? Because law enforcement do use the database, differently from what you guys will use it for but they do use it. And there is a lot of confusion about the database and this is what we are trying to do our outreach for, to make them understand what the database does but more importantly what it does not do. That is the big message that we are trying to get across to the governments and law enforcement, it's not what they think it's does it's trying to explain what it doesn't do, they often get confused about that. Because what they want and they only thing they want from it is to find the end user of an IP address, that is it. In our database, it tells a lot more in there but that's what law enforcement agencies want from the database, if they have got an IP address what service provider do I speak to who has responsibility for that IP address.
The other thing that ‑‑ just because it doesn't say what they think it says, they call it income rat and we are trying to say no, it's not inaccurate just because it doesn't say what you want it to say, that is not inaccurate.
Public safety Working Group, you have heard that mentioned a few times now. And it was mentioned during this week, because are the types of groups that we are dealing with. It's an advisory group to the GAC at ICANN and it's purposely called the public safety Working Group because it's not law enforcement only, it's any government agency that have a mandate to look after the safety of the public, so that is why it's call the public safety Working Group.
Initially set up to look at issues within ICANN but now looking at other agents ‑‑ other entities, organisations that have data, open source data that they can use to protect the consumer, protect the public. So that is why they are moving into this space.
At Marrakech at ICANN 55 we had a workshop similar to this, about 45 minutes, open to everybody to participate, and we discussed with an RIR is, how the PDP process works and what the concerns and issues and thankfully, they are now going to, the next presenter after me is going doing through a law enforcement case study to understand the difficulties that law enforcement are having in this space.
I will just nip through these but we do deal with Interpol, we work with Interpol, with some of the RIRs, APNIC, we have got a very good relationship, ARIN also got a very good relationship, with do coordinate amongst ourselves this type of engame, there is no point somebody from RIPE NCC going to Singapore where the Interpol headquarters are when we can have APNIC doing it for us, we do coordinate and make sure we are doing the right things in the right place with the right people. Stuff in the Middle East and Spain and we do try and train the trainers, it's very important and for us to ‑‑ we do try and train the law enforcement trainers so they can pass that knowledge without us having to repeat those type of courses. Do the same with Europol, and EC3, different organisation, different part of the world but the same type of coordination training and about the database, capacity building etc., and from us to gain from them what they see are issues.
I spent an awful lot of time with DG home and D N ECT, they are really driving the law enforcement agenda because they are responsible for Europol in this particular instance and they need to understand again but what the RIPE database here is. They hear about it. They hear police officers moaning about it but we need to hit them at high level, this is what it is and what it does and this is what it does not do. And if you are unhappy about what it does not do, then it's not the RIPE NCC's responsibility to change it, you need to be part of the community and you need to come and express those concerns in front of you lot and being involved in the policy process, so that is a message that ‑‑ it's hard for them to take but that is what they have to do, they do it in ICANN, they have to do it in this environment as well.
So the messages that we are trying to get out on be of the RIPE NCC and RIPE community is as I have put up there, it's explain how the RIR policy development process works, get them more involved, yes, they are here this week, how to report inaccuracies and I mean real inaccuracies, is there something maliciously being put in there to falsify a record, that if there is, let us know, then we will deal with it. Don't report to us just because it's not what they think it should say because that is not inaccurate.
It's quite self ex plenary the other two slides. This one I have put in, there is far more information on this particular slide in our website, it gives you the type of indication, the type of the number of direct requests that we do get from law enforcement and it isn't that many compared to how many are in 76 countries. So 2015 we had eight and it's up there. So, you can look at that two ways, say our outreach programme is working because law enforcement do understand what it does and doesn't do so we are getting our message across, it could also be not very many law enforcement agencies are at the moment using the database. They will, because all crime, no matter what it, has a presence on the Internet, it's not just down to high level cybercrime investigation, no more, it's all crime, so as more police officers get involved in knowing how, who to speak to, what to do, we ‑‑ we hopefully may have an increase in requests because hopefully we won't because we are doing that outreach programme.
So, the summary, what we are taking back to law enforcements and the governments is yes the RIPE NCC and the RIPE community take security seriously. We all do, and that is a message that we keep banging at them. We try hardest to validate and verify every single member and we are successful at that and we do understand that the challenges that law enforcement and governments have in keeping the Internet secure. But it's a two‑way process, they need to come and engage with us as well as we need to engage with them.
And lastly, we do a lot and but we know we can do more, so wave question session now but in the margins I would like to speak to everyone here about where can we do more in this space, is there something we could help in your regions? Is there suggest don't understand or want more detail on something, we don't need to have that type of conversation. So questions.
BRIAN NISBET: Thank you very much. Do we have any questions? Comments? Improvements? Things you prefer weren't happening, are happening, could be happening?
AUDIENCE SPEAKER: Just a comment ‑‑ Colin Anderson from measurement lab, I wanted to congratulate RIPE NCC on the transparency report that they publish. It is very thorough and it's impressive and I appreciate that sort of disclose our of numbers. So congratulations on a good job.
RICHARD LEANING: That was Athina, I think, wasn't it? Well done.
BRIAN NISBET: Yes and indeed Athina sends a mail out which went to the list about six weeks ago, maybe two months ago, anyway, with that and then there is more information on the website as mentioned.
AUDIENCE SPEAKER: Malcolm. A question on ‑‑ Malcolm Hutty, man off the street. Richard, a question on the public safety Working Group in ICANN, MoU if that scope is going to be not just ICANN related but going to be the rest of the community, that's going to be not obvious, shall we say, a lot of people are going to immediately think oh, that is an ICANN thing. Is that intended to be then something that will move out of ICANN, is its scope being a beyond a matter of convenience for now, intention to set up elsewhere, something else that could be done to make it the communication with other parts of the community more obvious and easier to handle and not have those sort of grit in the wheel?
RICHARD LEANING: Yes, that is very good question, Malcolm. I was one of the founder members of the public safety Working Group so that is probably why I am getting asked that question, it was always viewed that once we get ‑‑ once the public safety group had the core membership then maybe, because that is the challenge was getting everyone together, once you got everyone maybe it could move around the different Internet governance arenas, to do that you had to change its name for each one because if it's public safety Working Group from ICANN for the GACs, well why are they here, they should be here as the RIPE NCC, RIPE community security advisory or whatever they want to call it so they have to change the name, I know that is a discussion that is happening internally and I will feed that back to Alice who is the Chair of the PS WG.
MALCOLM HUTTY: Are you looking at potentially being not an ICANN public safety Working Group but your independent stakeholder group?
RICHARD LEANING: That was the view when it was set up, I haven't been there for the last 12 months, but it needs to change, but I know Nick ‑‑
AUDIENCE SPEAKER: Nick. I am on the GAC ICANN as, you know, so the public safety Working Group is a subgroup of the government advisory committee at ICANN, it has no jurisdiction outside of that, but sort of the point Dick is alluding to is in setting this up it's been a convenient way of getting some of those law enforcement public safety members together, where they can ‑‑ and they have also been discussing issues outside, it will have no mandate through the GAC doing and start sort of doing stuff to any outside organisations, but it's just been an opportunity for those people to get together. Does that make sense?
MALCOLM HUTTY: We have just seen an interesting interaction between the operational side that have certain expectations and the government side that have others, and I look forward that being resolved.
RICHARD LEANING: You are right but they did write official letter to the NRO which cascaded down to the NIR, they validated their existence, which is the correct procedure doing through.
AUDIENCE SPEAKER: I have short question about law enforcement requests. Could you please explain.....
Brian Nesbitt: Sorry, can you say who you are?
AUDIENCE SPEAKER: Ah, my name is Maxim Tuliav Natiet.
The question is could you please explain momentarily about law enforcement requests by country, which country do you ask ‑‑ ask you?
RICHARD LEANING: We do have that but I ‑‑ we haven't put ‑‑ I don't think it's in the ‑‑ it is by country in the thing, I don't know that off by ‑‑ Athina, you know, have you got that there.
BRIAN NISBET: The information is published, there was a link in the e‑mail you sent, Athina. It is there and you can read the link.
RICHARD LEANING: I didn't want doing through 35 slides.
GEOFF HUSTON: I don't want this answered but it's kind of a question I would like to hear over the coming years: You have represented what a particular community and constituency want from our data, and their motivations for looking there. This is what they need and this is why they are looking here, right?
RICHARD LEANING: Yes
GEOFF HUSTON: How well, are redoing, are we meeting our expectations, are they finding the data, easily, tractable, up to date, does it meet their needs and if not, how can we make it better for all of us? You know, so I don't expect an answer. It's a hard question, but part of this is.... we are putting a lot of effort in putting the data out there and you are saying here is a bunch of people who look at it, are we meeting or passing in the night and I would be keen to understand that.
RICHARD LEANING: That is a good question and I mean the law enforcement are one part of the community so what other parts of the community are getting out of the database that they want to get out of it.
GEOFF HUSTON: Can they tell what is accurate and timely and a little bit old is the kind of question.
BRIAN NISBET: I think one of the presentations we are having a little later in the session will address some of that as well. Thank you very much.
(Applause)
We know who it is, so this first presentation is from Gregory Mounier from EC3 and talking about IP resource announcement and the law enforcement perspective on that. Please.
GREGORY MOUNIER: Good morning, everyone. Thank you very much, Brian, the Anti‑Abuse Working Group, the RIPE community for allowing me a representative of the law enforcement community to come and speak to you today. What I want to say is that first law enforcement community is very important to engage with you because as you probably know, when you are investigating abuse and illegal activities on line, in 90% of the cases an investigation starts with an IP address, and we are not very techie and we sometimes pretty stupid and we need your deep knowledge of how the Internet infrastructure works, we need your understanding of how the technical layer behind the Internet works, so that we can do our job.
I also want to thank Dick of course and RIPE NCC for organising that session and allowing us to come here.
What I want to do today is really to start engaging with you by presenting you one of the common challenges that the investigators have when they want to use the IP resources and in particular the RIPE IP Whois database. So, this is a real case, I have changed the countries and the names and I have simplified a little bit the scenario but it's really something that investigators are encountering fairly often.
This is a scenario which is linked to IP resource announcement and in particular the difficulty for investigators to identify the country where a suspicious IP is physically located. So, that case is related to ransom ware which is being defused around Europe, I mean you know about the current trend and the number of ransom ware that are being spread around currently, I mean it's a very simple modest and a lot of crime groups are using that to make a lot of money and we haven't found yet really the silver bullet to address this issue so it's really a common case.
In my scenario the investigator is French, called Jean and is investigating that is organised crime group that is running the BotNet responsible for spreading the ransom ware. And through his investigation he has identified the serve within the criminal ‑‑ criminal infrastructure which is holding the decryption keys for a number of victims. That is very important of course, we had the case in 2014 with the Dutch police and they actually found the decryption keys and set up website so victims could take it and decrypt their information but he also has evidence from a different source that the information is going to be moved very soon, so you need to seize that server very, very soon.
What does he do, first thing he will check the RIPE Whois database because he has got the IP address. This is very important for you to understand that the RIPE and any IP Whois database is the first port of call for an investigator, they will use it in 90% of the cases, regardless of the accuracy or the currency of the tat, they will use it all the time, that is the first port of call. In that case, they find out that the IP and the ASN belongs to an operator based in Romania. In order to be a bit more sure they do an additional check and use the stat.ripe.net and indeed it is confirmed that the ASN belongs to that operator called guard owe micro AS based in Romania so lets continue the investigations. To be a little bit more sure he does a trace route and first problem, the trace route stops a few hops before the end and if you check the IP ‑‑ the IP address you see that it stops in the Netherlands. So, this is not super useful so he has three indications that it might be in Romania, one indication he doesn't know, is that server really located in Romania, that is his way of thinking, you have to put yourself in his shoes, he might be a young investigator in the cyber division of the police, he is potentially working on a very important case, if he seize the serve not save the life but help many victims to decrypt their information. He has then doing to magistrates, either prosecutor or investigative judges with this evidence, mostly based on the IP Whois database and convince him to launch a assistance request which is very heavy legal assistance procedure, so for him it's a big deal.
The first thing he will do use the phone number that he found in the IP Whois database, to informally contact the Romanian provider, just to see if evidence are leading to something. Not always but very often there is no response. In that case there was no response, nobody picked the phone. What does he do? He has doing back to the magistrates, present his evidence and OK, they decide to launch an imflat, that is a very heavy and long procedure, it's a discussion between the two ministers of justice, you have to fill in paper ‑‑ some paperwork and it takes between one and four months before you actually get any result. And of course, you know that when you do cyber investigations, the volatility of the cyber evidence is such that if you don't act within a few hours sometimes then your investigation is finished, so of course we have ‑‑ that is a different issue and we are not going to solve it here, MLAT is an old‑fashioned instrument, that is the only one we have, we need to that is the only legal means we have to seize evidence in different countries.
So the Romanian investigator gets the M lath and they go to the indicated company. Again you have two different scenarios that the investigators very often encounter, either the Romanian company will be cooperative and give the information they have, which is the first scenario, and in that case, they said yes, the AS number belongs to us, however we bought a block of /24 IP to German operator and it happened that that server is not ours and it's still in Germany. OK. So, Jean goes back to the minister of justice, he asks his prosecutor or investigator ‑‑ judge to do a second MLAT, one moment wasted, going to Germany, the German, go to the operator, seize the server, unfortunately it's too late, it's been two months, the information has been moved to another server, he has wasted two months to investigate something it goes basically, so that is finished. If you go back to the second possibility when the Romanian investigator goes to see the Romanian operator, either the company is cooperative and say the AS number is ours, the server is not ours, done finished, at this moment I would be interested to see from you what you would be doing. The other possibility of course is that the Romanian operator is victim of ID theft, somebody using fake ID and you don't know where the serve. Again what would do you and do you have a silver bullet, a magic trick to help us finding out where the server might be in that situation because it happens very often.
In that case, Jean again he is, a cop, so he likes looking at things, goes back into the RIPE Whois database, clicks on every entry, doesn't know what that means, maybe he had a RIPE NCC training on the RIPE database but mostly ‑‑ probably didn't have it so he just goes through and by chance he clicks on "maintainer" and he finds out that the maintainer has a German address and phone number, maybe for you it's obvious, for us it doesn't really mean anything. He goes back to the stat.ripe.net and yes, there is in fact a reference to Germany just underneath here, but again, would you go and see a prosecutor and say, the RIPE database tells me that the owner of the ASN and the IP address is based in Romanian but the maintainer is in Germany, I think we should issue an MLAT to Germany, the magistrates will never issue on that type of evidence. And again in both cases, too late because it's been two months and the information is moved to a different server. Concluding slide: Please help, maybe you have got an answer, maybe there is a technical tricks, maybe we don't understand how the Whois database is structured, maybe we don't have the knowledge about the type of information that is in it, maybe it's obvious for you, you would have solved that case easily but the question I have for you and I hope you can help us: How can we ensure that IP addresses are announced in the country where they are registered? If we could solve that issue we would save a lot of time for investigators, again this is into the critical issue, there are more important stuff but it would help a lot of investigators in Europe and around the world doing faster in investigations and take out individuals that are abusing the system. Thank you very much for your attention and looking forward for your questions.
BRIAN NISBET: Thank you. It might be useful if you leave the last slide up there. So, comments? Answers? Tears.
AUDIENCE SPEAKER: I am Will from IP max. I will not ensure you that the IP address I am announcing is actually being announced in the country where it has been registered, because I am Swiss and my network goes around Europe. So, yeah, I am sorry, I will not be able to help you there. Usually what I do is, we try to localise our IPs to get the information out and so I like try to mention the information in the RIPE database there so there is where we can do something but I don't think it's the case for everyone and also we know that the like ‑‑ like, for instance, like the regional location database, we don't necessarily easily update their resources and their ‑‑ yeah, so it's kind of difficult question and yeah. Exactly.
MARCO HOGEWONING: Just a quick response to Will and that is one of the things we have been discussing with Gregory, is this is a lot of confusion in the terms ‑‑ terminology used by law enforcements so when this slide says announced, I don't think it's meant to be it's BGP routing announcement but more would reflect where an IP address, the device using the IP address is actually located, am I right?
GREGORY MOUNIER: Not necessary, in fact we don't know want to know where the device is, if we could would be perfect, we need to know who is holding the resources or a country we can turn to serve a warrant for instance, that is only what we need to know. The current tree would be really great.
AUDIENCE SPEAKER: RIPE NCC. Thanks for the presentation I think it's very good start for discussing this kind of stuff. But to be honest I think on a higher level this was very specific case, the law ‑‑ from any insider should be a kind of mentality changes as well, because I am standing here, I am Iranian, I live in Netherlands and my name is listed for addresses in the US, RIPE NCC infrastructure, in US and many other countries, Australia. So yes, that is reality of Internet, it's noble, countries borders doesn't have any real meaning and adding that terminology problem and all of that yes, so I think there is a little bit more work and we have to try and clarify everything but having this jurisdictions doesn't work. Well, we are not really talking about jurisdictions, it's really giving an indication to those that are trying to solve a case of where they have to turn to. And in your case maybe it will turn to you and you have a precise idea of what your IP addresses are and you can help and it's perfect and it's not the majority I think.
AUDIENCE SPEAKER: I understand. In case that I wanted to hide it so I didn't want to help it would be super easy to do that if you think of jurisdictions of country, which country we have to turn to, it would be really easy to play that game.
RUEDIGER VOLK: Deutsche Telekom. Actually, Kaveh, for the globally distributed use of your addresses, I think the current registry data structures do not provide convenient ways to actually tell which of your things are in Napal and which are in Meanmar, so I would say what you are looking for really is not taken care of the in the design of a database. However, that ‑‑ and I am not completely sure whether an attempt at fixing that would be successful and whether that would ‑‑ whether that would take a year, a decade or a century. At least at decade level you have to also of course live with the fact that well OK this is not just network; we are living in the world of virtualisation, so, the guy who is renting out his addresses, from his headquarters in Romania, using some service provider, administrative service provider, registered in Germany, well OK, may actually provide tunnels to someone in Estonia and, kind of, that is going to be on a 'per host' address basis, if not even on a port basis and well OK, kind of for the evil guys, the path does not necessarily go via Thor, to hide from you, it even goes on the regular Internet.
GREGORY MOUNIER: Absolutely and I like what you said about Thor. I mean, we all know about Thor, but in fact, you don't need Thor to hide from the police. You just use your mobile phone to connect with the internet and use *netting can find what you are, anyway.
AUDIENCE SPEAKER: Milton Muller, from Georgia Tech, in the US. We have had interesting debates about trying to jurisdictionalise the address space in the ARIN region as well and I think we had this debate in connection with a proposal to allow addresses assigned in the North American region to be used by global network operators and indeed, this is something that makes a lot of sense for the efficiency of the Internet. I think in that controversy I got the impression that law enforcement really is in some sense mentally trying to recreate the telephone ‑‑ the PTT monopolies of the 1970s and superimpose this concept on the Internet and I think what we discovered is it's actually not necessary, you are looking ‑‑ you are identifying the wrong target, you don't need to reconfigure the IP addressing structure; you need to figure out how to cooperate with law enforcement people in other jurisdictions, it's not hard to find out where an address ‑‑ who is running the address, that is not the hard part. The part is, you know, getting a person in that other jurisdiction under their law to cooperate with you, isn't that the problem?
GREGORY MOUNIER: Well yeah, I get what you say, but at the end of the day, we could wish for an ideal world where we would have no jurisdiction problems and where I as a French police officer could go to the UK, whatever, it's not the case, in your world, in your Internet world you might in advance ‑‑ we are operating within a very tight legal framework and we can't just ask the Romanian ‑‑ I have got a friend in Romania and he could go and seize the serve and the whole procedure would fall apart as soon as it hits judge, there is a mismatch and discrepancy and between the Internet and how it works and there is no jurisdictions and it's trance national, I think it's good we have a dialogue with you as well to find a ways of making the old system our system, work with your new modern system and ‑‑ in my case the information is in the database just not simple and we can't find it or we find it too late you see what I mean. Tend I see some ways personally of bringing the two systems together to work it more efficiently.
AUDIENCE SPEAKER: Joe speaking for myself. I wanted to build on what Ruediger was saying, which is I believe you are not going to get a single one stop solution for what you seek in the RIPE database or any registry database. I think what you lay out in this example is a good first order proximatemation that I and every operator would do in this room when you are hunting problems but you have doing digging in several other sources, and maybe either building some of the skills internally or partnering with directly with folks within your jurisdiction that have the skills that are willing to dig into peering information, find out that can't be right because that round trip time is wrong and there is no fibre that goes to that country that crosses that border, these are the levels of detail that you have to get into when you are trying to chase the physical location of resources these days.
GREGORY MOUNIER: I completely agree with you and I think there is a lot of training to be done for law enforcement and we are hiring, so if you wanted to join.... ‑ which is that is the type of issue for some, for you it sounds so easy, we are first grade and you are 12, PhD, we need to include your knowledge in our force. Thank you, anyway.
BRIAN NISBET: Thank you very much.
(Applause)
So in Madrid we are going to have a deputisation part of the Working Group session, get your badge your star, the whole thing. One point before I forget, and again Geoff this may actually some of your questions around the database and usage thereof, there is going to abdiscussion in the Database Working Group led by Hans Petter in regards to some of these kind of areas as well and use of the database and he is not disagreeing with me so I am going to take that as ‑‑ you know. So, we now have a very quick run through the what Lu Heng was talking about at the plenary session on Monday, in regards to invisible IP hijacking. Please.
LU HENG: Hi. It's a follow‑up of my lightning talk in the plenary. So, I will keep the story really short. We managed infrastructure across global and software solutions and that is about us. And a quick run through what happened in case someone didn't listen to the lightning talk it's basically there is, there is someone become customer of DE‑CIX and they did a direct peering with Yahoo and announce hijack range in more specific announcement than our legitimate announcement through direct peering to Yahoo and send spam to Yahoo, that is basically what happened.
And then after my lightning talk quite a few folks come to me and basically raised quite a few interesting points and that is what I am about to share at this presentation. First, the Whois database, which is quite heavy topic in my presentation right after that. There is AS number both of them all hijacked and Hughes used by hijackers in DE‑CIX for years and I have done a cheque about all the AS number, the ‑‑ across here is the results:
You see the first AS number, it's belong to AfriNIC so AfriNIC is legitimate holder of that, it's doing the AfriNIC free poll so who is the Whois information which showed it's managed by AfriNIC. And here is interesting information in RIPE database, it's still there, anybody can still check it. It's interestingly, it even has a route object with telling import from which AS to which AS about this AS number which still sitting in the free pool of AfriNIC. And but if you check the rest, LACNIC, APNIC ARIN, all of them telling the correct information, which saying that this address block belong to AfriNIC and no other entry existed.
Same thing goes with the other AS number, if you check the AS 17445 in RIPE database it's claimed to belong to an organisation which called AF R O X, and it's creating 2015. However, if you check this AS number across the other four IRS belong to APNIC and does not exist, still in APNIC free pool. So I have a question for the rhyme folks here, like what is going on? I mean it seems that actually the whole database having problem with. So, that is the first question which ‑‑ was arised after my lightning talk and here is the second one: The user awareness. I didn't really address this point when I first did my lightning talk because some folks comes to us, don't you guys receive user complaint that they can't visit Yahoo? Yes we did, but at the same time we receive millions of other reports about some other website which is not reachable by our users, so unreachable single websites common problem ‑‑ and we normally we solve it by changing IP address because probably the IP was being blocked by some sort of firewall and some sort of network connectivity difficulties and so it's handled by the customer support side, not going to reach to the network team, so this part wasn't really important in terms of this particular case because we pay much more attention to the network abuse report rather than user report. Due to the volume, mostly.
And the routing viewers, Yahoo does not actually share what is their view in the global routing table and so when you share service like routing history, the hijacked announcement wasn't there, it was never there, and Yahoo don't share it. That is a point being raised by quite a few folks as well.
I would like to thank you Yahoo and DE‑CIX in solving the problem. They provide very detailed reports for Yahoo to DE‑CIX and the DE‑CIX promote response and actively different parties was really helpful. Totally over 100 e‑mail exchanges in order to figure out what is actually happening and solved it. This is most important slide and if there is any law informants agent people here I would like to ask the question as well, because this company who hijacked our addresses, they even response to DE‑CIX e‑mail communication, paying DE‑CIX invoice, even after our reports to DE‑CIX for almost a month's time they still in communication with DE‑CIX and their AS number that undelegated AS number has been peering with Yahoo for years so those people are doing this like legitimate real business and we totally believe they made millions of dollars out of it and probably nobody ever found out and reported them ever. So I would raise awareness to that and if there is any legal solution to the problem happy with colleague share their opinion about it. So that is it. Questions and discussions.
BRIAN NISBET: We have some brief time for such things.
Cava: I agree there is a problem, just to clarification about RIPE database and AS numbers. There is a hierarchy so when IANA delegates basically block of ASNs to us and APNIC, AfriNIC, others, so if delegation from IANA has been given to RIPE NCC to register that ASN in RIPE database you need ‑‑ it can only come from our registration services so that is a valid record if we stand by this and that goes to all of our registry files. But if it's outside of RIPE region as you mentioned like an ASN which has been delegated by IANA to APNIC or to AfriNIC anyone can register in RIPE database and put anything they want in it, all export lines, everything. The reason for that, this is historical ‑‑
BRIAN NISBET: This has been discussed in other locations.
AUDIENCE SPEAKER: The reason for that is if you want to create a route object you need in RIPE database IRR, you need authorisation from ASN and the INETNUM. People create ‑‑ people had access to create this arbitrary ought nums. There is discussion in the RIPE database, it has been many times but now there is a proposal so hopefully it will be resolved but just stating the facts.
BRIAN NISBET: I would like to keep that discussion in database where it should be. Thank you very much Kaveh, great, the point is made, database is after lunch. I recommend people go and look at the discussion and the mailing list. As long as you are not going doing into the details about that, Ruediger.
RUEDIGER VOLK: No. I just ‑‑ OK. What I would kind of take out of this as remarks is when talking about route hijacks, it is easily forgotten that the really evil route hijacks are those that are closely scoped, so to avoid being detected, and that is what happened to you. It also seems to me that some network operator that was involved here actually did not do due authentication of what he was receiving and yes, with the state of the databases, that may be unform more difficult than we would like it to be on ‑‑ on the other hand, I think, I think it looks like negligence and more effort and more effort and attention should be used on that and kind of the very easy remark there is, many people think the checklist item, when you open the BGP session, you establish authentication by MD 5 keys, well OK, the actual authentication is something that is outside of a BGP section ‑‑ session in that case, and I ‑‑ I am damn sure that a lot of network players are not taking that authentication serious. And there are actually not good tools for it.
BRIAN NISBET: OK. Anything else? No. OK, thank you very much.
(Applause)
So our last presentation, the last that is kind of agendaed piece of content is Chris to have Dietzel.
CHRIS DIETZEL: Thanks. I am with DE‑CIX and ‑‑ I am going to present some measurement ‑‑ results of measurement study we conducted. I guess for this talk, I don't ‑‑ or at least in this crowd I don't have to motivate that DDoS remains a serious threat and we need to do something about it. So, for time matter, we just gloss over this. And go to the directly to recap what blackholing is. I know that we already introduced this concept for IXPs so I just do this really quickly. It's an operational technique to counter DDoS attacks. You may trigger blackholing as owner of the IP space and directly through BGP. This concept actually comes from upstream providers and it's been around since years already, and since a few years IXPs start to adopt it. So quickly, how does blackholing at IXPs actually work:
So, if there is an attack which may congest the peering port of AS D in this case, some servers in the data centre or gear within the network, then we can or the ASD can announce blackholing for a specific IP address. This IP address is transferred or is through BGP announced to all other ASs connected to the IXP and also possible to just announce it towards the subset of the ASs.
So as soon as they are announced and accepted by the peers, we see that the traffic is stopped at the IXP on behalf of ASD. Since we know how this technique works and that it's actually used by some ASs, we ask several questions: Is it actually frequently used and how is it used? I mean just because it's there it does not necessarily mean that somebody already uses it and makes use of it, and what is the impact on traffic if somebody does blackholing, and the last question for especially for DE‑CIX would be how can we improve this service in order to make it more sufficient for our customers?
So, therefore, we conduct a measurement study and collected about 23,000 blackholing announcements over a period of three months, and here I plotted the announcements that were active per day as an average value. So we see over time the blue line are /32 announcements and we see that it's really used by let's say 1100, 1200 announcements over time at any given time, basically. And we also see that less specifics are there, namely between /31 and /18, and we see around 50 stable announcements over time so at any given point in time there are 50 announcements for blackholing at our vantage point. So we see in this plot we don't really see what comes and goes so this is just like over the time, and if you also add like new announcements per day, because an IP can be announced and reannounced and so on and we see this is rather spiky pattern. And we see that some days there is more activity at other days less activity, and we also see a very high spike in there and we would expect that this spike impacts the number of stable announcements over time but new announcements could be also the same prefix which comes and goes on a minute basis, so this does not necessarily influence the average announcements of a day.
So, now we know that blackholing indeed is used by a lot of or that a lot of prefixes are basically announced and with this not we want to dig into which prefix length are actually used and we see that mainly /32 announcements are present so, a host address are announced nor blackholing in 97% of the cases and note that this plot is log scaled. Then we see sort of mid‑range /24, /31 which account for only 2.5% and we see nine announcements less specific than /24. Majority /32 but also very, very ‑‑ a lot of IP addresses with very less specifics, basically.
So, to see how long are those active because just an announcement does not necessarily mean anything, it could be there for five minutes or for five days, so, this plot shows us each data point represents announcement and shows how long it was present per prefix size. So, we only focus for now on the /32 prefixes and we see that basically, the active duration is rather short so the majority of the blackholing announcements are short‑lived and 50% live less than three hours actually but we also see a very long tail so we see that the longest announcement was present for 76 days actually, so which is super long and we may ‑‑ we are not sure if this is really connected to DDoS attack or some sort of misconfiguration testing whatsoever. And if we look at the less specifics, then we also see again that they are the majority is short‑lived, but also we see the same pattern, that there are some that are active for very, very long durations. And given the fact that there are a lot of short‑lived ones, the question is, if I see like several times a short‑lived one could also be the same so the next question could it be the same prefix. And therefore, we just looked at unique prefixes, so we saw 7864 unique prefixes within our three‑month period, and then we have on this plot the anonymised AS numbers down there and we saw how often actually the same prefix was announced. And ‑‑ or prefixes were anouned by this AS. And what we see is actually, the majority does not announce the same prefix very often but still up to let's say ten times, a little bit less than ten times, 10% were announced just once or between 2 and 3 times, 15%. But where we also know that the outliers really spread from 10 to 100 and the max we observed is 623, so basically, the same prefix announced 623 times really gives us some notion on what is going on. Blackholing remains some sort of limited for now, as soon as it activated ASs, operators don't really have means to see what traffic volume actually is still hitting their network so they need to switch it off, withdraw their announcement and see, OK, what about the traffic, is it still harmful, still very high volume, and if so, they need to reannounce it. So we see that on/off pattern and this is why we have very, very high numbers for some prefixes.
So, then we just looked at, we have several case studies and one of it is plotted here, so what we see basically, the green line is the traffic that goes towards an AS like the total traffic, and we see that it ‑‑ from roughly 6 gigabits, peaks to 17 .6 gigabits, and what we observed is that the dashed vertical line is the blackholing announcements so we see the traffic is spiking and an operator does take actions and traffic is black hold. What we also see is the blue line, which is the traffic to that specific /3(holed) which was attacked in this case or potentially attacked and we see it's going up and the total traffic is going down and also the traffic to this /32 is going down very, very fast after the announcement of the blackholing. So we see in fact it can be an effective method to counter DDoS attacks but we also observed that there is still, and this is sort of surprising thing here, at first glance at least, we see that still the yellow dashed line, that is still traffic goes to this /32, so it's not entirely effective; I mean, it reduces the traffic and we see it really going down by one‑third at least, but we also see that still traffic going through and this is really where you need to take actions and you want to assure as an operator of an IXP that you accept more specifics, for instance, /32s, if it's announcement for blackholing, at DE‑CIX if it's the next IP address you really want to make sure that you accept these announcements because why still traffic or one of the reasons why still traffic is going to this /32 is because the announcement was not accepted. So, let me summarise:
We found that 23,000 announced blackholing ‑‑ 23,000 announcements of blackholing over three month measurement period so indeed it is used by a lot of ASs at our vantage point and we see there is in fact a high number of stable announcements so blackholing is used all over the time by someone, and we observed the least specific was a /18, which is quite huge. Also, very diverse announcements, patterns, some announcing blackholing very frequently, some very long, so we see everything and some of the reasons I pointed out, and we also see that it is in fact valuable tool to as last resort to counter DDoS attacks. And if you are curious to learn more about this topic or want to read about all the details, the full paper is available at this link or you can just Google blackholing at IXPs and you may find the paper. Thank you.
(Applause)
BRIAN NISBET: Thank you very much. I am an Ops guy, I hate blackholing, the terrorists have won day and it point in time, absolutely, it's very important and thank you for that. Any short questions or comments at this point in time? All the presentations are on‑line and because the NCC are so fantastic, this video is probably already on line.
RUEDIGER VOLK: I did not do a pledge that I would ‑‑
CHRIS DIETZEL: What is your affiliation?
RUEDIGER VOLK: Deutsche Telekom, still. Didn't change over the past quarter of an hour. I would like to ask for an aspect of the blackholing that seems to get very little exposure. For the blackholing that you observed and measured, is there a known, common, well‑defined, authorisation policy?
CHRIS DIETZEL: Yes, indeed, you may only ‑‑
RUEDIGER VOLK: OK. From the data, from ‑‑ from the measurement, I wonder whether you would see and whether you may ‑‑ maybe even saw, a possibility of identifying blackholing announcements that are actually not taking up an ongoing Dos attack but might be, say, a closely scoped denial of service attack of itself.
CHRIS DIETZEL: I mean, this is an operator could go and withdraw any prefix they would like and there would be basically the same effect. So I mean, it's my prefix and it's checked whether I am really legitimate announcer for this prefix, and so, this is mine and if I feel like DDoSSing myself I may do that. I can also switch off my server right.
WOLFGANG TREMMEL: We use for the DDoS authentication the same mechanism for the route server authentication, look up route objects and if the route objects source IS match to what is registered and actually we could see if we look into the announcements which are blocked by the route server if someone tries to announce a legitimate /32, these things actually do happen on purpose like transit provider wants to block for one of his customers a /32 and we said no, we do not allow this through, your customers needs to announce the /32 himself with his AS number.
CHRIS DIETZEL: Yes and this is the reason why we didn't study this for this measurement because we just looked for instance at the looking glass and could just observe the announcements that got through the described process.
BRIAN NISBET: Cool. Thank you very much.
CHRIS DIETZEL: Thank you.
(Applause)
BRIAN NISBET: So, one very quick thing: I want to say; Unfortunately, I am being very mean to the NC, in not giving them any opportunity to talk. The documentation, Ruediger, this may be of interest to you, the documentation regarding abuse‑c, Tim is going to send that to the mailing list and if there is other types of documentation people would like in regards to abuse‑c then we have have a discussion there and figure out what is missing, etc., etc.. no other AOB? No. OK. A reminder, we will be having another meeting, it will be in Madrid in October. The ‑‑ I am happy to accept agenda items from now for that meeting, in fact I have a few things noted down. Thank you very much to all of our speakers who kept wonderfully to time, thank you to our scribes, Jabber, stenographers, the tech crew and most importantly, to all of you because it would be a little lonely if I was standing up here talking to myself. Thank you very much and hopefully I shall see you all in Madrid.
(Applause)
