November 2010 - anti-abuse-wg

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

Draft Agenda - AA-WG Session RIPE 61
by Brian Nisbet 02 Nov '10

02 Nov '10

Colleagues, This is the draft agenda for the meeting in Rome. If anyone has anything they'd like to add, it's not too late! Anti-Abuse Working Group Agenda - RIPE 61 A. Administrative Matters * Welcome * Select a scribe * Jabber Monitor * Microphone Etiquette * Approve Minutes from RIPE 60 * Finalise agenda B. Update * B1. Network Abuse Update - Richard Cox * B2. Recent List Discussion - Reporting Fraud, Database Issues etc. * B3. Registrar Issues - Michele Neylon, Blacknight * B4. RIPE NCC Draft Closure Agreement/Service Abuse C. Policies D. Interactions * D1. Working Groups * D2. CCWP * D3. RIPE NCC Gov/LEA Interactions Update X. A.O.B. Z. Agenda for RIPE 62; Plenary Presentations

1 0

Draft Document: "Closure of LIR and Deregistration of Internet Number Resources"
by Axel Pawlik 02 Nov '10

02 Nov '10

[Apologies for duplicate emails] Dear colleagues, The RIPE NCC, in consultation with external legal experts, created the draft procedural document, "Closure of LIR and Deregistration of Internet Number Resources". A PDF of the document is available at: http://www.ripe.net/legal/Closure-of-LIR-and-deregistration-of-INRs_final-d… The text of this document is intended to replace sections in two RIPE Documents that deal with the closure of LIRs and the deregistration of resources: - Sections 3.0 and 4.0 of ripe-301, "Mergers, Acquisitions, Takeovers and Closures of Organisations Operating an LIR". These sections are entitled "Closing an LIR" and "When an LIR is Closed by the RIPE NCC", respectively. The original RIPE Document is available at: http://www.ripe.net/ripe/docs/mergers.html - Section 4.2 of ripe-475, "Independent Internet Number Resources - Contractual Relationship Changes between sponsoring LIR and End User". This section is entitled "Violation of RIPE Policy, Law or Contract". The original RIPE Document is available at: http://www.ripe.net/ripe/docs/ripe-475.html The RIPE NCC would like to receive feedback on this draft document from its members and the RIPE community. The RIPE NCC members and the RIPE community will have the opportunity to discuss the document on the mailing lists and at the RIPE NCC Services Working Group to be held on 17 November at the RIPE 61 Meeting in Rome. Best regards, Axel Pawlik Managing Director RIPE NCC

1 0

Finally, a Canadian Pharmacy in... Canada!
by Ronald F. Guilmette 01 Nov '10

01 Nov '10

Had to happen eventually... Canadian Health&Care Mall web site that's the WHOIS records indicate is actually hosted in... Canada! Of course, it _is_ the part of Canada that was annexed by the Ukraine, so there's that. www.canadianhealthcaremall.net == 109.72.146.38 TRACEROUTE (using port 80/tcp) HOP RTT ADDRESS 1 51.06 ms 3.255-62-69.res.dyn.surewest.net (69.62.255.3) 2 50.80 ms 172.21.2.57 3 49.56 ms 172.21.0.250 4 48.60 ms 245.98-30-64.ftth.swbr.surewest.net (64.30.98.245) 5 47.86 ms te-4-1.car1.Sacramento1.Level3.net (4.53.200.9) 6 46.40 ms ae-11-11.car2.Sacramento1.Level3.net (4.69.132.150) 7 52.54 ms ae-4-4.ebr2.SanJose1.Level3.net (4.69.132.158) 8 58.01 ms ae-82-82.csw3.SanJose1.Level3.net (4.69.134.218) 9 47.39 ms ae-74-74.ebr4.SanJose1.Level3.net (4.69.134.245) 10 112.23 ms ae-2-2.ebr2.NewYork1.Level3.net (4.69.135.186) 11 113.03 ms ae-6-6.ebr2.NewYork2.Level3.net (4.69.141.22) 12 114.43 ms ae-1-100.ebr1.NewYork2.Level3.net (4.69.135.253) 13 121.82 ms ae-3-3.ebr2.Washington1.Level3.net (4.69.132.89) 14 211.52 ms ae-43-43.ebr2.Frankfurt1.Level3.net (4.69.137.57) 15 217.17 ms ae-72-72.csw2.Frankfurt1.Level3.net (4.69.140.22) 16 212.96 ms ae-71-71.ebr1.Frankfurt1.Level3.net (4.69.140.5) 17 229.44 ms ae-1-12.bar1.Budapest1.Level3.net (4.69.141.249) 18 284.67 ms UKRTELECOM.bar1.Budapest1.Level3.net (212.162.26.6) 19 ... 20 241.85 ms 213.186.119.74.utel.net.ua (213.186.119.74) 21 246.26 ms 109.72.146.38 ========================================================================= % 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 % Information related to '109.72.144.0 - 109.72.151.255' inetnum: 109.72.144.0 - 109.72.151.255 netname: TANGRAM-CA descr: Main colocation pool country: EU admin-c: tang2-ripe tech-c: tcnc-ripe status: ASSIGNED PA mnt-by: TANGRAM-MNT mnt-routes: TANGRAM-MNT mnt-routes: AS6849-MNT changed: taras(a)tangramltd.com 20100825 source: RIPE role: Tangram NOC address: Canada, Etobicoke, Ontario M9A 4X7 address: 24 Mabelle ave. e-mail: noc(a)tangram.ws remarks: Contact information: remarks: Network security issues: abuse(a)tangram.ws remarks: Routing and peering issues: noc(a)tangram.ws remarks: Domain name system questions: noc(a)tangram.ws remarks: Mail system issues: postmaster(a)tangram.ws abuse-mailbox: abuse(a)tangram.ws admin-c: tang2-ripe tech-c: nale-ripe tech-c: SAP69-RIPE nic-hdl: tcnc-ripe mnt-by: TANGRAM-MNT changed: taras(a)tangramltd.com 20091027 source: RIPE person: Tsebro Oleksandr address: Canada, Etobicoke, Ontario M9A 4X7 address: 24 Mabelle ave. phone: +1 877 5319597 e-mail: alex(a)tangram.ws nic-hdl: tang2-ripe mnt-by: TANGRAM-MNT changed: yuriy(a)tangramltd.com 20090914 source: RIPE

2 1