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 to
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
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
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:
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
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 +-
net/ipv4/
> 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 alw
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
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 + SHA_WORKSPA
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];
> >
> > T
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 p
> > +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
On Wed, Feb 06, 2008 at 09:36:11AM -0800, Glenn Griffin wrote:
> > 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 stil
> 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 unsu
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 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.
> +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:
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 it
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 +
net/ipv6/sync
> 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 day
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 conn
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
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 sa
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 (windo
> >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 enabl
> 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 i
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
> y
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
> > > > valu
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 kern
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 th
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
> 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
> 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 t
> 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 harde
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 - port
> 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 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 mem
> 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 ri
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
> th
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. Comments/suggest
41 matches
Mail list logo
