From owner-freebsd-security Fri Dec 1 13:30:36 2000 Delivered-To: freebsd-security@freebsd.org Received: from faith.cs.utah.edu (faith.cs.utah.edu [155.99.198.108]) by hub.freebsd.org (Postfix) with ESMTP id 645EA37B400 for ; Fri, 1 Dec 2000 13:30:31 -0800 (PST) Received: (from danderse@localhost) by faith.cs.utah.edu (8.9.3/8.9.3) id OAA08033; Fri, 1 Dec 2000 14:30:13 -0700 (MST) Message-Id: <200012012130.OAA08033@faith.cs.utah.edu> Subject: Re: Defeating SYN flood attacks To: brett@lariat.org (Brett Glass) Date: Fri, 1 Dec 2000 14:30:13 -0700 (MST) Cc: dga@pobox.com (David G. Andersen), rjh@mohawk.net (Ralph Huntington), umesh@juniper.net (Umesh Krishnaswamy), freebsd-security@FreeBSD.ORG, steve@grc.com In-Reply-To: <4.3.2.7.2.20001201140439.048d42f0@localhost> from "Brett Glass" at Dec 01, 2000 02:08:29 PM From: "David G. Andersen" X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Lo and behold, Brett Glass once said: > > b) An evaluation of the computational load of performing an > > encryption on every SYN. Does this create a CPU DOS attack? > > Good question! This can probably be controlled by the number of > rounds of encryption. You need sufficient rounds of encryption so that it's not trivial to break; the recommended number of rounds for RC5 these days is sixteen, not twelve. Regardless of the number nitpicking, the time it takes to perform this encryption in a secure manner is nontrivial, though likely not huge since there's a constant key and relatively static IV. > > c) An evaluation of how it times out old SYN packets > > (replay, packet duplication). What are the consequences? > > Steve's algorithm doesn't have any timeouts. I think that this is > one of its weaknesses: the key is only changed at each boot, > instead of, say, hourly. This leaves a server open to known > plaintext attacks which can drastically limit the search space > required to break the cipher. This is fixable; you could have a rollover period where you check the key against two different tables, for instance. But that adds to the complexity and to the CPU requirements. .. but like I said: I think his proposal needs more serious thought than it's been given before we chuck it into the kernel. I'm fairly certain that there are other questions that should be raised and answered about his scheme. That doesn't mean I think it's a bad idea - I like it, though his presentation sucks - it just needs more careful consideration than his own "It's perfect! " paper. -Dave -- work: dga@lcs.mit.edu me: dga@pobox.com MIT Laboratory for Computer Science http://www.angio.net/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message