I've posted a series of patches that I believe address Andi's concerns
about syncookies not supporting valuable tcp options (primarily SACK,
and window scaling). The premise being if the client support tcp
timestamps we can encode the additional tcp options in the initial
timestamp we send back
On Fri, Feb 08, 2008 at 01:07:46PM +0100, Andi Kleen wrote:
On Thu, Feb 07, 2008 at 02:44:46PM -0500, Ross Vandegrift wrote:
On Wed, Feb 06, 2008 at 09:53:57AM +0100, Andi Kleen wrote:
My initial test is end-to-end 1000Mbps, but I've got a few different
packet rates.
If the young/old
In article [EMAIL PROTECTED] (at Thu, 07 Feb 2008 10:40:19 +0100), Eric
Dumazet [EMAIL PROTECTED] says:
[NET] IPV4: lower stack usage in cookie_hash() function
400 bytes allocated on stack might be a litle bit too much. Using a
per_cpu var is more friendly.
Signed-off-by: Eric Dumazet
In article [EMAIL PROTECTED] (at Thu, 7 Feb 2008 21:49:26 -0800), Glenn
Griffin [EMAIL PROTECTED] says:
Updated to incorporate Eric's suggestion of using a per cpu buffer
rather than allocating on the stack. Just a two line change, but will
resend in it's entirety.
Signed-off-by: Glenn
On Thu, Feb 07, 2008 at 02:44:46PM -0500, Ross Vandegrift wrote:
On Wed, Feb 06, 2008 at 09:53:57AM +0100, Andi Kleen wrote:
That would be useful yes -- for different bandwidths.
My initial test is end-to-end 1000Mbps, but I've got a few different
packet rates.
If the young/old
Evgeniy Polyakov a écrit :
On Wed, Feb 06, 2008 at 10:30:24AM -0800, Glenn Griffin ([EMAIL PROTECTED])
wrote:
+static u32 cookie_hash(struct in6_addr *saddr, struct in6_addr *daddr,
+ __be16 sport, __be16 dport, u32 count, int c)
+{
+ __u32 tmp[16 + 5 +
On Wed, Feb 06, 2008 at 09:53:57AM +0100, Andi Kleen wrote:
That would be useful yes -- for different bandwidths.
My initial test is end-to-end 1000Mbps, but I've got a few different
packet rates.
If the young/old heuristics do not work well enough anymore most
likely we should try readding
Or maybe use percpu storage for that...
That seems like a good approach. I'll incorporate it into my v6 patch,
and send out an update. Thanks.
I am not sure if cookie_hash() is always called with preemption disabled.
(If not, we have to use get_cpu_var()/put_cpu_var())
cookie_hash is
Updated to incorporate Eric's suggestion of using a per cpu buffer
rather than allocating on the stack. Just a two line change, but will
resend in it's entirety.
Signed-off-by: Glenn Griffin [EMAIL PROTECTED]
---
include/net/tcp.h|8 ++
net/ipv4/syncookies.c|7 +-
I work at a hosting company and we see these kinds of issues in the
real world fairly frequently. I would guess maybe a monthly basis.
The servers where we have seen this are typically running RHEL 4 or 5
kernels, so I can't really speak to how recent the kernel is in this
specific term.
On Tue, Feb 05, 2008 at 05:52:31PM -0800, Glenn Griffin ([EMAIL PROTECTED])
wrote:
+static u32 cookie_hash(struct in6_addr *saddr, struct in6_addr *daddr,
+__be16 sport, __be16 dport, u32 count, int c)
+{
+ __u32 tmp[16 + 5 + SHA_WORKSPACE_WORDS];
This huge buffer
I didn't think a module could have multiple module_inits. Are you
sure that works?
Indeed. That will fail whenever ipv6 is compiled as a module. It's
been removed. It snuck in from the v4 implementation, where I'm still
having trouble understanding why it's needed there.
--Glenn
--
To
+static u32 cookie_hash(struct in6_addr *saddr, struct in6_addr *daddr,
+ __be16 sport, __be16 dport, u32 count, int c)
+{
+ __u32 tmp[16 + 5 + SHA_WORKSPACE_WORDS];
This huge buffer should not be allocated on stack.
I can replace it will a kmalloc, but for my
Okay. Round3. Took into account that it was horribly broken when ipv6
was compiled as a module. The fixes export a few more symbols, and now
the syncookie_secret is shared between the v4 and v6 code. That should
be fine as it will be initialized when the v4 code starts, and it's not
currently
On Wed, Feb 06, 2008 at 10:30:24AM -0800, Glenn Griffin ([EMAIL PROTECTED])
wrote:
+static u32 cookie_hash(struct in6_addr *saddr, struct in6_addr *daddr,
+__be16 sport, __be16 dport, u32 count, int c)
+{
+ __u32 tmp[16 + 5 + SHA_WORKSPACE_WORDS];
This huge buffer
On Mon, Feb 04, 2008 at 03:01:01PM -0800, Glenn Griffin wrote:
Add IPv6 support to TCP SYN cookies. This is written and tested against
2.6.24, and applies cleanly to linus' current HEAD (d2fc0b). Unfortunately
linus' HEAD breaks my sky2 card at the moment, so I'm unable to test against
that.
On Tue, Feb 05, 2008 at 03:42:13PM +, Alan Cox wrote:
Syncookies are discouraged these days. They disable too many
valuable TCP features (window scaling, SACK) and even without them
the kernel is usually strong enough to defend against syn floods
and systems have much more memory
Also your sub PC class appliances rarely run LISTEN servers anyways
that are open to the world.
Really. The ones that first come to mind often have exposed ports
including PDA devices and phones. (Ditto low end PC boxes - portscan an
EEPC some day ;))
Is the other stuff enough - good question,
On Tue, Feb 05, 2008 at 04:03:01PM +, Alan Cox wrote:
Also your sub PC class appliances rarely run LISTEN servers anyways
that are open to the world.
Really. The ones that first come to mind often have exposed ports
including PDA devices and phones. (Ditto low end PC boxes - portscan
Syncookies are discouraged these days. They disable too many
valuable TCP features (window scaling, SACK) and even without them
the kernel is usually strong enough to defend against syn floods
and systems have much more memory than they used to be.
Somewhat untrue. Network speeds have risen
What kind of LISTEN ports? And does it matter if they're DoS'ed?
I guess that depends on the opinion of the owner
- Push based mobile services
- Email delivery
- VoIP
- Management ports
- Peer to peer data transfer
- Instant messaging direct user/user connections
Some of that can also be
Syncookies are discouraged these days. They disable too many
valuable TCP features (window scaling, SACK) and even without them
the kernel is usually strong enough to defend against syn floods
and systems have much more memory than they used to be.
So I don't think it makes much sense to add
On Tue, Feb 05, 2008 at 10:29:28AM -0800, Glenn Griffin wrote:
Syncookies are discouraged these days. They disable too many
valuable TCP features (window scaling, SACK) and even without them
the kernel is usually strong enough to defend against syn floods
and systems have much more memory
The problem is that any reasonably recent PC can generate enough
forged SYN packets to overwhelm reasonable SYN queues on a much more
powerful server.
Have you actually seen this with a recent kernel in the wild or are
you just talking theoretically?
Linux uses some heuristics to manage the
On Tue, Feb 05, 2008 at 10:29:28AM -0800, Glenn Griffin wrote:
Syncookies are discouraged these days. They disable too many
valuable TCP features (window scaling, SACK) and even without them
the kernel is usually strong enough to defend against syn floods
and systems have much more memory
On Feb 5 2008 16:55, Andi Kleen wrote:
On Mon, Feb 04, 2008 at 03:01:01PM -0800, Glenn Griffin wrote:
Add IPv6 support to TCP SYN cookies. This is written and tested against
2.6.24, and applies cleanly to linus' current HEAD (d2fc0b). Unfortunately
linus' HEAD breaks my sky2 card at the
On Tue, Feb 05, 2008 at 09:02:11PM +0100, Andi Kleen ([EMAIL PROTECTED]) wrote:
On Tue, Feb 05, 2008 at 10:29:28AM -0800, Glenn Griffin wrote:
Syncookies are discouraged these days. They disable too many
valuable TCP features (window scaling, SACK) and even without them
the kernel is
On Tue, Feb 05, 2008 at 11:39:11PM +0300, Evgeniy Polyakov wrote:
On Tue, Feb 05, 2008 at 09:02:11PM +0100, Andi Kleen ([EMAIL PROTECTED])
wrote:
On Tue, Feb 05, 2008 at 10:29:28AM -0800, Glenn Griffin wrote:
Syncookies are discouraged these days. They disable too many
valuable TCP
On Tue, Feb 05, 2008 at 09:11:06PM +0100, Andi Kleen wrote:
The problem is that any reasonably recent PC can generate enough
forged SYN packets to overwhelm reasonable SYN queues on a much more
powerful server.
Have you actually seen this with a recent kernel in the wild or are
you just
How does syncookies prevent windows from growing?
Enabling them doesn't.
Most (if not all) distributions have them enabled and window growing
works just fine. Actually I do not see any reason why connection
establishment handshake should prevent any run-time operations at all,
even if it
So I don't think it makes much sense to add more code to it, sorry.
Distributions should then probably deactivate it by default.
SUSE 10.3 for example still has it enabled on default installs.
Even though I work the loyal opposition to SuSE I'd say SuSE 10.3 is
correct in having it enabled
Hi Andi, Alan,
I've run extensive tests with/without syn cookies recently.
On Tue, Feb 05, 2008 at 05:39:12PM +0100, Andi Kleen wrote:
On Tue, Feb 05, 2008 at 03:42:13PM +, Alan Cox wrote:
Syncookies are discouraged these days. They disable too many
valuable TCP features (window
On Tue, Feb 05, 2008 at 09:53:45PM +0100, Andi Kleen ([EMAIL PROTECTED]) wrote:
How does syncookies prevent windows from growing?
Syncookies do not allow window scaling so you can't have any windows 64k
Then you meant not windows change, but the fact, that option is ignored
as long as sack
Hi Alan.
On Tue, Feb 05, 2008 at 09:20:17PM +, Alan Cox ([EMAIL PROTECTED]) wrote:
Most (if not all) distributions have them enabled and window growing
works just fine. Actually I do not see any reason why connection
establishment handshake should prevent any run-time operations at all,
On Wed, Feb 06, 2008 at 12:52:17AM +0300, Evgeniy Polyakov wrote:
Hi Alan.
On Tue, Feb 05, 2008 at 09:20:17PM +, Alan Cox ([EMAIL PROTECTED]) wrote:
Most (if not all) distributions have them enabled and window growing
works just fine. Actually I do not see any reason why connection
SACK is actually a good idea for mobile devices, so preventing
syncookies from not getting into account some options (btw, does it work
with timestamps and PAWS?) is not a solution.
Syncookies only get used at the point where the alternative is failure.
No SACK beats a DoS situation most days
Here is a reworked implementation that restricts the code to the ipv6 module as
Andi suggested. Uses the same CONFIG and sysctl variables as the ipv4
implementation.
Signed-off-by: Glenn Griffin [EMAIL PROTECTED]
---
include/net/tcp.h |6 +
net/ipv6/Makefile |1 +
I realized an earlier email I sent had an incorrect timestamp and wasn't
associated with the thread, so I thought it would be better to resend.
I apologize if this is duplicated for anyone.
Here is a reworked patch that moves the IPv6 syncookie support out of
the ipv4/syncookies.c file and into
+static __init int init_syncookies(void)
+{
+ get_random_bytes(syncookie_secret, sizeof(syncookie_secret));
+ return 0;
+}
+module_init(init_syncookies);
I didn't think a module could have multiple module_inits. Are you
sure that works?
-Andi
--
To unsubscribe from this list: send
Add IPv6 support to TCP SYN cookies. This is written and tested against
2.6.24, and applies cleanly to linus' current HEAD (d2fc0b). Unfortunately
linus' HEAD breaks my sky2 card at the moment, so I'm unable to test against
that. I see no reason why it would be affected though.
40 matches
Mail list logo
