ietf-asrg
[Top] [All Lists]

Re: [Asrg] New draft draft-irtf-asrg-bcp-blacklists-01.txt

2008-03-27 17:07:23

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

<Prev in Thread] Current Thread [Next in Thread>