Re: [anti-abuse-wg] [policy-announce] 2017-02 Review Phase (Regular abuse-c Validation)
Do you want to solve a problem or create one? I can imagine as the "click here and solve captcha" emails will be standardized that a carefully crafted attack might lure fist line helpdesk people onto shady websides and making them click stuff. So if I were a helpdesk manager I would order my team not to click on these.... IMHO the policy should only check if emails to the abuse contact are delivered, which can bei done with some HELO, MAIL FROM and RCPT TO magic on port 25. best regards Wolfgang
On 19. Jan 2018, at 10:58, ox <andre@ox.co.za> wrote:
you mean in practical "real life" work?
practically, abuse admins and people that actually deal with abuse are able to solve a capcha and tick a box.
-- Wolfgang Tremmel Phone +49 69 1730902 26 | Fax +49 69 4056 2716 | Mobile +49 171 8600 816 | wolfgang.tremmel@de-cix.net Geschaeftsfuehrer Harald A. Summa | Registergericht AG Köln HRB 51135 DE-CIX Management GmbH | Lindleystrasse 12 | 60314 Frankfurt am Main | Germany | www.de-cix.net
I have to agree with Wolfgang here ... If any of our helpdesk engineers would click on a link or attachment in what we receive on the abuse-mailbox ... he/she would have to keep restoring the systems due to the massive number of malware that is received in it.. I still think that the best way to validate a current abuse-contact is during the ARC's ... It wouldn't require any additional process nor additional contact moments from the RIPE NCC's point of view to the resource holders. Regards, Erik Bais
Well, let's be smart: You can only click in those that belong to RIPE. Look at the other way around: When I submit abuse reports (which means an extra cost for me, even if the one that causes the problem is giving the business to you), sometimes I get an automated response email that ask me for clicking a link, or filling a report, and then getting a confirmation email and clicking a link again, or a combination of some of those ... So, should I also avoid clicking the links and go to the courts to ask for the damages that your customer is creating to me? Let's be fair, the cost and possible damages, of customers that abuse third party networks using your infrastructure, need to be covered by them (or you as the provider) not by the folks being attacked. Or you will tell me that a court will tell me that the thief damaged my door because I keep it close, and I must pay for repairing the door, instead of the thief and those that cooperated with him in the attack? Regards, Jordi -----Mensaje original----- De: anti-abuse-wg <anti-abuse-wg-bounces@ripe.net> en nombre de Erik Bais <ebais@a2b-internet.com> Fecha: viernes, 19 de enero de 2018, 15:19 Para: "anti-abuse-wg@ripe.net" <anti-abuse-wg@ripe.net> Asunto: Re: [anti-abuse-wg] [policy-announce] 2017-02 Review Phase (Regular abuse-c Validation) I have to agree with Wolfgang here ... If any of our helpdesk engineers would click on a link or attachment in what we receive on the abuse-mailbox ... he/she would have to keep restoring the systems due to the massive number of malware that is received in it.. I still think that the best way to validate a current abuse-contact is during the ARC's ... It wouldn't require any additional process nor additional contact moments from the RIPE NCC's point of view to the resource holders. Regards, Erik Bais ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es 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.
Eric, Given the NCC have repeatedly said that the ARC is not a suitable way to validate the abuse contact and have proposed an alternative method, supported by the ARC process, do you have any comment on the actually proposed process? Thanks, Brian Co-Chair, RIPE AA-WG On 19/01/2018 14:19, Erik Bais wrote:
I have to agree with Wolfgang here ...
If any of our helpdesk engineers would click on a link or attachment in what we receive on the abuse-mailbox ... he/she would have to keep restoring the systems due to the massive number of malware that is received in it..
I still think that the best way to validate a current abuse-contact is during the ARC's ... It wouldn't require any additional process nor additional contact moments from the RIPE NCC's point of view to the resource holders.
Regards, Erik Bais
Brian Nisbet wrote:
Given the NCC have repeatedly said that the ARC is not a suitable way to validate the abuse contact and have proposed an alternative method, supported by the ARC process, do you have any comment on the actually proposed process?
Honestly, it's hard to tell. After looking at the text from the "Validation method" section of the proposal, it looks like the RIPE NCC may be suggesting doing something like issuing an SMTP RCPT command to see if the mail server rejects the email address. If this is the case, it is likely to provide plenty of false positives albeit no false negatives. I.e. if it fails this test, then the email address is categorically not working, but if it passes this test, then there is no guarantee that the email address is working, for a very limited definition of the word. Because of a lack of details, is not possible to tell if this is the actual method being suggested, but it is not incompatible with what is being proposed in the PP document. What's absent from this process is any mechanism to link the email address to the sorts of metrics and expected results described in presentations given by the authors, e.g. the presentation given in the RIPE75 AAWG session. What's also absent is a clear statement that the email address which has been "validated" isn't necessarily connected to anyone in the organisation handling abuse or that it may not actual function at all in any meaningful way. This isn't intended to rubbish what the RIPE NCC are proposing: they've been asked to do something which is fundamentally almost impossible to do in a meaningful way, and have suggested that by redefining the problem into something which can largely automated, that a practically impossible task can be turned into something feasible. The problem is that there is now a substantial mismatch between the stated aims of the policy proposal and the proposed validation method. I'm going to object to this version of the policy proposal too. Partly on these grounds, and partly due to the observation that few, if any, of the substantial objections made by numerous people to version 1.0 have been resolved either. If the latter needs fleshing out for the purposes of ensuring that these remain registered as formal unresolved objections, it would be helpful to know, because a bunch of these problems really haven't been addressed at all. Nick
On Fri, 19 Jan 2018 17:26:47 +0000 Nick Hilliard <nick@foobar.org> wrote:
Brian Nisbet wrote:
Given the NCC have repeatedly said that the ARC is not a suitable way to validate the abuse contact and have proposed an alternative method, supported by the ARC process, do you have any comment on the actually proposed process?
Honestly, it's hard to tell.
<snip>
What's absent from this process is any mechanism to link the email address to the sorts of metrics and expected results described in presentations given by the authors, e.g. the presentation given in the RIPE75 AAWG session.
What's also absent is a clear statement that the email address which has been "validated" isn't necessarily connected to anyone in the organisation handling abuse or that it may not actual function at all in any meaningful way.
RIPE sends a six digit alpha numeric that is entered on the RIPE website solves both the above points.
This isn't intended to rubbish what the RIPE NCC are proposing: they've been asked to do something which is fundamentally almost impossible to do in a meaningful way, and have suggested that by redefining the problem into something which can largely automated, that a practically impossible task can be turned into something feasible.
"fundamentally almost impossible" seriously? how does fundamentally and "almost" even sit next to each other and then followed by meaningful ??? I do not agree with anything you have said, because I do not find any foundation to any of it.
The problem is that there is now a substantial mismatch between the stated aims of the policy proposal and the proposed validation method.
I'm going to object to this version of the policy proposal too. Partly on these grounds, and partly due to the observation that few, if any, of the substantial objections made by numerous people to version 1.0 have been resolved either.
If the latter needs fleshing out for the purposes of ensuring that these remain registered as formal unresolved objections, it would be helpful to know, because a bunch of these problems really haven't been addressed at all.
Nick
Nick, On 19/01/2018 17:26, Nick Hilliard wrote:
Brian Nisbet wrote:
Given the NCC have repeatedly said that the ARC is not a suitable way to validate the abuse contact and have proposed an alternative method, supported by the ARC process, do you have any comment on the actually proposed process?
Honestly, it's hard to tell.
After looking at the text from the "Validation method" section of the proposal, it looks like the RIPE NCC may be suggesting doing something like issuing an SMTP RCPT command to see if the mail server rejects the email address. If this is the case, it is likely to provide plenty of false positives albeit no false negatives. I.e. if it fails this test, then the email address is categorically not working, but if it passes this test, then there is no guarantee that the email address is working, for a very limited definition of the word. Because of a lack of details, is not possible to tell if this is the actual method being suggested, but it is not incompatible with what is being proposed in the PP document.
I would suggest that seeking clarification from the NCC about the impact analysis and proposed solution is a perfectly fine thing to do, especially if people are uncertain, so hopefully they can clarify further here.
What's absent from this process is any mechanism to link the email address to the sorts of metrics and expected results described in presentations given by the authors, e.g. the presentation given in the RIPE75 AAWG session.
I will leave that to the authors.
What's also absent is a clear statement that the email address which has been "validated" isn't necessarily connected to anyone in the organisation handling abuse or that it may not actual function at all in any meaningful way.
Well, this is where we keep on coming back to in this conversation. There are clearly those who wish for the validation to go much further and others who do not wish it to happen at all. Threading that line is proving tricky. I, personally, do not see how the ARC could scale for this process.
This isn't intended to rubbish what the RIPE NCC are proposing: they've been asked to do something which is fundamentally almost impossible to do in a meaningful way, and have suggested that by redefining the problem into something which can largely automated, that a practically impossible task can be turned into something feasible.
The problem is that there is now a substantial mismatch between the stated aims of the policy proposal and the proposed validation method.
The stated aim of the proposal is: "This proposal aims to give the RIPE NCC a mandate to validate “abuse-c:” information, at least once a year, and to follow up in cases where contact information is found to be invalid." I take it in this instance you do not feel that the process as described counts as validation? Or is it rather sufficient validation?
I'm going to object to this version of the policy proposal too. Partly on these grounds, and partly due to the observation that few, if any, of the substantial objections made by numerous people to version 1.0 have been resolved either.
If the latter needs fleshing out for the purposes of ensuring that these remain registered as formal unresolved objections, it would be helpful to know, because a bunch of these problems really haven't been addressed at all.
I'm not going to object to you rounding this information up, at all, but I will obviously also be going through the discussion and it would be useful to hear from others who objected as to their opinion of the new version. Thanks, Brian Co-Chair, RIPE AA-WG
Brian Nisbet wrote:
Well, this is where we keep on coming back to in this conversation. There are clearly those who wish for the validation to go much further and others who do not wish it to happen at all. Threading that line is proving tricky. I, personally, do not see how the ARC could scale for this process.
This goes back to fundamentals. What's happening here is that a set of metrics was talked about at previous RIPE meetings, namely a requirement for organisations wanting to be able to contact the actual holders of address space. This morphed into a more vague aspiration, described in the text as "improving the trust and safety of the IP address space". It was made clear that although this aspiration was binding on RIPE NCC resource holders, that the same standards wouldn't apply to ERX holders because: "Legacy resource holders they would of course not be directly impacted but our assumption is if you are a legacy resource holder you are also committed like any other members of the community to the same objective of safety accountability and trust in the IP space, therefore you would establish your IP ‑‑ abuse contact and you would monitor it. That is the only answer we could come back with." (From https://ripe75.ripe.net/archives/steno/37/) The RIPE NCC have proposed a solution which apparently performs basic validation of whether the email address looks valid and (I assume) whether the SMTP MX host immediately rejects it. If for some reason this test fails, then the RIPE NCC is being explicitly instructed by the community that it's ok to deregister resources. It would be fair to say that loss of ip addressing resources would for most companies create an immediate and fundamental threat to their continued ability to operate. There are several fundamental problems with this proposal: 1. poorly specified metrics 2. mismatch between the assumed background aims and the validation proposals 3. lack of proportionality I talked about the first two issues in my email of last week, but the proportionality issue is what really bothers me. Any reasonable policy should be defined on the basis that the punishment should match the crime, but this is jarringly not the case here. Instead what we have is: - the policy is based on a hazily defined objective. - the rationale for excluding ERX holders applies just as much, if not more, to RIPE resource holders. In other words, the authors of the policy have explicitly shot their own arguments in the foot. - the validation mechanism performs only a basic syntactic validation of the email address rather than a semantic validation of whether it ends up on the desk of an organisational contact who can act as an actual abuse management contact. - despite all of this, in the case of validation failure, the RIPE NCC is being explicitly told that it is being given the mandate to pursue a course of action which could result in an organisation ceasing to operate. This is not, as has been suggested at the last AAWG meeting in Dubai, a case of whether the RIPE community is able to determine RIPE community policy. The core issues here are proportionality and over-reach. I have no problem with abuse-c validation, either via ARC, or the mechanism proposed in this policy, and probably not via a range of other mechanisms either. But threatening to terminate the right of an organisation to continue to exist in the case of non compliance of the terms specified in 2017-02 is frankly absurd. Nick
Hi, On Mon, Jan 22, 2018 at 11:25:12AM +0000, Nick Hilliard wrote:
I have no problem with abuse-c validation, either via ARC, or the mechanism proposed in this policy, and probably not via a range of other mechanisms either. But threatening to terminate the right of an organisation to continue to exist in the case of non compliance of the terms specified in 2017-02 is frankly absurd.
I second this concern. I do see the need for a working abuse contact, and I do see the need of sanctions in case a policy is violated, but "deregister all resources, because your mail server was broken when we tested" is too extreme (exaggeration for emphasis). 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
Folks, On 22/01/2018 13:19, Gert Doering wrote:
Hi,
On Mon, Jan 22, 2018 at 11:25:12AM +0000, Nick Hilliard wrote:
I have no problem with abuse-c validation, either via ARC, or the mechanism proposed in this policy, and probably not via a range of other mechanisms either. But threatening to terminate the right of an organisation to continue to exist in the case of non compliance of the terms specified in 2017-02 is frankly absurd.
I second this concern.
I do see the need for a working abuse contact, and I do see the need of sanctions in case a policy is violated, but "deregister all resources, because your mail server was broken when we tested" is too extreme (exaggeration for emphasis).
There's a lot more to discuss in Nick's email, but I want to talk about this point immediately. I believe the NCC have stated very clearly how incredibly unlikely deregistration of resources would be and I honestly don't believe the exaggeration for emphasis or otherwise is useful. Yes, it could happen, after many, many attempts to get in contact with the resource holder and lots of steps. However this is not a set of actions restricted to 2017-02. This is part of the membership contracts and the interaction between this and RIPE policies. There was a lot of discussion at the GM in October on this topic. If a member doesn't abide by RIPE policies then there is a danger that their resources could be deregistered. That's part of membership. As per the NCC's impact analysis this is something they deal with regularly: "The RIPE NCC has significant experience with resolving these kinds of situations. Over the past five years, it has investigated and resolved more than 1,000 external reports on incorrect “abuse-mailbox:” attributes, without ever needing to trigger the closure and deregistration procedure. Making unresponsive resource holders aware of this procedure has helped to ensure their cooperation." and "If the closure and deregistration procedure is triggered, the resource holder still has a further three months to resolve the problem before the actual LIR closure and/or resource deregistration takes place." So please, can we moderate the fears and properly estimate the risks around de-registration in the case of an invalid abuse-mailbox attribute. Thanks, Brian Co-Chair, RIPE AA-WG
Hi, sorry, Brian, i posted before receiving your email :) just to get back on topic then: I have not seen any objections to the process of emailing a alpha numeric number to abuse-c and then having that number entered into a website (after solving a capcha) This would solve many problems as it would mean that the abuse-c exists and is functional and not an auto-responder or other bot Kind Regards Andre On Mon, 22 Jan 2018 13:31:00 +0000 Brian Nisbet <brian.nisbet@heanet.ie> wrote:
Folks,
On 22/01/2018 13:19, Gert Doering wrote:
Hi,
On Mon, Jan 22, 2018 at 11:25:12AM +0000, Nick Hilliard wrote:
I have no problem with abuse-c validation, either via ARC, or the mechanism proposed in this policy, and probably not via a range of other mechanisms either. But threatening to terminate the right of an organisation to continue to exist in the case of non compliance of the terms specified in 2017-02 is frankly absurd.
I second this concern.
I do see the need for a working abuse contact, and I do see the need of sanctions in case a policy is violated, but "deregister all resources, because your mail server was broken when we tested" is too extreme (exaggeration for emphasis).
There's a lot more to discuss in Nick's email, but I want to talk about this point immediately.
I believe the NCC have stated very clearly how incredibly unlikely deregistration of resources would be and I honestly don't believe the exaggeration for emphasis or otherwise is useful.
Yes, it could happen, after many, many attempts to get in contact with the resource holder and lots of steps.
However this is not a set of actions restricted to 2017-02. This is part of the membership contracts and the interaction between this and RIPE policies. There was a lot of discussion at the GM in October on this topic.
If a member doesn't abide by RIPE policies then there is a danger that their resources could be deregistered. That's part of membership.
As per the NCC's impact analysis this is something they deal with regularly:
"The RIPE NCC has significant experience with resolving these kinds of situations. Over the past five years, it has investigated and resolved more than 1,000 external reports on incorrect “abuse-mailbox:” attributes, without ever needing to trigger the closure and deregistration procedure. Making unresponsive resource holders aware of this procedure has helped to ensure their cooperation."
and
"If the closure and deregistration procedure is triggered, the resource holder still has a further three months to resolve the problem before the actual LIR closure and/or resource deregistration takes place."
So please, can we moderate the fears and properly estimate the risks around de-registration in the case of an invalid abuse-mailbox attribute.
Thanks,
Brian Co-Chair, RIPE AA-WG
Brian Nisbet wrote:
I believe the NCC have stated very clearly how incredibly unlikely deregistration of resources would be and I honestly don't believe the exaggeration for emphasis or otherwise is useful.
this seems to be a statement that just because an extreme policy compliance enforcement mechanism hasn't been used in the past, it would be appropriate to maintain it as a compliance enforcement mechanism in the future for this situation. This is a deeply non-compelling argument. The core issue is proportionality. We're talking here about a tickbox compliance mechanism to further the aims of a fuzzily stated principal where the authors have taken a potshot at and sunk their own rationale. The final sanction for non-compliance has - unusually for a RIPE policy document - been reiterated as termination of contract and withdrawal of resources. For most LIRs, this would cause either serious or terminal operational problems. There is nothing proportional about this, and because of a gross lack of proportionality, the policy should not be adopted in its current form. Nick
I agree that exaggeration is not useful, and probably we need to have several clear attempts before turning down a contract, BUT, if we are talking about proportionality, there are MANY cases of abuses where the responsible LIRs aren't responding at all, and this means a very big harm to the networks being abused. Is that proportional? So clearly, if an LIR is running a decent business and is a good "net citizen", because is responsible of the damages that are caused from that network to others, there is no point to complain, about a possible enforcement of a policy after allowing many attempts to resolve that, of course, unless that LIR is willing to hide the head in the sand as an ostrich if that happens, which I think will show the rest of the Internet what is that LIR business/"who you are". Regards, Jordi -----Mensaje original----- De: anti-abuse-wg <anti-abuse-wg-bounces@ripe.net> en nombre de Nick Hilliard <nick@foobar.org> Fecha: lunes, 22 de enero de 2018, 16:09 Para: Brian Nisbet <brian.nisbet@heanet.ie> CC: Gert Doering <gert@space.net>, <anti-abuse-wg@ripe.net> Asunto: Re: [anti-abuse-wg] [policy-announce] 2017-02 Review Phase (Regular abuse-c Validation) Brian Nisbet wrote: > I believe the NCC have stated very clearly how incredibly unlikely > deregistration of resources would be and I honestly don't believe the > exaggeration for emphasis or otherwise is useful. this seems to be a statement that just because an extreme policy compliance enforcement mechanism hasn't been used in the past, it would be appropriate to maintain it as a compliance enforcement mechanism in the future for this situation. This is a deeply non-compelling argument. The core issue is proportionality. We're talking here about a tickbox compliance mechanism to further the aims of a fuzzily stated principal where the authors have taken a potshot at and sunk their own rationale. The final sanction for non-compliance has - unusually for a RIPE policy document - been reiterated as termination of contract and withdrawal of resources. For most LIRs, this would cause either serious or terminal operational problems. There is nothing proportional about this, and because of a gross lack of proportionality, the policy should not be adopted in its current form. Nick ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es 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.
JORDI PALET MARTINEZ via anti-abuse-wg wrote:
I agree that exaggeration is not useful, and probably we need to have several clear attempts before turning down a contract, BUT, if we are talking about proportionality, there are MANY cases of abuses where the responsible LIRs aren't responding at all, and this means a very big harm to the networks being abused. Is that proportional?
We're not discussing perpetration of abuse; we're discussing whether 2017-02 is fit for purpose. Nick
On 22/01/2018 16:07, Nick Hilliard wrote:
JORDI PALET MARTINEZ via anti-abuse-wg wrote:
I agree that exaggeration is not useful, and probably we need to have several clear attempts before turning down a contract, BUT, if we are talking about proportionality, there are MANY cases of abuses where the responsible LIRs aren't responding at all, and this means a very big harm to the networks being abused. Is that proportional?
We're not discussing perpetration of abuse; we're discussing whether 2017-02 is fit for purpose.
This is indeed the case, whatever opinions of that may be. Thanks, Brian Co-Chair, RIPE AA-WG
On 22/01/2018 15:09, Nick Hilliard wrote:
Brian Nisbet wrote:
I believe the NCC have stated very clearly how incredibly unlikely deregistration of resources would be and I honestly don't believe the exaggeration for emphasis or otherwise is useful.
this seems to be a statement that just because an extreme policy compliance enforcement mechanism hasn't been used in the past, it would be appropriate to maintain it as a compliance enforcement mechanism in the future for this situation. This is a deeply non-compelling argument.
No, it isn't. It's a statement that the process has many steps and that the NCC both say they do and clearly do whatever they can to not reach the termination point of the process. I'm not saying it could never happen, I'm saying that it if happens it's may have been started by 2017-02 but the deregistration would happen because over ~9 months the NCC would be unable to in contact with the LIR in any way. "The RIPE NCC will validate the “abuse-mailbox:” attribute at least annually. Where the attribute is deemed incorrect, it will follow up in compliance with relevant RIPE Policies and RIPE NCC procedures." No new procedures are being proposed here, no new powers. This would be invalid information in the database.
The core issue is proportionality. We're talking here about a tickbox compliance mechanism to further the aims of a fuzzily stated principal where the authors have taken a potshot at and sunk their own rationale.
The final sanction for non-compliance has - unusually for a RIPE policy document - been reiterated as termination of contract and withdrawal of resources. For most LIRs, this would cause either serious or terminal operational problems.
There is nothing proportional about this, and because of a gross lack of proportionality, the policy should not be adopted in its current form.
Well, it's stated in the impact analysis rather than the original (or even version 2) policy text by the authors. The policy text "simply" says that other policies will be followed. If there's work to do on them, that is arguably a different matter and this affects far more than just 2017-02. But so noted. Brian Co-Chair, RIPE AA-WG
Brian Nisbet wrote:
No, it isn't. It's a statement that the process has many steps and that the NCC both say they do and clearly do whatever they can to not reach the termination point of the process. I'm not saying it could never happen, I'm saying that it if happens it's may have been started by 2017-02 but the deregistration would happen because over ~9 months the NCC would be unable to in contact with the LIR in any way.
Couple of things here. Firstly, you're not denying that an extreme policy compliance enforcement mechanism exists. Having a policy which allows a LIR contract to be terminated is extreme, de-facto. It is extreme because the consequences of address resource withdrawal would be terminal for many address holders. I don't disagree that there are legitimate situations where LIR contract termination could be justified, but non-compliance with a relatively minor bureaucratic tickbox operation is not one of them. Presenting an argument about operational procedures and saying that this hasn't been deployed in the past is a different issue. It's akin to describing the colour of a pair of gloves and showing how soft and how nice and even how comfortable they are, while pretending that just because the gloves are so nice, that there isn't an iron fist underneath. Make no mistake, there here is an iron fist being inserted into the policy here and the policy proposal document is - unusually for a policy proposal - explicitly stating in the interpretation notes that this can, and will be used if compliance is not achieved. Again, I have no problem with a policy of LIR termination in situations where that is justified. This is not one of those situations. Secondly, there is no RIPE Community policy that I'm aware of which mandates LIR termination for anything, and certainly not for minor issues like this. It needs to be pointed out that the RIPE NCC board has recently, and without notification to either the membership or the RIPE Community, substantially changed the terms of the "RIPE NCC Audit Activity" document which is a RIPE NCC operational policy, not a RIPE Community policy. The old policy stated that the escalation path was "further measures may be necessary", without stating what those further measures were. Notably, termination of the rights of resource holders was not included. The new policy, dating from Jan 10th states that LIR termination is now a formal and documented RIPE NCC policy. This represents a substantial change in itself. Confusingly, the "RIPE NCC Audit Activity" document is linked from several RIPE Community policies without restriction, which means that we now appear to be in the awkward situation where the RIPE NCC is *arguably* making changes to RIPE Community policy (without reference or even notification to the community) because existing references in RIPE Community policy documents referred to RIPE-423 and previous versions rather than RIPE-694. This is troubling in its own right. What's inside the scope of AAWG is that apparently RIPE-694 now exists and if a policy is passed which acknowledges this document content change, then that RIPE Community policy - unlike all other previous RIPE Community policies which acknowledged RIPE-423 - will give explicit RIPE community mandate to termination of resource holder rights under the terms of 694. This marks a dramatic and substantial change in RIPE Community policy because for the first time, the community would be explicitly giving a mandate to the RIPE NCC to use RIPE-694 rather than RIPE-423. With due respect to your analysis, this is a far larger issue than ought to be dealt with in AAWG. If there is serious intent to continue with any proposal which involves extinguishment of resource holder rights, that discussion needs to be brought up into the context of the larger RIPE Community and the RIPE NCC membership rather than just this working group. Nick
Hello Nick, You say that: " Secondly, there is no RIPE Community policy that I'm aware of which mandates LIR termination for anything, and certainly not for minor issues like this." But the ripe-680 "IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region" explicitly states in §9 "Closing an LIR by the RIPE NCC" that "The RIPE NCC may close an LIR for any of the following reasons [...] - the LIR cannot be contacted by the RIPE NCC for a significant period of time - the LIR consistently violates the RIPE community's policies...." https://www.ripe.net/publications/docs/ripe-680#9 And, furthermore, the syntax is : the LIR "may close"... consequently the proposal wouldn't introduce any stricter mandate to terminate an LIR. And Marco Schmidt confirmed yesterday that "The RIPE NCC would not activate the closure procedure simply because a mail server was broken. The closure procedure can be activated if the resource holder refuses to provide correct abuse contact information, which would be considered a consistent policy violation, or if they are unresponsive over a longer period. During this process, the RIPE NCC will have attempted to contact them several times via different channels before considering that a resource holder is unresponsive." Regards Hervé -----Message d'origine----- De : anti-abuse-wg [mailto:anti-abuse-wg-bounces@ripe.net] De la part de Nick Hilliard Envoyé : mercredi 24 janvier 2018 15:40 À : Brian Nisbet Cc : Gert Doering; anti-abuse-wg@ripe.net Objet : Re: [anti-abuse-wg] [policy-announce] 2017-02 Review Phase (Regular abuse-c Validation) Brian Nisbet wrote:
No, it isn't. It's a statement that the process has many steps and
that the NCC both say they do and clearly do whatever they can to not
reach the termination point of the process. I'm not saying it could
never happen, I'm saying that it if happens it's may have been started
by
2017-02 but the deregistration would happen because over ~9 months the
NCC would be unable to in contact with the LIR in any way.
Couple of things here. Firstly, you're not denying that an extreme policy compliance enforcement mechanism exists. Having a policy which allows a LIR contract to be terminated is extreme, de-facto. It is extreme because the consequences of address resource withdrawal would be terminal for many address holders. I don't disagree that there are legitimate situations where LIR contract termination could be justified, but non-compliance with a relatively minor bureaucratic tickbox operation is not one of them. Presenting an argument about operational procedures and saying that this hasn't been deployed in the past is a different issue. It's akin to describing the colour of a pair of gloves and showing how soft and how nice and even how comfortable they are, while pretending that just because the gloves are so nice, that there isn't an iron fist underneath. Make no mistake, there here is an iron fist being inserted into the policy here and the policy proposal document is - unusually for a policy proposal - explicitly stating in the interpretation notes that this can, and will be used if compliance is not achieved. Again, I have no problem with a policy of LIR termination in situations where that is justified. This is not one of those situations. Secondly, there is no RIPE Community policy that I'm aware of which mandates LIR termination for anything, and certainly not for minor issues like this. It needs to be pointed out that the RIPE NCC board has recently, and without notification to either the membership or the RIPE Community, substantially changed the terms of the "RIPE NCC Audit Activity" document which is a RIPE NCC operational policy, not a RIPE Community policy. The old policy stated that the escalation path was "further measures may be necessary", without stating what those further measures were. Notably, termination of the rights of resource holders was not included. The new policy, dating from Jan 10th states that LIR termination is now a formal and documented RIPE NCC policy. This represents a substantial change in itself. Confusingly, the "RIPE NCC Audit Activity" document is linked from several RIPE Community policies without restriction, which means that we now appear to be in the awkward situation where the RIPE NCC is *arguably* making changes to RIPE Community policy (without reference or even notification to the community) because existing references in RIPE Community policy documents referred to RIPE-423 and previous versions rather than RIPE-694. This is troubling in its own right. What's inside the scope of AAWG is that apparently RIPE-694 now exists and if a policy is passed which acknowledges this document content change, then that RIPE Community policy - unlike all other previous RIPE Community policies which acknowledged RIPE-423 - will give explicit RIPE community mandate to termination of resource holder rights under the terms of 694. This marks a dramatic and substantial change in RIPE Community policy because for the first time, the community would be explicitly giving a mandate to the RIPE NCC to use RIPE-694 rather than RIPE-423. With due respect to your analysis, this is a far larger issue than ought to be dealt with in AAWG. If there is serious intent to continue with any proposal which involves extinguishment of resource holder rights, that discussion needs to be brought up into the context of the larger RIPE Community and the RIPE NCC membership rather than just this working group. 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.
the RIPE NCC "may close" sorry.... De : CLEMENT Herve IMT/OLN Envoyé : mercredi 24 janvier 2018 16:21 À : 'Nick Hilliard'; Brian Nisbet Cc : Gert Doering; anti-abuse-wg@ripe.net Objet : RE: [anti-abuse-wg] [policy-announce] 2017-02 Review Phase (Regular abuse-c Validation) Hello Nick, You say that: " Secondly, there is no RIPE Community policy that I'm aware of which mandates LIR termination for anything, and certainly not for minor issues like this." But the ripe-680 "IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region" explicitly states in §9 "Closing an LIR by the RIPE NCC" that "The RIPE NCC may close an LIR for any of the following reasons [...] - the LIR cannot be contacted by the RIPE NCC for a significant period of time - the LIR consistently violates the RIPE community's policies...." https://www.ripe.net/publications/docs/ripe-680#9 And, furthermore, the syntax is : the LIR "may close"... consequently the proposal wouldn't introduce any stricter mandate to terminate an LIR. And Marco Schmidt confirmed yesterday that "The RIPE NCC would not activate the closure procedure simply because a mail server was broken. The closure procedure can be activated if the resource holder refuses to provide correct abuse contact information, which would be considered a consistent policy violation, or if they are unresponsive over a longer period. During this process, the RIPE NCC will have attempted to contact them several times via different channels before considering that a resource holder is unresponsive." Regards Hervé -----Message d'origine----- De : anti-abuse-wg [mailto:anti-abuse-wg-bounces@ripe.net] De la part de Nick Hilliard Envoyé : mercredi 24 janvier 2018 15:40 À : Brian Nisbet Cc : Gert Doering; anti-abuse-wg@ripe.net<mailto:anti-abuse-wg@ripe.net> Objet : Re: [anti-abuse-wg] [policy-announce] 2017-02 Review Phase (Regular abuse-c Validation) Brian Nisbet wrote:
No, it isn't. It's a statement that the process has many steps and
that the NCC both say they do and clearly do whatever they can to not
reach the termination point of the process. I'm not saying it could
never happen, I'm saying that it if happens it's may have been started
by
2017-02 but the deregistration would happen because over ~9 months the
NCC would be unable to in contact with the LIR in any way.
Couple of things here. Firstly, you're not denying that an extreme policy compliance enforcement mechanism exists. Having a policy which allows a LIR contract to be terminated is extreme, de-facto. It is extreme because the consequences of address resource withdrawal would be terminal for many address holders. I don't disagree that there are legitimate situations where LIR contract termination could be justified, but non-compliance with a relatively minor bureaucratic tickbox operation is not one of them. Presenting an argument about operational procedures and saying that this hasn't been deployed in the past is a different issue. It's akin to describing the colour of a pair of gloves and showing how soft and how nice and even how comfortable they are, while pretending that just because the gloves are so nice, that there isn't an iron fist underneath. Make no mistake, there here is an iron fist being inserted into the policy here and the policy proposal document is - unusually for a policy proposal - explicitly stating in the interpretation notes that this can, and will be used if compliance is not achieved. Again, I have no problem with a policy of LIR termination in situations where that is justified. This is not one of those situations. Secondly, there is no RIPE Community policy that I'm aware of which mandates LIR termination for anything, and certainly not for minor issues like this. It needs to be pointed out that the RIPE NCC board has recently, and without notification to either the membership or the RIPE Community, substantially changed the terms of the "RIPE NCC Audit Activity" document which is a RIPE NCC operational policy, not a RIPE Community policy. The old policy stated that the escalation path was "further measures may be necessary", without stating what those further measures were. Notably, termination of the rights of resource holders was not included. The new policy, dating from Jan 10th states that LIR termination is now a formal and documented RIPE NCC policy. This represents a substantial change in itself. Confusingly, the "RIPE NCC Audit Activity" document is linked from several RIPE Community policies without restriction, which means that we now appear to be in the awkward situation where the RIPE NCC is *arguably* making changes to RIPE Community policy (without reference or even notification to the community) because existing references in RIPE Community policy documents referred to RIPE-423 and previous versions rather than RIPE-694. This is troubling in its own right. What's inside the scope of AAWG is that apparently RIPE-694 now exists and if a policy is passed which acknowledges this document content change, then that RIPE Community policy - unlike all other previous RIPE Community policies which acknowledged RIPE-423 - will give explicit RIPE community mandate to termination of resource holder rights under the terms of 694. This marks a dramatic and substantial change in RIPE Community policy because for the first time, the community would be explicitly giving a mandate to the RIPE NCC to use RIPE-694 rather than RIPE-423. With due respect to your analysis, this is a far larger issue than ought to be dealt with in AAWG. If there is serious intent to continue with any proposal which involves extinguishment of resource holder rights, that discussion needs to be brought up into the context of the larger RIPE Community and the RIPE NCC membership rather than just this working group. 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.
On Mon, 22 Jan 2018 14:19:26 +0100 Gert Doering <gert@space.net> wrote:
On Mon, Jan 22, 2018 at 11:25:12AM +0000, Nick Hilliard wrote:
I have no problem with abuse-c validation, either via ARC, or the mechanism proposed in this policy, and probably not via a range of other mechanisms either. But threatening to terminate the right of an organisation to continue to exist in the case of non compliance of the terms specified in 2017-02 is frankly absurd.
I second this concern. I do see the need for a working abuse contact, and I do see the need of sanctions in case a policy is violated, but "deregister all resources, because your mail server was broken when we tested" is too extreme (exaggeration for emphasis).
+1 for the need for sanctions when policy is violated +1 for the need for the sanctions process to be more clearly described Maybe when policy is violated, multiple times (more than once) and also then notice by additional communication (phone?) and if that also fails then loss of resource is reasonable. There has to be a stick otherwise it is all pointless anyway. So, defining the stick somewhat better (fairly) is not unreasonable. Andre
On 22.01.2018 14:19, Gert Doering wrote:
I do see the need for a working abuse contact, and I do see the need of sanctions in case a policy is violated, but "deregister all resources, because your mail server was broken when we tested" is too extreme (exaggeration for emphasis).
I fully agree a resource should not be withdrawn just because the abuse-mailbox is (temporarily) invalid or the holder once misses to complete the verification process in time - if he otherwise takes care of malicious activity emerging from his resources. However, I think RIPE-563 (and related policies) should state that resource holders have to provide a valid abuse-mailbox which is monitored on a regular basis and have to take care of complaints regarding malicious activity reported to this mailbox. An autoresponder asking people to fill out a webform should not be accepted as a valid solution as this does not work for CERTs and other security teams reporting hundreds of abuse cases per day to the responsible resource owners (in an automated fashion). Also, irrespective of how the abuse-c verification process will be implemented, IMHO there is a need for a defined process on how resources can be withdrawn (as a last resort) if the holder is constantly ignoring abuse complaints or even wittingly accepts malicious activity emerging from his resources (e.g. bullet proof hosting). - Thomas CERT-Bund Incident Response & Malware Analysis Team
Thomas, Just to be very clear, the current proposal is only in relation to verification. If the community wish for other processes to be put in place in regards to lack of action on abuse or similar, then that would require a wholly different proposal. Thanks, Brian Co-Chair, RIPE AA-W Thomas Hungenberg wrote on 23/01/2018 11:51:
On 22.01.2018 14:19, Gert Doering wrote:
I do see the need for a working abuse contact, and I do see the need of sanctions in case a policy is violated, but "deregister all resources, because your mail server was broken when we tested" is too extreme (exaggeration for emphasis).
I fully agree a resource should not be withdrawn just because the abuse-mailbox is (temporarily) invalid or the holder once misses to complete the verification process in time - if he otherwise takes care of malicious activity emerging from his resources.
However, I think RIPE-563 (and related policies) should state that resource holders have to provide a valid abuse-mailbox which is monitored on a regular basis and have to take care of complaints regarding malicious activity reported to this mailbox. An autoresponder asking people to fill out a webform should not be accepted as a valid solution as this does not work for CERTs and other security teams reporting hundreds of abuse cases per day to the responsible resource owners (in an automated fashion).
Also, irrespective of how the abuse-c verification process will be implemented, IMHO there is a need for a defined process on how resources can be withdrawn (as a last resort) if the holder is constantly ignoring abuse complaints or even wittingly accepts malicious activity emerging from his resources (e.g. bullet proof hosting).
- Thomas
CERT-Bund Incident Response & Malware Analysis Team
On Tue, 23 Jan 2018 14:45:13 +0000 Brian Nisbet <brian.nisbet@heanet.ie> wrote:
Just to be very clear, the current proposal is only in relation to verification.
If the community wish for other processes to be put in place in regards to lack of action on abuse or similar, then that would require a wholly different proposal.
As Marco Schmidt explained regarding exactly this, "verification" :
An SMTP RCPT command, as Nick mentioned, will likely be one of several checks that we perform. These checks will identify that the syntax and format of the email address is okay, the domain accepts email, and that the mailbox itself exists. We aim for the results to be as accurate as possible.
This is simply not good enough for abuse-c as the core of having a real abuse-c is that it is monitored/real/functional and not just an email address created with an autoresponder. this goes to the core of the real world problem. many resource holders create a valid email address and then link an autoresponder to that saying: thank you for your very valuable abuse notification! Please visit our website link to submit a report then on the "website/link" create an account for this singular complaint verify that account (jump through many hoops) then verify the actual complaint then confirm your details and information etc etc so many many hoops - all designed to waste time and to reduce actually receiving any abuse notifications. Sure, RIPE cannot tell resource users how to handle abuse reports or complaints BUT RIPE can ensure at least that having a resource record means something? otherwise it is pointless even having an abuse-c - as it means nothing. so, why have an abuse-c at all? the point is: verification, if done in this manner: send an alphanumeric key to be entered on website after solving a capcha proves that the abuse-c is real/monitored/etc. - and not a useless bot/autoresponder or nonsensical resource record. Andre
Dear Brian and Nick, On 2018-01-22 10:20:50 CET, Brian Nisbet wrote:
After looking at the text from the "Validation method" section of the proposal, it looks like the RIPE NCC may be suggesting doing something like issuing an SMTP RCPT command to see if the mail server rejects the email address. If this is the case, it is likely to provide plenty of false positives albeit no false negatives. I.e. if it fails this test, then the email address is categorically not working, but if it passes this test, then there is no guarantee that the email address is working, for a very limited definition of the word. Because of a lack of details, is not possible to tell if this is the actual method being suggested, but it is not incompatible with what is being proposed in the PP document.
I would suggest that seeking clarification from the NCC about the impact analysis and proposed solution is a perfectly fine thing to do, especially if people are uncertain, so hopefully they can clarify further here.
Thank you for your question. An SMTP RCPT command, as Nick mentioned, will likely be one of several checks that we perform. These checks will identify that the syntax and format of the email address is okay, the domain accepts email, and that the mailbox itself exists. We aim for the results to be as accurate as possible. As mentioned in the impact analysis, we are aware that there may be false positives. These can be always entered into the validation process by creating a report with our contact form: https://www.ripe.net/contact-form As we also mentioned in the impact analysis, a preliminary test revealed that probably around 10%-25% of the current abuse-mailbox attributes will not pass our planned validation check and so will need a review and potential fixing. I hope this clarifies. Kind regards, Marco Schmidt Policy Development Officer RIPE NCC Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum
On 19 Jan 2018, at 2:21, Wolfgang Tremmel wrote:
I can imagine as the "click here and solve captcha" emails will be standardized that a carefully crafted attack might lure fist line helpdesk people onto shady websides and making them click stuff.
If your helpdesk in charge of abuse is so vulnerable that clicking on a link or by extension, receiving a malware sample, will become a successful attack, then I would be interested to understand how exactly do they handle abuse reports today? Almost all of what we get involves links and/or potentially dangerous malware samples. Yet we somehow don't get compromised as easily as your message suggests. Luis Muñoz Director, Registry Operations ____________________________ http://www.uniregistry.link/ 2161 San Joaquin Hills Road Newport Beach, CA 92660 Office +1 949 706 2300 x 4242 lem@uniregistry.link
participants (11)
-
Brian Nisbet -
Erik Bais -
Gert Doering -
herve.clement＠orange.com -
JORDI PALET MARTINEZ -
Luis E. Muñoz -
Marco Schmidt -
Nick Hilliard -
ox -
Thomas Hungenberg -
Wolfgang Tremmel