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

Re: What do you want your ISP to block today?

  • From: Ian Mason
  • Date: Sat Aug 30 09:25:09 2003 
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 filtering it.

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.