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

Fwd: Hijack factory: AS201640 -- MEGA - SPRED LTD / Michael A. Persaud
by Suresh Ramasubramanian 20 Jun '16

20 Jun '16

I knew the time was, well, ripe for something like this to pop up directly after rfg started asking those questions yesterday. ---------- Forwarded message --------- From: Ronald F. Guilmette <rfg(a)tristatelogic.com> Date: Thu, 6 Nov 2014 at 03:31 Subject: Hijack factory: AS201640 -- MEGA - SPRED LTD / Michael A. Persaud To: <nanog(a)nanog.org> I already posted about this rogue AS days ago, but nothing has really changed much, since then, with respect to its hijacking of IP space. Well, at least Brian Krebs was kind anough to write about it: http://krebsonsecurity.com/2014/11/still-spamming-after-all-these-years/ (Please note that that is a convicted felon spamming from the hijacked IP space. He's not allowed to own firearms, but he _can_ apparently own a keyboard.) As of today, AS201640 is still hijacking a total of eleven routes to IP space scattered all over the world... none of which appears to belong to anybody in or near Bulgaria. In fact, it would appear that the organization that is the registrant of AS201640 currently has exactly -zero- IP addresses to call its own. Nobody in a postion to _do_ anything about this gives a darn? As of today: 36.0.56.0/21 41.92.206.0/23 41.198.80.0/20 41.198.224.0/20 61.242.128.0/19 119.227.224.0/19 123.29.96.0/19 177.22.117.0/24 177.46.48.0/22 187.189.158.0/23 202.39.112.0/20

6 8

RIPE NCC to set abuse-c for remaining organisation with ASNs or other resources allocated or assigned by the RIPE NCC
by Tim Bruijnzeels 19 Feb '16

19 Feb '16

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

9 20

Updated Document: Abuse Contact Data Sets
by Brian Nisbet 10 Feb '16

10 Feb '16

Colleagues, The group working on this document (L. Aaron Kaplan, Mirjam Kühne, Christian Teuschel) have produced a new draft. This draft contains a number of updates, based on feedback from the community. The main changes are: - clarified terminology such as abuse handler, security incident, registrant, national CERT, etc. - clarified problem statement - removed specific mentioning of name-based services in the problem statement - used "European" examples - added API details for Nation CSIRT DB - elaborated on conclusion and next steps This document was sent to me earlier in the week, but for various reasons I didn't manage to forward it on to you all until now. With the TF-CSIRT meeting happening next week it would be great if we could gather any further feedback before the end of this week, but I realise that is quite a short term period, for which I apologise. So I'm not proposing a hard cut-off by end of day on Friday, but I think it would be extremely useful if people could try to post to the list before then. This would hopefully allow the authors to go to the TF-CSIRT meeting with a very nearly final draft and then complete it shortly afterwards. Certainly I would propose no more than a working week to receive other feedback, so we'd be looking at the end of Wednesday 27th. Thanks, Brian Co-Chair, RIPE AA-WG

5 4

Re: [anti-abuse-wg] 2016-01 New Policy Proposal (Include Legacy Internet Resource Holders in the Abuse-c Policy)
by Marco Schmidt 02 Feb '16

02 Feb '16

Hi Piotr, We’re happy to outline some high-level approaches for how we might meet the requirements of the proposal. Please note that details of the actual implementation and potential limitations will need further study and will be covered in the impact analysis. We will seek guidance from the RIPE community on which particular approach it would like us to take — whether this ends up being a variation on one of the approaches mentioned below, or something different altogether. With this in mind, we would like to share the following information to support the WG’s discussion. The RIPE Database currently contains ~70,200 inetnum objects and ~700 aut-num objects with the status LEGACY. Of these, around 11,900 have an organisation object referenced, with around 3,900 of these organisation objects having an abuse-c attribute in place. This means that around 17% of the resource objects have an organisation object and around 5.5% have a reference to an abuse contact. One possible approach could be to add the abuse-c attribute to existing organisation objects. This could be done in a similar way to how it was done for resources that were allocated or assigned by the RIPE NCC. Resources without an organisation object would not have an abuse contact. The mandatory database update that Erik mentioned could be another possible approach. Whenever a resource with the status LEGACY is updated, it must have a reference to an organisation object with the abuse-c attribute to perform this update. Resources that are not updated will not get an abuse contact. A third approach would add abuse-c references to all organisation objects held by legacy holders. The RIPE NCC would need to contact these holders of 67,000 objects, of which 59,000 have no organisation object. Taking into account our experience from implementing 2007-01, “Direct Internet Resource Assignments to End Users from the RIPE NCC”, we would expect a significant amount of manual work with this approach. The RIPE NCC is currently unable to enforce updates on legacy resources. We hope this helps with your discussion of the proposal. Kind regards Marco Schmidt Policy Development Officer RIPE NCC On Thu, Jan 28, 2016 at 18:49:41 +0100, Piotr Strzyzewski wrote: > On Thu, Jan 28, 2016 at 10:06:50AM +0100, Marco Schmidt wrote: > > Marco > > > A new RIPE Policy proposal, "Include Legacy Internet Resource > Holders in > > the Abuse-c Policy", is now available for discussion. > > > > The goal of this proposal is to extend RIPE Document ripe-563, "Abuse > > Contact Management in the RIPE Database", to Legacy Internet Resource > > Holders. > > > > You can find the full proposal at: > > > > https://www.ripe.net/participate/policies/proposals/2016-01 > > > > We encourage you to review this proposal and send your comments to > > <anti-abuse-wg at ripe.net> before 26 February 2016. > > Would you be so kind and publish possible approaches to deal with the > requirements of this proposal. It will be a benefit for the members of > this WG to see how NCC perceive this proposal. > > Thanks in advance, > Piotr > > -- > gucio -> Piotr Strzyżewski > E-mail: Piotr.Strzyzewski at polsl.pl

2 2

2016-01 New Policy Proposal (Include Legacy Internet Resource Holders in the Abuse-c Policy)
by Marco Schmidt 31 Jan '16

31 Jan '16

Dear colleagues, A new RIPE Policy proposal, "Include Legacy Internet Resource Holders in the Abuse-c Policy", is now available for discussion. The goal of this proposal is to extend RIPE Document ripe-563, "Abuse Contact Management in the RIPE Database", to Legacy Internet Resource Holders. You can find the full proposal at: https://www.ripe.net/participate/policies/proposals/2016-01 We encourage you to review this proposal and send your comments to <anti-abuse-wg(a)ripe.net> before 26 February 2016. Regards Marco Schmidt Policy Development Officer RIPE NCC

7 13

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 13 Jan '16

13 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