From brian.nisbet at heanet.ie Mon Aug 9 11:58:52 2010 From: brian.nisbet at heanet.ie (Brian Nisbet) Date: Mon, 09 Aug 2010 10:58:52 +0100 Subject: [anti-abuse-wg] Draft Anti-Abuse Working Group Minutes - RIPE 60 Message-ID: <4C5FD15C.1080708@heanet.ie> Colleagues, Apologies for the delay in circulating these minutes for your consideration. Thanks, Brian. ------------------------- Draft Anti-Abuse Working Group Minutes - RIPE 60 Thursday, 6 May 2010, 16:00 ? Prague Marriott Hotel, Czech Republic Co-Chairs: Brian Nisbet, Richard Cox Scribe: Fergal Cunningham Jabber: Emile Aben A. Administrative Matters Working Group Co-Chair Brian Nisbet opened the session at 16:00 and welcomed attendees. The minutes from RIPE 59 were approved without comment. B Update B1. Network Abuse Update - Richard Cox Working Group Co-Chair Richard Cox gave an update on current abuse trends and recent relevant technical developments. He started by differentiating between cybercrime and abuse, both of which he said come within the scope of the Anti-Abuse Working Group but which need to be treated differently. He began by talking about snow shoe spam, which rotates the IP address of sent mail through up to a /20 or /19, and is being carried out by a small number of US-based organisations that are active in Europe. He explained that this type of spam is causing big problems at the moment because it has so far managed to avoid detection. He said there was a new detector for this type of spam at Spamhaus but he thought it would eventually find a way around this. Moving on to abuse, Richard talked mainly about domain abuse, where domains are registered using fake credit cards and malware is then transmitted through those domains. He said through use of this malware, which employs keyloggers, the criminals can transfer money to their accounts and because it comes from the user?s standard IP address it does not appear to the banks to be a fraudulent transaction. He mentioned that one problem is that police tend to pass responsibility for this type of crime to the banks. Richard mentioned the problem of IPv6 and traceability, which he said was not too visible yet but it would be and is the type of problem that will affect other working groups, such as the Address Policy and Database Working Groups. He concluded by talking about the UK-specific problem of large organisations and their customer bases being sold from one company to another without providing any precautions regarding the latest exploits. There were no questions and Brian thanked Richard for his update. B2. Recent List Discussion - Abuse contacts, Sanctions, etc. Brian started by mentioning the recent discussion on the Anti-Abuse mailing list, initiated by Frank Gadegast in April 2010, concerning implementation of an abuse monitor system. Brian explained that the proposal was to be able to mail an email address based on an abusive IP address, which would then be passed through a clearing house to the relevant LIR or IP holder. Brian said there was no formal policy proposed on this and there did not seem to be much support for it on the mailing list. Brian said they would wait for comments or further proposals on the mailing list. Brian said the second item to be discussed was from Tobias Knecht, Abusix, on an abuse contact information policy proposal. Brian said that the proposal is to introduce a mandatory reference to IRT objects in the inetnum, inet6num and aut-num objects in the RIPE Whois Database to provide a more accurate and efficient way for abuse reports to reach the correct network contact and help reporting institutions to find the correct abuse contact information more easily. Brian explained that the proposal was sent to the list and is a copy of proposals sent to AfriNIC and APNIC. He said the plan was to work with Tobias on creating a formal RIPE proposal but he would like to gather responses from the room before doing so. Niall O?Reilly, University College Dublin, said that discussion on irrelevant references in such objects took place some years ago and it would be a good idea to look at these discussions so as not to cover old ground. Brian agreed that this was a good idea and he would compile the relevant sections of the older discussions and post them to the list. Peter Koch, DENIC, agreed with Niall and asked if there were some restrictions on getting an irt object in the RIPE Database. Wilfried Woeber, Vienna University, said there were restrictions but these were removed a long time ago. Brian said another topic that came up on the mailing list was sanctions on people who abused networks. He said that Jochem de Ruig from the RIPE NCC would present on this later in the session that would address this area. Brian said that at this point it was worth mentioning that there was no big red button that anyone can press to legally remove someone from the Internet. Brian concluded by reminding people that this Anti-Abuse Working Group has replaced the Anti-Spam Working Group. He said this was to widen the focus of the working group. C. Technical Measures C1. RIPE NCC Tools update - Paul Palse, RIPE NCC Paul?s presentation is available at: http://www.ripe.net/ripe/meetings/ripe-60/presentations/Palse-RIPE_Labs_-_The_Abuse_Finder.pdf Paul?s presentation included a live demonstration of the prototype Abuse Finder tool, which is available on RIPE Labs at: http://labs.ripe.net/content/abuse-finder Paul asked for feedback on the tool and looked for questions. Co-Chair Richard Cox thanked Paul and asked said there is a need to find out exactly what investigators are looking for and tune the system accordingly so they can get answers quickly. He suggested talking about this and perhaps involving APNIC so a universal system can be developed that will provide the answers needed by investigators. He said one question asked if he had a problem with a resource, could the tool return results for resources with similar attributes that might be causing problems. Paul said the RIPE NCC could definitely look at that and try to improve the system based on this type of extremely helpful feedback. Richard said, as an example, he could look at announced ASN numbers but not see what is assigned, and this would be very helpful. He also suggested that if you found a certain maintainer, it would be useful to see what else that maintainer was maintaining. Wilfried Woeber said it would be useful to have a discussion about this on RIPE Labs, because this is what RIPE Labs is for and people could suggest a number of similar ideas to improve the tool. Wilfried said the tool sounds like a freetext search across all data in the database. He said he was not convinced it was a good idea to offer something like that publicly. He also said that 80% to 90% of what you want to do is available already through methods such as inverse lookups, but the problem lies in combining query X with query X+1. Paul said this was basically what the tool did. Denis Walker from the RIPE NCC commented that the Database Group in the RIPE NCC could run a script for whatever needed to be found. He said that if users told them what they wanted to find and gave use cases, then the Database Group could write a script that return exactly what they want. Brian supported this and asked that people come to the Anti-Abuse Working Group with examples of what they would like to see. Niall O?Reilly said the beauty of a RESTful wrapper is that you can make a single query of anything in whatever way you wish. Paul said the Abuse Finder tool has a bit more to it and can present material in a very concise way. D. Interactions D1. Working Groups Brian noted that the interactions with other working groups are covered by other agenda items in this session. Brian also noted that all law enforcement interaction and cooperation would now reside in the Anti-Abuse Working Group rather than the Cooperation Working Group, where such interactions originated. D2. RIPE NCC LEA Interactions Update - Jochem de Ruig, RIPE NCC Jochem?s presentation is available at: http://www.ripe.net/ripe/meetings/ripe-60/presentations/De_Ruig-RIPE_NCC_and_LEA_cooperation.pdf There were no questions. D3. Law Enforcement Interaction - Wout de Natris, London Action Plan Wout?s presentation is available at: http://www.ripe.net/ripe/meetings/ripe-60/presentations/deNatris-Industry-LEA_Cooperation.pdf Brian reiterated that the Anti-Abuse Working Group would be the channel for communication between LEAs and the RIPE community. He said this interaction could take place on the mailing list and at future RIPE Meetings, or people could contact himself or Richard. A member of the Serious Organised Crime Agency in the UK said that revocation is one of the major issues for law enforcement agencies. He added that a major part of this was the question of how to stop the routing of revoked resources. Brian said there was some discussion in the Address Policy Working Group about certified routing and revocation of certificates. He said that at the moment there was no real way to stop routing in this way because people route what they want to route. Wilfried Woeber said that interfering with the routing layer could have an impact on completely unrelated parties across the globe. He asked law enforcement representatives to be aware that if you have a mechanism for removing people from the Internet, it will be used to do so for political purposes. He said it was difficult to determine right and wrong in this situation because right and wrong can mean different things in different places. RIPE Chair Rob Blokzijl wanted to bring attention to Geoff Huston of APNIC?s presentation earlier in the week on measuring traffic on the Internet from network number 1. Rob said this network has never been announced but there is a huge amount of traffic on the Internet claiming to come from that network. He said that removing an address block from the registry would not stop anything, so it would be more profitable to think about actions that would help. He said he would be reluctant to have a mechanism that allows third parties tell the RIPE community what they can register and what they can?t. He concluded that law enforcement should be concerned with having the best registry data possible available. Richard Cox said it can be very difficult to identify the origin of a packet that caused harm on the Internet, so the important thing is to identify who contributed to the harm. He said there needs to be a mechanism to identify what problems are associated with a particular routing and get that information to people who are handling the traffic. He said the community can then decide to accept a route or not, and if 90% of the Internet decides not to accept a route then its harm will be limited. He concluded by reminding people that it is better to regulate yourself before government steps in to do it for you. X. AOB Alex le Heux from the Registration Services Department in the RIPE NCC outlined a proposal about address space reclaimed by the RIPE NCC. He said after an appropriate quarantine period the address space is re-allocated, but it might previously have been used by people who were not the best Internet citizens and the resources are on anti-abuse and anti-spam lists across the Internet. He explained that these addresses go back into the free pool after the quarantine period but the people who receive them can be unhappy they are not receiving brand new addresses, and replacing the addresses with new ones does not really solve the problem. He said this problem would only get worse as the last phase of RIPE Policy Proposal 2007-01 approached. He proposed that during the quarantine period, which typically lasts three months, the addresses could be published so that anti-spam groups could remove them from their lists. He asked the community to give feedback on this proposal. Richard Cox said Spamhaus has been arguing for something like this for some time. He said people operating anti-abuse lists take the view that if people are working towards solving a problem like this, then it is sensible to try to help them. He suggested creating an RFC that will define a standard by which the information can be published by all the RIRs on a standard webpage within their website that can be downloaded by those maintaining the anti-abuse lists. He said this could be used to reset the status of resources on a regular basis. He said there just needs to be an assurance that the resources are not handed back and then reclaimed by the same organisation, which is happening in some cases at the moment. Alex said that the RIPE NCC does not allow people to come in and choose the address space they want. Brian said it would be good for the RIPE NCC and other RIRs to publish such information with the caveats that Richard mentions. Rob Blokzijl said he was talking about this issue with John Curran, CEO of ARIN, about this specific problem. Rob said ARIN has procedures in place and he recommended that Alex look at these. He said it would also be good if all RIRs have the same procedure in place so the anti-abuse lists would be more up to date with reality. Carsten Scheifner, DENIC, said perhaps that list already exists through the RIPE Database and by doing an indirect search on unallocated space. Alex replied that the proposal applies to address space that was allocated and then reclaimed and which is waiting to be allocated to someone else. He said it was possible to do as Carsten suggested and look for holes in the database but this proposal might be an easier way to accomplish the same thing. Peter Koch, DENIC, said if the RIPE NCC uses a white list to override blacklists then that sounds fishy. He asked if it was possible that it would be a case of asking anti-abuse groups to do the same thing as those groups who take multiple addresses from the database. He asked who would be the target audience. Alex said groups like Spamhaus would be the target audience. He said the proposed list would make the assertion that the addresses were in use by someone else previously and will be used by someone else in the future. Paul Vixie, ARIN Board of Trustees, said there is a lot of space mentioned on black hole operator lists and he said this space is like toxic waste and there can only be clean-up efforts if there is no revolving door whereby the people who created the toxic waste cannot simply get another block of resources they can contaminate. He said many black list operators would say this is the RIPE NCC?s fault and it should resolve this. Brian said this issue is to do with reclamation and clean-up, and this proposal aims to make it easier to do that and to make best use of the remaining IPv4 address space rather than solve all problems. Richard Cox said, in response to the assertion from Peter Koch, that it takes a lot of time to conduct a clean-up. He said an RFC-defined list at a designated place would be a big help. He said there needs to be agreement, including among RIRs, and there are certain definitions that need to apply. He said people cause abuse of address space and the RIPE NCC has to ask if it is right to allocate space in certain situations to certain LIRs. Alex said he would talk to the relevant parties as soon as possible. Richard Cox presented two proposals that he said would inevitably be discussed on the working group mailing list. He said that RIPE needs to make some changes to make it less easy for cybercriminals who specifically come to RIPE because they see RIPE as more of a pushover than ARIN. Richard?s first proposal was to ask the DB WG to make available in the RIPE Database two additional fields so that a standard query with no switches will get data on the LIR that assigned a block and data on the most recent change of that block. He said for good reasons the existing fields cannot be altered so the date of change would need to go out under a different object to avoid breaking anything that currently exists. He said providing the LIR data would allow investigators to see patterns, and if the data is available in the RIPE Database, people will know immediately who to go to resolve a problem. Richard?s second proposal suggestion was on allocations. He asked if the process in the RIPE NCC is optimal for dealing with problems and he asked that the RIPE NCC make provision for dealing faster with allocation problems. He said it would be helpful if there was a published RIPE NCC address that people could use when people get a dodgy allocation. He suggested a small group of people from community could work on this under a non-disclosure agreement (NDA). Wilfried asked Richard to elaborate on the NDA aspect of this because he wasn?t sure if the NDAs were suitable for the RIPE environment. Brian said the proposals were not fully formed yet. He asked Richard to write them up and bring them to the mailing list, and he asked the community to comment on them when they were posted to help make them fully formed proposals. There was no further business. Brian thanked the presenters and the attendees and said he hoped to see everyone at the next Anti-Abuse Working Group session in Rome in November 2010. The session adjourned at 17:47. A full recording of this Anti-Abuse Working Group session is available at: http://rosie-arch.ncc.ripe.net/webcast/ripe-60/mp3/Anti-Abuse-WG.mp3 From ripe-anti-spam-wg at powerweb.de Mon Aug 9 13:59:47 2010 From: ripe-anti-spam-wg at powerweb.de (Frank Gadegast) Date: Mon, 09 Aug 2010 13:59:47 +0200 Subject: [anti-abuse-wg] Draft Anti-Abuse Working Group Minutes - RIPE 60 In-Reply-To: <4C5FD15C.1080708@heanet.ie> References: <4C5FD15C.1080708@heanet.ie> Message-ID: <4C5FEDB3.2080008@powerweb.de> Hi all, > Draft Anti-Abuse Working Group Minutes - RIPE 60 > Brian said there was some discussion in the Address Policy Working Group > about certified routing and revocation of certificates. He said that at > the moment there was no real way to stop routing in this way because > people route what they want to route. This might be true, but removing networks from RIPEs databased will also remove all reverse mapping and nameserver entries, right ? No mailserver, that is configured to fight only a bit against spam accepts mail from IPs without a working reverse mapping. So, if RIPE ever wants to punish network abusers, thats an easy way of doing it ... 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 ripe-anti-spam-wg at powerweb.de Mon Aug 9 14:13:22 2010 From: ripe-anti-spam-wg at powerweb.de (Frank Gadegast) Date: Mon, 09 Aug 2010 14:13:22 +0200 Subject: [anti-abuse-wg] Re: what I want from RIPE ... In-Reply-To: <4C5FD15C.1080708@heanet.ie> References: <4C5FD15C.1080708@heanet.ie> Message-ID: <4C5FF0E2.4000300@powerweb.de> Hi all, > Denis Walker from the RIPE NCC commented that the Database Group in the > RIPE NCC could run a script for whatever needed to be found. He said > that if users told them what they wanted to find and gave use cases, > then the Database Group could write a script that return exactly what > they want. Brian supported this and asked that people come to the > Anti-Abuse Working Group with examples of what they would like to see. "I simply want a daily dump of all networks and their abuse email address, public available via FTP for mirroring." I do not see, how these email addresses should be privat, because they are inserted into the object by effort. Network owners that do not want this published, do not put them in anyway. And making a dump is much easier than programming the finder tool any further. So please, simply dump that list containing all or just the most important email addresses(however they are found from the finder tool via the tech-c email, an abuse-field email, some email in the remarks or an IRT object) for every network daily. This will help all blacklist maintainers and all ISPs, that do fight against spam, to automate their reports without having to fight against limited whois lookup resources. 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 ripe-anti-spam-wg at powerweb.de Mon Aug 9 15:06:33 2010 From: ripe-anti-spam-wg at powerweb.de (Frank Gadegast) Date: Mon, 09 Aug 2010 15:06:33 +0200 Subject: [anti-abuse-wg] Re: how to punish a spammer In-Reply-To: <4C5FD15C.1080708@heanet.ie> References: <4C5FD15C.1080708@heanet.ie> Message-ID: <4C5FFD59.7070801@powerweb.de> Thor Kottelin wrote: >> -----Original Message----- >> From: anti-abuse-wg-admin at ripe.net [mailto:anti-abuse-wg- >> admin at ripe.net] On Behalf Of Frank Gadegast >> Sent: Monday, August 09, 2010 3:00 PM >> To: Brian Nisbet >> Cc: anti-abuse-wg at ripe.net > >> removing networks from RIPEs databased >> will also remove all reverse mapping and nameserver entries, right >> ? >> >> No mailserver, that is configured to fight only a bit against spam >> accepts mail from IPs without a working reverse mapping. >> >> So, if RIPE ever wants to punish network abusers, thats an easy way >> of >> doing it ... > > I agree that this may be a somewhat effective approach. > > However, I doubt that most mail exchanges are configured in such a categorical manner. I apologise for not having any hard data to present, but my experience is that missing or dysfunctional reverse mappings often are used to increase spam scores (such as in SpamAssassin) rather than to reject mail outright. > Thats right ... The default setting for most MTAs these days is to complain about mails from servers without any reverse mapping and to complain in a different manner about a not matching reverse mapping (at least sendmail, postfix, qmail and Exchange CAN do this). Most anti spam solutions surely raise the score, if there is no reverse mapping or if the reverse mapping does not match the hostname or HELO command. My personal experience is, that most provider do not accept email from servers without a reverse mapping but accept email from servers with a not matching reverse mapping and use this for further spam scoring. Some even put mailserver without a working reverse mapping on their blacklists ... So: its up to the server administrator to configure the final solution and thats perfect, everybody can decide what to do. A totally missing reverse mapping will surely help the receiver a lot and harm the spammer ... And removing route object will surely help even more. Most transit provider and exchange points usually generate their BGP filters from whois records and match them against customers known ASes and peering partner ASes (when accepting routes) daily. No route objects means no peering, no routing and no announcement. And transit provider or exchange points that are not working this way, have a serious security problem anyway ... All this is technically easy, the only thing missing is a discussion, who decides, what objects need to be remove and why. 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 -- Mit freundlichen Gruessen, -- 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 richard.cox at btuser.net Tue Aug 10 01:19:20 2010 From: richard.cox at btuser.net (Richard Cox) Date: Mon, 09 Aug 2010 23:19:20 +0000 Subject: [anti-abuse-wg] Draft Anti-Abuse Working Group Minutes - RIPE 60 In-Reply-To: <4C5FEDB3.2080008@powerweb.de> Message-ID: Frank Gadegast wrote: >> Brian said there was some discussion in the Address Policy Working >> Group about certified routing and revocation of certificates. He said >> that at the moment there was no real way to stop routing in this way >> because people route what they want to route. > > This might be true, but removing networks from RIPEs databases will > also remove all reverse mapping and nameserver entries, right? It certainly should. > No mailserver, that is configured to fight only a bit against spam > accepts mail from IPs without a working reverse mapping. So, if RIPE > ever wants to punish network abusers, thats an easy way of doing it RIPE has no role to punish network abusers. RIPE should have a role to take appropriate action against those who abuse RIPE's resources. That would include providing false identity or configuration details in connection with a request for network resources. Those are the cases where revocation of those resources is needed - and of course the routing data would then have to be removed as a result. What is worth bearing in mind is that a revoked allocation should show up in IP-WHOIS as REVOKED for a given period of time after revocation. Otherwise we get the vexing situation where an abuser asks an ISP to route his IP block and tells the ISP, when they check RIPE's WHOIS and see "not found", "Oh dear, looks like the RIPE database isn't working. "Revoked" must be clearly visible. For example, nobody really knows why AS43074 and 193.109.246.0/23 are no longer in the RIPE database. But AS43074 (announcing 193.109.246.0/23) is being routed by STARNET in Moldova and bringing you all the lovely Zeus malware and similar. Network Next Hop Path *> 193.109.246.0/23 208.74.64.40 3257 31252 43074 i Unfortunately removing rDNS etc won't stop that malware spreading. -- Richard From leo.vegoda at icann.org Tue Aug 10 01:43:04 2010 From: leo.vegoda at icann.org (Leo Vegoda) Date: Mon, 9 Aug 2010 16:43:04 -0700 Subject: [anti-abuse-wg] Draft Anti-Abuse Working Group Minutes - RIPE 60 In-Reply-To: References: Message-ID: <5F8AC5DF-BA7B-4121-8A7B-93745F10EC85@icann.org> On 9 Aug 2010, at 4:19, Richard Cox wrote: [...] > What is worth bearing in mind is that a revoked allocation should show > up in IP-WHOIS as REVOKED for a given period of time after revocation. > Otherwise we get the vexing situation where an abuser asks an ISP to > route his IP block and tells the ISP, when they check RIPE's WHOIS and > see "not found", "Oh dear, looks like the RIPE database isn't working. > > "Revoked" must be clearly visible. I disagree. I do not think the registry should publish a comment on why a registration exists or does not exist and the word REVOKED is clearly intended to imply that the registration was removed against the desires of the registrant. Publishing a registration (a positive act) but giving it a negative status is likely to cause confusion, especially with automated network-centric systems that ignore the status attribute value. I also think the example you give is unrealistic. If the ISP can see its own object and a bunch of other objects then the problem is unlikely to be that to be that the whois database is broken. And if they were genuinely concerned about a problem with the database they could always contact the RIPE NCC. If some kind of mechanism is needed to allow network operators to check that a prefix is not currently registered, then we should ask the RIPE NCC to publish an easy to parse list of prefixes and the date on which they were removed from the database. Presumably a prefix would remain on the list until it had completed any quarantine period and is ready to be re-issued. Regards, Leo Vegoda From andre at ox.co.za Tue Aug 10 07:40:12 2010 From: andre at ox.co.za (andre at ox.co.za) Date: Tue, 10 Aug 2010 07:40:12 +0200 Subject: [anti-abuse-wg] Re: how to punish a spammer In-Reply-To: <4C5FFD59.7070801@powerweb.de> References: <4C5FD15C.1080708@heanet.ie> <4C5FFD59.7070801@powerweb.de> Message-ID: <201008100740.12347.andre@ox.co.za> Frank Gadegast said on Monday 09 August 2010 : > Thor Kottelin wrote: > >> removing networks from RIPEs databased > >> will also remove all reverse mapping and nameserver entries, right > >> ? > >> > >> No mailserver, that is configured to fight only a bit against spam > >> accepts mail from IPs without a working reverse mapping. > >> > >> So, if RIPE ever wants to punish network abusers, thats an easy way > >> of > >> doing it ... > > > > I agree that this may be a somewhat effective approach. > > > > All this is technically easy, the only thing missing is a discussion, > who decides, what objects need to be remove and why. > This is the best idea that I have heard in a long time and there could be proper structures in place (similiar to spamcop) to prevent abuse Andre From ripe-anti-spam-wg at powerweb.de Tue Aug 10 12:41:41 2010 From: ripe-anti-spam-wg at powerweb.de (Frank Gadegast) Date: Tue, 10 Aug 2010 12:41:41 +0200 Subject: [anti-abuse-wg] Re: how to punish a spammer In-Reply-To: <201008100740.12347.andre@ox.co.za> References: <4C5FD15C.1080708@heanet.ie> <4C5FFD59.7070801@powerweb.de> <201008100740.12347.andre@ox.co.za> Message-ID: <4C612CE5.4070801@powerweb.de> andre at ox.co.za wrote: > Frank Gadegast said on Monday 09 August 2010 : >> Thor Kottelin wrote: >> >> removing networks from RIPEs databased >> >> will also remove all reverse mapping and nameserver entries, right >> >> ? >> >> >> >> No mailserver, that is configured to fight only a bit against spam >> >> accepts mail from IPs without a working reverse mapping. >> >> >> >> So, if RIPE ever wants to punish network abusers, thats an easy way >> >> of >> >> doing it ... >> > >> > I agree that this may be a somewhat effective approach. >> > >> >> All this is technically easy, the only thing missing is a discussion, >> who decides, what objects need to be remove and why. >> > > This is the best idea that I have heard in a long time and there > could be proper structures in place (similiar to spamcop) to > prevent abuse Even if I really want that, its nearly impossible. There are always some members, thats are not willing to restrict regulations, that are happy like it is. This can have a lot of reasons: - because their culture or country regulations do not allow that - because they want a free internet, even with free abuse - they make money with abuse (maybe even only with flooding others with mail offers or make money by selling upstream, hosting and services. I was talking to a spam solution provider lately, the most he fears, is that the RIRs are finally doing something ! you see: he is not eval himself, in fact his company is doing something really good, but he still makes money from spam) - or because they simply do not want to take care about their resources, because its work and therefor costs money We are talking about a definition of abuse for a couple of years now, without any result, because those members always find "a hair in the soup" (a saying in Germany). And you cannot change RIPEs regulations without a definition and he will to do something from the community. And RIPE NCC will never do anything thats not defined in the regulations. THATS the problem. Maybe we should make a rehersal, vote or proposal to answer a simply question: "should RIPE create regulations to remove resources because of abuse ?" > Andre 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 -- Mit freundlichen Gruessen, -- 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 richard.cox at btuser.net Tue Aug 10 12:44:55 2010 From: richard.cox at btuser.net (Richard Cox) Date: Tue, 10 Aug 2010 10:44:55 +0000 Subject: [anti-abuse-wg] Draft Anti-Abuse Working Group Minutes - RIPE 60 In-Reply-To: <5F8AC5DF-BA7B-4121-8A7B-93745F10EC85@icann.org> Message-ID: Leo Vegoda wrote >> "Revoked" must be clearly visible. > > I disagree. I do not think the registry should publish a comment on why > a registration exists or does not exist and the word REVOKED is clearly > intended to imply that the registration was removed against the desires > of the registrant. On those - increasing number of - occasions when an RIR discovers that information it was given in support of a registration, was untruthful or invalid then it seems to me entirely reasonable that the RIR should make it clear that what it had previously published, should not be relied upon. > Publishing a registration (a positive act) but giving it a negative > status is likely to cause confusion, especially with automated > network-centric systems that ignore the status attribute value. There will surely be technical solutions to that technical problem. > I also think the example you give is unrealistic. If the ISP can see its > own object and a bunch of other objects then the problem is unlikely to > be that to be that the whois database is broken. It's very realistic. Nobody would be suggesting that the "whole database is broken". What would be suggested is that some records are missing or the database has not been updated. That would not necessarily affect the records of the ISP querying the database, as its own record would probably be significantly older. > If some kind of mechanism is needed to allow network operators to check > that a prefix is not currently registered, then we should ask the RIPE > NCC to publish an easy to parse list of prefixes and the date on which > they were removed from the database. Presumably a prefix would remain on > the list until it had completed any quarantine period and is ready to be > re-issued. We have been asking for exactly that for some years now, partly to allow reputational records to be reset as and when an allocation is recovered. -- Richard From fweimer at bfk.de Tue Aug 10 12:54:53 2010 From: fweimer at bfk.de (Florian Weimer) Date: Tue, 10 Aug 2010 10:54:53 +0000 Subject: [anti-abuse-wg] Draft Anti-Abuse Working Group Minutes - RIPE 60 In-Reply-To: (Richard Cox's message of "Tue\, 10 Aug 2010 10\:44\:55 +0000") References: Message-ID: <821va6hh4y.fsf@mid.bfk.de> * Richard Cox: > It's very realistic. Nobody would be suggesting that the "whole database > is broken". What would be suggested is that some records are missing or > the database has not been updated. And I think not all RIRs run route registries, so there are cases where no reliable documentation for the prefix can be found, yet an announcement would still be legitimate. -- 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 frank at powerweb.de Tue Aug 10 12:16:05 2010 From: frank at powerweb.de (Frank Gadegast) Date: Tue, 10 Aug 2010 12:16:05 +0200 Subject: [anti-abuse-wg] Draft Anti-Abuse Working Group Minutes - RIPE 60 In-Reply-To: References: Message-ID: <4C6126E5.30904@powerweb.de> Richard Cox wrote: > RIPE has no role to punish network abusers. RIPE should have a role > to take appropriate action against those who abuse RIPE's resources. > That would include providing false identity or configuration details > in connection with a request for network resources. Those are the > cases where revocation of those resources is needed - and of course > the routing data would then have to be removed as a result. And there we are again. If we do not extend RIPEs responsibility and the RIPE regulations so that the members are responsible for using RIPE resources without abuse and RIPE NCC has therefor no responsibility to monitor abuse, there will be no revocation. And because we will never have a definition of abuse, there will be no change in the regulations and no demand to RIPE NCC handle this. Conclusion: because RIPEs members are not willing to take responsibility and abuse will continue forever. And we only can work here to make protection easier for those, who want to do something for themselv. But thats only a cure, not a solution ... > What is worth bearing in mind is that a revoked allocation should show > up in IP-WHOIS as REVOKED for a given period of time after revocation. > Otherwise we get the vexing situation where an abuser asks an ISP to > route his IP block and tells the ISP, when they check RIPE's WHOIS and > see "not found", "Oh dear, looks like the RIPE database isn't working. > > "Revoked" must be clearly visible. For example, nobody really knows Good idea. > why AS43074 and 193.109.246.0/23 are no longer in the RIPE database. > But AS43074 (announcing 193.109.246.0/23) is being routed by STARNET Well, thats clearly a mistake of STARNET then. You should talk to them, if STARNET is one of your upstream providers. The should really filter there routes against route objects. None, of our upstream providers does route this network. > in Moldova and bringing you all the lovely Zeus malware and similar. > > Network Next Hop Path > *> 193.109.246.0/23 208.74.64.40 3257 31252 43074 i > > Unfortunately removing rDNS etc won't stop that malware spreading. True, but revocation of route objects does. 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 olivier.beckers at ecc.eni.it Tue Aug 10 16:03:03 2010 From: olivier.beckers at ecc.eni.it (olivier.beckers at ecc.eni.it) Date: Tue, 10 Aug 2010 16:03:03 +0200 Subject: [anti-abuse-wg] Olivier Beckers/ZB00036/EniCoordinationCenter-BE/ENI/IT is out of the office. Message-ID: I will be out of the office starting 29/07/2010 and will not return until 18/08/2010. For any urgent message you can contact Giacomo Giglio From richard.cox at btuser.net Tue Aug 10 21:38:00 2010 From: richard.cox at btuser.net (Richard Cox) Date: Tue, 10 Aug 2010 19:38:00 +0000 Subject: [anti-abuse-wg] Re: how to punish a spammer In-Reply-To: <4C612CE5.4070801@powerweb.de> Message-ID: Frank Gadegast wrote: > Maybe we should make a rehersal, vote or proposal to answer a simply > question: "should RIPE create regulations to remove resources because > of abuse ?" The RIPE Policy Development Process is at your disposal. The AAWG is just as entitled to propose and agree a policy as any of the other RIPE WGs. You seem to have a lot of sympathetic ears here, so over to you. In the interests of Full Disclosure, I should mention that I will be submitting some of my own proposals very shortly (I referred to them briefly in Prague); they include providing registration- / changed-dates for IP and ASN allocations in all WHOIS responses (ie without requiring the -b switch) and also providing information in the standard WHOIS data on which LIR (if any) was involved in allocating a specific resource -- Richard From richard.cox at btuser.net Tue Aug 10 21:38:00 2010 From: richard.cox at btuser.net (Richard Cox) Date: Tue, 10 Aug 2010 19:38:00 +0000 Subject: [anti-abuse-wg] Draft Anti-Abuse Working Group Minutes - RIPE 60 In-Reply-To: <4C6126E5.30904@powerweb.de> Message-ID: frank at powerweb.de wrote: > Conclusion: because RIPEs members are not willing to take > responsibility and abuse will continue forever. We don't know what the members think, or are prepared to do. Sure, we are told in no uncertain terms what the NCC thinks the members think - but the members I have spoken to certainly don't think that way. So is it that the members don't effectively voice their opinions - or could it be that just one member of the NCC staff wants us all to believe that everyone thinks what he wants everyone to think? >> why AS43074 and 193.109.246.0/23 are no longer in the RIPE database. >> But AS43074 (announcing 193.109.246.0/23) is being routed by STARNET > Well, thats clearly a mistake of STARNET then. Such mistakes are often associated with appropriate revenue adjustments. > You should talk to them, if STARNET is one of your upstream providers. > The should really filter there routes against route objects. Starnet connect (to the UK) at LINX. LINX policies are clearly stated - their members can do whatever they like (as far as LINX is concerned) >> Unfortunately removing rDNS etc won't stop that malware spreading. > True, but revocation of route objects does. Only for some communities. Route objects are only relevant in parts of the RIPE service region. And certainly not in North America etc. See: http://www.robtex.com/as/as31252.html -- Richard From leo.vegoda at icann.org Tue Aug 10 22:01:22 2010 From: leo.vegoda at icann.org (Leo Vegoda) Date: Tue, 10 Aug 2010 13:01:22 -0700 Subject: [anti-abuse-wg] Draft Anti-Abuse Working Group Minutes - RIPE 60 In-Reply-To: References: Message-ID: On 10 Aug 2010, at 3:44, Richard Cox wrote: Leo Vegoda wrote >>> "Revoked" must be clearly visible. >> >> I disagree. I do not think the registry should publish a comment on why >> a registration exists or does not exist and the word REVOKED is clearly >> intended to imply that the registration was removed against the desires >> of the registrant. > > On those - increasing number of - occasions when an RIR discovers that > information it was given in support of a registration, was untruthful or > invalid then it seems to me entirely reasonable that the RIR should make > it clear that what it had previously published, should not be relied upon. > >> Publishing a registration (a positive act) but giving it a negative >> status is likely to cause confusion, especially with automated >> network-centric systems that ignore the status attribute value. > > There will surely be technical solutions to that technical problem. Why create a technical problem just so that you can create a technical solution? The actual problem is social and I suggest that that is where you should focus solutions. >> I also think the example you give is unrealistic. If the ISP can see its >> own object and a bunch of other objects then the problem is unlikely to >> be that to be that the whois database is broken. > > It's very realistic. Nobody would be suggesting that the "whole database > is broken". What would be suggested is that some records are missing or > the database has not been updated. That would not necessarily affect the > records of the ISP querying the database, as its own record would probably > be significantly older. Here and above you seem to be arguing two things: firstly, that the RIPE NCC's procedures or staff are considered so error prone that the removal of a registration from the database would automatically be assumed to be a mistake, rather than intentional. That seems unlikely to me but maybe I have missed the hollering and alarm at the frequent reports of errors. Secondly, you seem to believe that the RIPE NCC should not just maintain a registry of what is but should also annotate the registry with commentary about the organisations whose data are published there. I recognise that there is a group of people who abuse the system. However, I think that commentary about that group should be confined to communication between them and the RIPE NCC and if necessary the courtroom. I do not believe it is appropriate for the RIPE NCC to publish reasons for its actions in the database. In fact, I believe that to do so would breach the current IPv4 policy: 3.1 Confidentiality Internet Registries (IRs) have a duty of confidentiality to their registrants. Information passed to an IR must be securely stored and should not be distributed wider than necessary within the IR. When necessary, the information may be passed to a higher-level IR under the same conditions of confidentiality. I should probably also point out that this is a requirement of section 10 of ICP-2, too: http://www.icann.org/en/icp/icp-2.htm Of course, policy can be changed but I am not convinced that I have seen a convincing case to change the current policy yet. >> If some kind of mechanism is needed to allow network operators to check >> that a prefix is not currently registered, then we should ask the RIPE >> NCC to publish an easy to parse list of prefixes and the date on which >> they were removed from the database. Presumably a prefix would remain on >> the list until it had completed any quarantine period and is ready to be >> re-issued. > > We have been asking for exactly that for some years now, partly to allow > reputational records to be reset as and when an allocation is recovered. Has the RIPE NCC responded to these requests? If so, what has it said? Regards, Leo Vegoda From bengan at bag.org Tue Aug 17 12:04:28 2010 From: bengan at bag.org (Bengt =?iso-8859-1?q?G=F6rd=E9n?=) Date: Tue, 17 Aug 2010 12:04:28 +0200 Subject: [anti-abuse-wg] Updated Abuse Finder Tool available on RIPE Labs In-Reply-To: <4C10F404.5060800@ripe.net> References: <4C10F404.5060800@ripe.net> Message-ID: <201008171204.28664.bengan@bag.org> torsdag 10 juni 2010 16:17:40 skrev Mirjam Kuehne: > [apologies for duplicates] > > > Dear colleagues, > > About a month ago, we published the abuser finder tool that allows you > to find abuser handler information more easily in the RIPE Database. In > the meantime we received many good suggestions and comments. > > The new version of the abuse finder tool incorporates many of these > suggestions (thanks to Paul Palse and his team) and is now available on > the front page of RIPE Labs: > > http://labs.ripe.net/ > > (or you can use the direct link to the article: > > http://labs.ripe.net/content/updated-heuristics-abuse-finder-service ) > > Please also note the questions at the end of the article. We are looking > forward to your feedback. I've been looking into this application but there seems to be no progress. Am I doing something wrong or is it no data to be search for by this application? http://lab.db.ripe.net/portal/abuse-finder.htm If I'm doing something wrong, could someone give a quick walk through how to use it? PS. I've read all the other mail on the mail list regarding finding abuse contacts. DS. regards, /bengan From kzorba at otenet.gr Tue Aug 17 16:16:50 2010 From: kzorba at otenet.gr (Kostas Zorbadelos) Date: Tue, 17 Aug 2010 17:16:50 +0300 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: <201008171716.50795.kzorba@otenet.gr> On Friday 23 July 2010 17:57:21 Emanuele Balla wrote: > 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 am a bit skeptic about the creation of a single-point of failure that can be target of attacks with the gain being that the actual abuse addresses are not disclosed. This can cause more harm than good. Using public role accounts seems simpler. Kostas Zorbadelos > -- > # 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 kzorba at otenet.gr Tue Aug 17 16:56:15 2010 From: kzorba at otenet.gr (Kostas Zorbadelos) Date: Tue, 17 Aug 2010 17:56:15 +0300 Subject: [anti-abuse-wg] Working group focus In-Reply-To: References: Message-ID: <201008171756.15590.kzorba@otenet.gr> On Thursday 08 July 2010 11:16:56 Richard Cox wrote: > 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 alone can be a very good reason to attend RIPE meetings. It is an effort that should be sustained and extended. If worked properly the 2-hour timeslot in the meeting schedule will not be enough I guess :) > 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. This is an area the WG can do much better I think. For example in my case, information about best current practices in minimizing spam originating from a provider's network was found elsewhere such as the MAAWG [1], ETIS [2] or ENISA [3] and of course various contacts with antispam vendors. > (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. ? Yes, this is a problem. However it can be also viewed as a chicken-and-egg problem. If the community produces specific results, corporate managements can be convinced to focus and address the issues with a higher priority. And speaking of managements, education plus having supportive documentation and "pressure" from a respected public community in an area can be of help. > 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. > Of course you are right. Kostas > -- > Richard Cox > The Other Co-chair, RIPE Anti-Abuse WG [1] http://www.maawg.org/ [2] http://www.etis.org/ [3] http://www.enisa.europa.eu/ From kzorba at otenet.gr Tue Aug 17 16:09:42 2010 From: kzorba at otenet.gr (Kostas Zorbadelos) Date: Tue, 17 Aug 2010 17:09:42 +0300 Subject: [anti-abuse-wg] Abuse Contact Information - Policy Proposal In-Reply-To: <4C49A7E5.9000403@abusix.com> References: <4C49A7E5.9000403@abusix.com> Message-ID: <201008171709.42403.kzorba@otenet.gr> On Friday 23 July 2010 17:32:05 Tobias Knecht wrote: Tobias, > 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. > Best practice papers and documents should be I think one of the main purposes of an anti-abuse WG. I believe there is a lot of room for improvement in this area in this WG. > 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. > I am not sure sure if there are any "better" ways to achieve the result of having an abuse contact for all network ranges allocated in the RIPE region. There is however such a need which is not served now and your proposal of introducing one clear way to publish the information plus making it mandatory as a next step seems quite reasonable to me. Therefore I support your proposals. A general problem I find in this community, is that I see a lot of talk about issues and very little action. Clearly, abuse issues are not simple and there are no silver bullets, but I believe consensus on relatively small sub-areas can be reached and actions should be tried. This is a personal opinion of course and I would be interested to hear others on this subject. Do you have any schedule for the policy formation and submission? > Thanks, > > Tobias Regards Kostas PS: as a small personal experience, trying the abuse-finder tool of RIPE for spam arriving on my inbox, in most cases returns no abuse contact result. I guess this is a problem of data missing rather an error in the tool's logic. From phade at www.powerweb.de Tue Aug 17 18:13:35 2010 From: phade at www.powerweb.de (Frank Gadegast) Date: Tue, 17 Aug 2010 18:13:35 +0200 (MET DST) Subject: [anti-abuse-wg] Working group focus In-Reply-To: <201008171756.15590.kzorba@otenet.gr> Message-ID: <201008171613.o7HGDZ2k001351@www.powerweb.de> > > > 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. > > > > Of course you are right. Partly yes, but there are more ways ... One is the make it easier to seperate good from the eval, standards like SPF or signed emails help a lot there and there are enough other methods in development out there ... Another way is to make providers more aware of there network leaks and abused customers PCs and to have them to take more responsibility. A general abuse address was addressed by my proposal only two month ago but it kind of failed, simply because nobody supported it and RIPE NCC will never invest in the their infrastructure and people resources, when there is no will in the community. (we even dont really know, if the community WANTs to solve the spam problem.) Its easy, when its cheaper for RIPEs members to stuff their holes, restrict their users, automate monitoring of abuse in their networks aso than reacting to all those abuse reports they currently CAN ignore, they will close their systems and this will make it much more complicated and surely more expensive to spammers, so it will reduce the problem, if we can force RIPEs members to take responsibility. And: a general abuse email address that HAS to be read and WORKED with IS a good first step. I dont think that the SPOF problem really exists, email is really robust, can be delivered via a lot of servers that are fail tolerant and can handle peeks. Bill Gates still receives eMails, and I dont want to know, how much Microsofts servers are attacked every day :o) 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 > > Kostas > > > -- > > Richard Cox > > The Other Co-chair, RIPE Anti-Abuse WG > > [1] http://www.maawg.org/ > [2] http://www.etis.org/ > [3] http://www.enisa.europa.eu/ > > From artiren at gmail.com Thu Aug 19 11:57:14 2010 From: artiren at gmail.com (Artem Irenkov) Date: Thu, 19 Aug 2010 12:57:14 +0300 Subject: [anti-abuse-wg] Illegal information in your database Message-ID: <9610284802.20100819125714@gmail.com> Hello, in your database appeared the information that the pool of IP addresses 78.109.20.194 - 78.109.20.199 belongs to me - Artem Irenkov and my home address is mentioned either. It is not true, I do not have any relationship to these IP-addresses. Please delete this information from your database. Best Regards, Artem Irenkov. From sergey at devnull.ru Thu Aug 19 12:18:17 2010 From: sergey at devnull.ru (Sergey Myasoedov) Date: Thu, 19 Aug 2010 12:18:17 +0200 Subject: [anti-abuse-wg] Illegal information in your database In-Reply-To: <9610284802.20100819125714@gmail.com> References: <9610284802.20100819125714@gmail.com> Message-ID: <1267340505.20100819121817@devnull.ru> Artem, this assignment was made in November 2009. Was this network belong to you since November? Anyway, you have to contact Tehnologii Budushego LLC (hosting.ua) to perform the changes and not the working group mailing list. The information in the database is not illegal, but can be incorrect. -- Sergey Thursday, August 19, 2010, 11:57:14 AM, you wrote: AI> Hello, AI> in your database appeared the information that the pool of IP addresses AI> 78.109.20.194 - 78.109.20.199 belongs to me - Artem Irenkov and my home AI> address is mentioned either. AI> It is not true, I do not have any relationship to these IP-addresses. AI> Please delete this information from your database. AI> Best Regards, Artem Irenkov. From frank at altpeter.de Thu Aug 19 12:27:34 2010 From: frank at altpeter.de (Frank Altpeter) Date: Thu, 19 Aug 2010 12:27:34 +0200 Subject: [anti-abuse-wg] Illegal information in your database In-Reply-To: <9610284802.20100819125714@gmail.com> References: <9610284802.20100819125714@gmail.com> Message-ID: <20100819102733.GA20586@pegasus.dyndns.info> Moin, on 2010-08-19 at 11:57:14 CEST, Artem Irenkov wrote: > Hello, > > in your database appeared the information that the pool of IP addresses > 78.109.20.194 - 78.109.20.199 belongs to me - Artem Irenkov and my home > address is mentioned either. > > It is not true, I do not have any relationship to these IP-addresses. > Please delete this information from your database. > > Best Regards, Artem Irenkov. > I don't think that this discussion list is the right place for such requests. According to the mentioned whois output you should contact ripe at hosting.ua and/or abuse at hosting.ua for help. They maintain the inetnum object. We don't. Mit freundlichen Gr??en, Frank Altpeter -- FA-RIPE || http://www.altpeter.de/ Viva la evolution Jetzt kostenlos bei XING anmelden: http://www.xing.com/go/invite/27666.2a971e -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 230 bytes Desc: not available URL: