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

Re: [anti-abuse-wg] [policy-announce] 2017-02 Review Phase (Regular abuse-c Validation)
by Name 24 Jan '18

24 Jan '18

1 0

Re: [anti-abuse-wg] [policy-announce] 2017-02 Review Phase (Regular abuse-c Validation)
by Wolfgang Tremmel 24 Jan '18

24 Jan '18

Do you want to solve a problem or create one? I can imagine as the "click here and solve captcha" emails will be standardized that a carefully crafted attack might lure fist line helpdesk people onto shady websides and making them click stuff. So if I were a helpdesk manager I would order my team not to click on these.... IMHO the policy should only check if emails to the abuse contact are delivered, which can bei done with some HELO, MAIL FROM and RCPT TO magic on port 25. best regards Wolfgang > On 19. Jan 2018, at 10:58, ox <andre(a)ox.co.za> wrote: > > you mean in practical "real life" work? > > practically, abuse admins and people that actually deal with abuse are > able to solve a capcha and tick a box. -- Wolfgang Tremmel Phone +49 69 1730902 26 | Fax +49 69 4056 2716 | Mobile +49 171 8600 816 | wolfgang.tremmel(a)de-cix.net Geschaeftsfuehrer Harald A. Summa | Registergericht AG Köln HRB 51135 DE-CIX Management GmbH | Lindleystrasse 12 | 60314 Frankfurt am Main | Germany | www.de-cix.net

11 24

2017-02 Review Phase (Regular abuse-c Validation)
by Marco Schmidt 24 Jan '18

24 Jan '18

Dear colleagues, Policy proposal 2017-02, "Regular abuse-c Validation" is now in the Review Phase. The goal of this proposal is to give the RIPE NCC a mandate to regularly validate "abuse-c:" information and to follow up in cases where the attribute is deemed to be incorrect. This proposal has been updated following the last round of discussion and is now at version v2.0. Some of the differences from version v1.0 include: - A focus on validating the "abuse-mailbox:" attribute and fixing incorrect contact information - Added references to RIPE Policies and RIPE NCC procedures The RIPE NCC has prepared an impact analysis on this latest proposal version to support the community’s discussion. You can find the full proposal and impact analysis at: https://www.ripe.net/participate/policies/proposals/2017-02 And the draft documents at: https://www.ripe.net/participate/policies/proposals/2017-02/draft As per the RIPE Policy Development Process (PDP), the purpose of this four-week Review Phase is to continue discussing the proposal, taking the impact analysis into consideration, and to review the full draft policy document. At the end of the Review Phase, the WG Chairs will determine whether the WG has reached rough consensus. It is therefore important to provide your opinion, even if it is simply a restatement of your input from the previous phase. We encourage you to read the proposal, impact analysis and draft document, and share your comments on <anti-abuse-wg(a)ripe.net> before 16 February 2018. Kind regards, Marco Schmidt Policy Development Officer RIPE NCC Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum

7 6

Re: [anti-abuse-wg] [policy-announce] 2017-02 Review Phase (Regular abuse-c Validation)
by Name 24 Jan '18

24 Jan '18

2 1

Re: [anti-abuse-wg] [policy-announce] 2017-02 Review Phase (Regular abuse-c Validation)
by Name 23 Jan '18

23 Jan '18

2 1

Re: [anti-abuse-wg] [policy-announce] 2017-02 Review Phase (Regular abuse-c Validation)
by Name 23 Jan '18

23 Jan '18

2 1

Re: [anti-abuse-wg] [policy-announce] 2017-02 Review Phase (Regular abuse-c Validation)
by Sascha Luck [ml] 23 Jan '18

23 Jan '18

On Mon, Jan 22, 2018 at 04:45:43PM +0200, ox wrote: >> Have I made myself sufficiently clear? >> >Not really. Right. I will then re-iterate all of my arguments including the ones against v1. 1) The proposal states: "Improving the trust and safety of the IP address space is a priority for the RIPE community. It has therefore established the Assisted Registry Check (ARC) in order to help its members strengthen registry data by explaining the risks of outdated information and the benefits of ensuring their data is correct. ARC reviews are carried out for approximately 25%-30% of the membership every year and cover four subject areas: registry consistency, resource consistency, route/rDNS consistency and resource certification usage/consistency (RPKI). However, the ARC was not designed for the validation of the “abuse-c:” contact." While the ARC was not specifically designed to validate the correctness of abuse-c, it is *suitable* for the purpose. I disagree with the implication that the ARC can't be used to perform this validation. In my view, nothing makes abuse-c: any more special than admin-c: and tech-c:, so that it needs a separate ARC all of its own 2) The proposal states: "The objective of this proposal is not to devise a detailed validation procedure. The RIPE NCC is best placed to assess the technical challenges and the financial and human resources necessary to conduct validation tests in the most efficient manner." This actually makes the entire discussion around captchas and humans wasting their time with reading abuse-c emails redundant. Nothing of the kind of process you're dreaming about is actually part of the proposal, so I will forgo any further discussion on this unless a new implementation proposal comes along. What you have is a problem with the Impact Assessment and the way the NCC proposes to validate this contact. In fact, on this point alone, *I* should support the proposal and *you* should oppose it. (However, since I'm not sure the implementation process cannot just change without my consent, I still oppose it on this point, too) 3) Not explicitly stated in the proposal. The proposal and the IA assume that the abuse-c: is an email address (and the object, iirc explicitly asks for one). I don't think any new policy should be made that, even implicitly, ties RIPE NCC database information to legacy technologies. rgds, Sascha Luck

3 3

Re: [anti-abuse-wg] [policy-announce] 2017-02 Review Phase (Regular abuse-c Validation)
by Sascha Luck [ml] 22 Jan '18

22 Jan '18

On Mon, Jan 22, 2018 at 03:56:05PM +0200, ox wrote: >so, still, there has been no objections to the verification process - >if you have an objection to the process or would like to contribute an >improvement, please do so Sascha? OK, so for the avoidance of doubt among the trolls and the rules lawyers: 1) I object to the verification process proposals as floated on this list and i 2) I stand by my interpretation of the IA as stating that the NCC has no mandate to impose arbitrary hoops on members to jump through. Have I made myself sufficiently clear? On a further note, there is a discussion in the DB-WG with the goal of enabling delegation of more specific abuse-c for assigned or sub-allocated resources. The verification process, if implemented, should take care not to conflict with this. rgds, Sascha Luck

2 1

Re: [anti-abuse-wg] [policy-announce] 2017-02 Review Phase (Regular abuse-c Validation)
by Sascha Luck [ml] 22 Jan '18

22 Jan '18

On Mon, Jan 22, 2018 at 03:42:09PM +0200, ox wrote: >I have not seen any objections to the process of emailing a alpha >numeric number to abuse-c and then having that number entered into a >website (after solving a capcha) >This would solve many problems as it would mean that the abuse-c exists >and is functional and not an auto-responder or other bot Did my email somehow not make it to the list? I believe I clearly objected to anything of this sort. And, moreover, the IA clearly states that the NCC has *no* mandate to prescribe to operators how they handle abuse email. Additionally, the "community" has no mandate to prescribe to the NCC exactly how to implement a policy - this is a contractual matter. rgds, Sascha Luck

2 1

Re: [anti-abuse-wg] [policy-announce] 2017-02 Review Phase (Regular abuse-c Validation)
by Name 20 Jan '18

20 Jan '18

2 2

Re: [anti-abuse-wg] [policy-announce] 2017-02 Review Phase (Regular abuse-c Validation)
by Name 20 Jan '18

20 Jan '18

1 0

Re: [anti-abuse-wg] [policy-announce] 2017-02 Review Phase (Regular abuse-c Validation)
by JORDI PALET MARTINEZ 19 Jan '18

19 Jan '18

I fully agree with this proposal and should be implemented ASAP. HOWEVER, I’ve a question regarding the impact analysis, and specially this sentence: “To increase efficiency, this process will use an automated solution that will allow the validation of “abuse-mailbox:” attributes without sending an email. No action will be needed by resource holders that have configured their “abuse-mailbox:” attribute correctly.” Reading the policy proposal, how the NCC concludes that it should be “without sending an email”? I will say that the right way to do a validation (at creation/modification and yearly) is, in a way that makes sense (having an email that nobody is processing is exactly the same as not having the abuse attribute at all): 1) Send an email with a link that must be clicked by a human (so some kind of captcha-like mechanism should be followed) 2) If this link is not clicked in a period of 48 hours (not including Saturday-Sunday), an alarm should be generated so the NCC can take the relevant actions and make sure that the mailbox is actively monitored by the LIR Regards, Jordi -----Mensaje original----- De: policy-announce <policy-announce-bounces(a)ripe.net> en nombre de Marco Schmidt <mschmidt(a)ripe.net> Fecha: jueves, 18 de enero de 2018, 12:23 Para: <policy-announce(a)ripe.net> Asunto: [policy-announce] 2017-02 Review Phase (Regular abuse-c Validation) Dear colleagues, Policy proposal 2017-02, "Regular abuse-c Validation" is now in the Review Phase. The goal of this proposal is to give the RIPE NCC a mandate to regularly validate "abuse-c:" information and to follow up in cases where the attribute is deemed to be incorrect. This proposal has been updated following the last round of discussion and is now at version v2.0. Some of the differences from version v1.0 include: - A focus on validating the "abuse-mailbox:" attribute and fixing incorrect contact information - Added references to RIPE Policies and RIPE NCC procedures The RIPE NCC has prepared an impact analysis on this latest proposal version to support the community’s discussion. You can find the full proposal and impact analysis at: https://www.ripe.net/participate/policies/proposals/2017-02 And the draft documents at: https://www.ripe.net/participate/policies/proposals/2017-02/draft As per the RIPE Policy Development Process (PDP), the purpose of this four-week Review Phase is to continue discussing the proposal, taking the impact analysis into consideration, and to review the full draft policy document. At the end of the Review Phase, the WG Chairs will determine whether the WG has reached rough consensus. It is therefore important to provide your opinion, even if it is simply a restatement of your input from the previous phase. We encourage you to read the proposal, impact analysis and draft document, and share your comments on <anti-abuse-wg(a)ripe.net> <mailto:anti-abuse-wg@ripe.net> before 16 February 2018. Kind regards, Marco Schmidt Policy Development Officer RIPE NCC ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.

7 10

[FWD: Re: [policy-announce] 2017-02 Review Phase (Regular abuse-c Validation)]
by Name 19 Jan '18

19 Jan '18

2 1

Re: [anti-abuse-wg] 2017-02 Review Phase (Regular abuse-c Validation)
by Name 19 Jan '18

19 Jan '18

1 0

Re: [anti-abuse-wg] [policy-announce] 2017-02 Review Phase (Regular abuse-c Validation)
by JORDI PALET MARTINEZ 19 Jan '18

19 Jan '18

Agree. What I care is people reporting abuses and never getting the problem solved. If you are an LIR you're responsible for possible abuses to third parties, and you must respond to them. Your cost for resolving those abuses is your problem, because is your organization who takes advantage of whatever income for that you have. What you can't do is to ask the rest of the Internet to support the cost for you, by not responding to abuses, or asking the rest of the world to fill-in your form instead of allowing automated abuse reporting systems, which work by email (example, fail2ban), unless we define a world-wide standard web form for reporting abuses, instead of doing that by email. Regards, Jordi -----Mensaje original----- De: anti-abuse-wg <anti-abuse-wg-bounces(a)ripe.net> en nombre de ox <andre(a)ox.co.za> Organización: ox.co.za Fecha: viernes, 19 de enero de 2018, 10:58 Para: Wolfgang Tremmel <wolfgang.tremmel(a)de-cix.net> CC: "anti-abuse-wg(a)ripe.net" <anti-abuse-wg(a)ripe.net> Asunto: Re: [anti-abuse-wg] [policy-announce] 2017-02 Review Phase (Regular abuse-c Validation) On Fri, 19 Jan 2018 09:42:09 +0000 Wolfgang Tremmel <wolfgang.tremmel(a)de-cix.net> wrote: > I support this policy and IMHO an automated check is "good enough" > If someone asks how this could be done I suggest reading rfc2821 > > IMHO requiring human interaction would deliver too many "false > negatives". People suggesting a captcha I guess have never worked at > a helpdesk or in any customer support function.... > you mean in practical "real life" work? practically, abuse admins and people that actually deal with abuse are able to solve a capcha and tick a box. what this will prevent (to a certain degree) are 'automated' bots that exist simply to prove that something exists and not that something is actually attended to or is "real" (as in rfc2821 is so not relevant to the objective of the policy and the existence of a functional abuse@ as all an rfc2821 check will do is tell you that abuse@ can accept email many abuse-c addresses accept email (so an rfc2821 check will work) and then the mailbox responds: "this is an unattended mailbox and your email may never be seen or read by a human person. If you want to report abuse, please visit our website and click on "support" to ask a question in our forums" - or some similar drivel. Regards Andre > best regards > Wolfgang > > > On 18. Jan 2018, at 12:20, Marco Schmidt <mschmidt(a)ripe.net> wrote: > > > > Dear colleagues, > > > > Policy proposal 2017-02, "Regular abuse-c Validation" is now in the > > Review Phase. > ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.

1 0

Re: [anti-abuse-wg] [policy-announce] 2017-02 Review Phase (Regular abuse-c Validation)
by Michele Neylon - Blacknight 19 Jan '18

19 Jan '18

+1 Who cares what the email address / alias / forwarder / mailbox looks like -- Mr Michele Neylon Blacknight Solutions Hosting, Colocation & Domains https://www.blacknight.com/ https://blacknight.blog/ https://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 19/01/2018, 09:47, "anti-abuse-wg on behalf of ox" <anti-abuse-wg-bounces(a)ripe.net on behalf of andre(a)ox.co.za> wrote: not sure that I know of any abuse@ email that is privacy.85o8095.849804938(a)example.com (the privacy.xxx domain may exist and be a real domain - as such the "privacy.85o8095.849804938(a)privacy.xxx" you used, in your example, may actually belong to someone...) But quick question: who decides what email address is "real" and what is not "real" If an abuse@ uses privacy.85o8095.849804938(a)example.com then receives email and solves a capcha and then clicks a tickbox - the email address is functional / working and "real" ??? Regards Andre On Fri, 19 Jan 2018 10:40:40 +0100 JORDI PALET MARTINEZ via anti-abuse-wg <anti-abuse-wg(a)ripe.net> wrote: > One more thing I just realized ... > > I understand that the mailbox must be a "real" one, not the typical > "privacy.85o8095.849804938(a)privacy.xxx" that is used often in whois > data ... > > Regards, > Jordi > > -----Mensaje original----- > De: anti-abuse-wg <anti-abuse-wg-bounces(a)ripe.net> en nombre de ox > <andre(a)ox.co.za> Organización: ox.co.za > Fecha: viernes, 19 de enero de 2018, 10:37 > Para: <anti-abuse-wg(a)ripe.net> > Asunto: Re: [anti-abuse-wg] [policy-announce] 2017-02 Review Phase > (Regular abuse-c Validation) > > > Yes, the idea Thomas had about human interaction, solving a > captcha and a tickbox is a great idea > my 1c > > Andre > > On Fri, 19 Jan 2018 10:29:42 +0100 > JORDI PALET MARTINEZ via anti-abuse-wg <anti-abuse-wg(a)ripe.net> > wrote: > > I also think that Thomas suggestion of a checkbox agreeing with > > regularly monitoring the abuse-mailbox is a wonderful > > suggestion. Regards, > > Jordi > > Para: <anti-abuse-wg(a)ripe.net> > > Asunto: Re: [anti-abuse-wg] [policy-announce] 2017-02 Review > > Phase (Regular abuse-c Validation) > > I support the proposal in general and i also think a human > > interaction of the resource holder is required. > > > > Am 19.01.18 um 09:52 schrieb Thomas Hungenberg: > > > I second Jordi's opinion that validation of the > > > abuse-mailbox should require human interaction of the > > > resource holder. In addition to solving a captcha the > > > resource holder might need to confirm (click a checkbox) > > > that he will monitor the abuse-mailbox account on a > > > regular basis and take appropriate action to solve > > > reported abuse cases. > > > > > > > > > - Thomas > > > > > > CERT-Bund Incident Response & Malware Analysis Team > > > > > > > > > On 18.01.2018 19:44, JORDI PALET MARTINEZ via > > > anti-abuse-wg wrote: > > >> I fully agree with this proposal and should be > > >> implemented ASAP. > > >> > > >> HOWEVER, I’ve a question regarding the impact analysis, > > >> and specially this sentence: > > >> > > >> “To increase efficiency, this process will use an > > >> automated solution that will allow the validation of > > >> “abuse-mailbox:” attributes without sending an email. No > > >> action will be needed by resource holders that have > > >> configured their “abuse-mailbox:” attribute correctly.” > > >> > > >> Reading the policy proposal, how the NCC concludes that > > >> it should be “without sending an email”? > > >> > > >> I will say that the right way to do a validation (at > > >> creation/modification and yearly) is, in a way that makes > > >> sense (having an email that nobody is processing is > > >> exactly the same as not having the abuse attribute at > > >> all): 1) Send an email with a link that must be clicked > > >> by a human (so some kind of captcha-like mechanism > > >> should be followed) 2) If this link is not clicked in a > > >> period of 48 hours (not including Saturday-Sunday), an > > >> alarm should be generated so the NCC can take the > > >> relevant actions and make sure that the mailbox is > > >> actively monitored by the LIR > > >> > > >> Regards, > > >> Jordi > > > > > > > -- > > Mit freundlichem Gruß > > > > Artfiles New Media GmbH > > > > Andreas Worbs > > > > > > Artfiles New Media GmbH | Zirkusweg 1 | 20359 Hamburg > > Tel: 040 - 32 02 72 90 | Fax: 040 - 32 02 72 95 > > E-Mail: support(a)artfiles.de | Web: http://www.artfiles.de > > Geschäftsführer: Harald Oltmanns | Tim Evers > > Eingetragen im Handelsregister Hamburg - HRB 81478 > > > > > > > > > > > > > > ********************************************** > > IPv4 is over > > Are you ready for the new Internet ? > > http://www.consulintel.es > > The IPv6 Company > > > > This electronic message contains information which may be > > privileged or confidential. The information is intended to be > > for the exclusive use of the individual(s) named above and > > further non-explicilty authorized disclosure, copying, > > distribution or use of the contents of this information, even > > if partially, including attached files, is strictly prohibited > > and will be considered a criminal offense. If you are not the > > intended recipient be aware that any disclosure, copying, > > distribution or use of the contents of this information, even > > if partially, including attached files, is strictly prohibited, > > will be considered a criminal offense, so you must reply to the > > original sender to inform about this communication and delete > > it. > > > > > > > > > > > > > > > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.consulintel.es > The IPv6 Company > > This electronic message contains information which may be privileged > or confidential. The information is intended to be for the exclusive > use of the individual(s) named above and further non-explicilty > authorized disclosure, copying, distribution or use of the contents > of this information, even if partially, including attached files, is > strictly prohibited and will be considered a criminal offense. If you > are not the intended recipient be aware that any disclosure, copying, > distribution or use of the contents of this information, even if > partially, including attached files, is strictly prohibited, will be > considered a criminal offense, so you must reply to the original > sender to inform about this communication and delete it. > > > > >

1 0

Re: [anti-abuse-wg] [policy-announce] 2017-02 Review Phase (Regular abuse-c Validation)
by Wolfgang Tremmel 19 Jan '18

19 Jan '18

I support this policy and IMHO an automated check is "good enough" If someone asks how this could be done I suggest reading rfc2821 IMHO requiring human interaction would deliver too many "false negatives". People suggesting a captcha I guess have never worked at a helpdesk or in any customer support function.... best regards Wolfgang > On 18. Jan 2018, at 12:20, Marco Schmidt <mschmidt(a)ripe.net> wrote: > > Dear colleagues, > > Policy proposal 2017-02, "Regular abuse-c Validation" is now in the Review Phase. > -- Wolfgang Tremmel Phone +49 69 1730902 26 | Fax +49 69 4056 2716 | Mobile +49 171 8600 816 | wolfgang.tremmel(a)de-cix.net Geschaeftsfuehrer Harald A. Summa | Registergericht AG Köln HRB 51135 DE-CIX Management GmbH | Lindleystrasse 12 | 60314 Frankfurt am Main | Germany | www.de-cix.net

2 1

Re: [anti-abuse-wg] [policy-announce] 2017-02 Review Phase (Regular abuse-c Validation)
by JORDI PALET MARTINEZ 19 Jan '18

19 Jan '18

You're right, if we opt for some human interaction, never mind is using a privacy service, but it doesn't make sense to me that a privacy service is used for this kind of email, so I will strongly suggest to have some wording that "exclude privacy whois services for this abuse contact". Regards, Jordi -----Mensaje original----- De: anti-abuse-wg <anti-abuse-wg-bounces(a)ripe.net> en nombre de ox <andre(a)ox.co.za> Organización: ox.co.za Fecha: viernes, 19 de enero de 2018, 10:47 Para: JORDI PALET MARTINEZ via anti-abuse-wg <anti-abuse-wg(a)ripe.net> Asunto: Re: [anti-abuse-wg] [policy-announce] 2017-02 Review Phase (Regular abuse-c Validation) not sure that I know of any abuse@ email that is privacy.85o8095.849804938(a)example.com (the privacy.xxx domain may exist and be a real domain - as such the "privacy.85o8095.849804938(a)privacy.xxx" you used, in your example, may actually belong to someone...) But quick question: who decides what email address is "real" and what is not "real" If an abuse@ uses privacy.85o8095.849804938(a)example.com then receives email and solves a capcha and then clicks a tickbox - the email address is functional / working and "real" ??? Regards Andre On Fri, 19 Jan 2018 10:40:40 +0100 JORDI PALET MARTINEZ via anti-abuse-wg <anti-abuse-wg(a)ripe.net> wrote: > One more thing I just realized ... > > I understand that the mailbox must be a "real" one, not the typical > "privacy.85o8095.849804938(a)privacy.xxx" that is used often in whois > data ... > > Regards, > Jordi > > -----Mensaje original----- > De: anti-abuse-wg <anti-abuse-wg-bounces(a)ripe.net> en nombre de ox > <andre(a)ox.co.za> Organización: ox.co.za > Fecha: viernes, 19 de enero de 2018, 10:37 > Para: <anti-abuse-wg(a)ripe.net> > Asunto: Re: [anti-abuse-wg] [policy-announce] 2017-02 Review Phase > (Regular abuse-c Validation) > > > Yes, the idea Thomas had about human interaction, solving a > captcha and a tickbox is a great idea > my 1c > > Andre > > On Fri, 19 Jan 2018 10:29:42 +0100 > JORDI PALET MARTINEZ via anti-abuse-wg <anti-abuse-wg(a)ripe.net> > wrote: > > I also think that Thomas suggestion of a checkbox agreeing with > > regularly monitoring the abuse-mailbox is a wonderful > > suggestion. Regards, > > Jordi > > Para: <anti-abuse-wg(a)ripe.net> > > Asunto: Re: [anti-abuse-wg] [policy-announce] 2017-02 Review > > Phase (Regular abuse-c Validation) > > I support the proposal in general and i also think a human > > interaction of the resource holder is required. > > > > Am 19.01.18 um 09:52 schrieb Thomas Hungenberg: > > > I second Jordi's opinion that validation of the > > > abuse-mailbox should require human interaction of the > > > resource holder. In addition to solving a captcha the > > > resource holder might need to confirm (click a checkbox) > > > that he will monitor the abuse-mailbox account on a > > > regular basis and take appropriate action to solve > > > reported abuse cases. > > > > > > > > > - Thomas > > > > > > CERT-Bund Incident Response & Malware Analysis Team > > > > > > > > > On 18.01.2018 19:44, JORDI PALET MARTINEZ via > > > anti-abuse-wg wrote: > > >> I fully agree with this proposal and should be > > >> implemented ASAP. > > >> > > >> HOWEVER, I’ve a question regarding the impact analysis, > > >> and specially this sentence: > > >> > > >> “To increase efficiency, this process will use an > > >> automated solution that will allow the validation of > > >> “abuse-mailbox:” attributes without sending an email. No > > >> action will be needed by resource holders that have > > >> configured their “abuse-mailbox:” attribute correctly.” > > >> > > >> Reading the policy proposal, how the NCC concludes that > > >> it should be “without sending an email”? > > >> > > >> I will say that the right way to do a validation (at > > >> creation/modification and yearly) is, in a way that makes > > >> sense (having an email that nobody is processing is > > >> exactly the same as not having the abuse attribute at > > >> all): 1) Send an email with a link that must be clicked > > >> by a human (so some kind of captcha-like mechanism > > >> should be followed) 2) If this link is not clicked in a > > >> period of 48 hours (not including Saturday-Sunday), an > > >> alarm should be generated so the NCC can take the > > >> relevant actions and make sure that the mailbox is > > >> actively monitored by the LIR > > >> > > >> Regards, > > >> Jordi > > > > > > > -- > > Mit freundlichem Gruß > > > > Artfiles New Media GmbH > > > > Andreas Worbs > > > > > > Artfiles New Media GmbH | Zirkusweg 1 | 20359 Hamburg > > Tel: 040 - 32 02 72 90 | Fax: 040 - 32 02 72 95 > > E-Mail: support(a)artfiles.de | Web: http://www.artfiles.de > > Geschäftsführer: Harald Oltmanns | Tim Evers > > Eingetragen im Handelsregister Hamburg - HRB 81478 > > > > > > > > > > > > > > ********************************************** > > IPv4 is over > > Are you ready for the new Internet ? > > http://www.consulintel.es > > The IPv6 Company > > > > This electronic message contains information which may be > > privileged or confidential. The information is intended to be > > for the exclusive use of the individual(s) named above and > > further non-explicilty authorized disclosure, copying, > > distribution or use of the contents of this information, even > > if partially, including attached files, is strictly prohibited > > and will be considered a criminal offense. If you are not the > > intended recipient be aware that any disclosure, copying, > > distribution or use of the contents of this information, even > > if partially, including attached files, is strictly prohibited, > > will be considered a criminal offense, so you must reply to the > > original sender to inform about this communication and delete > > it. > > > > > > > > > > > > > > > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.consulintel.es > The IPv6 Company > > This electronic message contains information which may be privileged > or confidential. The information is intended to be for the exclusive > use of the individual(s) named above and further non-explicilty > authorized disclosure, copying, distribution or use of the contents > of this information, even if partially, including attached files, is > strictly prohibited and will be considered a criminal offense. If you > are not the intended recipient be aware that any disclosure, copying, > distribution or use of the contents of this information, even if > partially, including attached files, is strictly prohibited, will be > considered a criminal offense, so you must reply to the original > sender to inform about this communication and delete it. > > > > > ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.

1 0

Re: [anti-abuse-wg] [policy-announce] 2017-02 Review Phase (Regular abuse-c Validation)
by JORDI PALET MARTINEZ 19 Jan '18

19 Jan '18

One more thing I just realized ... I understand that the mailbox must be a "real" one, not the typical "privacy.85o8095.849804938(a)privacy.xxx" that is used often in whois data ... Regards, Jordi -----Mensaje original----- De: anti-abuse-wg <anti-abuse-wg-bounces(a)ripe.net> en nombre de ox <andre(a)ox.co.za> Organización: ox.co.za Fecha: viernes, 19 de enero de 2018, 10:37 Para: <anti-abuse-wg(a)ripe.net> Asunto: Re: [anti-abuse-wg] [policy-announce] 2017-02 Review Phase (Regular abuse-c Validation) Yes, the idea Thomas had about human interaction, solving a captcha and a tickbox is a great idea my 1c Andre On Fri, 19 Jan 2018 10:29:42 +0100 JORDI PALET MARTINEZ via anti-abuse-wg <anti-abuse-wg(a)ripe.net> wrote: > I also think that Thomas suggestion of a checkbox agreeing with > regularly monitoring the abuse-mailbox is a wonderful suggestion. > Regards, > Jordi > Para: <anti-abuse-wg(a)ripe.net> > Asunto: Re: [anti-abuse-wg] [policy-announce] 2017-02 Review Phase > (Regular abuse-c Validation) > I support the proposal in general and i also think a human > interaction of the resource holder is required. > > Am 19.01.18 um 09:52 schrieb Thomas Hungenberg: > > I second Jordi's opinion that validation of the abuse-mailbox > > should require human interaction of the resource holder. In > > addition to solving a captcha the resource holder might need to > > confirm (click a checkbox) that he will monitor the > > abuse-mailbox account on a regular basis and take appropriate > > action to solve reported abuse cases. > > > > > > - Thomas > > > > CERT-Bund Incident Response & Malware Analysis Team > > > > > > On 18.01.2018 19:44, JORDI PALET MARTINEZ via anti-abuse-wg > > wrote: > >> I fully agree with this proposal and should be implemented > >> ASAP. > >> > >> HOWEVER, I’ve a question regarding the impact analysis, and > >> specially this sentence: > >> > >> “To increase efficiency, this process will use an automated > >> solution that will allow the validation of “abuse-mailbox:” > >> attributes without sending an email. No action will be needed > >> by resource holders that have configured their > >> “abuse-mailbox:” attribute correctly.” > >> > >> Reading the policy proposal, how the NCC concludes that it > >> should be “without sending an email”? > >> > >> I will say that the right way to do a validation (at > >> creation/modification and yearly) is, in a way that makes > >> sense (having an email that nobody is processing is exactly > >> the same as not having the abuse attribute at all): 1) Send an > >> email with a link that must be clicked by a human (so some > >> kind of captcha-like mechanism should be followed) 2) If this > >> link is not clicked in a period of 48 hours (not including > >> Saturday-Sunday), an alarm should be generated so the NCC can > >> take the relevant actions and make sure that the mailbox is > >> actively monitored by the LIR > >> > >> Regards, > >> Jordi > > > > -- > Mit freundlichem Gruß > > Artfiles New Media GmbH > > Andreas Worbs > > > Artfiles New Media GmbH | Zirkusweg 1 | 20359 Hamburg > Tel: 040 - 32 02 72 90 | Fax: 040 - 32 02 72 95 > E-Mail: support(a)artfiles.de | Web: http://www.artfiles.de > Geschäftsführer: Harald Oltmanns | Tim Evers > Eingetragen im Handelsregister Hamburg - HRB 81478 > > > > > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.consulintel.es > The IPv6 Company > > This electronic message contains information which may be privileged > or confidential. The information is intended to be for the exclusive > use of the individual(s) named above and further non-explicilty > authorized disclosure, copying, distribution or use of the contents > of this information, even if partially, including attached files, is > strictly prohibited and will be considered a criminal offense. If you > are not the intended recipient be aware that any disclosure, copying, > distribution or use of the contents of this information, even if > partially, including attached files, is strictly prohibited, will be > considered a criminal offense, so you must reply to the original > sender to inform about this communication and delete it. > > > > > ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.

2 1

Automatische Antwort: [policy-announce] 2017-02 Review Phase (Regular abuse-c Validation)
by Heger, Christian 18 Jan '18

18 Jan '18

Ich bin zurzeit nicht im Hause. Bitte wenden Sie sich in dringenden Fällen an meine Kollegen. Diese Mail wird nicht weitergeleitet! Mit freundlichen Grüßen Christian Heger Netzwerk Access & Security | P352 Tel.: +49 911 319-42250 ________________________________ DATEV eG 90329 Nürnberg Telefon +49 911 319-0 Telefax +49 911 147-43196 E-Mail: info(a)datev.de Internet: https://www.datev.de Sitz: 90429 Nürnberg, Paumgartnerstraße 6-14 Registergericht Nürnberg, GenReg Nr. 70 Vorstand Dr. Robert Mayr (Vorsitzender) Eckhard Schwarzer (stellv. Vorsitzender) Prof. Dr. Peter Krug Jörg Rabe von Pappenheim Diana Windmeißer Vorsitzender des Aufsichtsrates: Joachim M. Clostermann

1 0

abuse-c attributes in resource objects
by Thomas Hungenberg 04 Jan '18

04 Jan '18

The "FAQs for abuse-c" says: You can have an "abuse-c:" attribute on both your ORGANISATION object AND your RESOURCE object (inetnum, inet6num and aut-num). The "abuse-c:" reference on applicable RESOURCE objects will override the value in the "abuse-c:" of your ORGANISATION object. [https://www.ripe.net/manage-ips-and-asns/resource-management/faqs-for-abuse…] However, in the RIPE documentation, the list of all possible attributes allowed in AUT-NUM and INETNUM objects does *not* include "abuse-c": [https://www.ripe.net/manage-ips-and-asns/db/support/documentation/ripe-data… rpsl-object-types/4-2-descriptions-of-primary-objects/4-2-1-description-of-the-aut-num-object] [https://www.ripe.net/manage-ips-and-asns/db/support/documentation/ripe-data… rpsl-object-types/4-2-descriptions-of-primary-objects/4-2-4-description-of-the-inetnum-object] There are currently some RESOURCE objects in the RIPE database having abuse-c attributes (which should not be allowed according to the documentation). For example: inetnum: 62.27.57.0 - 62.27.57.255 netname: TIS-D406483-NET descr: Cheetah Digital Germany GmbH country: DE admin-c: NET12312-RIPE tech-c: NET12312-RIPE abuse-c: CDAC23-RIPE status: ASSIGNED PA mnt-by: AS12312-MNT So we wonder what is correct? We would prefer sticking to the documentation allowing abuse-c attributes only in ORGANISATION objects but not in RESOURCE objects as this makes maintaining a local abuse contact database (for CERTs sending thousands of abuse reports per day) much easier. For example, for our local contact database, we import all ORGANISATION objects with "country: DE" and use "org-name" for the contact's name. Then, we link all RESOURCE objects referencing this ORG to the respective contact in our database. Also evaluating abuse-c attributes directly included in RESOURCE objects would make building a local contact database much more complex. - Thomas CERT-Bund Incident Response & Malware Analysis Team

1 0