All of lore.kernel.org
 help / color / mirror / Atom feed
From: Roberto Nibali <ratz@tac.ch>
To: Willy Tarreau <willy@w.ods.org>
Cc: netfilter-devel@lists.netfilter.org
Subject: Re: [PATCH 2.4] TCP window tracking: core implementation
Date: Wed, 23 Nov 2005 13:55:32 +0100	[thread overview]
Message-ID: <438466C4.5040701@tac.ch> (raw)
In-Reply-To: <20051122165631.GA13716@alpha.home.local>

Salut Willy,

>>A former version of this patch has been in production on a dozen nodes
>>for about 8 months now, and besides unmotivated DROPs invoked by
>>"non-RFC-comformant" applications, it works reasonably well.
>  
> Seconded !
> I've had it in production for 18 months now, handling between 1.2 and 1.8
> billions of sessions a month, and it still works like a charm.

Could you batch my patchset for your next -hf series, please? I'll try
to get you a tcpdump with erroneous behaviour regarding window tracking,
so you can verify this as well.

>>We'd hoped to overcome remaining "broken" applications by using the
>>NOTRACK flag to a filter rule. This would allow one to have a general
>>stateful packet filter with a few stateless rules for "broken"
>>applications; a feature most commercial firewall suites don't offer.
>>Unfortunately there is still an issue with regard to SMP and rmmod'ing
>>ip_conntrack while having NOTRACK rules loaded and network traffic
>>hitting NOTRACK and conntrack. Otherwise it works flawlessly. Patch will
>>follow shortly.
> 
> another possibility would be to add something like a "reason" code to the
> INVALID state, so that we could tell which types of invalids we still want
> to let go and which ones we definitely want to block.

This is of course possible but could potentially lead to a lot of
exception code. I reckon that it's safe enough to fallback to classic
packet filtering when dealing with non-RFC conform TCP clients or
applications. Meanwhile I've found the problem with the NOTRACK hanging
and will propose a fix in another thread I've started.

Best regards,
Roberto Nibali, ratz
-- 
-------------------------------------------------------------
addr://Kasinostrasse 30, CH-5001 Aarau tel://++41 62 823 9355
http://www.terreactive.com             fax://++41 62 823 9356
-------------------------------------------------------------
terreActive AG                       Wir sichern Ihren Erfolg
-------------------------------------------------------------

  reply	other threads:[~2005-11-23 12:55 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-11-21 10:16 {Spam?} [PATCH 2.4] TCP window tracking: core implementation Roberto Nibali
2005-11-22 16:56 ` Willy Tarreau
2005-11-23 12:55   ` Roberto Nibali [this message]
2005-11-23 13:14     ` Jozsef Kadlecsik
2005-11-23 21:54     ` Willy Tarreau
2005-11-23 22:32       ` Roberto Nibali
2005-11-23 23:27         ` Willy Tarreau

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=438466C4.5040701@tac.ch \
    --to=ratz@tac.ch \
    --cc=netfilter-devel@lists.netfilter.org \
    --cc=willy@w.ods.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.