- anti-abuse-wg - mailman.ripe.net

Support of, and comments on, proposal 2010-08
by Vissers, Pepijn 17 Nov '10

17 Nov '10

Dear list, On behalf of the Team Internetsafety of the Dutch Telecommunications Authority OPTA, I would like to comment on the draft proposal 2010-08. The Team Internetsafety conducts spam- and malware investigations related to the Netherlands. Almost all of these investigations have components which require us to use RIPE (or other RIRs) for several pieces of information, most commonly valid abuse contacts for a netblock or ASN. We strongly support the mandatory addition of an abuse-mailbox: field in the irt object. However, we see several loopholes in the current contents of the proposal. 1. There is no mention in the policy about the validity of an abuse-mailbox: entry 2. There is no mention in the policy about the responsiveness of an abuse-mailbox: entry 3. There is (logically) no mention in the policy about a periodic check on (1) and (2) 4. There is no mitigating procedure in case of false/missing/invalid/... abuse-mailbox: information Ad 1: What will stop a RIPE member from entering an invalid e-mail address? If the purpose of the policy is to 'solve the problem of finding the right abuse contact', some additional procedure should be in place to make sure mail to the mentioned abuse-mailbox: does actually arrive somewhere and does not bounce. Ad 2: A valid e-mail address is no guarantee that abuse mail is being handled or even looked at. Although we recognize it might not be the responsibility of RIPE to ensure a maintainer has a proper abuse policy mechanism in place, we'd encourage some additional reflection on this issue. Ad 3: Requiring a field update with each object update is a good idea, however with largely static objects it might be a good idea to periodically check at least (1) and preferably (2). Ad 4: If a member (systematically) does not adhere to the mandatory policy, some kind of procedure should be in place to motivate the member to follow procedure. Without 'repercussions', a 'mandatory' policy becomes just mandatory in name, not in function. Kind regards, Pepijn Vissers Team Internetsafety OPTA - +++++++++++++++++++++++++++++++++++++++++++++ Disclaimer Dit e-mailbericht kan vertrouwelijke informatie bevatten of informatie die is beschermd door een beroepsgeheim. Indien dit bericht niet voor u is bestemd, wijzen wij u erop dat elke vorm van verspreiding, vermenigvuldiging of ander gebruik ervan niet is toegestaan. Indien dit bericht blijkbaar bij vergissing bij u terecht is gekomen, verzoeken wij u ons daarvan direct op de hoogte te stellen via tel.nr 070 315 3500 of e-mail mailto:mail@opta.nl en het bericht te vernietigen. Dit e-mailbericht is uitsluitend gecontroleerd op virussen. OPTA aanvaardt geen enkele aansprakelijkheid voor de feitelijke inhoud en juistheid van dit bericht en er kunnen geen rechten aan worden ontleend. This e-mail message may contain confidential information or information protected by professional privilege. If it is not intended for you, you should be aware that any distribution, copying or other form of use of this message is not permitted. If it has apparently reached you by mistake, we urge you to notify us by phone +31 70 315 3500 or e-mail mailto:mail@opta.nl and destroy the message immediately. This e-mail message has only been checked for viruses. The accuracy, relevance, timeliness or completeness of the information provided cannot be guaranteed. OPTA expressly disclaims any responsibility in relation to the information in this e-mail message. No rights can be derived from this message.

4 5

2010-10 New Policy Proposal (Adding reference to sponsoring LIR in inetnum, inet6num and aut-num objects)
by Emilio Madaio 17 Nov '10

17 Nov '10

Dear Colleagues, A proposed change to RIPE Document ripe-452,"Contractual Requirements for Provider Independent Resource Holders in the RIPE NCC Service Region", is now available for discussion. You can find the full proposal at: http://ripe.net/ripe/policies/proposals/2010-10.html We encourage you to review this proposal and send your comments to <anti-abuse-wg(a)ripe.net> before 10 December 2010. Regards Emilio Madaio Policy Development Officer RIPE NCC

9 10

Request if Informations
by Carloalberto Sartor 17 Nov '10

17 Nov '10

Hi, I don't know if you are the correct contact for this kind of abuse. I have a great problem like this. The site attention-swindlers.com is registered by an identity theft. The apparent registrant, mr. Mokrane, reports me that he never registered that site. In that site there is an hard defamation about him, the Vatican State, and so on. This confirms that he isn't the true registrant. I wrote to nic.ru asking them to obscure site and domain, explaining the case (that involves diplomatic problems, I remark!). They repeated that I have to contact site admin and to solve the problem contracting with him and that they can't do nothing. I'll move an italian lawyer and activate the international legal procedure and surely with long time, I will obtain the end of this site but between the action and the solution the site will enter into search engines and so on... What can I do to stop this abuse? Thanks for you kind response!!! -- Carloalberto Sartor Digitalexpert.it, Consulenze informatiche Via Astichelli 14 - 36031 Dueville (VI) Tel.: 0444592675 Cell.: 3492517691 www.digitalexpert.it (generale, EMON ) www.descmain.it (monitoring apps) Consigli per gli acquisti: Usa "UBI ES" per posta con allegati giganti Usa "EMON" per il monitoraggio dei sistemi Usa "EBAK" per i tuo backup senza pensieri Usa "SeSi" per la sicurezza informatica Usa tanta pazienza con i computer!!!

2 1

2010-08 New Policy Proposal (Abuse contact information)
by Emilio Madaio 12 Nov '10

12 Nov '10

Dear Colleagues, A new RIPE Policy Proposal has been made and is now available for discussion. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2010-08.html We encourage you to review this proposal and send your comments to <anti-abuse-wg(a)ripe.net> before 6 December 2010. Regards Emilio Madaio Policy Development Officer RIPE NCC

16 81

Re: [anti-abuse-wg] 2010-08 New Policy Proposal (Abuse contact
by Frank Gadegast 12 Nov '10

12 Nov '10

Piotr Strzyzewski wrote: >>>> Im happy when we change the inetnum to have an mandatory abuse-mailbox-field, >>>> but thats nearly the same than the IRT-object. >>> >>> Exept we will save some time and resources. >> >> Really ? >> You cannot convert personal abuse-mail-fields to the inetnum automatically, >> this would be unlogical, because the intention of the LIR >> could have been different. >> >> So, all LIRs will have the same work with an INETNUM-abuse-field >> then with an IRT object. >> >> And then I like IRT better, because its intention was to take care >> of abuse anyway, and you need to change only ONE (or a couple) >> of IRT objects, when things changing ... > > One more time - some pros from the original email: > > - Reduced resource consumption: there will be no extra objects in DB (we > save some disk space) and there will be no extra references (we save > some whois servers' processors time). Both means: we save some money. :) Not at all. Modern databases will use less resources when referencing objects from other tables instead of copying information to many other objects. Using the IRT object will save resources. Furthermore: the definition of the IRT object does not to be changed. Simply that the abuse-field is mandatory in the future, and that a link to all INETNUM objects to an IRT object is required. Sounds pretty easy to implement ... > - IRT object still can be used as it is used right now (if LIR want's to > monitor abuse, even if the inet(6)num or aut-num is handled by its > customer) That will be confusing for everybody. What we want to achieve is a single place for the abuse contact, instead of spreading it in remarks, abuse-mailbox-fields in personal or INETNUM objects. Thats why a mandatory IRT object is the better solution to my opinion. > >>>> I personally simply want a mandatory abuse email address I can query without limitations, >>>> whatever way this is achieved, I will like it. >>> >>> As Tobias said - we all agree about "single point of abuse contact >>> information". What community disagree is this idea about IRT. >> >> Dont think that the community dont like IRT, looks to me more that >> they prever it, instead of in INETNUM. > > I don't agree with that point of view. Maybe some mails from others should make that clear. What does everybody like more ? IRT ? INETNUM ? >> Inserting it in INETNUM is no single point. > > It is single for this inetnum. It is not single for you. That's true. > >> When I like to change our abuse(a)powerweb.de to lets say >> complain(a)powerweb.de, I will have to change ALL INETNUM objects. >> I would not like that ... > > Good point - why not to mail it on the mailing list as a response to my > email? Just did. > But, I still believe this could be done relatively easy with simple > script. Yep, I thought that also for the needed updates with the IRT object, big LIRs should be able to insert the link and remove their remarks and other abuse-mailbox-fields pretty easily. But inserting the abuse email into the INETNUM object would mean, that nearly every small LIR also has to do scripting, it might be easier for the majority of the members to change their old objects once and then have a single IRT object for the future ... BTW: I have no opinion for you proposal under http://www.ripe.net/ripe/policies/proposals/2010-10.html yet, but find the following really interesting: "A clear statement that the resources will return by default to the RIPE NCC if the resource holder cannot be contacted". Im having hopes, if we put that together with Tobias' http://www.ripe.net/ripe/policies/proposals/2010-09.html (BIG SMILE) Kind regards, Frank -- PHADE Software - PowerWeb http://www.powerweb.de Inh. Dipl.-Inform. Frank Gadegast mailto:frank@powerweb.de Schinkelstrasse 17 fon: +49 33200 52920 14558 Nuthetal OT Rehbruecke, Germany fax: +49 33200 52921 ====================================================================== Public PGP Key available for frank(a)powerweb.de

2 3

Policies 2010-08 & 2010-09 at RIPE 61
by Brian Nisbet 09 Nov '10

09 Nov '10

Colleagues, Just to confirm that some time will be made available for discussion of these policies next week in Rome. That doesn't, of course, take away from the primacy of the mailing list as the discussion/decison space, but I just wanted to state it in case anyone was wondering. Thanks, Brian.

2 1

Re: [policy-announce] 2010-08 New Policy Proposal (Abuse contact information)
by Marcus Stoegbauer 09 Nov '10

09 Nov '10

Hi, On 08.11.10 16:14, Emilio Madaio wrote: > Dear Colleagues, > > A new RIPE Policy Proposal has been made and is now available for > discussion. [mandatory reference to irt objects in the inetnum, inet6num and aut-num objects in the RIPE Database] assuming I used the right keywords, I get the following numbers from a recent version of the ripe.db: lysis@ra:~$ egrep -c '^org-type: *LIR' ripe.db 8838 lysis@ra:~$ grep -c ^irt: ripe.db 216 So nearly 9000 LIRs and 216 irt objects registered. Let us assume for a minute that only 50% of those LIRs are interested in creating inet[6]nums for assigning IP addresses to their customers. So your proposal is basically saying: 4300 LIRs should each write an e-mail to RIPE NCC explaining how they handle abuse in their organization and requesting an irt object and RIPE NCC should evaluate all those requests in a rather prolonged process. Furthermore, all future PI assignments to end users need to have an irt reference, so all new PI holders also need to form an abuse team and document this accordingly through the RIPE NCC. I am also very curious how PI assignments to individual persons will form such an abuse team. Although there is a "me" in team I don't think this will work. In conclusion: Really? Kind regards, Marcus -- man-da.de GmbH, AS8365 Phone: +49 6151 16-6956 Petersenstr. 30 Fax: +49 6151 16-3050 D-64287 Darmstadt e-mail: ms(a)man-da.de Geschäftsführer Marcus Stögbauer AG Darmstadt, HRB 94 84

3 3

Re: 2010-08 New Policy Proposal (Abuse contact information)
by Richard Hartmann 09 Nov '10

09 Nov '10

Sorry for not replying in-thread, I don't have the correct email in this account. I whole-heartedly agree with 2010-08, though I still think abuse-c would have been a better name. While the person object of an abuse-c is not 100% appropriate for a group, itr expands to incident response team. What is an incident that needs to be reported to the itr? Spam, yes. Cracking, yes. DoS, yes. But what de-announcing a prefix? That would need to go to the NOC. admin-c would perfectly describe this distinction. All that being said, what's done's done. To get to the part where I stop babbling and give (hopefully) useful feedback: I really like the proposal, but I think the English could be improved. As it is, it reads a bit strained and is not 100% correct, imo. As it is, the text can be interpreted to require an update of irt on all updates of referencing objects which is obviously not Tobias' intention. Anyway, here goes: ---8<--- 1. Compulsory IRT Object A reference to an irt object is mandatory for the following RIPE database objects: inetnum, inet6num, and aut-num. All newly created and updated objects of these types must reference an irt object. The "abuse-mailbox" attribute is mandatory for all irt objects. Addition of an "abuse-mailbox" attribute in a non-irt object will be rejected. All "abuse-mailbox" attributes in non-irt objects will be deleted by the end of 2012. ---8<--- As an aside, what happens when I update a non-irt object which has a legacy abuse-mailbox attribute without touching it? Will this be rejected or allowed? 2010-08 does not answer this question. which should be fixed, imo. Thanks, especially to Tobias, Richard

3 2

There is no email contact to report spam
by Gary Vodvarka 08 Nov '10

08 Nov '10

Whois has started ... % This is the RIPE Database query service. % The objects are in RPSL format. % % The RIPE Database is subject to Terms and Conditions. % See http://www.ripe.net/db/support/db-terms-conditions.pdf % Note: This output has been filtered. % To receive output for a database update, use the "-B" flag. % Information related to '89.218.30.0 - 89.218.30.255' inetnum: 89.218.30.0 - 89.218.30.255 netname: ALMATYTELECOM descr: JSC Kazakhtelecom, Almaty Affiliate country: KZ admin-c: OR708-RIPE tech-c: OR708-RIPE status: ASSIGNED PA mnt-by: KNIC-MNT source: RIPE # Filtered person: Olga Reshetnyak address: JSC Kazakhtelecom, Almaty Affiliate address: Panfilov 74/72 str. 050004 address: Almaty address: Kazakhstan phone: +7 727 2736677 phone: +7 727 2710290 nic-hdl: OR708-RIPE source: RIPE # Filtered % Information related to '89.218.0.0/16AS9198' route: 89.218.0.0/16 descr: Kazakhtelecom Data Network Administration origin: AS9198 mnt-by: KNIC-MNT source: RIPE # Filtered % Information related to '89.218.30.0/24AS9198' route: 89.218.30.0/24 descr: Kazakhtelecom Megaline Almaty Network origin: AS9198 mnt-by: KNIC-MNT source: RIPE # Filtered % Information related to '89.218.0.0/19AS9198' route: 89.218.0.0/19 descr: Kazakhtelecom Data Network Administration origin: AS9198 mnt-by: KNIC-MNT source: RIPE # Filtered From: a_illavr(a)elad.co.il Subject: Be a LONG-man, buy this effective herbal EnlargementPills njq Date: November 8, 2010 2:31:38 AM PST To: gvodvarka(a)independentelectronics.com Reply-To: a_illavr(a)elad.co.il X-Envelope-From: a_illavr(a)elad.co.il Return-Path: <a_illavr(a)elad.co.il> Received: from myfhav ([89.218.30.36]) by mail25c25.carrierzone.com (8.13.6/8.13.1) with ESMTP id oA89ZjYu012749; Mon, 8 Nov 2010 04:36:13 -0500 Message-Id: <4CD7D18A.FC8E332D(a)elad.co.il> Sender: <a_illavr(a)elad.co.il> In-Reply-To: <e52801cb7ad0$2bfc819b$82e6e383@0oegf82> Mime-Version: 1.0 X-Sender: <a_illavr(a)elad.co.il> Content-Type: multipart/alternative; boundary="---- =_Part_26034_09D6_C82FF2BA.80216406" User-Agent: Mozilla/5.019 (Windows; U; NT4.0; U; NT4.0; en-us) Gecko/ 25250101 X-Accept-Language: en X-Mmr: 1 X-Csc: 100 X-Cha: v=1.1 cv=KrRviuykSTkSVsZRpK7OSRMYDmynR1rdVDp85VFp9w0= c=1 sm=1 p=L0kI9mEkAAAA:8 p=Ttymt33q7vk8JNQ5vvtAwDItcqIA:4 a=Ex0hX9_auY0A: 10 a=+FP2pi8CjQ0MV9UEcncBMg==:17 a=R-bjttS1Dz7pmrM3oagA:9 a=pn4Y1YDKl2xruIvj0SyFugq2hnUA:4 a=CjuIK1q_8ugA:10 a=qbEVF31rf57ft9UH2sYA:9 a=hq4mdgjE7NsLuDVACUAA:7 a= +FP2pi8CjQ0MV9UEcncBMg==:117

2 1

New RIPE Database Prototype - on RIPE Labs
by Mirjam Kuehne 04 Nov '10

04 Nov '10

[apologies for duplicates] Dear colleagues, The RIPE NCC is improving the RIPE Database functionality and usability by introducing a trial of an improved service. With this new service it is easier for any user to see which of the data objects they’re looking at are maintained by the RIPE NCC or an Internet resource holder. Please read more on RIPE Labs: http://labs.ripe.net/Members/Paul_P_/a-new-ripe-database-prototype Kind Regards, Mirjam Kuehne RIPE NCC

1 0