2019-04 Discussion Phase (Validation of "abuse-mailbox")
Dear colleagues, A new version of RIPE policy proposal, 2019-04, "Validation of "abuse-mailbox"", is now available for discussion. This proposal aims to have the RIPE NCC validate "abuse-c:" information more often and introduces a new validation process. Most of the text has been rewritten following the last round of discussion and the proposal is now at version 3.0. Some key points in this version: - The abuse-mailbox should not force the sender to use a form - The validation process must ensure that the abuse mailbox is able to receive messages - The validation should happen at least every six months You can find the full proposal at: https://www.ripe.net/participate/policies/proposals/2019-04 As per the RIPE Policy Development Process (PDP), the purpose of this four-week Discussion Phase is to discuss the proposal and provide feedback to the proposer. At the end of the Discussion Phase, the proposer, with the agreement of the Anti-Abuse Working Group Chairs, will decide how to proceed with the proposal. We encourage you to review this proposal and send your comments to <anti-abuse-wg@ripe.net> before 27 May 2020. Kind regards, -- Petrit Hasani Policy Officer RIPE NCC
Petrit Hasani wrote on 28/04/2020 15:01:
A new version of RIPE policy proposal, 2019-04, "Validation of "abuse-mailbox"", is now available for discussion.
The updated version of this policy proposal is here:
https://www.ripe.net/participate/policies/proposals/2019-04/draft
The proposal has the following problems, each of which would be sufficient reason it its own right to reject the proposal:
and must not force the sender to use a form.
It's not the job of the RIPE NCC to tell its members how to handle abuse reports, and it is beyond inappropriate for this working group to expect the RIPE NCC to withdraw numbering resources if member organisations don't comply with an arbitrary policy which forces the use of SMTP email like this.
[...] is present and can receive messages at least every six months*. If the validation fails, the RIPE NCC and:
*The RIPE NCC may change the validation period depending on the level of accuracy of the contacts. For example, switching from six-month to one-year period once contact accuracy has improved.
This addition proposes to micromanage the RIPE NCC even further. Arbitrary time-scales like this are operational details which have no place in a well-thought-out policy.
This validation process will not check how the abuse cases are processed. The community should escalate/report back to the RIPE NCC, so anonymised statistics can be collected and periodically published.
However, the community should report any situation to the RIPE NCC, which can provide (anonymous) periodical statistics to the community, which can take further decisions about that.
This proposes that the RIPE NCC becomes an abuse reporting clearinghouse based on unsubstantiated community gossip. This is inappropriate in many different ways.
It should be clear that the policy intent is not to look into how the abuse mailbox is monitored or how abuse cases are handled.
It's difficult to take this seriously when the intent of most of the rest of the text in the proposal is about using the RIPE NCC to monitor how abuse cases are handled and to ensure that the abuse mailbox is monitored. The proposal 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. In addition, all of these problems were identified in previous versions of the proposal, i.e. none of them has been resolved and because of that, there is no reason to think that this version is any more likely to reach consensus than any of the previous versions. The proposal needs to be abandoned. Nick
Hi, On Tue, Apr 28, 2020 at 08:27:32PM +0100, Nick Hilliard wrote:
The proposal needs to be abandoned.
Yep. gert -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
No point repeating Nick's points, but I agree. The current proposal should be abandoned - it's not getting better with each iteration Regards Michele -- Mr Michele Neylon Blacknight Solutions Hosting, Colocation & Domains https://www.blacknight.com https://blacknight.blog / http://ceo.hosting/ Intl. +353 (0) 59 9183072 Direct Dial: +353 (0)59 9183090 ------------------------------- Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park, Sleaty Road, Graiguecullen, Carlow, R93 X265,Ireland Company No.: 370845 On 28/04/2020, 20:27, "anti-abuse-wg on behalf of Nick Hilliard" <anti-abuse-wg-bounces@ripe.net on behalf of nick@foobar.org> wrote: Petrit Hasani wrote on 28/04/2020 15:01: > A new version of RIPE policy proposal, 2019-04, "Validation of > "abuse-mailbox"", is now available for discussion. The updated version of this policy proposal is here: > https://www.ripe.net/participate/policies/proposals/2019-04/draft The proposal has the following problems, each of which would be sufficient reason it its own right to reject the proposal: > and must not force the sender to use a form. It's not the job of the RIPE NCC to tell its members how to handle abuse reports, and it is beyond inappropriate for this working group to expect the RIPE NCC to withdraw numbering resources if member organisations don't comply with an arbitrary policy which forces the use of SMTP email like this. > [...] is present and can receive messages at least every six months*. > If the validation fails, the RIPE NCC and: > *The RIPE NCC may change the validation period depending on the level > of accuracy of the contacts. For example, switching from six-month to > one-year period once contact accuracy has improved. This addition proposes to micromanage the RIPE NCC even further. Arbitrary time-scales like this are operational details which have no place in a well-thought-out policy. > This validation process will not check how the abuse cases are > processed. The community should escalate/report back to the RIPE NCC, > so anonymised statistics can be collected and periodically > published. > However, the community should report any situation to the RIPE NCC, > which can provide (anonymous) periodical statistics to the community, > which can take further decisions about that. This proposes that the RIPE NCC becomes an abuse reporting clearinghouse based on unsubstantiated community gossip. This is inappropriate in many different ways. > It should be clear that the policy intent is not to look into how the > abuse mailbox is monitored or how abuse cases are handled. It's difficult to take this seriously when the intent of most of the rest of the text in the proposal is about using the RIPE NCC to monitor how abuse cases are handled and to ensure that the abuse mailbox is monitored. The proposal 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. In addition, all of these problems were identified in previous versions of the proposal, i.e. none of them has been resolved and because of that, there is no reason to think that this version is any more likely to reach consensus than any of the previous versions. The proposal needs to be abandoned. Nick
Nick Hilliard wrote:
and must not force the sender to use a form.
It's not the job of the RIPE NCC to tell its members how to handle abuse reports, and it is beyond inappropriate for this working group to expect the RIPE NCC to withdraw numbering resources if member organisations don't comply with an arbitrary policy which forces the use of SMTP email like this.
This is not how to *handle* abuse reports, but how to *receive* them. Given that the resource holder needs to provide an email mailbox for abuse contact, it doesn't seem so unreasonable to ask that it is possible to *gasp* send abuse reports using that abuse mailbox. Many autoreplies suggest you to use a form, as a way to speedy the request. However, if an abuse mailbox replies:
Your abuse request has NOT been proceed amd mpt tramsitted to our team. This automatic answer is NOT an acknowledge. Your request MUST be report on httos;//... (a real case from a RIPE member),
is it a working mailbox? What if abuse-c: pointed to abuse@example.com, then an autoreply told you to email instead bob@example.com, that john@example.com, that one jane@example.com, which replies that she is no longer and example.com and please could you send that to mary@example.com... Is that a "working mailbox"? Note we could have instead a abuse-uri rather than a mailbox, so that it could be reported via a mailto:, https://, gopher://... Ultimately, though, the real problem is to standardise the communication. That could be by using a mail compliant to x-arf (or anything else we might come up with), stating a set of fields needed by a REST abuse form, etc. And getting everyone to agree on such set of fields would be difficult. But once the information is structured, the next steps should be quite straightforward. According to whatever procedures you may have to handle these issues. Also, I should note that handling abuse _should_ be desirable for a member that *cares*. It may be a compromised host, an abusive customer... but a timely report would avoid, rather than just finding out when they find themselves on a third-party blacklist since nobody bothered to jump through the needed jumps just to tell them they needed to password reset a compromised account. Regards
Hi Nick, all, I was waiting a few days because I though it will be easier wait for most of the participants to be able to react and then try to summarize and respond to all the comments in a single email. I'm going to try to do it anyway with as fewer emails as I can. This means trying to avoid repeating myself, in the interest of everyone, but if you feel that I'm missing anything which is key, please, let me know. I would suggest to wait a couple of hours, so I stop replying in order to ask something that I will be replying already in minutes ... So ... My responses below, in line, as [Jordi] El 28/4/20 21:28, "anti-abuse-wg en nombre de Nick Hilliard" <anti-abuse-wg-bounces@ripe.net en nombre de nick@foobar.org> escribió: Petrit Hasani wrote on 28/04/2020 15:01: > A new version of RIPE policy proposal, 2019-04, "Validation of > "abuse-mailbox"", is now available for discussion. The updated version of this policy proposal is here: > https://www.ripe.net/participate/policies/proposals/2019-04/draft The proposal has the following problems, each of which would be sufficient reason it its own right to reject the proposal: > and must not force the sender to use a form. It's not the job of the RIPE NCC to tell its members how to handle abuse reports, and it is beyond inappropriate for this working group to expect the RIPE NCC to withdraw numbering resources if member organisations don't comply with an arbitrary policy which forces the use of SMTP email like this. [Jordi] The job of the RIPE NCC is to implement the policies agreed by the community. Different folks may consider different pieces of all of our policies as "inappropriate" or "arbitrary" and the goal is to find a point in the middle, which is what we call consensus. 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*. > [...] is present and can receive messages at least every six months*. > If the validation fails, the RIPE NCC and: > *The RIPE NCC may change the validation period depending on the level > of accuracy of the contacts. For example, switching from six-month to > one-year period once contact accuracy has improved. This addition proposes to micromanage the RIPE NCC even further. Arbitrary time-scales like this are operational details which have no place in a well-thought-out policy. [Jordi] The actual policy has a bigger level of micro-management, by setting one year and not allowing the NCC to change that. I think it is much better to explicitly allow it. One alternative, I will be fine with that, is not define the time at all, and let the NCC to adapt it to the needs. Would you thing this is more appropriate? > This validation process will not check how the abuse cases are > processed. The community should escalate/report back to the RIPE NCC, > so anonymised statistics can be collected and periodically > published. > However, the community should report any situation to the RIPE NCC, > which can provide (anonymous) periodical statistics to the community, > which can take further decisions about that. This proposes that the RIPE NCC becomes an abuse reporting clearinghouse based on unsubstantiated community gossip. This is inappropriate in many different ways. [Jordi] What I'm asking here is to make sure that we have stats. I'm not changing what is an actual practice. You can always report to *any* RIR, what you think is wrong and if you're a good internet citizen, you should do that. I'm happy if you believe that my wording is not good, and we agree on that goal, to find an alternative one. Any suggestion? > It should be clear that the policy intent is not to look into how the > abuse mailbox is monitored or how abuse cases are handled. It's difficult to take this seriously when the intent of most of the rest of the text in the proposal is about using the RIPE NCC to monitor how abuse cases are handled and to ensure that the abuse mailbox is monitored. [Jordi] I can't agree here. If you compare the different versions, you will see that I've taken in consideration the inputs on this and removed lots of text that were considered as telling the resource holders how to do it. The proposal no longer looks if you have a person, a robot, or whatever to monitor de abuse mailbox, or if you ignore the cases. The proposal 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. [Jordi] Again, the proposal is trying to ensure that we have stats. Then we, as a community, can decide if we need to do anything or not. I don't think this is intrusive at all and if we compare with other policies, that also tell us how you do the things, because many things related to how your get and manage resources, keep the database updated, etc., at the end, clearly have some impact in your processes as a business. In addition, all of these problems were identified in previous versions of the proposal, i.e. none of them has been resolved and because of that, there is no reason to think that this version is any more likely to reach consensus than any of the previous versions. The proposal needs to be abandoned. Nick ********************************************** 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.
JORDI PALET MARTINEZ via anti-abuse-wg wrote on 08/05/2020 12:07:
[Jordi] The job of the RIPE NCC is to implement the policies agreed by the community. Different folks may consider different pieces of all of our policies as "inappropriate" or "arbitrary"
which is fine, mostly. Subject to usual discretion of the RIPE NCC to ignore policy which is harmful to itself or others. Various board members have confirmed in the past that the RIPE NCC will not buy an island if instructed to do so by the RIPE Community.
and the goal is to find a point in the middle, which is what we call consensus.
The goal is to try to find consensus. There's nothing in the concept of consensus about trying to find a point in the middle. If I make a policy proposal to demand that the RIPE NCC buy an island, would it be reasonable to settle on a compromise which involved the RIPE NCC buying only half an island? It's ok for consensus to be that a policy proposal be rejected entirely.
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*.
Couple of things on this: - if you want to standardise a mechanism for abuse reporting, then that would be useful and by all means, go ahead with that idea first. There are many forums available for doing this. - your proposal threatens to close down RIPE NCC members if they decline to support abuse reports over email. This is unhinged.
[Jordi] The actual policy has a bigger level of micro-management, by setting one year and not allowing the NCC to change that. I think it is much better to explicitly allow it. One alternative, I will be fine with that, is not define the time at all, and let the NCC to adapt it to the needs. Would you thing this is more appropriate?
The entire policy is poorly thought-through to start with. You can't fix bad policy with minor tweaks around the edges.
[Jordi] What I'm asking here is to make sure that we have stats. I'm not changing what is an actual practice. You can always report to *any* RIR, what you think is wrong and if you're a good internet citizen, you should do that.
If you're a good internet citizen, you have some moral obligation to report abuse to an internet number resources registry? You're completely putting the cart before the horse here. The purpose of the RIRs is number resource registration.
I'm happy if you believe that my wording is not good, and we agree on that goal, to find an alternative one. Any suggestion?
Firstly, if you propose to collect stats about anything, you need to think about what sort of stats should be collected. Secondly, you need to make a credible argument about why the RIPE NCC should be obliged to spend membership funds collecting these stats and why the RIPE NCC is a more appropriate vehicle for collecting these stats than other organisations which specialise in online security and abuse issues, particularly those which already collect statistics about online abuse. Nick
It's ok for consensus to be that a policy proposal be rejected entirely.
but how many times? randy
Has this even been put to a vote or is it the same group of extremely vocal RIPE regulars against it and the same group of extremely vocal security types for it? Rough consensus has its limitations in such cases. From: anti-abuse-wg <anti-abuse-wg-bounces@ripe.net> Date: Saturday, 9 May 2020 at 4:22 AM To: Nick Hilliard <nick@foobar.org> Cc: anti-abuse-wg@ripe.net <anti-abuse-wg@ripe.net> Subject: Re: [anti-abuse-wg] 2019-04 Discussion Phase (Validation of "abuse-mailbox")
It's ok for consensus to be that a policy proposal be rejected entirely.
but how many times? randy
Hi, On Sat, May 09, 2020 at 01:12:32AM +0000, Suresh Ramasubramanian wrote:
Has this even been put to a vote or is it the same group of extremely vocal RIPE regulars against it and the same group of extremely vocal security types for it? Rough consensus has its limitations in such cases.
There is no voting. It's either "there is sufficient support and counterarguments have been adequately addressed" or "no consensus, rewrite or withdraw". Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
In a case where the community is polarised to this extent it would be better to break with procedure and call a vote for once. With member organizations represented by their abuse team heads, rather than IP / routing people, so that the organisation’s stance on this is clear. From: Gert Doering <gert@space.net> Date: Saturday, 9 May 2020 at 3:57 PM To: Suresh Ramasubramanian <ops.lists@gmail.com> Cc: Randy Bush <randy@psg.com>, Nick Hilliard <nick@foobar.org>, anti-abuse-wg@ripe.net <anti-abuse-wg@ripe.net> Subject: Re: [anti-abuse-wg] 2019-04 Discussion Phase (Validation of "abuse-mailbox") Hi, On Sat, May 09, 2020 at 01:12:32AM +0000, Suresh Ramasubramanian wrote:
Has this even been put to a vote or is it the same group of extremely vocal RIPE regulars against it and the same group of extremely vocal security types for it? Rough consensus has its limitations in such cases.
There is no voting. It's either "there is sufficient support and counterarguments have been adequately addressed" or "no consensus, rewrite or withdraw". Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
On Sat, May 09, 2020 at 11:56:58AM +0000, Suresh Ramasubramanian wrote:
In a case where the community is polarised to this extent it would be better to break with procedure and call a vote for once. With member organizations represented by their abuse team heads, rather than IP / routing people, so that the organisation�s stance on this is clear.
In the words of Lord Hoffman: " I find it difficult to express with appropriate moderation my disagreement with the proposition" Not only do you propose the abolition of the PDP, you want to also limit the "electorate" to such as are more likely to be sympathetic to your cause. I don't even know how to respond to this without invoking Godwin's Law or similar, so I'll stop here. rgds, Sascha Luck
From: Gert Doering <gert@space.net> Date: Saturday, 9 May 2020 at 3:57 PM To: Suresh Ramasubramanian <ops.lists@gmail.com> Cc: Randy Bush <randy@psg.com>, Nick Hilliard <nick@foobar.org>, anti-abuse-wg@ripe.net <anti-abuse-wg@ripe.net> Subject: Re: [anti-abuse-wg] 2019-04 Discussion Phase (Validation of "abuse-mailbox") Hi,
On Sat, May 09, 2020 at 01:12:32AM +0000, Suresh Ramasubramanian wrote:
Has this even been put to a vote or is it the same group of extremely vocal RIPE regulars against it and the same group of extremely vocal security types for it? Rough consensus has its limitations in such cases.
There is no voting.
It's either "there is sufficient support and counterarguments have been adequately addressed" or "no consensus, rewrite or withdraw".
Gert Doering -- NetMaster -- have you enabled IPv6 on something today...?
SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
All I am asking is that cobblers stick to their last. People with backgrounds in routing and networking are not necessarily the people in their organizations that handle abuse issues. Unless by extension you want your mailserver and spam filter people getting enable on your routers, or you want to go and filter spam for example. From: anti-abuse-wg <anti-abuse-wg-bounces@ripe.net> Date: Monday, 11 May 2020 at 10:48 PM To: anti-abuse-wg@ripe.net <anti-abuse-wg@ripe.net> Subject: Re: [anti-abuse-wg] 2019-04 Discussion Phase (Validation of "abuse-mailbox") On Sat, May 09, 2020 at 11:56:58AM +0000, Suresh Ramasubramanian wrote:
In a case where the community is polarised to this extent it would be better to break with procedure and call a vote for once. With member organizations represented by their abuse team heads, rather than IP / routing people, so that the organisation’s stance on this is clear.
In the words of Lord Hoffman: " I find it difficult to express with appropriate moderation my disagreement with the proposition" Not only do you propose the abolition of the PDP, you want to also limit the "electorate" to such as are more likely to be sympathetic to your cause. I don't even know how to respond to this without invoking Godwin's Law or similar, so I'll stop here. rgds, Sascha Luck
From: Gert Doering <gert@space.net> Date: Saturday, 9 May 2020 at 3:57 PM To: Suresh Ramasubramanian <ops.lists@gmail.com> Cc: Randy Bush <randy@psg.com>, Nick Hilliard <nick@foobar.org>, anti-abuse-wg@ripe.net <anti-abuse-wg@ripe.net> Subject: Re: [anti-abuse-wg] 2019-04 Discussion Phase (Validation of "abuse-mailbox") Hi,
On Sat, May 09, 2020 at 01:12:32AM +0000, Suresh Ramasubramanian wrote:
Has this even been put to a vote or is it the same group of extremely vocal RIPE regulars against it and the same group of extremely vocal security types for it? Rough consensus has its limitations in such cases.
There is no voting.
It's either "there is sufficient support and counterarguments have been adequately addressed" or "no consensus, rewrite or withdraw".
Gert Doering -- NetMaster -- have you enabled IPv6 on something today...?
SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
Hi, On Mon, May 11, 2020 at 05:23:43PM +0000, Suresh Ramasubramanian wrote:
All I am asking is that cobblers stick to their last. People with backgrounds in routing and networking are not necessarily the people in their organizations that handle abuse issues.
Unless by extension you want your mailserver and spam filter people getting enable on your routers, or you want to go and filter spam for example.
If you discuss "taking away resources" as sanctions for improper abuse handling (which is how this proposal started), yes, routing and networking people are most highly affected. If this is about "do you want a mail address or a web form for reporting abuse?", no, routing and networking people do not really care much. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
If this is about "do you want a mail address or a web form for reporting abuse?", no, routing and networking people do not really care much.
depends. will the bikeshed be magenta? randy
Hi, On Mon, May 11, 2020 at 10:46:51AM -0700, Randy Bush wrote:
If this is about "do you want a mail address or a web form for reporting abuse?", no, routing and networking people do not really care much.
depends. will the bikeshed be magenta?
magenta bikesheds are only available if you pay... gert -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
Precisely. But I wonder whether it is a greater problem to be packeted by a bot with C2 in IP space that would have been better off not being allocated, rather than being spammed or phished from there. And how much greater or lesser any or all of those compared to the inconvenience routing and networking people face from having resources taken away for originating such traffic. From: Gert Doering <gert@space.net> Date: Monday, 11 May 2020 at 11:12 PM To: Suresh Ramasubramanian <ops.lists@gmail.com> Cc: Sascha Luck [ml] <aawg@c4inet.net>, anti-abuse-wg@ripe.net <anti-abuse-wg@ripe.net> Subject: Re: [anti-abuse-wg] 2019-04 Discussion Phase (Validation of "abuse-mailbox") Hi, On Mon, May 11, 2020 at 05:23:43PM +0000, Suresh Ramasubramanian wrote:
All I am asking is that cobblers stick to their last. People with backgrounds in routing and networking are not necessarily the people in their organizations that handle abuse issues.
Unless by extension you want your mailserver and spam filter people getting enable on your routers, or you want to go and filter spam for example.
If you discuss "taking away resources" as sanctions for improper abuse handling (which is how this proposal started), yes, routing and networking people are most highly affected. If this is about "do you want a mail address or a web form for reporting abuse?", no, routing and networking people do not really care much. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
Hi, On Mon, 11 May 2020, Suresh Ramasubramanian wrote:
Precisely. But I wonder whether it is a greater problem to be packeted by a bot with C2 in IP space that would have been better off not being allocated, rather than being spammed or phished from there. And how much greater or lesser any or all of those compared to the inconvenience routing and networking people face from having resources taken away for originating such traffic.
Spam and phishing happen above layer3, however, significantly reducing spam and phishing (and other malicious bits) would also reduce packets to be pushed around... I can understand that for some people 90Gbps is (commercially) better than 9Gbps, even if 81Gbps of it are just plain crap... Oh, and one man's crap can be another man's gold. Especially if the first is in the receiving end and the latter in a sender position. :-) Regards, Carlos
Hi Suresh,
All I am asking is that cobblers stick to their last. People with backgrounds in routing and networking are not necessarily the people in their organizations that handle abuse issues.
As I'm sure you're aware, the RIPE working groups are open to all (regardless of any organisation's membership of the RIPE NCC or not, or location in the traditional service area of the RIPE NCC), and I would expect the Anti-Abuse Working Group to have reasonable representation from those dealing with abuse issues. I don't wish to speak for the co-chairs, but if those people aren't represented I am sure they'd be welcome to take part in the working group! Equally, people working in dealing with abuse issues are welcome to contribute to discussions on routing, networking, and re-soling shoes. Cheers, Rob
I am glad to hear that and of course that’s the case. But then I’m getting called out for “encouraging” consensus, to the point where it invites application of Godwin’s law, by crowding the room with people in support of the proposal, if I call for participation from organisations’ abuse teams. I keep getting the sense of a long running old closed club where anything above packet pushing and dns aren’t quite operational and just barely tolerated / mostly ignored for the most part. --srs From: Rob Evans <rhe@nosc.ja.net> Date: Tuesday, 12 May 2020 at 12:21 AM To: Suresh Ramasubramanian <ops.lists@gmail.com> Cc: Sascha Luck [ml] <aawg@c4inet.net>, anti-abuse-wg@ripe.net <anti-abuse-wg@ripe.net> Subject: Re: [anti-abuse-wg] 2019-04 Discussion Phase (Validation of "abuse-mailbox") Hi Suresh,
All I am asking is that cobblers stick to their last. People with backgrounds in routing and networking are not necessarily the people in their organizations that handle abuse issues.
As I'm sure you're aware, the RIPE working groups are open to all (regardless of any organisation's membership of the RIPE NCC or not, or location in the traditional service area of the RIPE NCC), and I would expect the Anti-Abuse Working Group to have reasonable representation from those dealing with abuse issues. I don't wish to speak for the co-chairs, but if those people aren't represented I am sure they'd be welcome to take part in the working group! Equally, people working in dealing with abuse issues are welcome to contribute to discussions on routing, networking, and re-soling shoes. Cheers, Rob
Suresh Ramasubramanian wrote on 11/05/2020 18:23:
All I am asking is that cobblers stick to their last. People with backgrounds in routing and networking are not necessarily the people in their organizations that handle abuse issues.
From another point of view, you're asking for the RIPE NCC RIR component to change its fundamental nature from being a registry to being an enforcement agency. It's ok for people who don't handle abuse issues on a daily basis to have an opinion about this. Nick
El vie, 08-05-2020 a las 22:57 +0100, Nick Hilliard escribió:
I'm happy if you believe that my wording is not good, and we agree on that goal, to find an alternative one. Any suggestion?
Firstly, if you propose to collect stats about anything, you need to think about what sort of stats should be collected.
Secondly, you need to make a credible argument about why the RIPE NCC should be obliged to spend membership funds collecting these stats and why the RIPE NCC is a more appropriate vehicle for collecting these stats than other organisations which specialise in online security and abuse issues, particularly those which already collect statistics about online abuse.
Nick
Hello Nick These are not statistics about online abuse. These are statistics about the contact information registered by RIPE being valid. RIPE contact database is like a phone book. It doesn't matter for that if the number which was looked up was the hairdresser's (a customer relationship) or the number of the upstairs neighbour which is flooding your home (abuse). It may be that the fire department has statistics of non-working numbers on the phone book (since, incidentally, they are using the same phone book as the rest of the people), but it is much more logical that the entity tracking the phone book quality was be the one compiling the phone book (even though it is the one which would need to provide the proper number should be the actual customer). Kind regards -- INCIBE-CERT - CERT of the Spanish National Cybersecurity Institute https://www.incibe-cert.es/ PGP Keys: https://www.incibe-cert.es/en/what-is-incibe-cert/pgp-public-keys ======================================================================== INCIBE-CERT is the Spanish National CSIRT designated for citizens, private law entities, other entities not included in the subjective scope of application of the "Ley 40/2015, de 1 de octubre, de Régimen Jurídico del Sector Público", as well as digital service providers, operators of essential services and critical operators under the terms of the "Real Decreto-ley 12/2018, de 7 de septiembre, de seguridad de las redes y sistemas de información" that transposes the Directive (EU) 2016/1148 of the European Parliament and of the Council of 6 July 2016 concerning measures for a high common level of security of network and information systems across the Union. ========================================================================
Ángel González Berdasco wrote on 11/05/2020 17:08:
These are not statistics about online abuse. These are statistics about the contact information registered by RIPE being valid.
The statistics thing was something that was inserted into version 3 of the proposal. It's hard to tell what the exact intention was, or what statistics were supposed to be collected. Nick
Hi Nick, El 8/5/20 23:58, "Nick Hilliard" <nick@foobar.org> escribió: JORDI PALET MARTINEZ via anti-abuse-wg wrote on 08/05/2020 12:07: > [Jordi] The job of the RIPE NCC is to implement the policies agreed > by the community. Different folks may consider different pieces of > all of our policies as "inappropriate" or "arbitrary" which is fine, mostly. Subject to usual discretion of the RIPE NCC to ignore policy which is harmful to itself or others. Various board members have confirmed in the past that the RIPE NCC will not buy an island if instructed to do so by the RIPE Community. > and the goal is > to find a point in the middle, which is what we call consensus. The goal is to try to find consensus. There's nothing in the concept of consensus about trying to find a point in the middle. If I make a policy proposal to demand that the RIPE NCC buy an island, would it be reasonable to settle on a compromise which involved the RIPE NCC buying only half an island? It's ok for consensus to be that a policy proposal be rejected entirely. [Jordi] I guess there is a translation problem here. For us in Spain, something in the middle means a middle term or "compromise" to find an agreement, not to buy half of the island ;-) even less when I'm not trying to buy any island! Consensus is very well described in many nice sentences in RFC7282 (by the way, remember that is not just consensus, we use it for short, but actually it is "rough consensus"). For example: "Coming to consensus is when everyone (including the person making the objection) comes to the conclusion that either the objections are valid, and therefore make a change to address the objection, or that the objection was not really a matter of importance, but merely a matter of taste. Of course, coming to full consensus like that does not always happen. That's why in the IETF, we talk about "rough consensus"." *** See also "5. Consensus is the path, not the destination", it requires time and sometimes many cycles (many versions), is the only way we have, is slow, by in my opinion is the right way. > 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*. Couple of things on this: - if you want to standardise a mechanism for abuse reporting, then that would be useful and by all means, go ahead with that idea first. There are many forums available for doing this. [Jordi] The standard is already defined and this version of the proposal included it. Now we need to agree if we want to use it or not, and at the time being I wrote it as one choice. Maybe the community prefers making it as the only valid option. We do that very often in many other proposals. Why not for abuse reporting? - your proposal threatens to close down RIPE NCC members if they decline to support abuse reports over email. This is unhinged. [Jordi] No, this is not my proposal, this is already *any policy violation* , and actually the actual policy already do that, but in an unclear way. I'm trying to expose it being more honest and transparent with the interpretation of the actual text: "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." > [Jordi] The actual policy has a bigger level of micro-management, by > setting one year and not allowing the NCC to change that. I think it > is much better to explicitly allow it. One alternative, I will be > fine with that, is not define the time at all, and let the NCC to > adapt it to the needs. Would you thing this is more appropriate? The entire policy is poorly thought-through to start with. You can't fix bad policy with minor tweaks around the edges. [Jordi] Well, we disagree here, many documents reached consensus thru contributions from people, even if it was a bad document (I don't think it is the case) from the start. > [Jordi] What I'm asking here is to make sure that we have stats. I'm > not changing what is an actual practice. You can always report to > *any* RIR, what you think is wrong and if you're a good internet > citizen, you should do that. If you're a good internet citizen, you have some moral obligation to report abuse to an internet number resources registry? [Jordi] This is my opinion, not just in the Internet community. If I see something wrong in "any community", I need to cooperate to make it better. Otherwise I can't complain. If you don't like the food in the restaurant, you either stop eating there or complain so they improve ... If you don't like how your city major does his job, you will complain, even provide suggestions, or not vote him anymore and convince others about that. You're completely putting the cart before the horse here. The purpose of the RIRs is number resource registration. [Jordi] Which include reliable and usable database information. > I'm happy if you believe that my wording > is not good, and we agree on that goal, to find an alternative one. > Any suggestion? Firstly, if you propose to collect stats about anything, you need to think about what sort of stats should be collected. Secondly, you need to make a credible argument about why the RIPE NCC should be obliged to spend membership funds collecting these stats and why the RIPE NCC is a more appropriate vehicle for collecting these stats than other organisations which specialise in online security and abuse issues, particularly those which already collect statistics about online abuse. [Jordi] What I understood from RIPE NCC, correct me please if I'm wrong, is that they have already those stats, but they aren't mandated to keep collecting them or even less, publish periodic reports. Regarding what stats, I was thinking that it is obvious, but seems not: Escalation cases for failed abuse mailboxes. We can then compare with the existing validation procedure and see if something is not really working or it is people that just don't handle abuse cases. By the way, this has been in place in APNIC for already around one year, and it is providing good results. Nick ********************************************** 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.
In relation to the policy, where it says: "must not force the sender to use a form." as someone that reports phishing websites, I find the use of forms helpful, as it ensures the company receives the report, particularly where they implement a CAPTCHA. To require the resource to only accept abuse reports via email, means all the criminals have to do is flood the mailbox, making it physically impossible to receive the abuse reports. If the policy could be amended to include a suggestion that the abuse mailbox contain a verification procedure (such as "your email has been received. Please "click here" to confirm you sent it") it would improve efficiency all around. In relation to Nick Hilliard's email, where they say: " it is beyond inappropriate for this working group to expect the RIPE NCC to withdraw numbering resources if member organisations don't comply with an arbitrary policy which forces the use of SMTP email like this." This is, in a nutshell, what is wrong with this RIR, and others, such as ARIN. Often I will look up abuse contacts on ARIN, to find that the abuse mailbox bounces, and a message such as "ARIN has attempted to verify this email address since 10-11-2010" - almost 10 YEARS! So, what are you seriously suggesting? Because these people that become offended at the suggestion that it's unreasonable for someone to ensure an email address is valid once per year (very onerous i'm sure), never really say what they really mean, which is really what is inappropriate: that criminals should be able to use a resource indefinitely to pump out spam, host phishing websites, co-ordinate botnets etc... and that the person that receives this crap is not even entitled to let the resource owner know? ---- On Wed, Apr 29, 2020 at 12:01 AM Petrit Hasani <phasani@ripe.net> wrote:
Dear colleagues,
A new version of RIPE policy proposal, 2019-04, "Validation of "abuse-mailbox"", is now available for discussion.
This proposal aims to have the RIPE NCC validate "abuse-c:" information more often and introduces a new validation process.
Most of the text has been rewritten following the last round of discussion and the proposal is now at version 3.0. Some key points in this version:
- The abuse-mailbox should not force the sender to use a form - The validation process must ensure that the abuse mailbox is able to receive messages - The validation should happen at least every six months
You can find the full proposal at: https://www.ripe.net/participate/policies/proposals/2019-04
As per the RIPE Policy Development Process (PDP), the purpose of this four-week Discussion Phase is to discuss the proposal and provide feedback to the proposer.
At the end of the Discussion Phase, the proposer, with the agreement of the Anti-Abuse Working Group Chairs, will decide how to proceed with the proposal.
We encourage you to review this proposal and send your comments to <anti-abuse-wg@ripe.net> before 27 May 2020.
Kind regards, -- Petrit Hasani Policy Officer RIPE NCC
Hi, On Wed, Apr 29, 2020 at 12:25:08PM +1000, No No wrote:
So, what are you seriously suggesting? Because these people that become offended at the suggestion that it's unreasonable for someone to ensure an email address is valid once per year (very onerous i'm sure), never really say what they really mean, which is really what is inappropriate: that criminals should be able to use a resource indefinitely to pump out spam, host phishing websites, co-ordinate botnets etc... and that the person that receives this crap is not even entitled to let the resource owner know?
We already have abuse-c mailbox verification, *and* the NCC does approach the LIRs to make sure the mailbox is working, if they encounter bounces (by sending mail to LIR contacts, by sending letters, calling up, bringing it up in the next yearly ARC). So a situation where a mailbox would be bouncing for 10+ years is unlikely to happen in RIPE land. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
El 29/4/20 4:25, "anti-abuse-wg en nombre de No No" <anti-abuse-wg-bounces@ripe.net en nombre de no0484985@gmail.com> escribió: In relation to the policy, where it says: "must not force the sender to use a form." as someone that reports phishing websites, I find the use of forms helpful, as it ensures the company receives the report, particularly where they implement a CAPTCHA. [Jordi] I disagree here and many people has also indicated the same in previous versions discussions. The problem of a form is that is not standard. If you’re reporting abuses to 100 ISPs, and each one has its own form, you really need to do it manually, you can’t automate it. Even if you do the job for automating it, they may change it and your automation may fail. This is economically non-sustainable and means that the cost of the abuse cases is on the back of the one actually reporting. To require the resource to only accept abuse reports via email, means all the criminals have to do is flood the mailbox, making it physically impossible to receive the abuse reports. [Jordi] That's why I’m suggesting the use of standards as one of the options. I’m happy to find a better way or wording to improve it. Do we agree that something that can be fully automatted is much better, even to filter that kind of flooding? If the policy could be amended to include a suggestion that the abuse mailbox contain a verification procedure (such as "your email has been received. Please "click here" to confirm you sent it") it would improve efficiency all around. [Jordi] A previous version had many many many details and it was considered to intrusive, that's why I’m going away from there. In relation to Nick Hilliard's email, where they say: " it is beyond inappropriate for this working group to expect the RIPE NCC to withdraw numbering resources if member organisations don't comply with an arbitrary policy which forces the use of SMTP email like this." This is, in a nutshell, what is wrong with this RIR, and others, such as ARIN. Often I will look up abuse contacts on ARIN, to find that the abuse mailbox bounces, and a message such as "ARIN has attempted to verify this email address since 10-11-2010" - almost 10 YEARS! So, what are you seriously suggesting? Because these people that become offended at the suggestion that it's unreasonable for someone to ensure an email address is valid once per year (very onerous i'm sure), never really say what they really mean, which is really what is inappropriate: that criminals should be able to use a resource indefinitely to pump out spam, host phishing websites, co-ordinate botnets etc... and that the person that receives this crap is not even entitled to let the resource owner know? ---- On Wed, Apr 29, 2020 at 12:01 AM Petrit Hasani <phasani@ripe.net> wrote: Dear colleagues, A new version of RIPE policy proposal, 2019-04, "Validation of "abuse-mailbox"", is now available for discussion. This proposal aims to have the RIPE NCC validate "abuse-c:" information more often and introduces a new validation process. Most of the text has been rewritten following the last round of discussion and the proposal is now at version 3.0. Some key points in this version: - The abuse-mailbox should not force the sender to use a form - The validation process must ensure that the abuse mailbox is able to receive messages - The validation should happen at least every six months You can find the full proposal at: https://www.ripe.net/participate/policies/proposals/2019-04 As per the RIPE Policy Development Process (PDP), the purpose of this four-week Discussion Phase is to discuss the proposal and provide feedback to the proposer. At the end of the Discussion Phase, the proposer, with the agreement of the Anti-Abuse Working Group Chairs, will decide how to proceed with the proposal. We encourage you to review this proposal and send your comments to <anti-abuse-wg@ripe.net> before 27 May 2020. Kind regards, -- Petrit Hasani Policy Officer RIPE NCC ********************************************** 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.
I would also like to make another suggestion: That where the RIPE has to manually verify an abuse mailbox, the costs of that verification should be levelled against the resource holder as a fee, for example: $2 per IPv4 address and, failing manual verification, that a countdown be implemented and sent to the abuse mailbox, in the form of: "Click here within 7 days to ensure your resources are not de-registered" and then if they fail to click that link, the automatic de-registering of the IP address/resources, and the immediate sale of that IPv4 address/space to the highest bidder. --- On Wed, Apr 29, 2020 at 12:01 AM Petrit Hasani <phasani@ripe.net> wrote:
Dear colleagues,
A new version of RIPE policy proposal, 2019-04, "Validation of "abuse-mailbox"", is now available for discussion.
This proposal aims to have the RIPE NCC validate "abuse-c:" information more often and introduces a new validation process.
Most of the text has been rewritten following the last round of discussion and the proposal is now at version 3.0. Some key points in this version:
- The abuse-mailbox should not force the sender to use a form - The validation process must ensure that the abuse mailbox is able to receive messages - The validation should happen at least every six months
You can find the full proposal at: https://www.ripe.net/participate/policies/proposals/2019-04
As per the RIPE Policy Development Process (PDP), the purpose of this four-week Discussion Phase is to discuss the proposal and provide feedback to the proposer.
At the end of the Discussion Phase, the proposer, with the agreement of the Anti-Abuse Working Group Chairs, will decide how to proceed with the proposal.
We encourage you to review this proposal and send your comments to <anti-abuse-wg@ripe.net> before 27 May 2020.
Kind regards, -- Petrit Hasani Policy Officer RIPE NCC
Dear "no no", who are you? what is your skin in this game? Kind regards, Job
Hi, On Wed, Apr 29, 2020 at 12:31:39PM +1000, No No wrote:
I would also like to make another suggestion:
That where the RIPE has to manually verify an abuse mailbox, the costs of that verification should be levelled against the resource holder as a fee, for example: $2 per IPv4 address
and,
failing manual verification, that a countdown be implemented and sent to the abuse mailbox, in the form of: "Click here within 7 days to ensure your resources are not de-registered" and then if they fail to click that link, the automatic de-registering of the IP address/resources, and the immediate sale of that IPv4 address/space to the highest bidder.
And *this* is exactly why this proposal is the beginning of a slippery slope that leads to "no way!" land. Mail system misconfigurations happen, even for the best of us. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
I fully agree with Gert here. The proposal is not trying to punish anyone, just to improve things, make sure that errors are discovered and corrected, and for that we need to have stats and tools. And this is why it was also removed from this version text that we had in previous versions about that. El 29/4/20 8:38, "anti-abuse-wg en nombre de Gert Doering" <anti-abuse-wg-bounces@ripe.net en nombre de gert@space.net> escribió: Hi, On Wed, Apr 29, 2020 at 12:31:39PM +1000, No No wrote: > I would also like to make another suggestion: > > That where the RIPE has to manually verify an abuse mailbox, the costs of > that verification should be levelled against the resource holder as a fee, > for example: $2 per IPv4 address > > and, > > failing manual verification, that a countdown be implemented and sent to > the abuse mailbox, in the form of: "Click here within 7 days to ensure your > resources are not de-registered" and then if they fail to click that link, > the automatic de-registering of the IP address/resources, and the immediate > sale of that IPv4 address/space to the highest bidder. And *this* is exactly why this proposal is the beginning of a slippery slope that leads to "no way!" land. Mail system misconfigurations happen, even for the best of us. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 ********************************************** 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.
Hi All I think this is a good policy. We can always find use cases where it fails, but it will help in some cases. And if some one is not able to answer an e-mail every six month, there are probably underlying issues. Also the argument, that the bad guys flood the mailbox is not really acceptable. It just means you can't filter spam. The proposal does not check how the reports are used. But it helps us to enumerate organizations, that don't act, coming up with various excuses, along the lines the best problems are some one else's problems, so let's make it some on else's problem. The fact is: Most mature organizations are perfectly capable of handling such mail boxes, even if they have a high load. Coming from the incident response side, I'm tiered of people constantly telling me, that issues are not their problem Best Serge On 28.04.20 16:01, Petrit Hasani wrote:
Dear colleagues,
A new version of RIPE policy proposal, 2019-04, "Validation of "abuse-mailbox"", is now available for discussion.
This proposal aims to have the RIPE NCC validate "abuse-c:" information more often and introduces a new validation process.
Most of the text has been rewritten following the last round of discussion and the proposal is now at version 3.0. Some key points in this version:
- The abuse-mailbox should not force the sender to use a form - The validation process must ensure that the abuse mailbox is able to receive messages - The validation should happen at least every six months
You can find the full proposal at: https://www.ripe.net/participate/policies/proposals/2019-04
As per the RIPE Policy Development Process (PDP), the purpose of this four-week Discussion Phase is to discuss the proposal and provide feedback to the proposer.
At the end of the Discussion Phase, the proposer, with the agreement of the Anti-Abuse Working Group Chairs, will decide how to proceed with the proposal.
We encourage you to review this proposal and send your comments to <anti-abuse-wg@ripe.net> before 27 May 2020.
Kind regards, -- Petrit Hasani Policy Officer RIPE NCC
-- Dr. Serge Droz Chair of the FIRST Board of Directors https://www.first.org
Hi, On Wed, Apr 29, 2020 at 10:22:13AM +0200, Serge Droz via anti-abuse-wg wrote:
Coming from the incident response side, I'm tiered of people constantly telling me, that issues are not their problem
How would this proposal help with said problem? It wouldn't. If people *want* to handle abuse reports, they do so today already (and if they mess up their mail reception, the NCC will check this today already, and let them know). If people *do not want* to handle abuse reports, this proposal will not make them. Failing the stated mission, abandon. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
Coming from the incident response side, I'm tiered of people constantly telling me, that issues are not their problem
How would this proposal help with said problem?
- It will catch the cases where some miss configuration happened indeed - It will make it impossible for orgs to say "We never received a report" - It allows us to enumerate better who does good work and who doesn't. And making this transparent will help showing thate there is an issue and maybe also be a motivation for people to change But I've said that before. Best Serge -- Dr. Serge Droz Chair of the FIRST Board of Directors https://www.first.org
Hi, On Wed, Apr 29, 2020 at 01:44:42PM +0200, Serge Droz via anti-abuse-wg wrote:
Coming from the incident response side, I'm tiered of people constantly telling me, that issues are not their problem
How would this proposal help with said problem?
- It will catch the cases where some miss configuration happened indeed
This is already caught today. The RIPE NCC *does* abuse-c mailbox validation today.
- It will make it impossible for orgs to say "We never received a report"
How so? Yes, there is a mailbox. But if someone doesn't care, why would they not still claim "I have never seen a report"?
- It allows us to enumerate better who does good work and who doesn't.
And how does *this proposal* have any influence on this? I'm usually more of an reporter than a responder, but I've seen both sides - and [as I've said before...] you don't get orgs that do not care to magically expend resources on abuse handling by introducing more mailbox verification procedures. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
El 29/4/20 14:23, "anti-abuse-wg en nombre de Gert Doering" <anti-abuse-wg-bounces@ripe.net en nombre de gert@space.net> escribió: Hi, On Wed, Apr 29, 2020 at 01:44:42PM +0200, Serge Droz via anti-abuse-wg wrote: > >> Coming from the incident response side, I'm tiered of people constantly > >> telling me, that issues are not their problem > > > > How would this proposal help with said problem? > > - It will catch the cases where some miss configuration happened indeed This is already caught today. The RIPE NCC *does* abuse-c mailbox validation today. [Jordi] But is not working, it is just a technical validation. > - It will make it impossible for orgs to say "We never received a report" How so? Yes, there is a mailbox. But if someone doesn't care, why would they not still claim "I have never seen a report"? [Jordi] We need to know stats about those cases. > - It allows us to enumerate better who does good work and who doesn't. And how does *this proposal* have any influence on this? [Jordi] I agree here with Gert. Personally, I will like to know who is not handling abuse cases, so I can filter its network. As "what is best for the community, at the time being", and the way I phrased it in the proposal I just want to have stats, not pointing to anyone. I'm usually more of an reporter than a responder, but I've seen both sides - and [as I've said before...] you don't get orgs that do not care to magically expend resources on abuse handling by introducing more mailbox verification procedures. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 ********************************************** 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.
Hi, On 29/04/2020 13:22, Gert Doering wrote:
If people *want* to handle abuse reports, they do so today already (and if they mess up their mail reception, the NCC will check this today already, and let them know).
If people *do not want* to handle abuse reports, this proposal will not make them.
The above is unquestionable truth. There is a grey area, where a mailbox doesn't work because of misconfiguration, mailbox full, or similar issues. Validation might help in those cases. However, statements like: The “abuse-c:” will be mandatory for all aut-nums are in conflict with the unquestionable truth quoted above. Please, allow abuse-c to be empty! I have to keep a dont-send list of non-responding abuse addresses. Some 70% of the complaints I would have sent hit that list. It would be more practical to have an empty abuse-c entry in the first place. In addition, having networks without abuse addresses makes them more easily identifiable. RIPE NCC could compile the relevant IP addresses into an easily usable format, for example one readable by rbldns. Rather than following-up and threatening resource revocation, upon repeated validation failures, the RIPE NCC should just remove the non-working abuse-c entry, thereby adding the relevant IP addresses to the "no-complaints" list. A web form to report bouncing abuse addresses would be useful too. Best Ale --
As long as the ASNs that are not maintaining an abuse address are published along with the no complaints list, I personally have no complaints. From: anti-abuse-wg <anti-abuse-wg-bounces@ripe.net> Date: Monday, 4 May 2020 at 3:59 PM To: anti-abuse-wg@ripe.net <anti-abuse-wg@ripe.net> Subject: Re: [anti-abuse-wg] 2019-04 Discussion Phase (Validation of "abuse-mailbox") Hi, On 29/04/2020 13:22, Gert Doering wrote:
If people *want* to handle abuse reports, they do so today already (and if they mess up their mail reception, the NCC will check this today already, and let them know).
If people *do not want* to handle abuse reports, this proposal will not make them.
The above is unquestionable truth. There is a grey area, where a mailbox doesn't work because of misconfiguration, mailbox full, or similar issues. Validation might help in those cases. However, statements like: The “abuse-c:” will be mandatory for all aut-nums are in conflict with the unquestionable truth quoted above. Please, allow abuse-c to be empty! I have to keep a dont-send list of non-responding abuse addresses. Some 70% of the complaints I would have sent hit that list. It would be more practical to have an empty abuse-c entry in the first place. In addition, having networks without abuse addresses makes them more easily identifiable. RIPE NCC could compile the relevant IP addresses into an easily usable format, for example one readable by rbldns. Rather than following-up and threatening resource revocation, upon repeated validation failures, the RIPE NCC should just remove the non-working abuse-c entry, thereby adding the relevant IP addresses to the "no-complaints" list. A web form to report bouncing abuse addresses would be useful too. Best Ale --
Is this "Alessandro Vesely" person from an alternate universe or something? "The Police aren't going to respond to a call about someone breaking in to my house... so let's just remove the phone number from the phone book all together." What. The.. F................ On Mon, May 4, 2020 at 8:29 PM Alessandro Vesely <vesely@tana.it> wrote:
Hi,
On 29/04/2020 13:22, Gert Doering wrote:
If people *want* to handle abuse reports, they do so today already (and if they mess up their mail reception, the NCC will check this today already, and let them know).
If people *do not want* to handle abuse reports, this proposal will not make them.
The above is unquestionable truth. There is a grey area, where a mailbox doesn't work because of misconfiguration, mailbox full, or similar issues. Validation might help in those cases.
However, statements like:
The “abuse-c:” will be mandatory for all aut-nums
are in conflict with the unquestionable truth quoted above. Please, allow abuse-c to be empty! I have to keep a dont-send list of non-responding abuse addresses. Some 70% of the complaints I would have sent hit that list. It would be more practical to have an empty abuse-c entry in the first place.
In addition, having networks without abuse addresses makes them more easily identifiable. RIPE NCC could compile the relevant IP addresses into an easily usable format, for example one readable by rbldns. Rather than following-up and threatening resource revocation, upon repeated validation failures, the RIPE NCC should just remove the non-working abuse-c entry, thereby adding the relevant IP addresses to the "no-complaints" list.
A web form to report bouncing abuse addresses would be useful too.
Best Ale --
Hi Alessandro, As I've indicated already several times (and not just in this discussion), all the RIRs have forms or other methods to escalate any issues. The proposal is only changing "let's have stats". El 4/5/20 12:29, "anti-abuse-wg en nombre de Alessandro Vesely" <anti-abuse-wg-bounces@ripe.net en nombre de vesely@tana.it> escribió: Hi, On 29/04/2020 13:22, Gert Doering wrote: > > If people *want* to handle abuse reports, they do so today already > (and if they mess up their mail reception, the NCC will check this today > already, and let them know). > > If people *do not want* to handle abuse reports, this proposal will not > make them. The above is unquestionable truth. There is a grey area, where a mailbox doesn't work because of misconfiguration, mailbox full, or similar issues. Validation might help in those cases. However, statements like: The “abuse-c:” will be mandatory for all aut-nums are in conflict with the unquestionable truth quoted above. Please, allow abuse-c to be empty! I have to keep a dont-send list of non-responding abuse addresses. Some 70% of the complaints I would have sent hit that list. It would be more practical to have an empty abuse-c entry in the first place. In addition, having networks without abuse addresses makes them more easily identifiable. RIPE NCC could compile the relevant IP addresses into an easily usable format, for example one readable by rbldns. Rather than following-up and threatening resource revocation, upon repeated validation failures, the RIPE NCC should just remove the non-working abuse-c entry, thereby adding the relevant IP addresses to the "no-complaints" list. A web form to report bouncing abuse addresses would be useful too. Best Ale -- ********************************************** 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.
On Fri 08/May/2020 13:28:10 +0200 JORDI PALET MARTINEZ via anti-abuse-wg wrote:
Hi Alessandro,
As I've indicated already several times (and not just in this discussion), all the RIRs have forms or other methods to escalate any issues.
The proposal is only changing "let's have stats".
I read: 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. https://www.ripe.net/participate/policies/proposals/2019-04 The anonymized statistics is mentioned afterward. It seems to result from community escalation and reporting, rather than from the abuse-mailbox validation itself. By my proposal, instead, the output of the validation process is borne out when the abuse address is removed from the database —and the corresponding IP ranges duly transmitted. Best Ale
El 4/5/20 12:29, "anti-abuse-wg en nombre de Alessandro Vesely" <anti-abuse-wg-bounces@ripe.net en nombre de vesely@tana.it> escribió:
Hi,
On 29/04/2020 13:22, Gert Doering wrote: > > If people *want* to handle abuse reports, they do so today already > (and if they mess up their mail reception, the NCC will check this today > already, and let them know). > > If people *do not want* to handle abuse reports, this proposal will not > make them.
The above is unquestionable truth. There is a grey area, where a mailbox doesn't work because of misconfiguration, mailbox full, or similar issues. Validation might help in those cases.
However, statements like:
The “abuse-c:” will be mandatory for all aut-nums
are in conflict with the unquestionable truth quoted above. Please, allow abuse-c to be empty! I have to keep a dont-send list of non-responding abuse addresses. Some 70% of the complaints I would have sent hit that list. It would be more practical to have an empty abuse-c entry in the first place.
In addition, having networks without abuse addresses makes them more easily identifiable. RIPE NCC could compile the relevant IP addresses into an easily usable format, for example one readable by rbldns. Rather than following-up and threatening resource revocation, upon repeated validation failures, the RIPE NCC should just remove the non-working abuse-c entry, thereby adding the relevant IP addresses to the "no-complaints" list.
A web form to report bouncing abuse addresses would be useful too.
Best Ale --
********************************************** 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.
On 08-05-2020 20:17 +0200, Alessandro Vesely wrote:
On Fri 08/May/2020 13:28:10 +0200 JORDI PALET MARTINEZ wrote:
Hi Alessandro,
As I've indicated already several times (and not just in this discussion), all the RIRs have forms or other methods to escalate any issues.
The proposal is only changing "let's have stats".
I read:
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.
https://www.ripe.net/participate/policies/proposals/2019-04
The anonymized statistics is mentioned afterward. It seems to result from community escalation and reporting, rather than from the abuse- mailbox validation itself. By my proposal, instead, the output of the validation process is borne out when the abuse address is removed from the database —and the corresponding IP ranges duly transmitted.
Best Ale
Currently there are already abuse contacts marked as having failed validation. Maybe it should be tagged in a different way. I do not think removing them would be the solution, as that would be ambiguous with not having been set at all. Plus, it is also possible that it is actually working, and the failure was just a transient error. Trying to suit everything, I would probably go for providing along the abuse contact when was the first and last known date it worked, and -if newer- they didn't. An individual could contribute to the contact being marked as failed (as it's already the case) by notifying RIPE. The rir owner could also trigger a new check to show that it is working again. And whatever you do with such information, is still up for local policy. If am abuse contact is known to have been working last Monday, but fails since yesterday, there's a good chance that it has been fixed or it will be shortly. If it has never been verified to work and it has been failing for seven years, well, there's probably no point in notifying them through that address. However, all of that would still be a local policy decision, which I suspect would be better received. You would set your own arbitrary thresholds there, rather than the discussion on after which X time should RIPE pull that entry from the db. Plus, not all purposes would treat them similarly. In case you are reporting an abuse from two hours ago, you may only care that it is working *right now*. However, if you were checking whether their abuse contact status, as one of multiple points evaluating a peering request, trying to guess how problematic your prospective neighbour may be, you might prefer seeing that their abuse mail has been reachable for the last 6 months. Best regards
On Fri 08/May/2020 21:30:14 +0200 Ángel González Berdasco wrote:
On 08-05-2020 20:17 +0200, Alessandro Vesely wrote:
On Fri 08/May/2020 13:28:10 +0200 JORDI PALET MARTINEZ wrote:
Hi Alessandro,
As I've indicated already several times (and not just in this discussion), all the RIRs have forms or other methods to escalate any issues.
The proposal is only changing "let's have stats".
I read:
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.
https://www.ripe.net/participate/policies/proposals/2019-04
The anonymized statistics is mentioned afterward. It seems to result from community escalation and reporting, rather than from the abuse-mailbox validation itself. By my proposal, instead, the output of the validation process is borne out when the abuse address is removed from the database —and the corresponding IP ranges duly transmitted.
Currently there are already abuse contacts marked as having failed validation. Maybe it should be tagged in a different way. I do not think removing them would be the solution, as that would be ambiguous with not having been set at all. Plus, it is also possible that it is actually working, and the failure was just a transient error.
Before removing or marking as invalid an abuse-mailbox, RIPE NCC has to make absolutely sure that that is a permanent condition. A statement by the registrant that they are not willing to employ an abuse team would be the best evidence. Then someone, possibly external, has to read the database and produce a list of the relevant IP addresses, so that MTAs having a suitable policy can immediately deploy it. As for removing vs. marking as invalid, the only consideration is that tools for retrieving abuse-addresses via rdap can hardly cope with the latter. However, they can probably check an exclusion list. So, it would work both ways.
An individual could contribute to the contact being marked as failed (as it's already the case) by notifying RIPE.
Is it? How? There is a contact form https://www.ripe.net/contact-form where the topic can be selected to be "RIPE Database". However, I happened to report a bounce from an abuse address and see a reply from RIPE NCC Support asking "Could you please let us know which action is requested from our side?" The first steps of the validation process could be easily automated. The failure reporting web form could even show the first and last known dates when the reported address was tested.
The rir owner could also trigger a new check to show that it is working again.
Right. That should result in immediate rehabilitation.
And whatever you do with such information, is still up for local policy. If am abuse contact is known to have been working last Monday, but fails since yesterday, there's a good chance that it has been fixed or it will be shortly. If it has never been verified to work and it has been failing for seven years, well, there's probably no point in notifying them through that address.
Transient failures can happen, especially with heavily loaded mailboxes. However, the state of an abuse-mailbox should be a clear yes/no, not flipping too often.
However, all of that would still be a local policy decision, which I suspect would be better received. You would set your own arbitrary thresholds there, rather than the discussion on after which X time should RIPE pull that entry from the db. Plus, not all purposes would treat them similarly. In case you are reporting an abuse from two hours ago, you may only care that it is working *right now*. However, if you were checking whether their abuse contact status, as one of multiple points evaluating a peering request, trying to guess how problematic your prospective neighbour may be, you might prefer seeing that their abuse mail has been reachable for the last 6 months.
I'd leave to RIPE NCC to determine how to reliably set an abuse contact status. If I, as an MTA admin, had to extract data from the RIPE database, trying to understand the reliability of abuse-c data, such as the first and last known dates it worked, I'd probably give up. OTOH, if I only had to rsync an IP list having a very low false positive rate, I'd probably go for it. If RIPE NCC remove or mark as invalid just the abuse-c's of acknowledged non-responding or non-existing abuse teams, then the FP rate ought to be very low. There will always be the case of the MTA which badly contracted with an unconcerned ISP. Their FP rate will account for the 0.x%, and they will keep complaining until they change provider. That's already the way email works for those large mailbox providers who can afford a reliable IP reputation system. Best Ale --
*" A statement by the registrant that they are not willing to employ an abuse team would be the best evidence."* ... Followed by swift de-registration of all IP resources. --- On Sat, May 9, 2020 at 8:28 PM Alessandro Vesely <vesely@tana.it> wrote:
On Fri 08/May/2020 21:30:14 +0200 Ángel González Berdasco wrote:
On 08-05-2020 20:17 +0200, Alessandro Vesely wrote:
On Fri 08/May/2020 13:28:10 +0200 JORDI PALET MARTINEZ wrote:
Hi Alessandro,
As I've indicated already several times (and not just in this discussion), all the RIRs have forms or other methods to escalate any issues.
The proposal is only changing "let's have stats".
I read:
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.
https://www.ripe.net/participate/policies/proposals/2019-04
The anonymized statistics is mentioned afterward. It seems to result from community escalation and reporting, rather than from the abuse-mailbox validation itself. By my proposal, instead, the output of the validation process is borne out when the abuse address is removed from the database —and the corresponding IP ranges duly transmitted.
Currently there are already abuse contacts marked as having failed validation. Maybe it should be tagged in a different way. I do not think removing them would be the solution, as that would be ambiguous with not having been set at all. Plus, it is also possible that it is actually working, and the failure was just a transient error.
Before removing or marking as invalid an abuse-mailbox, RIPE NCC has to make absolutely sure that that is a permanent condition. A statement by the registrant that they are not willing to employ an abuse team would be the best evidence.
Then someone, possibly external, has to read the database and produce a list of the relevant IP addresses, so that MTAs having a suitable policy can immediately deploy it.
As for removing vs. marking as invalid, the only consideration is that tools for retrieving abuse-addresses via rdap can hardly cope with the latter. However, they can probably check an exclusion list. So, it would work both ways.
An individual could contribute to the contact being marked as failed (as it's already the case) by notifying RIPE.
Is it? How? There is a contact form https://www.ripe.net/contact-form where the topic can be selected to be "RIPE Database". However, I happened to report a bounce from an abuse address and see a reply from RIPE NCC Support asking "Could you please let us know which action is requested from our side?"
The first steps of the validation process could be easily automated. The failure reporting web form could even show the first and last known dates when the reported address was tested.
The rir owner could also trigger a new check to show that it is working again.
Right. That should result in immediate rehabilitation.
And whatever you do with such information, is still up for local policy. If am abuse contact is known to have been working last Monday, but fails since yesterday, there's a good chance that it has been fixed or it will be shortly. If it has never been verified to work and it has been failing for seven years, well, there's probably no point in notifying them through that address.
Transient failures can happen, especially with heavily loaded mailboxes. However, the state of an abuse-mailbox should be a clear yes/no, not flipping too often.
However, all of that would still be a local policy decision, which I suspect would be better received. You would set your own arbitrary thresholds there, rather than the discussion on after which X time should RIPE pull that entry from the db. Plus, not all purposes would treat them similarly. In case you are reporting an abuse from two hours ago, you may only care that it is working *right now*. However, if you were checking whether their abuse contact status, as one of multiple points evaluating a peering request, trying to guess how problematic your prospective neighbour may be, you might prefer seeing that their abuse mail has been reachable for the last 6 months.
I'd leave to RIPE NCC to determine how to reliably set an abuse contact status. If I, as an MTA admin, had to extract data from the RIPE database, trying to understand the reliability of abuse-c data, such as the first and last known dates it worked, I'd probably give up. OTOH, if I only had to rsync an IP list having a very low false positive rate, I'd probably go for it.
If RIPE NCC remove or mark as invalid just the abuse-c's of acknowledged non-responding or non-existing abuse teams, then the FP rate ought to be very low.
There will always be the case of the MTA which badly contracted with an unconcerned ISP. Their FP rate will account for the 0.x%, and they will keep complaining until they change provider. That's already the way email works for those large mailbox providers who can afford a reliable IP reputation system.
Best Ale --
On Sun 10/May/2020 04:43:30 +0200 No No wrote:
/" A statement by the registrant that they are not willing to employ an abuse team would be the best evidence."/ / / ... Followed by swift de-registration of all IP resources.
Bravo! Here you're touching the very essence of our disagreement. Please don't think that I wouldn't opt for a world without miscreants, if it were possible. However, by de-registration you're not eliminating those people and you're not stopping their abusing, are you? (Don't reply "If all the RIRs did like so..."). And then, what's the practical difference between eliminating miscreants and just eluding them, apart from the fact that the former is not possible while the latter is? Best Ale --
Hi Alessandro, El 8/5/20 20:18, "anti-abuse-wg en nombre de Alessandro Vesely" <anti-abuse-wg-bounces@ripe.net en nombre de vesely@tana.it> escribió: On Fri 08/May/2020 13:28:10 +0200 JORDI PALET MARTINEZ via anti-abuse-wg wrote: > Hi Alessandro, > > As I've indicated already several times (and not just in this discussion), all the RIRs have forms or other methods to escalate any issues. > > The proposal is only changing "let's have stats". I read: 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. https://www.ripe.net/participate/policies/proposals/2019-04 The anonymized statistics is mentioned afterward. It seems to result from community escalation and reporting, rather than from the abuse-mailbox validation itself. By my proposal, instead, the output of the validation process is borne out when the abuse address is removed from the database —and the corresponding IP ranges duly transmitted. [Jordi] Yes, RIPE provide stats for many things and probably this text is not really needed, but if we want to make sure to have this specific set of stats, *we need the text*. If we try to reach consensus in what I'm interpreting from your last half of the paragraph, it is very difficult to get consensus, and reclaiming resources must be only done in my opinion, in extreme cases. What cases are already described in https://www.ripe.net/publications/docs/ripe-716, not specific to abuse cases. Best Ale > El 4/5/20 12:29, "anti-abuse-wg en nombre de Alessandro Vesely" <anti-abuse-wg-bounces@ripe.net en nombre de vesely@tana.it> escribió: > > Hi, > > On 29/04/2020 13:22, Gert Doering wrote: > > > > If people *want* to handle abuse reports, they do so today already > > (and if they mess up their mail reception, the NCC will check this today > > already, and let them know). > > > > If people *do not want* to handle abuse reports, this proposal will not > > make them. > > > The above is unquestionable truth. There is a grey area, where a mailbox > doesn't work because of misconfiguration, mailbox full, or similar issues. > Validation might help in those cases. > > However, statements like: > > The “abuse-c:” will be mandatory for all aut-nums > > are in conflict with the unquestionable truth quoted above. Please, allow > abuse-c to be empty! I have to keep a dont-send list of non-responding abuse > addresses. Some 70% of the complaints I would have sent hit that list. It > would be more practical to have an empty abuse-c entry in the first place. > > In addition, having networks without abuse addresses makes them more easily > identifiable. RIPE NCC could compile the relevant IP addresses into an easily > usable format, for example one readable by rbldns. Rather than following-up > and threatening resource revocation, upon repeated validation failures, the > RIPE NCC should just remove the non-working abuse-c entry, thereby adding the > relevant IP addresses to the "no-complaints" list. > > A web form to report bouncing abuse addresses would be useful too. > > > Best > Ale > -- > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ********************************************** > 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. > > > > > ********************************************** 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.
Hi Jordy, On Tue 12/May/2020 11:34:19 +0200 JORDI PALET MARTINEZ via anti-abuse-wg wrote:
El 8/5/20 20:18, "anti-abuse-wg en nombre de Alessandro Vesely" <anti-abuse-wg-bounces@ripe.net en nombre de vesely@tana.it> escribió: On Fri 08/May/2020 13:28:10 +0200 JORDI PALET MARTINEZ via anti-abuse-wg wrote:
As I've indicated already several times (and not just in this discussion), all the RIRs have forms or other methods to escalate any issues.
The proposal is only changing "let's have stats".
I read:
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. https://www.ripe.net/participate/policies/proposals/2019-04
The anonymized statistics is mentioned afterward. It seems to result from community escalation and reporting, rather than from the abuse-mailbox validation itself. By my proposal, instead, the output of the validation process is borne out when the abuse address is removed from the database —and the corresponding IP ranges duly transmitted.
[Jordi] Yes, RIPE provide stats for many things and probably this text is not really needed, but if we want to make sure to have this specific set of stats, *we need the text*. If we try to reach consensus in what I'm interpreting from your last half of the paragraph, it is very difficult to get consensus, and reclaiming resources must be only done in my opinion, in extreme cases. What cases are already described in https://www.ripe.net/publications/docs/ripe-716, not specific to abuse cases.
You misunderstood me. I'm not advocating de-registration of IP resources. I meant to remove just the abuse-c email address, since it does not work. As an alternative, as Àngel noted, there could be a tag saying that the email address is not valid, without actually removing it. Knowing if an abuse team is reachable is much more useful than statistics which onehas to interpret in order to derive the same information. Setting that information has to be done with care, after making sure that the corresponding organization has acknowledged that their abuse-c doesn't work and doesn't seem to be after fixing it. At that point, actions like transmitting the relevant IP ranges to a DNSBL can take place. Such actions are derived from a public database and don't have to be carried out by RIPE NCC. In particular, they imply no termination. Best Ale --
Hi Alessandro, El 12/5/20 19:26, "anti-abuse-wg en nombre de Alessandro Vesely" <anti-abuse-wg-bounces@ripe.net en nombre de vesely@tana.it> escribió: Hi Jordy, On Tue 12/May/2020 11:34:19 +0200 JORDI PALET MARTINEZ via anti-abuse-wg wrote: >> El 8/5/20 20:18, "anti-abuse-wg en nombre de Alessandro Vesely" <anti-abuse-wg-bounces@ripe.net en nombre de vesely@tana.it> escribió: >> On Fri 08/May/2020 13:28:10 +0200 JORDI PALET MARTINEZ via anti-abuse-wg wrote: >>> >>> As I've indicated already several times (and not just in this discussion), all the RIRs have forms or other methods to escalate any issues. >>> >>> The proposal is only changing "let's have stats". >> >> >> I read: >> >> 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. >> https://www.ripe.net/participate/policies/proposals/2019-04 >> >> The anonymized statistics is mentioned afterward. It seems to result from >> community escalation and reporting, rather than from the abuse-mailbox >> validation itself. By my proposal, instead, the output of the validation >> process is borne out when the abuse address is removed from the database —and >> the corresponding IP ranges duly transmitted. > > [Jordi] Yes, RIPE provide stats for many things and probably this text is > not really needed, but if we want to make sure to have this specific set of > stats, *we need the text*. If we try to reach consensus in what I'm > interpreting from your last half of the paragraph, it is very difficult to > get consensus, and reclaiming resources must be only done in my opinion, in > extreme cases. What cases are already described in > https://www.ripe.net/publications/docs/ripe-716, not specific to abuse > cases. You misunderstood me. I'm not advocating de-registration of IP resources. I meant to remove just the abuse-c email address, since it does not work. As an alternative, as Àngel noted, there could be a tag saying that the email address is not valid, without actually removing it. [Jordi] I got your point now, thanks! I think it is more useful instead of removing the address, marking the record as invalid, and this is being done if I recall correctly from RIPE NCC presentations. Because it may be a temporary failure of the address, so *not removing it* may bring it back in a subsequent verification. Of course all this depends on the detailed procedure that RIPE NCC is using, but I don't think having so many operational details is good in a policy, unless (I'm not saying is the case, just speaking in general, and not about this specific policy) RIPE NCC is doing so badly and ignoring the community inputs, that the community can only enforce a specific procedure via a policy proposal - but still needs to reach consensus. In one of my earlier versions of the proposal, I had a detailed "example procedure, not part of the policy text". Knowing if an abuse team is reachable is much more useful than statistics which onehas to interpret in order to derive the same information. Setting that information has to be done with care, after making sure that the corresponding organization has acknowledged that their abuse-c doesn't work and doesn't seem to be after fixing it. [Jordi] I think both are useful to know. Is the address valid/invalid. If valid, is this LIR processing abuse reports or there is information escalated from the community that is not? At that point, actions like transmitting the relevant IP ranges to a DNSBL can take place. Such actions are derived from a public database and don't have to be carried out by RIPE NCC. In particular, they imply no termination. [Jordi] Totally agree. I still think ideally, we should have X-ARF as the single way to do all the abuse reporting. Not sure if this could be also connected to provide feedback to DNSBL, but I'm not convinced RIPE NCC (or any other RIR) could do that ... very difficult to reach consensus on that at the time being. The stats might prove that on the long term and then we can change our minds. Best Ale -- ********************************************** 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.
El mar, 12-05-2020 a las 22:21 +0200, JORDI PALET MARTINEZ via anti- abuse-wg escribió:
You misunderstood me. I'm not advocating de-registration of IP resources. I meant to remove just the abuse-c email address, since it does not work. As an alternative, as Àngel noted, there could be a tag saying that the email address is not valid, without actually removing it.
[Jordi] I got your point now, thanks!
I think it is more useful instead of removing the address, marking the record as invalid, and this is being done if I recall correctly from RIPE NCC presentations.
5.135.48.50is one of such IP addresses. It has as abuse-c abuse@for-ns.com, which is trivially invalid: for- ns.com mail is handled by 10 mail.for-ns.com. mail.for-ns.com has address 176.9.154.142 Yet, there is no mail server on 176.9.154.142:25 Port 43 access provides:
% Information related to '5.135.48.48 - 5.135.48.51'
% Abuse contact for '5.135.48.48 - 5.135.48.51' is 'abuse@for-ns.com' % Abuse-mailbox validation failed. Please refer to ORG-OS3-RIPE for further information.
I am unable to see such piece of information on the RDAP view, though: https://rdap.db.ripe.net/ip/5.135.48.48 Best regards -- INCIBE-CERT - CERT of the Spanish National Cybersecurity Institute https://www.incibe-cert.es/ PGP Keys: https://www.incibe-cert.es/en/what-is-incibe-cert/pgp-public-keys ======================================================================== INCIBE-CERT is the Spanish National CSIRT designated for citizens, private law entities, other entities not included in the subjective scope of application of the "Ley 40/2015, de 1 de octubre, de Régimen Jurídico del Sector Público", as well as digital service providers, operators of essential services and critical operators under the terms of the "Real Decreto-ley 12/2018, de 7 de septiembre, de seguridad de las redes y sistemas de información" that transposes the Directive (EU) 2016/1148 of the European Parliament and of the Council of 6 July 2016 concerning measures for a high common level of security of network and information systems across the Union. ======================================================================== Disclaimer: This message may contain confidential information, within the framework of the corporate Security Management System.If you are not the intended recipient, please notify the sender and delete this message without forwarding or retaining a copy, since any unauthorized use is strictly prohibited by law. ========================================================================
Clearly something that RIPE NCC should improve in their procedures (or at least explain if there is any issue doing so), but I don't think we need to include those procedural details in the policy proposal. What do you think Petrit? Regards, Jordi @jordipalet El 13/5/20 0:46, "anti-abuse-wg en nombre de Ángel González Berdasco" <anti-abuse-wg-bounces@ripe.net en nombre de angel.gonzalez@incibe.es> escribió: El mar, 12-05-2020 a las 22:21 +0200, JORDI PALET MARTINEZ via anti- abuse-wg escribió: > You misunderstood me. I'm not advocating de-registration of IP > resources. I > meant to remove just the abuse-c email address, since it does not > work. As an > alternative, as Àngel noted, there could be a tag saying that the > email address > is not valid, without actually removing it. > > [Jordi] I got your point now, thanks! > > I think it is more useful instead of removing the address, marking > the record as invalid, and this is being done if I recall correctly > from RIPE NCC presentations. 5.135.48.50is one of such IP addresses. It has as abuse-c abuse@for-ns.com, which is trivially invalid: for- ns.com mail is handled by 10 mail.for-ns.com. mail.for-ns.com has address 176.9.154.142 Yet, there is no mail server on 176.9.154.142:25 Port 43 access provides: > % Information related to '5.135.48.48 - 5.135.48.51' > > % Abuse contact for '5.135.48.48 - 5.135.48.51' is 'abuse@for-ns.com' > % Abuse-mailbox validation failed. Please refer to ORG-OS3-RIPE for > further information. I am unable to see such piece of information on the RDAP view, though: https://rdap.db.ripe.net/ip/5.135.48.48 Best regards -- INCIBE-CERT - CERT of the Spanish National Cybersecurity Institute https://www.incibe-cert.es/ PGP Keys: https://www.incibe-cert.es/en/what-is-incibe-cert/pgp-public-keys ======================================================================== INCIBE-CERT is the Spanish National CSIRT designated for citizens, private law entities, other entities not included in the subjective scope of application of the "Ley 40/2015, de 1 de octubre, de Régimen Jurídico del Sector Público", as well as digital service providers, operators of essential services and critical operators under the terms of the "Real Decreto-ley 12/2018, de 7 de septiembre, de seguridad de las redes y sistemas de información" that transposes the Directive (EU) 2016/1148 of the European Parliament and of the Council of 6 July 2016 concerning measures for a high common level of security of network and information systems across the Union. ======================================================================== Disclaimer: This message may contain confidential information, within the framework of the corporate Security Management System.If you are not the intended recipient, please notify the sender and delete this message without forwarding or retaining a copy, since any unauthorized use is strictly prohibited by law. ======================================================================== ********************************************** 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.
Hello Jordi, Allow me to respond as this is a more an operational topic. I agree with you that RIPE policies should provide the general framework, while the RIPE NCC works out the best operational details to apply the policies. In the mentioned example the procedure has worked, as the contact was identified and marked as invalid. Ed has clarified already that after the RIPE 80 meeting, we will work on adding this information also to the RIPE RDAP service. Thank you and Angel once more for bringing this to our attention. Kind regards, Marco Schmidt RIPE NCC On 13/05/2020 09:05, JORDI PALET MARTINEZ via anti-abuse-wg wrote:
Clearly something that RIPE NCC should improve in their procedures (or at least explain if there is any issue doing so), but I don't think we need to include those procedural details in the policy proposal.
What do you think Petrit?
Regards, Jordi @jordipalet
El 13/5/20 0:46, "anti-abuse-wg en nombre de Ángel González Berdasco" <anti-abuse-wg-bounces@ripe.net en nombre de angel.gonzalez@incibe.es> escribió:
El mar, 12-05-2020 a las 22:21 +0200, JORDI PALET MARTINEZ via anti- abuse-wg escribió: > You misunderstood me. I'm not advocating de-registration of IP > resources. I > meant to remove just the abuse-c email address, since it does not > work. As an > alternative, as Àngel noted, there could be a tag saying that the > email address > is not valid, without actually removing it. > > [Jordi] I got your point now, thanks! > > I think it is more useful instead of removing the address, marking > the record as invalid, and this is being done if I recall correctly > from RIPE NCC presentations.
5.135.48.50is one of such IP addresses. It has as abuse-c abuse@for-ns.com, which is trivially invalid: for- ns.com mail is handled by 10 mail.for-ns.com. mail.for-ns.com has address 176.9.154.142 Yet, there is no mail server on 176.9.154.142:25
Port 43 access provides: > % Information related to '5.135.48.48 - 5.135.48.51' > > % Abuse contact for '5.135.48.48 - 5.135.48.51' is 'abuse@for-ns.com' > % Abuse-mailbox validation failed. Please refer to ORG-OS3-RIPE for > further information.
I am unable to see such piece of information on the RDAP view, though: https://rdap.db.ripe.net/ip/5.135.48.48
Best regards
-- INCIBE-CERT - CERT of the Spanish National Cybersecurity Institute https://www.incibe-cert.es/
PGP Keys: https://www.incibe-cert.es/en/what-is-incibe-cert/pgp-public-keys
========================================================================
INCIBE-CERT is the Spanish National CSIRT designated for citizens, private law entities, other entities not included in the subjective scope of application of the "Ley 40/2015, de 1 de octubre, de Régimen Jurídico del Sector Público", as well as digital service providers, operators of essential services and critical operators under the terms of the "Real Decreto-ley 12/2018, de 7 de septiembre, de seguridad de las redes y sistemas de información" that transposes the Directive (EU) 2016/1148 of the European Parliament and of the Council of 6 July 2016 concerning measures for a high common level of security of network and information systems across the Union.
========================================================================
Disclaimer: This message may contain confidential information, within the framework of the corporate Security Management System.If you are not the intended recipient, please notify the sender and delete this message without forwarding or retaining a copy, since any unauthorized use is strictly prohibited by law.
========================================================================
********************************************** 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.
El mié, 13-05-2020 a las 15:11 +0200, Marco Schmidt escribió:
Hello Jordi,
Allow me to respond as this is a more an operational topic.
I agree with you that RIPE policies should provide the general framework, while the RIPE NCC works out the best operational details to apply the policies.
In the mentioned example the procedure has worked, as the contact was identified and marked as invalid. Ed has clarified already that after the RIPE 80 meeting, we will work on adding this information also to the RIPE RDAP service.
Thank you and Angel once more for bringing this to our attention.
Kind regards, Marco Schmidt RIPE NCC
You are welcome, Edward, Marco. I only noticed that such note was missing from rdap when I was going to show here that it an example of contact marked as invalid by RIPE process. Long-term, Alessandro proposal of having a field for tagging the contact status as (probably) not-working seems the way to go (not sure who should propose that to IANA), but storing it in a comment would allow for a quick solution in the interim. Best regards -- INCIBE-CERT - CERT of the Spanish National Cybersecurity Institute https://www.incibe-cert.es/ PGP Keys: https://www.incibe-cert.es/en/what-is-incibe-cert/pgp-public-keys ======================================================================== INCIBE-CERT is the Spanish National CSIRT designated for citizens, private law entities, other entities not included in the subjective scope of application of the "Ley 40/2015, de 1 de octubre, de Régimen Jurídico del Sector Público", as well as digital service providers, operators of essential services and critical operators under the terms of the "Real Decreto-ley 12/2018, de 7 de septiembre, de seguridad de las redes y sistemas de información" that transposes the Directive (EU) 2016/1148 of the European Parliament and of the Council of 6 July 2016 concerning measures for a high common level of security of network and information systems across the Union. ========================================================================
Hello Ángel, WG,
On 13 May 2020, at 00:45, Ángel González Berdasco <angel.gonzalez@incibe.es> wrote:
...
5.135.48.50is one of such IP addresses. It has as abuse-c abuse@for-ns.com, which is trivially invalid: for- ns.com mail is handled by 10 mail.for-ns.com. mail.for-ns.com has address 176.9.154.142 Yet, there is no mail server on 176.9.154.142:25
Port 43 access provides:
% Information related to '5.135.48.48 - 5.135.48.51'
% Abuse contact for '5.135.48.48 - 5.135.48.51' is 'abuse@for-ns.com' % Abuse-mailbox validation failed. Please refer to ORG-OS3-RIPE for further information.
I am unable to see such piece of information on the RDAP view, though: https://rdap.db.ripe.net/ip/5.135.48.48
You are correct: the RIPE RDAP service returns the abuse-c contact as an entity under an IP object, but not the "validation failed" comment. We will add this comment as a "remarks" data structure within the IP object: https://tools.ietf.org/html/rfc7483#section-4.3 We plan to work on the RDAP functionality after the RIPE 80 meeting, we will include this change. Thanks for bring this omission to our attention. Regards Ed Shryane RIPE NCC
Hi Jordy, On Tue 12/May/2020 22:21:11 +0200 JORDI PALET MARTINEZ via anti-abuse-wg wrote:
El 12/5/20 19:26, "anti-abuse-wg en nombre de Alessandro Vesely" <anti-abuse-wg-bounces@ripe.net en nombre de vesely@tana.it> escribió:
I think it is more useful instead of removing the address, marking the record as invalid, and this is being done if I recall correctly from RIPE NCC presentations. Because it may be a temporary failure of the address, so *not removing it* may bring it back in a subsequent verification.
If at all possible, I'd suggest to register a suitable RDAP JSON value for the relevant remark type, at IANA[*]. That would allow automated tools to discard the corresponding vcard entry. ARIN write a remark, like so: "remarks" : [ { "description" : [ "ARIN has attempted to validate the data for this POC, but has received no response from the POC since 2011-06-07" ], "title" : "Unvalidated POC" } ], Such remark is not quite actionable, as it doesn't say which POC does not work (recall there are various arrays of vcards, only some of which are tagged with the "abuse" role.) Perhaps more importantly, it doesn't say if the invalid nature of the mailbox was notified to the responsible organization, and such notification acknowledged.
[Jordi] I think both [actual validity and statistics] are useful to know. Is the address valid/invalid. If valid, is this LIR processing abuse reports or there is information escalated from the community that is not?
The latter datum is much more difficult to get right. I'd stick with an invalid mark. If, say, email messages bounced since 2011, and the organization was promptly notified and shrugged, a loud and clear mark is well deserved.
[Jordi] Totally agree. I still think ideally, we should have X-ARF as the single way to do all the abuse reporting. Not sure if this could be also connected to provide feedback to DNSBL, but I'm not convinced RIPE NCC (or any other RIR) could do that ... very difficult to reach consensus on that at the time being. The stats might prove that on the long term and then we can change our minds.
The format, like the actual handling of reports, is one or more levels above. As for a DNSBL, I keep reading that most data in the RIPE Database is public. Are there API to browse its content? Is it possible to maintain a (filtered) copy of it? If one could collect all the blocks whose abuse-c is marked as invalid, she could then run a corresponding DNSBL. However, article 3 of the Terms and Conditions for Data Access[†] seems to disallow just that. Best Ale -- [*] https://www.iana.org/assignments/rdap-json-values/rdap-json-values.xhtml [†] https://labs.ripe.net/datarepository/conditions/basic
Hi Alessandro, I just read Marco response to this thread (Marco thanks for the quick reaction on it!), and also Angel response (so to avoid answering to several emails about the same). I guess all your other inputs are also relevant for the NCC. In principle, I don't think all that should be part of the policy proposal, but if the NCC seems otherwise, I'm happy to work with you/Angel/others to make sure that we have captured correctly that and see what the WG believes. Thanks! Regards, Jordi @jordipalet El 13/5/20 13:02, "anti-abuse-wg en nombre de Alessandro Vesely" <anti-abuse-wg-bounces@ripe.net en nombre de vesely@tana.it> escribió: Hi Jordy, On Tue 12/May/2020 22:21:11 +0200 JORDI PALET MARTINEZ via anti-abuse-wg wrote: > El 12/5/20 19:26, "anti-abuse-wg en nombre de Alessandro Vesely" <anti-abuse-wg-bounces@ripe.net en nombre de vesely@tana.it> escribió: > > I think it is more useful instead of removing the address, marking the > record as invalid, and this is being done if I recall correctly from RIPE > NCC presentations. Because it may be a temporary failure of the address, so > *not removing it* may bring it back in a subsequent verification. If at all possible, I'd suggest to register a suitable RDAP JSON value for the relevant remark type, at IANA[*]. That would allow automated tools to discard the corresponding vcard entry. ARIN write a remark, like so: "remarks" : [ { "description" : [ "ARIN has attempted to validate the data for this POC, but has received no response from the POC since 2011-06-07" ], "title" : "Unvalidated POC" } ], Such remark is not quite actionable, as it doesn't say which POC does not work (recall there are various arrays of vcards, only some of which are tagged with the "abuse" role.) Perhaps more importantly, it doesn't say if the invalid nature of the mailbox was notified to the responsible organization, and such notification acknowledged. > [Jordi] I think both [actual validity and statistics] are useful to know. Is > the address valid/invalid. If valid, is this LIR processing abuse reports or > there is information escalated from the community that is not? The latter datum is much more difficult to get right. I'd stick with an invalid mark. If, say, email messages bounced since 2011, and the organization was promptly notified and shrugged, a loud and clear mark is well deserved. > [Jordi] Totally agree. I still think ideally, we should have X-ARF as the > single way to do all the abuse reporting. Not sure if this could be also > connected to provide feedback to DNSBL, but I'm not convinced RIPE NCC (or > any other RIR) could do that ... very difficult to reach consensus on that > at the time being. The stats might prove that on the long term and then we > can change our minds. The format, like the actual handling of reports, is one or more levels above. As for a DNSBL, I keep reading that most data in the RIPE Database is public. Are there API to browse its content? Is it possible to maintain a (filtered) copy of it? If one could collect all the blocks whose abuse-c is marked as invalid, she could then run a corresponding DNSBL. However, article 3 of the Terms and Conditions for Data Access[†] seems to disallow just that. Best Ale -- [*] https://www.iana.org/assignments/rdap-json-values/rdap-json-values.xhtml [†] https://labs.ripe.net/datarepository/conditions/basic ********************************************** 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.
Dear colleagues, The proposer has alerted us to a mistake in the “Draft Document” prepared for policy proposal 2019-04: https://www.ripe.net/participate/policies/proposals/2019-04/draft The “Additional information” section in the draft document is part of the proposal and should not be included in the actual policy text. We will update the draft document to remove this section. This means that this section would not be part of the policy text if the proposal is accepted. Please note that the policy proposal itself is not changed - the "Additional information" section remains a part of the proposal: https://www.ripe.net/participate/policies/proposals/2019-04 Kind regards, -- Petrit Hasani Policy Officer RIPE NCC
On 28 Apr 2020, at 16:01, Petrit Hasani <phasani@ripe.net> wrote:
Dear colleagues,
A new version of RIPE policy proposal, 2019-04, "Validation of "abuse-mailbox"", is now available for discussion.
This proposal aims to have the RIPE NCC validate "abuse-c:" information more often and introduces a new validation process.
Most of the text has been rewritten following the last round of discussion and the proposal is now at version 3.0. Some key points in this version:
- The abuse-mailbox should not force the sender to use a form - The validation process must ensure that the abuse mailbox is able to receive messages - The validation should happen at least every six months
You can find the full proposal at: https://www.ripe.net/participate/policies/proposals/2019-04
As per the RIPE Policy Development Process (PDP), the purpose of this four-week Discussion Phase is to discuss the proposal and provide feedback to the proposer.
At the end of the Discussion Phase, the proposer, with the agreement of the Anti-Abuse Working Group Chairs, will decide how to proceed with the proposal.
We encourage you to review this proposal and send your comments to <anti-abuse-wg@ripe.net> before 27 May 2020.
Kind regards, -- Petrit Hasani Policy Officer RIPE NCC
Hi Petrit, all, Thanks a lot for the clarification. I only discovered that once I was working on the slide for tomorrow, as during the previous days discussion I always used my original word proposal document. I had the feeling that some of the points that we discussed in the last days were misunderstood because there was a "reinforcement or duplication" of the policy text, while it was meant as a clarification. I will make sure to clarify it tomorrow during the WG presentation. Regards, Jordi @jordipalet El 13/5/20 17:58, "anti-abuse-wg en nombre de Petrit Hasani" <anti-abuse-wg-bounces@ripe.net en nombre de phasani@ripe.net> escribió: Dear colleagues, The proposer has alerted us to a mistake in the “Draft Document” prepared for policy proposal 2019-04: https://www.ripe.net/participate/policies/proposals/2019-04/draft The “Additional information” section in the draft document is part of the proposal and should not be included in the actual policy text. We will update the draft document to remove this section. This means that this section would not be part of the policy text if the proposal is accepted. Please note that the policy proposal itself is not changed - the "Additional information" section remains a part of the proposal: https://www.ripe.net/participate/policies/proposals/2019-04 Kind regards, -- Petrit Hasani Policy Officer RIPE NCC > On 28 Apr 2020, at 16:01, Petrit Hasani <phasani@ripe.net> wrote: > > Dear colleagues, > > A new version of RIPE policy proposal, 2019-04, "Validation of > "abuse-mailbox"", is now available for discussion. > > This proposal aims to have the RIPE NCC validate "abuse-c:" information > more often and introduces a new validation process. > > Most of the text has been rewritten following the last round of > discussion and the proposal is now at version 3.0. Some key points in > this version: > > - The abuse-mailbox should not force the sender to use a form > - The validation process must ensure that the abuse mailbox is able to > receive messages > - The validation should happen at least every six months > > You can find the full proposal at: > https://www.ripe.net/participate/policies/proposals/2019-04 > > As per the RIPE Policy Development Process (PDP), the purpose of this > four-week Discussion Phase is to discuss the proposal and provide > feedback to the proposer. > > At the end of the Discussion Phase, the proposer, with the agreement of > the Anti-Abuse Working Group Chairs, will decide how to proceed with the > proposal. > > We encourage you to review this proposal and send your comments to > <anti-abuse-wg@ripe.net> before 27 May 2020. > > Kind regards, > -- > Petrit Hasani > Policy Officer > RIPE NCC > > > > > ********************************************** 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.
participants (17)
-
Alessandro Vesely -
Carlos Friaças -
Edward Shryane -
Gert Doering -
Job Snijders -
JORDI PALET MARTINEZ -
Marco Schmidt -
Michele Neylon - Blacknight -
Nick Hilliard -
No No -
Petrit Hasani -
Randy Bush -
Rob Evans -
Sascha Luck [ml] -
Serge Droz -
Suresh Ramasubramanian -
Ángel González Berdasco