On Mar 31, 2008, at 11:44 AM, Seth wrote:
Douglas Otis <dotis(_at_)mail-abuse(_dot_)org> wrote:
Will information be added related to warnings regarding network
provider associated address space about to be list?
I hope not.
Why do you keep assuming that only things that _have_ network
providers can be listed? Who is the "network provider" for a
"Mailer-agent" header DNSBL?
Any IP address used by bad actors for sending UCEs or other types of
abuse is being routed by a network provider. Network providers are
identified by their address space advertisements. There is no other
identity related to an IP address that a recipient is able to
ascertain with certainty. In addition, the network provider is in the
unique position of being able to curtail the abuse immediately. After
all, only the network provider is paid to provide access, and can
fully monitor the traffic of a reported bad-actor. How can a BL
operator establish relationships with millions of a network providers'
customers, without expecting network providers to intercede? Only
network provider can establish AUPs, and know who might be making
trouble, and then halt the abuse.
While few black-hole/block list operators are able to coordinate with
network providers and thereby prevent abuse at the source, _no_ other
approach is as effective or as robust. The current draft is promoting
the concept of automation with a significant amount of hand-waving
about avoiding being gamed.
As part of the security concerns, many BL operators offer samples,
where any bad-actor is able to include subtle identifiers to track
points of detection. When individual bad actors control millions of
compromised systems, the process of elimination quickly locates
networks, and eventually specific addresses, where abusive messages
are being detected. These addresses might even become targeted in an
effort to overwhelm the BL operator's resources using DDoS techniques.
A level of trust is required between the BL operator and the network
provider to be both effective and to improve safely. Curbing abuse is
the goal after all. Defining a BL mode of operation that asks the
least of the network operator, also does the least in terms of curbing
abuse. Only network operators are able to identify bad-actors and
adequately monitor their activity once reported.
There is also an additional security considerations for BL operators
that automatically generate lists. Not monitoring the veracity of the
address space announcements permits an egregious type of DoS attack,
where the BL operator becomes an unwitting pawn.
For that matter, who is the "network provider" for a domain, in a
domain list? The IP address of the domain might be in the space of
numerous providers, and change rapidly. Similarly for the DNS server.
A network provider routes IP addressed packets. Routing only depends
upon the IP address and not the domain name related to the address.
Currently, few BLs rate domain names. IP addresses resolved by the
name or used by the name server may serve as a reference identifier.
Until DKIM becomes more popular, source domains of a message remain
commonly spoofed.
In many cases, only the network provider can be identified as being
associated with the address space in question.
In many cases, nobody can be.
This is simply not true, or the packet could not be routed.
Will there be any recommendation regarding the notification of
listings?
The listing is its own notification.
No. The goal is to stop the abuse at its source. As such, prior
notification of a listing given the network provider can then be
directed to their customer. The network provider interceding is
likely the only means to notify a system operator that their server
has been compromised. Compromised systems introduce a significant
portion of abuse, and many of these systems do not normally send
email. Operators of compromised systems that do not normally send
email are unlikely to notice BL listings. As compromised systems play
a major role in the amount of abuse being seen, the network operator
must play a critical role of abuse notification.
-Doug
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/asrg