Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 1 Dec 2000 14:30:13 -0700 (MST)
From:      "David G. Andersen" <dga@pobox.com>
To:        brett@lariat.org (Brett Glass)
Cc:        dga@pobox.com (David G. Andersen), rjh@mohawk.net (Ralph Huntington), umesh@juniper.net (Umesh Krishnaswamy), freebsd-security@FreeBSD.ORG, steve@grc.com
Subject:   Re: Defeating SYN flood attacks
Message-ID:  <200012012130.OAA08033@faith.cs.utah.edu>
In-Reply-To: <4.3.2.7.2.20001201140439.048d42f0@localhost> from "Brett Glass" at Dec 01, 2000 02:08:29 PM

next in thread | previous in thread | raw e-mail | index | archive | help
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!  <big yellow smiley>" 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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200012012130.OAA08033>