From mir at ripe.net Tue Jul 6 11:51:20 2010 From: mir at ripe.net (Mirjam Kuehne) Date: Tue, 06 Jul 2010 11:51:20 +0200 Subject: [anti-abuse-wg] Economic incentives for more cooperation in fighting spam (new article on RIPE Labs) Message-ID: <4C32FC98.3030200@ripe.net> Dear colleagues, John S. Quarterman and his team at the University of Texas is advocating more cooperation in fighting spam. They are building models for economic incentives for Internet mail providers. Read more on RIPE Labs: http://labs.ripe.net/content/cooperation-to-fight-spam The team is very interested to receive feedback from the RIPE community. Please note at the end of the article a list of specific questions and a forum we set up for further discussion. Kind Regards, Mirjam K?hne RIPE NCC From peter at hk.ipsec.se Tue Jul 6 23:17:25 2010 From: peter at hk.ipsec.se (peter h) Date: Tue, 6 Jul 2010 23:17:25 +0200 Subject: [anti-abuse-wg] Economic incentives for more cooperation in fighting spam (new article on RIPE Labs) In-Reply-To: <4C32FC98.3030200@ripe.net> References: <4C32FC98.3030200@ripe.net> Message-ID: <201007062317.26456.peter@hk.ipsec.se> On Tuesday 06 July 2010 11.51, Mirjam Kuehne wrote: > Dear colleagues, > > John S. Quarterman and his team at the University of Texas is advocating > more cooperation in fighting spam. They are building models for economic > incentives for Internet mail providers. Read more on RIPE Labs: > > http://labs.ripe.net/content/cooperation-to-fight-spam > > The team is very interested to receive feedback from the RIPE community. > Please note at the end of the article a list of specific questions and a > forum we set up for further discussion. > > Kind Regards, > Mirjam K?hne > RIPE NCC > > Nice initiative! RIPE could start with reorganizing it's lame anti-abuse group to a more specific anti-spam working group and start propagating already known facts to it's "customers". Such as "best practices for running broadband networks" or "securing mobile networks against spam" An active campain directed to all ripe "users" would be a good starting point, educating and spreading recepies of successful ways to prevent customers windows-computers of becoming spam-senders. This could be followed-up with statistics that pinpoints "sleazy ISP's" and lobbying with politicans to sharpen the lame legal tools that is available. In sweden as an example, it has been illegal since several years to send spam, but the only person that is assigned this task has ( to my knowledge ) not convicted a single spammer. I even have examples of so called it-security companies that has been sending spam for 3 ye?rs ( using stolen or harvested addresses) We need to take the spam-problem seriously. It hurts out ability to use email, it steals our time and ressources. And it's a channel to even more serious crime. Ant now! -- Peter H?kanson There's never money to do it right, but always money to do it again ... and again ... and again ... and again. ( Det ?r billigare att g?ra r?tt. Det ?r dyrt att laga fel. ) From fm-lists at st-kilda.org Wed Jul 7 01:09:33 2010 From: fm-lists at st-kilda.org (Fearghas McKay) Date: Wed, 07 Jul 2010 00:09:33 +0100 Subject: [anti-abuse-wg] Economic incentives for more cooperation in fighting spam (new article on RIPE Labs) In-Reply-To: <201007062317.26456.peter@hk.ipsec.se> References: <4C32FC98.3030200@ripe.net> <201007062317.26456.peter@hk.ipsec.se> Message-ID: <4C33B7AD.3060509@st-kilda.org> Peter On 06/07/2010 22:17, peter h wrote: > RIPE could start with reorganizing it's lame anti-abuse group to a more specific anti-spam > working group and start propagating already known facts to it's "customers". It looks like you are confusing the RIPE NCC with the RIPE Community. If you want to reorganise the WG then you should put proposals to the community, not rant at a post fron an NCC staffer about work being done in the NCC labs. If you have formal proposals about the way forward for the Anti-Abuse WG then the community and the WG Chairs would like to hear them so that they can be developed and progressed. Remember the RIPE NCC !== The RIPE Community f From brian.nisbet at heanet.ie Wed Jul 7 13:43:19 2010 From: brian.nisbet at heanet.ie (Brian Nisbet) Date: Wed, 07 Jul 2010 12:43:19 +0100 Subject: [anti-abuse-wg] Economic incentives for more cooperation in fighting spam (new article on RIPE Labs) In-Reply-To: <201007062317.26456.peter@hk.ipsec.se> References: <4C32FC98.3030200@ripe.net> <201007062317.26456.peter@hk.ipsec.se> Message-ID: <4C346857.8090900@heanet.ie> Peter, "peter h" wrote the following on 06/07/2010 22:17: > > RIPE could start with reorganizing it's lame anti-abuse group to a more specific anti-spam > working group and start propagating already known facts to it's "customers". I'm very sorry that you feel that way about the working group but hopefully I can address some of your points. First off, as Fearghas has already pointed out, RIPE doesn't have any customers. The RIPE NCC has members, but the RIPE community, of which the AA-WG is a part has none. I suspect "participants" is the best word to use. At RIPE 55 it was agreed by the community that to focus on spam at this point was the wrong way to tackle the problem and so the group changed, both in name and charter, to become what it is now. I do not believe there is any strong feeling in the community to reverse that decision, nor do I think there is any organisational or technical reason to do so. > Such as "best practices for running broadband networks" or "securing mobile networks against spam" The RIPE 409 document, while in need of updating, exists and more documentation is planned. Of course all of this will be produced by the community and we would welcome your input, especially if all of these facts are known. > An active campain directed to all ripe "users" would be a good starting point, educating > and spreading recepies of successful ways to prevent customers windows-computers of > becoming spam-senders. > > This could be followed-up with statistics that pinpoints "sleazy ISP's" and lobbying > with politicans to sharpen the lame legal tools that is available. This is a lot of work, disregarding the ambiguity over the idea of a RIPE "user". It's also substantially more complicated than it may at first seem. The RIPE NCC, assisted by various members of the community, are already engaging with governments and LEAs around the world to educate, advise and to improve the experience for all Internet citizens. However if there are further activities that the members of the RIPE NCC feel they should pursue, these matters should be raised to the NCC and ultimately agreed by the membership. > We need to take the spam-problem seriously. It hurts out ability to use email, it steals > our time and ressources. And it's a channel to even more serious crime. Trust me, Richard and I as co-chairs of the WG and the good folks in the NCC, along with the community participants, take the problem of spam and all network abuse extremely seriously. We are always happy to talk about any initiatives that anyone may have to ease this issue, but such discussions are always easier once as much disambiguation and clarification as possible has taken place. Regards, Brian Co-chair, RIPE Anti-Abuse WG From richard.cox at btuser.net Thu Jul 8 10:16:56 2010 From: richard.cox at btuser.net (Richard Cox) Date: Thu, 08 Jul 2010 08:16:56 +0000 Subject: [anti-abuse-wg] Economic incentives for more cooperation in fighting spam (new article on RIPE Labs) In-Reply-To: <4C346857.8090900@heanet.ie> Message-ID: Brian Nisbet wrote: > At RIPE 55 it was agreed by the community that to focus on spam at this > point was the wrong way to tackle the problem and so the group changed, > both in name and charter, to become what it is now. I do not believe > there is any strong feeling in the community to reverse that decision, > nor do I think there is any organisational or technical reason to do so. I fully endorse that view, and everything else Brian wrote. > The RIPE NCC has members, but the RIPE community, of which the AA-WG > is a part has none. I suspect "participants" is the best word to use. I think what Peter meant there, was Internet users in the RIPE service region. Of which "participants" are, sadly, no more than a small subset. The point of the name-change was that we can no longer separate "pure" spam from the many other abusive activities that are needed to enable it, while spam itself is the conduit for other abusive and criminal activity. In other words, e-crime and abuse has become a self-sustaining eco-system. Since the AAWG membership elected Brian and myself as co-chairs, we have been working hard to identify what changes will need to take place for the RIPE community to become more pro-active in the fight against spam. Initially we found that there was a need for more (and more complete) information about the problem. So we have worked to bring to the AAWG workshops at the RIPE meetings, reports on the present threat level, and presentations from specialists in the community dealing with particular aspects of abuse. This will lay the foundations for what we need to do next - which I see as falling into two categories: (a) major rework on published documents such as RIPE 409 (and possibly the creation of new documents) to establish what actions are needed within the community to mitigate the threat from spam and malware. (b) introducing proposals (within the RIPE Policy Development Process) to make such adjustments as are needed in terms of how the community should manage its resources and information. I introduced some of those ideas during the meeting in Prague, hoping for some feedback from that audience on the relevance and deliverability of the ideas. Now we need to get started on the formal part of the processes. This will be the tricky bit. Almost everyone (except abusers) agrees that abuse needs to stop - but when it is pointed out that achieving that would involve changes in how each of them currently operates (and that in many cases requires resources and expenditure) their enthusiasm for "stopping spam" tends to rapidly diminish. We will have to see just how willing the RIPE community would be, to make the changes that are essential in order to reduce the prevalence of abuse. But in terms of resource abuse it's become clear that the RIPE community is seen as having rather more issues than any of the other regional communities. Let me be clear on one point: there are only two ways to stop spam and abuse: one is to make the cost and (perceived) risk to anyone sending spam or committing abuse, exceed the profits/benefits from so doing, and the other is to switch off the internet. -- Richard Cox The Other Co-chair, RIPE Anti-Abuse WG From michele at blacknight.ie Thu Jul 8 10:56:15 2010 From: michele at blacknight.ie (Michele Neylon :: Blacknight) Date: Thu, 8 Jul 2010 08:56:15 +0000 Subject: [anti-abuse-wg] Economic incentives for more cooperation in fighting spam (new article on RIPE Labs) In-Reply-To: References: Message-ID: On 8 Jul 2010, at 09:16, Richard Cox wrote: > Brian Nisbet wrote: > >> At RIPE 55 it was agreed by the community that to focus on spam at this >> point was the wrong way to tackle the problem and so the group changed, >> both in name and charter, to become what it is now. I do not believe >> there is any strong feeling in the community to reverse that decision, >> nor do I think there is any organisational or technical reason to do so. > > I fully endorse that view, and everything else Brian wrote. > >> The RIPE NCC has members, but the RIPE community, of which the AA-WG >> is a part has none. I suspect "participants" is the best word to use. > > I think what Peter meant there, was Internet users in the RIPE service > region. Of which "participants" are, sadly, no more than a small subset. > > The point of the name-change was that we can no longer separate "pure" > spam from the many other abusive activities that are needed to enable it, > while spam itself is the conduit for other abusive and criminal activity. > In other words, e-crime and abuse has become a self-sustaining eco-system. Very true Abuse of all types is interconnected. Mr Michele Neylon Blacknight Solutions Hosting & Colocation, Brand Protection ICANN Accredited Registrar http://www.blacknight.com/ http://blog.blacknight.com/ http://blacknight.mobi/ http://mneylon.tel Intl. +353 (0) 59 9183072 US: 213-233-1612 UK: 0844 484 9361 Locall: 1850 929 929 Direct Dial: +353 (0)59 9183090 Twitter: http://twitter.com/mneylon ------------------------------- Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty Road,Graiguecullen,Carlow,Ireland Company No.: 370845 From peter at hk.ipsec.se Thu Jul 8 17:43:05 2010 From: peter at hk.ipsec.se (peter h) Date: Thu, 8 Jul 2010 17:43:05 +0200 Subject: [anti-abuse-wg] Spam costs are huge! Message-ID: <201007081743.05819.peter@hk.ipsec.se> To understand the size of the problem i will compare the loss in man-days of a terr?rist attack ( 9/11 ) with the loss of human time spam causes : 2100 lifes, est remaining lifettime 40 years will ad up to 30660000 man-days 5 spam per day, each taking 1 s of our time, this for 1 billion ( 1000000000 ) users will cost 21122685.5 mandays per year! I do not mean to reduce the impact of several thousend deat's, thats a huge number of tragic events. But we loose about the same amount of time dealing with spam IN ONE YEAR as the total loss of human time for all these victims ! How much effort is spent on terror-fighting ? How much is spent on spam-fighting ? Which will give us back the most time ? We need, in my opinion, to see the real size of the spam-problem and accept that we all need to contribute to eleminate the problem. Not just talk. Suggestions ? -- Peter H?kanson There's never money to do it right, but always money to do it again ... and again ... and again ... and again. ( Det ?r billigare att g?ra r?tt. Det ?r dyrt att laga fel. ) From fweimer at bfk.de Wed Jul 14 14:28:34 2010 From: fweimer at bfk.de (Florian Weimer) Date: Wed, 14 Jul 2010 12:28:34 +0000 Subject: [anti-abuse-wg] Abuse Contact Information - Policy Proposal In-Reply-To: <4BDE819B.1050608@abusix.com> (Tobias Knecht's message of "Mon\, 03 May 2010 09\:56\:11 +0200") References: <4BDE819B.1050608@abusix.com> Message-ID: <82eif6qmbx.fsf@mid.bfk.de> * Tobias Knecht: > 4.1 Institute a mandatory reference to an IRT object in inetnum, > inet6num and aut-num objects. So it seems to me that one particular problem is that the abuse-mailbox data is not available in the bulk database dumps, and neither are the IRT objects. Wouldn't it be easier if RIPE created person/role object dumps, containing only the nic-hdl and the abuse-mailbox field? IRT object dumps would make a lot of sense, too. Historically, IRT objects had significant organizational overhead and have been subject to politics, so I'm not sure if they are the proper answer. -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra?e 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From tk at abusix.org Wed Jul 14 15:41:54 2010 From: tk at abusix.org (Tobias Knecht) Date: Wed, 14 Jul 2010 15:41:54 +0200 Subject: [anti-abuse-wg] Abuse Contact Information - Policy Proposal In-Reply-To: <82eif6qmbx.fsf@mid.bfk.de> References: <4BDE819B.1050608@abusix.com> <82eif6qmbx.fsf@mid.bfk.de> Message-ID: <4C3DBEA2.2070403@abusix.org> Hi, >> 4.1 Institute a mandatory reference to an IRT object in inetnum, >> inet6num and aut-num objects. > > So it seems to me that one particular problem is that the > abuse-mailbox data is not available in the bulk database dumps, > and neither are the IRT objects. I fully agree with the description of the problem. The biggest problem is, that RIPE is not telling their members which is the right way to publish abuse contact information and not telling them that they have to publish those information. And I disagree completely the opinion of not having any mandatory email addresses in the whois information. IMHO as long as an IP address can be abused, there must be a point of contact. The second problem is the query restriction. RIPE has more than 2 million inet(6)nums and it is absolutely impossible to query for the single IP addresses. Even with caching it is absolutely not possible. The idea to offer an abuse finder (http://labs.ripe.net/content/abuse-finder) is good and we will try that out soon. > Wouldn't it be easier if RIPE created person/role object dumps, > containing only the nic-hdl and the abuse-mailbox field? IRT object > dumps would make a lot of sense, too. I think RIPE shuts down the Bulk Data Service because of Privacy issues. So that might not be the right way. > Historically, IRT objects had significant organizational overhead and > have been subject to politics, so I'm not sure if they are the proper > answer. I know, but IMHO it does not make sense to create something new again. The mandatory IRT Object would solve almost all of those problems. Why is that? If you create an IRT Object with an abuse-mailbox attribute you can query the range or the single address with the "-b" flag which is not query restricted as far as RIPE told me. Use the Example of IRT-MCI-NL (whois -h whois.ripe.net IRT-MCI-NL) They have an abuse-mailbox attribute. So I can query: whois -h whois.ripe.net 193.67.0.0/16 -b whois -h whois.ripe.net 193.67.0.1 -b whois -h whois.ripe.net IRT-MCI-NL -b whois -h whois.ripe.net ASXXXX -b (would be possible I guess) and I always get back the abuse-mailbox attribute. That way everybody can build a caching system, that uses all the IRT Object found in the split files and connects them to the found abuse-mailbox attributes. And the second pro argument is, that the IRT Object allows to publish an e-mail attribute for personal communication. The query restriction forces us to send messages to the wrong contact, because we are not able to get the subdelegation contact because of the query restrictions. The arguments against are clear as well. So the decision must be done by RIPE and their members. APNIC did the decision and they will go online with the mandatory IRT Object in November. At the end I would be even happy if RIPE could agree on a Best Practice Paper which tells their members to use the IRT Object in the explained way to offer abuse contact information and stops creating of abuse-mailbox attributes in non IRT-Objects. With a Best Practice like that, everybody could easily reference on that without getting in discussions about the right way of doing it. Thanks, Tobias From fweimer at bfk.de Wed Jul 14 15:52:42 2010 From: fweimer at bfk.de (Florian Weimer) Date: Wed, 14 Jul 2010 13:52:42 +0000 Subject: [anti-abuse-wg] Abuse Contact Information - Policy Proposal In-Reply-To: <4C3DBEA2.2070403@abusix.org> (Tobias Knecht's message of "Wed\, 14 Jul 2010 15\:41\:54 +0200") References: <4BDE819B.1050608@abusix.com> <82eif6qmbx.fsf@mid.bfk.de> <4C3DBEA2.2070403@abusix.org> Message-ID: <828w5enpat.fsf@mid.bfk.de> * Tobias Knecht: >> Wouldn't it be easier if RIPE created person/role object dumps, >> containing only the nic-hdl and the abuse-mailbox field? IRT object >> dumps would make a lot of sense, too. > > I think RIPE shuts down the Bulk Data Service because of Privacy issues. > So that might not be the right way. What? Even for the inetnum objects? Can you provide a pointer for that, please? > whois -h whois.ripe.net IRT-MCI-NL -b I would expect that query type to be subject to rate limits as well. And when every network block needs an IRT object, some people will likely script the creation of it, so you end up with less caching. -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra?e 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From denis at ripe.net Wed Jul 14 16:10:54 2010 From: denis at ripe.net (Denis Walker) Date: Wed, 14 Jul 2010 16:10:54 +0200 Subject: [anti-abuse-wg] Abuse Contact Information - Policy Proposal In-Reply-To: <82eif6qmbx.fsf@mid.bfk.de> References: <4BDE819B.1050608@abusix.com> <82eif6qmbx.fsf@mid.bfk.de> Message-ID: <4C3DC56E.8000508@ripe.net> Florian Weimer wrote: > * Tobias Knecht: > > >> 4.1 Institute a mandatory reference to an IRT object in inetnum, >> inet6num and aut-num objects. >> > > So it seems to me that one particular problem is that the > abuse-mailbox data is not available in the bulk database dumps, > and neither are the IRT objects. > > Wouldn't it be easier if RIPE created person/role object dumps, > containing only the nic-hdl and the abuse-mailbox field? IRT object > dumps would make a lot of sense, too. > > Historically, IRT objects had significant organizational overhead and > have been subject to politics, so I'm not sure if they are the proper > answer. > > Dear Florian Weimer Bulk access is always problematic where personal data is involved. You are correct that we do not provide dump files for PERSON and ROLE objects or for MNTNER objects which also have the possibility for "abuse-mailbox:" attributes. Within the next week or so we will be putting a new release of the software into production that creates these dump files. In this we have had to extend the restriction of bulk data access by removing NIC Handle references. This is because NIC Handles are regarded as personal data in Dutch law. So we would not be able to create a file as you suggested. But we will provide the dump file for IRT objects. It should also be remembered that IRT objects were introduced for a specific purpose that required additional administrative overhead. That purpose is still valid today and some of that overhead still applies to these objects. But it is not all bad news. We have an Abuse Finder Tool. This is still in a pre-production phase and is described on RIPE Labs: http://labs.ripe.net/content/updated-heuristics-abuse-finder-service This service will find "abuse-mailbox:" attributes and related IRT objects and "remarks:" attributes that 'look like' they contain a reference to an abuse handler for any specified Internet resource. This service currently works for RIPE and APNIC resources. To a limited extent it also works with AfriNIC's data, but they don't use IRT objects or "abuse-mailbox:" so it can only look for "remarks:". This service does not return any personal data other than abuse contacts. Therefore it is not subject to any access control limits. The tool provides 'on demand' access to abuse contacts as many times as you wish. This reduces, or in many cases eliminates, the need for access to bulk data. Regards Denis Walker Business Analyst RIPE NCC Database Group From denis at ripe.net Wed Jul 14 16:21:50 2010 From: denis at ripe.net (Denis Walker) Date: Wed, 14 Jul 2010 16:21:50 +0200 Subject: [anti-abuse-wg] Abuse Contact Information - Policy Proposal In-Reply-To: <828w5enpat.fsf@mid.bfk.de> References: <4BDE819B.1050608@abusix.com> <82eif6qmbx.fsf@mid.bfk.de> <4C3DBEA2.2070403@abusix.org> <828w5enpat.fsf@mid.bfk.de> Message-ID: <4C3DC7FE.60900@ripe.net> Florian Weimer wrote: > * Tobias Knecht: > > >>> Wouldn't it be easier if RIPE created person/role object dumps, >>> containing only the nic-hdl and the abuse-mailbox field? IRT object >>> dumps would make a lot of sense, too. >>> >> I think RIPE shuts down the Bulk Data Service because of Privacy issues. >> So that might not be the right way. >> > > What? Even for the inetnum objects? Can you provide a pointer for > that, please? > > Just to clarify this point, the RIPE NCC has no plans to shut down bulk access to operational data. The only restrictions are regarding personal and security data. There will be no bulk access to PERSON, ROLE, ORGANISATION or MNTNER objects. In other objects types NIC Handle references will also be removed from the bulk access data. Regards Denis Walker Business Analyst RIPE NCC Database Group >> whois -h whois.ripe.net IRT-MCI-NL -b >> > > I would expect that query type to be subject to rate limits as well. > And when every network block needs an IRT object, some people will > likely script the creation of it, so you end up with less caching. > > From tk at abusix.org Wed Jul 14 16:19:42 2010 From: tk at abusix.org (Tobias Knecht) Date: Wed, 14 Jul 2010 16:19:42 +0200 Subject: [anti-abuse-wg] Abuse Contact Information - Policy Proposal In-Reply-To: <828w5enpat.fsf@mid.bfk.de> References: <4BDE819B.1050608@abusix.com> <82eif6qmbx.fsf@mid.bfk.de> <4C3DBEA2.2070403@abusix.org> <828w5enpat.fsf@mid.bfk.de> Message-ID: <4C3DC77E.9080302@abusix.org> Am 14.07.2010 15:52, schrieb Florian Weimer: > * Tobias Knecht: > >>> Wouldn't it be easier if RIPE created person/role object dumps, >>> containing only the nic-hdl and the abuse-mailbox field? IRT object >>> dumps would make a lot of sense, too. >> >> I think RIPE shuts down the Bulk Data Service because of Privacy issues. >> So that might not be the right way. > > What? Even for the inetnum objects? Can you provide a pointer for > that, please? http://ripe.net/ripe/maillists/archives/db-wg/2010/msg00063.html The inet(6)num Split Files contain all the Handles. But IRT Objects are defined as personal data, that way there is just a dummy split file. >> whois -h whois.ripe.net IRT-MCI-NL -b > > I would expect that query type to be subject to rate limits as well. Database Documentation and testing tells me that there is no limit. > And when every network block needs an IRT object, some people will > likely script the creation of it, so you end up with less caching. How about making the IRT Object only mandatory for the direct allocations? That way we would have at least one abuse contact per IP. And the Netrange owner can decide if he wants to receive the complaints and if not he can create an irt for his subdelegations. Less caching does not hurt as long as the rate limits are not existing. Thanks, Tobias From tk at abusix.org Thu Jul 15 15:08:36 2010 From: tk at abusix.org (Tobias Knecht) Date: Thu, 15 Jul 2010 15:08:36 +0200 Subject: [anti-abuse-wg] Abuse Contact Information - Policy Proposal In-Reply-To: <4C3DC56E.8000508@ripe.net> References: <4BDE819B.1050608@abusix.com> <82eif6qmbx.fsf@mid.bfk.de> <4C3DC56E.8000508@ripe.net> Message-ID: <4C3F0854.4050301@abusix.org> Hello again, > But it is not all bad news. We have an Abuse Finder Tool. This is still > in a pre-production phase and is described on RIPE Labs: > http://labs.ripe.net/content/updated-heuristics-abuse-finder-service > > This service will find "abuse-mailbox:" attributes and related IRT > objects and "remarks:" attributes that 'look like' they contain a > reference to an abuse handler for any specified Internet resource. This > service currently works for RIPE and APNIC resources. To a limited > extent it also works with AfriNIC's data, but they don't use IRT objects > or "abuse-mailbox:" so it can only look for "remarks:". > > This service does not return any personal data other than abuse > contacts. Therefore it is not subject to any access control limits. The > tool provides 'on demand' access to abuse contacts as many times as you > wish. This reduces, or in many cases eliminates, the need for access to > bulk data. I really love it. This is a really good idea and this might help a lot. BUT: (sorry I have to ;-) I found out a few things: At the moment the XML Webservice is restricted. I was just trying to penetrate that service a little bit and it shut down after about 15 minutes of excessive usage. The service might be a little slow to use it without local caching. But I think that will change in future and with the "real" API. And last but not least the problem all RIRs have and such a great thing as the Abuse Finder will not solve the integrity and correctness (not accuracy). I have done a test, I was using all 4791 (/8 up to /16) ranges from the RIPE Database and shot them into the Abuse Finder. 2616 did have a results, which is around 54% 2175 did not have any result, which is around 45% That problem should be addresses as well. Probably with a Best Practice Paper. At the end there are some questions about data output. For example: 134.61.0.0/16 This range is giving back 2 different addresses. That is absolutely correct, but does it make sense? This will lead again to frustration of not knowing which is the right place and correct way to publish abuse related data. So I'm still a big fan of the IRT Object, because it is tailor made and solves all those problems. And probably once there will be a time, were it is not necessary to offer abuse-mailbox attributes for any other objects than the IRT and not necessary to use remark fields for abuse contact publishing and at that time it is not needed to do up to 150 queries for one request at the Abuse Finder. Thanks Tobias From fweimer at bfk.de Fri Jul 23 10:25:05 2010 From: fweimer at bfk.de (Florian Weimer) Date: Fri, 23 Jul 2010 08:25:05 +0000 Subject: [anti-abuse-wg] Abuse Contact Information - Policy Proposal In-Reply-To: <4C3DC7FE.60900@ripe.net> (Denis Walker's message of "Wed\, 14 Jul 2010 16\:21\:50 +0200") References: <4BDE819B.1050608@abusix.com> <82eif6qmbx.fsf@mid.bfk.de> <4C3DBEA2.2070403@abusix.org> <828w5enpat.fsf@mid.bfk.de> <4C3DC7FE.60900@ripe.net> Message-ID: <82fwzappum.fsf@mid.bfk.de> * Denis Walker: > Just to clarify this point, the RIPE NCC has no plans to shut down bulk > access to operational data. The only restrictions are regarding personal > and security data. There will be no bulk access to PERSON, ROLE, > ORGANISATION or MNTNER objects. In other objects types NIC Handle > references will also be removed from the bulk access data. NIC handles are operational data for many of us who need to contact operators to address issues we encounter and make the Internet a better place for everyone. I'm disappointed that RIPE NCC plans to take things into that direction. Was this project prompted by requests from the membership? At the very least, you could introduce an opt-in flag so that we can agree to have our data published in bulk form, so that we can benefit from others willing to help us to keep our networks clean. -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra?e 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From ripe-anti-spam-wg at powerweb.de Fri Jul 23 10:42:31 2010 From: ripe-anti-spam-wg at powerweb.de (Frank Gadegast) Date: Fri, 23 Jul 2010 10:42:31 +0200 Subject: [anti-abuse-wg] Abuse Contact Information - Policy Proposal In-Reply-To: <82fwzappum.fsf@mid.bfk.de> References: <4BDE819B.1050608@abusix.com> <82eif6qmbx.fsf@mid.bfk.de> <4C3DBEA2.2070403@abusix.org> <828w5enpat.fsf@mid.bfk.de> <4C3DC7FE.60900@ripe.net> <82fwzappum.fsf@mid.bfk.de> Message-ID: <4C4955F7.6040708@powerweb.de> Florian Weimer wrote: > * Denis Walker: > >> Just to clarify this point, the RIPE NCC has no plans to shut down bulk >> access to operational data. The only restrictions are regarding personal >> and security data. There will be no bulk access to PERSON, ROLE, >> ORGANISATION or MNTNER objects. In other objects types NIC Handle >> references will also be removed from the bulk access data. > > NIC handles are operational data for many of us who need to contact > operators to address issues we encounter and make the Internet a > better place for everyone. > > I'm disappointed that RIPE NCC plans to take things into that > direction. Was this project prompted by requests from the membership? > > At the very least, you could introduce an opt-in flag so that we can > agree to have our data published in bulk form, so that we can benefit > from others willing to help us to keep our networks clean. > Hi, we are voting for abuse data in bulk form too. We need nothing else but a simple dump from RIPEs abuse finder tool containing the netblock and the abuse email address. I personally dont think that this data could be declared as personal data, that needs to be protected by law. The netblock owner already decided explicitly to publish this (usually in remark fields or the optional abuse-email-field. If this is "too redical" I also recommend a simply flag in the LIR portal anybody could select. [x] publish abuse data in bulk form Kind regards, Frank -- PHADE Software - PowerWeb http://www.powerweb.de Inh. Dipl.-Inform. Frank Gadegast mailto:frank at powerweb.de Schinkelstrasse 17 fon: +49 33200 52920 14558 Nuthetal OT Rehbruecke, Germany fax: +49 33200 52921 ====================================================================== Public PGP Key available for frank at powerweb.de From denis at ripe.net Fri Jul 23 15:32:29 2010 From: denis at ripe.net (Denis Walker) Date: Fri, 23 Jul 2010 15:32:29 +0200 Subject: [anti-abuse-wg] Abuse Contact Information - Policy Proposal In-Reply-To: <82fwzappum.fsf@mid.bfk.de> References: <4BDE819B.1050608@abusix.com> <82eif6qmbx.fsf@mid.bfk.de> <4C3DBEA2.2070403@abusix.org> <828w5enpat.fsf@mid.bfk.de> <4C3DC7FE.60900@ripe.net> <82fwzappum.fsf@mid.bfk.de> Message-ID: <4C4999ED.5030505@ripe.net> Dear Florian, This is an issue that was raised by the lawyers to the RIPE Data Protection Task Force. After consideration by the Task Force a recommendation was put to the RIPE Database Working Group. There is a reference to this in the RIPE NCC presentation to the RIPE 59 meeting in Lisbon http://www.ripe.net/ripe/meetings/ripe-59/archives.php?day=thursday The bulk access daily split files still make available all the operational data. If, after processing that data, you need the personal data for a specific object you can query the RIPE Database for that object and return the personal data or just the references to it. With the current design of the RIPE Database there is no way to have any opt in methods for personal data. The RIPE NCC has no relationship with most of the people referenced by PERSON objects. RPSL does not provide any means of distinguishing between PERSON objects for network administrators and PERSON objects related to end user customer data. Nor does it provide any means to gather, verify and store such opt in approval. Regards Denis Walker Business Analyst RIPE NCC Database Group Florian Weimer wrote: > * Denis Walker: > > >> Just to clarify this point, the RIPE NCC has no plans to shut down bulk >> access to operational data. The only restrictions are regarding personal >> and security data. There will be no bulk access to PERSON, ROLE, >> ORGANISATION or MNTNER objects. In other objects types NIC Handle >> references will also be removed from the bulk access data. >> > > NIC handles are operational data for many of us who need to contact > operators to address issues we encounter and make the Internet a > better place for everyone. > > I'm disappointed that RIPE NCC plans to take things into that > direction. Was this project prompted by requests from the membership? > > At the very least, you could introduce an opt-in flag so that we can > agree to have our data published in bulk form, so that we can benefit > from others willing to help us to keep our networks clean. > > From richard.cox at btuser.net Fri Jul 23 15:43:25 2010 From: richard.cox at btuser.net (Richard Cox) Date: Fri, 23 Jul 2010 13:43:25 +0000 Subject: [anti-abuse-wg] Abuse Contact Information - Policy Proposal In-Reply-To: <82fwzappum.fsf@mid.bfk.de> Message-ID: Florian Weimer schrieb: > NIC handles are operational data for many of us who need to contact > operators to address issues we encounter and make the Internet a better > place for everyone. > > I'm disappointed that RIPE NCC plans to take things into that direction. I concur 100%. > Was this project prompted by requests from the membership? A more-specific question would be, was this policy change authorised by any decision reached by means of the RIPE Policy Development Process? If so, can we please be given a reference to the documentation? > At the very least, you could introduce an opt-in flag so that we can > agree to have our data published in bulk form, so that we can benefit > from others willing to help us to keep our networks clean. Contact information would only ever contain personal information if the person submitting the information chooses to utilise a personal mailbox rather than a role-account. I am reachable by email at abuse at btuser.net or richard.cox at btuser.net; only one of those constitutes personal data. It is my choice which I use in any given scenario. One size does not always fit all, so I'm not saying that because that works for me it should be imposed for everybody. What I am saying is that it provides a path forward. Perhaps the AAWG should at last dust off the policy-development process manuals and find out how we can DO something instead of just talking about it. It is just as valid for the AAWG to create a RIPE policy using that process, as it is for any of the other RIPE working groups to do so. My personal thinking goes something like this: Any entity which holds either an ASN, or an IP address range obtained DIRECTLY from RIPE or from an LIR, should be required by policy to provision an abuse mailbox; we should also recommend that such an abuse mailbox be in the form of a role account rather than an individual's mailbox. The same policy could also be applied to any sub-assignment greater than /25 (IPv4) or larger (and a similar figure should be chosen for IPv6 address blocks). That abuse mailbox should be included in all RIPE data elements, no matter how they are delivered. There is another strategy, which I have suggested before, which is that abuse (and possibly other contact) mailboxes would not be at the domain of the resource-holder, but in a special form "xxxxxxxxx at abuse.ripe.net" where "xxxxxxxxx" is an encrypted string pointing to the real mailbox and that string would actually change every (N) days, so that there would be no value in spammers harvesting such addresses. Mail to those addresses would be forwarded by the RIPE mailserver, with a re-written Return-Path etc so that a bounce would never go directly to the sender but instead come to the RIPE server where it would pass through a filter taking out the personal data. If mail to such an address did bounce in any quantity that could alert the RIPE analysts to the possibility that the resource was no longer in use, or that the resource holder no longer existed. That's a simplified description of a more-detailed spec which I worked out a while back, and something similar is currently in successful use by several domain registrars. So that proves it's not rocket-science! -- Richard Cox RDGC1-RIPE From fweimer at bfk.de Fri Jul 23 15:50:10 2010 From: fweimer at bfk.de (Florian Weimer) Date: Fri, 23 Jul 2010 13:50:10 +0000 Subject: [anti-abuse-wg] Abuse Contact Information - Policy Proposal In-Reply-To: <4C4999ED.5030505@ripe.net> (Denis Walker's message of "Fri\, 23 Jul 2010 15\:32\:29 +0200") References: <4BDE819B.1050608@abusix.com> <82eif6qmbx.fsf@mid.bfk.de> <4C3DBEA2.2070403@abusix.org> <828w5enpat.fsf@mid.bfk.de> <4C3DC7FE.60900@ripe.net> <82fwzappum.fsf@mid.bfk.de> <4C4999ED.5030505@ripe.net> Message-ID: <8239val33h.fsf@mid.bfk.de> * Denis Walker: > The bulk access daily split files still make available all the > operational data. I don't think you can unilaterally declare what's operational and what's not. Does anyone else feel that the anti-abuse working group should ask RIPE NCC to work with its lawyers to make this data available? > If, after processing that data, you need the personal > data for a specific object you can query the RIPE Database for that > object and return the personal data or just the references to it. By definition, role objects do not contain personal data. Corporations are not persons. > If, after processing that data, you need the personal data for a > specific object you can query the RIPE Database for that object and > return the personal data or just the references to it. If you proceed in that direction, you will soon be forced to discontinue that service, too. > With the current design of the RIPE Database there is no way to have > any opt in methods for personal data. This is preposterous. As it stands, the whole thing is totally opt-in. There is no requirement whatsoever to associate inetnum objects with personal data. -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra?e 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From michele at blacknight.ie Fri Jul 23 15:51:08 2010 From: michele at blacknight.ie (Michele Neylon :: Blacknight) Date: Fri, 23 Jul 2010 13:51:08 +0000 Subject: [anti-abuse-wg] Abuse Contact Information - Policy Proposal In-Reply-To: References: Message-ID: On 23 Jul 2010, at 14:43, Richard Cox wrote: > > > My personal thinking goes something like this: Any entity which holds > either an ASN, or an IP address range obtained DIRECTLY from RIPE or > from an LIR, should be required by policy to provision an abuse mailbox; > we should also recommend that such an abuse mailbox be in the form of a > role account rather than an individual's mailbox. The same policy could > also be applied to any sub-assignment greater than /25 (IPv4) or larger > (and a similar figure should be chosen for IPv6 address blocks). > That abuse mailbox should be included in all RIPE data elements, no > matter how they are delivered. That makes a lot of sense We encourage our clients to have their own abuse contacts, as it saves everyone time and energy. It would be good if there was some form of policy or even a suggest best practice .. > > There is another strategy, which I have suggested before, which is that > abuse (and possibly other contact) mailboxes would not be at the domain > of the resource-holder, but in a special form "xxxxxxxxx at abuse.ripe.net" > where "xxxxxxxxx" is an encrypted string pointing to the real mailbox and > that string would actually change every (N) days, so that there would be > no value in spammers harvesting such addresses. Mail to those addresses > would be forwarded by the RIPE mailserver, with a re-written Return-Path > etc so that a bounce would never go directly to the sender but instead > come to the RIPE server where it would pass through a filter taking out > the personal data. If mail to such an address did bounce in any quantity > that could alert the RIPE analysts to the possibility that the resource > was no longer in use, or that the resource holder no longer existed. > > That's a simplified description of a more-detailed spec which I worked > out a while back, and something similar is currently in successful use > by several domain registrars. So that proves it's not rocket-science! As a registrar I'd be interested in learning more ! > > -- > Richard Cox > RDGC1-RIPE > Mr Michele Neylon Blacknight Solutions Hosting & Colocation, Brand Protection ICANN Accredited Registrar http://www.blacknight.com/ http://blog.blacknight.com/ http://blacknight.mobi/ http://mneylon.tel Intl. +353 (0) 59 9183072 US: 213-233-1612 UK: 0844 484 9361 Locall: 1850 929 929 Direct Dial: +353 (0)59 9183090 Twitter: http://twitter.com/mneylon PS: Check out our latest offers on domains & hosting: http://domainoffers.me/ ------------------------------- Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty Road,Graiguecullen,Carlow,Ireland Company No.: 370845 From tk at abusix.com Fri Jul 23 16:32:05 2010 From: tk at abusix.com (Tobias Knecht) Date: Fri, 23 Jul 2010 16:32:05 +0200 Subject: [anti-abuse-wg] Abuse Contact Information - Policy Proposal In-Reply-To: References: Message-ID: <4C49A7E5.9000403@abusix.com> Hello together, why are we moving the problem of non existing abuse contact away from open access to bulk access. I would suggest the following. Anti-Abuse Working Group publishes a Best Practice Paper, which tells every RIPE member that the "ONE" and "ONLY" way for publishing abuse contact information is: Creating an IRT Object with an abuse-mailbox attribute. If there is such a paper, a lot of institutions will push this to their members as a best practice paper and they will have to follow. The next step is a policy proposal that does the following things: - Introduce the IRT Object into ASN Objects. - Make the abuse-mailbox attribute mandatory for the IRT Objects. - Make IRT Objects mandatory for directly by RIPE delegated Ranges. IMHO this will solve all the problems. Query is possible with the -b and you get for all IPs in the RIPE region at least one contact, that is in direct connection with RIPE. The Abuse Finder Tool (which is really cool) is able to give back an contactfor all IP addresses all the time. The query restriction problem is solved and Bulk Data service is not needed. Saves money, saves resources, save small institutions from not reporting abusive behavior because of to big barriers. The ISP/LIR/... can decide if he wants to receive all messages for his netranges and forward them to the right contact or if he offers his customers the possibility to create an own IRT Object. If the Object is wrong all messages go to the Top Contact again and he can check out why his customer is not offering the right contact information. I think this is all there, this is easy, it is not yet another big idea to solve all the problems and being disappointed if it is not working. Writing a Best Practice, making a abuse-mailbox attribute mandatory and making an IRT Object Mandatory should not waste resources at RIPE. Please give me just feedback to the Best Practice part. I think this should really happen and the next steps could be discussed in a policy process. Thanks, Tobias -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 262 bytes Desc: OpenPGP digital signature URL: From balla at spin.it Fri Jul 23 16:57:21 2010 From: balla at spin.it (Emanuele Balla) Date: Fri, 23 Jul 2010 16:57:21 +0200 Subject: [anti-abuse-wg] Abuse Contact Information - Policy Proposal In-Reply-To: <4C49A7E5.9000403@abusix.com> References: <4C49A7E5.9000403@abusix.com> Message-ID: <4C49ADD1.4080707@spin.it> On 7/23/10 4:32 PM, Tobias Knecht wrote: > Hello together, > > why are we moving the problem of non existing abuse contact away from > open access to bulk access. > > I would suggest the following. [...] > Creating an IRT Object with an abuse-mailbox attribute. > - Introduce the IRT Object into ASN Objects. > - Make the abuse-mailbox attribute mandatory for the IRT Objects. > - Make IRT Objects mandatory for directly by RIPE delegated Ranges. > > IMHO this will solve all the problems. "All the problems" is maybe too optimistic, but at least we have something to start with. +1 I also like Richard's idea of xxxxxxxxx at abuse.ripe.net contact addresses: this will solve (part of) the problem of email-address exposure AND allow abuse address reachability monitoring. -- # Emanuele Balla # # # System & Network Engineer # Cell: +39 348 7747907 # # Spin s.r.l. - AS6734 # Phone: +39 040 9869090 # # Trieste # Email: balla at staff.spin.it # From leo.vegoda at icann.org Fri Jul 23 18:06:15 2010 From: leo.vegoda at icann.org (Leo Vegoda) Date: Fri, 23 Jul 2010 09:06:15 -0700 Subject: [anti-abuse-wg] Abuse Contact Information - Policy Proposal In-Reply-To: <4C49A7E5.9000403@abusix.com> References: <4C49A7E5.9000403@abusix.com> Message-ID: On 23 Jul 2010, at 7:32, Tobias Knecht wrote: [...] > I would suggest the following. > > Anti-Abuse Working Group publishes a Best Practice Paper, which tells > every RIPE member that the "ONE" and "ONLY" way for publishing abuse > contact information is: Please see RFC 1925, section 2, point 10. That document may have been published on April Fool's Day but the statement is true, nonetheless. Solutions that require everyone else to change to for your convenience are unlikely to work the way you think they will. Regards, Leo Vegoda From Piotr.Strzyzewski at polsl.pl Sat Jul 24 18:06:06 2010 From: Piotr.Strzyzewski at polsl.pl (Piotr Strzyzewski) Date: Sat, 24 Jul 2010 18:06:06 +0200 Subject: [anti-abuse-wg] Abuse Contact Information - Policy Proposal In-Reply-To: <4C49A7E5.9000403@abusix.com> References: <4C49A7E5.9000403@abusix.com> Message-ID: <20100724160606.GA11862@hydra.ck.polsl.pl> On Fri, Jul 23, 2010 at 04:32:05PM +0200, Tobias Knecht wrote: Hi > I would suggest the following. [cut] > The next step is a policy proposal that does the following things: > > - Introduce the IRT Object into ASN Objects. > - Make the abuse-mailbox attribute mandatory for the IRT Objects. > - Make IRT Objects mandatory for directly by RIPE delegated Ranges. So why are you not going to propose that under PDP? Piotr -- gucio -> Piotr Strzy?ewski E-mail: Piotr.Strzyzewski at polsl.pl From tk at abusix.org Sat Jul 24 13:28:21 2010 From: tk at abusix.org (Tobias Knecht) Date: Sat, 24 Jul 2010 13:28:21 +0200 Subject: [anti-abuse-wg] Abuse Contact Information - Policy Proposal In-Reply-To: <4C49ADD1.4080707@spin.it> References: <4C49A7E5.9000403@abusix.com> <4C49ADD1.4080707@spin.it> Message-ID: <4C4ACE55.3010207@abusix.org> Am 23.07.2010 16:57, schrieb Emanuele Balla: > On 7/23/10 4:32 PM, Tobias Knecht wrote: >> Hello together, >> >> why are we moving the problem of non existing abuse contact away from >> open access to bulk access. >> >> I would suggest the following. > [...] > >> Creating an IRT Object with an abuse-mailbox attribute. > >> - Introduce the IRT Object into ASN Objects. >> - Make the abuse-mailbox attribute mandatory for the IRT Objects. >> - Make IRT Objects mandatory for directly by RIPE delegated Ranges. >> >> IMHO this will solve all the problems. > > "All the problems" is maybe too optimistic, but at least we have > something to start with. > > +1 Okay, not all the problems, but it will be a good start and solve a lot of stuff which is discussed here for years. > I also like Richard's idea of xxxxxxxxx at abuse.ripe.net contact > addresses: this will solve (part of) the problem of email-address > exposure AND allow abuse address reachability monitoring. I like the idea, but creating a single point of failure feels not right for me. There are huge ISPs which are having problems to receive all their incoming reports with really expensive high-end MTAs. The spammers will have the ability to harvest those addresses and attack the single point of failure. You will not even be able to filter the bad stuff because you do not know if it's really bad stuff or just a report with really bad stuff attached. Thanks, Tobias From tk at abusix.com Mon Jul 26 08:29:15 2010 From: tk at abusix.com (Tobias Knecht) Date: Mon, 26 Jul 2010 08:29:15 +0200 Subject: [anti-abuse-wg] Abuse Contact Information - Policy Proposal In-Reply-To: <20100724160606.GA11862@hydra.ck.polsl.pl> References: <4C49A7E5.9000403@abusix.com> <20100724160606.GA11862@hydra.ck.polsl.pl> Message-ID: <4C4D2B3B.5040408@abusix.com> Hi, >> The next step is a policy proposal that does the following things: >> >> - Introduce the IRT Object into ASN Objects. >> - Make the abuse-mailbox attribute mandatory for the IRT Objects. >> - Make IRT Objects mandatory for directly by RIPE delegated Ranges. > > So why are you not going to propose that under PDP? Because I think a Best Practice Paper is easier to find consensus. But you are absolutely right there has to be a policy proposal in future. And there will be one. ;-) Thanks, Tobias -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 262 bytes Desc: OpenPGP digital signature URL: