September 2017 - anti-abuse-wg

2017-02 New Policy Proposal (Regular abuse-c Validation)
by Marco Schmidt 27 Oct '17

27 Oct '17

Dear colleagues, A new RIPE Policy proposal, 2017-02, "Regular abuse-c Validation", is now available for discussion. The goal of this proposal is to give the RIPE NCC a mandate to regularly validate "abuse-c:" information and to follow up in cases where contact information is found to be invalid. You can find the full proposal at: https://www.ripe.net/participate/policies/proposals/2017-02 As per the RIPE Policy Development Process (PDP), the purpose of this four-week Discussion Phase is to discuss the proposal and provide feedback to the proposer. At the end of the Discussion Phase, the proposer, with the agreement of the RIPE Working Group Chairs, decides how to proceed with the proposal. We encourage you to review this proposal and send your comments to <anti-abuse-wg(a)ripe.net> before 6 October 2017. Kind regards, Marco Schmidt Policy Development Officer RIPE NCC Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum

10 15

Re: [anti-abuse-wg] 2017-02: what does it achieve?
by Malcolm Hutty 05 Oct '17

05 Oct '17

Andre writes: > probably, yes. if ai is advanced enough to deal with incoming > communications in an acceptable fashion, this will be just fine. > - your trust in your ai would be most commendable and as imho, ai will > be running everything in a few years anyway, this is perfectly > acceptable Andre, please accept my apologies for writing about the "Turing test", it was meant lightheartedly but has confused the issue. It is my fault for being flippant. I didn't envisage that a true AI would handle would such enquiries. I was pointing out two areas that are problematic, separately: 1. The RIPE NCC may not recognise an auto-responder when they see it, if it has been tailored to them specifically (and to achieving a formal but spurious compliance); and 2. A response by a real human being may be just useless as a bounce message, if constrained by policy. That is to say, if all the human is permitted to do is choose from a small range of stock responses (such as directing the person making the enquiry to some pre-written FAQ) then this is equivalent to an autoresponder, so why prohibit (deem non-compliant) only the automated response? However from Hervé's reply I see that a less ambitious bar is being set, and an autoresponder is acceptable, whether a human autoresponder or a software one. I have my doubts that this really achieves anything useful, but at least it is clear. On 25/09/2017 11:34, ox wrote: > On Mon, 25 Sep 2017 10:55:09 +0100 > Malcolm Hutty <malcolm(a)linx.net> wrote: >> Scenario 1: An LIR directs e-mail sent to their abuse-cc: address to >> an auto-responder that says "This mailbox is not monitored by a human >> being", and advises on alternate "support services" (e.g. a FAQ, a >> webform that feeds a ticketing system etc). Is RIPE NCC intended to >> mark the attribute as invalid in this scenario? >> > there is no point to have an email address that does not exist or is not monitored. > > if or when email ever stops working and is replaced by alternate "support services" > this will be a good timeTM to accept non monitored email addresses > > but to granularly define generally accepted forms of communications, > is pointless as there will always be a good reason for whatever form of > communication, to not be suitable or acceptable to someone. > > take mobile, or phone numbers, it can easily be argued "but i am not > available to take calls" or whatever... - everything always has > exceptions, it is whether those exceptions are generally reasonable or not > and/or generally acceptable. > > >> Scenario 2: An LIR filters incoming e-mail sent to their abuse-cc: >> address. Email from RIPE NCC gets "priority treatment", i.e. is >> directed to someone who passes a Turing test administered by the NCC. >> E-mail from anyone else gets the same treatment as in scenario 1. >> >> Is Scenario 2 compliant with the policy? If not, how is RIPE NCC >> supposed to know to mark the attribute as invalid? What tests are the >> NCC supposed to administer? And what must an LIR do to pass them? >> > probably, yes. if ai is advanced enough to deal with incoming > communications in an acceptable fashion, this will be just fine. > > ianal but, there are legal implications, if your ai receives x notice, replies, etc. > > - your trust in your ai would be most commendable and as imho, ai will > be running everything in a few years anyway, this is perfectly > acceptable :) > > > Andre > -- Malcolm Hutty | tel: +44 20 7645 3523 Head of Public Affairs | Read the LINX Public Affairs blog London Internet Exchange | http://publicaffairs.linx.net/ London Internet Exchange Ltd Monument Place, 24 Monument Street London EC3R 8AJ Company Registered in England No. 3137929 Trinity Court, Trinity Street, Peterborough PE1 1DA

7 9

Draft Minutes - RIPE 74 AA-WG Session
by Brian Nisbet 28 Sep '17

28 Sep '17

Colleagues, Apologies for the delay in circulating these minutes. Please let me know if you have any comments or corrections. Thanks, Brian -- Brian Nisbet Network Operations Manager HEAnet CLG, Ireland's National Education and Research Network 1st Floor, 5 George's Dock, IFSC, Dublin D01 X8N7, Ireland +35316609040 brian.nisbet(a)heanet.ie www.heanet.ie Registered in Ireland, No. 275301. CRA No. 20036270

1 0

2017-02: what does it achieve?
by Malcolm Hutty 25 Sep '17

25 Sep '17

I would like to clarify the effect of this proposal. The proposal states: "The RIPE NCC will validate the “abuse-mailbox:” attribute at least annually. If no valid reply is received by RIPE NCC within two weeks (including if the email bounces back), the “abuse-mailbox:” contact attribute will be marked as invalid." Scenario 1: An LIR directs e-mail sent to their abuse-cc: address to an auto-responder that says "This mailbox is not monitored by a human being", and advises on alternate "support services" (e.g. a FAQ, a webform that feeds a ticketing system etc). Is RIPE NCC intended to mark the attribute as invalid in this scenario? Scenario 2: An LIR filters incoming e-mail sent to their abuse-cc: address. Email from RIPE NCC gets "priority treatment", i.e. is directed to someone who passes a Turing test administered by the NCC. E-mail from anyone else gets the same treatment as in scenario 1. Is Scenario 2 compliant with the policy? If not, how is RIPE NCC supposed to know to mark the attribute as invalid? What tests are the NCC supposed to administer? And what must an LIR do to pass them? Malcolm. -- Malcolm Hutty | tel: +44 20 7645 3523 Head of Public Affairs | Read the LINX Public Affairs blog London Internet Exchange | http://publicaffairs.linx.net/ London Internet Exchange Ltd Monument Place, 24 Monument Street London EC3R 8AJ Company Registered in England No. 3137929 Trinity Court, Trinity Street, Peterborough PE1 1DA

4 4

@EXT: RE: 2017-02 New Policy Proposal (Regular abuse-c Validation)
by Mounier, Grégory 19 Sep '17

19 Sep '17

Hi everyone, Thank you all very much for your comments, suggestions and constructive 'criticisms'. Hervé and I have carefully read and assessed your points and we would like to provide the following answers and clarifications. First of all, thanks to all those would spoke in support of the proposal to mandate RIPE NCC to validate abuse-c contact. We wanted to stress that this proposal is basically our contribution to help RIPE NCC to implement some of its 2017 priorities such "maintaining a strong, secure and accurate registry" and "playing an active role in enhancing RIR stability through good governance and accountability". We hope that every attempts to pursue these goals will be welcomed by the community. Now turning to some specific questions: Sergey and Erik asked how would RIPE NCC deal with uncooperative legacy holders. We need to clarify that RIPE NCC members and PI will be impacted by the proposal. When it comes to legacy holders, while drafting the proposal we thought that the improvement of trust and safety of the IP space is a priority for the community in general and for LRH particularly. We think that this proposal would not impose an unreasonable burden on operators (confirmed by Andre and Michele's input) and could therefore be easily implemented by everybody (or at least the vast majority). Overall, this would be an improvement - yet not perfect - for the community as a whole. Sascha asked how RIPE NCC would proceed such validations. As explained by Marco and Brian, the specific procedure would be addressed by RIPE NCC in their impact analysis (IA). Initially we wanted to briefly describe a procedure but refrained from doing so because we thought that it would be a step too far and that it was for those who would conduct the validation process to come up with the right procedure. Nick and Erik proposed to include abuse-c validation in the Assisted Registry Check (aka ARC). The RIPE NCC confirmed that ARC is a rather light-weight procedure which only includes questions as to know if contact information are still correct without any specific check. Furthermore, it would take many years before all RIPE NCC members are checked via ARC at the current rate. For those who are alarmed that resources would be deregistered right after it would be tagged as invalid, we anticipated your concerns and specifically wrote: "In cases where the abuse-mailbox: contact attribute is invalid, the RIPE NCC will follow up with the resource holder and attempt to correct the issue" (thanks Andreas). We felt that this would give ample room for RIPE NCC to implement a gradual approach, in a flexible manner, where dialogue with the resource holders would be a priority. Deregistration of resources would only come in last resort, in cases where obvious uncooperative behaviour would have been clearly documented by RIPE NCC and not because the abuse email would not work (confirmed by Marco/NCC in his email dated 8 September). That's not what we would call a "highly aggressive approach", on the contrary. Sascha underlined that abuse-c was likely to point at a NOC or support desk and he felt that this proposal put too much pressure on that role. The point is that admin-c is the legal contact and that the actions or inactions of a support/abuse desk shouldn't be responsible for attention from the NCC leading to possible deregistration. We don't believe this is a valid argument, but we think the NCC may need to give some clarity that in case there were no response to a mail to abuse-c, contacting admin-c would be part of the process. Thanks again for all your feedback and for the discussion. We're looking forward to receiving more comments and questions and we will try to provide answers (quicker). Greg and Hervé Thursday, September 7, 2017, 1:59:07 PM, you wrote: MS> Dear colleagues, MS> A new RIPE Policy proposal, 2017-02, "Regular abuse-c Validation", is now available for discussion. MS> The goal of this proposal is to give the RIPE NCC a mandate to MS> regularly validate "abuse-c:" information and to follow up in cases where contact information is found to be invalid. MS> You can find the full proposal at: MS> https://www.ripe.net/participate/policies/proposals/2017-02 MS> As per the RIPE Policy Development Process (PDP), the purpose of MS> this four-week Discussion Phase is to discuss the proposal and provide feedback to the proposer. MS> At the end of the Discussion Phase, the proposer, with the agreement MS> of the RIPE Working Group Chairs, decides how to proceed with the proposal. MS> We encourage you to review this proposal and send your comments to MS> <anti-abuse-wg(a)ripe.net> before 6 October 2017. MS> Kind regards, MS> Marco Schmidt MS> Policy Development Officer MS> RIPE NCC MS> Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum ******************* DISCLAIMER : This message is sent in confidence and is only intended for the named recipient. If you receive this message by mistake, you may not use, copy, distribute or forward this message, or any part of its contents or rely upon the information contained in it. Please notify the sender immediately by e-mail and delete the relevant e-mails from any computer. This message does not constitute a commitment by Europol unless otherwise indicated. *******************

1 0

Fwd: [ripe-list] Network security and Brussels
by Brian Nisbet 14 Sep '17

14 Sep '17

As I know not everyone is on or reads the ripe-list, I felt it useful to forward this to the WG. Thanks, Brian -------- Forwarded Message -------- Subject: [ripe-list] Network security and Brussels Date: Thu, 14 Sep 2017 11:19:53 +0200 From: Gordon Lennox <gordon.lennox.13(a)gmail.com> To: ripe-list(a)ripe.net The Commission has just published a little bunch of things on security. As a very simple guide: a “Communication” is about what could happen, a “Report” is about what has happened and the “Regulation” is about changing ENISA. A lot of reading! Too much? But of interest to various WGs, including of course the Cooperation WG and the new IoT community? So: A COMMUNICATION from the Commission to the European Parliament and the Council. Making the most of NIS – towards the effective implementation of Directive (EU) 2016/1148 concerning measures for a high common level of security of network and information systems across the Union https://ec.europa.eu/transparency/regdoc/rep/1/2017/EN/COM-2017-476-F1-EN-M… https://ec.europa.eu/transparency/regdoc/rep/1/2017/EN/COM-2017-476-F1-EN-A… A REPORT from the Commission to the European Parliament and the Council assessing the extent to which member states have taken the necessary measures to comply with Directive 2013/40/EU on attacks against information systems and replacing Council Framework Decision 2005/222/JHA https://ec.europa.eu/transparency/regdoc/rep/1/2017/EN/COM-2017-474-F1-EN-M… A REPORT from the Commission to the European Parliament and the Council on the evaluation of the European Union Agency for Network and Information Security (ENISA) https://ec.europa.eu/transparency/regdoc/rep/1/2017/EN/COM-2017-478-F1-EN-M… A Proposal for a REGULATION of the European Parliament and of the Council on ENISA, the "EU Cybersecurity Agency", and repealing Regulation (EU) 526/2013, and on Information and Communication Technology cybersecurity certification (''Cybersecurity Act'') https://ec.europa.eu/transparency/regdoc/rep/1/2017/EN/COM-2017-477-F1-EN-M… Gordon

2 1

(no subject)
by Christian Carstensen 13 Sep '17

13 Sep '17

1 0

RIPE75 Anti-Abuse Working Group Agenda
by Brian Nisbet 12 Sep '17

12 Sep '17

Morning, Due to the notification requirements of RIPE75 this is the final agenda for the Anti-Abuse WG meeting on Wednesday 25th October. While there may be some adjustments to timings etc nothing much else will change. I look forward to seeing you all in Dubai! A. Administrative Matters * Welcome * Scribe, Jabber, Stenography * Microphone Etiquette * Approve Minutes from RIPE 74 * Finalise agenda B. Update * B1. Recent List Discussion - 10' * B2. C. Policies - * C1. 2017-02 (Regular abuse-c Validation) - Gregory Mounier - 20' D. Interactions - * D1. Working Groups - DB & Implementation of "abuse-c" * D2. E. Presentation - * E1. Netflow Based Botnet Detection, Alireza Vaziri - 25' * E1. Pre-Transfer Clean-Up of Abused Prefixes, Eric Bais - 25' X. A.O.B. Z. Agenda for RIPE 76 Thanks, Brian -- Brian Nisbet Network Operations Manager HEAnet CLG, Ireland's National Education and Research Network 1st Floor, 5 George's Dock, IFSC, Dublin D01 X8N7, Ireland +35316609040 brian.nisbet(a)heanet.ie www.heanet.ie Registered in Ireland, No. 275301. CRA No. 20036270

1 0

Re: [anti-abuse-wg] 2017-02 New Policy Proposal (Regular abuse-c Validation)
by phishing＠storey.xxx 12 Sep '17

12 Sep '17

1 0

Re: [anti-abuse-wg] [db-wg] RIPE Policy Proposal 2017-02 Validates Database Attributes
by Horváth Ágoston János 11 Sep '17

11 Sep '17

Hi all, Agreed that a yearly email ping-pong is not really a good verification of abuse contact address. It's trivial to let RIPE NCC mails through and throw away the rest. But, one might ask, what's the point of a database if the data is not reliable? What's the point of all that contact info if we can't trust it? Why would we want to store (and serve) data that is not correct? Data validation is standard industry practice, pretty much everywhere. You can't even buy a bar of chocolate without validating your email address. One might ask, why would RIPE NCC not follow even the most basic industry practices while validating data of this importance? Cheers, Agoston On Thu, Sep 7, 2017 at 6:54 PM, Sascha Luck [ml] via db-wg <db-wg(a)ripe.net> wrote: > > > ---------- Forwarded message ---------- > From: "Sascha Luck [ml]" <dbwg(a)c4inet.net> > To: db-wg(a)ripe.net > Cc: anti-abuse-wg(a)ripe.net > Bcc: > Date: Thu, 7 Sep 2017 17:54:04 +0100 > Subject: Re: [db-wg] RIPE Policy Proposal 2017-02 Validates Database Attributes > All, > > I will discuss this here as I do not accept the Anti-Abuse WG as > a forum for this proposal. For one thing, this proposal affects > every ripedb user - in fact, as this entails changes to how the > NCC provides services, the services-wg would be an even better > venue. For another, given the "population" and culture of > "debate" on the AAWG, any "consensus" reached there would be so > worthless as to be farcical. (If anyone wants amplification on > this, https://www.ripe.net/ripe/mail/archives/anti-abuse-wg/ > provides ample evidence. > > To the meat of the proposal: > > Firstly, this proposal conflicts somewhat with NWI-7 in this very > WG. (Another reason why it should have gone here in the first > place) With the upcoming possibility of delegating abuse-c: to > (customers') resource objects, who bears any consequences of > these customers not replying to this proposed email? >> >> Rationale >> a. Arguments supporting the proposal > > >> Accurate and validated information in the RIPE Database is >> essential to establish a trusted and transparent environment in >> which all network operators can operate safely. > > > abuse-c: is a contact object, just as admin-c: or tech-c: and > (correct me if I'm wrong) audited at the same time as the rest of > the contact information. What makes it so unique that this > verification is not enough? > >> Accurate and >> validated information helps Internet troubleshooting at all >> levels, but it also helps to attribute malicious online >> activities that undermine this trusted environment. > > > See above. > >> The lack of reliable accurate and validated information in the >> database negatively impacts legitimate uses of the RIPE Database, >> including: > > > An *email adress* that doesn't reply once a year does NOT equate > to a "lack of reliable accurate and validated information". I > find this statement somewhat insulting to the NCC team who do > make the effort to keep the ripedb data accurate and do audit > resource holders. > There is an issue with the reliability of out-of-region and > legacy resource data but as the NCC has no "enforcement" powers > over these resource holders, in these cases this proposal > snatches at thin air. >> >> Assuring the security and reliability of the network by >> identifying points of contact for IP addresses for network >> operators, ISPs, and certified computer incident response teams; > > > "org:", "admin-c:", "tech-c:", "mnt-by:" and, yes, "abuse-c:" exist. > >> Ensuring that IP address holders are accountable, so individuals, >> consumers and the public are empowered to resolve abusive >> practices that impact safety and security; >> Assisting businesses, consumer groups, healthcare organisations >> and other organisations that are combating fraud (some of which >> have mandates to electronically save records) to comply with >> relevant legal and public safety safeguards; > > > The contact object that does (or *should*) stand for the person(s) who > can speak for a LIR, legally, is "admin-c:". "abuse-c:" is some role > account in a NOC or even a ticket system unlikely to have any > decision-making power. An attempt to make these roles (perhaps > even personally) responsible for the behaviour of a LIR and its > customers is counter-productive. I for one would flatly refuse to > do any abuse report handling under these circumstances. > >> Complying with national, civil and criminal due process laws in >> support of investigations and providing justice for victims. > > > Would the proposers please amplify exactly which law or due > process is violated by the NCC not sending an email once a year > to an abuse-c:? Myself, and I'm sure the NCC legal team, would be > interested to know. > > On a technical note, email is neither a secure nor a reliable > transport for such verification. In the day of blocklists and > large email providers imposing arbitrary restrictions on email > senders it is not guaranteed that a verification email reaches > the intended address or that a reply reaches the sender. The NCC > ARC procedure, however employs both email and personal contact > via telephone to verify the accuracy of the ripedb information. > > In toto, this proposal would impose unneccessary work on LIRs and > the NCC, using unsuitable means to rectify a non-existing issue, and I therefore oppose it. > >

1 0