[4135] in linux-net channel archive
Re: SYN floods
daemon@ATHENA.MIT.EDU (Racer X)
Thu Aug 22 02:09:36 1996
Date: Thu, 22 Aug 1996 00:34:36 -0400 (EDT)
From: Racer X <shagboy@wspice.com>
Reply-To: shagboy@bluesky.net
To: "Alex.Bligh" <amb@xara.net>
cc: Lefty <lefty@sliderule.geek.org.uk>, alan@cymru.net,
linux-net@vger.rutgers.edu, nelson@crynwr.com
In-Reply-To: <199608201744.SAA22563@diamond.xara.net>
On Tue, 20 Aug 1996, Alex.Bligh wrote:
> The latter is quite interesting. It was a suggestion for an
> RFC for a protocol which worked on the principle of working back
> from an 'attacked' host through the routers on the way asking
> each router 'where are you seeing traffic with a source address
> of w.x.y.z coming in', and if it did see traffic through one
> i/f, broadcasting the same packet up to upstream routers. Each
> router on the way reports back to the original host which
> builds up a map of where the traffic is coming from. Obviously
> certain people might chose to turn this off. But then they
> might well be treated as suspect.
This seems like it would generate an AWFUL lot of traffic - for each
packet, you have to trace the route all the way to destination, then send
back "ok" messages, then finally send the actual packet.
Am I missing something? I guess you could cache entries, but again, that
requires a lot of memory on the routers, and if you cache entries that
are "known bad", what happens when a new class C starts being used? Do
you have to wait for the bad entries to time out?
shag
Judd Bourgeois | When we are planning for posterity,
shagboy@bluesky.net | we ought to remember that virtue is
Finger for PGP key | not hereditary. Thomas Paine
