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

abuse-c + org / inetnum
by Gilles Massen 19 Oct '13

19 Oct '13

Dear WGs, In the light of the upcoming RIPE meeting I'd like to bring the problem of a single entity (organisation) wanting different abuse-c for different resources up again. The discussion starting in June (http://www.ripe.net/ripe/mail/archives/db-wg/2013-June/004079.html ) was rather open ended. Apparently the only workable solution at this point is to create a duplicate organisation object with a different abuse-c. Is data duplication really the solution that the WGs would like? Gilles -- Fondation RESTENA - DNS-LU 6, rue Coudenhove-Kalergi L-1359 Luxembourg tel: (+352) 424409 fax: (+352) 422473

4 4

contradictory abuse contacts and some stats
by Frank Gadegast 17 Oct '13

17 Oct '13

Hi, we realize more and more networks having an abuse-c now, but also realize that most networks now have contradictory abuse email addresses spreaded in between new abuse contacts or old remarks or abuse-mailbox-fields. Might be a good idea to contact alls memmbers and LIR again to fix their records now ... Find some stats from our blacklist attached, it shows basically, that there is no big effort to be seen from spammers or spam friendly or ignorant LIRs to use the new abuse-c, the percentage of networks that are sending spam AND having an abuse-c contact is going up and down, but has not even reached 50% ... Pretty poor. Kind regards, Frank -- MOTD: "have you enabled SSL on a website or mailbox today ?" -- 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 ======================================================================

2 1

Call for feedback on 2013-01: Openness about Policy Violations
by Sander Steffann 17 Oct '13

17 Oct '13

Hello working group, We (the authors of 2013-01) are not sure how to continue with our policy proposal. To refresh your memories here is the summary of the proposal: > The RIPE NCC is the membership organisation that manages the shared public resources of IP addresses and Autonomous System Numbers in its service region. This proposal makes complaints about delegated resources more visible. It also specifies a separate list that documents all reclaimed resources. > > The goals are to provide more insight into the good stewardship of the RIPE NCC and to encourage assistance in stopping abuse of these shared public resources. > > This proposal explicitly does not set or change any policies about assignment, allocation or revocation of these resources. The latest version of the proposal hasn't received any feedback for the working group. Is this still something this working group wants, or should we withdraw the proposal? If you want this policy proposal to go forward: please speak up before the 17th of November If we receive no significant support then the authors will withdraw the policy proposal. Thank you, Sander Steffann Shane Kerr A.k.a. the authors of 2013-01

1 0

Re: [anti-abuse-wg] [db-wg] abuse-c + org / inetnum
by Elvis Velea 10 Oct '13

10 Oct '13

Hi, On 10/10/13 5:50 PM, Sebastian Wiesinger wrote: > * Gert Doering <gert(a)space.net> [2013-10-08 13:33]: >> Hi, >> >> On Mon, Oct 07, 2013 at 11:00:28PM +0200, Gilles Massen wrote: >>> Something else in mind: as before: allow abuse-c for inet*num. Prefer >> >> This. >> >> (But I've said this before :-) - I do not see it as a useful excercise >> having to create an organization: object for the sole purpose of being >> able to have a different abuse-c: for some inet(6)num object) > > ++++++1 I think that having the abuse-c role linked to the org object was a great idea. I also understand that some organisation may want to have different abuse contacts/roles defined for different IP blocks. One way on how this could be fixed, in my opinion, is by allowing an abuse-c role to be referenced in the inet*num object (but only if the inet*num object references an org that already has an abuse-c role referenced). In this case, the general abuse-c would be the one referenced in the org and the 'local' abuse-c would be the role referenced in the inet*num object. cheers, elvis

1 0

RIPE67 AA-WG Agenda - Latest
by Brian Nisbet 09 Oct '13

09 Oct '13

Morning (where I am, certainly), We've made a small tweak to the AA-WG agenda for Thursday of next week, swapping some items around and I just wanted to update you all: https://ripe67.ripe.net/programme/meeting-plan/anti-abuse-wg/ Thursday, 17 October 14:00 – 15:30 A. Administrative Matters - Welcome - Scribe, Jabber, Stenography - Microphone Etiquette - Approve Minutes from RIPE 66 - Finalise agenda B. Policies - RIPE Policy 2011-06 Update, RIPE NCC - RIPE Policy Proposal 2013-01 C. Update - C1. Recent List Discussion - C2. AA-WG Charter D. Interactions - D1. Working Groups - D2. RIPE NCC Gov/LEA Interactions Update E. Presentation - E1. ACDC Project - E2. x-arf – Tobias Knecht X. A.O.B. Z. Agenda for RIPE 68 Obviously if anyone does have any last minute additions to the agenda, please let Tobias and I know. Brian

1 0

Yahoo Spamcop (spamcop@mailservices.yahoo.com)
by Reza Farzan 05 Sep '13

05 Sep '13

Hello All, Does anyone know what is going on at Yahoo, where Spammers can create e-mails without any impunity, and where all complaints submitted to Yahoo Spamcop (spamcop(a)mailservices.yahoo.com) all end up at Yahoo! Small Business [yahoosmb(a)cc.yahoo-inc.com]? Every Spam report that I send to Yahoo comes back with this automated response: * Thanks for contacting Yahoo!. Unfortunately, this address cannot accept direct reports of spam. If Yahoo Spamcop has become a meaningless source for complaining against Yahoo related Spammers, then where should one go to report such violations? As always, I welcome your comments and suggestions. Thank you, Reza Farzan rezaf(a)mindspring.com

2 1

Draft Agenda, RIPE 67
by Brian Nisbet 04 Sep '13

04 Sep '13

Colleagues, Here is the draft agenda for the WG session at RIPE 67. This will be happening at 14:00 EEST on Thursday 17th October. The agenda is shaping up nicely, but if you have any additional items you'd like to see on there, please let us know. A. Administrative Matters * Welcome * Scribe, Jabber, Stenography * Microphone Etiquette * Approve Minutes from RIPE 66 * Finalise agenda B. Update * B1. Recent List Discussion * B2. AA-WG Charter C. Policies * RIPE Policy 2011-06 Update, RIPE NCC * RIPE Policy Proposal 2013-01 D. Interactions * D1. Working Groups * D3. RIPE NCC Gov/LEA Interactions Update E. Presentation * E1. ACDC Project * E2. Internet Bad Neighborhoods - Giovane Moura * E2. x-arf - Tobias Knecht X. A.O.B. Z. Agenda for RIPE 68

1 0

New on RIPE Labs: All IP Addresses Are Not The Same (by Geoff Huston)
by Mirjam Kuehne 02 Sep '13

02 Sep '13

Dear colleagues, We published a new article by Geoff Huston on RIPE Labs that you might find interesting: All IP Addresses Are Not The Same https://labs.ripe.net/Members/gih/all-ip-addresses-are-not-the-same Kind regards, Mirjam Kuehne RIPE NCC

1 0

Clarification Regarding Needs Assessment and Audits
by Andrew de la Haye 02 Sep '13

02 Sep '13

Dear colleagues, We have been following the recent discussions on the mailing list and would like to offer clarification in relation to a couple of points that were raised. According to "IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region" [1], address space is distributed based on demonstrated technical need in order to deliver services. This need is evaluated according to addressing requirements, network infrastructure, equipment and number of customers. The exact services for which the resources are being requested are not considered as part of the evaluation process. As an example, if address space is requested for the technical need of a mail server, it is not verified what type of mails are being sent through that server. This practice is in line with the current IPv4 policy [1]. It is important to note that technical need is evaluated for assignments. The need for an additional allocation is considered based on past and future usage, taking into account all assignments that have been made by the LIR previously. The RIPE NCC does not have a mandate to deregister allocations if the expected growth was less or different than expected. Nevertheless, we do see LIRs voluntarily returning allocations in the event that they no longer have a need for the addresses. As above, this practice is based on current RIPE Policies. When a policy is changed through the RIPE Policy Development Process (PDP) [2], we adjust our processes accordingly. When the RIPE NCC conducts an audit of an LIR, it checks that: - RIPE Policies are followed correctly - Assignments are registered properly and being used for the purpose they were requested for (if not, the technical need is re-evaluated) - Contact information is still correct An LIR is either randomly selected for an audit, or selected following a community report against that member [3]. Last year, the RIPE NCC created a report form to facilitate and simplify reporting on policy violations, provision of untruthful information to the RIPE NCC and incorrect RIPE Database data [4]. Once the reported information and evidence is evaluated, the RIPE NCC investigates the claim and proceeds according to RIPE Policies and RIPE NCC procedures. This can result in address space being deregistered. More detailed information on reasons for deregistration of address space is available in "Closure of Member and Deregistration of Internet Number Resources" [5]. Kind regards Andrew de la Haye Chief Operations Officer RIPE NCC [1] "IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region" http://www.ripe.net/ripe/docs/v4policy [2] "RIPE Policy Development" http://www.ripe.net/ripe/policies [3] "RIPE NCC Audit Activity" http://www.ripe.net/ripe/docs/audit [4] "RIPE NCC Reporting Procedure" http://www.ripe.net/contact/ripe-ncc-complaints-procedure [5] "Closure of Member and Deregistration of Internet Number Resources" http://www.ripe.net/ripe/docs/closure

10 21

next step on abuse-c deployment
by Denis Walker 21 Aug '13

21 Aug '13

Dear Brian and Tobias We are approaching the end of quarter 3 when all LIRs should have an abuse-c otherwise we said we would add it. Having talked to our customer service guys they have the impression that many LIRs had problems adding abuse-c despite all the documentation, Labs articles and videos. So we had a think about the next step. What we would suggest is: -for us to do a short presentation in the AA WG session at RIPE 67 reviewing how this first phase went with latest stats. -Then propose a new feature to add to the LIR Portal. Allow LIRs who don't yet have an abuse-c to simply enter an email address in a box that they want to use. -We will have scripts in the background that will create a new ROLE object, add this email as abuse-mailbox in that ROLE and add an abuse-c to their ORGANISATION object referencing the new ROLE object. -Then extend the deadline for LIRs to the end of October -After October we will use the same scripts to add the internal LIR contact email address, held by the RIPE NCC, in the same way for any LIR that still does not have one Then in November we start the next phase for PI holders. As they don't have access to the LIR Portal we can offer the same simple process with a web page having 3 boxes. Enter the email address they want to use, the name of their ORGANISATION object and the password to authorise an update to their ORGANISATION object. Using the same scripts we will create a ROLE and make the connections. What do you think? cheers denis

2 2