On Mar 26, 2008, at 8:18 AM, Matt Sergeant wrote:
Douglas Otis wrote:
This was expanded upon in text you deleted by stating not all BLs
depend upon full list automation. Some lists attempt to audit
networks and provide notifications to afford opportunities to
remedy issues. Establishing co-operative relationships often
involves time. The time expended means such efforts can easily be
gamed, especially when de-listing is automatic at set intervals or
acted upon automatically from any request. Keep in mind, some
organizations structure their BL services differently. Some offer
BLs run in the manner suggested by the current version of the draft
and others do not. Trend happens to do both.
OK, so let me just clarify this - when you are listing a netblock
(and communicating with the owner or whatever you do), you NEVER
periodically re-check that netblock to make sure it hasn't changed
hands or gone quiet or anything? It's just listed permanently until
the heat death of the universe?
Two major players are effective at controlling email abuse, individual
senders and network providers. Enforcement of the network provider's
AUPs offers the greatest impact and creates a hierarchy of
responsibility that fairly distributes costs related to curbing
abuse. The provider must also seek remuneration for their services
and are thus best able to defend against evasive abusers as well.
The concept of "automated individual IP address blocking" based upon
automated detection and instant removal is clearly an ideal aimed at
shifting all culpability onto often anonymous individual senders. At
times, an individualized approach in controlling abuse is
appropriate. However, the strategy taken depends upon the stewardship
of the network provider.
Some networks permit high levels abusive, where their traffic might be
blocked when there lacks justification to re-establish a baseline
which must endure this abuse. Soliciting network providers
involvement sometimes takes years, where blocking just their
individual IP addresses is counter-productive and ultimately
ineffective. This draft is confusing the mechanism with the entity
being held responsible.
Or is it temporary after all?
There is no pre-ordained maximums in terms of time (or CIDRs), as
suggested by this draft.
This draft shifts resolving abuse to individual senders and third-
party blocking lists, and away from network providers. While an
individual IP address approach is suitable for a growing number of
networks, this draft assumes only the behaviour of individual IP
addresses plays _any_ role, and completely ignores the role played by
network providers. Where in this draft is the most specific AS even
mentioned? A BCP about black-hole listings that omits details related
to ASNs and BGP seems ludicrous. What role does the AS play in
abating abuse and identifying responsible entities? None? As email
begins to use IPv6 addresses, the number of addresses able to defeat
_any_ automated system will again become overwhelmingly apparent. The
role network providers must play is not based upon concepts that have
become antiquated back in the year 2000, as some on this list are
suggesting.
And if you have reason to remove the netblock, do you not do so
promptly? Are you holding the owner hostage for some particular
purpose?
How many legal fees will be expended by black-hole list operators
arguing over whether blocking removal should be automatic on a per IP
address basis in so many days, or that all IP addresses may not be
handled separately as a result of this draft's recommendations. This
draft appears to be part of an ongoing effort to declare network
providers innocent of abuse sourced from their networks. On the
contrary, only network providers are able to know the entity
involved. As a result, _only_ network providers are able to be
effective at curbing abuse, and as such, must be held responsible when
they fail to act in curbing abuse.
Justifying a listing and de-listing policy should consider all
factors involved. This draft concludes de-listing interval of 180
days is sensible without a basis to support the claim.
You've beat this drum before Doug. Please suggest a different figure
with justification for YOUR figure. The 180 days figure is a maximum
period which we suggest you list between doing a re-check on your
listing criteria. It does NOT mean you have to remove the entry
after 180 days, simply that you update the listing within that
timeframe as IPs do change hands and change purposes.
This misses points made about the roles network providers MUST play.
When abuse is resolved to the AS, the concern of "changing hands" is
completely misplaced.
Despite all of this, these items are SHOULDs so that if your DNSBL
doesn't meet these criteria it is still ok by the BCP.
This still assumes blocking is always based upon the IP address and
not the AS. This is wrong. As a result, these ill considered
"shoulds" may lead to protracted litigation and increased amounts of
abuse when network providers use this draft's portrayal of best
practices as an excuse to dodge their responsibilities. Network
providers were only included in the historical overview. How quaint.
It does not help the cause to have these "SHOULD" statements which,
in the end, will likely prove highly counter productive. While
automation helps, it is not a complete solution, nor will automation
ever be. Automation can and is being gamed.
So build in anti-gaming measures. The freely run DNSBLs do.
What are the anti-gaming measures needed to sustain this draft's
concept of complete black-hole list automation? Currently there are
millions of IP addresses changing as a source of abuse every hour that
then go quiescent for months. A growing number of these sources have
even gained access to the provider's outbound servers as well.
Besides, automatic delisting can be implemented with human
intervention- notify your administrators that a range is about to be
delisted and should therefore be re-checked for it's listing
criteria, and the
expiration date moved back if required.
Did you say a range of IP addresses? Shouldn't the draft indicate how
to determine the boundaries separating different network providers?
Should this draft dare to discuss the detection of spoofed BGP
announcements? Such route spoofing could cause black-hole list
automation to becoming a method for staging massive DDoS attacks.
As a separate matter, should this draft mention the recognition of
RFC3464 in conjunction with content removal?
-Doug
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/asrg