mailing list archives
Re: What do you want your ISP to block today?
From: Ian Mason <nanog () ian co uk>
Date: Sat, 30 Aug 2003 13:44:05 +0100
At 07:33 30/08/2003, Iljitsch van Beijnum wrote:
On zaterdag, aug 30, 2003, at 05:42 Europe/Amsterdam, Sean Donelan wrote:
If you don't want to download patches from Microsoft, and don't want to
pay McAfee, Symantec, etc for anti-virus software; should ISPs start
charging people clean up fees when their computers get infected?
Only if it impacts the ISP, which it doesn't most of the time unless they
buy an unfortunate brand of dial-up concentrators.
Would you pay an extra $50/Mb a month for your ISP to operate a firewall
and scan your traffic for you?
No way. They have no business even looking at my traffic, let alone
What would be great though is a system where there is an automatic check
to see if there is any return traffic for what a customer sends out. If
someone keeps sending traffic to the same destination without anything
coming back, 99% chance that this is a denial of service attack. If
someone sends traffic to very many destinations and in more than 50 or 75
% of the cases nothing comes back or just an ICMP port unreachable or TCP
RST, 99% chance that this is a scan of some sort.
This is fine until a customers sends out legitimate multicast traffic, so
any such scheme has to ignore multicast traffic. Then the worms and virus
writers will just switch to using multicast as a vector.
Also this only works where routing is strictly symmetrical (e.g. edge
connections, and to single homed edges at that).
It also has the problem that you have to retain some state (possibly
little) for all outbound traffic until you can match it to inbound traffic.
Given the paupacity of memory in most edge routers this is a problem. Even
with a decent amount of memory, it would soon get overrun, even on a
slowish circuit like a T1. A DSLAM with several hundred DSL lines would
need lots of memory to implement this, and lots of CPU cycles to manage it.
At the layer 3 level, all TCP traffic is revertive as it has to send ACKs
back so this scheme can't simply work on '"I've seen another packet in the
reverse direction, so it's OK". So we have to work on byte counts and see
if what goes one way is balanced by what goes another way.
Then it gets worse still, much legitimate traffic is highly asymmetric. In
a POP3 session, most traffic is one way and only a small quantity of high
level ACKs go the other way. Ditto SMTP and most HTTP traffic.
So, we're reached the stage that, for this to work, it has to have at least
the complexity of a stateful firewall. OK, that is doable, at a cost. But
in the process we seem to have lost any characteristic of asymmetry that
allows us to distinguish good from bad traffic.