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

New on RIPE Labs: TLS Security and Data Centre Monitoring
by Mirjam Kuehne 22 Oct '17

22 Oct '17

Dear colleagues, Please read this guest post by Kathleen Moriarty, Security Area Director at the Internet Engineering Task Force (IETF): TLS Security and Data Centre Monitoring: Searching for a Path Forward Protocols are evolving to meet the demands of the future. As such, we must continue to strengthen the security of these protocols to keep pace with the threat landscape. https://labs.ripe.net/Members/mirjam/tls-security-and-data-centre-monitorin… Kind regards, Mirjam Kuhne RIPE NCC

1 0

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

11 Oct '17

Hi everyone, Thanks for your questions and comments. In light of those, Hervé and I will prepare a slightly amended version of the proposal to specify some languages, in particular when it comes to the role of RIPE NCC’s impact analysis in providing more details about the concrete implementation of this policy change proposal. Andre rightly asked what was the goal of the proposal. Ultimately, the goal of the proposal is to reduce the likelihood of getting no response when someone (anyone) need to urgently contact a LIR via the abuse-c contact. To achieve this goal we believe that RIPE NCC should be mandated to regularly validate the abuse-c contact point. We think that the main criteria to decide whether to move the proposal to the review phase or not, should be whether there is a majority of AAWG members who thinks that having a valid and functioning abuse-c contact points is a valid goal. Most questions raised were about the actual implementation of the proposal. As explained by Marco/RIPE NCC, the practical details of how the validation procedure will be implemented should not be laid down in the policy change proposal at this stage but rather by the impact analysis that RIPE NCC will conduct. RIPE NCC is the best placed to propose a working procedure (whether it should be done in the framework of ARC, what will be the criteria to consider a contact point invalid, how to address auto-answer, how often the validation process should be carried out etc.) because they are the ones who can best assess the financial and human resources to conduct these checks in the most efficient manner. Lastly, it seems that some members assume that this proposal is driven by law enforcement (LE) needs only. It is not. All network operators/LIRs have at some points been in the frustrating situation of not being able to find a valid contact point, this is why Hervé/Orange is co-authoring the proposal. There is not so many ways of ensuring that you get an answer: the community needs to agree that at least one contact point will be validated by RIPE NCC. In parallel, law enforcement is indeed working with NCC and some RIPE members to develop our knowledge and possibly a tool to visualize BGP routing tables. But improving the way LE can identify and investigate malicious IPs is not the goal of this policy change proposal. In conclusion, we think that so far, except for one or two members who explicitly opposed the goal of the proposal, a majority of members who expressed themselves on the AAWG mailing list during the discussion phase, agrees with the general objective of the proposal – that is to mandate RIPE NCC to regularly validate abuse-c contact in order to reduce the likelihood of not getting an answer when someone needs to urgently contact a LIR. Therefore, in agreement with the AAWG chair, we would like to move this proposal to the review phase. Thanks Greg and Hervé From: anti-abuse-wg [mailto:anti-abuse-wg-bounces@ripe.net] On Behalf Of herve.clement(a)orange.com Sent: 09 October 2017 15:01 To: Nick Hilliard; Michele Neylon - Blacknight Cc: ox; Gert Doering; anti-abuse-wg(a)ripe.net Subject: Re: [anti-abuse-wg] 2017-02 New Policy Proposal (Regular abuse-c Validation) Hello Nick, We have already talked with the RIPE NCC about ARC. If the ARC would include actual contact validation, a same LIR would be contacted less frequently for a global audit. Dealing specifically with abuse-c validation, RIPE NCC Impact Analysis will answer the question of extra work evaluation. Hervé -----Message d'origine----- De : anti-abuse-wg [mailto:anti-abuse-wg-bounces@ripe.net] De la part de Nick Hilliard Envoyé : lundi 9 octobre 2017 13:01 À : Michele Neylon - Blacknight Cc : ox; Gert Doering; anti-abuse-wg(a)ripe.net<mailto:anti-abuse-wg@ripe.net> Objet : Re: [anti-abuse-wg] 2017-02 New Policy Proposal (Regular abuse-c Validation) Michele Neylon - Blacknight wrote: > The current situation is that abuse-c can be populated with rubbish. > The email addresses can be completely non-functioning. > That is the real and current issue. the real issue is that this is a complex layer 9 problem inside each organisation, and although creating technological tickbox policies will provide a veneer of doing something, that veneer is very thin. The RIPE NCC already has a mechanism for information consistency audits, namely the Assisted Registry Check. Has anyone talked to the RIPE NCC about including abuse contacts in the ARC, and been given credible reasons as to why this wouldn't be a simpler, better and more effective way of dealing with issue of stale / inaccurate details? Nick _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. ******************* 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. *******************

4 5

Re: [anti-abuse-wg] 2017-02 New Policy Proposal (Regular abuse-c Validation)
by Gert Doering 09 Oct '17

09 Oct '17

Hi, On Fri, Oct 06, 2017 at 08:54:14AM +0200, ox wrote: > +++++ > requiring abuse email (RR data) to be valid and functional is a very > basic tenet (as it relates to morality and ethics as well as RR "goals") > +++++ True. This is the goal, and I share that. But I'm sceptic on whether the particular proposal on the table will do much to actually achieve this goal where change is needed - while at the same time imposing extra work on those that already do the right thing. > > We can force people to have abuse mailboxes that trigger a response if > > a mail from the RIPE NCC is received. > > > this is perfectly fine, imnsho, as it indicates receipt of > communications, even if it is autoresponded. > > it just cannot autorespond: that this is a non monitored mailbox - as > by definition, in this proposal, it has to be functional. > > functional implies that it can receive and respond to communications > and is not a "black hole" or dev/null So, what have we achieved if there is someone who will personally reply to verification mails from the RIPE NCC, and throw away everything else? Yes, Mails will no longer bounce. Good. But will it magically make those networks not interested in handling abuse mails more interested in them? No. So, where's the gain in the larger picture "fight against abuse"? [..] > > Thus, ambivalence on the policy. > > is this a good thing? please reconsider your ambivalence? all it takes > is for a few good people....(Edmond Burke...) I see no positive effect. So I find it hard to support it. The negative effects are limited. So I find it hard to oppose it. Ambivalence. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279

5 4

Re: [anti-abuse-wg] 2017-02 New Policy Proposal (Regular abuse-c Validation)
by Gert Doering 06 Oct '17

06 Oct '17

Hi, On Fri, Oct 06, 2017 at 08:13:32AM +0200, ox wrote: > clearly you are supportive of this as non support of this makes no > sense other than to derail ethical and moral behavior towards public > owned allocated resources. That's an invalid conclusion. Someone might share the same goal ("have a robust registry with valid contact information") but still disagree with the particular means - any policy change needs to be weighted (at least) against "does it achieve the set goal?" and "does the extra effort imposed relate positively to the effect". Which is why I'm not speaking up in favour or against this proposal either. I share the goals ("robust registry") but I have my doubts that this is going to achieve much - those that have good documentation today will have a bit more work, and those that do not care will continue to not care, finding ways to fulfill the policy, but still not caring. We can force people to have abuse mailboxes that trigger a response if a mail from the RIPE NCC is received. We (as in "the 10 people that speak up their mind here") can not force them to have working abuse handling, as in, infected customer systems gets fixed, IoT shit gets tracked down and disconnected, malicious customers get thrown out. Thus, ambivalence on the policy. Gert Doering -- long time handler of abuse@ -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279

3 2

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

Europol report on Cyber Crime threats IOCTA
by Richard Leaning 02 Oct '17

02 Oct '17

Dear Colleagues, I thought it might interest the working group to have sight of the latest cyber crime risk report for 2017 from Europol - EC3 - please see the link, its a very good read https://www.europol.europa.eu/activities-services/main-reports/internet-org… <https://www.europol.europa.eu/activities-services/main-reports/internet-org…> Please feel free to pass this on to anyone who you think will benefit from it, Cheers Dick Richard Leaning External Relations RIPE NCC

2 1

regarding proposal 2017-02
by Jasper.Rappard＠rabobank.nl 02 Oct '17

02 Oct '17

Dear WG, In response to the announcement made on Fri 29/09/2017 11:58 regarding NEW PROPOSAL: 2017-02, "Regular abuse-c Validation" I would like to bring forward for your consideration: The proposed new policy text '... 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.' implies that RIPE NCC will attempt to correct the issue. Consider "In cases where the "abuse-mailbox:" contact attribute is [add: marked as] invalid, the RIPE NCC will follow up with the resource holder and [remove: attempt] [add: require him] to correct the issue." Furthermore: Since you are stating in the rationale "If organisations are not cooperative, the RIPE NCC ultimately has the possibility to close their RIPE NCC membership and deregister their Internet number resources". This ultimate possibility is not described in the current policy (ripe-563) and maybe part of the overarching agreements. Do the overarching agreements contain notification standards and timelines? If not, do these need to be incorporated in the amended ripe-563? My 2 cents. Met vriendelijke groet, Kind regards, Jasper Rappard Performance Consultant Online businesscard https://visitekaartjes.rabobank.nl/Jasper.Rappard ====================================================== Rabobank disclaimer: http://www.rabobank.nl/disclaimer

2 1

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