[4323] in North American Network Operators' Group
Re: SYN floods (was: does history repeat itself?)
daemon@ATHENA.MIT.EDU (Curtis Villamizar)
Thu Sep 12 13:13:29 1996
To: perry@piermont.com
cc: nanog@merit.edu
Reply-To: curtis@ans.net
In-reply-to: Your message of "Mon, 09 Sep 1996 13:19:02 EDT."
<199609091719.NAA24855@jekyll.piermont.com>
Date: Thu, 12 Sep 1996 13:07:59 -0400
From: Curtis Villamizar <curtis@ans.net>
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
