Re: [anti-abuse-wg] Seeking Input on the Future of the Anti-Abuse Working Group

[Alessandro Vesely]

On Fri 10/May/2024 13:57:44 +0200 Nick Hilliard wrote:

Serge,

there's been extensive debate on AAWG over the years about the principles 
behind your additional suggestions below, but very little consensus. If 
sanctioning is added to the charter of a new security-wg, this lack of 
consensus is likely to continue, and the only outcome will be that the WG will 
be distracted from other productive output.



Sanctioning has various meanings, from penalties and coercive measures to 
hinder or discouragement.  Before putting that into the charter we should 
discuss and reach consensus about what meaning we exactly mean, which includes 
clarifying what leeway is the RIPE NCC allowed.  At a minimum, listing proven 
bad actors must be possible.



I understand why you might want it in there, but punitive action is not 
within the remit of the RIPE NCC. Similarly on point 2, advocacy is 
important, but requirement / enforcement is out of scope for both the RIPE 
Community and RIPE NCC.



Implementing solutions and utilities is certainly in scope.


Best
Ale



Serge Droz via anti-abuse-wg wrote on 10/05/2024 07:21:


Hi Leo

It's more about sharpening the focus. I colored this red below. I feel 
eventually the RIPE NCC must adapt stronger policies to punish non-action or 
disregard of action. I think it would be better if this WG comes up with such 
policies which the RIPE NCC can then adopt (or not) rather than the RIPE NCC 
having to react to external pressure, e.g. from policy makers, in particular 
the EU. I'm sure one can formulate this much better. I firmly believe, that 
there is no way around stronger regulation, and I'd much rather see this 
coming from this community than form the outside. The regulators i see and 
work with are increasingly irritated and react with totally inadequate 
demands, which I wont reproduce here.


 1. Identifying and analyzing emerging security threats and vulnerabilities
affecting Internet infrastructure.
 2. Collaborating with stakeholders, in particular the RIPE community, to
develop and advocate and implement best practices, guidelines, and
standards for securing Internet resources.
 3. Facilitating information sharing and cooperation among network operators,
law enforcement, and relevant entities to mitigate security risks.
 4. Providing education, training, and outreach initiatives to raise
awareness of security issues and promote best practices adoption.
 5. Develop policies recommendations to the RIPE NCC that help enforcing good
behavior and sanction disregard for faccepted security standards. This
includes the definition of acceptable minimal standards.

Best regards
Serge



--

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

Re: [anti-abuse-wg] Co-Chair selection

[Alessandro Vesely]

On Tue 07/May/2024 11:37:10 +0200 Markus de Brün wrote:
Brian is willing to accept his nomination. Tobias and I are happy to continue 
to work with him.



All well, then.  My full support to all three of you.


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

Re: [anti-abuse-wg] Reverse DNS delegations

[Alessandro Vesely]

On Mon 08/Apr/2024 12:19:15 +0200 Gert Doering wrote:

On Mon, Apr 08, 2024 at 12:10:57PM +0200, Alessandro Vesely wrote:


Delegations don't seem to be generated from the database.  How is that
supposed to work?


They are, but maybe not for the highest level.

Like, 8.0.6.0.1.0.0.2.ip6.arpa - that's our space, 2001:608::/32, and
the reverse DNS delegation was done (back then, in August 2002) via
the DB entry, and I'm assured it still works that way.



Yup, that matches:

$ dig 8.0.6.0.1.0.0.2.ip6.arpa ns

; <<>> DiG 9.18.24-1-Debian <<>> 8.0.6.0.1.0.0.2.ip6.arpa ns
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26275
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 7

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: f5890ae0f4d0b45601006613c858ab439750be740ddf (good)
;; QUESTION SECTION:
;8.0.6.0.1.0.0.2.ip6.arpa.  IN  NS

;; ANSWER SECTION:
8.0.6.0.1.0.0.2.ip6.arpa. 43200 IN  NS  ns4.dns.space.net.
8.0.6.0.1.0.0.2.ip6.arpa. 43200 IN  NS  ns.ripe.net.
8.0.6.0.1.0.0.2.ip6.arpa. 43200 IN  NS  ns.space.net.
8.0.6.0.1.0.0.2.ip6.arpa. 43200 IN  NS  ns3.dns.space.net.

...

$ whois -h whois.ripe.net -T domain -d 2001:608::
% This is the RIPE Database query service.
% The objects are in RPSL format.
%
% The RIPE Database is subject to Terms and Conditions.
% See https://apps.db.ripe.net/docs/HTML-Terms-And-Conditions

% Note: this output has been filtered.
%   To receive output for a database update, use the "-B" flag.

% Information related to '8.0.6.0.1.0.0.2.ip6.arpa'

domain: 8.0.6.0.1.0.0.2.ip6.arpa
descr:  SpaceNET IPv6 Space, reverse delegation (new style)
admin-c:SVB
tech-c: SPCN-RIPE
zone-c: SPCN-RIPE
nserver:ns.ripe.net
nserver:ns.space.net
nserver:ns3.dns.space.net
nserver:ns4.dns.space.net
mnt-by: SPACENET-N
created:2002-08-19T13:31:57Z
last-modified:  2016-12-07T21:11:25Z
source: RIPE

...


Thanks
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

Re: [anti-abuse-wg] Reverse DNS delegations

[Alessandro Vesely]

On Sun 07/Apr/2024 20:33:28 +0200 Gert Doering wrote:

On Sun, Apr 07, 2024 at 01:44:45PM -0400, John Levine wrote:
If you care about rDNS, you need to find a better ISP that meets your 
needs.  Then tell the old one why you left.


That seems to be a problem in Italy these days - few ISPs offer IPv6 
at all, so finding one that does IPv6 *and* rDNS seems hard.


(In Germany, there's competition on the ISP market, but I'm not sure 
there are many that actually delegegate out /48s - and I'm not sure 
how many of those that do provide reverse DNS actually permit customers 
to put in records of their choice, and not just auto-generated PTRs)



I counted 2101 lines in the Italian LIRs page[*] and 4302 in the German one[†] 
(including ~20 lines of header/ footer).


Unfortunately, those lists say nothing about what kind of services each ISP 
does.  I wonder if filling those tables with attributes that would be useful to 
prospect customers is something that RIPE members want RIPE to do...



Best
Ale
--

[*] https://www.ripe.net/membership/indices/IT.html
[†] https://www.ripe.net/membership/indices/DE.html





--

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

Re: [anti-abuse-wg] Reverse DNS delegations

[Alessandro Vesely]

On Sun 07/Apr/2024 16:47:37 +0200 Semisol via anti-abuse-wg wrote:

On 7.04.2024 15:42, Alessandro Vesely wrote:


BTW, how should one search DB objects like 2.0.a.2.ip6.arpa?  I can search it 
in the DNS but not in https://apps.db.ripe.net/db-web-ui/query



-T domain -d 

I believe you can also use the more/less specific flags with that query but I 
didn't try.



Thanks, that apparently works.  However, -T domain -d 2a02:: finds 
0.0.0.0.2.0.a.2.ip6.arpa. It seems to prepend a variable number of zeroes and 
cite the wrong name servers (see queries below).  Shouldn't it find 
2.0.a.2.ip6.arpa?  That domain exists, although it has no name servers.


The parent zone, 0.a.2.ip6.arpa, has lots of international NSes, none of which 
matches the ones returned by the database queries.


Delegations don't seem to be generated from the database.  How is that supposed 
to work?



- queries -

$ whois -h whois.ripe.net -T domain -d 2a02::
% This is the RIPE Database query service.
% The objects are in RPSL format.
%
% The RIPE Database is subject to Terms and Conditions.
% See https://apps.db.ripe.net/docs/HTML-Terms-And-Conditions

% Note: this output has been filtered.
%   To receive output for a database update, use the "-B" flag.

% Information related to '0.0.0.0.2.0.a.2.ip6.arpa'

domain: 0.0.0.0.2.0.a.2.ip6.arpa
descr:  IPv6 reverse delegation SES
nserver:isrvdns1.astra-net.com
nserver:isrvdns2.astra-net.com
nserver:isrvdns3.astra-net.com
...


$ dig 0.0.0.0.2.0.a.2.ip6.arpa ns
;; communications error to ::1#53: timed out
...

$ dig @isrvdns1.astra-net.com 0.0.0.0.2.0.a.2.ip6.arpa ns
;; communications error to 212.56.224.20#53: timed out
;; communications error to 212.56.224.20#53: timed out
;; communications error to 212.56.224.20#53: timed out

; <<>> DiG 9.18.24-1-Debian <<>> @isrvdns1.astra-net.com 
0.0.0.0.2.0.a.2.ip6.arpa ns

; (1 server found)
;; global options: +cmd
;; no servers could be reached

$ dig @isrvdns2.astra-net.com 0.0.0.0.2.0.a.2.ip6.arpa ns
;; communications error to 212.56.224.21#53: timed out
;; communications error to 212.56.224.21#53: timed out
;; communications error to 212.56.224.21#53: timed out

; <<>> DiG 9.18.24-1-Debian <<>> @isrvdns2.astra-net.com 
0.0.0.0.2.0.a.2.ip6.arpa ns

; (1 server found)
;; global options: +cmd
;; no servers could be reached

$ dig @isrvdns3.astra-net.com 0.0.0.0.2.0.a.2.ip6.arpa ns
;; communications error to 213.169.107.4#53: timed out
;; communications error to 213.169.107.4#53: timed out
;; communications error to 213.169.107.4#53: timed out

; <<>> DiG 9.18.24-1-Debian <<>> @isrvdns3.astra-net.com 
0.0.0.0.2.0.a.2.ip6.arpa ns

; (1 server found)
;; global options: +cmd
;; no servers could be reached


$ dig 0.a.2.ip6.arpa ns

; <<>> DiG 9.18.24-1-Debian <<>> 0.a.2.ip6.arpa ns
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32256
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 9

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: b9ca8f96dd329dbf01006613bf18d99a4c9d9cbff52a (good)
;; QUESTION SECTION:
;0.a.2.ip6.arpa.IN  NS

;; ANSWER SECTION:
0.a.2.ip6.arpa. 78819   IN  NS  ns3.lacnic.net.
0.a.2.ip6.arpa. 78819   IN  NS  ns4.apnic.net.
0.a.2.ip6.arpa. 78819   IN  NS  rirns.arin.net.
0.a.2.ip6.arpa. 78819   IN  NS  ns3.afrinic.net.
0.a.2.ip6.arpa. 78819   IN  NS  pri.authdns.ripe.net.

...

$ whois -h whois.ripe.net -T domain -d 2a00::
% This is the RIPE Database query service.
% The objects are in RPSL format.
%
% The RIPE Database is subject to Terms and Conditions.
% See https://apps.db.ripe.net/docs/HTML-Terms-And-Conditions

% Note: this output has been filtered.
%   To receive output for a database update, use the "-B" flag.

% Information related to '0.0.0.0.a.2.ip6.arpa'

domain: 0.0.0.0.a.2.ip6.arpa
descr:  Arcor AG & Co. KG
org:ORG-MAT1-RIPE
admin-c:ANOC1-RIPE
tech-c: ANOC1-RIPE
zone-c: ANOC1-RIPE
nserver:ns1.arcor-ip.de
nserver:ns2.arcor-ip.de
nserver:ns3.arcor-ip.de
created:2006-03-14T11:25:21Z
last-modified:  2016-11-07T14:07:33Z
source: RIPE
mnt-by: ARCOR-MNT
remarks:Unmaintained reverse domain object.
remarks:Address prefix maintainer(s) added by RIPE NCC.
remarks:For more information see:
remarks:http://www.ripe.net/db/support/security/domain/syntax.html


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

Re: [anti-abuse-wg] Reverse DNS delegations

[Alessandro Vesely]

On Sat 06/Apr/2024 19:54:27 +0200 Randy Bush wrote:
Why isn't it possible to gain a delegation by proving number 
assignment?

Because your ISP can't be bothered.

Is such unbotherability legitimate?


these years, it is one of the things when considering a provider from 
which one gets address space.


part of the problem is that this used not to be the case.  "rdns is not 
really useful" was the common thought.  so many isps did not pay it much 
attention.  now, more and more services are using rdns mapping to defend 
against crapola.  so it has become useful, and quite needed in some 
cases.


but it is notalways easy to justify to management the costs of cleaning 
it up, often involving your provider, sometimes your provider's 
provider, and on up the chain.



RIPE could at least reproach those LIRs that have an inet6num but no rDNS 
delegation to it.


BTW, how should one search DB objects like 2.0.a.2.ip6.arpa?  I can search it 
in the DNS but not in https://apps.db.ripe.net/db-web-ui/query



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

Re: [anti-abuse-wg] Reverse DNS delegations

[Alessandro Vesely]

On Sat 06/Apr/2024 17:23:27 +0200 Gert Doering wrote:

On Sat, Apr 06, 2024 at 11:52:45AM +0200, Alessandro Vesely wrote:

On Fri 05/Apr/2024 20:19:59 +0200 John Levine wrote:

It appears that Alessandro Vesely  said:

Why isn't it possible to gain a delegation by proving number assignment?


Because your ISP can't be bothered.


Is such unbotherability legitimate?


There's no law against bad customer service... usually the market will
eventually fix this (as in "some other ISP will offer IPv6 and proper
reverse DNS").  For reasons not clear to me, Italian ISPs do take
their time in rolling out IPv6... so maybe a bit more patience will
get you there.



That's right.  Big ISPs play big ads, but only serve mass users.  Small ISPs 
exist, but are hard to find and don't properly advertise what services they do.




(This said, sending mails over IPv6 is a bit of hit and miss anyway,
with Google inventing new requirements on IPv6 connections that are
not there for IPv4...)



I'm trying to use IPv6 only when there's no IPv4, but at times a DNS delay can 
make the server make the wrong choice...



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

Re: [anti-abuse-wg] Reverse DNS delegations

[Alessandro Vesely]

On Fri 05/Apr/2024 20:19:59 +0200 John Levine wrote:

It appears that Alessandro Vesely  said:

Why isn't it possible to gain a delegation by proving number assignment?


Because your ISP can't be bothered.



Is such unbotherability legitimate?

I appreciate the fact that my provider endowed me with a bunch of IPv6 
addresses.  Previous ISPs couldn't put up with it.  However, to have addresses 
and not being able to use them is not much of an advancement.



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

Re: [anti-abuse-wg] Reverse DNS delegations

[Alessandro Vesely]

On Fri 05/Apr/2024 14:41:01 +0200 Michele Neylon - Blacknight via anti-abuse-wg 
wrote:

Have you asked them to setup PTR records?



I did so for IPv4.  They're unable to delegate but can set PTRs.

For IPv6, they don't have delegation for their own range, so cannot possibly 
resolve mine.



We usually do it for our clients, so I’ve no idea how others handle it



Why can't users of a given range set up their own delegation?  I know it should be 
hierarchical, but in case RIPE did not delegate anything (found SOA 0.a.2.ip6.arpa. 
dns.ripe.net) couldn't they delegate directly after proof of "ownership"?


Best
Ale




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

I have sent this email at a time that is convenient for me. I do not expect you 
to respond to it outside of your usual working hours.


From: anti-abuse-wg  on behalf of Alessandro Vesely 

Date: Friday, 5 April 2024 at 13:01
To: anti-abuse-wg 
Subject: [anti-abuse-wg] Reverse DNS delegations
[EXTERNAL EMAIL] Please use caution when opening attachments from unrecognised 
sources.

Hi all,

what's the policy for reverse delegation?  My provider assigned me a 
2a02:29e1:500:6c00::/56.  Great.  However they didn't delegate reverse DNS.  
Indeed, their own 2a02:29e1::/32 has no delegations:

; <<>> DiG 9.18.24-1-Debian <<>> 1.e.9.2.2.0.a.2.ip6.arpa ns
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 19800
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: cad8ae482b0e559c0100660fe49763aa815e05fda159 (good)
;; QUESTION SECTION:
;1.e.9.2.2.0.a.2.ip6.arpa.  IN  NS

;; AUTHORITY SECTION:
0.a.2.ip6.arpa. 3600IN  SOA pri.authdns.ripe.net. 
dns.ripe.net. 1712314758 3600 600 864000 3600


Now there are mail servers which reject mail if they don't find a matching PTR:

   <<< 554 resimta-c2p-559421.sys.comcast.net 
resimta-c2p-559421.sys.comcast.net 2a02:29e1:500:6c00::4 Comcast requires that all mail 
servers must have a PTR record with a valid Reverse DNS entry. Currently your mail 
server does not fill that requirement. For more information, refer to: 
https://postmaster.comcast.net/smtp-error-codes.php#554


Why isn't it possible to gain a delegation by proving number assignment?


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




--

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

[anti-abuse-wg] Reverse DNS delegations

[Alessandro Vesely]

Hi all,

what's the policy for reverse delegation?  My provider assigned me a 
2a02:29e1:500:6c00::/56.  Great.  However they didn't delegate reverse DNS.  
Indeed, their own 2a02:29e1::/32 has no delegations:

; <<>> DiG 9.18.24-1-Debian <<>> 1.e.9.2.2.0.a.2.ip6.arpa ns
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 19800
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: cad8ae482b0e559c0100660fe49763aa815e05fda159 (good)
;; QUESTION SECTION:
;1.e.9.2.2.0.a.2.ip6.arpa.  IN  NS

;; AUTHORITY SECTION:
0.a.2.ip6.arpa. 3600IN  SOA pri.authdns.ripe.net. 
dns.ripe.net. 1712314758 3600 600 864000 3600


Now there are mail servers which reject mail if they don't find a matching PTR:

 <<< 554 resimta-c2p-559421.sys.comcast.net resimta-c2p-559421.sys.comcast.net 
2a02:29e1:500:6c00::4 Comcast requires that all mail servers must have a PTR record with 
a valid Reverse DNS entry. Currently your mail server does not fill that requirement. 
For more information, refer to: https://postmaster.comcast.net/smtp-error-codes.php#554


Why isn't it possible to gain a delegation by proving number assignment?


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

Re: [anti-abuse-wg] Seeking Input on the Future of the Anti-Abuse Working Group

[Alessandro Vesely]

Hi chairs, all,

I think this is a great working group.  Periods of silence are physiological; 
for example, they may arise after a thorough discussion about a proposed point 
which is eventually found to be unfeasible.  The idea to force every abuse-c to 
actually receive email messages and act on them suits that example.


If there are security topics that the current charter doesn't cover, 
re-chartering is certainly a good idea.  The chairs are great, especially 
Brian, and I see no reason to select new ones.  Closing the working group would 
be a matter of regret and I hope it's not going to happen.



Best
Ale


On Thu 21/Mar/2024 10:09:00 +0100 Markus de Brün wrote:


Dear Anti-Abuse Working Group Members,


As Co-Chairs, we have been carefully monitoring the discussions on the mailing 
list and are concerned about the current state of stagnation and lack of progress.


After consideration and discussion among the Co-Chairs, we believe it is 
necessary to initiate a dialogue regarding the future direction of our working 
group. Some action is needed to revitalise our efforts.



The Co-Chairs have discussed a number of options, both between ourselves and 
with the RIPE Chair Team. However, due to the lack of general engagement, and 
the circular conversations on the list, we see three viable options at this point::



 1.

Re-charteringthe working group, possibly transitioning it into a Security
Working Group to broaden our scope and address related concerns
comprehensively. (The current charter can be found here:
https://www.ripe.net/community/wg/active-wg/anti-abuse/
)

 2.

It is possible we are simply the wrong Co-Chairs at the wrong time, so we
can step-downand allow the working group to select new Co-Chairs.

 3.

Closing the working groupif consensus cannot be reached on a viable path
forward.


It may be that there are people in the Working Group who are eager to propose 
new policies, or embark on a project to systematically examine the abuse 
ecosystem, but over the last year or so, there has been no evidence this is the 
case.



However, we firmly believe that the best course of action is to engage all 
members of the Anti-Abuse Working Group in an open and transparent discussion 
about the challenges we face and the opportunities for positive change. Your 
input and perspectives are invaluable in shaping the future of our community.



Therefore, we are inviting you to participate actively in this crucial 
conversation. We encourage you to share your thoughts, suggestions, and 
concerns regarding the current state of the working group and your vision for 
its future direction.



Your input will help inform our next steps and guide the evolution of the 
Anti-Abuse Working Group. We encourage you to share your feedback openly on the 
mailing list so that all members can participate in the conversation. We hope 
to discuss the status at RIPE88.



Thank you for reading this far. We look forward to your active participation in 
shaping the future of the Anti-Abuse Working Group.



Best regards,

Brian, Tobias, Markus





--

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

Re: [anti-abuse-wg] IS3C public consultation on an alternative narrative to deploy Internet standards

[Alessandro Vesely]

On Tue 12/Mar/2024 17:24:08 +0100 David Conrad wrote:

On Mar 12, 2024, at 1:57 AM, Alessandro Vesely  wrote:
DNSSEC everywhere would make more sense than HTTPS everywhere, which instead 
won the hype. 


I figure enabling DNSSEC validation everywhere and signing what makes sense 
after doing a cost/benefit trade off would be the rational way to go.  As 
signing technologies get more mature, the cost goes down and even the marginal 
benefit of signing everything would be justified.



Right, and I'd guess the number of operators involved in switching to DNSSEC is 
less than that for HTTPS.




Being sure to connect to the IP designated by the
domain is essential, while encrypting every page of sites like, say,
wikipedia is just wasting cycles.


As Randy points out, TLS also gives you authentication (as long as you trust 
the myriad CAs) and with more granularity than the IP address.



Right, and let's note that the chain of trust is hierarchical for DNSSEC, which 
makes for a clear cut PKI.  HTTPS certificate are based on browser/ system/ 
distro/ user policy choices, a rather hazy infrastructure.



On wasting cycles, if you only encrypt the sensitive stuff, you give away the 
fact that you’re communicating sensitive stuff when you encrypt.


However, I suspect this isn’t particularly in the charter of this mailing list…



Well, the OP topic is DNSSEC and _Resource_ Public Key Infrastructure (RPKI), 
which is similar in principle to the domain based hierarchy of DNSSEC.



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

Re: [anti-abuse-wg] IS3C public consultation on an alternative narrative to deploy Internet standards

[Alessandro Vesely]

On 11/03/2024 22:30, John Levine wrote:

It appears that Michele Neylon - Blacknight via anti-abuse-wg 
 said:


Several ccTLD registries have given discounts for DNSSEC.

What is unclear is how many of the domains with DNSSEC enabled are in active 
use, so the lack of �problems� could be simply down to a complete lack of us / 
ignorance that the technology was enabled.

My main issue with focus on DNSSEC is that it is seen being a �good use� of 
resources, so small registries who should invest in other things that are 
fundamentally more important feel obliged to enable
it. There�s also the entire �I�ve got DNSSEC so now my domain / site / service 
is secure� belief. Much like people who think that smacking an SSL cert on 
their site magically renders it secure.


It makes sense if you're likely to be a phish target or you're
sophisticated enough to use DANE. DNSSEC works pretty well for Comcast.

I agree that for random little private domains the benefit is marginal.



DNSSEC everywhere would make more sense than HTTPS everywhere, which 
instead won the hype.  Being sure to connect to the IP designated by the 
domain is essential, while encrypting every page of sites like, say, 
wikipedia is just wasting cycles.



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

Re: [anti-abuse-wg] Abuse Report ignored. What to do as next?

[Alessandro Vesely]

On Tue 05/Dec/2023 15:17:59 +0100 Gert Doering wrote:

On Mon, Dec 04, 2023 at 09:40:22AM +, Michele Neylon - Blacknight via 
anti-abuse-wg wrote:

The claim is that the change in policy had an impact in other regions.
If that is true then where is the data to backup that assertion?


Especially: saying "it feels less painful to send abuse complaints", aka
"there is less bounces" is not the same as "there is less abuse" or "more
people properly handle abuse requests directed to them now"

"Getting a bounce from an ill-maintained abuse mailbox" might actually
be more insightful than "the mail is delivered just fine, but then ignored"
- nothing in these proposals will force the receiver to deal with the mail
properly, so getting abounce actually sends a clear signal "please just
block this target network" instead of raising hopes.



That's right.  Rather than having, for example:

Responsible organisation: Oliv Evelyn
Abuse contact info: nore...@lighost.com
inetnum: 162.19.141.192 - 162.19.141.195
netname: OVH_293642614

where the address obviously bounces, it would be clearer to have an established 
way to say there is no abuse team.  Empty, noservice@. or anything definite.


Publishing a database containing rubbish is not a good service to the Internet 
community anyway.


Whether that checking can lead to a characterization, via listing, that mail or 
web operators can use when vetting external input can be established at a 
further time.



Best
Ale
--


have you enabled IPv6 on something today...?


On it, but will take a while...





--

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

Re: [anti-abuse-wg] Abuse Report ignored. What to do as next?

[Alessandro Vesely]

On Thu 30/Nov/2023 12:40:46 +0100 Laura Atkins wrote:

What happens if / when someone doesn’t?



A minimal, yet useful reaction would be to remove their abuse PoC from RDAP 
pages.  If the convention is clear that network operators without abuse-c are 
non-responders, it is easy for all the others to add the corresponding IPs to 
their drop lists.  Ripe NCC could even distribute non-responders lists.


A motion to reclaim wasted resources can be set up at a later time.


Best
Ale


On 30 Nov 2023, at 10:47, Matthias Merkel  wrote:

The proposal is to send verification emails to abuse mailboxes and have a 
link in them clicked, right? I would have no objection to that.


Is there more that is being proposed in this proposal specifically?

—
Maria Merkel

This email was sent by [company]. Any statements contained in this email are 
personal to the author and are not necessarily the statements of the company 
unless specifically stated.


Novecore and Staclar are collective trading names of Novecore Ltd., 
registered in England and Wales under company number 11748197, Novecore 
Licensing Ltd., registered in England and Wales under company number 
11544982, Staclar Carrier Ltd., registered in England and Wales under company 
number 12219686, Staclar Financial Services Ltd., registered in England and 
Wales under company number 13843292 (registered offices 54 Portland Place, 
London, UK, W1B 1DY); Novecore Professional Services Ltd., registered in 
England and Wales under company number 13965912 (registered office 13 
Freeland Park, Wareham Road, Poole, UK, BH16 6FA); Novecore (Estonia) OÜ, 
registered in Estonia under registry code 16543205 (local contact Baltic 
Business Services OÜ, Narva mnt 5, 10117 Tallinn, Estonia); Novecore (USA) 
Inc., registered in Delaware under file number 6707907, Novecore Licensing 
(USA) LLC, registered in Delaware under file number 4030866, and Staclar, 
Inc., registered in Delaware under file number 7413401 (registered agents The 
Corporation Trust Company, Corporation Trust Center, 1209 Orange St, 
Wilmington DE 19801, USA). Novecore Licensing Ltd. is registered for VAT in 
the United Kingdom under VAT registration number 347 4545 80. Novecore 
(Estonia) OÜ is registered for VAT in the European Union under VAT 
registration number EE102518979. Novecore Professional Services Ltd. is a 
trust or company service provider registered with and supervised by HM 
Revenue & Customs under the Money Laundering, Terrorist Financing and 
Transfer of Funds (Information on the Payer) Regulations 2017 (registration 
number XMML0178208). Staclar Financial Services Ltd. is an Annex 1 
financial institution registered with and supervised by the Financial Conduct 
Authority under the Money Laundering, Terrorist Financing and Transfer of 
Funds (Information on the Payer) Regulations 2017 (firm reference number 
989521). Registration is not equivalent to authorisation and is not an 
endorsement to do business with a firm. Staclar Financial Services Ltd. is 
not an authorised person within the meaning of the Financial Services and 
Markets Act 2000 and does not review, approve, or endorse financial 
promotions for securities issues it is involved in or provide any form of 
investment advice.

Sent from Front
On November 30, 2023 at 11:45 AM GMT+1 ops.li...@gmail.com 
 wrote:


There is somewhat more being proposed than that bare minimum of due 
diligence but none of this makes ripe ncc a regulator any more than a 
pharmacist verifying a prescription becomes the FDA


--srs
---
*From:* Matthias Merkel >

*Sent:* Thursday, November 30, 2023 4:03:07 PM
*To:* Suresh Ramasubramanian >; Leo Vegoda >
*Cc:* anti-abuse-wg@ripe.net  
mailto:anti-abuse-wg@ripe.net>>

*Subject:* Re: [anti-abuse-wg] Abuse Report ignored. What to do as next?
I have already noted that I have no objections to a proposal solely to 
verify abuse mailbox functionality, but that we should be careful adding 
anything further. Perhaps I wasn't clear enough in this:


Arguably a proposal to simply require verification of the abuse mailbox
does not make the NCC a regulator (and, in fact, I think the NCC already
does this with ASNs), but I do not see how this would be an effective
measure.

Making further requirements would make the NCC a regulator, and this may
be dangerous precedent.


Regarding the potential that government regulators will put rules in place 
if we don't, I don't think this is a big concern here. Many governments 
already do have those rules and already supervise network operators in their 
countries. The issue in this specific case is that some countries simply 
don't care, and do not have laws or regulations around the issue.


—
Maria Merkel

This email was sent by 

[anti-abuse-wg] Is SWIP dead?

[Alessandro Vesely]

Hi all,

I heard about the Shared WHOIS Project from MIPSpace, an IP reputation database 
who reads in Cc:.  They say it should be available at every RIR, but at RIPE I 
only found this:

https://ftp.ripe.net/ripe/inaddr/arin-templates/swipinstruction.txt

It is a 1998 article with guidelines for using it.  Does it have any validity?

I also found a swip.net site, with no content but an expired certificate.


IP reputation databases want a proof that a domain has exclusive use of an 
address or range thereof.  There seem to be obvious reasons for such a 
requirement.  And black lists are still a strong anti-spam tool.  However, ISPs 
don't consider it worth, or reserve registration to 1st class customers.


While the question in the subject is somewhat rhetorical, isn't there any other 
way to solve this problem?  Any rule or service RIPE might undertake?



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

Re: [anti-abuse-wg] Cost-benefit of registering reassignments

[Alessandro Vesely]

On Wed 19/Apr/2023 15:39:48 +0200 Michele Neylon - Blacknight via anti-abuse-wg 
wrote:

How big an IP allocation do you have?



/29, which I think is the minimum size.


As an LIR we routinely assign blocks of IPs to clients with more than X IPs or 
blocks etc., and give them their own abuse-c etc.,



What's X?  And doesn't that depend on the kind of link (PON, DSL, P2P)?



But we wouldn’t do it for a single IP.

Though tbh it sounds more like an issue with the block list than anything to do 
with the IP address, your ISP or anyone else.



MIPSpace.com.  They're ID 595 in Valli's multirbl list, but they're not tested 
when you run the lookup.



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

[anti-abuse-wg] Cost-benefit of registering reassignments

[Alessandro Vesely]

Hi all,

I found a (minor) black list who blocks my new IP.  They say to not even try to 
ask for delisting unless I am the official owner of the IP.  They observe that 
"rwhois/SWIP is normally offered free of charge by most providers".


Sounds oldish, doesn't it?  RDAP is working well, at least for numbers, and I 
see no reason to mention rwhois,  SWIP is mentioned in a 1993 RFC[*] in the 
context of a move toward an "X.500 distributed database model".  Where are we 
now?  I see ARIN has relatively recent blogs on that.[†]


My ISP says that registration is reserved to non-GPON "privileged fiber" whose 
costs start at around 10x ordinary fares.  How much does RIPE charge for 
registering reassignments?


Why isn't it possible for end-user to claim IP "ownership"?  If the IP database 
were dependable, there wouldn't be so many site-verification TXT records in the 
DNS.


I use RDAP to complain about network abuse, and the average response I get is 
that they passed the complaint to their customer.  Some times ISPs make 
pressure on the customer to fix security leaks, so this seems good.  In some 
other cases, ISPs ignore complaints, whereas the operator might have been 
interested.  Alternatively, complaints might be sent in Cc: to national CERTs, 
LEAs, AbuseIPDB, and the like.


Simple reassignments can be done without changing abuse-c.  Does that still 
imply any responsibility?



Best
Ale
--

[*] https://datatracker.ietf.org/doc/html/rfc1491#section-2.2.4.1
[†] https://www.arin.net/blog/2018/05/03/which-swip-type-is-right-for-you/








--

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

Re: [anti-abuse-wg] Adding a "Security Information" contact?

[Alessandro Vesely]

Hi Max,


thank you for your reply and explanations.  Some more comments/ 
questions inline:


On Sun 03/Jul/2022 23:25:28 +0200 Max Grobecker wrote:

Am 20.06.22 um 18:04 schrieb Alessandro Vesely:

Our abuse mailbox is not overflowing with these, of course, but it 
makes semi-automated handling a bit painful. For example, we would 
like to forward these information to our customers, but we wont 
need to take further action on this, because we refuse to break 
into the offices of our customers at night and patch their software.
sorry to bother, but I hardly got that.  Are these IP-driven 
messages?  Don't CERTs lookup the abuse address with RDAP or WHOIS?


The reports we get from CERT-BUND are highly IP focused. I cited one 
of these report as an example at the end of this mail.
In general, I think these organizations we get mail from are 
downloading the database from RIPE and are using an offline version.



It is very expensive.  Do you think they only do European IPs, or do 
they have specialized procedures for each RIR?


Perhaps RIPE provides for maintaining remote copies of the database, 
but a caching RDAP tool would be more standard compliant.



Why doesn't the abuse address point (in)directly to the relevant IP 
user?  That is, what's wrong in automatically forwarding CERT's 
security notices?  I cannot understand how doing so entailS 
obligations to reach the customer's premises at night.


If I point the abuse address directly to an address controlled by the 
customer, I don't get any notices - regardless of security information 
or real abuse.
And I'm interested in the latter one, as I want to stop the abuse, of 
course ;-)
Therefore all abuse reports are handled by our internal system to be 
automatically escalated to the appropriate internal and external 
contacts.



What I'd be curious to know is whether automatic escalation is based 
on per-customer abuse addresses or on parsing message contents looking 
for IPs.


Per-customer address is something like asn65...@bc.grobecker.info or 
ip192.0.2.8/2...@sc.grobecker.info, which can be forwarded to the 
relevant (big or small) customer without actually opening the 
messages, but still maintaining a copy of them.  Doing so requires 
more work for maintaining the database, but less work for forwarding 
messages.



But for notices like "Oh, we think there might be a vulnerable service 
reachable on that IP" we don't want that whole escalation thing.
Also, most of these notices contain a list of addresses, but 
sometimes, these lists are not stable parseable because there seems to 
be no standardized format.
Reports we receive from CERT-BUND come with a CSV file which we are 
able to parse - but in the last months there came several new other 
services with their own data formats and I suspect, there will come more.



And the CSVs refer to multiple customers?


If I could "route" these reports directly to the customer, this would 
improve reporting speed and keep these away from our regular abuse 
desk with escalations and all that stuff.



I understand you don't want your abuse desk to get involved in 
checking whether, for example, an open DNS does in fact amplify 
queries if it is open.  Is that the difference between forward and 
escalate?


Using a different field entails the extra burden to educate 
organizations like CERT-BUND to use the appropriate reporting address 
based on the kind of report.


For RDAP, those addresses could be tagged as less preferred.  Some 
RIRs do so, leaving the actual meaning a bit obscure, though. 
Alternatively, RFC 7483 provides for a "notifications" role, which in 
theory applies to an associated object.



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

Re: [anti-abuse-wg] Adding a "Security Information" contact?

[Alessandro Vesely]

On Tue 07/Jun/2022 20:14:49 +0200 Ángel González Berdasco via anti-abuse-wg 
wrote:

Gert Doering wrote:


"whois, as in 'this particular way users interface with the DB'" :-)

(I'm aware it's the server doing this - which makes changing the 
implementation easier, as it's "just one place" - but in the end,  
"it needs to be done" which was the point I tried to make ;-) )


Indeed. And many other tools interacting with the RIPE DB to find abuse 
contacts, I'm afraid. The uptake of those new attributes would 
necessarily be relatively slow.



People who send not only to RIPE IPs will never uptake, unless this is going to 
be a global change, including RDAP specs.


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

Re: [anti-abuse-wg] Adding a "Security Information" contact?

[Alessandro Vesely]

Hi,

On Tue 07/Jun/2022 11:45:05 +0200 Max Grobecker wrote:
Our abuse mailbox is not overflowing with these, of course, but it makes 
semi-automated handling a bit painful. For example, we would like to forward 
these information to our customers, but we wont need to take further action 
on this, because we refuse to break into the offices of our customers at 
night and patch their software.


sorry to bother, but I hardly got that.  Are these IP-driven messages?  Don't 
CERTs lookup the abuse address with RDAP or WHOIS?


Why doesn't the abuse address point (in)directly to the relevant IP user?  That 
is, what's wrong in automatically forwarding CERT's security notices?  I cannot 
understand how doing so entailS obligations to reach the customer's premises at 
night.



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

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

[Alessandro Vesely]

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

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

[Alessandro Vesely]

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







--

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

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

[Alessandro Vesely]

Hi,

On Fri 21/Jan/2022 19:40:40 +0100 denis walker wrote:

On Fri, 21 Jan 2022 at 13:03, Alessandro Vesely  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
--







--

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

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

[Alessandro Vesely]

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 abuse-customer@isp.example, 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
--









--

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

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

[Alessandro Vesely]

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




--

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

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

[Alessandro Vesely]

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

Re: [anti-abuse-wg] Is there any analysis on root causes of mail account break-ins?

[Alessandro Vesely]

Hi,

On Wed 17/Nov/2021 09:12:13 +0100 Hans-Martin Mosner wrote:


Here I want to focus on hacked mail accounts. I can think of two major root 
causes but I have no idea about their relative significance:



I agree with Steve and Ángel that the main causes are reused passwords and 
phishing.



  * Easily guessable passwords, with two subcauses for exploits:
  o Brute force authentication attempts - I'm seeing them regularly, and
the most egregious networks (e.g. 5.188.206.0/24) are fully blocked at
our mailserver, but some mailops are less struct about blocking such
abusers.



I used to look at what passwords they try.  Those brute force attacks are so ridiculous 
that I agree with those who call them "clowns".

About that network, I only collected 40 addresses (15.7%) of it.  Here's the 
list:

list records in IP range 5.188.206.0-5.188.206.255,
min age 0 secs, max age 1637146807 secs, min prob 0=0.00%, max prob 
2147483647=100.00%.
 IP  CREATED   PROB.  BLOCKEDPACKETS  UPDATED  DECAY  
THRESHOLD CAUGHT DESCRIPTION
   5.188.206.98 Aug-2021  27.83% Oct-2021 184598 Oct-2021 2.7648e+06
  7 13 SMTP auth dictionary attack
   5.188.206.99 Aug-2021  42.44% Oct-2021 187446 Oct-2021 2.7648e+06
  7 13 SMTP auth dictionary attack
  5.188.206.100 Aug-2021  32.63% Oct-2021 191132 Oct-2021 2.7648e+06
  7 14 SMTP auth dictionary attack
  5.188.206.101 Aug-2021  23.06% Oct-2021 195623 Oct-2021 2.7648e+06
  7 13 SMTP auth dictionary attack
  5.188.206.102 Aug-2021  30.12% Oct-2021 193158 Oct-2021 2.7648e+06
  7 14 SMTP auth dictionary attack
  5.188.206.146 Jul-2021   0.00% Jul-2021  38385 Jul-2021 172800
  3 11 SMTP auth dictionary attack
  5.188.206.147 May-2021   0.00% May-2021   2690 May-2021  43200
  1  6 SMTP auth dictionary attack
  5.188.206.154 Aug-2021  22.50% Oct-2021 199790 Oct-2021 2.7648e+06
  7 13 SMTP auth dictionary attack
  5.188.206.155 Aug-2021  63.96% Oct-2021 200505 Oct-2021 5.5296e+06
  8 14 SMTP auth dictionary attack
  5.188.206.156 Aug-2021  44.10% Oct-2021 188176 Oct-2021 2.7648e+06
  7 13 SMTP auth dictionary attack
  5.188.206.157 Aug-2021  21.81% Oct-2021 201093 Oct-2021 2.7648e+06
  7 12 SMTP auth dictionary attack
  5.188.206.158 Aug-2021  13.69% Oct-2021 186692 Oct-2021 1.3824e+06
  6 16 SMTP auth dictionary attack
  5.188.206.162 Apr-2021   0.00% Apr-2021 16 May-2021  21600
  0  4 Domain does not exist
  5.188.206.163 Apr-2021   0.00% Apr-2021 49 May-2021  21600
  0  6 SPF failure
  5.188.206.164 Apr-2021   0.00% Apr-2021  8 Apr-2021 60
  0  3 SPF failure
  5.188.206.165 Apr-2021   0.00% Apr-2021  9 May-2021 60
  0  3 SPF failure
  5.188.206.166 Apr-2021   0.00% Apr-2021 12 May-2021 60
  0  4 SPF failure
  5.188.206.171 May-2021   0.00%   0 May-2021 60
  0  1 SPF failure
  5.188.206.172 May-2021   0.00%   0 May-2021  21600
  0  1 Domain does not exist
  5.188.206.174 May-2021   0.00%   0 May-2021  21600
  0  1 Domain does not exist
  5.188.206.182 May-2021   0.00% Jun-2021 321619 Jun-2021 691200
  5 13 SMTP auth dictionary attack
  5.188.206.194 Jul-2020  41.18%  52s ago 106607  53s ago 2.7648e+06
  7 24 SMTP auth dictionary attack
  5.188.206.195 Jul-2020  78.44% 570s ago 225627 569s ago 2.7648e+06
  7 25 SMTP auth dictionary attack
  5.188.206.196 Jul-2020  71.04%  54s ago 170925  54s ago 2.7648e+06
  7 58 SMTP auth dictionary attack
  5.188.206.197 Aug-2020  86.35%  51s ago 172424  57s ago 5.5296e+06
  8 37 SMTP auth dictionary attack
  5.188.206.198 Sep-2020  55.70% 572s ago 234734 573s ago 5.5296e+06
  8 34 SMTP auth dictionary attack
  5.188.206.199 Oct-2020  99.24% 571s ago 191169 572s ago 5.5296e+06
  8 23 SMTP auth dictionary attack
  5.188.206.200 Oct-2020  86.89%  45s ago 189656  60s ago 5.5296e+06
  8 23 SMTP auth dictionary attack
  5.188.206.201 Oct-2020  59.52% 686s ago 659987 687s ago 5.5296e+06
  8 30 SMTP auth dictionary attack
  5.188.206.202 Dec-2020  91.54%  57s ago 466233  62s ago 5.5296e+06
  8 25 SMTP auth dictionary attack
  5.188.206.203 Dec-2020  55.00%  42s ago 214836  50s ago 5.5296e+06
  8 23 SMTP auth dictionary attack
  5.188.206.204 Dec-2020  11.66% Aug-2021 374345 Aug-2021 2.7648e+06
  7 25 SMTP auth dictionary attack
  5.188.206.205 Jan-2021  32.61% 

Re: [anti-abuse-wg] Anti-Abuse Training: Questions for the WG

[Alessandro Vesely]

On Sat 23/Oct/2021 01:38:56 +0200 Ronald F. Guilmette wrote:

In message <26f1df33-b958-bed4-f748-f82324d0b...@tana.it>, Alessandro Vesely 
 wrote:


Shouldn't there be a standard for automatically forwarding messages destined
to abuse-c following a path similar to that of RFC 2317 delegations?  I'd love 
if AA training encouraged such behavior.


Although delegation of abuse report handling may sound like a good idea
in theory, in practice it is a tragically bad idea.

What happens when the customer is a spammer and abuse handling is delegated
to that customer?  Google for the term "list washing".

This isn't merely a theoretical possibility.  Digital Ocean has previously
sent me multiple response emails saying quite explicitly that they had
forwarded my spam reports to their spammer customer(s).  Those customers
will then surely cease to spam *me* but will continue to spam everyone
else on the planet.



That'd be an incentive to send spam reports, wouldn't it?



This does not create any meaningful reduction in the global spam load.  It
simply rewards those "responsible" spammers who remove from their target
lists the email addresses of the few "complainers" who nowadays take the time
to report spam.


On the other hand, there are honest mailbox providers who have not realized 
that their system has been hacked, or that their clients' credentials have been 
stolen.  And if you send a complaint to my abuse-c address, I won't get it.


For an easy guess, LIRs who offer services at regular prices —not thousand 
domain discounts— have more of the latter cases.  Still, their budget might not 
be enough for an abuse team capable of looking at each complaint.



Best
Ale

Re: [anti-abuse-wg] Anti-Abuse Training: Questions for the WG

[Alessandro Vesely]

On Fri 22/Oct/2021 23:26:23 +0200 Ángel González Berdasco wrote:

Hello all


Shouldn't there be a standard for automatically forwarding messages
destined to abuse-c following a path similar to that of RFC 2317
delegations?  I'd love if AA training encouraged such behavior.


I don't think the standard should be for automatically forwarding
messages. You would need a standard for *exchanging* the information.
Fields you would need should include IP address being reported, port
(optionally), timestamp, whether this may be shared with the customer
(default yes), RSIT taxonomy of the incident being reported, etc.



Yeah, I didn't mean a capital 'S' Standard.  Rather some common practice.



And then, among the actions that can be taken, automatically forwarding
could be one of them (and probably the less expensive for the abuse-c
owner), but they could choose to process them differently.
But the first step is to match the report with the machine/customer.



If I were LIR.example, I'd set my abuse-c entries to something like:

   abuse-customer1@LIR.example
   abuse-customer2@LIR.example
   ...

That way messages can be forwarded without parsing them; but there's still a 
chance to look at them, if the budget allows it.




Many abuse teams already do that automatically, although I don't know
the amount of guessing needed by the tools on their normal flows.

The first idea that comes to mind when talking about communicating
this would be to create a solution based on X-ARF, but it's not without
its shortcomings, either, so maybe a different way is felt to be
preferable.



plain text, X-ARF, ARF, IODEF, https://xkcd.com/927/

Another way is to send an autoresponse which asks to fill the provider's web 
form, whereby the number of different formats grows unconstrained.


However, it'd be possible for a forwarding LIR.example to ask its clients to 
fill a web form, in order to summarize the complaint and its followup.  Most 
providers only have one or two ISPs, so the number of formats would stay low. 
And that could ease LIR's monitoring.




This is an interesting discussion, although I feel it's a bigger design
issue, significantly more ambitious than the proposal of providing some
abuse training which opened this thread.



Since the training is addressed to LIRs, a schema like the above could at least 
be aired.



Best
Ale

Re: [anti-abuse-wg] Anti-Abuse Training: Questions for the WG

[Alessandro Vesely]

Hi all,

On Mon 18/Oct/2021 18:40:06 +0200 Michele Neylon - Blacknight via anti-abuse-wg 
wrote:



3) If not, would there be other areas of Anti-Abuse training that would be of 
interest?


A lot of hosting providers aren’t LIRs, but are getting IP space from LIRs. 
Maybe providing materials that LIRs could share with their clients would help? 
There  seems to be a lot of ignorance out there.



There are also people who are not hosting providers, but host their own 
server(s) using a handful of IP addresses.  I know mailbox self-providers are 
an endangered species, but they may still happen to have an IP delegation w/o 
abuse-c.  And complainants may prefer to send reports to the top level 
delegate.  However, top level delegate may happen to have non-responding abuse 
teams.  At best, ISPs forward complaints to their clients.

Shouldn't there be a standard for automatically forwarding messages destined to 
abuse-c following a path similar to that of RFC 2317 delegations?  I'd love if 
AA training encouraged such behavior.


Best
Ale
--

[anti-abuse-wg] Abuse address checking

[Alessandro Vesely]

Hi,

it is rather common to find auto-responders at abuse addresses.  For this one, 
however, it took me a minute to understand its intent,


Best
Ale


 Forwarded Message 
Subject: Confirmacion para RIPE
Date: Sun, 17 Oct 2021 04:32:32 +0200
To: ab...@tana.it
Auto-Submitted: auto-replied (vacation)

OK, me llegan los correos!!.

Re: [anti-abuse-wg] Proposed Training on Anti-Abuse

[Alessandro Vesely]

On Wed 17/Mar/2021 15:42:26 +0100 alireza vaziri wrote:
I have attached the draft proposal of the training and it would be great to 
provide us with your feedback



The draft states four general principle.  The 4th is expressed as:

   - The community expects you to handle Abuse in your network
 and keep the resources you have been granted clean

That's very nice and fully agreeable.  However, in today's "object oriented" 
world, I'd rather express it as:


   - The way you handle Abuse in your network is going to
 define the quality of the resources granted to you


jm2c
Ale
--

Re: [anti-abuse-wg] What is YAHOONET?

[Alessandro Vesely]

As someone pointed out off-list, there's plenty of @yahoo.com email addresses.

However, IP addresses for mail seem to use ARIN networks, such as:
A-YAHOO-US2 66.163.160.0-66.163.191.255,
A-YAHOO-US3 209.191.64.0-209.191.127.255,
...
A-YAHOO-US8 67.195.0.0-67.195.255.255,
A-YAHOO-US9 98.136.0.0-98.139.255.255,
...

RIPE's YAHOONET, 77.238.177.0-77.238.177.255, seems to be an abandoned object.

Best
Ale

 Original Message 
Subject: [anti-abuse-wg] What is YAHOONET?
Date: Wed, 17 Mar 2021 09:46:45 +0100
From: Alessandro Vesely 
To: anti-abuse-wg@ripe.net

Hi all,

I'm aware of the various pages that Wikipedia dedicate to Yahoo! and related 
services.  I'm unsure how to treat YAHOONET as an ISP.


The abuse contact they registered at RIPE in 2007 is ab...@yahoo-inc.com.  It 
bounces.  I wrote to network-ab...@cc.yahoo-inc.com asking what address should 
I use for complaints.  I got an automated reply telling me to go to:

https://io.help.yahoo.com/contact/index?page=contact=en_US=PROD_MAIL_ML

That link ultimately redirects to the same host/path with the query string 
replaced by "page=oops".


I had tried to contact someone at Yahoo! before.  I don't think it's worth 
trying again.  So I think I'm going to put YAHOONET in the heavily firewalled 
list of ISPs with no abuse team.  I hesitated because I used to consider Yahoo! 
something big, with possibly many worthy customers.  Is it still so?  I mean, 
would any savvy netizen face the Internet through such an ISP?



Best
Ale
--

[anti-abuse-wg] What is YAHOONET?

[Alessandro Vesely]

Hi all,

I'm aware of the various pages that Wikipedia dedicate to Yahoo! and related 
services.  I'm unsure how to treat YAHOONET as an ISP.

The abuse contact they registered at RIPE in 2007 is ab...@yahoo-inc.com.  It 
bounces.  I wrote to network-ab...@cc.yahoo-inc.com asking what address should 
I use for complaints.  I got an automated reply telling me to go to:
https://io.help.yahoo.com/contact/index?page=contact=en_US=PROD_MAIL_ML

That link ultimately redirects to the same host/path with the query string replaced by 
"page=oops".

I had tried to contact someone at Yahoo! before.  I don't think it's worth 
trying again.  So I think I'm going to put YAHOONET in the heavily firewalled 
list of ISPs with no abuse team.  I hesitated because I used to consider Yahoo! 
something big, with possibly many worthy customers.  Is it still so?  I mean, 
would any savvy netizen face the Internet through such an ISP?


Best
Ale
--

Re: [anti-abuse-wg] UCEPROTECT DNSBL possibly abusive practice and RIPEStat Blacklist entries widget

[Alessandro Vesely]

On Tue 09/Mar/2021 10:37:17 +0100 Christian Teuschel wrote:

Dear colleagues,

Thinking about a course of action - it looks there is an agreement to
have more RBLs on RIPEstat. It would be good to have a list of
candidates that the community feels would be useful. Once we have this
list, we can perform a feasibility analysis and present this to the
community.  We can then take it from there.



May I suggest this list of 345 RBLs?
http://multirbl.valli.org/list/


Best
Ale
--

Re: [anti-abuse-wg] UCEPROTECT DNSBL possibly abusive practice and RIPEStat Blacklist entries widget

[Alessandro Vesely]

On Thu 04/Mar/2021 17:16:34 +0100 Christian Teuschel wrote:

If I am reading the feedback in this discussion correctly, the sentiment
is leaning towards adding more RBLs instead of less and if that is the
case we are going to look into how and when we can achieve this. Please
let me know if that is aligned with your requirements/expectations.



https://stat.ripe.net/data-sources mentions spamhaus and uceprotect.

Couldn't it just mention multirbl.valli.org?


Best
Ale
--

Re: [anti-abuse-wg] UCEPROTECT DNSBL possibly abusive practice and RIPEStat Blacklist entries widget

[Alessandro Vesely]

On Tue 02/Mar/2021 12:12:33 +0100 Esa Laitinen wrote:


On 02.03.21 10:49, Vittorio Bertola via anti-abuse-wg wrote:
Il 02/03/2021 00:08 Kristijonas Lukas Bukauskas via anti-abuse-wg 
 ha scritto: 


UCEPROTECT blacklists the whole range of IP addresses, including the full IP 
range of some autonomous systems:
I stress that the problem is not in blacklisting entire providers, something 
that may be justified if those providers are lenient in fighting abuse on 
their networks, but in blacklisting entire providers with very weak criteria 
(so weak that most big European hosters end up at least in the level 3 
blacklist) and then asking for money to remove them. This is actually 
prohibited by RFC 6471 (section 2.2.5) because indeed, especially when done 
at scale, it looks a lot like extortion.


They don't ask for money to be removed from the the list. The listing gets 
automatically removed after 7 days of taking care of the issue, without money 
changing hands. Please stop spreading lies.



Hm... perhaps they remove records after some time.  However, they ask money for 
whitelisting, which sorts out the same effect as delisting.


From whitelisted.org website:
Registration is available for 1 Month (25 CHF), 6 Month (50 CHF), 12 Month (70 
CHF), 24 Month (90 CHF) .



Best
Ale
--

Re: [anti-abuse-wg] Question about spam to abuse inbox

[Alessandro Vesely]

On Sat 27/Feb/2021 01:40:01 +0100 Ángel González Berdasco wrote:

Cynthia Revström writes:


if you want a human to read your emails, you shouldn't automate the
sending so you end up with potential situations like that. >

No. You should actually love automated reports.

[...automated classification of automated abuse reports...]
[...held in esteem but not quoted...]

Note I'm not covering the quality of the information. In either cases,
Joe notifications could generally be either good or bad. If you find
Joe to provide reliable information, you may even want to trust their
reports automatically. If they have a lot of noise, you probably will
want to prioritize them at the bottom of your queue.



It's also to be noted that abuse teams do reply.  If the quality isn't good, 
the human who read the report replies and points out what is missing in order 
to make it actionable.  Some replies are fully automated and repetitive, some 
are based on a template on which the operator on duty can add manually written 
text.  Thus, while reports are generated automatically, replies have to be 
handled by hands, possibly deploying regexes or eyeballs to classify them.


That begs the question of whether abuse reports have valid reply addresses.



Don't assume people are lacking in basic knowledge, rather consider
that some people might have requirements other than yours, and that
it might not be as simple as you suggest.


Sadly, problems often lie at the management level, out of the hands of
the technicians which suffer them.



How much to invest in abuse handling is obviously a management decision.  It 
shapes an ISP's characteristics, quality, and costs.


From my POV, the best way to implement a couldn't-give-a-damn attitude is to 
not register an abuse address at all.  Having an automated abuse reporting 
system driven by firewall events, it is straightforward to multiply the banning 
period by months when the abuse address is empty.  Unfortunately, RIPE seems to 
have it mandatory to fill abuse-c, so one has to manually track bounces, 
distinguishing temporary hiccups from permanent failures, and equate the latter 
to empty addresses.



Best
Ale
--

Re: [anti-abuse-wg] Question about spam to abuse inbox

[Alessandro Vesely]

On Thu 25/Feb/2021 14:41:00 +0100 Cynthia Revström wrote:


I think you have misunderstood my point.


Would they send such report using their customer's own web form?


No? I don't know what implied that?



If you predicate sending reports via web form, then report forwarding 
from the ISP to its customer should also be done via web form.  That 
is, the ISP should jump all the required hoops until it finds out 
where and how to fill the appropriate form.  However, doing so defeats 
the advantage of having the customer automatically identified.




Yes, doing so requires some work too, but heck aren't we paying for that

already?

The person sending the abuse report is rarely a paying customer.


The right thing to do would be to arrange for the abuse mailbox address

to point (in)directly to the actual user of the IP address.

I am assuming you are referring to having a separate abuse contact for each
customer, so like abuse.cust123@domain and registering it in the RIPE
Registry/DB?



Yes, exactly.  That's the extra work required from the ISP.  It is 
paid by cust123.  Presumably, abuse.cust123@domain forwards to the 
abuse address chosen by the customer on signing the contract.  Keeping 
a copy allows the ISP to monitor how many complaints its customers 
receive.




In some cases with large customers maybe but if you are a hosting provider
where each customer might only have one or two IPv4 addresses, that can get
to an insane amount of handles and make the database really messy.



You can keep a record for each IPv4 address with only a few Terabytes.

I don't think the reason why ISPs tend to neither assign rfc2317 
reverse delegations nor customer specific abuse-mailbox is because 
they or the RIPE cannot afford enough disk space to store that data.


Every now and then I ask my ISP to assign me an abuse-mailbox (which 
my previous ISP did, but then they were acquired by a bigger shark 
while the RIPE changed format to abuse-c.)  At times I also try and 
send fake complaints about my IP, to see if they would forward them to 
me.  All of those messages fall into a black black hole where time is 
frozen expectations fade.  Lazy.




Also the customer in question is not the only info that is relevant, like
is it DoS, spam, or port scanning, etc?

But in general I think there are pros and cons to web forms and email
templates just as there are pros and cons to arbitrarily structured emails.



For a third alternative, I recently added abuseipdb.com to my 
end-of-day abuse reporting script.  They provide an http API that 
allows to specify the most basic info, IP, time, and kind of abuse. 
That method has some of the advantages of forms, as it allows 
semantically bound fields, and some advantages of email messages, as 
it can be automated.



Best
Ale
--

Re: [anti-abuse-wg] Question about spam to abuse inbox

[Alessandro Vesely]

Sorry for being late to the party...

On Sun 21/Feb/2021 03:44:07 +0100 Cynthia Revström via anti-abuse-wg wrote:
If the hosting company provides a web form, they can have a field where they 
explicitly ask for the offending IP address.
This report could then automatically also be sent to the customer in question, 
because we shouldn't assume the customer is malicious, they might just have a 
bad config that made them a relay for example.



Would they send such report using their customer's own web form?

The right thing to do would be to arrange for the abuse mailbox address to 
point (in)directly to the actual user of the IP address.  Yes, doing so 
requires some work too, but heck aren't we paying for that already?



Best
Ale
--

Re: [anti-abuse-wg] IPv4 squatting -- Courtesy of AS44050, AS58552

[Alessandro Vesely]

On Mon 30/Nov/2020 22:56:22 +0100 John Levine wrote:

In article ,
Richard Clayton  wrote:

Only a few of them are listed on https://www.spamhaus.org/drop/



So announcing a prefix that is on that list is not a good sign (indeed
far from it) -- but don't expect a "new" hijacker to only choose from
that list or indeed to pick any prefixes from that list at all.


Spamhaus have very conservative criteria for their DROP list, so it's
not surprising that you wouldn't immediately find all those hijacked
blocks on it. On the other hand, they update it frequently and I see
they added a bunch of new blocks to it today.



Indeed.  As I have the command still in bash's history, matches increased from 
5 to 17, nearly one half of Ronald's post:


199.84.16.0->  spamhaus-drop/drop.txt:199.84.16.0/20   ; SBL503515
199.185.144.0  ->  spamhaus-drop/drop.txt:199.185.144.0/20 ; SBL503521
68.66.48.0 ->  spamhaus-drop/drop.txt:68.66.48.0/20; SBL502548
207.70.224.0   ->  spamhaus-drop/drop.txt:207.70.224.0/20  ; SBL503527
207.228.192.0  ->  spamhaus-drop/drop.txt:207.228.192.0/20 ; SBL503528
96.45.144.0->  spamhaus-drop/drop.txt:96.45.144.0/20   ; SBL502550
204.44.208.0   ->  spamhaus-drop/drop.txt:204.44.208.0/20  ; SBL503530
204.156.192.0  ->  spamhaus-drop/drop.txt:204.156.192.0/20 ; SBL503537
69.8.64.0  ->  spamhaus-drop/drop.txt:69.8.64.0/20 ; SBL502549
69.8.96.0  ->  spamhaus-drop/drop.txt:69.8.96.0/20 ; SBL503524
206.125.16.0   ->  spamhaus-drop/drop.txt:206.125.16.0/20  ; SBL503526
64.92.224.0->  spamhaus-drop/drop.txt:64.92.224.0/20   ; SBL503523
204.147.96.0   ->  spamhaus-drop/drop.txt:204.147.96.0/20  ; SBL503525
24.137.16.0->  spamhaus-drop/drop.txt:24.137.16.0/20   ; SBL502541
204.128.32.0   ->  spamhaus-drop/drop.txt:204.128.32.0/20  ; SBL503533
199.73.64.0->  spamhaus-drop/drop.txt:199.73.64.0/20   ; SBL502551
104.156.144.0  ->  spamhaus-drop/drop.txt:104.156.144.0/20 ; SBL503516


Best
Ale
--

Re: [anti-abuse-wg] IPv4 squatting -- Courtesy of AS44050, AS58552

[Alessandro Vesely]

On 30/11/2020 08:08, Ronald F. Guilmette wrote:

Please be advised that the set of IPv4 blocks listed below appear to be
squatted on at the present time, with the apparent aid and assistance of
AS44050 -- "Petersburg Internet Network Ltd." (Russia) and also AS58552 --
"PT Multidata Rancana Prima" (Indonesia).

These blocks appear to be mostly or entirely very old "legacy" block,
primarily from the ARIN region.



Only a few of them are listed on https://www.spamhaus.org/drop/



#
# COUNT: 1 ORG: (CA) NINS-1 "AllCore Communications Inc."
#
68.66.48.0/20



68.66.48.0   ->  spamhaus-drop/drop.txt:68.66.48.0/20  ; SBL502548



#
# COUNT: 1 ORG: (US) EVANS-25 "Evanston Data & Colocation, Inc."
#
96.45.144.0/20



96.45.144.0  ->  spamhaus-drop/drop.txt:96.45.144.0/20 ; SBL502550



#
# COUNT: 2 ORG: (US) HAWK "Hawk Communications"
#
69.8.64.0/20
69.8.96.0/20



69.8.64.0->  spamhaus-drop/drop.txt:69.8.64.0/20   ; SBL502549



#
# COUNT: 1 ORG: (US) PLCA "PlanetCable Corp."
#
24.137.16.0/20



24.137.16.0  ->  spamhaus-drop/drop.txt:24.137.16.0/20 ; SBL502541



#
# COUNT: 1 ORG: (US) SYSTEM-71 "Systems and Electronics Inc."
#
199.73.64.0/20



199.73.64.0  ->  spamhaus-drop/drop.txt:199.73.64.0/20 ; SBL502551

Re: [anti-abuse-wg] Draft Anti-Abuse WG Minutes from RIPE 81

[Alessandro Vesely]

Hi Tobias,

On Thu 12/Nov/2020 16:28:58 +0100 Tobias Knecht wrote:


Please see the draft minutes from our Anti-Abuse Working Group Session in 
127.0.0.1. Please let us know about any objections or necessary corrections asap.



Maybe it's me, but I cannot quite parse this sentence:

From his own work experience, he confirmed that abuse handling is
considered a security incident, there is a need for documentation
to be able to convince managers.

Perhaps "if abuse handling is to be considered a security matter..."?


Best
Ale
--

Re: [anti-abuse-wg] Appeal against the Anti-Abuse WG Co-chairs decisions on proposal 2019-04 (Validation of “abuse-mailbox”)

[Alessandro Vesely]

On Mon 26/Oct/2020 15:33:21 +0100 Alex de Joode wrote:

Jordi et al,
​
I have to comment RIPE NCC and WGCC (and those that recused themselves). The 
appeals process was used, the outcome reaffirmed the original decision.


It's clear the proposal was fatally flawed.

May I suggest we do not waist extra effort on this but accept the outcome and 
instead of looking back, regroup and look forward?



+1, there is more than just trying to rebuke non-compliant ISPs.


Best
Ale
--

[anti-abuse-wg] NWI issuing abuse contact changes, was reviews: NWI-1 staying on top of

[Alessandro Vesely]

On Wed 23/Sep/2020 01:45:26 +0200 ripedenis--- via anti-abuse-wg wrote:

Hi Leo

I was proposing a tool to help the registrant manage their data. If you want to 
find the abuse contact you just query the resource and the abuse contact is 
returned.



I thought only ISPs had the right to manage their own abuse-c's.  From the text 
below, I infer there are more ways to get the right data to the DB.


For example, my ISP (Eutelia) went belly up between the change from 
abuse-mailbox to abuse-c.  The one who took over (Clouditalia) never took care 
to point abuse-c to my abuse mailbox.  Actually, they don't even reply to the 
email address currently pointed to (in CC).


What are the extra methods which allow to carry out arrangements that the 
resource holder can overlook?



Best
Ale


cheers
denis

co-chair DB-WG

On Tuesday, 22 September 2020, 23:13:02 CEST, Leo Vegoda  
wrote:


Hi Denis,

On Tue, Sep 22, 2020 at 1:51 PM ripedenis--- via anti-abuse-wg
mailto:anti-abuse-wg@ripe.net>> wrote:

[...]

Over time, with large hierarchies, we could end up with very complex 
arrangements with objects, attributes and values that have been overlooked and 
forgotten about. Even though they may have been forgotten about they are still 
'active' and queries will return the most appropriate abuse contact details, 
even if it is the wrong contact.


There is no simple query that will return the details of such a complex 
structure of abuse contact data in the RIPE Database. So there is no easy way 
for a resource holder to review or manage these abuse contacts. Although most 
resources will only ever have one abuse contact for the whole hierarchy, over 
several years we could end up with the kind of data swamp we had before we 
introduced the "abuse-c:" attribute for the larger networks.


Any user could write their own script to do more specific queries, parse the 
returned objects and work out the abuse contact data structure for their 
resource. It would require detailed knowledge of the RIPE Database structure, 
the abuse contact rules and would involve multiple queries just to get the 
data, which you then have to visualise.


My reason for this NWI-1 was to suggest the RIPE NCC creates a tool or 
RIPEstat widget that would take in a resource and map out the abuse contact 
details for the whole hierarchy including that resource.


Would this be useful, is it necessary or a waste of time? Please discuss



Should I understand this as a proposal for a tool that is used to keep
the registrant informed about changes related to resources for which
they are responsible, or a tool to help other network operators and
users find the right place to send an abuse report?

Many thanks,

Leo

Re: [anti-abuse-wg] Report & Co-Chair's Decision on Proposal 2019-04

[Alessandro Vesely]

On Tue 08/Sep/2020 16:33:20 +0200 Alex de Joode wrote:
A webform, for a regulator, most likely will be seen as an 'upgrade'. Note that 
FB and Google also *only accept* complaints, notices etc via webforms. So one 
can argue a webform is abuse@ 2.0 :)​ So I do not share you view that a webform 
is a second rate instrument for accepting abuse notifications.





IME that's not true.  I notice Google's auto-responses.  Perhaps, I should set 
up a web form myself for receiving such replies...?



Best
Ale
--

[anti-abuse-wg] Fail2ban usage, was Draft Minutes - AA-WG @ RIPE80

[Alessandro Vesely]

Hi Jordi and all,

TL;DR:  Fail2ban can deal with missing or non-responding abuse teams
automatically, without the need to load RIPE with extra costs.


In the draft minutes I read:

Jordi said he thinks it will work because smaller providers use more and
more Open Source tools and it's very common to use Fail2ban. He uses it
himself, and it takes a couple of hours to implement that. So, he
disagreed, but pointed out there there are lots of different opinions on
the matter.


I can confirm that abuse reporting by email works.  When I started reporting I 
noticed some ISPs were receiving lots or reports each day.  In some cases, the 
frequency suddenly dropped.  Most likely, that's the result of the ISP starting 
to work on my reports and clean up.


Based on such evidence, I recently changed my reporting script.  Now, I don't 
use Fail2ban; I use ipqbdb, which works in a similar way.  It features an 
abuserdap utility which looks up abuse addresses.  It takes as argument an 
exclusion-file, which I manually fill with the addresses that seem to be 
permanently bouncing.  Currently, the utility returns no address if either no 
address is found in RDAP, or all the addresses found there are also found in 
the exclusion file.  (See bash snippet below).


Like Fail2ban, ipqbdb bans addresses for a limited time.  Wrong passwords 
deserve a particularly short time period, because they can be given by legit 
users.  However, users coming from IP addresses not supported by a responding 
abuse team can be safely banned for a longer period.  I do one month.



On Tue 07/Jul/2020 10:33:58 +0200 PP wrote:
The complaint to RIPE mechanism should only be an escalation mechanism when the 
ISP does not respond.



Besides costs, that would make RIPE behave different than other LIRs.  I log 
how many RDAP lookup fail.  Most of them are in LACNIC and APNIC.  Figures are 
as follows:


Total RDAP lookups   99,   3.03% of which failed
Total RDAP lookups  107,   5.61% of which failed
Total RDAP lookups  102,   3.92% of which failed
Total RDAP lookups  140,  17.14% of which failed
Total RDAP lookups  125,   6.40% of which failed
Total RDAP lookups  115,   8.70% of which failed
Total RDAP lookups  127,   7.09% of which failed
Total RDAP lookups  113,   4.42% of which failed
Total RDAP lookups  415,  21.93% of which failed
Total RDAP lookups 1542,  39.49% of which failed
Total RDAP lookups 1996,  49.10% of which failed
Total RDAP lookups 1297,  55.05% of which failed
Total RDAP lookups  242,  31.40% of which failed
Total RDAP lookups  125,  40.80% of which failed
Total RDAP lookups  149,  43.62% of which failed
Total RDAP lookups   89,  30.34% of which failed
Total RDAP lookups   55,  18.18% of which failed
Total RDAP lookups   53,  18.87% of which failed
Total RDAP lookups   61,   9.84% of which failed
Total RDAP lookups   64,  25.00% of which failed
Total RDAP lookups 1259,  49.80% of which failed
Total RDAP lookups 1725,  60.46% of which failed
Total RDAP lookups 1746,  64.83% of which failed
Total RDAP lookups  643,  62.99% of which failed
Total RDAP lookups   73,   5.48% of which failed
Total RDAP lookups  148,   8.11% of which failed
Total RDAP lookups  163,  11.04% of which failed
Total RDAP lookups  155,  21.94% of which failed

The relevant snippet of code is below:

let rdap_lookup++
readarray -t <<< "$(abuserdap -x $XCLUDE -vs $rdap_url 2>> $RDAP_LOG)"
rcpt=${MAPFILE[0]}
if test -z "$rcpt"; then
let rdap_failed++
# since Tue 19 May 2020, ban for 1 month.  Don't use -l here!!
ibd-ban -i $key -c 0 -t 2592000 -r "IP without abuse team"
fi
lastline="Recipient found in ${MAPFILE[1]}"

# [...]

if [ "$rdap_lookup" -gt 0 ]; then
printf 'Total RDAP lookups %8d, %6.2f%% of which failed\n' \
"$rdap_lookup" "$(echo "100*$rdap_failed/$rdap_lookup"| bc -l)"
fi


Best
Ale
--

Re: [anti-abuse-wg] 2019-04 Discussion Phase (Validation of "abuse-mailbox")

[Alessandro Vesely]

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" 
>  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

Re: [anti-abuse-wg] 2019-04 Discussion Phase (Validation of "abuse-mailbox")

[Alessandro Vesely]

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" 
>>  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
-- 

Re: [anti-abuse-wg] 2019-04 Discussion Phase (Validation of "abuse-mailbox")

[Alessandro Vesely]

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

Re: [anti-abuse-wg] 2019-04 Discussion Phase (Validation of "abuse-mailbox")

[Alessandro Vesely]

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

Re: [anti-abuse-wg] 2019-04 Discussion Phase (Validation of "abuse-mailbox")

[Alessandro Vesely]

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

Re: [anti-abuse-wg] 2019-04 Discussion Phase (Validation of "abuse-mailbox")

[Alessandro Vesely]

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

































signature.asc
Description: OpenPGP digital signature

[anti-abuse-wg] And of course the Australian lady hits the spam button...

[Alessandro Vesely]

Every time I send a message to this list, I receive Dina's complaint from 
Yahoo! feedback loop.

I tried to reach Yahoo's FBL in order to convince them that the proper action 
to take when a mailing list message is reported as spam is to unsubscribe the 
user from the reported mailing list.  I didn't succeed.

I wrote to anti-abuse-wg-ow...@ripe.net, maybe they could unsubscribe Dina 
Williams.  They replied that "the RIPE NCC is not responsible for any form of 
spamming, hacking or phishing."

I think I'm not the only poster subscribed to Yahoo's FBL.  Do you get reports 
like the following too?


Best
Ale

 Forwarded Message 
Subject: FW:Re: [anti-abuse-wg] Reporting abuse to OVH -- don't bother
Date: Wed, 12 Feb 2020 17:10:08 +0100
From: Yahoo! Mail AntiSpam Feedback 
To: ab...@tana.it

This is an email abuse report for an email message from tana.it on Wed, 12 Feb 
2020 12:16:59 +


 Feedback-Report 
Feedback-Type: abuse
User-Agent: Yahoo!-Mail-Feedback/2.0
Version: 0.1
Original-Mail-From: 
Original-Rcpt-To: dinaswilli...@yahoo.com
Received-Date: Wed, 12 Feb 2020 12:16:59 +
Reported-Domain: tana.it
Authentication-Results: authentication result string is not available


 Reported Message 
Subject: Re: [anti-abuse-wg] Reporting abuse to OVH -- don't bother
Date: Wed, 12 Feb 2020 13:16:36 +0100
From: Alessandro Vesely 
To: anti-abuse-wg@ripe.net

On Wed 12/Feb/2020 09:51:22 +0100 Ronald F. Guilmette wrote:
> The RIPE WHOIS data base says that the abose contact for AS16276 is
> ab...@ovh.net.
> 
> It would appear thet the folks at OVH haven't yet quite figured how
> this whole email thing works.
> 
> Give them time.  Another decade or two and they should have it down pat.


+1, X-VR-SPAMCAUSE looks particularly appealing...

Best
Ale

[... Forwarded Message elided ...]

Re: [anti-abuse-wg] Reporting abuse to OVH -- don't bother

[Alessandro Vesely]

On Thu 13/Feb/2020 05:26:10 +0100 Fi Shing wrote:
> All OVH and DigitalOcean abuse reports must be submitted via the abuse
> reporting forms on the website, or they won't be actioned:
>  
> https://www.ovh.com/world/abuse/
>  
> https://www.digitalocean.com/company/contact/abuse/


I'm unable to post to each abuse team specific web form.  I collect abusive
behavior from the firewall log during an end-of-day cron, and notify that to
the addresses I find using RDAP, in the hope that it can be useful to the users
paying for presumably infected hosts.

I skip reporting to countries like CN RU VN EG LA BY KE IR AZ BN and the like,
where Internet is not free, afraid to cause more harm than good.  In addition,
I have a skip list where I add bouncing addresses like ab...@ovh.net.  Some
times I report invalid WHOIS data to the relevant RIR, before adding an address
to that list.

I feel like sharing this spirit because of a recent discussion about validation
of abuse-mailboxes, and the obligation to publish one.


> At the moment, the resource holder can:
> 
> ignore it due to funding issues,
> ignore it due to lazyness,
> ignore it due to criminal influence,
> ignore it due to language barrier,
> be forced to ignore it due to DDoS style email flooding,
> be forced to ignore it due to the size of the resource holdings (because 
> of the sheer volume of complaints made to them due to the size of their 
> network),
> be forced to ignore it due to a glitch which they are unaware of,


Of course they can.  Once I received an auto-reply saying the abuse "team" was
on holidays at the time.  That's ok, live and let leave.  If everyone do just
the best they can (not more), it'd be probably enough.


Best
Ale
-- 

Re: [anti-abuse-wg] Reporting abuse to OVH -- don't bother

[Alessandro Vesely]

Hi,

On Wed 12/Feb/2020 18:43:54 +0100 Alex de Joode wrote:
> 
> The abuse notification below, is absolutely terrible: it only highlights the
> OVH IP that was used, however it completely fails to identify the IP/hostname
> that was "attacked", no action (other than forward the notice to the user of
> the IP) can be taken.​


Yes, the user of the IP is the one who should take care.  I don't think an
actual (paying) user would waste resources on such desperate dictionary
attacks.  So, the host must be 0wned, and needs cleanup.


> Please in the future include all relevant data in you abuse notice. (src+dst 
> ip
> are relevant!)


Src+port are already there.  The destination IP is indirectly mentioned in a
sort of (stripped off[*]) legend which explains which host, what firewall, and
similar details.


Best
Ale
-- 

[*] I'd publish it if I were sure it's bullet proof.  Until it's fully vetted,
some obscurity sounds more secure ;-)


> On Wed, 12-02-2020 13h 16min, Alessandro Vesely  wrote:
> 
> 
> Dear Abuse Team
> 
> The following abusive behavior from IP address under your constituency
> 188.165.221.36 has been detected:
> 
> 2020-02-11 11:39:25 CET, 188.165.221.36, old decay: 86400, prob: 34.72%,
> SMTP auth dictionary attack
> 
> 188.165.221.36 was caught 102 times since Fri May 18 01:42:13 2018
> 
> original data from the mail log:
> 2020-02-11 11:39:05 CET courieresmtpd: 
> started,ip=[188.165.221.36],port=[58534]
> 2020-02-11 11:39:05 CET courieresmtpd: 
> started,ip=[188.165.221.36],port=[62026]
> 2020-02-11 11:39:05 CET courieresmtpd: 
> started,ip=[188.165.221.36],port=[63198]
> 2020-02-11 11:39:25 CET courieresmtpd: 
> started,ip=[188.165.221.36],port=[58743]
> 2020-02-11 11:39:25 CET courieresmtpd: 
> started,ip=[188.165.221.36],port=[50520]
> 2020-02-11 11:39:25 CET courieresmtpd:
> error,relay=188.165.221.36,port=58743,msg="535 Authentication 
> failed.",cmd:
> AUTH LOGIN 42D117A2.9F10013D
> 
> 

Re: [anti-abuse-wg] Reporting abuse to OVH -- don't bother

[Alessandro Vesely]

On Wed 12/Feb/2020 09:51:22 +0100 Ronald F. Guilmette wrote:
> The RIPE WHOIS data base says that the abose contact for AS16276 is
> ab...@ovh.net.
> 
> It would appear thet the folks at OVH haven't yet quite figured how
> this whole email thing works.
> 
> Give them time.  Another decade or two and they should have it down pat.


+1, X-VR-SPAMCAUSE looks particularly appealing...

Best
Ale



 Forwarded Message 
Subject: failure notice
Date: 12 Feb 2020 06:18:04 +0200
From: mailer-dae...@mx1.ovh.net
To: ab...@tana.it

Hi. This is the qmail-send program at mx1.ovh.net.
I'm afraid I wasn't able to deliver your message to the following addresses.
This is a permanent error; I've given up. Sorry it didn't work out.

:
user does not exist, but will deliver to 
/homez.12/vpopmail/domains/ovh.net/abuse/
can not open new email file errno=2 
file=/homez.12/vpopmail/domains/ovh.net/abuse/Maildir/tmp/1581481084.9867.mail660.ha.ovh.net,S=4191
system error

--- Below this line is a copy of the message.

Return-Path: 
Received: from localhost (HELO queue) (127.0.0.1)
by localhost with SMTP; 12 Feb 2020 06:18:04 +0200
Received: from unknown (HELO output25.mail.ovh.net) (10.108.117.188)
  by mail660.ha.ovh.net with AES256-GCM-SHA384 encrypted SMTP; 12 Feb 2020 
06:18:04 +0200
Received: from vr26.mail.ovh.net (unknown [10.101.8.26])
by out25.mail.ovh.net (Postfix) with ESMTP id 48HRFm0K5Sz7P6Fd8
for ; Wed, 12 Feb 2020 04:18:04 + (UTC)
Received: from in14.mail.ovh.net (unknown [10.101.4.14])
by vr26.mail.ovh.net (Postfix) with ESMTP id 48HRFf6fgNzrQV85
for ; Wed, 12 Feb 2020 04:17:58 + (UTC)
Received-SPF: Pass (mailfrom) identity=mailfrom; client-ip=62.94.243.226; 
helo=wmail.tana.it; envelope-from=ab...@tana.it; receiver=ab...@ovh.net 
Authentication-Results: in14.mail.ovh.net;
dkim=pass (1152-bit key; unprotected) header.d=tana.it 
header.i=@tana.it header.b="DSzDkiE5";
dkim-atps=neutral
Received: from wmail.tana.it (wmail.tana.it [62.94.243.226])
by in14.mail.ovh.net (Postfix) with ESMTPS id 48HRFf5rYcz1qqm5
for ; Wed, 12 Feb 2020 04:17:58 + (UTC)
Received: from localhost (localhost [127.0.0.1])
  (uid 1000)
  by wmail.tana.it with local
  id 005DC0BE.5E437C70.6938; Wed, 12 Feb 2020 05:17:51 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta;
t=1581481072; bh=hqA0axQ0F0EZuKcuD4BJM7lec22phleodccLJFRo7js=;
l=1187; h=From:To:Date;
b=DSzDkiE5M2E2RHdufCjt/pvL8szxXfCQCiPcYrJMYxbHDSM6/qNrHDy0JZwW3HfQG
 jvGk5T7PlE7c6dBvfNjmQl2Z0yTpvjOVufBM6xGVi3WEzkPUb2Wpr0b6oW/Ptan3/d
 d81pOjTCPaAxOXfx0G1t5PpotLEo0P48qxyNPtkGYVZoMp7kdUev7jtac9Jcq
Authentication-Results: tana.it; auth=pass (details omitted)
X-mmdbcountrylookup: FR
From: "tana.it" 
To: ab...@ovh.net
Date: Wed, 12 Feb 2020 05:17:51 +0100
Subject: Mail server abuse by 188.165.221.36 on 11 February 2020
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-Auto-Response-Suppress: DR, OOF, AutoReply
Message-ID: 
X-Ovh-Remote: 62.94.243.226 (wmail.tana.it)
X-Ovh-Tracer-Id: 8968355709213900626
X-VR-SPAMSTATE: OK
X-VR-SPAMSCORE: 50
X-VR-SPAMCAUSE: 
gggruggvucftvghtrhhoucdtuddrgedugedrieeggdeifecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjpdevjffgvefmvefgnecuuegrihhlohhuthemucehtddtnecuogfvvgigthfqnhhlhidqqdetfeejfedqtdegucdlhedtmdenucfjughrpefhvfffufggtgfgsehtjedttddttdejnecuhfhrohhmpedfthgrnhgrrdhithdfuceorggsuhhsvgesthgrnhgrrdhitheqnecuffhomhgrihhnpehtrghnrgdrihhtpdhrihhpvgdrnhgvthenucfkphepiedvrdelgedrvdegfedrvddvieenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhhouggvpehsmhhtphdphhgvlhhopehinhdugedrmhgrihhlrdhovhhhrdhnvghtpdhinhgvthepiedvrdelgedrvdegfedrvddviedpmhgrihhlfhhrohhmpegrsghushgvsehtrghnrgdrihhtpdhrtghpthhtoheprggsuhhsvgesohhvhhdrnhgvth
X-Ovh-Spam-Status: OK
X-Ovh-Spam-Reason: vr: OK; dkim: disabled; spf: disabled
X-Ovh-Message-Type: OK

Dear Abuse Team

The following abusive behavior from IP address under your constituency
188.165.221.36 has been detected:

2020-02-11 11:39:25 CET, 188.165.221.36, old decay: 86400, prob: 34.72%, 
SMTP auth dictionary attack

188.165.221.36 was caught 102 times since Fri May 18 01:42:13 2018

original data from the mail log:
2020-02-11 11:39:05 CET courieresmtpd: 
started,ip=[188.165.221.36],port=[58534]
2020-02-11 11:39:05 CET courieresmtpd: 
started,ip=[188.165.221.36],port=[62026]
2020-02-11 11:39:05 CET courieresmtpd: 
started,ip=[188.165.221.36],port=[63198]
2020-02-11 11:39:25 CET courieresmtpd: 
started,ip=[188.165.221.36],port=[58743]
2020-02-11 11:39:25 CET courieresmtpd: 
started,ip=[188.165.221.36],port=[50520]
2020-02-11 11:39:25 CET courieresmtpd: 
error,relay=188.165.221.36,port=58743,msg="535 Authentication failed.",cmd: 
AUTH LOGIN 42D117A2.9F10013D

Re: [anti-abuse-wg] working in new version of 2019-04 (Validation of "abuse-mailbox")

[Alessandro Vesely]

Hi,

a few points:

The “abuse-mailbox:” attribute must be available in an unrestricted way
via whois, APIs and future techniques.

I'd explicitly mention RDAP here.  It's not a future technique any more


Confirm that the resource holder understands the procedure and the policy,
that they regularly monitor the abuse-mailbox, that measures are taken,
and that abuse reports receive a response.

I'd skip the last line.  In my automated abuse reports a add a header field
like "X-Auto-Response-Suppress: DR, OOF, AutoReply".  Yet, many abuse team send
automatic notifications that I have to skim, possibly hiding real replies that
need attention.  Responses are due only if needed.


Furthermore, couldn't the RIPE NCC have a web form, possibly advertised in RDAP
output, where receivers of NDNs from abuse-c contacts can notify that a given
mailbox bounces?  The effect of filling such form would be to advance the
mailbox position in the validation queue.


Finally, IMHO:

On Tue 14/Jan/2020 10:24:42 +0100 JORDI PALET MARTINEZ via anti-abuse-wg wrote:
> El 14/1/20 0:11, "Leo Vegoda"  escribió:
>   
>> It creates hope for reporters and wastes the RIPE NCC's and the
>> reporters' resources by forcing unwilling organizations to spend
>> cycles on unproductive activity.
>> 
>> Why not give networks two options?
>> 
>> 1. Publish a reliable method for people to submit abuse reports - and 
>> act on it
>> 2. Publish a statement to the effect that the network operator does
>> not act on abuse reports
>> 
>> This would save lots of wasted effort and give everyone more reliable
>> information about the proportion of networks/operators who will and
>> won't act on abuse reports.
>  
> Even if I think that the operators MUST process abuse cases, if the
> community thinks otherwise, I'm happy to support those two options in the
> proposal. For example, an autoresponder in the abuse-c mailbox for those
> that don't intend to process the abuse cases to option 2 above?

No, autoresponders waste even more resources.  In case, let's use a
conventional address like, say, noone@localhost to decline to receive abuse
reports.  There would be no attempt to validate such address.

There are a number of cases, especially in large organizations, where a mailbox
fails to work because email refurbishing resulted in mail loops, erroneous
forwarding, dead relays, and the like.  Having an alternative contact can bring
attention to the fact and reestablish the functionality.

There are cases where there is no abuse team and holders don't care.  Sooner or
later the community will find out how to set up some kind of Don't Route Or
Peer list of those.  However, forcing them to have a "working" abuse-c is
nonsensical.



Best
Ale




> 
>
> There might be some value in having the RIPE NCC cooperate with
> networks who want help checking that their abuse-c is working. But
> this proposal seems to move the RIPE NCC from the role of a helpful
> coordinator towards that of an investigator and judge.
> 
> No, I don't think so, but I'm happy to modify the text if it looks like that.
> 
> 
> 
> 
> 
> **
> 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.
> 
> 
> 
> 
> 

Re: [anti-abuse-wg] Non-ASCII characters in abuse-mailbox addresses

[Alessandro Vesely]

Hi all

On Tue 19/Nov/2019 21:38:44 +0100 David Guo via anti-abuse-wg wrote:
> The most important thing for me is I don’t know how to type those letters on 
> my
> English keyboard ☹

It's curious that you can type emoticons and not accented letters.  Enabling
composition allows to type uppercase and foreign characters, which national
keyboards cannot.


> But yes I agree, forcing Latin chars is the best way to solve this problem.

Please do not force!  Let's go forward, not backward.

Please allow non-ASCII characters, encoded in UTF-8 [RFC3629] using the
normalization form canonical composition (NFC) as described in Unicode Format
for Network Interchange ([RFC5198]).

At most, suggest to providers who use EAI addresses to also provide an ASCII
alternative, if possible.


Best
Ale

Re: [anti-abuse-wg] 2019-04 Discussion Period extended until 9 December 2019 (Validation of "abuse-mailbox")

[Alessandro Vesely]

On Fri 08/Nov/2019 14:39:27 +0100 Petrit Hasani wrote:
> The Discussion Period for the policy proposal 2019-04, "Validation of 
> "abuse-mailbox"" has been extended until 09 December 2019.
> 
> This proposal aims to have the RIPE NCC validate "abuse-c:" information more 
> often, and introduces a new validation process that requires input from 
> resource holders.
> 
> You can find the full proposal at:
> https://www.ripe.net/participate/policies/proposals/2019-04
> 
> We encourage you to review this proposal and send your comments to
> .


Rather than doubling the frequency, I'd try and ease reporting.  It is not
immediate to find how to report a bad abuse address.  ARIN puts the inaccuracy
reporting URL right in the RDAP response.  Wouldn't RIPE do the same?

The form should accept an NDN message along with the RDAP URL which points to
the bad abuse address.  Consistency checks can be easily automated.

Checking reported addresses is more effective.  After all, the reachability of
an abuse email address is as important as the number of complaints originating
from the relevant range of IP addresses.


Best
Ale





signature.asc
Description: OpenPGP digital signature

Re: [anti-abuse-wg] RIPE NCC Report: Law Enforcement Agency Requests 2018

[Alessandro Vesely]

On Tue 19/Mar/2019 11:03:06 +0100 Linda Slaakweg wrote:
> You can find the report at: 
> https://www.ripe.net/publications/docs/ripe-715/


[1] The majority of these requests were sent by
one particular party from the United States.

GOP?

Re: [anti-abuse-wg] Webzilla

[Alessandro Vesely]

On Sat 16/Mar/2019 21:15:22 +0100 Ronald F. Guilmette wrote:

> First, I am inclined to wonder aloud why anyone is even still peering
> with any of the several ASNs mentioned in the report.  To me, the mere
> fact that any of these ASNs still have connectivity represents a clear
> and self-evident failure of "self policing" in and among the networks
> that comprise the Internet.


RIRs cannot themselves enact block lists such as Spamhaus DROP.  However, those
ASNs could well make their way to such lists.  Why don't they?


Best
Ale
--