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

Fwd: ICANN News Alert -- DISCUSSION: Reviewing New gTLD Program Safeguards Against DNS Abuse
by Michele Neylon - Blacknight 21 Jan '16

21 Jan '16

Slightly off topic but possibly of interest to some people on this list Mr Michele Neylon Blacknight Hosting & Domains http://www.blacknight.host/ http://www.mneylon.social Sent from mobile so typos and brevity are normal Begin forwarded message: From: ICANN News Alert <no-reply(a)external.icann.org<mailto:no-reply@external.icann.org>> Date: 21 January 2016 at 06:25:17 GMT To: <michele(a)blacknight.com<mailto:michele@blacknight.com>> Subject: ICANN News Alert -- DISCUSSION: Reviewing New gTLD Program Safeguards Against DNS Abuse Reply-To: <no-reply(a)external.icann.org<mailto:no-reply@external.icann.org>> [ICANN]<http://www.icann.org/> News Alert https://www.icann.org/news/announcement-2016-01-20-en ________________________________ DISCUSSION: Reviewing New gTLD Program Safeguards Against DNS Abuse 20 January 2016 ICANN is currently engaged in data collection on DNS abuse and mitigation efforts implemented as part of the New gTLD Program. Members of the community and general public are invited to join ICANN on 28 January 2016 in an open discussion on the topic. This work will help inform the efforts of the review team examining the effects of the Program on Competition, Consumer Choice, and Consumer Trust<https://newgtlds.icann.org/en/reviews/cct>, which will assess the safeguards in the Program as part of its work. The goals of the discussion are to help formulate a definition of DNS abuse, brainstorm methods for measuring abuse, and gather qualitative, experiential input on whether safeguards to mitigate DNS abuse in new gTLDs have been effective. The discussion will be structured around 4 central topics, which participants are encouraged to consider prior to joining: Topic 1: Which activities do you consider to be DNS abuse? If you could put forth a globally accepted definition of DNS abuse, what would it be? This definition should be broad enough to cover various malicious uses of the DNS. Topic 2: What are the most effective methods to measure the prevalence of abusive activities in the DNS? Topic 3: As part of the New gTLD Program, ICANN introduced safeguards<https://archive.icann.org/en/topics/new-gtlds/mitigating-malicious-conduct-…> [PDF, 128 KB] to mitigate potential DNS abuse in new gTLDs (listed below). How can we measure the effectiveness of these safeguards? 1. Vetting registry operators 2. Requirement for DNSSEC deployment 3. Requirement for Thick WHOIS records 4. Prohibition of "wild carding" 5. Removal of orphan glue records 6. Centralization of Zone file access 7. Abuse contact and documented anti-abuse policy requirements for registries and registrars 8. Availability of expedited registry security request process 9. High-security zone verification Topic 4: What has been your experience, personally or on behalf of an organization, with these safeguards? Please tell us: * Which were and/or were not effective? How so and why do you believe they were or were not effective? * Are there safeguards that should have been included but were not? Any remaining time will be open for questions and related discussion. ________________________________ Discussion Details & How to Attend ICANN will hold two discussions to enable participation in all regions. Use the time zone converter<https://www.timeanddate.com/worldclock/converter.html> to determine local times. Date: 28 January 2016 * Discussion 1: 02:00 - 03:30 UTC * Discussion 2: 16:00 - 17:30 UTC Join Online: https://icann.adobeconnect.com/gdd Join the Teleconference: Download numbers now<https://newgtlds.icann.org/en/announcements-and-media/webinars/dial-in-28ja…> [PDF, 89 KB]. Passcode: 144 144 2688 These discussions will be conducted in English. Recordings will be published at: https://newgtlds.icann.org/en/reviews/dns-abuse. Register to Attend or Participate via Questionnaire Want ICANN to remind you about the event? Register to attend the discussion and we'll send you an email with participation information. Unable to attend, but want to contribute? Give us the OK to send you a questionnaire so you can tell us about your experiences. Visit: http://survey.clicktools.com/app/survey/go.jsp?iv=25apb9wqx72s8 ________________________________ Further Information ICANN's New gTLD Program has enabled hundreds of new top-level domains to enter into the Internet's root zone since the first delegation occurred in October 2013. Comprehensive reviews<http://newgtlds.icann.org/en/reviews> of the program have begun and will cover a variety of topics including competition, consumer trust and choice (CCT), security and stability, rights protection and other areas. Along with commissioning third-party analyses, ICANN is capturing stakeholder experiences regarding operation of the New gTLD Program and its effects on the domain name industry. Lessons learned as a result of these efforts will help shape future rounds of the program. Suggested Reading * "Mitigating Malicious Conduct," ICANN, New gTLD Program Explanatory Memorandum, https://archive.icann.org/en/topics/new-gtlds/mitigating-malicious-conduct-… [PDF, 128 KB], (3 October 2009). * New gTLD Program Review page: http://newgtlds.icann.org/en/reviews This message was sent to michele(a)blacknight.com<mailto:michele@blacknight.com> from: ICANN News Alert | no-reply(a)external.icann.org<mailto:no-reply@external.icann.org> | ICANN | 12025 Waterfront Drive Suite 300 | Los Angeles, CA 90094-2536 Email Marketing by [iContact - Try It Free!] <http://www.icontact.com/a.pl/144186> Manage Your Subscription <http://app.icontact.com/icp/mmail-mprofile.pl?r=9827379&l=6333&s=S5QC&m=979…>

1 0

Re: [anti-abuse-wg] anti-abuse-wg Digest, Vol 51, Issue 2
by Marilson 14 Jan '16

14 Jan '16

Gentlemen, Brian Nisbet said > ...given the lack of further responses..." > without "disagreements" > "...with the general feeling of consensus" You're a joker! That is better than standup comedy. All my complains were blocked. (The RIPE community has an Anti-Abuse Working Group that discusses topics relating to Internet abuse and the participation in RIPE Working Groups is open to all) All my complains were relating to internet abuse - with evidence. The solution being finalized is proof of the uselessness of this anti-abuse working group. The market is ripe for sc(p)ammers and RIPE is not ripe, is rotten. And the population will continue to be raped. My condolences Marilson -----Mensagem Original----- From: anti-abuse-wg-request(a)ripe.net Sent: Wednesday, January 13, 2016 9:00 AM To: anti-abuse-wg(a)ripe.net Subject: anti-abuse-wg Digest, Vol 51, Issue 2 Send anti-abuse-wg mailing list submissions to anti-abuse-wg(a)ripe.net To subscribe or unsubscribe via the World Wide Web, visit https://www.ripe.net/mailman/listinfo/anti-abuse-wg or, via email, send a message with subject or body 'help' to anti-abuse-wg-request(a)ripe.net You can reach the person managing the list at anti-abuse-wg-owner(a)ripe.net When replying, please edit your Subject line so it is more specific than "Re: Contents of anti-abuse-wg digest..." Today's Topics: 1. Re: RIPE NCC to set abuse-c for remaining organisation with ASNs or other resources allocated or assigned by the RIPE NCC (Brian Nisbet) 2. Re: [db-wg] RIPE NCC to set abuse-c for remaining organisation with ASNs or other resources allocated or assigned by the RIPE NCC (denis) ---------------------------------------------------------------------- Message: 1 Date: Tue, 12 Jan 2016 15:23:17 +0100 From: Brian Nisbet <brian.nisbet(a)heanet.ie> To: Tim Bruijnzeels <tim(a)ripe.net>, anti-abuse-wg(a)ripe.net, Database WG <db-wg(a)ripe.net> Subject: Re: [anti-abuse-wg] RIPE NCC to set abuse-c for remaining organisation with ASNs or other resources allocated or assigned by the RIPE NCC Message-ID: <56950C55.4060802(a)heanet.ie> Content-Type: text/plain; charset=utf-8; format=flowed Afternoon(-ish), As I'm pretty sure Monday is now everywhere in the world, I think that given the lack of further responses or discussion or, importantly, disagreements with the general feeling of consensus, I think we can proceed. Tim, is the date of the 1st of February still possible for the first mailing on this? Thanks, Brian Brian Nisbet, Network Operations Manager HEAnet Limited, Ireland's Education and Research Network 1st Floor, 5 George's Dock, IFSC, Dublin 1 Registered in Ireland, no 275301 tel: +35316609040 web: http://www.heanet.ie/ Brian Nisbet wrote on 05/01/2016 10:29: > Colleagues, > > There has been some responses to this and some good discussion. The > general response has been positive and while I'm not ignoring Denis' > comments, I'm not sure the issues are enough to say we shouldn't do this? > > I'd like to give a little more time for responses or discussion, I think > until the end of Monday 11th January. > > Thanks, > > Brian > Co-Chair, RIPE AA-WG > > On 15/12/2015 16:58, Brian Nisbet wrote: >> I know that we're getting near to what for a lot of people will be a >> well deserved break at the end of the year, but it would be great if >> there could be some feedback for the NCC on this, even if it's just >> agreement! :) >> >> Thanks, >> >> Brian >> Co-Chair, RIPE AA-WG >> On 09/12/2015 12:49, Tim Bruijnzeels wrote: >>> Dear working groups, >>> >>> As you know all organisations that have internet number resources >>> allocated or assigned by the RIPE NCC need to have an abuse-c >>> attribute according to policy 2011-06. The following implementation >>> plan was communicated for this policy: >>> >>> https://labs.ripe.net/Members/kranjbar/implementation-details-of-policy-201… >>> >>> >>> >>> Phase 1 of this plan was completed in December 2013, setting up >>> abuse-c for then existing LIRs. Phase 2 of this plan was completed for >>> organisations holding sponsored PI resources in November 2014. >>> However, since then LIRs and end-users have been responsible for >>> ensuring that an abuse-c exists for their organisation. In practice it >>> has proven difficult to enforce this, since abuse-c is not a mandatory >>> attribute in the RIPE DB schema, and as a result new cases where >>> organisations do not have an abuse contact have been created. >>> >>> There is an important change in the implementation we would like to do >>> ? based on our experiences thus far ? which would like the community's >>> mandate on. We propose to use the end-user organisation's email >>> address instead of the sponsoring LIR email address. We believe there >>> are valid reasons for this change, but of course if this suggested >>> change is controversial we would encourage discussing it in the >>> anti-abuse working group. Ideally, we need to have a decision on this >>> by early January so that we can prepare the work. >>> >>> >>> 1) Prevent NEW cases >>> >>> We want to ensure that no new cases will be created as follows: >>> >>> = Since 1 March, the new member application form already provides much >>> better integration with the RIPE Database >>> - because of this an abuse contact is now created whenever a new >>> LIR is activated >>> - it can be modified the LIR, e.g. using web-updates, but not removed >>> >>> = We are currently adapting the new create organisation webupdates >>> form to include abuse-c by default allowing the user to: >>> - reference an existing abuse-c role object, or >>> - enter an email address to create an abuse-c role for the >>> organisation (using the same maintainer) >>> >>> = We are also adapting the edit organisation webupdates form to always >>> suggest adding an abuse-c contact if it's not present >>> >>> = We plan to extend the new request forms: >>> - check that an end-user organisation has abuse-c before it can be >>> used >>> - if not, refer to the edit form for the organisation where it will >>> be easy to add reference an existing abuse contact, or create a new >>> object >>> >>> 2) Resolve remaining EXISTING cases >>> >>> Originally the idea for phase 2 was to use the sponsoring LIR's email >>> address in case the end-user organisation was unresponsive to requests >>> to set their own abuse contact. However, since then policy 2012-08 has >>> been implemented and nowadays the sponsoring LIR, and its abuse >>> contact, can be found through the sponsoring-org attribute. >>> >>> Also, the RIPE NCC found that using the sponsoring organisation's >>> email address leads to a number of issues: >>> >>> - end-users have no incentive to set their own abuse-c, rather then >>> letting abuse questions go to their sponsor, so the majority remains >>> unresponsive >>> - in case an end-user has resources from more than one sponsor it is >>> ambiguous which sponsor's email should be used >>> - many LIRs were unpleasantly surprised by finding their email address >>> in the abuse-c of the organisation they sponsor >>> - in case LIRs no longer wish to sponsor resources, or when they are >>> returned, existing references to their email in the end-user abuse-c >>> are not cleaned up >>> >>> We would therefore like to propose a change to the implementation plan >>> when addressing the remaining cases. Today, in case no abuse contact >>> is set, users of the database will resort to using the organisation's >>> default email. Therefore, adding a dedicated abuse-c role object using >>> this email address, doesn't cause any noticeable new effects on >>> organisations. It may well be the correct email address to use for an >>> organisation, and no action would be required. However, it *enables* >>> an organisation to use a different email address for abuse questions >>> if appropriate. >>> >>> We would like to email remaining LIRs, and end-user organisations and >>> sponsoring LIRs on Monday 1 February, giving them until Monday 15 >>> February to set their abuse contact. We realise that this means we >>> would have another delay, but we believe that it would be unwise to do >>> this change over the end of year holiday period, and to ensure that we >>> can give proper support to questions we want to avoid doing this at >>> the same time as the start of the year invoicing. >>> >>> Please let us know what you think. >>> >>> Kind regards, >>> >>> Tim Bruijnzeels >>> Assistant Manager Software Engineering >>> RIPE NCC Database Group >>> >>> >>> >> > ------------------------------ Message: 2 Date: Wed, 13 Jan 2016 11:48:49 +0100 From: denis <ripedenis(a)yahoo.co.uk> To: Brian Nisbet <brian.nisbet(a)heanet.ie>, Tim Bruijnzeels <tim(a)ripe.net>, anti-abuse-wg(a)ripe.net, Database WG <db-wg(a)ripe.net> Subject: Re: [anti-abuse-wg] [db-wg] RIPE NCC to set abuse-c for remaining organisation with ASNs or other resources allocated or assigned by the RIPE NCC Message-ID: <56962B91.20800(a)yahoo.co.uk> Content-Type: text/plain; charset=utf-8; format=flowed Hi Brian A little late, but I was on holiday :) I agree my comments are a separate issue and should not delay the process of adding any missing abuse-c attributes. I am about to write a separate email about how to use abuse-c as I think we are in danger of losing the plot regarding the original goal of abuse-c. cheers denis On 12/01/2016 15:23, Brian Nisbet wrote: > Afternoon(-ish), > > As I'm pretty sure Monday is now everywhere in the world, I think that > given the lack of further responses or discussion or, importantly, > disagreements with the general feeling of consensus, I think we can > proceed. > > Tim, is the date of the 1st of February still possible for the first > mailing on this? > > Thanks, > > Brian > > Brian Nisbet, Network Operations Manager > HEAnet Limited, Ireland's Education and Research Network > 1st Floor, 5 George's Dock, IFSC, Dublin 1 > Registered in Ireland, no 275301 tel: +35316609040 > web: http://www.heanet.ie/ > > Brian Nisbet wrote on 05/01/2016 10:29: >> Colleagues, >> >> There has been some responses to this and some good discussion. The >> general response has been positive and while I'm not ignoring Denis' >> comments, I'm not sure the issues are enough to say we shouldn't do this? >> >> I'd like to give a little more time for responses or discussion, I think >> until the end of Monday 11th January. >> >> Thanks, >> >> Brian >> Co-Chair, RIPE AA-WG >> >> On 15/12/2015 16:58, Brian Nisbet wrote: >>> I know that we're getting near to what for a lot of people will be a >>> well deserved break at the end of the year, but it would be great if >>> there could be some feedback for the NCC on this, even if it's just >>> agreement! :) >>> >>> Thanks, >>> >>> Brian >>> Co-Chair, RIPE AA-WG >>> On 09/12/2015 12:49, Tim Bruijnzeels wrote: >>>> Dear working groups, >>>> >>>> As you know all organisations that have internet number resources >>>> allocated or assigned by the RIPE NCC need to have an abuse-c >>>> attribute according to policy 2011-06. The following implementation >>>> plan was communicated for this policy: >>>> >>>> https://labs.ripe.net/Members/kranjbar/implementation-details-of-policy-201… >>>> >>>> >>>> >>>> >>>> Phase 1 of this plan was completed in December 2013, setting up >>>> abuse-c for then existing LIRs. Phase 2 of this plan was completed for >>>> organisations holding sponsored PI resources in November 2014. >>>> However, since then LIRs and end-users have been responsible for >>>> ensuring that an abuse-c exists for their organisation. In practice it >>>> has proven difficult to enforce this, since abuse-c is not a mandatory >>>> attribute in the RIPE DB schema, and as a result new cases where >>>> organisations do not have an abuse contact have been created. >>>> >>>> There is an important change in the implementation we would like to do >>>> ? based on our experiences thus far ? which would like the community's >>>> mandate on. We propose to use the end-user organisation's email >>>> address instead of the sponsoring LIR email address. We believe there >>>> are valid reasons for this change, but of course if this suggested >>>> change is controversial we would encourage discussing it in the >>>> anti-abuse working group. Ideally, we need to have a decision on this >>>> by early January so that we can prepare the work. >>>> >>>> >>>> 1) Prevent NEW cases >>>> >>>> We want to ensure that no new cases will be created as follows: >>>> >>>> = Since 1 March, the new member application form already provides much >>>> better integration with the RIPE Database >>>> - because of this an abuse contact is now created whenever a new >>>> LIR is activated >>>> - it can be modified the LIR, e.g. using web-updates, but not >>>> removed >>>> >>>> = We are currently adapting the new create organisation webupdates >>>> form to include abuse-c by default allowing the user to: >>>> - reference an existing abuse-c role object, or >>>> - enter an email address to create an abuse-c role for the >>>> organisation (using the same maintainer) >>>> >>>> = We are also adapting the edit organisation webupdates form to always >>>> suggest adding an abuse-c contact if it's not present >>>> >>>> = We plan to extend the new request forms: >>>> - check that an end-user organisation has abuse-c before it can be >>>> used >>>> - if not, refer to the edit form for the organisation where it will >>>> be easy to add reference an existing abuse contact, or create a new >>>> object >>>> >>>> 2) Resolve remaining EXISTING cases >>>> >>>> Originally the idea for phase 2 was to use the sponsoring LIR's email >>>> address in case the end-user organisation was unresponsive to requests >>>> to set their own abuse contact. However, since then policy 2012-08 has >>>> been implemented and nowadays the sponsoring LIR, and its abuse >>>> contact, can be found through the sponsoring-org attribute. >>>> >>>> Also, the RIPE NCC found that using the sponsoring organisation's >>>> email address leads to a number of issues: >>>> >>>> - end-users have no incentive to set their own abuse-c, rather then >>>> letting abuse questions go to their sponsor, so the majority remains >>>> unresponsive >>>> - in case an end-user has resources from more than one sponsor it is >>>> ambiguous which sponsor's email should be used >>>> - many LIRs were unpleasantly surprised by finding their email address >>>> in the abuse-c of the organisation they sponsor >>>> - in case LIRs no longer wish to sponsor resources, or when they are >>>> returned, existing references to their email in the end-user abuse-c >>>> are not cleaned up >>>> >>>> We would therefore like to propose a change to the implementation plan >>>> when addressing the remaining cases. Today, in case no abuse contact >>>> is set, users of the database will resort to using the organisation's >>>> default email. Therefore, adding a dedicated abuse-c role object using >>>> this email address, doesn't cause any noticeable new effects on >>>> organisations. It may well be the correct email address to use for an >>>> organisation, and no action would be required. However, it *enables* >>>> an organisation to use a different email address for abuse questions >>>> if appropriate. >>>> >>>> We would like to email remaining LIRs, and end-user organisations and >>>> sponsoring LIRs on Monday 1 February, giving them until Monday 15 >>>> February to set their abuse contact. We realise that this means we >>>> would have another delay, but we believe that it would be unwise to do >>>> this change over the end of year holiday period, and to ensure that we >>>> can give proper support to questions we want to avoid doing this at >>>> the same time as the start of the year invoicing. >>>> >>>> Please let us know what you think. >>>> >>>> Kind regards, >>>> >>>> Tim Bruijnzeels >>>> Assistant Manager Software Engineering >>>> RIPE NCC Database Group >>>> >>>> >>>> >>> >> > End of anti-abuse-wg Digest, Vol 51, Issue 2 ********************************************

1 0

abuse-c: important points on it's usage
by denis 13 Jan '16

13 Jan '16

HI All I make no apologies for the length of this email, but I would ask anyone concerned with abuse handling, RIPE Database data management and RIPE Database maintenance to read it. I am not trying to be a perfectionist or technical purist, but the changes being forced through now do matter. cheers denis When "abuse-c:" was first proposed, Tobias (co-chair of Anti Abuse WG) and I spent a lot of time discussing how to achieve the intended goal. We came up with the current implementation, which after community discussion was approved. But you never think of everything in the first instance. I believe there is one piece missing that allows the whole system to be broken (see later). I also believe the changes being made (without proper discussion) by the RIPE NCC's 'improvements' to Webupdates will break the abuse-c system over time. As a separate issue, but related to this, I think the RIPE NCC should give advance notice to the community of changes to interfaces like Webupdates and allow some discussion on significant changes like ORGANISATION object creation and authorisation and not just 'slip them in', then try to justify them when someone notices. These are major changes to the way the RIPE Database works. They are not just changing the look and feel of Webupdates as an interface tool. So lets start with some history. The goal of "abuse-c:" When the data model was designed there was no thought given to abuse contacts. The internet was much smaller and more personal. The data model was built on the principle of human readability and not programatic parsing. So when the need for abuse reporting was first considered necessary it was good enough to add things like: remarks: In case of abuse contact me(a)here.com You could put this anywhere and someone would find it. Then it got a bit more formal and we introduced the "abuse-mailbox:" attribute. But this was allowed in five or six object types. None of these were the resource objects. So the information was scattered all over the database. This was still almost impossible to find programatically. The goal of "abuse-c:" was: -to have one way of documenting abuse contact details -parsable programatically -very simple for majority of resources -flexible for any other resource situation The "abuse-c:" design Tobias and I considered many options to achieve these goals. What we focussed in on was that most small to medium LIRs may have many resources but only one person/role handling abuse complaints. All these resource objects in the database referenced their one ORGANISATION object. So by adding the "abuse-c:" attribute to the one ORGANISATION object, referencing a ROLE object containing the contact details, we handled a large number of simple cases in a very simple way. All the resources referencing this one ORGANISATION object and all the more specific resources would inherit this contact information from this one location. Easy to set up, easy to maintain. But there are other situations. For example sub allocations. We also considered that accountability is an important element of this public registry database. There is a notion that when a resource is allocated or assigned by the RIPE NCC to an organisation, then that organisation is ultimately responsible for anything that happens regarding that resource. This is why ORGANISATION objects are mandatory for any organisation that wants to hold internet resources. So we considered that if part of the responsibility has been delegated to another organisation with a sub allocation, it is not unreasonable that another ORGANISATION object should be created to reflect this delegated responsibility. If this second organisation handles the abuse reporting for this sub allocation, then another "abuse-c:" attribute can be added to their ORGANISATION object to reflect this. If the LIR who is responsible for this allocation, including the sub allocation, wants to handle all abuse reports for the whole of their allocation then no "abuse-c:" should be added to the second ORGANISATION object. The sub allocation will then continue to inherit the abuse contact details of the LIR who holds the whole resource. Inheritance vs Scattering The data model for the RIPE Database was not designed with inheritance in mind. In many situations duplicated, redundant data is scattered all over the database. There are over 3 million INETNUM objects in the database. They all contain one or more "admin-c:" and "tech-c:" attributes. In reality all these references are to a few tens of thousands of individual roles. These contacts could be inherited from the ORGANISATION objects in the way "abuse-c:" has been set up. The "abuse-c:" was designed to be inherited and not to be duplicated where it is not needed. The changes made recently to Webupdates by the RIPE NCC (without any discussion) breaks the inheritance of "abuse-c:". It forces the scattering of more redundant data throughout the database. If you create an ORGANISATION object with Webupdates it forces the addition of an "abuse-c:" attribute whether it is needed or not. They argue that you can refer to an existing ROLE object making it the same abuse contact. Even if this was set up correctly it is redundant data. In reality people setting this up quickly will just take the easy option of giving any email address (mickey(a)mouse.com). They may not realise the impact of this. But this simple mistake overrides the LIRs genuine abuse contact details from any point in a network where this new ORGANISATION object is referenced. Understanding your network and the RIPE Database What it comes down to is that you should understand how your network is structured. You should at least know who needs to be contacted, for what reason, from which point in your network. Unfortunately with the current data model you also need to have at least a basic understanding of how the data is structured within the RIPE Database. And to be honest if you don't understand the basic structure of the RIPE Database you should not be managing data in it, maintaining it or documenting it. With knowledge of your network and the database you can decide where you need to put "abuse-c:" attributes. DO NOT add extra, redundant "abuse-c:" attributes. What can possibly go wrong? In defence of their unannounced changes to Webupdates, the RIPE NCC has argued that adding additional "abuse-c:" attributes is harmless and will NOT lead to bad data in the database. Forcing users to add additional, redundant data that breaks the principle of inheritance is in itself technically wrong. But without being a technical purist what else can go wrong? Once these additional references have been added, the seeds have been sown for future mistakes. It all depends now on who maintains what and who is notified of what changes. The referenced ROLE object can be changed or the "abuse-mailbox:" value in the ROLE object can be changed. This could be accidental or with good intent, but just got it wrong or even maliciously. Without the proper checks this can easily go unnoticed. Over time some/many of these redundant references may/will get out of sync with what they should refer to. In a few years time someone will argue that all this contact data is messed up, abuse-c did not work and we will invent a new system... The missing bit The "abuse-c:" attribute does work and will work well if used properly. But there is one bit missing from the original design....proper notifications. We need another attribute adding to the ORGANISATION object abuse-notif: [required] [multiple] [] This will allow the resource holder to keep an audit trail of any changes made to the abuse contact details for any parts of their resources. The 'required' (as defined in the database documentation) means it is syntactically optional, but business rules enforce it's presence in some situations. This should be added to any ORGANISATION object referenced by a resource object. Any addition, change or deletion of any part of the abuse contact details ("abuse-c: attribute, referenced ROLE object, "abuse-mailbox:" attribute) at any part of a network will be notified to the resource holder's email address specified in this attribute. Only the "abuse-notif:" referenced via the top level of a resource object will be notified. Any redundant references in more specific objects will be ignored (and should be removed, warned or disallowed). This means the resource holder will always be notified if anything is changed at any point in the resources/networks they are responsible for. I also think it would be useful if RIPEstat could give a visual representation of where abuse contacts are located within a network. This would allow a resource holder to review who is managing abuse for any part of their networks.

1 0

Draft Minutes: AA-WG Session at RIPE 71
by Brian Nisbet 04 Jan '16

04 Jan '16

Colleagues, Here are the draft minutes for the AA-WG session at RIPE71. If you would like anything to be removed, corrected or added, please let me know. In the meantime I would like to wish you all a very Merry Christmas or other happy and joyous sentiments as appropriate. I look forward to working with you in the 2016! Brian Co-Chair, RIPE AA-WG Anti-Abuse Working Group Draft Agenda Thursday, 19 November 11:00 - 12:30 A. Administrative Matters [5 min] • Welcome • Scribe, Jabber, Stenography • Microphone Etiquette • Approve Minutes from RIPE 70 • Finalise Agenda B. Update [15 min] • B1. AA-WG Chair Matters Tobias was accepted to continue as co-chair. • B2. Recent List Discussion - Foreign/Undelegated Route Objects (see section C) - no comments - Data Verification & abuse-c contact methods - no comments - LIR Contract Discussions - no comments - Brian has asked the RIPE NCC for more info on the claims that RIPE NCC is party to End User contracts. - Sources of Abuse Contact Info Document - no comments  C. Policies [0 min] - Foreign objects in the RIPE DB - Brian encouraged the group to participate in the discussions taking place in the Database Working Group (DB-WG). D. Interactions [20 min] • D0. Richard Leaning (RIPE NCC) will work on extending Law Enforcement engagement • D1. Update on RIPE NCC Security Outreach Activities - Mirjam Kühne https://ripe71.ripe.net/presentations/5-SecurityUpdate4RIPE71.pdf   Sean Turner (IECA) asked whether the work between ICANN and the RIRs on IP and Whois accuracy and due diligence public safety has started yet, as per the ICANN meeting minutes. Marco Hogewoning (RIPE NCC) confirmed that RIPE NCC is involved with the PS WG. Hans Petter Holen (RIPE Chair) added that lots of suggestions from ICANN meetings come up from misunderstanding existing processes. He suggested that they believe we have more problems with Whois accuracy than they do with domain names - he thinks it’s the opposite. Marco confirmed that the RIRs continue to educate where needed. Mirjam Kühne (RIPE NCC) added that the RIPE NCC is educating and engaging on how to use our tools. Brian Nisbet (AA-WG Chair) commented that the MAAWG meeting was surprisingly good and that there was a positive reaction to the presentation and the openness of the RIPE Community - the relationship continues. Mirjam reiterated that there is a continued need for more collaboration between the two communities. Peter Koch (DENIC) commented that openness can be a barrier to collaboration. Marco d’Itri (Seeweb) reminded the group of the open invitation from MAAWG to RIPE community members to participate. Mirjam rounded off by adding that if RIPE NCC can help to bridge any divide, it is happy to and will continue to. E. Presentation [45 min] • E1. Open Source Abuse Management for Network Operators - Abuse.io (Erik Bais)  https://ripe71.ripe.net/presentations/130-AbuseIO-4.0-RIPE71-AAWG-v1.pdf (Bart Vrancken is on IRC to answer additional questions) Marco D’Itri asked whether the system process ARF and legacy feedback group. Erik confirmed that they do include Spamhaus reports and ARF as well. You can also write your own parsers. Bengt Gorden (Resilans) asked whether it was easy to get your own customer database included? Erik confirmed that they did it manually, but there is an option to do lookups in your own administrative environment. Bart Vrancken (via IRC) confirmed that there is built-in support and 4.0 support for PHP. Erik encouraged everyone to look at the website, join IRC and chat with Bart. • E2. The Traffic Amplifiers Great Hunt - ANSSI (Florian Maury)  https://ripe71.ripe.net/presentations/65-ripe71_antiabusewg_anssi_the_traff… Steve Nash (Arbor Networks) added that another thing people can do is to elevate management visibility so that the money becomes available. Erik Bais (A2B Internet) asked whether the info from the scans has been made available? Florian clarified that they haven’t performed any scans. They used open data, which is already available publicly. • E3. Helping Network Operators to Bring Down DDoS Sources - ANSSI (Markus de Brün) https://ripe71.ripe.net/presentations/72-DDoS_Open_Services_Cleanup_Germany… Brian asked whether there is any feeling for when ANSSI would no longer consider this to be a problem worth worrying about? Do you ever expect it to reduce to zero? Markus explained that the goal is to get as far down as possible and that this will take a long time. Florian Maury confirmed that indeed this would be difficult, but reducing the number of available nodes is a short-term action that can be taken now. But also longer term actions (such as working on anti-spoofing technologies and updating the protocols being used for these attacks) can be useful too. Marco Hogewoning asked what triggered the ISPs into action? Was it the outreach or incidents happening? Markus shared that early on, due to repeated communication, ISPs that were not aware of the situation took action. Mohsen Souissi (AFNIC) asked whether DNS over DNS will ever become a full replacement? Florian suspects that it won’t solve the problem but having DNS over TCP will probably help. Will van Gulik (IP-Max SA) indicated that receiving reports from other countries (e.g. France) would be really appreciated. Markus advised that they only have data for Germany, but perhaps his French colleagues would start an action like this. Florian explained that their data came from worldwide scans, so if you provide the prefixes you are interested in we can share. Brian reminded the room that the Internet has no borders. Chris Baker added that the shadow serve foundation is available to give reports without country restrictions. X. A.O.B. Brian mentioned that there is still time to submit a lightning talk for tomorrow’s session. Z. Agenda for RIPE 72

2 3

Working Group Chair Matters
by Brian Nisbet 26 Nov '15

26 Nov '15

Colleagues, Apologies for not sending this email last week. During the working group session at RIPE71 Tobias was re-appointed as co-chair of the working group. Thanks, Brian Co-Chair, RIPE AA-WG

1 0

Sources of Abuse Contact Info For Abuse Handlers
by Brian Nisbet 26 Nov '15

26 Nov '15

Colleagues, Mirjam Kuehne, L. Aaron Kaplan and Christian Teuschel have been doing a lot of work on a document on "Sources of Abuse Contact Info For Abuse Handlers". Versions of this document have been sent to the WG over the past year. There has been a lot of input from a lot of people and organisations and we'd like to thank them all. At this point it is our intend to publish this as a BCP RIPE Document from the AA-WG. At this point we would like to invite any final comments from the WG (a last call of sorts) before it is published. Ideally these comments would be great before the WG Session at 11:00 EET on Thursday 19th November, but definitely before the end of this week. Thanks again to all involved. Brian Co-Chair, RIPE Anti-Abuse WG -- Brian Nisbet, Network Operations Manager HEAnet Limited, Ireland's Education and Research Network 1st Floor, 5 George's Dock, IFSC, Dublin 1 Registered in Ireland, no 275301 tel: +35316609040 web: http://www.heanet.ie/

11 15

Spam from a C class
by turgut kalfaoğlu 22 Nov '15

22 Nov '15

Hello everyone; I just joined this group. My name is Turgut Kalfaoglu, those old enough to have seen me in EARN (now TERENA) perhaps remember me; if so, hello to you all. I have a problem on a server that I'm managing, it's getting a substantial amount of spam over many months from various IP's in the 185.111.244.0/24 range. The "abuse" email address is destek(a)oyunmerkezi.com.tr , which translates as "support(a)gamecenter.com.tr". Having a such "light" abuse email, I suspect that reporting to this "game center" will not solve the spam problem; I believe they are doing this knowingly. I emailed them to stop, and blocked the IP range on my server, but I also want these people reported as they are spamming millions, and hopefully have their IP range revoked. Is there a procedure within RIPE to apply for a such abuse? Many thanks, Turgut Kalfaoglu

2 1

New on RIPE Labs: Implementing DANE for RIPE NCC Websites
by Mirjam Kuehne 19 Nov '15

19 Nov '15

Dear colleagues, In September of this year, we activated DNS-based Authentication of Named Entities (DANE) for our main web services, including www.ripe.net, the LIR Portal and RIPE Labs. Please find more details on RIPE Labs: https://labs.ripe.net/Members/mgrigore/implementing-dane-for-ripe-ncc-websi… Kind regards, Mirjam Kuehne RIPE NCC

1 0

Reminder: Anti-Abuse WG at RIPE71 Today
by Brian Nisbet 19 Nov '15

19 Nov '15

Colleagues, A brief reminder that the Anti-Abuse WG session at RIPE 71 kicks off at 11:00 EET (GMT +2) today. If you aren't in Bucharest you can follow along live here: https://ripe71.ripe.net/live/side/ You can also join the Chat Room either via that page or via irc.ripe.net #anti-abuse Brian -- Brian Nisbet, Network Operations Manager HEAnet Limited, Ireland's Education and Research Network 1st Floor, 5 George's Dock, IFSC, Dublin 1 Registered in Ireland, no 275301 tel: +35316609040 web: http://www.heanet.ie/

1 0

Solving the issue of rogue ROUTE objects in the RIPE Database
by denis 14 Nov '15

14 Nov '15

Hi All I raised an idea before the last RIPE Meeting but it did not generate a lot of interest at that time. I brought it up again yesterday on the Anti Abuse WG list and it seemed to get quite a bit of support. So I will bring it back to the DB WG as it is a DB issue. I have CC'ed both AA WG and Routing WG for information. But it may be useful to keep the discussion now on the DB WG list. I don't claim this will solve all the problems of the universe, but it does satisfy an immediate goal to have all ROUTE objects in the RIPE Database created with the knowledge and approval of the related resource holders. And I believe it could be implemented in a relatively short space of time giving immediate benefits. cheers denis STEP 1 Any ROUTE object submitted for creation in the RIPE Database involving an out of region resource (address space and/or ASN) where that out of region resource does not exist in the authoritative RIR database (has not been allocated or assigned), reject the creation. The RIPE NCC mirrors the operational data from all the other 4 RIRs. These mirrors are updated daily as well as the RIRs daily stats. It is easy to determine if a resource is registered in the authoritative database. STEP 2 For those ROUTE objects from STEP 1 where the out of region resource does exist, hold the object creation as pending. The mechanism for doing this already exists in the RIPE Database software as it is used for multiple authentications. Lookup the out of region resource(s) in the authoritative database(s) and find the contacts for that resource. Send a notification to those contacts informing them of the pending ROUTE object creation in the RIPE Database. The notification mechanism already exists in the RIPE Database software. If they don't approve, do nothing and the creation request will time out after a week and the object will not be created. If they do approve, respond in some way (many technical options for doing this that the RIPE NCC can choose from). If appropriate approval(s) are received within a week, create the ROUTE object. STEP 3 On a daily basis, for each ROUTE object in the RIPE Database that relates to an out of region resource, check for the continued existence of that resource in the appropriate RIR database. If it no longer exists, delete the ROUTE object from the RIPE Database. STEP 4 This is a one off cleanup of existing ROUTE objects. For all ROUTE objects currently in the RIPE Database that relate to an out of region, existing resource, send the appropriate notifications. For any that no response is received, delete the ROUTE object from the RIPE Database. We can be a bit more generous on the timing for this step and even send multiple reminder notifications to be sure. (Possible) STEP 5 If a delete request is sent to the RIPE Database for a ROUTE object related to out of region address space without the proper authorisation, send a notification to the contacts for the authoritative address space holder. If an appropriate response is received back, delete the ROUTE object. This would simulate the reclaim functionality for RIPE address space holders. AUT-NUM copies Another byproduct of implementing this is that we no longer need to hold copies of AUT-NUM objects in the RIPE Database. The out of region ASN auth requirement is satisfied by the appropriate response to the notification. So all 'foreign' AUT-NUM objects could be immediately deleted. (Or after allowing time for these ASN holders to make sure their routing policy is actually up to date in the authoritative AUT-NUM object.)

9 22