You are here: Home > Participate > Join a Discussion > RIPE Forum
RIPE Forum v1.4.2

Anti-Abuse Working Group

Threaded
Collapse

[anti-abuse-wg] Proposal: Publish effective users' abuse-c

User Image

Alessandro Vesely

2022-01-20 13:37:53 CET

Hi all,

we all know abuse-c data is to be filled by the IP assignee, which I call ISP 
in the following.

I understand that, since ISPs own IP space it is their job to ensure that it 
isn't abused.  If they give up the receiving of abuse complaints and give it to 
their customer instead, and they don't receive the complaints as a result, then 
they won't be aware if their customer is violating important policies.

However, it is the ISPs' customers who are the effective users of those IPs. 
Any complaint, whether reporting spam or botnet activity, can probably be 
handled more effectively by the people who run the systems connected to a given 
IP than the actual owner.

I propose that RIPE accepts abuse-c email addresses from verified effective 
users of a range of IP numbers, stores them in the database, and serves them in 
RDAP/ WHOIS queries besides the abuse-c addresses provided by the ISP.  Various 
automated methods can be adopted to allow an effective user to be verified; for 
example publishing an HTTP URL or a DNS entry.  Abuse contacts added that way 
can expire after a few months, forcing the effective user to renew them, so as 
to avoid stale entries.

I'm unsure if the above requires proposing a new policy or what else.  For the 
time being, it would be interesting to gauge if this WG likes the idea and if 
there are effective users, apart from me, who would be interested in publishing 
their abuse-c.


Best
Ale
-- 





denis walker

2022-01-20 16:18:10 CET

Hi Alessandro

Do you realise that abuse-c works hierarchically? The resource holder
is required to have an abuse-c in their ORGANISATION object as a
default. It was agreed by the community a few years ago to allow
additional abuse-c attributes in the resource objects. So if an end
user wants to receive abuse reports for their network the resource
holder can add an additional abuse-c attribute into the assignment
object (which is usually maintained by the resource holder). The abuse
ROLE object can be maintained by the end user so they can set their
own abuse email address. A query will only return the closest abuse
email address to any given IP address. So for any address in the end
user's range it will return their abuse email.

cheers
denis
co-chair DB-WG

On Thu, 20 Jan 2022 at 13:37, Alessandro Vesely <vesely _at_ tana _dot_ it> wrote:
>
> Hi all,
>
> we all know abuse-c data is to be filled by the IP assignee, which I call ISP
> in the following.
>
> I understand that, since ISPs own IP space it is their job to ensure that it
> isn't abused.  If they give up the receiving of abuse complaints and give it to
> their customer instead, and they don't receive the complaints as a result, then
> they won't be aware if their customer is violating important policies.
>
> However, it is the ISPs' customers who are the effective users of those IPs.
> Any complaint, whether reporting spam or botnet activity, can probably be
> handled more effectively by the people who run the systems connected to a given
> IP than the actual owner.
>
> I propose that RIPE accepts abuse-c email addresses from verified effective
> users of a range of IP numbers, stores them in the database, and serves them in
> RDAP/ WHOIS queries besides the abuse-c addresses provided by the ISP.  Various
> automated methods can be adopted to allow an effective user to be verified; for
> example publishing an HTTP URL or a DNS entry.  Abuse contacts added that way
> can expire after a few months, forcing the effective user to renew them, so as
> to avoid stale entries.
>
> I'm unsure if the above requires proposing a new policy or what else.  For the
> time being, it would be interesting to gauge if this WG likes the idea and if
> there are effective users, apart from me, who would be interested in publishing
> their abuse-c.
>
>
> Best
> Ale
> --
>
>
>
>
>
> --
>
> To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/anti-abuse-wg

Ángel González Berdasco

2022-01-20 16:27:59 CET

Alessandro Vesely wrote:
> Hi all,
> 
> (...)
> 
> I propose that RIPE accepts abuse-c email addresses from verified effective 
> users of a range of IP numbers, stores them in the database, and serves them in 
> RDAP/ WHOIS queries besides the abuse-c addresses provided by the ISP.  Various 
> automated methods can be adopted to allow an effective user to be verified; for 
> example publishing an HTTP URL or a DNS entry.  Abuse contacts added that way 
> can expire after a few months, forcing the effective user to renew them, so as 
> to avoid stale entries.


Hello Ale

I think you should describe how this proposal differs from what is
available nowadays. Wouldn't they already be able to configure verified
effective users for the IP addresses (e.g. with an abuse-c of the
client and another of theirs) ?

They may be unwilling to do so or consider it a hurdle, requiring them
to create new objects and so on, but what makes you believe they would
be willing to use that new system?


Best

-- 
INCIBE-CERT - Spanish National CSIRT
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.

====================================================================

In compliance with the General Data Protection Regulation of the EU
(Regulation EU 2016/679, of 27 April 2016) we inform you that your
personal and corporate data (as well as those included in attached
documents); and e-mail address, may be included in our records 
for the purpose derived from legal, contractual or pre-contractual
obligations or in order to respond to your queries. You may exercise
your rights of access, correction, cancellation, portability,
limitationof processing and opposition under the terms established by
current legislation and free of charge by sending an e-mail to
dpd _at_ incibe _dot_ es. The Data Controller is S.M.E. Instituto Nacional de
Ciberseguridad de España, M.P., S.A. More information is available
on our website: https://www.incibe.es/proteccion-datos-personales
and https://www.incibe.es/registro-actividad.

====================================================================

User Image

Alessandro Vesely

2022-01-21 13:03:31 CET

Hi Denis,

I followed the discussion, and got a rough idea of how it works.  At the time, 
I succeeded convincing my ISP (Eutelia) to assign an abuse-mailbox to me. 
Afterwards the policy changed, but meanwhile my ISP went belly up and I 
couldn't convince the new one to set abuse-c for me.

The idea is to add extra addresses to assignment objects, irrespective of the 
resource holder, based on the wish of its customer who is actually connected to 
the resource.  Would that be at all possible?  And, if yes, would it be 
acceptable by the resource holder or are there contractual impediments? 
Finally, if feasibility is ok, would operators take advantage of it or is it 
only me?


Best
ale


On Thu 20/Jan/2022 16:18:10 +0100 denis walker wrote:
> Hi Alessandro
> 
> Do you realise that abuse-c works hierarchically? The resource holder
> is required to have an abuse-c in their ORGANISATION object as a
> default. It was agreed by the community a few years ago to allow
> additional abuse-c attributes in the resource objects. So if an end
> user wants to receive abuse reports for their network the resource
> holder can add an additional abuse-c attribute into the assignment
> object (which is usually maintained by the resource holder). The abuse
> ROLE object can be maintained by the end user so they can set their
> own abuse email address. A query will only return the closest abuse
> email address to any given IP address. So for any address in the end
> user's range it will return their abuse email.
> 
> cheers
> denis
> co-chair DB-WG
> 
> On Thu, 20 Jan 2022 at 13:37, Alessandro Vesely <vesely _at_ tana _dot_ it> wrote:
>>
>> Hi all,
>>
>> we all know abuse-c data is to be filled by the IP assignee, which I call ISP
>> in the following.
>>
>> I understand that, since ISPs own IP space it is their job to ensure that it
>> isn't abused.  If they give up the receiving of abuse complaints and give it to
>> their customer instead, and they don't receive the complaints as a result, then
>> they won't be aware if their customer is violating important policies.
>>
>> However, it is the ISPs' customers who are the effective users of those IPs.
>> Any complaint, whether reporting spam or botnet activity, can probably be
>> handled more effectively by the people who run the systems connected to a given
>> IP than the actual owner.
>>
>> I propose that RIPE accepts abuse-c email addresses from verified effective
>> users of a range of IP numbers, stores them in the database, and serves them in
>> RDAP/ WHOIS queries besides the abuse-c addresses provided by the ISP.  Various
>> automated methods can be adopted to allow an effective user to be verified; for
>> example publishing an HTTP URL or a DNS entry.  Abuse contacts added that way
>> can expire after a few months, forcing the effective user to renew them, so as
>> to avoid stale entries.
>>
>> I'm unsure if the above requires proposing a new policy or what else.  For the
>> time being, it would be interesting to gauge if this WG likes the idea and if
>> there are effective users, apart from me, who would be interested in publishing
>> their abuse-c.
>>
>>
>> Best
>> Ale
>> --
>>
>>
>>
>>
>>
>> --
>>
>> To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/anti-abuse-wg
> 

User Image

Alessandro Vesely

2022-01-21 13:31:12 CET

Hi Ángel,

On Thu 20/Jan/2022 16:27:59 +0100 Ángel González Berdasco wrote:
> Alessandro Vesely wrote:
>> 
>> I propose that RIPE accepts abuse-c email addresses from verified effective 
>> users of a range of IP numbers, stores them in the database, and serves them in 
>> RDAP/ WHOIS queries besides the abuse-c addresses provided by the ISP.  Various 
>> automated methods can be adopted to allow an effective user to be verified; for 
>> example publishing an HTTP URL or a DNS entry.  Abuse contacts added that way 
>> can expire after a few months, forcing the effective user to renew them, so as 
>> to avoid stale entries.
> 
> I think you should describe how this proposal differs from what is
> available nowadays. Wouldn't they already be able to configure verified
> effective users for the IP addresses (e.g. with an abuse-c of the
> client and another of theirs) ?
> 
> They may be unwilling to do so or consider it a hurdle, requiring them
> to create new objects and so on, but what makes you believe they would
> be willing to use that new system?


Curiously, IME, they're keen on doing RFC 2317 delegations, but refrain from 
assigning abuse-c attributes.  I don't know if those belong to different 
departments or if there's just a different policy.  The concept that they are 
safer holding abuse-c for themselves was expressed on mailop recently.  If I 
were an ISP, I'd set up different abuse-c addresses for each customer, 
something like [email protected], with possible auto-forward to a 
customer supplied address.  But I'm not.

RDAP allows some leeway in responses, so that something could be set to 
indicate whether a vcard entry belongs to the ISP or to the final operator.  I 
don't think ARIN or other RIRs are already featuring that kind of facility.  Is 
it because nobody asked?


Best
Ale
-- 









Hans-Martin Mosner

2022-01-21 14:21:41 CET

Am 20.01.22 um 13:37 schrieb Alessandro Vesely:
>
> However, it is the ISPs' customers who are the effective users of those IPs. Any complaint, whether reporting spam or 
> botnet activity, can probably be handled more effectively by the people who run the systems connected to a given IP 
> than the actual owner. 

In a considerable amount of cases, the ISP's customer is also the spammer. I would prefer not to talk to them when 
complaining about their behavior - in the best case, they will ignore me, in the worst case, they might do something in 
revenge.

The IP owner is the one who can pull the plug on misbehaving customers. As it is much easier to identify IP owners, I 
can collect reputation data about who I can trust to handle my abuse complaint responsibly, who will just ignore it, who 
will forward it unedited to their customer. Depending on this assessment of their trustworthiness, I will or won't report.

There are very few cases where reporting to end users makes much sense. Either they operate their system responsibly 
including monitoring the mail rejects and bounces, then they already know there's something that needs to be fixed, or 
they don't, and most often don't care, and my complaint will probably not change that.

Cheers,
Hans-Martin


denis walker

2022-01-21 19:40:40 CET

Hi Alessandro


On Fri, 21 Jan 2022 at 13:03, Alessandro Vesely <vesely _at_ tana _dot_ it> wrote:
>
> Hi Denis,
>
> I followed the discussion, and got a rough idea of how it works.  At the time,
> I succeeded convincing my ISP (Eutelia) to assign an abuse-mailbox to me.
> Afterwards the policy changed, but meanwhile my ISP went belly up and I
> couldn't convince the new one to set abuse-c for me.
>
> The idea is to add extra addresses to assignment objects, irrespective of the
> resource holder, based on the wish of its customer who is actually connected to
> the resource.  Would that be at all possible?

When you say " irrespective of the  resource holder, based on the wish
of its customer" do you mean without their consent or control? That is
not possible as they maintain the assignment object. I would also say
it is not desirable. That would allow an abuser to override the
resource holders abuse-c and ignore all abuse reports.

> And, if yes, would it be
> acceptable by the resource holder or are there contractual impediments?
> Finally, if feasibility is ok, would operators take advantage of it or is it
> only me?

If you are talking about adding extra abuse addresses to assignment
objects by agreement with the resource holder, as I explained, that is
possible now by simply adding an abuse-c to the assignment .

cheers
denis
co-chair DB-WG


>
>
> Best
> ale
>
>
> On Thu 20/Jan/2022 16:18:10 +0100 denis walker wrote:
> > Hi Alessandro
> >
> > Do you realise that abuse-c works hierarchically? The resource holder
> > is required to have an abuse-c in their ORGANISATION object as a
> > default. It was agreed by the community a few years ago to allow
> > additional abuse-c attributes in the resource objects. So if an end
> > user wants to receive abuse reports for their network the resource
> > holder can add an additional abuse-c attribute into the assignment
> > object (which is usually maintained by the resource holder). The abuse
> > ROLE object can be maintained by the end user so they can set their
> > own abuse email address. A query will only return the closest abuse
> > email address to any given IP address. So for any address in the end
> > user's range it will return their abuse email.
> >
> > cheers
> > denis
> > co-chair DB-WG
> >
> > On Thu, 20 Jan 2022 at 13:37, Alessandro Vesely <vesely _at_ tana _dot_ it> wrote:
> >>
> >> Hi all,
> >>
> >> we all know abuse-c data is to be filled by the IP assignee, which I call ISP
> >> in the following.
> >>
> >> I understand that, since ISPs own IP space it is their job to ensure that it
> >> isn't abused.  If they give up the receiving of abuse complaints and give it to
> >> their customer instead, and they don't receive the complaints as a result, then
> >> they won't be aware if their customer is violating important policies.
> >>
> >> However, it is the ISPs' customers who are the effective users of those IPs.
> >> Any complaint, whether reporting spam or botnet activity, can probably be
> >> handled more effectively by the people who run the systems connected to a given
> >> IP than the actual owner.
> >>
> >> I propose that RIPE accepts abuse-c email addresses from verified effective
> >> users of a range of IP numbers, stores them in the database, and serves them in
> >> RDAP/ WHOIS queries besides the abuse-c addresses provided by the ISP.  Various
> >> automated methods can be adopted to allow an effective user to be verified; for
> >> example publishing an HTTP URL or a DNS entry.  Abuse contacts added that way
> >> can expire after a few months, forcing the effective user to renew them, so as
> >> to avoid stale entries.
> >>
> >> I'm unsure if the above requires proposing a new policy or what else.  For the
> >> time being, it would be interesting to gauge if this WG likes the idea and if
> >> there are effective users, apart from me, who would be interested in publishing
> >> their abuse-c.
> >>
> >>
> >> Best
> >> Ale
> >> --
> >>
> >>
> >>
> >>
> >>
> >> --
> >>
> >> To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/anti-abuse-wg
> >

User Image

Alessandro Vesely

2022-01-22 12:04:51 CET

Hi,

On Fri 21/Jan/2022 19:40:40 +0100 denis walker wrote:
> On Fri, 21 Jan 2022 at 13:03, Alessandro Vesely <vesely _at_ tana _dot_ it> wrote:
>>
>> The idea is to add extra addresses to assignment objects, irrespective of the
>> resource holder, based on the wish of its customer who is actually connected to
>> the resource.  Would that be at all possible?
> 
> When you say " irrespective of the  resource holder, based on the wish
> of its customer" do you mean without their consent or control? That is
> not possible as they maintain the assignment object. I would also say
> it is not desirable. That would allow an abuser to override the
> resource holders abuse-c and ignore all abuse reports.


Yes, I meant extra attributes linked to the assignment object.  If it's not 
possible let's just forget it.


>> And, if yes, would it be acceptable by the resource holder or are there
>> contractual impediments? Finally, if feasibility is ok, would operators
>> take advantage of it or is it only me? >
> If you are talking about adding extra abuse addresses to assignment
> objects by agreement with the resource holder, as I explained, that is
> possible now by simply adding an abuse-c to the assignment .


Except that I don't have write access to the assignment object.


Best
Ale
-- 







User Image

Alessandro Vesely

2022-01-22 12:19:14 CET

On Fri 21/Jan/2022 14:21:41 +0100 Hans-Martin Mosner wrote:
> Am 20.01.22 um 13:37 schrieb Alessandro Vesely:
>>
>> However, it is the ISPs' customers who are the effective users of those IPs. 
>> Any complaint, whether reporting spam or botnet activity, can probably be 
>> handled more effectively by the people who run the systems connected to a 
>> given IP than the actual owner. 
> 
> In a considerable amount of cases, the ISP's customer is also the spammer. I 
> would prefer not to talk to them when complaining about their behavior - in the 
> best case, they will ignore me, in the worst case, they might do something in 
> revenge.


That makes sense when you're reporting spam.  Botnet activity differs.  If RDAP 
data allows to recognize which abuse contact belongs to which kind of operator, 
tools can accept options to output either one or both.


> The IP owner is the one who can pull the plug on misbehaving customers. As it 
> is much easier to identify IP owners, I can collect reputation data about who I 
> can trust to handle my abuse complaint responsibly, who will just ignore it, 
> who will forward it unedited to their customer. Depending on this assessment of 
> their trustworthiness, I will or won't report.


Wow!  I just collect those which bounce.  Some send some feedback, and in a 
minority of those cases I seem to be able to grasp that they actually do 
something to mitigate reported abuse.


> There are very few cases where reporting to end users makes much sense. Either 
> they operate their system responsibly including monitoring the mail rejects and 
> bounces, then they already know there's something that needs to be fixed, or 
> they don't, and most often don't care, and my complaint will probably not 
> change that.


Some operators say they refuse abuse reporting by email because they want 
complainants to fill web forms.  Of course, web forms have fields that provide 
for better handling.  However, the only handling I can think of is to associate 
the IP field to the corresponding customer and automatically forward the 
complaint there.  That could be done by RDAP.



Best
Ale
-- 







Ángel González Berdasco

2022-01-22 21:47:26 CET

Alessandro Vesely wrote:
> > > And, if yes, would it be acceptable by the resource holder or are
> > > there
> > > contractual impediments? Finally, if feasibility is ok, would
> > > operators
> > > take advantage of it or is it only me? >
> > 
> > If you are talking about adding extra abuse addresses to assignment
> > objects by agreement with the resource holder, as I explained, that
> > is
> > possible now by simply adding an abuse-c to the assignment .
> 
> 
> Except that I don't have write access to the assignment object.
> 
> 
> Best
> Ale


I'm not an expert on all the supported RIPE db details, but I think you
could have an abuse contact object, that you could modify, with the
main resource linking to your abuse contact plus the ISP one.

I find that abuse contacts are fairly static ones (if not directly
following rfc2142), so the client need to write to it is probably not a
very relevant use case. Maybe some weird setup, such as if you wanted
to present a dynamic abuse contact that changed every day-

-- 
INCIBE-CERT - Spanish National CSIRT
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.

====================================================================

In compliance with the General Data Protection Regulation of the EU
(Regulation EU 2016/679, of 27 April 2016) we inform you that your
personal and corporate data (as well as those included in attached
documents); and e-mail address, may be included in our records 
for the purpose derived from legal, contractual or pre-contractual
obligations or in order to respond to your queries. You may exercise
your rights of access, correction, cancellation, portability,
limitationof processing and opposition under the terms established by
current legislation and free of charge by sending an e-mail to
dpd _at_ incibe _dot_ es. The Data Controller is S.M.E. Instituto Nacional de
Ciberseguridad de España, M.P., S.A. More information is available
on our website: https://www.incibe.es/proteccion-datos-personales
and https://www.incibe.es/registro-actividad.

====================================================================

denis walker

2022-01-23 00:01:04 CET

Hi Angel

On Sat, 22 Jan 2022 at 21:47, Ángel González Berdasco
<angel.gonzalez _at_ incibe _dot_ es> wrote:
>
> Alessandro Vesely wrote:
> > > > And, if yes, would it be acceptable by the resource holder or are
> > > > there
> > > > contractual impediments? Finally, if feasibility is ok, would
> > > > operators
> > > > take advantage of it or is it only me? >
> > >
> > > If you are talking about adding extra abuse addresses to assignment
> > > objects by agreement with the resource holder, as I explained, that
> > > is
> > > possible now by simply adding an abuse-c to the assignment .
> >
> >
> > Except that I don't have write access to the assignment object.
> >
> >
> > Best
> > Ale
>
>
> I'm not an expert on all the supported RIPE db details, but I think you
> could have an abuse contact object, that you could modify,

This bit is possible. The ROLE object containing the "abuse-mailbox:"
can be maintained by the end user so they can set their own email
address and change it whenever they wish.


> with the
> main resource linking to your abuse contact plus the ISP one.

This bit is not possible. The "abuse-c:" attribute is 'single'. So the
resource object can only ever reference one abuse contact.

cheers
denis
co-chair DB-WG


>
> I find that abuse contacts are fairly static ones (if not directly
> following rfc2142), so the client need to write to it is probably not a
> very relevant use case. Maybe some weird setup, such as if you wanted
> to present a dynamic abuse contact that changed every day-
>
> --
> INCIBE-CERT - Spanish National CSIRT
> https://www.incibe-cert.es/
>
> PGP keys: https://www.incibe-cert.es/en/what-is-incibe-cert/pgp-public-keys

Ángel González Berdasco

2022-01-23 00:12:30 CET

> This bit is not possible. The "abuse-c:" attribute is 'single'. So the
> resource object can only ever reference one abuse contact.

Thanks Denis. abuse-c arity is a point I was dubious about.

Thus, it is not currently possible to publish an abuse-c with the customer address and keep the ISP copied at the same time, as desired.
In order to know what is being sent thete, the ISP needs to provide its own address and (if appropriate) forward complaints received there to the customer.


Best regards

--
INCIBE-CERT - Spanish National CSIRT
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.

====================================================================

In compliance with the General Data Protection Regulation of the EU
(Regulation EU 2016/679, of 27 April 2016) we inform you that your
personal and corporate data (as well as those included in attached
documents); and e-mail address, may be included in our records
for the purpose derived from legal, contractual or pre-contractual
obligations or in order to respond to your queries. You may exercise
your rights of access, correction, cancellation, portability,
limitationof processing and opposition under the terms established by
current legislation and free of charge by sending an e-mail to
dpd _at_ incibe _dot_ es. The Data Controller is S.M.E. Instituto Nacional de
Ciberseguridad de España, M.P., S.A. More information is available
on our website: https://www.incibe.es/proteccion-datos-personales
and https://www.incibe.es/registro-actividad.

====================================================================






User Image

Michele Neylon

2022-02-10 11:54:04 CET

That’s not entirely true.

It’ll depend on how granular the LIR is with their allocations to their clients.

Speaking on behalf of my company we do assign blocks and abuse-c contacts to quite a few of our clients.
However we wouldn’t do that for every single IP address and due to the nature of some of the services we provide a single IP address is going to be linked to multiple clients.

The main issue we run into is with some reporters using a scatter gun approach with reporting abuse, which is just a waste of everyone’s time. (Basically sending notices to every single contact they can find – not just the abuse-c)

Regards

Michele



--
Mr Michele Neylon
Blacknight Solutions
Hosting, Colocation & Domains
https://www.blacknight.com/
https://blacknight.blog/
Intl. +353 (0) 59  9183072
Direct Dial: +353 (0)59 9183090
Personal blog: https://michele.blog/
Some thoughts: https://ceo.hosting/
-------------------------------
Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty
Road,Graiguecullen,Carlow,R93 X265,Ireland  Company No.: 370845


From: anti-abuse-wg <anti-abuse-wg-bounces _at_ ripe _dot_ net> on behalf of Ángel González Berdasco <angel.gonzalez _at_ incibe _dot_ es>
Date: Saturday, 22 January 2022 at 23:12
To: denis walker <ripedenis _at_ gmail _dot_ com>
Cc: anti-abuse-wg _at_ ripe _dot_ net <anti-abuse-wg _at_ ripe _dot_ net>
Subject: Re: [anti-abuse-wg] Proposal: Publish effective users' abuse-c

[EXTERNAL EMAIL] Please use caution when opening attachments from unrecognised sources.
> This bit is not possible. The "abuse-c:" attribute is 'single'. So the
> resource object can only ever reference one abuse contact.

Thanks Denis. abuse-c arity is a point I was dubious about.

Thus, it is not currently possible to publish an abuse-c with the customer address and keep the ISP copied at the same time, as desired.
In order to know what is being sent thete, the ISP needs to provide its own address and (if appropriate) forward complaints received there to the customer.


Best regards

--
INCIBE-CERT - Spanish National CSIRT
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.

====================================================================

In compliance with the General Data Protection Regulation of the EU
(Regulation EU 2016/679, of 27 April 2016) we inform you that your
personal and corporate data (as well as those included in attached
documents); and e-mail address, may be included in our records
for the purpose derived from legal, contractual or pre-contractual
obligations or in order to respond to your queries. You may exercise
your rights of access, correction, cancellation, portability,
limitationof processing and opposition under the terms established by
current legislation and free of charge by sending an e-mail to
dpd _at_ incibe _dot_ es. The Data Controller is S.M.E. Instituto Nacional de
Ciberseguridad de España, M.P., S.A. More information is available
on our website: https://www.incibe.es/proteccion-datos-personales
and https://www.incibe.es/registro-actividad.

====================================================================







denis walker

2022-02-10 22:40:18 CET

Hi Michele

Yes you can allow any customer with an assignment to have their own
abuse-c contact. But the database query will only return a single
abuse contact for any IP address. If the assignment object has an
abuse-c then a query on any IP address in the range of that assignment
will only return the customer's abuse contact details. If an
assignment does not have an abuse-c then such a query will return the
resource holder's abuse-contact details. A query will not return both
the customer's and the resource holder's details.

However, this can be changed if the community wants something
different. We can make abuse-c a multiple attribute so the resource
holder can add the customer's and their own abuse-c to an assignment.
Or we can change the default behaviour of the query so when an abuse-c
is found in an assignment it always returns the resource holder's
abuse-c as well. Or we can add a new query flag to return both abuse-c
details when available. Or we can modify the abuse-c attribute in some
way so the resource holder can choose what a query returns.  Any
behaviour is possible as long as you define what behaviour you want
and the community finds it useful.

chears
denis
co-chair DB-WG

On Thu, 10 Feb 2022 at 11:54, Michele Neylon - Blacknight
<michele _at_ blacknight _dot_ com> wrote:
>
> That’s not entirely true.
>
>
>
> It’ll depend on how granular the LIR is with their allocations to their clients.
>
>
>
> Speaking on behalf of my company we do assign blocks and abuse-c contacts to quite a few of our clients.
>
> However we wouldn’t do that for every single IP address and due to the nature of some of the services we provide a single IP address is going to be linked to multiple clients.
>
>
>
> The main issue we run into is with some reporters using a scatter gun approach with reporting abuse, which is just a waste of everyone’s time. (Basically sending notices to every single contact they can find – not just the abuse-c)
>
>
>
> Regards
>
>
>
> Michele
>
>
>
>
>
>
>
> --
>
> Mr Michele Neylon
>
> Blacknight Solutions
>
> Hosting, Colocation & Domains
>
> https://www.blacknight.com/
>
> https://blacknight.blog/
>
> Intl. +353 (0) 59  9183072
>
> Direct Dial: +353 (0)59 9183090
>
> Personal blog: https://michele.blog/
>
> Some thoughts: https://ceo.hosting/
>
> -------------------------------
>
> Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty
>
> Road,Graiguecullen,Carlow,R93 X265,Ireland  Company No.: 370845
>
>
>
>
>
> From: anti-abuse-wg <anti-abuse-wg-bounces _at_ ripe _dot_ net> on behalf of Ángel González Berdasco <angel.gonzalez _at_ incibe _dot_ es>
> Date: Saturday, 22 January 2022 at 23:12
> To: denis walker <ripedenis _at_ gmail _dot_ com>
> Cc: anti-abuse-wg _at_ ripe _dot_ net <anti-abuse-wg _at_ ripe _dot_ net>
> Subject: Re: [anti-abuse-wg] Proposal: Publish effective users' abuse-c
>
> [EXTERNAL EMAIL] Please use caution when opening attachments from unrecognised sources.
>
> > This bit is not possible. The "abuse-c:" attribute is 'single'. So the
>
> > resource object can only ever reference one abuse contact.
>
>
>
> Thanks Denis. abuse-c arity is a point I was dubious about.
>
>
>
> Thus, it is not currently possible to publish an abuse-c with the customer address and keep the ISP copied at the same time, as desired.
>
> In order to know what is being sent thete, the ISP needs to provide its own address and (if appropriate) forward complaints received there to the customer.
>
>
>
>
>
> Best regards
>
>
>
> --
>
> INCIBE-CERT - Spanish National CSIRT
>
> 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.
>
>
>
> ====================================================================
>
>
>
> In compliance with the General Data Protection Regulation of the EU
>
> (Regulation EU 2016/679, of 27 April 2016) we inform you that your
>
> personal and corporate data (as well as those included in attached
>
> documents); and e-mail address, may be included in our records
>
> for the purpose derived from legal, contractual or pre-contractual
>
> obligations or in order to respond to your queries. You may exercise
>
> your rights of access, correction, cancellation, portability,
>
> limitationof processing and opposition under the terms established by
>
> current legislation and free of charge by sending an e-mail to
>
> dpd _at_ incibe _dot_ es. The Data Controller is S.M.E. Instituto Nacional de
>
> Ciberseguridad de España, M.P., S.A. More information is available
>
> on our website: https://www.incibe.es/proteccion-datos-personales
>
> and https://www.incibe.es/registro-actividad.
>
>
>
> ====================================================================
>
>
>
>
>
>
>
>
>
>
>
>

User Image

Alessandro Vesely

2022-02-14 11:09:06 CET

Hi,

On Thu 10/Feb/2022 22:40:18 +0100 denis walker wrote:
> 
> Yes you can allow any customer with an assignment to have their own
> abuse-c contact. But the database query will only return a single
> abuse contact for any IP address. If the assignment object has an
> abuse-c then a query on any IP address in the range of that assignment
> will only return the customer's abuse contact details. If an
> assignment does not have an abuse-c then such a query will return the
> resource holder's abuse-contact details. A query will not return both
> the customer's and the resource holder's details.


Queries at ARIN or APNIC (and maybe more) often return multiple addresses.  For 
example:
https://rdap.apnic.net/ip/136.185.8.145
has two addresses, returned as two entries in the relevant vcardArray.


> However, this can be changed if the community wants something
> different. We can make abuse-c a multiple attribute so the resource
> holder can add the customer's and their own abuse-c to an assignment.
> Or we can change the default behaviour of the query so when an abuse-c
> is found in an assignment it always returns the resource holder's
> abuse-c as well. Or we can add a new query flag to return both abuse-c
> details when available. Or we can modify the abuse-c attribute in some
> way so the resource holder can choose what a query returns.  Any
> behaviour is possible as long as you define what behaviour you want
> and the community finds it useful.


I don't know if the current settings allows to enter a comma-separated list as 
an abuse-c string value.  Most often, the abuse-c value is an email alias.  So, 
I don't see why people would enter several addresses if they can manage the 
aliases.

IMHO, it makes more sense to store multiple addresses if they can be added by 
different people.


jm2c
Ale
-- 






denis walker

2022-02-14 18:10:53 CET

Hi Alessandro

A query on APNIC's web query form for 136.185.0.0/16 only specifies a
single abuse email contact. The other email address in the rdap output
is the "email:" attribute value from the referenced IRT object. That
is not intended for abuse reports. When we implemented abuse-c in the
RIPE Database, one of the underlying principles was to have a single
process for documenting and finding abuse contact details. We
specifically removed "abuse-mailbox:" from the IRT object, which APNIC
still has. So you can't directly compare the two database outputs.

There are many ways we can tweak the technical details of how abuse-c
works in the RIPE Database. Rather than go round in circles discussing
all possible permutations, perhaps it would be better if you specified
the behaviour you would like to see. If others in the community agree,
then the RIPE NCC can make the necessary technical changes. As long as
we don't break that basic principle of having the one process for
documenting and finding abuse contacts, each of which is singularly
defined, anything else can be changed.

cheers
denis
co-chair DB-WG

On Mon, 14 Feb 2022 at 11:09, Alessandro Vesely <vesely _at_ tana _dot_ it> wrote:
>
> Hi,
>
> On Thu 10/Feb/2022 22:40:18 +0100 denis walker wrote:
> >
> > Yes you can allow any customer with an assignment to have their own
> > abuse-c contact. But the database query will only return a single
> > abuse contact for any IP address. If the assignment object has an
> > abuse-c then a query on any IP address in the range of that assignment
> > will only return the customer's abuse contact details. If an
> > assignment does not have an abuse-c then such a query will return the
> > resource holder's abuse-contact details. A query will not return both
> > the customer's and the resource holder's details.
>
>
> Queries at ARIN or APNIC (and maybe more) often return multiple addresses.  For
> example:
> https://rdap.apnic.net/ip/136.185.8.145
> has two addresses, returned as two entries in the relevant vcardArray.
>
>
> > However, this can be changed if the community wants something
> > different. We can make abuse-c a multiple attribute so the resource
> > holder can add the customer's and their own abuse-c to an assignment.
> > Or we can change the default behaviour of the query so when an abuse-c
> > is found in an assignment it always returns the resource holder's
> > abuse-c as well. Or we can add a new query flag to return both abuse-c
> > details when available. Or we can modify the abuse-c attribute in some
> > way so the resource holder can choose what a query returns.  Any
> > behaviour is possible as long as you define what behaviour you want
> > and the community finds it useful.
>
>
> I don't know if the current settings allows to enter a comma-separated list as
> an abuse-c string value.  Most often, the abuse-c value is an email alias.  So,
> I don't see why people would enter several addresses if they can manage the
> aliases.
>
> IMHO, it makes more sense to store multiple addresses if they can be added by
> different people.
>
>
> jm2c
> Ale
> --
>
>
>
>
>
>
> --
>
> To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/anti-abuse-wg