February 2016 - anti-abuse-wg

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

objection to RIPE policy proposal 2016-01
by Ruediger Volk 09 Mar '16

09 Mar '16

Dear colleagues, I object to passing the policy as proposed. There is no serious need for the policy, and at this time and under curent circumstance it would actually be harmful. I believe that the supposed good intentions would be better served by other actions, and the policy focussing on enforcement is ill advised. I understand that the current implementation of the RIPE database allows legacy holders to enter abuse-c attributes for their legacy resources if that's currently not possible the required extension of the database should be discussed (in the approprioate wg) and implementation would NOT require the PDP (as more drastic changes have been done to the database - and that extension hardly would contradict existing policy). No PDP is needed to send friendly invitations to legacy holders to populate their data objects with abuse-c information; I'm sure asking the RIPE NCC to do this would not create an undue burden or serious problem. Enhancing the invitations with some additional information potentially helpful to the recipients could be considered too: - some hints/guidance about expected use and support of that mailbox (active members of the abuse handling community probably will NOT be the typical recipient! and no injuries are expected if any community member sees that information:-) - specific suggestions what to put into the abuse-c field (whatever the RIPE NCC might use to extrapolate abuse-c from existing data) The working group should contribute helpful information to be included. I'm quite certain running a second invitation campaign would be even less of a problem and effort for RIPE NCC; I cannot predict how much the information provided in a later campaign can be improved based on feedback and experience from an earlier one. You may argue, that such more friendly approach could have been used also earlier - and I would very much agree and I certainly complained and suggested that at least the forced population of missing abuse-c should be postponed until friendly information was made available. Now we do NOT HAVE TO repeat past errors... Specifically with legacy resource holders it would be a good idea for RIPE community and NCC to address them with an inviting and helpful approach; as there is a sad history of seemingly coercive and unfriendly communications towards legacy holders. REPEATING the error now - even considering the much lower number of relevant records - is however actually MORE SERIOUS in DAMAGING the CREDIBILITY of the working group (and as a consequence the RIPE NCCs position) because of the accumulated history. Repeated requests for information on supposed use und handling of abuse-c has been answered by pointing out that it is required by a policy that was consciously created without any such information. The new policy proposal painfully fits into the sad observation that the anti-abuse working group as a community has constantly put effort into enforcing creation and population of abuse-c data but not (even tried) to provide to the rest of the world helpful explanations on requirements and expected handling at the requested mailboxes. That observations leads to the question whether the community is not able to come up with some helpful explanation or whether it does not care... :-( In both cases asking for enforcement does seem neither appropriate nor acceptable and means that the request cannot be taken serious - bad for the perception of RIPE and RIPE NCC activety by parties that are not heavily involved in the community processes. Consider the typical person confronted with a request to define abuse-c: how deeply is he involved with the anti-abuse working group (where a common understanding might exist - I consider myself only occassional observer and not a member and don't know)? Trying to close more quickly and on a more constructive perspective let me skip to elaborate here on my judgement: at close inspection the rationale and arguments look quite broken. The policy content does actually not matter that much - look for a sketch of a potential harmless implementation approach above in this message. What matters is appropriate use of the PDP (it can be abused!!!) and what are good goals of the working group and good ways of achieving them. The assumed good goals (as I understand it) are (a) improving quality of abuse-c information in order to (b) improve abuse reporting and report handling processes and (c) extending the abuse-c coverage for Internet number resources in the RIPE NCC registry The policy proposal references (a) and (b) quite explicitly; I took the liberty to interpolate (b) which actually seems to be the primary goal, and it looks like the working group decided that this will be helped by means of creating distinctly identified mailbox information to be put into abuse-c. The criterium for gauging (a) seems to be whether "improved data" actually helps "improve processing" (b) - what else? Creating abuse-c entries of better/good quality obviously depends on the recipient being appropriate and informed about expected potential messages and preparing to deal with them. Forcing creation of abuse-c in any other way is not going to create better quality but actually looses information (you loose track of which entries have the "quality of informed and [potentially] prepared recipient"). We have to assume that Internet number resource holders requested to establish abuse-c - usually are NOT focussed an abuse handling (different core business:-) - in many cases are not members of the anti-abuse working (and unlikely to have insight into undocumented potential consensus views of the working group or the larger abuse-c activist community) - in general willing to cooperate (we really should care for those and help them! ... yes, there are others - from "don't care" to "evil") For making a reasoned decision about the recipient for abuse-c and preparing for handling messages one obviously needs some understanding/explanation of what is expected. If no such helpful information is offered at the time of requesting abuse-c setup, many well intentioned parties will *something* (not really good "quality") to fill required fields and little motivation to followup will remain. If they care to ask for helpful information and the answer stays "this is required by policy, and it consciously declines to explain", they are likely to conclude that they have to submit to RIPE policies and the policy makers+process that cannot be taken serious... I note that for goal (b) of course some common understanding of expected use and handling for the abuse-c mailbox is a prerequisite on BOTH sides (senders also!) I do not expect to see formal, precise, and exhaustive definition of requirements and intended/expected use of abuse-c use - that would seem fairly impossible and certainly would not provide a practical answer to the issue. The working group needs to followup it previous abuse-c policy by starting to create practically useful explanations, before considering more "enforcement" (actually IMHO all enforcement activety should [have] be[en] postponed - potentially replaced by friendly invitations). It may take considerable effort to develope consensus on such documentation - but is it reasonable to rely on all relevant outside parties to have the first contact figure out completely on his own and explain to his management, consultants, service providers, etc... what needs to be done? (what aggregated cost and what "quality" implications do you expect?) It's ok to have working groups that just have internal fun between some birds of a feather. If a working group feels like making demands (e.g. policies) to a larger community it should also consider what support it needs to provide to serve the purposes of that larger community. Thanks for your attention and consideration. Ruediger Volk P.S.: Sorry, for a painfully long message. Trust me I had more painful time writing - and making it shorter would have been worse - with termination not secure:-) I hope that the painful length does not obscure - valid concern - constructive suggestions

13 16

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

Reminder: 2016-01 New Policy Proposal (Include Legacy Internet Resource Holders in the Abuse-c Policy)
by Brian Nisbet 19 Feb '16

19 Feb '16

Colleagues, We're now a week away from the end of the initial discussion phase on 2016-01 and things have been a little quiet here of late. The Chairs would greatly appreciate more opinions and/or discussion of the policy and/or some of the specific suggested approaches. You can find the (very short) policy text here: https://www.ripe.net/participate/policies/proposals/2016-01 and you can find the specific approaches in the recent mails to the list. Thanks, Brian Co-Chair, RIPE AA-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 fax: +35316603666 web: http://www.heanet.ie/

1 0

Abuse Contact Data Sets Document Published
by Brian Nisbet 11 Feb '16

11 Feb '16

Colleagues, Thank you for the feedback and conversation around the Abuse Contact Data Sets document. A lot of this has been incorporated, along with a few other tweaks, into the final version of the document which has now been published as RIPE-658 and can be found here: https://www.ripe.net/publications/docs/ripe-658 Of course there will be other iterations of this document as things change. Thanks also to the three authors, L. Aaron Kaplan, Mirjam Kühne and Christian Teuschel. Brian Co-Chair, RIPE AA-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 fax: +35316603666 web: http://www.heanet.ie/

1 0

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