In message <199609091719.NAA24855@jekyll.piermont.com>, "Perry E. Metzger" writ es:
Re: SYN floods
PANIX, a large public access provider in New York, was badly hit with SYN flood attacks from random source addresses over the last few days. It nearly wrecked them.
I think its time for the larger providers to start filtering packets coming from customers so that they only accept packets with the customer's network number on it.
Yes, its a load on routers. Yes, its nasty for the mobile IP weenies. Unfortunately, the only known way to stop this. Many TCPs go belly up as soon as they get SYN flooded -- its a defect in the protocol design, and other than Karn style anti-clogging tokens ("cookies") being put into a TCP++ and mass implemented worldwide soon, the only reasonable way to stop this sort of terrorism is provider filtering.
Perry
Perry, I'm not arguing against your point. There are some feasibility issues right now that mean we can't just "turn this on". Packet filtering on prefixes is only feasible as slower speeds with current routers and even then it can give smaller routers a tough time. There is also a problem with packet filtering due to assymetric routing. You can legitimately end up with packets coming from addresses other than those that you route towards and should not black hole that traffic. Given the practical limits, this is a good idea for single homed customers behind a router that can handle it. The problem is what can large providers do about other providers that don't even want to keep track of who their customers are and exchanging the list of prefixes with other providers in support of reliable routing. If routing were symetric, you could look up the destination and only take packets whose source address is reached through that path (given influence on the forwarding code). This was actually considered in the NSFNET days. Routing often isn't symmetric so this would present a black hole problem and so it wasn't done. An alternate is to keep stats on the source/dest prefix pairs (not host pairs). If stats on all of your routers are collected and forged source flooding attacks occur, you need to look at all of the routers for the src/dst pairs reported by the target of the attack. You have then traced the problem back to the physical entry point to your own network. This *was* done in the NSFNET days. If the commonly used routers supported this sort of stat collection providers could quite easily trace an attack back to the source (or at least back to a provider in the path not collecting stats). We've made this request (the ability to collect these sort of stats) to both Bay and Cisco (neither has said "no" but they are busy and haven't got to this yet). I think providing the means to trace back these attacks represents the best large provider level solution to the forged source SYN flooding attacks. At the single homed connection a router option to reverse the sense of the forwarding table on a specific interface (look up the source in the forwarding table and only accept if the source is reachable through that next hop) seems to be a effective preventative that could be easily just "switched on". Otherwise prefix filters have to be configured, which does represent work for the ISP and so won't get done. We have not yet made this request of Bay or Cisco (unless they are reading right now). This would help, except for the providers whose routers don't even support CIDR yet (and are unlikely to pick this up quickly) from whom some of these attacks may originate. Curtis