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
- resistance to swamping attacks. Bill Sommerfeld
- Re: resistance to swamping attacks. Kim L. Toms
- Re: resistance to swamping attacks. Robert Moskowitz
- Re: resistance to swamping attacks. Matt Crawford
- Re: resistance to swamping attacks. Bill Sommerfeld
- Re: resistance to swamping attacks. Bill Sommerfeld
- Re: resistance to swamping attacks. touch
- Re: resistance to swamping attacks. Bill Sommerfeld
- Re: resistance to swamping attacks. Bill Sommerfeld
- Re: resistance to swamping attacks. touch
- Re: resistance to swamping attacks. Bill Sommerfeld
- Re: resistance to swamping attacks. touch
- Re: resistance to swamping attacks. Germano Caronni
- Re: resistance to swamping attacks. touch
- Re: resistance to swamping attacks. Germano Caronni