Re: What should we do with packets marked as INVALID?

[Pablo Neira Ayuso <pablo@netfilter.org>]

Krzysztof Oledzki wrote:
> One of the most important feature provided by the netfilter subsystem is
> stateful connection tracking - the ability to decide that a packet is
> valid (or not) using not only data from a packet itself but also from a
> history of a flaw.
> 
> So, the question is: what should we do with packets marked as INVALID?
> 
> [...]
> 
> So OK, REJECT is wrong (possibly kills valid connections), DROP (makes
> invalid connections hang "forever") is also wrong, so maybe we should
> forward such packets and allow dst hosts to handle it
> (ignore/reset/etc). Bzzzz... no, wait, it is also wrong as we lose one
> of the most important netfilter feature.

IMO, the default action should be drop. Having a look at the errors in
the tcp window tracking code, I can't think about a sane connection that
can generate invalid out of window packets even under packet lost.

> So, I have two propositions:
>  - Add another state (ex. UNCLEAN) for packet that matches
> proto/src/dst/sport/dport, but netfilter consider that it is wrong.

If you let the invalid packet go through just because there is a tuple
in the conntrack table that matches it then, why do you want the whole
TCP window tracking? Just disabled it via ip_conntrack_tcp_be_liberal if
you want to do so, out of window packets will not be marked as invalid,
and you can still drop unclean packets since they are marked as invalid.

-- 
The dawn of the fourth age of Linux firewalling is coming; a time of
great struggle and heroic deeds -- J.Kadlecsik got inspired by J.Morris