Customer-facing ACLs

Fri Mar 7 22:54:52 UTC 2008

Scott Weeks wrote:

> fire + gasoline = religious argument on this issue that we've had *many* times in the past...  ;-)

I wore my flame-retardent tidy whiteys today though so I'm prepared. :-)

I can understand the problem from both camps.  As a tech-savvy user I 
don't want my provider to filter my Internet (I pay for both halves!). 
However having spent more time that I care to admit doing customer 
support and as a SP engineer I recognize the need to protect the masses 
who can't (or can't be bothered to) do it for themselves.  SPs are 
really damned if we do and damned if we don't.  Frankly I would rather 
do something than nothing.  My overhead will increase in all categories 
if I do nothing.  Infected hosts consume a significant portion of my 
resources.  Tackling the problem reduces my overall support costs, 
increases 99% of my customers' overall satisfaction with our prices and 
services, but increases my labor costs and will spurn the ire of the 1% 
of my users who are tech-savvy enough to want/need unfiltered Internet 
access (or even understand the full implications of it, beyond the 
"they're filtering something that was sent to me!" limited thought 
process).

To me there is no question of whether or not you filter traffic for 
residential broadband customers.  The only thing beyond that is whether 
you as a SP also offer unfiltered packages.  I personally thought the 
old SpeakEasy model was a nice approach.  The unfiltered SysAdmin 
package was the perfect solution in my opinion.  With my userbase I can 
think of only a tiny fraction of the users who would need such an 
offering.  This would provide an acceptable solution for that very small 
percentage of users that need this kind of access.  The other 99% of the 
users reap the benefits of our filtering.  Problem solved IMHO.

So that only leaves the question of what ports to block or rate-limit. 
Minimizing FPs is important.  I think one could probably block 90% of 
the common crap without too much overhead.  The remaining 10% would 
likely require too much labor to be worthwhile unless you were a sizable 
entity and could justify you R&D by the sheer mass of your userbase.

Justin