Quarantining infected hosts (Was: FBI tells the public to call their ISP for help)

Sean Donelan sean at donelan.com
Wed Jun 20 17:14:52 UTC 2007

On Tue, 19 Jun 2007, Jack Bates wrote:
> This sounds great, except it doesn't scale. My router says there is no 
> noticeable difference between tcp/25 and tcp/445, or udp/134 or udp/1434 or 
> tcp/1025, or tcp/80. It asked if we should just block all ports and force 
> people through proxy servers. Why mitigate one vector when you can take them 
> all out? What makes SMTP so special a vector?

Actually, yes ISPs should block them all.  That's a bit provocative, but
lets work through it.

Its a question of what should be the "defaults" for various types of 
Internet connections.  Almost every consumer grade router/modem (d-link, 
linksys, netgear, etc) now includes stateful packet firewalls.  Almost 
all recent consumer operating systems now include a stateful packet 

While the ultimate decision should remain the subscriber's, ISPs still 
should adopt improved "default" settings for today's Internet.  If a 
subscriber wants to surf the Internet naked, that should be their informed
choice. If you use the principle of least surprise, most retail consumers 
don't initially expect their computers to be "open" to the Internet or
for their computer to do things they didn't initiate.

Individual "default settings" shouldn't be in the backbone, that doesn't
scale.  However, at the "edge" (or near edge, which might be on the 
provider side of the demarc or the user side of the demarc) may be a good 
spot for some things we've found we can't trust with hosts/applications.

Most of the work on improving defaults for CPE and "near edge" defaults is
not occuring in the IETF.  Instead CableLabs and the DSL Forum have been
the leaders in this area.  While the "default" might be to block 
unexpected/unusual traffic, the ISP, edge, cpe, etc should all give
the user the control until they abuse it.

Caution: UltraDNS/Neustar's monthly rates aren't month to month.

More information about the NANOG mailing list