What do you want your ISP to block today?

Sat Aug 30 12:44:05 UTC 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. 