Re: Enable syn cookies by default

Re: Enable syn cookies by default

[Frans Pop]

This question is better asked on the kernel network development list.
Original mail from Olaf below.

Cheers,
FJP

=================
Hi,

I'm forwarding Debian feature request #520668.

Could syn cookies be enabled by default?

AFAIK syn cookies only get send when the half-open TCP connection
queue is full. So stuff like window scaling should work fine in normal
situations.

Speaking of which:
When the half-open TCP connection queue is full and syn cookies are
enabled, you get a message like "kernel: possible SYN flooding on port
2710. Sending cookies."
However when syn cookies are disabled, you don't get any message (in
kern.log), although connections to your server are timing out.
Could such a message be added?
Maybe with a suggestion to increase the size of that queue or to
enable syn cookies.

Greetings,

Olaf

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=520668
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=520667
https://bugs.launchpad.net/ubuntu/+bug/57091

Re: Enable syn cookies by default

[Olaf van der Spek]

On Sat, Oct 10, 2009 at 3:01 PM, Olaf van der Spek <olafvdspek@gmail.com> wrote:
> Hi,
>
> I'm forwarding Debian feature request #520668.
>
> Could syn cookies be enabled by default?
>
> AFAIK syn cookies only get send when the half-open TCP connection
> queue is full. So stuff like window scaling should work fine in normal
> situations.
>
> Speaking of which:
> When the half-open TCP connection queue is full and syn cookies are
> enabled, you get a message like "kernel: possible SYN flooding on port
> 2710. Sending cookies."
> However when syn cookies are disabled, you don't get any message (in
> kern.log), although connections to your server are timing out.
> Could such a message be added?
> Maybe with a suggestion to increase the size of that queue or to
> enable syn cookies.
>
> Greetings,
>
> Olaf
>
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=520668
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=520667
> https://bugs.launchpad.net/ubuntu/+bug/57091
>

Somebody?

Re: Enable syn cookies by default

[Jarek Poplawski]

On 15-10-2009 10:59, Olaf van der Spek wrote:
> On Sat, Oct 10, 2009 at 3:01 PM, Olaf van der Spek <olafvdspek@gmail.com> wrote:
>> Hi,
>>
>> I'm forwarding Debian feature request #520668.
>>
>> Could syn cookies be enabled by default?

Hi,

Alas, I can only give you a hint: while waiting for a better response,
you could try to 'google' for some archives of this list; AFAICR a few
(?) months ago David Miller explained this first question at least.
(In short: they aren't up-to-date enough.)

Regards,
Jarek P.

>>
>> AFAIK syn cookies only get send when the half-open TCP connection
>> queue is full. So stuff like window scaling should work fine in normal
>> situations.
>>
>> Speaking of which:
>> When the half-open TCP connection queue is full and syn cookies are
>> enabled, you get a message like "kernel: possible SYN flooding on port
>> 2710. Sending cookies."
>> However when syn cookies are disabled, you don't get any message (in
>> kern.log), although connections to your server are timing out.
>> Could such a message be added?
>> Maybe with a suggestion to increase the size of that queue or to
>> enable syn cookies.
>>
>> Greetings,
>>
>> Olaf
>>
>> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=520668
>> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=520667
>> https://bugs.launchpad.net/ubuntu/+bug/57091
>>
> 
> Somebody?

Re: Enable syn cookies by default

[Jarek Poplawski]

Jarek Poplawski wrote, On 10/16/2009 10:55 AM:

> On 15-10-2009 10:59, Olaf van der Spek wrote:
>> On Sat, Oct 10, 2009 at 3:01 PM, Olaf van der Spek <olafvdspek@gmail.com> wrote:
>>> Hi,
>>>
>>> I'm forwarding Debian feature request #520668.
>>>
>>> Could syn cookies be enabled by default?
> 
> Hi,
> 
> Alas, I can only give you a hint: while waiting for a better response,
> you could try to 'google' for some archives of this list; AFAICR a few
> (?) months ago David Miller explained this first question at least.
> (In short: they aren't up-to-date enough.)

It looks like my memory is exact only about dates ("?"! ;-). There was
mainly David's opinion and some more in the thread (shared with lkml).
Here is a link:
http://lkml.indiana.edu/hypermail/linux/kernel/0807.3/0050.html

Jarek P.

Re: Enable syn cookies by default

[Florian Westphal]

Jarek Poplawski <jarkao2@gmail.com> wrote:
> > On 15-10-2009 10:59, Olaf van der Spek wrote:
> >> On Sat, Oct 10, 2009 at 3:01 PM, Olaf van der Spek <olafvdspek@gmail.com> wrote:
> >>> Hi,
> >>>
> >>> I'm forwarding Debian feature request #520668.
> >>>
> >>> Could syn cookies be enabled by default?
> > 
> > Hi,
> > 
> > Alas, I can only give you a hint: while waiting for a better response,
> > you could try to 'google' for some archives of this list; AFAICR a few
> > (?) months ago David Miller explained this first question at least.
> > (In short: they aren't up-to-date enough.)
> 
> It looks like my memory is exact only about dates ("?"! ;-). There was
> mainly David's opinion and some more in the thread (shared with lkml).
> Here is a link:
> http://lkml.indiana.edu/hypermail/linux/kernel/0807.3/0050.html

Hrm, strange.

The syncookie sysctl only has an effect on tcp options
once a listening sockets' syn queue is full. And even if you lose all
the tcp options -- without tcp_syncookies=1, the connection request
would have been discarded. So I do not really understand why they
shouldn't default to 1. I've sent patches for both points raised
(no warning about syn queue overflow if cookies are disabled,
 syncookies sysctl defaults to 0), lets see what happens :-)

[PATCH 1/2] syncookies: print synflood warning if syn queue is full

[Florian Westphal]

Always print a warning if the syn queue is full, just like
the tcp/ipv6 code does.

The "want_cookie" define is no longer needed -- gcc
removes the relevant branches in the CONFIG_SYN_COOKIES=n case.

Signed-off-by: Florian Westphal <fw@strlen.de>
---
 net/ipv4/tcp_ipv4.c |   27 ++++++++++++---------------
 1 files changed, 12 insertions(+), 15 deletions(-)

diff --git a/net/ipv4/tcp_ipv4.c b/net/ipv4/tcp_ipv4.c
index 7cda24b..93b02a3 100644
--- a/net/ipv4/tcp_ipv4.c
+++ b/net/ipv4/tcp_ipv4.c
@@ -786,19 +786,19 @@ static void tcp_v4_reqsk_destructor(struct request_sock *req)
 	kfree(inet_rsk(req)->opt);
 }
 
-#ifdef CONFIG_SYN_COOKIES
 static void syn_flood_warning(struct sk_buff *skb)
 {
-	static unsigned long warntime;
-
-	if (time_after(jiffies, (warntime + HZ * 60))) {
-		warntime = jiffies;
+#ifdef CONFIG_SYN_COOKIES
+	if (sysctl_tcp_syncookies)
 		printk(KERN_INFO
-		       "possible SYN flooding on port %d. Sending cookies.\n",
-		       ntohs(tcp_hdr(skb)->dest));
-	}
-}
+		       "Possible SYN flooding on port %d. "
+		       "Sending cookies.\n", ntohs(tcp_hdr(skb)->dest));
+	else
 #endif
+		printk(KERN_INFO
+		       "Possible SYN flooding on port %d. "
+		       "Dropping request.\n", ntohs(tcp_hdr(skb)->dest));
+}
 
 /*
  * Save and compile IPv4 options into the request_sock if needed.
@@ -1217,11 +1217,7 @@ int tcp_v4_conn_request(struct sock *sk, struct sk_buff *skb)
 	__be32 daddr = ip_hdr(skb)->daddr;
 	__u32 isn = TCP_SKB_CB(skb)->when;
 	struct dst_entry *dst = NULL;
-#ifdef CONFIG_SYN_COOKIES
 	int want_cookie = 0;
-#else
-#define want_cookie 0 /* Argh, why doesn't gcc optimize this :( */
-#endif
 
 	/* Never answer to SYNs send to broadcast or multicast */
 	if (skb_rtable(skb)->rt_flags & (RTCF_BROADCAST | RTCF_MULTICAST))
@@ -1232,6 +1228,8 @@ int tcp_v4_conn_request(struct sock *sk, struct sk_buff *skb)
 	 * evidently real one.
 	 */
 	if (inet_csk_reqsk_queue_is_full(sk) && !isn) {
+		if (net_ratelimit())
+			syn_flood_warning(skb);
 #ifdef CONFIG_SYN_COOKIES
 		if (sysctl_tcp_syncookies) {
 			want_cookie = 1;
@@ -1283,10 +1281,9 @@ int tcp_v4_conn_request(struct sock *sk, struct sk_buff *skb)
 
 	if (want_cookie) {
 #ifdef CONFIG_SYN_COOKIES
-		syn_flood_warning(skb);
 		req->cookie_ts = tmp_opt.tstamp_ok;
-#endif
 		isn = cookie_v4_init_sequence(sk, skb, &req->mss);
+#endif
 	} else if (!isn) {
 		struct inet_peer *peer = NULL;
 
-- 
1.6.3.3

[PATCH 2/2] syncookies: enable by default

[Florian Westphal]

change syncookie sysctl initialization to 1.

Syn cookies have no effect under normal conditions; cookies are
only sent if a sockets syn queue is exhausted (and the connection
request would be dropped with cookies disabled).

sysctl_tcp_syncookies needs to be set to 0 in the CONFIG_SYN_COOKIES=n
case, as tcp_v4_conn_request() evaluates the variable in a conditional
expression (which then would always be false).

Signed-off-by: Florian Westphal <fw@strlen.de>
---
 net/ipv4/Kconfig         |    7 +++----
 net/ipv4/tcp_minisocks.c |    6 +++---
 2 files changed, 6 insertions(+), 7 deletions(-)

diff --git a/net/ipv4/Kconfig b/net/ipv4/Kconfig
index 70491d9..86e5bc8 100644
--- a/net/ipv4/Kconfig
+++ b/net/ipv4/Kconfig
@@ -289,7 +289,7 @@ config ARPD
 	  If unsure, say N.
 
 config SYN_COOKIES
-	bool "IP: TCP syncookie support (disabled per default)"
+	bool "IP: TCP syncookie support"
 	---help---
 	  Normal TCP/IP networking is open to an attack known as "SYN
 	  flooding". This denial-of-service attack prevents legitimate remote
@@ -314,11 +314,10 @@ config SYN_COOKIES
 	  server is really overloaded. If this happens frequently better turn
 	  them off.
 
-	  If you say Y here, note that SYN cookies aren't enabled by default;
-	  you can enable them by saying Y to "/proc file system support" and
+	  You can disable them by saying Y to "/proc file system support" and
 	  "Sysctl support" below and executing the command
 
-	  echo 1 >/proc/sys/net/ipv4/tcp_syncookies
+	  echo 0 >/proc/sys/net/ipv4/tcp_syncookies
 
 	  at boot time after the /proc file system has been mounted.
 
diff --git a/net/ipv4/tcp_minisocks.c b/net/ipv4/tcp_minisocks.c
index 624c3c9..2b0ddc2 100644
--- a/net/ipv4/tcp_minisocks.c
+++ b/net/ipv4/tcp_minisocks.c
@@ -26,10 +26,10 @@
 #include <net/inet_common.h>
 #include <net/xfrm.h>
 
-#ifdef CONFIG_SYSCTL
-#define SYNC_INIT 0 /* let the user enable it */
-#else
+#ifdef CONFIG_SYN_COOKIES
 #define SYNC_INIT 1
+#else
+#define SYNC_INIT 0 /* tcp_ipv4.c checks sysctl_tcp_syncookies even if CONFIG_SYN_COOKIES=n */
 #endif
 
 int sysctl_tcp_syncookies __read_mostly = SYNC_INIT;
-- 
1.6.3.3

Re: [PATCH 1/2] syncookies: print synflood warning if syn queue is full

[Olaf van der Spek]

On Fri, Oct 16, 2009 at 8:49 PM, Florian Westphal <fw@strlen.de> wrote:
> Always print a warning if the syn queue is full, just like
> the tcp/ipv6 code does.
>
> The "want_cookie" define is no longer needed -- gcc
> removes the relevant branches in the CONFIG_SYN_COOKIES=n case.
>
> Signed-off-by: Florian Westphal <fw@strlen.de>

Any comments?

Olaf

Re: [PATCH 1/2] syncookies: print synflood warning if syn queue is full

[David Miller]

From: Olaf van der Spek <olafvdspek@gmail.com>
Date: Tue, 8 Dec 2009 15:47:59 +0100

> On Fri, Oct 16, 2009 at 8:49 PM, Florian Westphal <fw@strlen.de> wrote:
>> Always print a warning if the syn queue is full, just like
>> the tcp/ipv6 code does.
>>
>> The "want_cookie" define is no longer needed -- gcc
>> removes the relevant branches in the CONFIG_SYN_COOKIES=n case.
>>
>> Signed-off-by: Florian Westphal <fw@strlen.de>
> 
> Any comments?

You patch isn't even in patchwork any more, so for one thing
it's definitely not in my queue any more.

Re: [PATCH 1/2] syncookies: print synflood warning if syn queue is full

[Olaf van der Spek]

On Tue, Dec 8, 2009 at 10:09 PM, David Miller <davem@davemloft.net> wrote:
> From: Olaf van der Spek <olafvdspek@gmail.com>
> Date: Tue, 8 Dec 2009 15:47:59 +0100
>
>> On Fri, Oct 16, 2009 at 8:49 PM, Florian Westphal <fw@strlen.de> wrote:
>>> Always print a warning if the syn queue is full, just like
>>> the tcp/ipv6 code does.
>>>
>>> The "want_cookie" define is no longer needed -- gcc
>>> removes the relevant branches in the CONFIG_SYN_COOKIES=n case.
>>>
>>> Signed-off-by: Florian Westphal <fw@strlen.de>
>>
>> Any comments?
>
> You patch isn't even in patchwork any more, so for one thing
> it's definitely not in my queue any more.

Florian?

Re: Enable syn cookies by default

[Olaf van der Spek]

On Thu, Oct 15, 2009 at 10:59 AM, Olaf van der Spek
<olafvdspek@gmail.com> wrote:
> On Sat, Oct 10, 2009 at 3:01 PM, Olaf van der Spek <olafvdspek@gmail.com> wrote:
>> Hi,
>>
>> I'm forwarding Debian feature request #520668.
>>
>> Could syn cookies be enabled by default?
>>
>> AFAIK syn cookies only get send when the half-open TCP connection
>> queue is full. So stuff like window scaling should work fine in normal
>> situations.
>>
>> Speaking of which:
>> When the half-open TCP connection queue is full and syn cookies are
>> enabled, you get a message like "kernel: possible SYN flooding on port
>> 2710. Sending cookies."
>> However when syn cookies are disabled, you don't get any message (in
>> kern.log), although connections to your server are timing out.
>> Could such a message be added?
>> Maybe with a suggestion to increase the size of that queue or to
>> enable syn cookies.
>>
>> Greetings,
>>
>> Olaf
>>
>> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=520668
>> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=520667
>> https://bugs.launchpad.net/ubuntu/+bug/57091
>>
>
> Somebody?

Anybody?

Re: Enable syn cookies by default

[Eric Dumazet]

Olaf van der Spek a écrit :
> On Thu, Oct 15, 2009 at 10:59 AM, Olaf van der Spek
> <olafvdspek@gmail.com> wrote:
>> On Sat, Oct 10, 2009 at 3:01 PM, Olaf van der Spek <olafvdspek@gmail.com> wrote:
>>> Hi,
>>>
>>> I'm forwarding Debian feature request #520668.
>>>
>>> Could syn cookies be enabled by default?
>>>
>>> AFAIK syn cookies only get send when the half-open TCP connection
>>> queue is full. So stuff like window scaling should work fine in normal
>>> situations.
>>>
>>> Speaking of which:
>>> When the half-open TCP connection queue is full and syn cookies are
>>> enabled, you get a message like "kernel: possible SYN flooding on port
>>> 2710. Sending cookies."
>>> However when syn cookies are disabled, you don't get any message (in
>>> kern.log), although connections to your server are timing out.
>>> Could such a message be added?
>>> Maybe with a suggestion to increase the size of that queue or to
>>> enable syn cookies.
>>>
>>> Greetings,
>>>
>>> Olaf
>>>
>>> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=520668
>>> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=520667
>>> https://bugs.launchpad.net/ubuntu/+bug/57091
>>>
>> Somebody?
> 
> Anybody?

This is a user selectable setting. What's wrong with /etc/sysctl.conf ?

Re: Enable syn cookies by default

[Olaf van der Spek]

On Wed, Oct 21, 2009 at 9:25 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Olaf van der Spek a écrit :
>> On Thu, Oct 15, 2009 at 10:59 AM, Olaf van der Spek
>> <olafvdspek@gmail.com> wrote:
>>> On Sat, Oct 10, 2009 at 3:01 PM, Olaf van der Spek <olafvdspek@gmail.com> wrote:
>>>> Hi,
>>>>
>>>> I'm forwarding Debian feature request #520668.
>>>>
>>>> Could syn cookies be enabled by default?
>>>>
>>>> AFAIK syn cookies only get send when the half-open TCP connection
>>>> queue is full. So stuff like window scaling should work fine in normal
>>>> situations.
>>>>
>>>> Speaking of which:
>>>> When the half-open TCP connection queue is full and syn cookies are
>>>> enabled, you get a message like "kernel: possible SYN flooding on port
>>>> 2710. Sending cookies."
>>>> However when syn cookies are disabled, you don't get any message (in
>>>> kern.log), although connections to your server are timing out.
>>>> Could such a message be added?
>>>> Maybe with a suggestion to increase the size of that queue or to
>>>> enable syn cookies.
>>>>
>>>> Greetings,
>>>>
>>>> Olaf
>>>>
>>>> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=520668
>>>> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=520667
>>>> https://bugs.launchpad.net/ubuntu/+bug/57091
>>>>
>>> Somebody?
>>
>> Anybody?
>
> This is a user selectable setting. What's wrong with /etc/sysctl.conf ?

It requires user action...
Often you notice cookies are disabled only after a service becomes unreachable.
What's wrong with improving defaults?
Don't forget the missing log entries.

Olaf

Re: Enable syn cookies by default

[William Allen Simpson]

Olaf van der Spek wrote:
> On Wed, Oct 21, 2009 at 9:25 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
>> This is a user selectable setting. What's wrong with /etc/sysctl.conf ?
> 
> It requires user action...
> Often you notice cookies are disabled only after a service becomes unreachable.
> What's wrong with improving defaults?

I've not been a regular contributor here, so I'm not sure that my view has
much weight, but I'm *against* changing the coded default.

Keep in mind that I'm busy trying to replace syncookies with real cookies,
so I'm biased.  The syncookies interfere with new options; although in
Linux, they interfere less than other systems.

For Ubuntu, the practice is complicated.  In /etc/sysctl.conf, the text
assumes that the default is off:

# Uncomment the next line to enable TCP/IP SYN cookies
# This disables TCP Window Scaling (http://lkml.org/lkml/2008/2/5/167),
# and is not recommended.
#net.ipv4.tcp_syncookies=1

But in the default installed /etc/sysctl.d/10-network-security.conf, it
is explicitly on in any case:

# Turn on SYN-flood protections.  Starting with 2.6.26, there is no loss
# of TCP functionality/features under normal conditions.  When flood
# protections kick in under high unanswered-SYN load, the system
# should remain more stable, with a trade off of some loss of TCP
# functionality/features (e.g. TCP Window scaling).
net.ipv4.tcp_syncookies=1

As Ubuntu is debian based, perhaps they can back-port the Ubuntu changes?


> Don't forget the missing log entries.
> 
On this I agree.  I'd like the system to syslog it's under attack,
especially whenever syncookies are off.

Re: Enable syn cookies by default

[Olaf van der Spek]

On Wed, Oct 21, 2009 at 11:16 AM, William Allen Simpson
<william.allen.simpson@gmail.com> wrote:
> Keep in mind that I'm busy trying to replace syncookies with real cookies,
> so I'm biased.  The syncookies interfere with new options; although in
> Linux, they interfere less than other systems.

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.
So I really don't see the disadvantage of enabling cookies by default.

> 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).

Olaf

Re: Enable syn cookies by default

[William Allen Simpson]

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.

Re: Enable syn cookies by default

[Olaf van der Spek]

On Wed, Oct 21, 2009 at 8:36 PM, William Allen Simpson
<william.allen.simpson@gmail.com> wrote:
> 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"....

No, I didn't.

>> 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.

How's that? Are you saying no connection is better than a connection
with timestamps and SACK?
I don't believe you.

Wasn't there recently a patch to enable these things even when syn
cookies are actually being used?

> A better solution is usually a firewall/IDS.

Why's that?

> The best solution: I'm working on it.

Hmm, got any link to those cookies? I can only find docs on SYN cookies.

> As I'm sure you're aware, Timestamps and Sack options are fairly crucial.

Of course. I'm not saying you should disable them.

>
>>> 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!

Why?

> 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.

I'm not aware of any differences.

> 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.

Olaf

Re: Enable syn cookies by default

[David Miller]

From: Olaf van der Spek <olafvdspek@gmail.com>
Date: Wed, 21 Oct 2009 09:17:53 +0200

> Anybody?

Would please you be patient?

In case you haven't fucking noticed, all of the major kernel
developers are in Japan at the annual kernel summit and the Japan
Linux Symposium since late last week.

So nobody has the time to look into anything requiring real
long thinking like this issue does.

Re: Enable syn cookies by default

[William Allen Simpson]

David Miller wrote:
> Would please you be patient?
> 
> In case you haven't fucking noticed, all of the major kernel
> developers are in Japan at the annual kernel summit and the Japan
> Linux Symposium since late last week.
> 
Wow, that's way over the top!  I'd noticed your recent rudeness to many
folks in my perusal of this list, and carelessness about reading their
documentation (such as confusing "interdependent" with independent), but
I'd ascribed that to the Peter Principle and overwork....

This behavior is inexcusable.  Please apologize or resign.


> So nobody has the time to look into anything requiring real
> long thinking like this issue does.
> 
Thanks for the information.  Too bad it conflicts with the NANOG and ARIN
conferences hosted here in Michigan this week.

Re: Enable syn cookies by default

[Olaf van der Spek]

On Wed, Oct 21, 2009 at 2:04 PM, David Miller <davem@davemloft.net> wrote:
>> Anybody?
>
> Would please you be patient?
>
> In case you haven't fucking noticed, all of the major kernel
> developers are in Japan at the annual kernel summit and the Japan
> Linux Symposium since late last week.
>
> So nobody has the time to look into anything requiring real
> long thinking like this issue does.

Hi David,

Have you had a chance to do some real long thinking? ;)

Greetings,

Olaf