resistance to swamping attacks.

Bill Sommerfeld <sommerfeld@apollo.hp.com> Thu, 19 September 1996 16:55 UTC

Received: from cnri by ietf.org id aa02233; 19 Sep 96 12:55 EDT
Received: from neptune.hq.tis.com by CNRI.Reston.VA.US id aa29391; 19 Sep 96 12:54 EDT
Received: from neptune.tis.com by neptune.TIS.COM id aa08868; 19 Sep 96 12:32 EDT
Received: from relay.hq.tis.com by neptune.TIS.COM id aa08852; 19 Sep 96 12:25 EDT
Received: by relay.hq.tis.com; id MAA08983; Thu, 19 Sep 1996 12:29:16 -0400
Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1) id xma008977; Thu, 19 Sep 96 12:28:49 -0400
Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA28147; Thu, 19 Sep 96 12:28:00 EDT
Received: by relay.hq.tis.com; id MAA08969; Thu, 19 Sep 1996 12:28:46 -0400
Received: from capone.ch.apollo.hp.com(15.254.24.3) by relay.tis.com via smap (V3.1.1) id xma008945; Thu, 19 Sep 96 12:28:24 -0400
Received: from thunk.orchard.medford.ma.us (thunk.ch.apollo.hp.com) by capone.ch.apollo.hp.com id <AA295390630@capone.ch.apollo.hp.com>; Thu, 19 Sep 1996 12:30:30 -0400
Received: from thunk (sommerfeld@localhost) by thunk.orchard.medford.ma.us (8.6.12/8.6.12) with ESMTP id MAA00380 for <ipsec@tis.com>; Thu, 19 Sep 1996 12:30:29 -0400
Message-Id: <199609191630.MAA00380@thunk.orchard.medford.ma.us>
X-Authentication-Warning: thunk.orchard.medford.ma.us: sommerfeld owned process doing -bs
To: ipsec@tis.com
Subject: resistance to swamping attacks.
Date: Thu, 19 Sep 1996 12:30:27 -0400
From: Bill Sommerfeld <sommerfeld@apollo.hp.com>
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk

at the last IETF meeting, there was a presentation about how cookies
don't necessarily help all that much.

There have been a number of press reports about swamping attacks on
TCP using forged source addresses.  Some of these press reports have
suggested that IPv6 will solve all this by requiring authentication.

I'd like this to be the truth, not just optimism..

I think that one of the not-well-stated requirements of ipsec is that
it resist such attacks -- most importantly, that a system be able to
continue to communicate with legitimate peers in the face of a
packet-storm, including peers it did not have any shared state with
prior to the start of the storm.

Here's a more specific goal:

If a system has a normal communications bandwidth of X, and recieves
an incoming storm from forged source addresses with a bandwidth of Y
(less than X), it should be able to continue to use at least half of
the remaining bandwith (X-Y) constructively to communicate with
arbitrary legitimate peers, including peers which had never before
communicated with it.

Now, at some level, this is a property of the implementation, but
nothing in the *protocol* should preclude this.

Any objections?

					- Bill