From: William Allen Simpson <william.allen.simpson@gmail.com>
To: netdev@vger.kernel.org
Subject: Re: Enable syn cookies by default
Date: Wed, 21 Oct 2009 14:36:09 -0400 [thread overview]
Message-ID: <4ADF5499.2080107@gmail.com> (raw)
In-Reply-To: <b2cc26e40910210310o31ca24dcv50f8bd0c3234b71b@mail.gmail.com>
Olaf van der Spek wrote:
> How and when do they interfere?
> If syn cookies are enabled and the queue isn't full, they're not used
> so they don't interfere.
> If the queue is full, they do interfere, but the alternative would be
> no connection at all.
You just answered your own question, both "how" and "when"....
> So I really don't see the disadvantage of enabling cookies by default.
>
On systems with long delay paths, it represents turning back the clock
more than a decade or so. A better solution is usually a firewall/IDS.
The best solution: I'm working on it.
As I'm sure you're aware, Timestamps and Sack options are fairly crucial.
>> As Ubuntu is debian based, perhaps they can back-port the Ubuntu changes?
>
> Actually changing the value isn't the problem, but the Debian
> maintainer isn't sure it's a good idea (but he doesn't know why).
>
Well, that depends. For a client, it's a good idea, as the defense is
mostly local and rare. For a server run by a small underfunded ISP, it's
still a good idea as a last ditch defense. But for a full-fledged ISP,
especially running in a satellite environment or with a lot of dial-up
customers, it's terrible!
That's a reason the Ubuntu configuration approach works for me.
A caveat: I've not run debian directly in many, many years (IIRC, since
Red Hat Colgate), and more recently via Unbuntu (since Badger). I don't
know whether debian has evolved different installation procedures for
different environments.
My comments are based on fairly extensive experience with deployment of
Yellow Dog Linux servers at an ISP (as a co-founder), and Ubuntu clients
for the past 2 (US) election cycles.
next prev parent reply other threads:[~2009-10-21 18:36 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-10-10 13:01 Enable syn cookies by default Olaf van der Spek
2009-10-11 10:26 ` Frans Pop
2009-10-15 8:59 ` Olaf van der Spek
2009-10-16 8:55 ` Jarek Poplawski
2009-10-16 19:01 ` Jarek Poplawski
2009-10-16 19:56 ` Florian Westphal
2009-10-16 19:49 ` [PATCH 1/2] syncookies: print synflood warning if syn queue is full Florian Westphal
2009-10-16 19:51 ` [PATCH 2/2] syncookies: enable by default Florian Westphal
2009-12-08 14:47 ` [PATCH 1/2] syncookies: print synflood warning if syn queue is full Olaf van der Spek
2009-12-08 21:09 ` David Miller
2010-01-27 17:01 ` Olaf van der Spek
2009-10-21 7:17 ` Enable syn cookies by default Olaf van der Spek
2009-10-21 7:25 ` Eric Dumazet
2009-10-21 7:48 ` Olaf van der Spek
2009-10-21 9:16 ` William Allen Simpson
2009-10-21 10:10 ` Olaf van der Spek
2009-10-21 18:36 ` William Allen Simpson [this message]
2009-10-21 18:45 ` Olaf van der Spek
2009-10-21 13:04 ` David Miller
2009-10-21 18:04 ` William Allen Simpson
2009-11-13 12:42 ` Olaf van der Spek
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4ADF5499.2080107@gmail.com \
--to=william.allen.simpson@gmail.com \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.