Anti‑Abuse Working Group
RIPE 79
17 October 2019
9 a.m.
BRIAN NISBET: Good morning. As we were just discussing, this is the Anti‑Abuse Working Group. If you are looking for IPv6, it is not in here. It is over there somewhere. I have only just arrived, I haven't learned the venue yet.
To what will be hopefully a less firework filled Working Group session than we had in Reykjavik. But it was very cold there and we all needed to be warm. So, debate and discussion was the best way of achieving that. I am Brian Nisbet and one of the co‑chairs of the Working Group, the other co‑chair and unfortunately Tobias is not managing to make it here for this meeting.
So, we have got a few interesting things to talk through, and to get through. So, let us move on.
Thank you to obviously the NCC staff for the scribing and chat monitoring and hello to any of our remote participation people, and of course thank you very much for the awesome stenography, greatly appreciated.
So, there were minutes from RIPE 78 which we circulated to the list, there didn't seem to be any issues. So, unless anybody has any comments now, we will deem them to be official and accepted and all the rest of that.
No? Okay, great. Cool. Tick.
And are there any last minute additions to the agenda that anybody has? Again, great, cool.
So, let us move on in that case. Recent list discussion. I think most of that is covered either by ‑‑ well by the policies we're going to talk about or the policies we're not going to talk about. I think obviously it's worth stating for those who haven't been paying attention to the mailing list, that 2019‑03 which was a nice simple policy that no one had any particularly strong opinions about, has been withdrawn and the reasons for that withdrawal were sent to the mailing list and there is probably something to talk about at some later point in time I think in the RIPE community and I speak as much as as app community member as the co‑chair of the Working Group at this point in time, about Impact Analysis, where the Executive Board say they are not going to do the thing that the community may or may not be asking them to do. I think that's going to be something we have going to have to discuss as a community. I don't propose to talk about it here now, but certainly when I read the Impact Analysis I was surprised by that form of words. So I think that that is something that we have to ‑‑ we'll have to talk about in this particular case obviously the proposal was withdrawn, but you know it's it would be interesting to have seen what kind of constitutional crisis would have occurred had the Working Group approved the policy.
And therefore enough constitutional crises going on in the world at the moment without needing one here too. Listen, as I said I wanted to say out loud that that is something that struck me as strange. I think it's something in the community we'll need to talk about. But I'm not going to do now because we could fill the 90 minutes and the 90 minutes after that and after that, so I think not today, but we need to figure out a way of doing that and maybe at the next meeting ‑‑ I don't know, but equally have to see.
There is no other particular recent list discussion that I can think of that I want to particularly talk about. Again, if anybody else wishes to say anything on any of that. No? In which case great, we will move on in that case to first of all the update on the policy, which is 2017‑02 and an update from the NCC, Marco, on that please.
MARCO SCHMIDT: Good morning everybody. My name is Marco Schmidt, I work for the RIPE NCC in the registration services and I would like to give you the final update on the implementation of policy proposal 2017‑02, the proposal that your Working Group has been discussing and had reached consensus last year.
We gave you over the last RIPE meetings some progress updates, how the implementation is going on, and today, I have the own up because just around one week ago we announced the full implementation to give you the last update, the final report on that one.
To the one of you that are not aware about this proposal, it was about that the RIPE NCC got the mandate to regularly validate the abuse mail book attribute that the mandatory in the RIPE database for resource objects and to follow up when this attribute is incorrect. Final consensus was reached already last year in June and as I mentioned one week ago we announced full implementation.
Here is a little overview why it took the time that it took, because it was quite a big change. Basically, whole 2018 we were busy to develop the right approach because we decided that we will test the technical parameters of abuse mailbox attributes, of the e‑mail address basis'ically, and to test it via some e‑mail validation tool without the need to contact holder of that address, and only if it would fail, then we would actually follow up.
And so we had to integrate this tool in our systems, our ticket system, we had to create the process, we were running a trial to estimate actually the work load because we had to find out how much e‑mails probably will be needing a follow‑up. And this took us until January 2019. It also included that people send it to our board, the RIPE NCC Board some options, how exactly to take this approach. And then from February until now basically, we validated all more than 77,000 distinct abuse mailbox addresses that are there in the RIPE database.
Also just as a little reminder to the ones that haven't been here, the last RIPE meetings we decided to split this in PE three faces because you can basically divide the abuse mailbox attributes in roughly three groups. The first one are the ones that are researches to LIR organisation objects, so the one of our members. There were around 18,000 of those. Then we had more than 45,000 of more specific parts of LIR resources, so let's say an MP assume, there was directly an abuse mail attribute INETNUM object or there was an organisational object references which then‑an Abuse‑C with the mailbox attribute. And last but not least of course also all the independent resource holder objects, resources, they also need to have an abuse mail book. Attribute and there were more than 13,500.
This other quantitative numbers, but I'm pretty sure you are actually interested what about the quality. What was the outcome? How many e‑mails had to be fixed, what failed, what worked. And actually to get these numbers it was more difficult than expected, but I can show you something that gives some indication, because as I just mentioned, there was ‑‑ we are running an automated e‑mail check and if this check is passed it execs if the domain exists, and so on, then we consider this e‑mail as validated. And this almost 72,000 of this 77,000 abuse mailbox attribute addresses passed that test and five and a half thousand needed a follow‑up. So a ticket was triggered basically.
That's about 7 percent. And still this number has to be taken with a pinch of salt because there is an amount, there is a fair amount of false positive in it. What we did is, when an e‑mail address failed to automate the test, besides informing the LIR, we also send an e‑mail to that address with validation link to see if it's actually a false positive that the link had clicked on. But, even there, cannot afterwards say perfectly if the link was clicked, if it was something that was fine from the beginning or maybe the e‑mail address hasn't changed but they did some mail server configuration to make it work again.
Another interesting outcome was that initially, we, from some initial testing, we anticipated that the quality of abuse mailbox attribute for LIR objects would have a higher quality than the other ones, so of the more specific peer assignments and of the PI assignments, but what we observed that probably quite some LIRs that were contacted the first time because we saw their own e‑mail address failing, then they started to fix that one but also look into deeper what other mailbox attributes that have control over, and actually solve them as well. So, again, there is a bit difficult to get exact numbers but we see that around 8,000 abuse mailbox attributes have been updated during the time of our validation process. So, that's an indication, and this number is higher than the one that actually failed the test. Again there might be some that would have been updated anyhow, but it seems people did their work, they fixed things, even proactively, once there were informed the first time, which is actually quite a good result. And overall it's fair to say that several thousand abuse mailbox attributes are new working and receiving e‑mail addresses because of this validation.
Some additional results. We could talk much more about it but I will limit this a bit.
Not just where this e‑mail address is fixed, but also quite often when such e‑mail failed it turned out it was related maybe that the resource holder had changed name or was merged. And so in the process overwards we fixed some registration updates.
Also sponsorship changes happened and also there were some resource holders that didn't exist any more, the resources were not in use, we found this out during this validation process and some addresses were even returned.
There was more work load. We had hired 3 temporary colleagues that did especially the validation for the LIR organisational objects and the abuse contacts there, and also interesting that might be relevant for the policy proposal that Jordi is prepending after me around 20 to 25% of the, of those tickets needed a manual follow‑up, because what happened again, with such e‑mail address failed to automate the test, a process started, we sent some automated e‑mails, three in total, I'm not sure maybe four, to remind them hey there is something that you need to fix. And includes the validation link to the abuse contact and details to the LIR.
Still, around a quarter of them still didn't respond to, or acted upon those e‑mails, and we need to call them or we need to send them more personalised e‑mails. And this was, we're talking about an amount of around 4,000 tickets, 4 to 5,000 tickets, which would be more, as you will see when Jordi's proposal would reach consensus.
And now we have done a regular validation and they are integrated in our regular processes and we expect now as we went through the hassle of the first time validation, the amount of ticket that failed those tests will be much lower.
And that brings me to the end of my summary. I think I am nicely on time. I see Jordi rushing to the mic.
JORDI PALET: If you can go back one slide. I just want to be clear about that point because I am not sure I understood correctly ‑‑ the 20, 25% is after you send several e‑mails after the automated validation failed?
MARCO SCHMIDT: Correct. So again there was about one month in which we sent several automated e‑mails, we increased the tone during those e‑mails, hey, you really need to fix it. And still around 20, 25% didn't respond to that and we needed to take additional actions.
CHAIR: Just to check. So at this point in time, this is now happening ‑‑ so it's now part of your regular process, happening once a year?
MARCO SCHMIDT: Once a year, there is something, I forgot to say that for abuse mailbox tracts of independent resources and more specific PA parts, we, at the moment we then stop to really push them to fix it because most important was the fix the LIR ones and we added a remark in the database, okay, if this one is not working, go to the sponsoring LIR and there is an abuse contact. And right now, even if the twelve months haven't passed we are now validating those ones that are not completely fixed again after four months. But in general, yes, it's in the regular process.
AUDIENCE SPEAKER: Thank you very much Marco for the report you have made to the implementation of the policy. So I'm pretty happy that such a proposal ‑‑ we proposed with Gegory Monday yeah was pretty useful, I could see that happen and I had a question regarding the work load for the RIPE NCC but you have partially answered the question, and I think now you will have the element to answer the result or the outcome of the next policies, that Jordi will propose perhaps, to evaluate what could be the workload of the RIPE NCC of the way to go one step beyond of such a verification.
MARCO SCHMIDT: Absolutely. So the lessons learned from this implementation will be definitely useful for an Impact Analysis if possible for the next proposal, yes.
AUDIENCE SPEAKER: Rudiger Volk. Marco, do I hear that you are not seeing any additional work to improve this process and the communications attached to it?
MARCO SCHMIDT: You mean that we can improve our process further?
RUDIGER VOLK: Well, okay, actually the distribution of the error messages ‑‑ well, okay, not very much focused, so I'm getting them too, and what I'm seeing is that actually the information I'm getting there is not very helpful. It looks like even I would have a quarter of an hour to work on any indication of a problem to actually figure out what relations with customers and so on actually are the source of the damn thing. And kind of, when I'm looking at it and I'm not spending a lot of time on it, it looks to me that well, okay, you are pointing to somewhere where you could figure out how the strange database schema can be tracked back. Actually I would very much suggest that you look into providing the mechanisms that does the research essentially on your side automated and allows the recipient of the problem report to do the stuff that they actually have to do without incurring additional effort.
MARCO SCHMIDT: Thank you, and you are absolutely right. There is always way to improve processes and I will find you later off‑line to get your guidance what could be made more clear. Thanks.
CHAIR: Okay. There we are with that. I wish to say, though, just before you leave the stage, and I know this was said in Address Policy yesterday, now that Marco is moving away from the policies office in the way that he has been to registration services which is apparently where all the cool excitement is, surprisingly, but there you go. I wish to thank you very much for the all the work you have done for us through the last few years with several fun policies, and it has been absolutely wonderful to have you there to help help and guide us through the policy development process. So thank you very much.
(Applause)
So, speaking that have policy development process, now we have the regular Jordi slot in this time we are talking about 2019‑04, please.
JORDI PALET: No BGP hijacking any more ‑‑ at the moment.
Okay. So, taking advantage of the previous presentation of course, I think it's obvious that it's time to improve it. When I presented this at the previous meeting, I was told, look, it's too early. We need to wait for ‑‑ even if we have some results. So the problem I still see with the actual implementation or the actual policy is that it's ‑‑ and Marco said it, there are chance for false positives, okay. So there are e‑mails that survive to the check that there is an existing server and there is an existing mailbox, but actually we don't know if that mailbox will receive abuse reports or respond to them or whatever, so there are many possibilities that happen from the actual validation, even if it looks very nice and we have got updated about 8,000 e‑mails or 8,000 abuse contacts, it's still a high number of e‑mails that not necessarily are going to do it well.
So one of the comments I got from the previous version was, I was asked for human validation. I removed that. I agree, there is ways to automatically process the abuse validation. It may be artificial intelligence or whatever, so I am fine with that.
I have also reviewed, I think, probably 75 percent of the previous text to a much shorter version, trying to match what it was set in the mailing list and in the previous meeting.
And, again, this is the open question. We know now that with the existing validation, only 7 percent failed and hopefully this 7 percent is being fixed sooner or later. But from the 93 percent, how many are for real? That's the thing. I believe our existing policy is good, but not good enough, and we need to improve that.
So, what I am suggesting ‑‑ I am not going to read all the text, just a short summary of what we have in the proposal.
What I'm suggesting is a better definition of what is the abuse mailbox. What are the objectives of this new validation process if we reach consensus, and basically, it will turn in something like this.
We'll start the validation, we have 15 days for the Abuse‑C to respond to that validation. If it fails, then it will escalate to other contacts, which is the same as it being done now but the difference is that now we don't know from the 93 percent, how many are for real. And I think that's a big number of uncertainty, right.
This orange thing here is not in the policy text. It's a suggestion for the implementation. I think if the first validation fail, we need to know somehow. So, I am suggesting it can be marked as provisionally inveiled in the database. For those that are not aware, this policy probe, the most complicated one was implemented already in the APNIC and they implemented that feature, so I think it will be nice to have the same across the different registries.
So if this second validation fails, if the escalation process to additional contacts fails, then it will be marked as invalid, right. That's the thing and then you are not complying with the policy, exactly like what we have till now. But the validation is more efficient this way, in my opinion.
Additional points:
Well, I am describing how it works, this validation, very, very shortly. And then I want to make sure that there is a clear escalation process for anyone that is not able to use one of the abuse contacts to escalate that to the NCC. I was told that this is already existing. In fact I have used it sometimes. But I understood from our, my conversations with Marco that, it's better that we state it in the policy text.
And I think that's it. I am done with the slides. Questions? I recall from the mailing list, there was a few people commenting that what are the legal impacts on this but some people were saying well what are the legal impacts of not doing this as well. So that was the point. And I got several inputs, very good review I think from Carlos, I think it's the will only one that really provided several inputs that, depending on the discussion we have here today as well, I will, if necessary, update to a new version or whatever. Thank you.
BRIAN NISBET: Thank you. So, there has been a small amount of discussion on the mailing list, we're still in the discussion phase and we now have pay treat from the policy development office, who will be helping us and guiding us through this, so thank you very much, and remember, please, if you have comments or otherwise, if it's not in the mailing list, it doesn't include itself in the discussion. But with all of that said, Peter.
AUDIENCE SPEAKER: Peter Koch, DENIC and since the minutes of this meeting go to the mailing list, I would propose that comments made at the mic are part of the discussion.
When our friendly regulators who are increasingly motivated to get their hands on policy making, when they come up with an interesting suggestions, we usually demand that there be fact based policy making or evidence based policy making. In that spirit, while I understand Jordi that you are pointing at percentages and so forth, I fail to understand what the real world problem is that you are trying to solve. That's for one.
The other is an observation that I think that I made on a previous policy proposal that that is successfully been withdrawn already, that I fail to see how this defines policy. What this does, the text does is, it defines tests from which one has to derive the policy, and I'm not suggesting that you turn that around because the real motivation behind this again is weaponising the registry by creating compliance cases, and I still think that this is an abuse of the policy process. And until we find a real world problem to solve, I think we need a moratorium on this kind of proposal. Thank you.
JORDI PALET: Well. The thing here is, what is the mission of the registry? It's having the right registration data. Today, we don't know from the 93 percent how much is for role. So we don't have a good policy right now to fulfil our mission. I think it's simple.
AUDIENCE SPEAKER: Rudiger Volk. I certainly agree a lot with Peter, and I am I think only slightly different angle on the same stuff.
In many of the policy proposals, I'm seeing that, or it looks like people really want to police and that is actually, I think, not what the whole RIPE stuff is about and it's strange that Germans step up and object to that.
What I'm seeing is ‑‑ well, okay, Peter points out that you are creating compliance conditions, and well, okay, not really spelling out what should be done, and actually I would that I can that argument a step further and say, well, okay, the purpose of this Working Group actually should be helping people who fail somewhere to do a better job. And I'm not seeing anything there that actually explains what is expected from people to do. And of course, I can tell you, if we formalise the compliance criteria, well, okay, evil people will construct the robots that work and sly and don't do what actually is the purpose of this Working Group, as I understand it.
JORDI PALET: I don't agree with that. I think I tried to find the right wording to avoid that. If it can be improved, probably. But I think this is helpful, and I think you can make tricks to pass the validation always, but that don't means you are actually complying with the policy.
CHAIR: Okay. Sorry, hang on ‑‑ hang on ‑‑ you disagree
RUDIGER VOLK: I disagree, and the point is, the point is, you are not ‑‑ well, okay, I'm seeing no single letter in this that helps people to set up the processes to really respond to the real life cases and not just for the formal checking.
CHAIR: Okay. So there is app point made there that part of the, not the whole of but part of the role of this Working Group is absolutely, to educate and help. So, if, and indeed either way, if or if not this policy reaches, yes then absolutely there is probably a work item there which is giving a bit more information, you know, giving information and helping. Point is taken. Disagreement between the two of you on the policy is also taken.
Carlos.
AUDIENCE SPEAKER: Carlos from Portugal.
For me the problem statement is pretty damn clear. There are people who don't really like to answer abuse, so this is an effective way of having the minimum trouble. But to me, as we are trying to manage a registry with the most accurate information, well, an abuse contact is part of that. So, what ‑‑ at some point we are seeing is that the registry data, well, it's like if we register the abuse contact for Donald duck and Mickey Mouse, that's okay. So something has to be done to improve that situation.
JORDI PALET: Thank you.
CHAIR: And I think probably last at this point in time. Peter.
PETER KOCH: And let me clarify, and also respond to Carlos, because he paved the way in a nice way.
The issue that both of you brought up in terms of accuracy is something that we have discussed in multiple places, and I would suggest that everybody who is interested in the bigger picture come to the Community Plenary this afternoon, because as, you know, the bigger topic of what's the purpose of the registry is addressed and will be addressed by a task force that is going to be announced there, which is probably another suggestion to dampen micro actions on the current database, and here we understand where we want to go.
The other issue is that we need to be careful about policy proposals concerning the jurisdiction of this community as in, what you, Jordi, have been conveying now is that you want to, well say encourage, dictate, whatever is the nicest word, or maybe the most appropriate, business processes of LIRs /ISPs /network operators. And there is a very interesting question in how far the community can actually rules those, and I'd rather see that in explicit discussion rather than sliding into this more and more by policy proposals that actually only define policing tests. And that's more constitutional issue, what can this community or what would this community actually be able to set policy for, to set rules for. And I think that going into the business processes is already a step too far. Thank you.
JORDI PALET: In the previous version I will agree with you, there was too much in depth processes process management to the members. But I don't think this is the case any more in this version.
CHAIR: Okay. Thank you very much.
(Applause)
So, there are, it's roughly two weeks left of the discussion period I think, give or take, but for this policy on the mailing list. So, please, if you have opinions, one way or the other way, questions, etc., etc., that is what the mail list, the forum is there for.
So, moving away from policies, we now have a couple of presentations on abuse matters and what is happening elsewhere. Things are happening here, things are happening elsewhere. So I would ask Carlos to come up, so this is a presentation/discussion about ASN drop. So thank you very much.
CARLOS FRIACAS: Good morning everyone. I have presented myself.
I work for the Portuguese research and education network. I understand that at some point certs are under represented in this group. But this is a small presentation about some thoughts, something that I found and decided to look at some numbers. And get some numbers. So I am sharing that with you.
So, this is what my team does. Well, we are integrated in a national CSIRT network, also a European wide CSIRT European wide network and also a global forum.
What is ASN drop? So this is something that is generated by Spamhaus, and this is something that I monitor on a daily basis. This is basically a list. I understand it as a bit of like a rating system, but they don't rate like A, B, C and D and E. They just rate what they think it's the bottom of the rating.
So, in my country, well because we were in bailout some years ago, we know a bit about financial rating companies like Standard&Poors, Moody's, Fich and so on.
This is a bit different. But also as a reputation impact, a potential reputational impact on some networks.
So, just before proceeding, I want to just make clear that we are still not using this list. We are just monitoring it. We consider this to be free intelligence, so it's ‑‑ this is a list published everyday on the Internet. So, anybody can see that if they are interested of course.
What I wonder is that if anyone really is using it or not. Either from a security point of view, or either from a networking point of view.
So, I wonder a bit further, and I tried to understand what it is, the usefulness of this list. So, I have some ideas. I hope that someone at the microphone could point me up to other sources that can help measure the usefulness of this list.
So, I took a snapshot at the end of last month, this list was comprised of about 450 entries, and about the 3 sources that I listed on a previous slide. Looking into BGP, I saw that from those, around 450 networks, ASNs, 44% are still visible. So, it seems that well the networks get on this really the bad list of rating, but they are still announced on the Internet.
Going off to ROAs. So currently I measure around that number of ROAs. And looking at the 450 entries, 64 of them are certified. So, this means a 14 percent figure.
Going a bit further, I have looked also at IXP dB, at the other Internet Exchanges, the figure is a bit lower, only 8 percent, but it's interesting also to note that 13 of those 39 that show up on IX PD B are present at multiple Internet Exchanges.
So these are basically my two main questions.
Should we, I moon my network, start dropping routes and incoming packets from these ASNs? So what do you think?
And also, on a more philosophical note, can someone operate the network and services on top of that network if their autonomous system number falls and remains on that list for sometime?
And that's it. I hope to have some someone discuss this at the mic. Thank you.
BRIAN NISBET: Okay. Thank you.
RUDIGER VOLK: Thank you Carlos. Well, okay, I am primarily a routing person and I have spent a lot of time and effort in doing routing security. Now, what you are talking about is, I understand, is essentially you are saying, well, okay, you are taking a source of reputation classification, and that's quite certainly something very different from security.
CARLOS FRIACAS: Well, reputation is a source for applying security?
RUDIGER VOLK: No, no. I am pretty sure most routing persons would say no. This does not look like something to do. The source of information actually has to be very, very finely understood. I haven't done that homework for that Spamhaus list. But kind of, I did not see anything in your considerations that clicked with me like being ‑‑
CARLOS FRIACAS: One of the questions is that 56 percent of that short list don't show up on routing any more. So...
RUDIGER VOLK: Well, I don't know, I don't know why they got there. I know that when I'm looking into the routing tables, I am seeing all kinds of funny stuff. I'm seeing that people are inserting routes with faked origin ASs. I am seeing, I am seeing, I am seeing, AS paths that include AS numbers that are not really valid technically there. I'm seeing, in the RPKI, ROAs for ASNs that should not happen and show up in the public routing. All kinds of strange things happen. Kind of very specifically, because I have been working on the RPKI a lot, I think looking at RPKI and that reputation stuff really, really does not help any, because I know in the RPKI there is authorisation forecasts that are completely invalid. And kind of, it is not really clear what you think you would be doing about ROAs that are there and are authorising bad reputation ASes.
CARLOS FRIACAS: That's a problem for me too.
RUDIGER VOLK: So, kind of, very simple technical statement I think is RPKI and reputation are separate worlds, no clear and useful interaction.
CARLOS FRIACAS: But, this indicator is possibly one of the signs that this kind of blacklist is not fully usable.
RUDIGER VOLK: In some cases having kind of miss matches, it may indicate problems on within side or the other side.
CARLOS FRIACAS: Yeah.
CHAIR: It's very annoying that, I know my colleague Anna is in v6 at the moment because she has been doing some work on some drop stuff and experimenting with on our, not on on transit or otherwise but on some of the internal pieces of the network.
CARLOS FRIACAS: Also one of the questions I have is that, if 50% of this list is not announced, so, the value of dropping also drops. So... but then again, well, if it's 4545 percent now, it can be 30 percent tomorrow and 50%. So this is also ‑‑ well, the problem with this number is it's only a snapshot.
RUDIGER VOLK: Okay. Just consider that a lot of the mall use actually only makes temporary use of certain ASes. And the bad reputation may be attached to that and marked, but, yes, the usage only occurs once in a while.
CARLOS FRIACAS: Okay. Sorry, because you were the only person going to the microphone. But what happens if your ASN gets on to this list? So you'll try to delist it, right?
RUDIGER VOLK: The reputation of that reputation list will go down.
CARLOS FRIACAS: More comments?
BRIAN NISBET: It doesn't look like it. Thank you very much Carlos.
(Applause)
And so, now, we have Guillermo from LACNIC to speak to us about the WARP centre that they have.
GUILLERMO CICIELO: Thank you. Good morning. I work at LACNIC. I am the head of R&D. I will speak about the WARP from LACNIC, but I'm not the, I am not involved with this service, but I will be speaking on behalf of her.
First of all, about LACNIC. We are the RIR for Latin America. We have 33 RIR services, 33 territories, from Mexico to the south. We have based in you're guy and the LACNIC organisation has been set up in 2002. We are responsible of signing IPv4, IPv6 and ASNs and also we are responsible about the reverse DNS for those resources.
What is the WARP? As I said Graciela
Martinez, she is not here unfortunately, she is the head of the WARP, so if you want to have more details about, if you want to know more details about the WARP, you can contact her.
WARP stands for Warning Advice and Reporting Point. It's like an incident response team for dealing with security incidents. The main role of the WARP is coordinating centre, we have the ‑‑ we are like a centre for coordinating incidents between our members, the WARP constituency are LACNIC members and so we act on certain security incidents that are reported to us.
The WARP started as a ‑‑ because we were having many requirements from part of our members about different kinds of incidents, and there were reports that we received and they were processed by us, but we didn't have an incident dealing, an incident report dealing with this.
So, what kind of incidents relationship currently reported to WARP were, as you can see in this graph, most of the incidents are phishing. There are also malware and other kinds of incidents. You can see this in more detail in the link that is below, but we are constantly receiving reports about phishing incidents.
With respect to the regions that originated this kind of incident in this graph, it is seeing that ARIN is one of the most, one of the biggest area of incidents that are reported to us. That is the attacks or the incident originates in ARIN region and our members are reporting that to us.
And the second one is RIPE. But by far, it's ARIN is the region that we would he have more attacks from.
This is a timeline of the phishing reports from other organisations to LACNIC WARP. As you can see, the number various between different parts of the year. And the second one there is malware. The first one is phishing.
The type of incidents managed by WARP, here you have not only the things that are reported by members but also things like for instance open resolver, I will talk a little bit about these. And another kind of incident that we did with them.
With respect to the botnets, those are the more common botnets in our region. As you can see conif I can errand IoT MIRAI are two affecting our region while there are others listed there.
We have been targeted by the phishing and the ‑‑ we had
ASAF SOMEKH: Activities about awareness for our staff because we had this kind of fraud that is happening in our region.
There are some problems where we managed some of this phishing reports, like the GDPR or the WHOIS information or not having the WHOIS information, not having the contact of high level in the WHOIS, so, those are problems that we faced when we tried to contact the organisations. Involved.
And there are a lot of systems out of date that are ‑‑ that are concerning the botnets.
We have a honey net deployed with sensors in many countries. We have the idea of this honey net was to have a first hand ‑‑ a first hand knowledge of the kind of more frequent attacks in the region, and help our constituency with advices and reports about this. And the honeypot is composed of sensors that report on Telnet and SSH, and they are designed to log all the activities then by the attackers.
Well, the active sensors are in those countries listed there, and you can have more information about the project there. This is the project is led by Dario from LACNIC, he is part of the WARP team.
Another project is open resolvers in IPv6. As you all know the open resolvers are a bad thing in the Internet. And we have been receiving a lot of reports about open resolvers in IPv6, so, we started this project between the two RIRs, between WARP and R&D, and how do we do this, how to detect the open resolvers.
Well, LACNIC has one of the name servers authoritative for reverse zones for the reverse DNS zone. So, we get from there the, this name server gets queries from different resolvers, and so we get the list of resolvers that are querying this server. From that we check if they are open or not. With a query for a specific domain and check the answer. If the query fails, it is okay. And if the resolver answers, then it's an open resolver that we ‑‑ we try to contact the organisation and give them recommendations to fix this.
With respect to DHCP hijacking, we also received a lot of reports about this activity and so we tried to contact the originating autonomous system of the hijack. And here, the WARP acts as a coordinating organisation between the two, the affected and the reported organisation. It is very difficult to prove if it is done incorrectly by mistake or it is done intentionally, so, we warn the organisation and contact them to try to solve the problems.
With respect to RPKI, LACNIC operates the RPKI system for their members, their resources. Well, we help our local repository. We work in a hosted mode but we are now working with Nick Brazil, because they are going to deploy RPKI and we are going to use up/down between the two systems.
This is the link to report a security incident in the Latin America region. If you are in the region, you can report an incident, if you are out of the region also, if the incident is coming from our region.
We have a map of CSIRTs in Latin America at the Caribbean. Those are the countries that have currently some CSIRTs. You can click on this map in a country and check the different kind of CSIRTs that are in that country. This is an interactive map. If you go to the page, you can click and you will see how many CSIRTs are in each of those countries.
What else do we do to fight cybercrime? In the WARP, we warn or constituency about the main incidents that are occurring in the region. We have MoU signed with different organisations to exchange information and to guarantee the confidentiality of the information ex exchange. We do a lot of trainings. We have this Amparo training project that is about the computer security and how to build an incident response team, and we have done more than 15 Amparo training and approximately 1,000 professionals have been trained with that.
We organise security conferences in our main meetings, in our events. We have two big meetings per year, and in those meetings we organise security conference for instance first colloquium, first symposium and team similarly.
And we also organise meetings between the different CSIRTs in the region, face‑to‑face meetings, also during those events where the CSIRTs get together in our meetings.
We encourage working in a multistakeholder approach.
That's what I have to say. If you have ‑‑ if you want more information, I can give you more general information, but if you want to know more in detail about the WARP activities, you can contact her here on this e‑mail.
BRIAN NISBET: Thank you very much. So, Jordi? No, Carlos.
CARLOS FRIACAS: Well, thank you for coming and prepending. I recognise you have a lot of stuff provided by LACNIC that we don't have in the RIPE community. So, I really just hope that this community finds resources and the will to build ‑‑ well, let's not say tomorrow or next week or next month, but try to get to the point where you are already now. So, congratulations for the great work you do in LACNIC, in regards to the warning advice and reporting point.
JORDI PALET: Actually, I want to thank you for volunteering to do this talk. I just want to explain, taking Trust Achor that the next slot is somehow open mic. The reason why Carlos and I suggested having a talk on this topic is because we have been working on the BGP hijacking policy proposal, more about the WARP and we understood, as Carlos just said, that this is also interesting for this community and we should work on that. So my point here is, not just a question for you, for all of us, what do we think on this? And it has been said before during the policy proposal presentations, this Working Group is tasked to help the community, and we believe this is helpful. So, opinions on that, if I'm alone, maybe I am taking your hat for a minute.
BRIAN NISBET: I was going to say, so LANIC is 10, 12 years old ‑‑
GUILLERMO CICIELO: It's from 2002.
BRIAN NISBET: But, how long is the WARP?
GUILLERMO CICIELO: The WARP I think is five years.
BRIAN NISBET: And do you know was that an initiative of LACNIC or was it ‑‑ did the community ask for it or how ‑‑
GUILLERMO CICIELO: No, it was more LACNIC initiative but it was based on community demands but not ‑‑ it was more LACNIC.
BRIAN NISBET: I suppose I would echo, and again this is a question worth asking rather than any one of mine is, is is it ‑‑ what are the ‑‑ you know, again one of those things with RIRs, is what the deferences are, why LACNIC has this? Why the NCC doesn't? Is that the right thing? Is it the wrong thing? Again, no opinion here, but, I suppose if there are other opinions in the room as well on that as Jordi says, or indeed questions for goer Mo. All perfectly happy. I mean, is this something that people would find useful in the RIPE region?
RUDIGER VOLK: The ‑‑ well, okay, I am kind of surprised that a member of the global SIRT community out of Europe is reporting that kind of, he doesn't see that his community has provided points of, points for contact and reporting and warning. My assumption actually was that the SIRT community was quite well organised in Europe, but they usually, they usually don't intersect with this community and don't show up in large numbers and contribute to this Working Group as far as I can tell
I'm not really a user of these services, so I cannot tell whether someone who has something to report has an easy and well defined way, but I certainly would appreciate if the SIRT community actually interacts a little bit more.
On the other hand, I also think that division of labour and clear focus of purpose for organisations and communities makes sense, and kind of the detailed incidents follow up and identification and so on is, in my opinion, definitely not on the plate of the registry system. More interaction, more visibility, certainly, very interesting and helpful. But, kind of, I have some ideas why, in Latin America, things worked out this way because the establishment of the LACNIC happened in very different ways from how RIPE was created 30 years ago. And the demands on the people driving the LACNIC were different than what has happened and what is happening in Europe.
BRIAN NISBET: Albeit, and sorry for speaking, and Carlos, absolutely, but this is one of the questions I think for the community. We talk about, you know, what we're doing with the registry, we talk about ‑‑ and again, these are all questions, I'm not espousing any point of view here. What I'm saying is, we have done things here for a long time and for reasons, they are reasons, it doesn't matter whether they are good or bad, it's what has happened. We have now reached a point where what has been the main activity of the NCC for a very long time is obviously a part of that is closing the registry, the maintenance of that is still hugely important and still very valid. I mean, a huge piece of work I'm not saying it's suddenly gone away. I was joking with Marco earlier that the registration services will have it easier, that's obviously a joke and not the truth by any stretch of the imagination. But it's one of those changes, as the world changes and things changes, are there pieces there, and obviously your opinion there is Rudiger is not, but are there pieces there that the NCC should ‑‑ the community should look to the, or the members should look to the NCC to do or not. And as I said, these are questions.
And I suppose it also goes, because I know there are operators, I know there are groups and we have the certs and things like that, some people don't, there are lots and lots I suspect the new LIRs, there is 20,000 or whatever the number is at this point in time, a lot of whom are very small who do not have security people, do not have those things there. A lot of them who are not large established European operators or telcos, of the whatever it was, when Axel started 20 years ago. So that's something to consider. As I said it's something to consider, I am going to go to Carlos now, but just how much is the world changed? How much are the people who have been driving RIPE, the RIPE community, membership for a long time, are their needs reflective of the needs of the 10,000 LIRs we have had in the last two years or whatever the number is?
CARLOS FRIACAS: Well, I know that the RIPE, APNIC, other RIRs, have CSIRTs, but they only account for the RIR infrastructure. What WARP does goes beyond, and that's the big added value I see. When we were working about the hijacking proposal within LACNIC, we were told that in the previous year there were like 15 cases of reported hijacks to LACNIC. So if you try to report an hijack to the RIPE NCC, nobody cares. That's the truth really, because they say RIPE NCC is a registry, go bother someone else.
But, again, picking up on what LACNIC is doing right, they told us like there were 15 reports and they solved 14.
So, I see this as a huge success. 14 people were desperate. They were getting their prefix announced by somebody else and the coordination through LACNIC worked. So... I would like to see the same coordination and help also in this region because our how CSIRTs works is, okay, they cooperate, they exchange information but they primarily watch over their constituency, and the RIPE NCC's constituency is 76 countries. But it's not really the same.
RUDIGER VOLK: I would make ‑‑ well, okay, first of all, I guess if I look in the routing tables and browse through the monitoring systems, I am seeing multiples 15 hijacks per day, and well, okay, kind of that's stuff where I'm very sure that in the end, it cannot be a task for the RIPE NCC to take care of all of that.
A general observation for me, or for me over the years has been that yes, the focus and the expertise and the techniques used by the SIRT community and the routing security problems are kind of very far apart. And so, kind of... I am ‑‑ I can understand that you see that well, okay, when in kind of your community, something is done and successfully, that clicks as a good thing with you. But kind of understanding how routing security can be improved is something that is not easy to get out of how the CSIRTS have been working ‑‑
CARLOS FRIACAS: Just one small point. It's routing security, so you don't do routing security without the routing guys and you also shouldn't do routing security without the security guys. So it should be a mix.
RUDIGER VOLK: Well, okay. Kind of, I have been in the very active in the IETF working on this, and of course we have had with security, we actually were in the security area I think and we always had that in there. But kind of, kind of figuring out ‑‑ well, okay, actually understanding the routing domain is something that's not that easy to get access to and, by the way, there is a lot of stuff that can be done and has to be done there technically that is moving very, very slowly. Like the concept of the RPKI was already done in the previous Millennium, ten years ago we had the essential stuff, so essentially ten years ago we could have already done the RPKIbuff, please do your ROAs ten years ago would be ‑‑ it would have been very early then, but it could have been done and we are moving that slowly, and kind of the improvements and dealing with hijacks, and by the way, I was a little bit surprised that you bothered to figure out whether hijacks are malicious or not. It doesn't matter. You have to actually detect and work on it regardless what the damage is done.
GUILLERMO CICIELO: The thing I said is that's not easy or possible to detect whether it's malicious or not. We only process that and contact the organisation ‑‑
RUDIGER VOLK: And kind of for the actual proceeding in the network operation, it does not matter. It matters for damage claims and it matters for the police. But that's not our first order of thought.
BRIAN NISBET: So, yeah... and I am conscious and thank you for ‑‑ this has gone a little bit away from where we are, I don't know ‑‑ and I know it's not your area, this is possibly and unfair question. Do you think this is something that can be replicated elsewhere?
GUILLERMO CICIELO: I'm not sure in our case this was naturally grown because we had this kind of request from our constituency, from our members that were sending reports and trying to contact other organisations and asking us to do something. Well, we decided to build the WARP. But it was not exactly a proposal of the community, but it was a decision of LACNIC to do this because of the need that there was in the community. So... I don't know if this is the same here. You must decide that.
BRIAN NISBET: That's certainly not as clear. Thank you very much.
So, that is the last of the agenda items. I think there are things to, you know, talk more about, not right now. I'll try and give some of the time we stole from you in Reykjavik back to you here in Rotterdam. But I think there is things to consider there. I think there is ‑‑ you know we do know rapidly changing world we live in, and whether it is policies or not and obviously there is some there for discussion, whether it is things like WARP, whether it is more coordination, whether there is something about, you know, about all of these things or whether we continue in our course in the Plenary and part of this is me exhorting people to engage in things like the Community Plenary this afternoon in this room, where things like the task force in relation to the registry that Peter mentioned will be talked about and a number of other things.
Just to engage in those, to look at it and to go, ask that question. It's always worth asking the question, but certainly as we come to the end of another decade as linear time seems to speed up is to ask what we're doing the right thing? Are there other things we could be doing? Are there other ways of looking at things? Are the way we have worked for the last 30 years in the community, it's been changed in the time I have been involved, which is about half of that now, but is it the right thing? Are there other things we can do? This is always a good thing to ask and a good thing to check in on.
I was about to ask for AOB. But Rudiger?
RUDIGER VOLK: Let me contribute one point. You made remarks, well, okay, lots of small entities have joined the RIPE NCC and are around, and I would like to air the question, what this Working Group has been done to provide help to those.
BRIAN NISBET: That's an excellent question. I think it's fair to say, and you know, obviously, it's not on the co‑chairs to do all the work, I know you're not suggesting that. But, there's been some things, but not enough. We talk about the documentation, we talk about that, it certainly dust exist, but like every Working Group in the RIPE community, it needs people to do that work to write that documentation. So people are very active. There is a lot of really good information and experience out there that the Working Group, this Working Group and every other Working Group in the RIPE community can massively benefit from and I would ask that question. It's part of the charter of this Working Group as well and raise that challenge to people about, yes, how are we, and bear in mind this community, 800 members at the meeting, lots of people on the mailing list, but still very much slanted towards the larger western and north western European ISPs and operators and things like that, what are we doing in relation to passing on information to making sure people don't have to reinvent the wheel or relearn things or otherwise, as the world changes and as government and regulators and LEAs and everything else look more closely at our operations because the thing that we run, that thing that we patch together with policy and hope and tape becomes ‑‑ has become, it has become, is one of the most important utilities that humanity takes advantage of at the moment. And I think I am going to stop there. It's ‑‑ these are considerations and hopefully things we can look at into the future on the mailing list at other meetings about how people can help. About documentation we can write, the how tos, all of these things, which may be useful for both ourselves and others, and I think you know, to make sure that we're not saying well the CIRTS are doing that or some other group is doing that. But to do it ourselves as well.
So with all of that in mind, is there any other business? No?
In which case, I would say please think about these sort of things, about these things as an agenda item for our next meeting in Berlin in May. I would like to thank everyone who contributed today. Thank you all of you for coming, co‑chair, and thank you all.
And as I said, the Community Plenary this afternoon which I would exort you to look at and also obviously PC elections which we have six people, which I need to mention as a member thereof, so please vote, and we will see you all in Berlin. Thank you all very much.
(Applause)
(Coffee break)
LIVE CAPTIONING BY
MARY McKEON, RMR, CRR, CBC
DUBLIN, IRELAND.
