North American Network Operators Group
Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: Customer-facing ACLs

  • From: Justin Shore
  • Date: Fri Mar 07 17:58:26 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