On Apr 1, 2008, at 8:48 AM, Chris Lewis wrote:
Determining the network provider helps establish their reputation,
which should represent a significant factor in whether their
advertised space can be trusted.
Very few existing (at least public) DNSBLs pay any attention
whatsoever to this. Those that do usually do little more than ad-
hoc aggregate statistical reports, eg http://cbl.abuseat.org/country.html
and http://cbl.abuseat.org/domain.html, or Spamhaus's country/
provider top 100 listings, or Cymru's or helping guide the manual
escalation of manual listings...
Hence, it misses the "C" ("current") required for a BCP.
It may be the perfect reputational DNSBL design, but it's still not
a _current_ one, and is hence not eligible for a BCP.
Secondly, it's DNSBL listing policy, not operational practise.
Thus, it is out of scope for the document at hand _even_ if such
DNSBLs existed today.
The Internet is a collaboration of separate, privately owned
networks. Each network provider freely decides to mutually accept
each other's address space advertisements and related traffic. The
draft, although somewhat improved, still needs to differentiate
between policies that relate to automated listings, from those that
are created manually. Also, do not assume listings pertain to the
actions of individual IP addresses. This is _not_ always the case.
In addition, policy suggestions for listing and delisting should be
limited to automated lists only.
When MAPS (the original black-hole list) first started, its
assessments _always_ included the network provider. It was understood
who MUST be held responsible. This is not a new untried idea. This
has been the case since MAPS first started, and is still the case
today. Then and now, this practice encourages network providers to
enforce AUPs that prohibit UCEs and other forms of abuse.
Only the network provider knows the entities associated with their
address space. Only the network provider can assert the governance
required to abate abuse. Ensuring the network provider stays involved
is vital. Many systems emitting abuse have been compromised and may
not normally send email. Unless the network provider conveys this
situation to their customers, these systems may continue to emit
abuse. Although some email providers abhor assessments that include
the network provider, privately many acknowledge the effort provides
an overall, albeit painful, benefit.
The draft is clearly recommending use of automation and excludes any
role involving network providers. Unfortunately, automated systems
are easily defeated because of their automation. No block list
receives a comprehensive view of all sources emitted by a network
provider. Acceptance of traffic may depend upon a sampling technique
used in industry to ascertain product quality. Rejection may not
involve direct observation of each item, rather this is done through
sampling. A conclusion can be safely reached that network provider's
process lacks the necessary and essential quality controls.
The strategy initially adopted by MAPS has not been made obsolete by
network providers improving their controls, although many have. Some
network providers still do not exercise the requisite governance. In
addition, prevalence of Bot-Nets has only made the initial strategy
taken by MAPs to have been prescient. In excess of 50,000 compromised
systems may be leased by bad-actors as a unit. Such leasing permits a
bad-actor, within a single spam campaign, to identify _all_ networks
not conveying abuse to block-list operators. Those networks that
convey abuse, when blocking is automated, only require bad-actors to
emit their campaign at slow rates to identify where abuse is
monitored. In this case, automation clearly benefits bad-actors.
In addition to listing automation, recommending a method to request
automatic removal without involving network operators is ideal for bad-
actors as well. After all, bad-actors are often using leased
resources of compromised systems, and have no relationship with their
network provider. After running their "request removal" scripts,
their leased Bot-Net is ready to emit spam campaigns scrubbed of known
monitors. Bad-actors should offer the authors of this draft their
heart felt thanks for ensuring block-listing is no longer their problem.
Block-lists that incorporate a manual strategy are designed to make
listing and de-listing uncertain or inconvenient for bad-actors by:
- notifying the network provider of pending listings and waiting for
their response.
- not automatically removing a listing.
- accepting removal requests only from network providers.
While this is a PITA for many email providers, and appears to be the
motivation behind the current draft, it would be hard to describe
policy recommendations contained within this draft as a good or even a
sustainable practice.
Change:
2.2.1. Listings SHOULD Be Temporary
To:
2.2.1. Listings SHOULD Be Temporary for automated listings
Change:
2.2.3. Removals SHOULD Be Prompt
To:
2.2.3. Removals SHOULD Be Prompt for automated listings
Conclusions reached in the last three paragraphs of section 2.2.3 are
naive and wrong. Strike these paragraphs:
---
Many DNSBLs can effectively use a "no questions asked" removal policy
because by their very nature they will redetect or relist problems
almost immediately. They can mitigate more organized attempts to
"game" the system by elementary checking and rate-limiting
procedures, increasing lockout periods, rescans etc. Furthermore, a
few IP addresses more or less do not make a significant difference in
the overall effectiveness of a DNSBL. Moreover, a "no questions
asked" removal policy provides the huge benefit of a swift reaction
to incorrect listings.
As an example, one popular DNSBL uses a "no questions asked" removal
policy, but does perform rate-limiting and malicious removal
detection and mitigation.
Another important consideration supporting a "no questions asked"
self-removal policy is that it forestalls many conflicts between
DNSBL operators and organizations whose IP addresses have been
listed. Such a policy also can be an effective deterrent to legal
problems.
---
The last sentence in this section could be seen as a threat. "Such a
policy also can be an effective deterrent to legal problems." suggests
list operators become liable when adhering to their policy when it
differs from this poorly considered and naive recommendation. Public
lists could incorporate ACLs that register the IP addresses of those
that entered into click-through agreements that indemnifies the
operator. The ACL agreement suggestion would be how this draft might
attempt to offer operators greater legal protection. This draft seems
determined to ignore the goal of operating a blocking list. This goal
would be to curb abuse at its source. This is done by network
operators improving enforcement of their AUPs. The Internet can not
continue to exist without network providers ensuring good governance.
3.6. Use of Collateral Damage MUST Be Disclosed
This section assumes only individual IP addresses are assessed. The
list may represent a range of IP addresses pertaining to single
entity, the rated network provider. Would listings based upon this
entity's address space represent collateral damage? Such a rating may
suggest this provider is not effective at enforcing reasonable
Acceptable Use Policies.
Calling this "collateral damage" represents a concerted bias against
rating network providers. Clearly, when a listing is constrained to
that of specific network provider, there would not be _any_ collateral
damage involving other network providers.
In the Security Consideration Section, block-list operators that
develop an effective strategy not easily defeated are likely to find
their resources DDoS attacked. These resources include monitoring and
distribution systems. DNS is a fairly robust distribution method, but
definitely not the only method available. Information can be
distributed as a BGP feed placed within the subscriber's routers. BGP
offers protection from a range of attacks. Listing and removal
automation also exposes the location of the operators resources.
Automation should be used with extreme caution.
-Doug
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/asrg