These are unedited transcripts and may contain errors.
Anti Abuse Working Group, 5 May, 2011, at 2 p.m.:
CHAIR: Hello and good afternoon. Welcome to the RIPE 62 Anti Abuse Working Group session. We have lots of interesting, exciting things for you this afternoon. So, no going asleep or otherwise, I am sure the food was lovely, but stay awake and alert.
I am Brian Nisbet, co chair of the Working Group, and I'd like to welcome you all and just to go through a couple of bits of administration.
So, first off, I'd like to thank the folk from the NCC who'll be providing the scribing and Jabber and everything, there appears to be five of them over there, clearly we rate a lot of attention, and indeed the wonderful stenographer. Again, I cannot say how much I love this service and hope that it will continue forever.
STENOGRAPHER: Me, too.
CHAIR: If up do wish to ask a question you see the problem here is, I can't see what she has just written.
STENOGRAPHER: Recession and all...
CHAIR: If you wish to ask a question or make a point at the microphone, then if you could please state your name and chosen affiliation, whatever that may be before you ask your question.
So, first off, just to formally approve the minutes from RIPE 61, there were some comments, I think we made some changes but there has been nothing since the last draft. So unless there is any comments in the room? No, excellent, so approved. And the second part is those of you you were in Rome or read the mailing list afterwards know that the Working Group decided, at RIPE 61, to ask Richard Cox to no longer be a co chair of the Working Group, and I said at that point in time that it was my fervent hope that we would have a new Working Group chair and co chair in place by RIPE 62. We discussed this on the mailing list, but as we have said previously, co chairs of this Working Group are formally agreed and approved on by the meeting. It's the one decision that's very definitely taken here rather than on the mailing list so. I would like to commend to you the Working Group co chair proposed that I mention in the mailing list and who got a very good reception, Tobias Knecht, who is standing here, unless there are any objections, if I could hear some manner or class of the Working Group to approve him as co chair.
(Applause)
CHAIR: Thank you very much. One of the changes that, Tobias will be doing, which I am grateful for, is resurrecting or reinvigorating the somewhat dormant BCP document process. This is something I sadly did not find time to do, but now that we have a renewed co chair we can do so, so he should be mailing the mailing list soon, looking for renewal of people who volunteered previously or otherwise with an aim to producing the two documents, I think the administrative and the technical document that we had discussed.
So, the agenda. I don't think there is any additions. I certainly haven't got any, so unless anybody has anything they wish to add at this point in time, we shall press on. Excellent.
Right. So, updates:
There was a lot of this discussion over the last few months. Forward and backwards on a lot of things, some of which are being addressed by the abuse contact taskforce, some of which are being addressed by the RIPE 517 closure and deregistration document in regards to what RIPE and the RIPE NCC can do in relation to people who are being naughty. I don't propose to go into that now, unless there are points based on the recent lis discussion that anyone in the room would like to raise or discuss. So, we shall go on to the first of our two main presentations this afternoon, which is Ingvar Mattsson from Google on admin tools for blackhole administration.
INGVAR MATTSSON: I am Ingvar Mattsson, I work for Google, this presentation has nothing to do with with Google at all, just to make that abundantly clear.
So, I am going to be talking about a [blackhole] administration tool that arrived a couple of years ago. A bit of motivation behind it. I think that's fairly obvious to anyone, but just to talk about how blackhole normally works. It's a fairly tedious process. You log into a router, you type IP route and hope you type it correctly. You can't really comment on what you do in the router config, and you don't know when you did something and when it needs to go away and you don't remember why you did it. This means you have to keep the administration elsewhere, and that's a bit of a burden.
However, blackholing is very useful. Using blackholing for Anti Abuse means that you are moving an awful lot of work to your routing fabric, it means instead of doing it on the hosts. That's relatively cheap, the forwarding plane is very good to do the routing issues. And fire walling on hosts is relatively expensive and there is little to no overhead in the modern world.
So, what do you need from a routing blackhole administration tool? Well, we want to know why we blackholed something, when we blackholed something, who said we needed to blackhole it? And when we want to remove it. Ideally, we want a web interface, and since most of us are fairly useful and can type in key boards, we also want a command line interface. So the I should probably say that this is more a proof of concept than something that that is production ready. It is based on things similar to tools that originated in the past that ran in production for six years, so it is not an entirely new.
So, this is what I did. It's a proof of concept implementation. It uses an SQL database back end to store all the data. And it also has a process to remove Blackholes from the router as needed. My suggestion for, if you want to use this, is that you have one machine that runs the front end. You have a one machine with the database that may well be the web front end, and I apparently cannot spell a router that you designate as the router that actually injects the blackhole into the BGP. That means that you can have a router that does not participate in your normal router management password policies, because obviously the blackhole tool needs to have an enabled password on the router and you may not want that to have the potential of leaking.
It it also supports something that I call tagging, because that's what the router configs call it. And that allows you to specify different kinds of blackholing, be that because you won't have an administrative difference or you can actually do different things. So, the proof of concept code included Cisco configuration, can do one of three things. It can send the blackhole traffic to a central machine for whatever reason. It can send the traffic into a local non interface on each router. And it can also propagate the blackhole prefix upstream. So, your peers, if you have that agreement with with them, can blackhole the traffic for you.
That also allows you to use RPF, or relaxed RPF to block the traffic as it comes in on your boarder. Or, indeed, anything that allows you to stake a tag or a BGP community or whatever on your BGP route and then you can do what you want in the route maps.
The tool is written to be modular. A [TAS], a back end concept, where a back end is a python module with two functions: One to add a command, add a route, and one function to remove a route. And, there are three back ends included. One that does nothing, very useful for debugging. One that logs into an IS router, and one that injects routes in the routing table on the Linux box where the web server runs or the CLI client. And this is a quick walk through of the interfaces, so you can see not entirely how they run in production, because they don't. But starting with the web interface, it is a single page. It looks like this...
It is not very exciting. But as you can see, there is an operator, it's just selected out of the database. There is a space for a password so you know that it was actually the person you thought he was. There is a text field for a reason. There is space for IPv4 prefix. There is nothing actually in the proof of concept code that requires it to be IPv4. You would need to write something that comparison in IPv6 address and turns it into a big number, so you can do the write masking on it, but the database itself, that is a text field, and I think the SUL as it comes it actually large enough for a fully qualified /128.
There are some stats. When it was blackholed. When it should have been removed. I didn't run the beeper, so yeah, it's still there. The reason it was blackholed. The tag and who did it. Similar for the next one. As you can see, there is a link there, that's me violently violating the BGP protocol, but is a get link that removes the blackhole route because that's quick and easy.
There is a command line interface. It can do three things. It can add, delete and list blackholes.
I thought I had an example of that. Well, it doesn't really matter. You specify the operator, the comment and the lifetime. There are defaults. By default, the operator is whoever the user name of whoever runs the command. I don't think it has a default operation, so if you just run it, it will tell you what to do. And there is the reaper. The reaper is the process that is a basically, a command that runs of a [] /KROPB or whatever, and that is what actually goes through the database and checks for active blackholes that have yet to be deleted. When it sees them, it goes off to the right back end, removes them and then flags them as no longer active in the database. When I ran this in production, and as I said I did run something very similar in production, we ran the blackhole at nine o'clock in the morning, at one o'clock in the afternoon and at 4 p.m. but the exact frequency would depend on what you deemed suitable. Maybe once an hour, maybe once a week.
There is an URL with a more expanded paper, and some example source code. It's all written in python; it doesn't, I believe, have a licence dated, but if it does, it's probably GPL. And in my operational experience with this sort of thing in place, a blackhole is blackholing is actually useful and pleasant and not pain at all.
CHAIR: Thank you very much, Ingvar. Do we have any questions?
AUDIENCE SPEAKER: Hello, David Friedman, I think this is to be commended. We have a similar tool in house written to do exactly this with a web interface, and if anybody would like to see me afterwards, I am happy to show it to them but essentially, the key problem is where prefixes are not reaped and they remain in black holing and then of course, if you don't share this information with support people, when a customer calls in saying I can't reach something, you have a remote provider mail use saying your customer can't reach something. Unless your support people know where to look, something could get escalated to and this will be found out. The more and more problems you have, unless you have reaping these prefixes unless you are doing it in an intelligent fashion, you are going to have problems.
INGVAR MATTSSON: If I may ask, do you find it more pleasant to use blackholing after you have got the after you implemented the similar tool?
AUDIENCE SPEAKER: Do I find it more pleasant to use blackholing?
INGVAR MATTSSON: Or rather less of a pain because the reason I wrote this similar thing in the first place is we used blackholing at ISP worked but it was all route to configures and state kept on
AUDIENCE SPEAKER: I mean, originally, blackholing was done manually and do you it when they said denial a service attack then you'd get requests from other departments saying, oh we'd like to blackhole this server because it keeps trying to send us spam and that's I guess why we created the interface, we gave them the restricted ability to only be able to blackhole certain addresses of certain prefix lengths, just to make sure they couldn't set up TCP connections with the mail servers and that's where the concept attacks came from for us. It's made our life a lot better.
CHAIR: Are there any other questions? Comments? No, okay. Thank you very much.
(Applause)
CHAIR: So, next up is the, well, very long title on the board, clearly attempting to beat the earlier record we set in the week, but it's Darren Anstee from Arbor Networks.
DARREN ANSTEE: Good afternoon, I am a solutions architect for other networks in the EMEA region. For the next 20 minutes or so I'll going to go talking to DDoS attack trends through 2010. I am going to do that based around two data sets. Firstly I am going to talk the 6:Arbor. Secondly I am talking to what I extracted from Arbor's Atlas initiative. What I am going to be comparing those data sets together to see if we can define some of the attack trends we saw through 2010.
One thing do I have to do right at the start here is make it clear that the ash or Atlas initiative and the RIPE Atlas project are actually very different things. The Arbor Atlas initiative is all about modelling Internet traffic patterns in terms of how much traffic goes from A to B, how it gets there what it is and it's also about modelling Internet threat evolution, especially in terms of DDoS attacks and hopefully as I go through some of these slides it will become a bit clearer as to what the differences are.
I am going to go through a lot of this pretty quickly because I only have 20 minutes. If any of you are interested in this stuff, please do come and call on me later. I have got more background information.
One thing I wasn't entirely clear on when I put these slides together are how familiar the audience was going to be it with ash or networks. So I did put a quick 30 second intro in. It makes sense to why we actually put so much time and effort into gathering all of this data.
So, Arbor are a provider of network detection, mitigation, traffic monitoring and report work solution. We search provider networks, gathering flow BGP and SNMP from the routers you already have deployed. Using that data we build models of Internet traffic patterns and from those models we provide threat detection and traffic monitoring and data. You think use peering analysis, capacity planning that kind of thing. We are best known for DDoS detection and mitigation solutions and that's why we put so much time and evident into analysing all of this stuff because it's important for us to know what's going on out there, how Internet threats are evolving so that we can make sure our products actually protect you and that you can protect your customers using them. We have a team within ash or, the Arbor security engineering and research team, whose primary job it is to look at the how the Internet is changing, to help us out with generating the infrastructure security report and also to manage the data collection and analysis tools that we have within the Atlas initiative.
I am not going to explain what a DDoS attack is. This is there as a prompt for me to explain three terms I use when I talk to this stuff. I always talk about different categories of DDoS attack. I talk about volumetric attacks, which are attacks that try to consume link and forwarding capacity, state exhaustion attacks which are there to exhaust state tables and firewalls and hosts and application layer attacks which are there to exploit some aspect of a service or a solution at layer 7. I wanted to make sure that I qualified those terms before I started using them.
The first thing I am going to talk to is Arbor's 6th annual infrastructure security survey and report which were published about three months ago and first presented at NANOG. From our perspective the idea behind the report is really to gather together the ideas, concerns, observations and experiences of the brood err operational security community. With he then collate the response, publish the report. This year the report, well the survey contained 113 different questions. We are asking for quite a lot of information here about the kinds of DDoS attacks people are seeing, how frequently they are seeing them, how big they are, what's being targeting but also about the detection mechanisms they are using, mitigation mechanisms and their thoughts on IPv6 security, v4 address space exhaustion, those kind of things. I am very much only going to talk to the DDoS side of things today, due to lack of time. If you want to see the rest of it, just download it from our website.
This year we had 11 different responses to the survey. The key thing with the survey respondents is that they are all directly involved in operational security, so these are the people that are detecting and mitigating DDoS attacks. The information we get from them is very relevant.
As I said I am going to start off by talking to some of the key findings of the survey in relation to DDoS at a high level. Then talk to some findings from the at also initiative to see if they compare.
First key finding from this year's infrastructure security report was that threats severity and complexity are continuing to increase. In the first four iterations of Arbor's infrastructure security report we saw 100% year on year growth in the side of the largest reported DDoS attack from your survey respondents. Last year, we only saw a 20% increase year on year with the largest attack being at 49 gigs, so we thought, well that's a pretty big number so maybe the growth curve has started to from then off. This year we have seen a return to a hundred percent, with the largest attack being over 100 gigs. That represents 1,000 percent growth since our first survey. From your personal perspective, we were stale talking about 1 gig attacks as being pretty significant so the fact that there are now 100 gig attacks out there is scary. That magnitude of attack is going to have a major impact on anyone's infrastructure.
As well as seeing this return to rapid increase in the size of large attacks, we have also seen more of our survey respondents indicate that they are seeing application layer DDoS attacks. As in previous years they are predominantly TAR defendanting HTTP and DNS services. We have started to see some growth in attacks TAR getting SMTP and voice infrastructure. We are starting to see threat the deif he was gap widen slightly. That's because attackers are clever remember about how they are using their resources and they are start to go use much more mixed attack so they are combining together volume metrics, state exhaust and application layer attacks at the same time to make it much more difficult for to us figure out what's going on and therefore make it harder for to us react proactively before there's any impact to service. It does emphasise the fact that everyone Des need to have the right people, right processes and the right kit in place to deal with this stuff.
The last things that I want to talk you from the infrastructure security survey is quite interesting, and it came from a lot of our survey respondents who indicated that they had IDC and mobile services. What they were telling us in the survey responses is that through 2010 they saw quite a lot of problems with their firewalls in relation to DDoS where the state tables became exhausted and I'll talk to that in a bit more detail in some of the upcoming slides.
Going back to DDoS attack size growth over time in terms of survey response. We can see that in 2009, we had 49 big being the largest reported attack size. 2010, 100 gig. So this return to 100% year on year growth. So why do we think the growth slowed down last year and returned this year? Well, last year was the first year that we saw a lot of application layer attacks out there and application layer attacks can be very effective with just a few hundred which will bits of. And they can be difficult to detect because from a protocol perspective they can be entirely legitimate. As a consequence of their effectiveness though, what we have seen is that service providers and also application vendors have put counter measures in place to help deal with application layer attacks and as a consequence, attackers have had to up the anti in terms what they have been doing to achieve their goals. We have seen a combination of things that we think are driving the attack sizes back up again.
Firstly, there are larger botnets out there that seem to be better run. Secondly, we have seen a big push of malware into mobile connected devices which has expanded the number of bots that people have available. Thirdly, we have seen attackers, this one is important, making far more use of open DNS resolvers to generate very large volumetric attacks using DNS reflective amplification. And we have also used we have also seen as I mentioned this increase in the use of mixed attack vectors, people combining volumetric, state exhaustion and application layer attack vectors together in order to make it move difficult to figure out what's going on. Because when there is lots of sessions being reset, when the networks are being congested, it is harder to figure out what's happening.
We have also seen, as I mentioned, more application layer attacks. More of our respondents seeing this. 77% this year. They are predominantly targeting HTTP and DNS. We are seeing some increase in attacks in port 25. We have seen some attacks against VoIP infrastructure as well and we went out to ask what those were and what they turned out to be was people trying to brute force credentials for toll fraud. It manifested itself as a DDoS attack.
In terms of attack frequency, that again seems to be increasing. 94 percent of our respondents seeing at least one attack per month. 35 percent seeing 10 or more attacks per month. That was up from 18 percent last year. So overall, we are seeing the size of the large DDoS attacks out there growing. We are seeing more large attacks out there. We are seeing more application layer attacks out there and overall the frequent receive attacks does seem to be growing.
Going back to my last point on the infrastructure security report in relation to firewalls and state rich infrastructure, we did get a lot of responses from IDC and mobile service providers indicating they were having issues in this area. If we look at the IDC responses 86 percent of those had firewalls. 50% of them saw that infrastructure fail in 2010 due to DDoS and to an extent it's not hugely surprising because this equipment is very good at what it does. It's good at maintaining confidentiality and integrity. It's just not great in the face of a DDoS attack because it does maintain a lot of state on the traffic that's going through it. We have started to see attacks that target this specifically so attacks that are crafted to exhaust the state tables in firewalls. And that's a bit of a concern. So, just wanted to make people aware of that. We do need to think about this when we are designing our solutions, when we are deploying firewalls to make sure that we protect them with ACLs if we can, all that have kind of stuff.
What I want to do now is talk to some data from the Arbor Atlas initiative and compare that with the responses we got to the survey. The Arbor Atlas initiative is very different to the RIPE Atlas project and I am going to talk about one data set here, the at loss Internet trends data. If you want to know more about how Arbor Atlas works, I am talking about it in the MAT group. But the Internet trends data relies on Arbor's customers of our peak flow solution and what our customers can do is they can tick a check box in their configuration which allows their deployments to share anonymised statistics with us on an hourly basis. Those statistics include information on the attacks that that customer is seeing and. We scant tell who the customer is, we can't tell what's being attacked. We can't tell a few of those things but what we can see is how big the attacks are, what ports they are on. Those kinds of things.
For this talk, I am focusing on one of the detection mechanisms that our product has, something called misuse detection which is there to detect your traditional flood type attacks, so sin floods, and all that. Those kind of things. And I focused in on that purely because it's easier for me. If I use any of the other detection mechanisms I have to do a lot more data mine to go make sure I don't include results that you are down to route reconvergence, flash crowds, that kind of stuff.
In terms of the size of the sample, we had a misuse event roughly every eight minutes in the Atlas system last year, so it is a fairly large number of things that I am kind of correlating using some scripts. So what can we see from the Atlas initiative data? Firstly, we can see that the majority of attacks are still relatively small. 79 percent less than a gig. 87 percent less than 1 million packets per second. There is a trend, however, that the number of small attacks are, is actually reducing. You can see that in 2009 those two numbers were 93 percent and 94 percent. Also, we can see that if we look at the destinations for those small attacks we can see that the stand out ports support 80, port 53 and also port 0. So you know we are seeing something akin to what we saw in the infrastructure security report that attacks do seem to be focusing on ports 80 and 53, and we are seeing a trend of attack sizes increasing. You'll hear me talking about portions when I go through these slides rather than absolute number. That's because as we add customers to this system the number of things that we monitor increase anyway. I tend to talk about proportion because it's more statistically valid.
We can look at average monitored attack sizes on a month by month basis and these graphs are showing me the average attack sizes in mega bits per second and the average attack size in kill bats per second. And as you can see, it is trending upwards, although it's not entirely smooth. There are some big spikes here and here and if I get time at the end I'll talk to what caused those spikes. The average attack size in February this year was 891 MEGS, 622 kilo packets per second. Not that large in terms of you know the big attacks you see in the press of 40, 50, 10 gigs, those kind of things. Given a lot of edge connectivity is still down at 1 gig and below that size of attack is going to have a major impact on a lot of customers.
If we look at things at the other end of the scale though, the larger attacks, the attacks that I would qualify as being over 10 gig, over 10 million packets per second. What we can see is that there has been quite a large growth in the proportion of these attacks. Up 470% from 2009. And that again ties in with what we saw from the infrastructure security report in that we didn't just see an increase in the largest reported attack. We also saw more large attacks being indicated by the survey responses.
In terms of attack duration though, that hasn't changed very much. We are still seeing that the majority of attacks are relatively short lived. 70% are less than an hour, but again at the other end of the scale we are seeing an increase in the number of large of longer lived attacks, attacks lasting more than 24 hours and this again plays to some of the things that you may have seen in other Arbor presentations where we often talk about the fact that it's important not just to have the right solutions in place, it's important to have the right processes and the right people in place to make sure that you can deal with this stuff very quickly when it occurs, because if it takes you two hours to react the attack it probably finish and the customer has had problems already by then.
I am going to drill down to see what we saw for port 80 and 53 because those were two ports that were highlighted in the infrastructure security survey response. 2009, 19.6 percent of our survey respondents indicated, sorry we had 19.6 percent of attacks targeting port 80. In 2010 this had increased to 31%. What we saw is far more attacks targeting fewer ports and port 80 and port 53 and fragments seem to be popular because they get through people's firewalls and ACLs. If we look at the other end of the end of the scale, it's more concerning that we saw a rapid growth in the number of large attacks targeting port 80. 590 percent growth in attacks targeting port 80. All in all, what this is supposed to show is the fact that we are seeing overall attack sizes targeting port 80 increase. To 292% growth in the number of attacks over 1 gig. 500 percent growth in the number of attacks over 10 gig. Again that seems to tie up with what we got from our infrastructure security survey respondents.
We look at port 53 though, it's different the the proportion of attacks targeting ports 53 didn't change much between 2009 and 2010. But what did change was the size of the attacks. We had an 885% increase in the number of attacks over 10 gig targeting port 53 and this again played to some feedback we got in the infrastructure security survey, which indicated that about 30% of our respondents seeing failures in their DNS infrastructure due to DDoS through 2010. And there was also a lot of concern there in relation to people using open resolvers to generate very large attacks through DNS reflective amplification. And we did monitor a number of very large attacks from the Atlas initiative last year over 40 gigs and over 50 million packets per second. So again, those two things do seem to tie up.
So, I think I have got a couple of minutes left before questions. So, I'll come back to the average attack sizes I had earlier on and talk to those two spikes. Had a these graphs here are doing are, this is the proportion of attacks over 10 million attacks and the proportion of attacks over 10 gigs per month. And we can clearly see the same spikes that we had earlier on in June and July in terms of bits per second and August and September in perspective of packets per second. What we can do with the Atlas initiative is drill down into the data to see what caused them. The spikes in the bits per second mainly down to some very intense activity targeting South Korea in June and July last year. 242 attacks greater than 10 gig in a two month period having only had 16 in the previous five months. So it was a fairly frenetic time in last June and July in Korea. In terms of PPS spike this one is more interesting. We saw the majority of attacks that caused that spike targeting two particular IDC and hosting providers in the US, the focus of those attacks of port 80 and port 53 which again were the two that were highlighted in the infrastructure security response and we did see some very large and very long lived attacks there, so we saw one attack at 66.2 gigs. 108.89 million packets per second lasting three days targeting port 53. That's what caused the second spike that we saw earlier on in the graphs.
The key points from this really that we can take away are that we do seem to be seeing DDoS attacks trending upwards right across the scale in terms of size. We also seem to be seeing the frequency of DDoS attacks increasing. But, the top end of the scale, we do seem to be seeing far more larger attacks, attacks larger than gigabits per second, larger than 10 million packets per second and the top end of those big attacks is increasing rapidly and the boast ISC and the Atlas initiative seem to be confirming that. That's pretty much all I wanted to talk to you today and I'd like to invite questions.
CHAIR: Thank you very much. Very interesting. Are there any questions?
AUDIENCE SPEAKER: It's not really a question, it's more of a plug. As Darren mentioned, he is going to talk about the details behind the methodology of the Atlas initiative in the MAT Working Group that starts at 4 p.m. in the St. John's Room across the corridor today.
CHAIR: Of course it would be remiss not to mention that after the MAT Working Group, there is a Measurements BoF which you should all go to which takes place in St. John's Room. I am not saying that because I have to be there. More of you should go along as well.
AUDIENCE SPEAKER: Thank you for your presentation. Actually, a few questions.
CHAIR: Could you just say who you are.
AUDIENCE SPEAKER: I am [] /SRALT err, and I am with with the [] NATers consol but also the Chair of the Cybercrime Working Party at the RIPE NCC. The first question I have is, you can see a rise in the attacks but what sort of attacks are they? Are they criminally or politically or do you have any figures on that?
SPEAKER: I don't have any numbers on that. South Korea, you can draw your own conclusions. We do have well we do know why, for example, we know why there was a large spike in attacks against two hosting providers in America but I can't really tell you that, because you'd be able to tell who I was talking about if I did and we are not really supposed to do that. So, we don't really talk to stats on whether a lot of these attacks are commercially, politically motivated although it is a fair mixture. We had WIKI leaks and anonymous, we had various people who were you were set at various companies merging last year. We have the traditional summer attack festival words to South Korea and the retaliation towards to China. There are some there is fair mixture in there.
AUDIENCE SPEAKER: The second comment is on mobile phones, because a hell of a lot more people are getting smart phones and connecting to the Internet. I was at the BotNet meeting that was organised with Echo earlier in March, and the message they gave off basically is mobile isn't really a problem yet, but we expect it to become late this year early next year. You mention it specifically. Is it growing already?
SPEAKER: There is two things there. Firstly we have started to see a lot more attack traffic coming out of mobile connected devices. Now we don't know whether those are smart devices or whether those are laptops with 3G dongles in them but we know they are coming from mobile service providers. That's confirmed by a number of other reports, I think Akamai has seen an increase in traffic in one of their reports they publish quarterly.
On the second point there, we have seen, or I have seen reports out there, I think [Semantec] have published one which indicates they have seen a big growth in the amount of mobile malware that's targeted at Smart devices, so we are not seeing anything that we can confirm yet is coming from Smart devices but I think it's only a matter of time.
AUDIENCE SPEAKER: One last question? The last question is, I was in South Africa at the meeting I was asked to present there on cybercrime and cooperation, just like I am doing here and there was a gentleman, I think it was Congo, and he said, well, tell me all these beautiful cooperations but we are being DDoS, our national bank is DDoS and we don't have anybody in the whole country who knows what's happening and does anything about it and it just stops when it stops. Do you have any tips for developing countries to start something like a protection against this because they apparently have no money, no education, nothing. Where do you start in your opinion?
SPEAKER: Without commercial solutions, there are things you can do, so there are traditional ways of doing this using diagnostic ACLs, using flow tools, that's one of the most popular ways of doing it in fact. In this year infrastructure's security report, using flow tools and home developed scripts was one of the most popular way for detecting DDoS attacks. They tended to use commercial products to actually figure out in detail what was going on and then mitigate it, but flow tools, C flow D, things like that do seem to be fairly popular ways of isolating what's going on. It's difficult to do that proactively though, so without the commercial tools, you tend to be relying on something actually falling over before you know it's going on and then you can use flow tools to diagnose it but they can do that. I mean, we are doing I am doing a talk at first this year which talks about how to use NetFlow to actually diagnose DDoS and things like that. That might be useful for them to get a copy of.
AUDIENCE SPEAKER: Daniel Karrenberg, chief scientist at the RIPE NCC. On the port 53 attacks, did you do any differentiation whether the attack traffic was queries or responses?
SPEAKER: No. All the data we get is based around our peak flow product which uses flow. All we can see is based on data which is from the layer 3 header. With he don't know whether it's requests, queries or garbage.
AUDIENCE SPEAKER: Daniel. You also have some sources as part of this that is more detail.
SPEAKER: We do.
AUDIENCE SPEAKER: This would be really interesting because in order to find out whether it's are reflecting attacks or not. And what the relative proportion is here because my suspicion is here from experience, that there is a fair amount of reflection going on in this business.
SPEAKER: That was fairly clear in the infrastructure security survey. We had a lot of comment to that. Interestingly, one of my well my final question to the MAT group later on is going to be, I am interested in ideas of things you'd like us to look at from the Atlas initiative, so that's one of them. That's great.
AUDIENCE SPEAKER: I mentioned it there again.
AUDIENCE SPEAKER: Do you have the data that you get generally packet sizes or is it just megabits and packets per second?
SPEAKER: Just megabits and packets per second.
CHAIR: Okay, are there any other questions, comments? No, in which case, thank you very much.
(Applause)
BRIAN NISBET: So, you get me again. As some of you will remember, there was three proposals made to the Anti Abuse Working Group at RIPE 61, specifically 2010 08, 09 and 10 from two different proposers. After discussion at the meeting, it was decided that those three proposals would be withdrawn and some, possibly not all, of the matters discussed within them would be dealt with by a taskforce, and we have substantiate that had taskforce have been doing some work and the taskforce has stated that it will update the community through the Anti Abuse Working Group. So here is the first of those updates.
Those of you you are going to DNS later will hear this again, albeit in a slightly shorter form, because it was very much not DNS, database, sorry, database again because it was felt that as databases are already involved in that taskforce we would give a brief update and then direct everyone to Anti Abuse from then on.
So, the aim was to develop one or more policy proposals and our general recommendations on how collection, maintenance of relevant information in the registry database should be organised. And it was very important that it wasn't just a group of the community that we had regular contact with the NCC, especially the database group to do this.
The participants there, and there is a number of other people who have been invited or whoever participated to some degree but these are the kind of main participants. And they come from a wide variety of backgrounds and sadly I didn't run away fast enough.
So the first meeting was on the 10th March of this year, after some discussion in the mailing list. We had a second meeting on Monday, where we decided on our charter, amongst other things, and the next meeting is planned for June of this year, in or around that time. Before we all go and get distracted for the summer.
So, the basic requirements that we're looking at are to have a single point of contact that may perhaps be hierarchal, can simply be queried to return a single piece of information. So to make it as easy as possible for operators, consumers, law enforcement, whomever needs this data, to go, right, who do I have to contact? You know, who is this person or who are these people? And is easy configured and referenced by others. Now, the NCC have already done a lot of work with with tools to make this easier, so we are now going to try and make the data they are querying more straightforward. And so, yes, it's to separate storage in the database from querying the database and presentation. One of the things we have experienced with law enforcement is and other groups is that with we are very familiar in the operator community with the Whois, with we need to make it as simple as possible to ask this one question, if someone is doing something wrong, who are they, how do I get in contact with with them?
So we are exploring a number of options in how to do this. There is been a couple of proposals made already. And we are motoring our way through them. But feedback and/or input and/or I have had an amazing idea on how to do this, is still welcomed. We are not really looking to expand the size of the taskforce, but we will be we are looking definitely for more feedback.
I figured as both myself and Tobias are on the taskforce, rather than invent yet another mail address, we have decided to use the Anti Abuse Working Group Chair's mail address for this, so if you have anything new you want to say or otherwise, then please do.
So, one other thing: Some of the items of the proposal, and I'll be talking to some people very specifically who have already asked me questions about this some of the proposals that were made last year have been considered out of the scope for the taskforce. So, we'll be speaking to the relevant people about this, and progressing those via other means, but if you have asked me questions about it, I will be getting back to you very soon.
So, are are there any questions about that? No, excellent, you all approve. We are all very happy. As I said, the taskforce will continue to report back via the Anti Abuse mailing list and indeed at the RIPE meetings.
So, I am going to stand up here for a little while longer. One of the thing, just moving slightly further down the agenda, into our interactions. Well Working Groups obviously database is the one where we are still interacting with the most, because they are lovely. And also I promise that today's Anti Abuse Working Group will not impinge on the time of database's. I promise sincerely. But the interaction, the main interaction there has been those proposals and the taskforce, both the database Working Group and indeed the database group in the NCC are absolutely vital to the abuse contact management taskforce. So we'll be continuing to do that.
One of the other very large pieces of interaction that the Anti Abuse Working Group does and this has been decided, is with the cybercrime working party, which those of you who may remember, it reports back to the community via this Working Group and so I'd like to take this opportunity to ask [Fous] to come up and give us an update on the activities of the working party.
[FOUS]: Thank you, Brian. It's not at our presentation this year, some of you may remember that last year in Prague we decided to have the cybercrime working party, and to actually start cooperation between the RIPE community, the RIPE NCC and law enforcement. And I gave a story then that I won't repeat here, but one of the slides I had was an open book that was completely with blank pages, and the challenge we faced is trying to get letters into the book and we actually have written a couple, at this moment we have written a couple of chapters which I am going to go into.
We met through the past year for several occasions like the meeting in Barcelona, we met at the ICANN in Brussels in June last year. We had a few telephone conferences, we also met at the RIPE meeting in Rome. We met in London in March, and in February we met at the EU US taskforce on cybercrime where we gave presentations on the cybercrime working party, made it known to law enforcement and governments what we are trying to achieve.
So actually what are the topics that we came up with? We sat down together and said what is it we would like to get out of the cybercrime working party and we came up a few topics that it would be important to have training, the knowledge which is present within the RIPE community and the RIPE NCC is something which law enforcement sometimes lacks, and it needs to have access to. And we decided to look into possibilities for training. We looked into the databases that are present within the RIPE NCC. The information tools they have, and what which could they be of interest to law enforcement.
We discussed the need of a template to exchange information requests. So that actually, it would be a template would be every time the same when the RIPE NCC gets a message for information, and why wouldn't that template be used for RIPE's members in the future if and when it's there, because it's a tool that everybody could actually use, once translated into your own language and adapted to your law system.
We discussed it would be good to have some sort of a contact list. The EU has a system up and running called [] /SES seal which would be actually used for that so we could find each other when necessary and be in contact easier and discuss things on this database.
We also discussed that it would be good to have a list of topics that law enforcement wants to discuss with the RIPE community. So we came up with that, and I'll get into that later. And it would be good, in general, to exchange information together so that you learn to know each other, understand each other's background better.
So, one of the first things that law enforcement did was come up with a list of topics that would be good to discuss with the hype community, and a lot of that at that time it was about a year ago had to do with data accuracy, whether on IPv6 in the future and IPv4 now. So that is something which came up in a few different angles. Also the due diligence when a new member comes to the RIPE NCC as discussed in ICANN and at ARIN, it was also discussed here now at the RIPE NCC.
We discussed forms of information sharing and ways of getting together and actually cooperating. So, it has to do with IP addresses, with with LEAs, discussing topics with RIPE and the way to do that. We also said we need to meet regularly. As you see from the list, we are doing that at the moment, which is I think very positive and it means that there is a better information position on both sides which we are also aiming for.
But this is a list, and I am going to challenge the room here, because there is no LEAs present, so far as I know, is I am going to challenge you as the RIPE community, we have this list from law enforcement. They tell us what they want. But what is it what you want from law enforcement? Are there some specific topics you would like to discuss with them? What are they? We don't know yet because we only know the at the moment plates which is something the RIPE NCC wants. But is there anything that the RIPE community would want to discuss with law enforcement? Is there anything that they want to discuss with governments if the cooperation Working Group which I gave you the comment on yesterday? What is it that you would actually like to discuss with law enforcement? Tell us and bring it to the cybercrime working party because it could be a two way mechanism. You can bring your grave concerns or your problems to a law enforcement and make them understand why you are concerned.
So, where are we and where are we going to? I think that we have achieved a few things. I think that it's very important too that we actually start to go know each other better and understand each other's motives better. We know what is possible and what isn't possible. Law enforcement is understanding that it is a necessity to participate in RIPE's policy processes, which is something they are not used to and now finding out how to equip themselves to do that. Law enforcement comes with completely different questions than in June last year. The list at this moment is starting to change. They are start to go understand the problems that IPv4 transition to IPv6 is going to bring to them and they have a lot of questions on that, and the RIPE NCC is helping law enforcement understand the transition better. It's going to be discussed, for example, at the highest level in the EU, cybercrime taskforce in which all the 27 heads of the cybercrime taskforce of the EU meet twice a year and we are going to present there actually for the first time. Something which went really discussible about a half year ago because they didn't really understand what we were trying to do. They do now. Europol is assisting in this actively so RIPE NCC can actually reach out to law enforcement in an active way.
What we also do is that the RIPE NCC has, to get more understanding for the problems of law enforcement so is means a discussion also changes, which you just heard Brian say on the domain name registration, this is something which evolves in the past two years of discussing this together. It also means that the RIPE NCC takes more responsibility in that direction.
So where are we going to in the future? We already said the EU CCTF, I think also what is happening at this moment is that the RIRs are discussing the topic together. In November I was invited to go to Johannesburg at AfriNIC to present on the cybercrime working party because they were very much considered in the concept. In ARIN a lot of things were discussed with law enforcement at the moment and also they are discussing it together so that it means that also the concept of cooperation on a global basis changes.
I think that in October there is a London Action Plan, which is the anti spam enforcement community is going to meet with the message Anti Abuse Working Group and we are going to be present there also so we are going to present ourselves to the anti spam community, but also to MORG but they think it would be a good thing to continue facilitating this process in the future. What I ended with last year is that we have the opportunity to give this a chance, that we worked on in the past year, this idea, and actually making progress. What I would like to conclude with is, to continue this process and see where it brings us, and also, to make this a two way street; that you can actually bring your concerns to this group also so the law enforcement hears better what your grave concerns are and maybe help prioritising in the future what law enforcement actually should be enforcing.
So that's where I would like to leave off for this year. And see where we'll take it in the next year. Thank you.
CHAIR: Thank you. Are there any questions or comments?
AUDIENCE SPEAKER: Frank, APNIC. I'd like you to thank you for the talk for starters. Our IRT object contact in our emergency contact team for implementation of the abuse policy is security at APNIC.net. I think February, about mid February, we started receiving e mails; in March, we got about 25,000; April, I think close to 30,000. With the sheer volume there is nothing much that APNIC can really do. We can't sort of assess these details on a one by one basis. However, in the back of my mind, I think that maybe we can use the information to report on IP reputation to our members. Another thing that we could possibly do is on a month by month basis, generate reports and not name and shame, but actually show what are the most abused allocations that we have given out. Where is the abuse coming from, what countries in our region. So I think it's a valuable source of information. Thinking of, at the moment, logging all the abuse e mails in a database and possibly in the future make that information available to research institutes. That's all. Thank you.
SPEAKER: Thank you for your comment. Have you thought to engage anti spam law enforcement where possible, because in New Zealand and Australia at least they have very active anti spam law enforcement agencies.
AUDIENCE SPEAKER: I can answer that question for you. I am Paulo, public affairs in APNIC, and, yes, we have been engaging in different cooperating groups that law enforcement agencies have, the global basis, have a regional basis as well and I am here mostly to learn about the approach that this community has words to this law enforcement agency. So, the answer is yes, and I am looking for to increase that.
CHAIR: So, anything else? No, in which case thank you very much.
(Applause)
CHAIR: I think I'll stay down here for the moment. It is really very bright up on that stage.
There is a number of things that I'd like to say at this point in time which lead directly from [] /SROUT's commentary about the CCWP, and touch on the RIPE NCC Government and law enforcement engagement and interactions. There is a number of things which have happened recently which have given us great encouragement as regards our relationship with the law enforcement agencies that are in the RIPE region. Not only has their engagement increased but they have very definitely shown a greater understanding of the issues that the community are are facing and kind of gaining an awareness of the technical problems with which make what they would potentially occasionally like to happen far more difficult. We have spent a lot of time talking to them about IPv6, about how it's not all that scary, and how we will still be keeping an up to date and clean database. They, like most of the RIPE community, appreciate the need, no matter what happens from the point of view of further registrations of addresses or otherwise to keep a good database of that. So they have been very happy in most cases with 2010 06 proposal for IPv6 registration of the database and they have been happy with, you know, what we have talked about as regards the beginnings of what we have been talking about about transfers and I feel sure that we may get some interest and I think what we'll be doing is potentially waving under the noses of some law enforcement people when the document that Dave Wilson was discussing earlier in Address Policy is a little bit more concrete. He doesn't know I was about to say that. But I am one of the authors so I can in I want to.
There is a couple of things I want to also mention here sorry, the other document that they were increasingly happy with was the RIPE 517 document, which we have been talking about a lot at the Anti Abuse Working Group and increed the NCC services. It's the closure and deregistration document. The law enforcement community and Government communities have been very happy that this shows very positive steps the RIPE NCC are taking words to reducing the ability for people to abuse the mechanisms for the registration or otherwise. There is a huge number of positive steps there.
And we have also been speaking to them about the things that are likely to happen as regards IPv4 depletion, or indeed final run out, and some of the threats there, problems around logging carrier grade Nats, around tunnelling and those aspects and that's going to be another technical hill to climb, to a certain extent. We have kind of gone okay, so this is IPv6, and you can find out about it here and here is all the logging, and by the way while people are transitioning they are going to be using several Nats which require far more logging that no one is really doing at the moment, and might be incredibly expensive and difficult to do. So, sorry. And I think, certainly, those communities would much prefer a nice clean transition from IPv4 to IPv6 but as they are not going to get that, we are trying to keep them up to date and the NCC is doing fantastic job, talking and giving train to those groups where possible and that initiative is only going to expand.
I would also say to this Working Group, even those of you, and I know that there is a fairly large cross section between policy and technical people at this Working Group, there are some matters being discussed in Address Policy at the moment and indeed in IPv6, which are of huge interest to the Anti Abuse community. Now, I have just mentioned a lot of them there, carrier grade Nats are obviously a very, very important aspect of tracking and potentially vectors for abuse, also there is a very long, very, very long thread of e mails currently on the Address Policy mailing list in relation to the RPKI certification, allocation certification setup that is being proposed, specific 2008 08 policy. I am not going to express any feelings either way, although I sent a couple of mails to the mailing list and it should be fairly obvious what I my opinion is, but from an abuse point of view or from a law enforcement point of view, that certification may have an impact, may have an impact in what can be done, may have an an impact in how you can avoid your network being abused by people who attempt to route your addresses elsewhere. There is a lot to be read there and it's very, very important and I think, and as we venture further into the bar on waist land that is a lack of IPv4 addresses, all of those other Working Groups are going to have more and more of an impact on abuse. So all very, very important.
And those interactions will continue and all of our interactions with other Working Groups will grow and continue and I would encourage you all to go to as many of them as possible.
So, what else do we have? Not much. Runs massively ahead which in some way makes up for Rome, possibly: Your lost coffee break. So I have nothing else, is there any other business? Anything else that anyone would like to raise at this point in time? No? Okay. So, I shall remind people that if they have any items for RIPE 63, which is taking place in Vienna in October, and please let us know, I will obviously be putting out reminders on the mailing list. As I mentioned, Tobias will be talking about the best common practice document and really, I know I have said this before, but I promise we will have an updated version of that document and the plan is to go with with what was suggested a while ago which is to have a very technical document and also an executive summary document for those who may not know what exactly all the words and numbers mean. And I will make one more reminder of the Measurements BoF, which could be very interesting to people in this room which is happening after the MAT Working Group this evening and other than that, say thank you all very much and I will see you in Vienna.
(Applause)
LIVE CAPTIONING BY MARY McKEON RPR
DOYLE COURT REPORTERS LTD, DUBLIN, IRELAND.
WWW.DCR.IE
51