Maybe I’m not using the right wording.

What I’m suggesting is and “intermediation” but automated. NCC staff doesn’t “see” anything, just goes thru a system that logs everything and forwards to each other party.

 

El 17/1/20 13:04, "Volker Greimann" <vgreimann@key-systems.net> escribió:

 

Hmm, if you include RIPE NCC in all responses, you will greatly increase the overhead and noise to signal ratio it has to deal with. It may be better to maintain the ability to audit the responses. instead of receiving them all.

-- 
Volker A. Greimann
General Counsel and Policy Manager
KEY-SYSTEMS GMBH

T: +49 6894 9396901
M: +49 6894 9396851
F: +49 6894 9396851
W: 
www.key-systems.net

Key-Systems GmbH is a company registered at the local court of Saarbruecken, Germany with the registration no. HR B 18835
CEO: Alexander Siffrin

Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358.

 

 

On Fri, Jan 17, 2020 at 12:00 PM JORDI PALET MARTINEZ via anti-abuse-wg <anti-abuse-wg@ripe.net> wrote:

I will be fine with this (having RIPE NCC as an intermediator just to send the abuse report), if instead of a web form (or in addition to it), it is possible to automate it, for example RIPE NCC also accepts x-arf via email.

RIPE NCC has the obligation to keep the information without disclosing it, so why we need to have a way to encypt it so RIPE NCC can’t read it? Furthermore, this should be an automated process. The staff is not going to handle every report manually. And moreover, in case of a bigger dispute, even if going to the courts, RIPE NCC can provide in a neutral way all the info of what happened.

However, I’ve the feeling that in order to get this working, the policy must mandate that all the responser from the operator which customer is producing the abuse, also follow the same path, so:

Abuse reporter (Victim or its ISP) -> RIPE NCC -> abuser operator -> RIPE NCC -> abuse reporter

Otherwise, there will not be a way for RIPE to have stats of who is responding to abuse cases and who is not, or even simpler than that, what abuse mailboxes get bounced (which will be a policy violation if happens all the time with the same operator). Never mind we decide or not that not-responding is an abuse-c violation. Stats are good, even if not published with operator names.

 

El 17/1/20 1:12, "anti-abuse-wg en nombre de ripedenis--- via anti-abuse-wg" <anti-abuse-wg-bounces@ripe.net en nombre de anti-abuse-wg@ripe.net> escribió:

 

Hi Sergio

 

As I read through this thread similar ideas came to my mind. The question I would ask is "Is it too late to take a completely different approach to abuse contacts and reporting via the RIPE Database?"

 

Suppose we had a standard form available via the ripe.net website for providing details of abuse. If you are able to find the "abuse-c:" details in the database now then you must know the IP address involved. The RIPE NCC could send the report to the abuse contact taken from the database via the specified IP address. This does not have to be an email interface either. We could look at other options. The RIPE NCC would then at least know if the report was successfully delivered. Using a standard form would make it much easier for the resource holder to interpret the information.

 

Someone said:

"Making such a scheme compulsory would be unacceptable to people who wish to interact with network owners without disclosing that in public ..."

I have no understanding of the technology involved here, but when I send you a message on WhatsApp it is encrypted end to end. WhatsApp have no idea (they say) of the content of the message. Would it be possible to submit a form on ripe.net in a way that the content of that form is encrypted and sent to the resource holder so the RIPE NCC have no idea of the content of the form? That would satisfy this concern.

 

Regardless of the outcome of the RIPE Database Requirements Task Force, something like this could still be implemented as it is external to the RIPE Database.

 

Food for thought...

 

cheers

 

denis

 

co-chair DB-WG

 

 

On Wednesday, 15 January 2020, 10:22:28 CET, Sérgio Rocha <sergio.rocha@makeitsimple.pt> wrote:

 

 

Hi,

Maybe we can change the approach.
If RIPE website had a platform to post abuse report, that send the email for
the abuse contact, it will be possible to evaluate the responsiveness of the
abuse contact.

This way anyone that report an abuse could assess not only the response but
also the effectiveness of the actions taken by the network owner. After some
time with this evaluations we would easy to realize who manages the reports
and even who does not respond at all.

Sérgio


-----Original Message-----
From: anti-abuse-wg [mailto:anti-abuse-wg-bounces@ripe.net] On Behalf Of
Gert Doering
Sent: 15 de janeiro de 2020 08:06
To: Carlos Friaças <cfriacas@fccn.pt>
Cc: Gert Doering <gert@space.net>; anti-abuse-wg <anti-abuse-wg@ripe.net>
Subject: Re: [anti-abuse-wg] working in new version of 2019-04 (Validation
of "abuse-mailbox")

Hi,

On Wed, Jan 15, 2020 at 07:23:38AM +0000, Carlos Friaças via anti-abuse-wg
wrote:
> I obviously don't speak for the incident handling community, but i
> think this (making it optional) would be a serious step back. The
> current situation is already very bad when in some cases we know from
> the start that we are sending (automated) messages/notices to blackholes.

So why is it preferrable to send mails which are not acted on, as opposed to
"not send mail because you know beforehand that the other network is not
interested"?

I can see that it is frustrating - but I still cannot support a policy
change which will not help dealing with irresponsible networks in any way,
but at the same time increases costs and workload for those that do the
right thing alrady.


> To an extreme, there should always be a known contact responsible for
> any network infrastructure. If this is not the case, what's the
> purpose of a registry then?

"a known contact" and "an *abuse-handling* contact" is not the same thing.

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.


**********************************************
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.