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

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

Update on "abuse-c:" coverage in RIPE Database
by Johan Åhlén 20 Aug '13

20 Aug '13

Dear colleagues, We would like to update you on the current "abuse-c:" coverage in the RIPE Database now that we have sent out the second batch of reminders. The last update you received was at the end of June; you can find the archived message at http://www.ripe.net/ripe/mail/archives/anti-abuse-wg/2013-June/002273.html -------- NETWORK NUMBERS: Total number of IPv4 allocations listed: 21,068 Number of IPv4 allocations covered with "abuse-c:": 10,901 or 51.7% of IPv4 allocations Total number of IPv4 PI assignments listed: 28,542 Number of IPv4 PI assignments covered with "abuse-c:": 1,591 or 5.6% of IPv4 assignments Total number of IPv6 allocations listed: 6,037 Number of IPv6 allocations covered with "abuse-c:": 3,223 or 53.4% of IPv6 allocations Total number of IPv6 assignments: 1,493 Number of IPv6 assignments covered with "abuse-c:": 190 or 12.7% of IPv6 assignments Total number of objects: 57,140 (IPv4: 49,610 / IPv6: 7,530) Number of objects covered with "abuse-c:": 15,905 or 27.8% (IPv4: 25.2% / IPv6: 45.3%) -------- IPv4 NETWORK SIZES: Total size of IPv4 allocations listed: 594,555,904 Size of IPv4 allocations covered with "abuse-c:": 337,556,992 or 56.8% Total size of IPv4 PI assignments listed: 169,707,896 Size of IPv4 PI assignments covered with "abuse-c:": 14,646,192 or 8.6% Total size of listed IPv4 addresses: 764,263,800 Size of listed IPv4 addresses covered with "abuse-c:": 352,203,184 or 46.1% In our last update, the coverage of IPv4 allocations, by size, was 41.1%. Today it is at 56.8%. -------- LIR NUMBERS: LIRs with "abuse-c:": 4,024 LIRs without "abuse-c:": 5,404 If you have any questions about theses figures, please feel free to contact us. Kind regards, Johan Åhlén Assistant Manager, Database Group RIPE NCC

1 0

Call For Agenda Items - RIPE67
by Brian Nisbet 12 Aug '13

12 Aug '13

Colleagues, While Europe is still enjoying its summer, the next RIPE meeting is slowly approaching. This meeting will be taking place in Athens from the 14th - 18th October 2013 and all the details can be found at http://ripe67.ripe.net As always Tobias and I are hoping the Anti-Abuse WG session will be full of interesting presentations and discussions. If you have anything you would like to present at the meeting, please email us at aa-wg-chairs(a)ripe.net Thanks, Brian

1 0

SQL injection attacks from Kyivstar GSM
by Roy Vij 02 Aug '13

02 Aug '13

We have seen a rush of SQL injection attacks from Ukraine based Kyivstar GSM. How can I query the ripe database to provide all IP blocks from Kyivstar GSM? -Regards

3 2

RIPE NCC Report: Law Enforcement Agency Requests 2012
by Paul Rendek 16 Jul '13

16 Jul '13

[Apologies for duplicates] Dear colleagues, As mentioned in the Anti-Abuse Working Group session at RIPE 66, the RIPE NCC has published a transparency report that details the nature of the requests we received from Law Enforcement Agencies (LEAs) in 2012. You can find the report here: http://www.ripe.net/ripe/docs/ripe-593 Kind regards, Paul Rendek Director of External Relations RIPE NCC

2 1

Re: [anti-abuse-wg] Who owns 24.205.98.101?
by Reza Farzan 11 Jul '13

11 Jul '13

Hello Olaf, Yes, not a single response from Charter, and I am not surprised. Charter Communications [charter.net & charter.com] is one of those mega providers that does not respond to such questions. Their Contact Page, http://www.myaccount.charter.com/Customers/ContactUs.aspx, deals mainly with their customers and their related inquiries. But calling Charter's National Network Operations Center (+1-314-288-3111) could be the last option, if they actually answer that line. With countless servers and IPs, Charter may not be as responsive as we expect them to be. Thank you, Reza Farzan ++++++++++ -----Original Message----- >From: Olaf van der Spek <ml(a)vdspek.org> >Sent: Jul 2, 2013 10:29 AM >To: Reza Farzan <rezaf(a)mindspring.com> >Subject: Re: [anti-abuse-wg] Who owns 24.205.98.101? > >On Tue, Jun 25, 2013 at 4:07 PM, Reza Farzan <rezaf(a)mindspring.com> wrote: >> Hello Peter, >> >> The Whois information clearly shows this IP to be part of Charter Communications network: >> >> NetRange: 24.205.76.0 - 24.205.99.255 >> CIDR: 24.205.96.0/22, 24.205.80.0/20, 24.205.76.0/22 >> OriginAS: >> NetName: CHAR-PAS-205-76-99 >> NetHandle: NET-24-205-76-0-1 >> Parent: NET-24-205-0-0-1 >> NetType: Reallocated >> RegDate: 2001-09-30 >> Updated: 2003-08-27 >> Ref: http://whois.arin.net/rest/net/NET-24-205-76-0-1 >> >> OrgName: Charter Communications >> OrgId: CC04 >> Address: 12405 Powerscourt Dr. >> City: St. Louis >> StateProv: MO >> PostalCode: 63131 >> Country: US >> RegDate: >> Updated: 2012-07-03 >> Ref: http://whois.arin.net/rest/org/CC04 >> >> OrgTechHandle: IPADD1-ARIN >> OrgTechName: IPAddressing >> OrgTechPhone: +1-314-288-3889 >> OrgTechEmail: ipaddressing(a)chartercom.com >> OrgTechRef: http://whois.arin.net/rest/poc/IPADD1-ARIN >> >> OrgAbuseHandle: ABUSE19-ARIN >> OrgAbuseName: Abuse >> OrgAbusePhone: +1-314-288-3111 >> OrgAbuseEmail: abuse(a)charter.net >> OrgAbuseRef: http://whois.arin.net/rest/poc/ABUSE19-ARIN >> >> OrgNOCHandle: NNOC16-ARIN >> OrgNOCName: National Network Operations Center >> OrgNOCPhone: +1-314-288-3111 >> OrgNOCEmail: dlnocip(a)chartercom.com >> OrgNOCRef: http://whois.arin.net/rest/poc/NNOC16-ARIN >> >> ++++ >> >> So, I do not understand why they are telling you otherwise. >> >> I have copied the responsible parties at Charter Communication so that they could investigate this matter further. ++++ Not a single response from Charter it seems. What's next?

4 3

Sending SPAM
by lhcarrara＠gmail.com 04 Jul '13

04 Jul '13

Hello friends. Not sure this is the correct channel, if there is some other form of contact, but I do not see how else to complain about, I'm trying all possibilities. This message is translated by Google Translator. So excuse me if there are any errors. Well, I'm having problems with SPAM from provider OVH. I have received several of them in recent weeks, but not when I am finding solution complaints. When I started to complain to the email abuse(a)ovh.net (that does not work, even), and then the e-mail suporte(a)ovh.net, the operator asked me to get in touch directly with the email abuse that listed in the register of IP RIPE.NET. It is what I have done. But in recent days, the customer who owns the OVH email spam-control(a)hospedagemgenial.com.br been sending me various SPAM. But this email ( spam-control(a)hospedagemgenial.com.br) does not exist, so my complaints are not enough. So, I began to denounce the SPAM directly to OVH, but nothing was done. I keep getting these SPAM. I do not know if they do not have infrastructure to filter it, or do not want to block the account of spamming, but keep getting the messages. To my enchegar things, when a carrier sells a framework for sending emails advertising (fancy name for SPAM), it is also responsible for such transmission. I did not ask her client (the spam-control(a)hospedagemgenial.com.br) send me SPAM. These customers simply take our e-mail who knows where and start sending us spam. And when we complained, the provider does nothing. I can not stand staying receiving such messages, do not want to receive and do not want to be made a fool by clicking on "click here to unsubscribe" because I know I'll keep getting spam from the same company, only one other product. Wish you could help me make a formal complaint about the sending of SPAM opereradora OVH or, if not the responsibility of you, if you could show me how it should be done. Thank you for your attention. Henrique

4 3

Re: [anti-abuse-wg] [db-wg] abuse-c + org
by Denis Walker 04 Jul '13

04 Jul '13

[Apologies for duplicate emails.] Dear Gilles, These points were discussed on the Anti Abuse Working Group mailing lists quite extensively in June and December 2012. As you correctly pointed out policy ripe-563 says "This policy introduces a new contact attribute named "abuse-c:”, that can be included in inetnum, inet6num and aut-num objects." During the discussions last year it was asked if the RIPE NCC should 'interpret' policy. Our understanding is that this policy expresses the desire and goal of the RIPE community for a new feature in the RIPE Database. To achieve these goals this desire needs to be translated into, and incorporated in, an efficient, technical database design. In the RIPE Labs article https://labs.ripe.net/Members/kranjbar/implementation-details-of-policy-201… we pointed out that there are about 3.7 million Internet resource objects in the RIPE Database. To add an "abuse-c:" attribute physically to each of these objects is unmanageable. Every users network is physically linked to their existing ORGANISATION object. Each user only needs to add one "abuse-c:" attribute in their ORGANISATION object and all their networks are covered. When any address is queried in the RIPE Database, the software will find the related "abuse-c:" reference and return this information as part of the query. By returning this information as a default with each query we have satisfied the policy requirement that the "abuse-c:" is "included in inetnum, inet6num and aut-num objects". It is not physically stored in each object in an unmanageable way, but logically associated with each object in an efficient and manageable way. This implementation was presented to and discussed by the community on the Anti Abuse Working Group mailing list last year and Brian declared that a consensus had been reached in his email on December 5, on behalf of the co-chairs of the DB and AA Working Groups: http://www.ripe.net/ripe/mail/archives/anti-abuse-wg/2012-December/001993.h… In a follow up RIPE Labs article https://labs.ripe.net/Members/denis/creating-and-finding-abuse-contacts-in-… the RIPE NCC explained how this implementation works in practise. You may recall that we discussed the details of how these references using the ORGANISATION object worked and how they can be fine tuned: http://www.ripe.net/ripe/mail/archives/anti-abuse-wg/2012-December/001998.h… The old RIPE Database reference manuals on the ripe.net web site still refer to the use of "abuse-mailbox:" attributes in other object types, but don't refer to "abuse-c:" at all. These attributes were never allowed to be added directly to the resource objects even in the legacy software. These old reference manuals are now out of date in many respects and should perhaps be clearly marked as archived documents. I hope this answers your specific questions. Regards Denis Walker Business Analyst RIPE NCC Database Team On 27/06/2013 10:06, Gilles Massen wrote: > Dear WG, and RIPE NCC staff, > > While trying to add an abuse-c to our resources, I was quite surprised > that you can only attach the abuse-c to an org object (while the policy > suggests otherwise and implementation notes are not very clear on the > limitation). > > So I'd like to ask why this restriction exists? What is wrong with > adding an abuse-c directly to an inet[6]num or aut-num? > > Best regards, > Gilles >

7 12

New on RIPE Labs: Geoff Huston - Here's Looking At You..
by Mirjam Kuehne 04 Jul '13

04 Jul '13

[apologies for duplicates] Dear colleagues, Geoff Huston measured to what extent information relating to individuals’ activities online is being passed to others. Please see his findings on RIPE Labs: https://labs.ripe.net/Members/gih/heres-looking-at-you Kind regards, Mirjam Kuehne RIPE NCC

1 0