Re: Using cookies/computational effort to defeat syn-flooding
"Donald E. Eastlake 3rd" <dee@world.std.com> Mon, 23 September 1996 18:21 UTC
Received: from cnri by ietf.org id aa04690; 23 Sep 96 14:21 EDT
Received: from neptune.hq.tis.com by CNRI.Reston.VA.US id aa09679; 23 Sep 96 14:21 EDT
Received: from neptune.tis.com by neptune.TIS.COM id aa02108; 23 Sep 96 13:39 EDT
Received: from relay.hq.tis.com by neptune.TIS.COM id aa02092; 23 Sep 96 13:34 EDT
Received: by relay.hq.tis.com; id NAA22942; Mon, 23 Sep 1996 13:37:50 -0400
Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1) id xma022931; Mon, 23 Sep 96 13:37:24 -0400
Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA04693; Mon, 23 Sep 96 13:36:31 EDT
Received: by relay.hq.tis.com; id NAA22914; Mon, 23 Sep 1996 13:37:21 -0400
Received: from europe.std.com(199.172.62.20) by relay.tis.com via smap (V3.1.1) id xma022899; Mon, 23 Sep 96 13:37:08 -0400
Received: from world.std.com by europe.std.com (8.7.5/BZS-8-1.0) id NAA20789; Mon, 23 Sep 1996 13:39:27 -0400 (EDT)
Received: by world.std.com (5.65c/Spike-2.0) id AA04210; Mon, 23 Sep 1996 13:39:26 -0400
Message-Id: <199609231739.AA04210@world.std.com>
To: ipsec@tis.com
Subject: Re: Using cookies/computational effort to defeat syn-flooding
In-Reply-To: Your message of "Fri, 20 Sep 1996 17:14:38 EDT." <199609202114.AA17657@swan.lcs.mit.edu>
Date: Mon, 23 Sep 1996 13:39:26 -0400
From: "Donald E. Eastlake 3rd" <dee@world.std.com>
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
There are two facets to this problem, as I see it. One is spam packets of any type that have forged sources, can't be easily traced due to ISPs not being prepared to do this, etc. The second is fragile mechanisms that are easily toppled even without any forgery. While we need to fix the second where we can, there will always be packets that can cause trouble and evem just a string of nonsense packets firehosed at a host can degrade/deny service to others due to bandwidth considerations. ((Actually I wonder what the chance is that mostly random packets would crash the IP stack in an average host... Seems like the kind of test everyone would know you should do on your software but who knows...)) I think we need to always worry about the first with some sort of IP level mechanism that is very much cheaper than any of the current IPSECs and which also provides some assistance in tracing back the physical origin of packets. The Internet is increasingly under attack and we need continuing effort at making it more robust at all levels. Donald
- Using cookies to defeat syn-flooding Ron Rivest
- Re: Using cookies to defeat syn-flooding touch
- Re: Using cookies/computational effort to defeat … Donald E. Eastlake 3rd
- Re: Using cookies to defeat syn-flooding Matt Crawford
- Re: Using cookies to defeat syn-flooding Greg Minshall