September 2020 - anti-abuse-wg

[db-wg] Fw: NWI reviews: NWI-1 staying on top of abuse contact changes
by ripedenis＠yahoo.co.uk 24 Sep '20

24 Sep '20

Hi Lutz Good try but this script does not do it. Firstly, if you start with the allocation object it needs to be -rM in the first query. Then you are only looking for the "org:" attribute. The INET(6)NUM object may have an "abuse-c:" attribute in the object. It may have both in which case the local attribute overrides the "abuse-c:" in the referenced ORGANISATION object. Also to manage this feature it is not just about producing a list of abuse email addresses. It is knowing where these are referenced within a hierarchy and knowing which parts of the hierarchy are covered by which addresses. I agree that most resources will only have a single abuse contact referenced from their single ORGANISATION object. However, we were pushed hard by the community to allow "abuse-c:" to be added to the INET(6)NUM objects. I assume therefore that this feature has been used. So we already have a mix of abuse contacts referenced from both ORGANISATION and resource objects. When this was asked for the emphasis was on 'ease of use' to add these contacts. Probably no one gave much thought to how these contacts will be cleaned up when no longer relevant. It's most likely that someone will ask someone to remove it. Knowing human nature it is more likely some will just be forgotten about. If the contact is still there it is still active, but maybe no one is reading that email address any longer. I am not an operator so I don't know how many end user customers in large networks handle their own abuse reports. Or how many sub allocations handle abuse with their own customers handling abuse. So I don't know how complex this will get and maybe all operators already have good procedures in place to manage all this. That is why I am asking the question...is such a visualisation tool needed, useful or a waste of time? As an analyst, I can only see how complex this 'could' become over time. Unless we go back to the drawing board and redesign the abuse contact system (again) this is not going to be simplified any time soon. cheersdenis co-chair DB-WG On Thursday, 24 September 2020, 15:32:09 CEST, Lutz Donnerhacke via db-wg <db-wg(a)ripe.net> wrote: > > We need to take some action on these old NWIs. Either we move forward > with them or we cancel them. It is difficult to draw a consensus on 2 > comments. Can you please give us a couple of minutes of your time and > let us know if this NWI-1 is needed, useful or a waste of time. > > I share the view already expressed. If we need a tool, maybe the problem > is somewhere else. I support any proposal, that comes to the same result as the ripe whois database tool. It's not really hard to do correctly. #! /bin/sh getripe="whois -h whois.ripe.net --" $getripe -rL -T inetnum,inet6num "$1" | egrep '^org:' | while read ot ov; do $getripe -r -T organisation $ov | egrep '^abuse-c:' | while read at av; do $getripe -r $av | fgrep abuse-mailbox done done | tail -1 In order to fix the issue on the database side, it's necessary to prevent any occurrence of "abuse-mailbox" in all objects beside an newly created "abuse-contact" type, which is only allowed to referenced in the "abuse-c". See here for a corner case: https://lutz.donnerhacke.de/eng/Blog/Antispammers-and-Abuse-C

2 1

NWI reviews: NWI-1 staying on top of abuse contact changes
by ripedenis＠yahoo.co.uk 24 Sep '20

24 Sep '20

Colleagues This is now a very old NWI that never got out of the starting blocks. I am posting this to the AA-WG as I think the discussion is more relevant to this community given the impact of not properly managing this data. https://www.ripe.net/ripe/mail/archives/db-wg/2016-May/005234.html Since I raised this point the world has moved on and the situation is now even more complex. The "abuse-c:" attribute can be added to:-the resource holders primary ORGANISATION object-any secondary ORGANISATION object referenced from any point in the address hierarchy-any resource object at any point in the address hierarchy-all, or any combination, of the above These (multiple) "abuse-c:" attributes can reference the same or multiple ROLE objects. These (multiple) ROLE objects can include "abuse-mailbox:" attributes referencing the same or multiple email addresses. Over time, with large hierarchies, we could end up with very complex arrangements with objects, attributes and values that have been overlooked and forgotten about. Even though they may have been forgotten about they are still 'active' and queries will return the most appropriate abuse contact details, even if it is the wrong contact. There is no simple query that will return the details of such a complex structure of abuse contact data in the RIPE Database. So there is no easy way for a resource holder to review or manage these abuse contacts. Although most resources will only ever have one abuse contact for the whole hierarchy, over several years we could end up with the kind of data swamp we had before we introduced the "abuse-c:" attribute for the larger networks. Any user could write their own script to do more specific queries, parse the returned objects and work out the abuse contact data structure for their resource. It would require detailed knowledge of the RIPE Database structure, the abuse contact rules and would involve multiple queries just to get the data, which you then have to visualise. My reason for this NWI-1 was to suggest the RIPE NCC creates a tool or RIPEstat widget that would take in a resource and map out the abuse contact details for the whole hierarchy including that resource. Would this be useful, is it necessary or a waste of time? Please discuss.... cheersdenis co-chair DB-WG

4 6

Re: [anti-abuse-wg] NWI reviews: NWI-1 staying on top of abuse contact changes
by Stephane.Dodeller＠swisscom.com 23 Sep '20

23 Sep '20

Hello Leo, Hello all, > I have no objection to creating useful tools for people to use when > managing their resources. That said, whenever the data structure is so > complex that a special tool is needed to help people understand it, I > wonder if the real problem is the data structure. +1 Such a tool would certainly bring something, but may not be needed if we could simplify the structure in the first place. Best regards Stéphane Dodeller

2 1

Invitation to IGF survey and workshop on Internet standards deployment
by Wout de Natris 21 Sep '20

21 Sep '20

Dear colleagues, Last year you were invited to a survey concerning the slow deployment of Internet standards. This led to a report published in March of this year. Below you find the next step towards deployment, to work on recommendations and actions. The deployment of Internet security-related standards and ICT best practices is a topic that continues to be the subject of important discussion worldwide with the aim of achieving a more secure and safer online environment that is necessary to support the rapid adoption of new digital technologies. This has been made even more urgent by the COVID-19 pandemic. I am sure you would agree that it is time to move on from what has been largely an uncoordinated and technical debate spread across various fora, and initiate global stakeholder cooperation that will have a positive impact on economic and social well-being through helping digital technologies to transform everybody’s daily lives. As you may know, the UN Internet Governance Forum is establishing a new Dynamic Coalition on Internet Standards, Security and Safety (DC-ISSS) with the aim of achieving this objective and I am now writing as the leader of this initiative to invite you as a leading expert to join this important multi-stakeholder coalition. The intended outcomes of the DC-ISSS will be recommendations for actions by key policymakers and decision-takers that will enable security-related Internet standards and best practices to be deployed more rapidly and with greater determination and commitment. By involving stakeholders like yourself we believe that we can at last make a difference in making deployment more effective and widespread. It has to stop to be a, primarily, technical debate, to be changed into a digital healthcare topic. As a first step, the coalition needs to prioritise its work and finalise its work plan. A preparatory session for this purpose will be held during the upcoming IGF 2020 on Wednesday 4 November at 09.40 – 11.10 CET. A short questionnaire has been drawn up to help with this process. It would be appreciated very much if in addition to considering the invitation to join the coalition, you could complete this questionnaire which can be accessed at: https://survey.sogosurvey.com/Survey1.aspx?k=SsQYPPXWsRsPsPsP&lang=0. Our deadline for responses in 7 October. It does not take up more of your time than five minutes at a maximum. The formal launch of the DC-ISSS will be held in a separate session on Friday 6 November from 10.10 - 11.40 CET when the establishment of thematic working groups will be announced and the work programme presented. This will be followed by an online discussion with stakeholders. You are cordially invited to this as well of course. Further information about the DC-ISSS can be found on the IGF website at: <https://www.intgovforum.org/multilingual/content/dynamic-coalition-on-inter…> https://www.intgovforum.org/multilingual/content/dynamic-coalition-on-inter… Here is the link to join the DC-ISSS email list in order to receive updates and be informed of progress: https://www.intgovforum.org/multilingual/content/dc-jobs-mailing-list Please also bear in mind that in order to participate in the work of the DC-ISSS you need to register for IGF 2020. This can be done by accessing the registration page at: https://www.intgovforum.org/multilingual/content/igf-2020-registration If you have any questions about the aims of the DC-ISSS, its objectives and the process for planning its work, please do not hesitate to get in touch - and of course I and the support team comprising Mark Carvell and Marten Porte would welcome any thoughts and suggestions you may have for making this important Dynamic Coalition a success in achieving its objectives in creating greater security and safety online for all users worldwide. Best regards, Wout de Natris - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - De Natris Consult Kamerlingh Onnesstraat 43 Tel: +31 648388813 2014 EK Haarlem Skype: wout.de.natris denatrisconsult(a)hotmail.nl<mailto:denatrisconsult@hotmail.nl> http://www.denatrisconsult.nl Blog http://woutdenatris.wordpress.com

1 0

2019-04 Policy Proposal Withdrawn (Validation of "abuse-mailbox")
by Petrit Hasani 09 Sep '20

09 Sep '20

Dear colleagues, The policy proposal 2019-04, "Validation of "abuse-mailbox”” has been withdrawn. The proposal aimed to have the RIPE NCC validate "abuse-c:” information more often and introduce a new validation process. The proposal is archived and can be found at: https://www.ripe.net/participate/policies/archived-policy-proposals/archive… Reason for withdrawal: The proposal did not reach consensus and the WG chairs did not feel that any further redrafting of the proposal would achieve consensus. Kind regards, -- Petrit Hasani Policy Officer RIPE NCC

5 5

Report & Co-Chair's Decision on Proposal 2019-04
by Brian Nisbet 09 Sep '20

09 Sep '20

Colleagues, A few weeks ago we reached the end of the latest review phase for 2019-04. The Co-Chairs have worked closely with the NCC Policy Development Office since then to try to make a decision on this policy. This email contains a report on the Discussion Phase and Review Phase and then a final decision which, we believe, is supported by the activity during those phases. As always, this is underpinned by the RIPE PDP - https://www.ripe.net/publications/docs/ripe-710 Discussion Phase: There was some clear support for the policy during the Discussion Phase. This came from: Serge Droz, who felt that it would help in a number of cases and that an inability to answer an e-mail every six month probably indicated underlying issues. He also felt it would allow the community to understand who was doing good work and who wasn't, and it will prevent organisations from saying they never received a report. He also pointed out some of the difference in reaction between the security and operator communities on this policy. Carlos Friacas, agreed that it would help, but not solve all problems. He also flagged that if "deregistration" was not a possible outcome for a continuous failure to validate, then the outcome of transparency would still be positive, but did say that must be balanced against the NCC Impact Analysis. Jordi Palet Martinez, the proposer, was, of course, in favour, but also reacted to a number of voices against the proposal: - The job of the RIPE NCC is to implement the policies agreed by the community. I believe is perfectly understandable the need to avoid using manual forms which don't follow a single standard, which means extra work for *everyone*. (Responding to Nick Hilliard) - The actual policy has a bigger level of micro-management, by setting one year and not allowing the NCC to change that. (Responding to Nick Hilliard) - The problem of a form is that is not standard. This is economically non-sustainable and means that the cost of the abuse cases is on the back of the one actually reporting. (Responding to No No) - The actual validation is not working, it is just a technical validation (responding to Gert Doering) - The community prefers to do things in steps, we initially asked for an abuse mailbox, we then added a technical validation, now we are asking for a better validation. I am not asking to verify if you handle abuse case or not and I am not asking to take any new actions. Angel Gonzalez Berdasco suuported the proposal, but also made multiple comments on a different approach, including an abuse-uri and highlighted that standarising the communications was important. A number of people spoke in clear opposition. Nick Hilliard stated that it is not the job of the RIPE NCC to tell its members how to handle abuse reports. He further said that the is self-contradictory, intrusive into NCC membership business processes and there is no compelling reason to believe that the proposal will end up reducing the amount of abuse on the internet. Gert Doering said that if people *do not want* to handle abuse reports, this proposal will not make them and that cases of misconfiguration are already caught today. No No did not want anyone to be restricted in how they received abuse reports. Michele Neylon opposed the proposal and agreed with the points made by Nick. A number of other people posted either with mixed comments, or in a way that did not make it clear where they stood on the proposal: Job Snijders, Elad Cohen, Alistair Mackenzie, Suresh Ramasubramanian, Hans-Martin Mosner, Shane Kerr, Sascha Luck, Arash Naderpur, Richard Clayton, Alessandro Vesely, Randy Bush The Review Phase of the proposal lasted from 20 July 2020 to 18 August 2020. There were 14 messages received during the review phase. Out of which, 3 were from the PDO, 1 was myself's and 2 were Jordi’s requesting clarification on the Impact Analysis. - There was no messages of support to the proposal. There was one message stating that the form is more beneficial than email to report abuse because it always reaches the host to which Jordi tried to address stating that email can be automated whilst forms can not. - There were opposing arguments based on two fronts: 1) Nick Hilliard and Erik Bais commented that the effort and cost to implement this proposal are too great in relations to the benefits that are alleged. 2) Michele Neylon and Arash Naderpour commented that they oppose forcing operators to use only email for handling abuse reports and internal handling procedures should be solely defined by the operator. Nick Hilliard and Michele Neylon also requested the proposal to be dropped as concerns raised over the last 18 months have not been addressed and tweaking this proposal would not add any value. There was no attempt to address the opposing arguments above during the review phase. With all of this in mind, and with the continued failure of any kind of consensus from the working group, the Co-Chairs have decided to withdraw this proposal. As always we would welcome proposals on this and other matters, however we do not feel that there is any likelihood of 2019-04, regardless of possible edits, reaching consensus in the short or medium term. Alireza, Brian, Tobias Co-Chairs, RIPE AA-WG Brian Nisbet Service 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

12 20

Re: [anti-abuse-wg] Report & Co-Chair's Decision on Proposal 2019-04
by JORDI PALET MARTINEZ 08 Sep '20

08 Sep '20

Hi Brian, all, First of all, tks for this detailed report. I’m still processing it. However, I’ve a open question for you, which I think it has been also clear from other emails, that it is not clear for the community. People in favor (or against) the proposal has not (including myself), re-stated their position or repeated the same arguments. Is not that an indication that they keep their previous position? Regards, Jordi @jordipalet El 7/9/20 17:19, "anti-abuse-wg en nombre de Brian Nisbet" <anti-abuse-wg-bounces(a)ripe.net en nombre de brian.nisbet(a)heanet.ie> escribió: Colleagues, A few weeks ago we reached the end of the latest review phase for 2019-04. The Co-Chairs have worked closely with the NCC Policy Development Office since then to try to make a decision on this policy. This email contains a report on the Discussion Phase and Review Phase and then a final decision which, we believe, is supported by the activity during those phases. As always, this is underpinned by the RIPE PDP - https://www.ripe.net/publications/docs/ripe-710 Discussion Phase: There was some clear support for the policy during the Discussion Phase. This came from: Serge Droz, who felt that it would help in a number of cases and that an inability to answer an e-mail every six month probably indicated underlying issues. He also felt it would allow the community to understand who was doing good work and who wasn't, and it will prevent organisations from saying they never received a report. He also pointed out some of the difference in reaction between the security and operator communities on this policy. Carlos Friacas, agreed that it would help, but not solve all problems. He also flagged that if "deregistration" was not a possible outcome for a continuous failure to validate, then the outcome of transparency would still be positive, but did say that must be balanced against the NCC Impact Analysis. Jordi Palet Martinez, the proposer, was, of course, in favour, but also reacted to a number of voices against the proposal: - The job of the RIPE NCC is to implement the policies agreed by the community. I believe is perfectly understandable the need to avoid using manual forms which don't follow a single standard, which means extra work for *everyone*. (Responding to Nick Hilliard) - The actual policy has a bigger level of micro-management, by setting one year and not allowing the NCC to change that. (Responding to Nick Hilliard) - The problem of a form is that is not standard. This is economically non-sustainable and means that the cost of the abuse cases is on the back of the one actually reporting. (Responding to No No) - The actual validation is not working, it is just a technical validation (responding to Gert Doering) - The community prefers to do things in steps, we initially asked for an abuse mailbox, we then added a technical validation, now we are asking for a better validation. I am not asking to verify if you handle abuse case or not and I am not asking to take any new actions. Angel Gonzalez Berdasco suuported the proposal, but also made multiple comments on a different approach, including an abuse-uri and highlighted that standarising the communications was important. A number of people spoke in clear opposition. Nick Hilliard stated that it is not the job of the RIPE NCC to tell its members how to handle abuse reports. He further said that the is self-contradictory, intrusive into NCC membership business processes and there is no compelling reason to believe that the proposal will end up reducing the amount of abuse on the internet. Gert Doering said that if people *do not want* to handle abuse reports, this proposal will not make them and that cases of misconfiguration are already caught today. No No did not want anyone to be restricted in how they received abuse reports. Michele Neylon opposed the proposal and agreed with the points made by Nick. A number of other people posted either with mixed comments, or in a way that did not make it clear where they stood on the proposal: Job Snijders, Elad Cohen, Alistair Mackenzie, Suresh Ramasubramanian, Hans-Martin Mosner, Shane Kerr, Sascha Luck, Arash Naderpur, Richard Clayton, Alessandro Vesely, Randy Bush The Review Phase of the proposal lasted from 20 July 2020 to 18 August 2020. There were 14 messages received during the review phase. Out of which, 3 were from the PDO, 1 was myself's and 2 were Jordi’s requesting clarification on the Impact Analysis. - There was no messages of support to the proposal. There was one message stating that the form is more beneficial than email to report abuse because it always reaches the host to which Jordi tried to address stating that email can be automated whilst forms can not. - There were opposing arguments based on two fronts: 1) Nick Hilliard and Erik Bais commented that the effort and cost to implement this proposal are too great in relations to the benefits that are alleged. 2) Michele Neylon and Arash Naderpour commented that they oppose forcing operators to use only email for handling abuse reports and internal handling procedures should be solely defined by the operator. Nick Hilliard and Michele Neylon also requested the proposal to be dropped as concerns raised over the last 18 months have not been addressed and tweaking this proposal would not add any value. There was no attempt to address the opposing arguments above during the review phase. With all of this in mind, and with the continued failure of any kind of consensus from the working group, the Co-Chairs have decided to withdraw this proposal. As always we would welcome proposals on this and other matters, however we do not feel that there is any likelihood of 2019-04, regardless of possible edits, reaching consensus in the short or medium term. Alireza, Brian, Tobias Co-Chairs, RIPE AA-WG Brian Nisbet Service 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 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.

4 5

2nd Call For Agenda Items - AA-WG @ RIPE81
by Brian Nisbet 07 Sep '20

07 Sep '20

Colleagues, RIPE 81 will be taking place somewhere on the Internet from the 27th - 30th October 2020. https://ripe81.ripe.net<https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fripe81.ri…> The Anti-Abuse WG will be meeting and Alireza, Tobias and I would invite people to submit topics for discussion, presentations for general enlightenment and, of course, work items for the working group. The session will is currently scheduled for 45 minutes, as it was at RIPE80. As always you can reach us at aa-wg-chair(a)ripe.net Thanks, Brian Co-Chair, RIPE AA-WG Brian Nisbet Service 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