From mschmidt at ripe.net Tue Feb 2 15:33:37 2016 From: mschmidt at ripe.net (Marco Schmidt) Date: Tue, 02 Feb 2016 15:33:37 +0100 Subject: [anti-abuse-wg] 2016-01 New Policy Proposal (Include Legacy Internet Resource Holders in the Abuse-c Policy) In-Reply-To: <56ACF3D0.3050300@yahoo.co.uk> References: <56AB7F0E.1080401@ripe.net> <56ACF3D0.3050300@yahoo.co.uk> Message-ID: <56B0BE41.4090105@ripe.net> Hello Denis, Thank you for your question. There are currently about 4,000 top-level legacy resources registered in the RIPE Database. Some of the organisations, that have received these resources from organisations like InternNIC, have distributed parts of these address blocks further to other parties. The details of this further distribution are often not known to the RIPE NCC. It is possible, that the holder of the top-level legacy resource has no responsibility for the more specific blocks. Therefore it can't be assumed by default that Legacy address space follows the same clear hierarchical structure as address space allocated by the RIPE NCC. It would be part of the implementation to find out if the resource holders of top-level legacy resources want to be responsible for more specific objects. Currently this is only known, when legacy resource holders have entered into a contractual relationship with the RIPE NCC. Details about the challenges to identify the legitimate holder of legacy resources have been outlined in the impact analysis for proposal 2012-07, "RIPE NCC Services to Legacy Internet Resource Holders". https://www.ripe.net/participate/policies/proposals/2012-07 Based on the approach the RIPE community will choose, the RIPE NCC will perform a deeper analysis on the actual impact once this proposal would move to the Review Phase. Hope this answers your question. Regards, Marco Schmidt Policy Development Officer RIPE NCC On 30/01/2016 18:33, denis wrote: > > > On 29/01/2016 16:02, Marco Schmidt wrote: >> 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. > > How many of these INETNUM objects are top level legacy resources? They > are the only ones that need an "abuse-c:" attribute. > >> >> 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. > > NO!!! Only top level legacy resource need to reference an ORGANISATION > object. Keep in mind that every object more specific to the top level > legacy resource object also has the same status 'LEGACY'. > >> >> A third approach would add abuse-c references to all organisation >> objects held by legacy holders. The RIPE NCC would need to contact these > > Again NO!!! This is the same argument I have had about the new > Webupdates. Because "abuse-c:" works in an inherited way within the > hierarchy it is fundamentally wrong to add redundant links where they > are not needed. > > cheers > denis > >> 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 >>> > 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 >> From kaplan at cert.at Wed Feb 10 15:23:17 2016 From: kaplan at cert.at (L. Aaron Kaplan) Date: Wed, 10 Feb 2016 15:23:17 +0100 Subject: [anti-abuse-wg] Updated Document: Abuse Contact Data Sets In-Reply-To: <56A2251F.7060204@netcologne.de> References: <569FB45B.7070400@heanet.ie> <56A2251F.7060204@netcologne.de> Message-ID: <30574EFF-92C1-4AB8-9E61-2E87F0C680BB@cert.at> Dear Gunther, dear anti abuse wg list, > On 22 Jan 2016, at 13:48, Gunther Nitzsche wrote: > > On 01/20/2016 05:22 PM, Brian Nisbet wrote: >> 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. >> I am one of the co-authors. First of all let me say a big "thank you" to Gunther and everyone who gave us feedback. While we were able to incorporate most feedback and suggestions , we are very well aware that this is just a first version of the document and that the contents discussed in the document is bound to change frequently. So, in case some feedback did not make it yet, we apologise and aim to add it to the next version. Please also find some comments to Gunther's mail below inline. > (...) > > > Some notes to the text: > > . Problem Statement > CERTs need to look up contact information frequently > > > that might not hit the problem completely. Abuse-contacts are usually > contacted by victims, spamtrap/honeypot/incident reporters > or just by abuse-aware mailserver providers. CERTs are a very small > sub-section of contacts - important, but definitely not the main > abuse-contact searchers. Well, you are right but this document focuses on CERTs and incident handlers as target audience of the document. The document has a special focus on tools which yield themselves to automation (APIs). So that's why we left it as it is right now. Open to new suggestions (as noted above) to expand the target audience of course... > > > The first example - hacked webpages - is also not completely the way how > reporters (the ones I know) work. For CERTs i can assure that that's the way they work :) > admin-c and tech-c are good targets for the complaint; but there is no > need to find more and more hacked > webspaces in the same ip-range before contacting the ip-address owner. Please note that we should not get stuck on this one specific text. It was an example. > That means: the reporter resolves > the (first (!)) webpage address to an ip-address and contacts the owner > of this ip-address (who is either > responsible for the content by himself or has some kind of contract with > the domain-owner) > In the end it is always the owner of the ip-address who can put an end > to abuse. > > In the end of "4" it says: "his document aims at describing these > different datasets " > but it is not described what "these" datasets are. In the lines before > that only problems with existing > sourced are listed. Fixed, thank you for the suggestion. > > > > In the end of section 5 it reads: > > "Sometimes an incident reporter might want to contact a single point of > contact (PoC) for a whole country." > > I would change that to: "in very rare cases.." We left it because many CERTs address other national CERTs as a super-remediator. Again - it's a matter of how you define the target audience :) > > > *6. Existing Datasets > * > > If you say: we list various datasets that can be used by incident > reporters to determine the right contact information > > then it might not be the right idea to list sources who are "member > only" restricted or > give only information about listed members like the 6.1. This list maybe > helpful (?) for > CERTs contacting other CERTs, but it is not an obvious source for "the > incident reporter" Please note that nearly all of them are not members only. What a members only section contains is *additional* information. But that's a good point... noted for the next iteration. Thank you. > > Same problem with 6.2:https://www.first.org/ > This list maybe helpful (?) for CERTs contacting other CERTs, but it is > not an obvious source > for "the incident reporter". It is "the global Forum for Incident > Response and Security Teams", > not a source for an "incident reporter" to determine an abuse address. > The API only lists > FIRST members. Not very helpful in the day-to-day abuse contact search. > Again. Depends on the target audience of the document. For us (CERTs) it is :) > 6.3 CSIRT Database...yes, nice..but ..it has nothing to do with the > search for a direct > abuse contact for a given incident. > see above. > 6.4. Enisa .. even more CERTs...no api > unfortunately no API yet. Yes. But... > 6.5 even more CERTs .. > > 6.6 here we go..there is a source! > :) (..) > -------------- > What I am missing: > > * name based search: which whois databases are out there; maybe which format > do they use in the output, which email-address in the output should be > used as contact. > We discussed this. Yes. However, is it really important to document name based (domain) whois? I mean - that technology just works out of the box when you apt-get install whois. (in OSX it comes by default on the cmd line, same for windows) So, what would be the point in documenting plain old good whois for domains? "yes it exists!" :) That's sort of the only thing that comes to my mind :) > * ip-based search: which sources can really be asked (by the public > and/or by CERTs) > (like abusix, which was for some strange reasons not included. (Some > Data Sets mentioned > in the document include also "second hand sources" - can't see a > difference to > abusix) > -> next version. We have been talking to abusix already. But good catch. > > While there might be a need or at least interest in a document like this > I would > change the targeted audience from > > " This document is targeted towards CERTs and abuse handlers as well as > professionals working > on automating IT security incident handling." > > to something like > > " This document is targeted towards CERTs and professional IT security > teams working on incident handling." Well, actually I like the part about automating IT security incident handling. Because that is *exactly* why we started to document this. The next step will be a client library which is capable of querying all these APIs (if they exist - see ENISA case) and offer that as a plugin in lib for automation tools. > > > Also I would change the purpose of the document: > > "this document is intended to document existing data sources for abuse > handlers." > > to something like: > > "this document is intended to document existing CERT and security team > contacts" No. I do not agree here. Because it also tries to document for example stats.ripe.net And that is not only a CERT contact DB. > > The example (hacked webpage) mentioned in section 1 shows the problem: > If an incident reporter wants to report that incident, he has no > advantages to > find the right abuse contact by scrolling through the CERT-list in this > document. > That example shows that either the targeted audience or the description > of the > purpose should be adapted. > > > Sorry to sound so destructive :-/ > Not at all. Thank you very much for the feedback. Measuring our document against critique makes it better. That does not mean, I agree with every point you made (I agree with some). But it got us thinking. Thank you very much for taking so much time in answering. We decided to push out the document - we can still make another iteration for the next version :) This topic is changing regularly. Thank you all for the feedback! L. Aaron Kaplan -- // CERT Austria // L. Aaron Kaplan // T: +43 1 505 64 16 78 // http://www.cert.at // Eine Initiative der NIC.at Internet Verwaltungs- und Betriebs GmbH // http://www.nic.at/ - Firmenbuchnummer 172568b, LG Salzburg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP using GPGMail URL: From brian.nisbet at heanet.ie Thu Feb 11 14:51:50 2016 From: brian.nisbet at heanet.ie (Brian Nisbet) Date: Thu, 11 Feb 2016 13:51:50 +0000 Subject: [anti-abuse-wg] Abuse Contact Data Sets Document Published Message-ID: <56BC91F6.7070600@heanet.ie> 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/ From brian.nisbet at heanet.ie Fri Feb 19 10:46:42 2016 From: brian.nisbet at heanet.ie (Brian Nisbet) Date: Fri, 19 Feb 2016 09:46:42 +0000 Subject: [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 In-Reply-To: <7035FAF5-4DF7-43E6-8759-20FF9FDBBEA4@ripe.net> References: <61E8987E-8774-422F-A758-17A6E6EB6DF7@ripe.net> <567046AC.3000802@heanet.ie> <568B8CF4.2070208@heanet.ie> <56950C55.4060802@heanet.ie> <7035FAF5-4DF7-43E6-8759-20FF9FDBBEA4@ripe.net> Message-ID: <56C6E482.1010909@heanet.ie> Tim, On 14/01/2016 14:57, Tim Bruijnzeels wrote: > Hi all, > > > >> On 12 Jan 2016, at 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? > > Yes. Unless we hear otherwise we will send the emails on 1 February and proceed to set the abuse-c on 15 February. So people have two weeks to set their abuse contact to something else before we create it. However no action is necessary in case they are happy with the email address we will use in the object, and they can of course also modify the abuse-mailbox later. I was just wondering, would you be able to provide an update on this project? 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 fax: +35316603666 web: http://www.heanet.ie/ From brian.nisbet at heanet.ie Fri Feb 19 10:48:43 2016 From: brian.nisbet at heanet.ie (Brian Nisbet) Date: Fri, 19 Feb 2016 09:48:43 +0000 Subject: [anti-abuse-wg] Reminder: 2016-01 New Policy Proposal (Include Legacy Internet Resource Holders in the Abuse-c Policy) Message-ID: <56C6E4FB.40601@heanet.ie> 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/ From eshryane at ripe.net Fri Feb 19 10:50:47 2016 From: eshryane at ripe.net (Edward Shryane) Date: Fri, 19 Feb 2016 10:50:47 +0100 Subject: [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 In-Reply-To: <56C6E482.1010909@heanet.ie> References: <61E8987E-8774-422F-A758-17A6E6EB6DF7@ripe.net> <567046AC.3000802@heanet.ie> <568B8CF4.2070208@heanet.ie> <56950C55.4060802@heanet.ie> <7035FAF5-4DF7-43E6-8759-20FF9FDBBEA4@ripe.net> <56C6E482.1010909@heanet.ie> Message-ID: <2FFA7B8E-E9D9-4FD8-90C5-F782D24F0EEA@ripe.net> > On 19 Feb 2016, at 10:46, Brian Nisbet wrote: > > Tim, > > On 14/01/2016 14:57, Tim Bruijnzeels wrote: >> Hi all, >> >> >> >>> On 12 Jan 2016, at 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? >> >> Yes. Unless we hear otherwise we will send the emails on 1 February and proceed to set the abuse-c on 15 February. So people have two weeks to set their abuse contact to something else before we create it. However no action is necessary in case they are happy with the email address we will use in the object, and they can of course also modify the abuse-mailbox later. > > I was just wondering, would you be able to provide an update on this project? > > Thanks, > > Brian > Morning Brian, we set the abuse-c for the remaining organisations on 15 February, as planned, and contacted those affected by email. Regards Ed Shryane RIPE NCC -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 235 bytes Desc: Message signed with OpenPGP using GPGMail URL: From brian.nisbet at heanet.ie Fri Feb 19 10:52:50 2016 From: brian.nisbet at heanet.ie (Brian Nisbet) Date: Fri, 19 Feb 2016 09:52:50 +0000 Subject: [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 In-Reply-To: <2FFA7B8E-E9D9-4FD8-90C5-F782D24F0EEA@ripe.net> References: <61E8987E-8774-422F-A758-17A6E6EB6DF7@ripe.net> <567046AC.3000802@heanet.ie> <568B8CF4.2070208@heanet.ie> <56950C55.4060802@heanet.ie> <7035FAF5-4DF7-43E6-8759-20FF9FDBBEA4@ripe.net> <56C6E482.1010909@heanet.ie> <2FFA7B8E-E9D9-4FD8-90C5-F782D24F0EEA@ripe.net> Message-ID: <56C6E5F2.30009@heanet.ie> On 19/02/2016 09:50, Edward Shryane wrote: > >> On 19 Feb 2016, at 10:46, Brian Nisbet wrote: >> >> Tim, >> >> On 14/01/2016 14:57, Tim Bruijnzeels wrote: >>> Hi all, >>> >>> >>> >>>> On 12 Jan 2016, at 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? >>> >>> Yes. Unless we hear otherwise we will send the emails on 1 February and proceed to set the abuse-c on 15 February. So people have two weeks to set their abuse contact to something else before we create it. However no action is necessary in case they are happy with the email address we will use in the object, and they can of course also modify the abuse-mailbox later. >> >> I was just wondering, would you be able to provide an update on this project? >> >> Thanks, >> >> Brian >> > > Morning Brian, > > we set the abuse-c for the remaining organisations on 15 February, as planned, and contacted those affected by email. Thanks for the update! 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 fax: +35316603666 web: http://www.heanet.ie/ From rv at NIC.DTAG.DE Sun Feb 28 19:38:10 2016 From: rv at NIC.DTAG.DE (Ruediger Volk) Date: Sun, 28 Feb 2016 19:38:10 +0100 Subject: [anti-abuse-wg] objection to RIPE policy proposal 2016-01 Message-ID: <11461.1456684690@x59.NIC.DTAG.DE> 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 From ops.lists at gmail.com Mon Feb 29 12:09:25 2016 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Mon, 29 Feb 2016 16:39:25 +0530 Subject: [anti-abuse-wg] objection to RIPE policy proposal 2016-01 In-Reply-To: <11461.1456684690@x59.NIC.DTAG.DE> References: <11461.1456684690@x59.NIC.DTAG.DE> Message-ID: <432BB70C-DD25-42C1-AFBA-BAB04E64C27A@gmail.com> On 29-Feb-2016, at 12:08 AM, Ruediger Volk wrote: > We have to assume that Internet number resource holders requested > to establish abuse-c > - usually are NOT focussed an abuse handling (different core business:-) With all due respect - assume that the number resource holder is a corporation engaged in, for example, brewing beer. Admittedly their core business is not providing internet access or managing abuse. Wouldn?t they have a corporate IT team tasked with looking at compromises on their network that are causing abuse / DDoS issues (which might further lead to data leaks from their company etc)? With abuse-c an external reporter can reach out to the appropriate team, which might possibly be a third party vendor, rather than having to call or email the brewery?s corporate HQ and then have the message work through several layers of staff and possibly just get lost. This merely provides a standard format to contact the relevant team - which may well be the same corporate IT team for them that manages their IP space and routing. Reporters are simply spared the decision tree of whether to mail a tech contact for a ddos issue where he / she may be totally different from the security department that handles it. Or an ISP providing services and allocating a range to their customer may want their information in the abuse-c. From michele at blacknight.com Mon Feb 29 13:37:16 2016 From: michele at blacknight.com (Michele Neylon - Blacknight) Date: Mon, 29 Feb 2016 12:37:16 +0000 Subject: [anti-abuse-wg] objection to RIPE policy proposal 2016-01 In-Reply-To: <11461.1456684690@x59.NIC.DTAG.DE> References: <11461.1456684690@x59.NIC.DTAG.DE> Message-ID: <734DEF8D-6AD8-420C-8F2F-F53563DF3E2C@blacknight.com> Reedier I disagree A standardised abuse-c contact was introduced by RIPE some time ago based on the anti-abuse WG?s work. This was communicated via various media and via RIPE staff and at RIPE meetings etc., The ?new? policy that is being proposed improves the overall ecosystem for all users and any delay in implementing it is ill advised. Regards Michele -- Mr Michele Neylon Blacknight Solutions Hosting, Colocation & Domains http://www.blacknight.host/ http://blog.blacknight.com/ http://ceo.hosting/ Intl. +353 (0) 59 9183072 ------------------------------- Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty Road,Graiguecullen,Carlow,Ireland Company No.: 370845 From dhc at dcrocker.net Mon Feb 29 16:09:11 2016 From: dhc at dcrocker.net (Dave Crocker) Date: Mon, 29 Feb 2016 07:09:11 -0800 Subject: [anti-abuse-wg] objection to RIPE policy proposal 2016-01 In-Reply-To: <432BB70C-DD25-42C1-AFBA-BAB04E64C27A@gmail.com> References: <11461.1456684690@x59.NIC.DTAG.DE> <432BB70C-DD25-42C1-AFBA-BAB04E64C27A@gmail.com> Message-ID: <56D45F17.3010100@dcrocker.net> On 2/29/2016 3:09 AM, Suresh Ramasubramanian wrote: > On 29-Feb-2016, at 12:08 AM, Ruediger Volk wrote: >> We have to assume that Internet number resource holders requested >> to establish abuse-c >> - usually are NOT focussed an abuse handling (different core business:-) > > With all due respect - assume that the number resource holder is a corporation engaged in, for example, brewing beer. ... > Wouldn?t they have a corporate IT team tasked with looking at compromises on their network that are causing abuse / DDoS issues ... > With abuse-c an external reporter can reach out to the appropriate team, ... +1 d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From jerry1upton at aol.com Mon Feb 29 21:51:23 2016 From: jerry1upton at aol.com (Jerry Upton) Date: Mon, 29 Feb 2016 15:51:23 -0500 Subject: [anti-abuse-wg] objection to RIPE policy proposal 2016-01 In-Reply-To: <56D45F17.3010100@dcrocker.net> Message-ID: <1532eccbe5a-60ba-8c84@webprd-m49.mail.aol.com> +2 Jerry Upton Executive Director M3AAWG.org -----Original Message----- From: Dave Crocker To: Suresh Ramasubramanian ; Ruediger Volk Cc: aa-wg-chairs ; db-wg-chairs ; db-wg ; anti-abuse-wg Sent: Mon, Feb 29, 2016 9:10 am Subject: Re: [anti-abuse-wg] objection to RIPE policy proposal 2016-01 On 2/29/2016 3:09 AM, Suresh Ramasubramanian wrote: > On 29-Feb-2016, at 12:08 AM, Ruediger Volk wrote: >> We have to assume that Internet number resource holders requested >> to establish abuse-c >> - usually are NOT focussed an abuse handling (different core business:-) > > With all due respect - assume that the number resource holder is a corporation engaged in, for example, brewing beer. ... > Wouldn?t they have a corporate IT team tasked with looking at compromises on their network that are causing abuse / DDoS issues ... > With abuse-c an external reporter can reach out to the appropriate team, ... +1 d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From fw at deneb.enyo.de Mon Feb 29 22:06:55 2016 From: fw at deneb.enyo.de (Florian Weimer) Date: Mon, 29 Feb 2016 22:06:55 +0100 Subject: [anti-abuse-wg] objection to RIPE policy proposal 2016-01 In-Reply-To: <11461.1456684690@x59.NIC.DTAG.DE> (Ruediger Volk's message of "Sun, 28 Feb 2016 19:38:10 +0100") References: <11461.1456684690@x59.NIC.DTAG.DE> Message-ID: <87lh638bv4.fsf@mid.deneb.enyo.de> * Ruediger Volk: > 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. How is 2016-01 different from sending such notices? The net effect seems to be about the same. The interesting question (with either approach) is what RIPE NCC should do if it has proof that the contact information in the RIPE database is incorrect.