[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Using cookies to defeat syn-flooding

> From ipsec-request@neptune.hq.tis.com Mon Sep 23 05:51:48 1996
> From: Ron Rivest <rivest@theory.lcs.mit.edu>
> Date: Fri, 20 Sep 96 17:14:38 EDT
> To: ipsec@tis.com
> Subject: Using cookies to defeat syn-flooding
> 
> 
> Here is a thought on a scheme for defeating swamping (syn-flooding)
> attacks, together with an improvement suggested by Butler Lampson.
> Since I'm not an expert on network protocols, it needs review by those
> who are...
> 
> Flooding attack (paragraph to define problem and establish terminology):
> 
...
> The idea:
> 
> Defer A's allocation of resources until A has some confirmation that 
> B is "real". (I.e. until the third message of the three-message protocol
> is received from B).

This is the key issue - deferring resources. As others have
pointed out, this includes CPU time.

> How:
> 
> When A receives the first SYN packet, it does NOT generate a queue
> entry.  Rather, it sends B, as part of its return SYN packet, 
> a "cookie" that contains the information that the queue entry would have:
> 	-- source id of the SYN packet received
> 	-- when to time the connection request out
> 	-- port number
> 	-- other stuff (?)
> The cookie would contain this material in the clear, together with
> a cryptographic checksum (MAC) on this data, computing from the data
> of the cookie and a secret key known only to machine A. 

> When B replies, he returns the cookie, which A checks.  A cookie with
> an invalid MAC is discarded.  A cookie with a good MAC that has not
> timed out and which has not already been honored will generate a new

The time-out, together with the resources to store the cookie
and associated info, is the resource that needs to be
deferred.

So this has the same problem. Rather than tying up a TCP control block, 
this will tie-up your "cookie" table.

The presumption here must be that, by sending a cookie, the receiver
can time-out quicker. This can't occur, since a gap in the cookie-exchange 
has no effect on the timeout of the TCP connection establishment.

Joe
----------------------------------------------------------------------
Joe Touch - touch@isi.edu		    http://www.isi.edu/~touch/
ISI / Project Leader, ATOMIC-2, LSAM       http://www.isi.edu/atomic2/
USC / Research Assistant Prof.                http://www.isi.edu/lsam/

From: "carlisle (c.m.) adams" <cadams@nortel.ca>
Message-Id:  <"1680 Mon Sep 23 10:32:20 1996"@bnr.ca> 
To: jkennedy@cylink.com
Cc: johnmarc@cylink.com, ipsec@TIS.COM, ietf-pkix@tandem.com, 
    isakmp-oakley@cisco.com, skip-info@tik.ee.ethz.ch
Subject:  re:NOTICE: DSS Profile for X.509 Certificates to be deleted. 
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
Date: Mon, 23 Sep 96 12:39:20 EDT



In message "NOTICE: DSS Profile for X.509 Certificates to be deleted.", 
jkennedy@cylink.com writes:

>
>I received the following message from the Internet-Drafts Administrator about 
>a month ago regarding the deletion of the I-D John Marchioni and I co-authored 
>on a "DSS Profile for X.509 Certificates".  This draft was submitted only as 
>an interim solution since the PKIX was just coming up to speed and had not yet 
>included this material in the PKIX draft.  I do not know exactly what the 
>status of the X.509 DSS profile is in the PKIX document so I am sharing this 
>current status information with you now.  As far as I know DSS Certificates 
>are being used in both the SKIP and ISAKMP/Oakley reference implementations 
>and the aforementioned draft is cited in the applicable I-D's for these key 
>management protocols.
>
>I have a number of choices:
>
>a) Do nothing and let the draft gracefully expire.
>b) Update and submit a revised draft of draft-ietf-ipsec-dss-cert-00.txt.
>c) Pester the PKIX editors to make sure this material gets absorbed into their 
>next draft if it is not already there. (hint, hint...:) )
>
>My preference and intention is to do (a) and (c) and at most submit a revised 
>draft that simply points to PKIX.  It is not clear that a revised draft is 
>even necessary if current IPSEC and other working group drafts which point to 
>draft-ietf-ipsec-dss-cert-00.txt are revised to now point to pkix-3.


Do you really mean "pkix-3" here, or do you mean "pkix-1".  Part three is
the certificate management protocols -- it's not clear to me that a DSS profile
for X.509 certificates belongs there.  Or am I missing something?

Carlisle.



From: Ran Atkinson <rja@inet.org>
Reply-To: rja1@home.net
Organization: The Internet Guild
X-Mailer: Mozilla 3.0 (Win95; I)
Mime-Version: 1.0
To: senvad@hotmail.com
Cc: ipsec@TIS.COM
Subject: IPsec Security Association attributes
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
Date: Mon, 23 Sep 96 13:18:23 EDT
Message-ID:  <9609231318.aa01788@neptune.TIS.COM>

Hi,

  Please go read RFC-1825, available online from
ftp://ds.internic.net/rfc/rfc1825.txt, where the attributes
of an IPsec Security Association are defined.

  If you're looking for reference code, I usually recommend
examining the NRL IPsec source code for 4.4 BSD available from
	http://web.mit.edu/network/isakmp/
OR	ftp://ftp.ripe.net/ipv6/nrl/

Thanks,

Ran
rja@inet.org