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: Marshall Eubanks
  • Date: Sat Aug 30 11:00:44 2003

On Sat, 30 Aug 2003 13:44:05 +0100
 Ian Mason <[email protected]> wrote:
> 
> 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.
> 

It's not just UDP Multicast. Unicast streaming is moving towards UDP. In
Apple Darwin Streaming Server, for example, unicast streaming is UDP 
by default. Examination of my DSS server logs shows that over 2/3 of 
our video streaming in the last 2 months is over UDP.

In this UDP streaming there is return traffic but it is highly assymetric.

Regards
Marshall Eubanks

> 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. 
>