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