Re: resistance to swamping attacks.
Bill Sommerfeld <sommerfeld@apollo.hp.com> Fri, 20 September 1996 00:09 UTC
Received: from relay.hq.tis.com by neptune.TIS.COM id aa14323; 19 Sep 96 20:09 EDT
Received: by relay.hq.tis.com; id UAA21972; Thu, 19 Sep 1996 20:13:12 -0400
Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1) id xma021967; Thu, 19 Sep 96 20:12:47 -0400
Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA19608; Thu, 19 Sep 96 20:11:54 EDT
Received: by relay.hq.tis.com; id UAA21963; Thu, 19 Sep 1996 20:12:41 -0400
Received: from relay.hp.com(15.255.152.2) by relay.tis.com via smap (V3.1.1) id xma021961; Thu, 19 Sep 96 20:12:27 -0400
Received: from it_750.ch.apollo.hp.com by relay.hp.com with ESMTP (1.37.109.16/15.5+ECS 3.3) id AA153248489; Thu, 19 Sep 1996 17:14:50 -0700
Message-Id: <199609200014.AA153248489@relay.hp.com>
Received: from snarfblatt.ch.apollo.hp.com by it_750.ch.apollo.hp.com id AA186618489; Thu, 19 Sep 1996 20:14:49 -0400
To: John Gilmore <gnu@toad.com>
Cc: ipsec@TIS.COM
Subject: Re: resistance to swamping attacks.
In-Reply-To: gnu's message of Thu, 19 Sep 1996 17:00:04 -0700. <199609200000.RAA28145@toad.com>
Date: Thu, 19 Sep 1996 20:14:48 -0400
From: Bill Sommerfeld <sommerfeld@apollo.hp.com>
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
Also, your goal assumes a non-interactive attack, that is, that the
attacker cannot see any of the outgoing traffic in response to the
attack.
This is deliberate, though I'm beginning to wonder if it might be a
case of "fighting the last war" ...
It's a much harder problem if the attacker is positioned on the
network so that they can snatch some of the cookies off the ether,
and send them back as part of the attack.
True. I was attempting to propose an engineering problem, not a PhD
dissertation topic..
I think the meta-goal is to require that a swamping attack actually
use up enough bandwidth that tracking the flow(s) back to its
originator(s) is easy.
and also receives ICMP messages resulting
from bouncing response packets consuming incoming bandwidth IZ.
Assume that the attacker is unable to read any of the response
packets.
Hmm. I'd rephrase this as
"Error packets generated in reply to responses to forged packets
should also be considered part of the incoming flooding
attack".
since different key mgt protocols may well use different ways to
return error messages.
- 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