netdev - Re: [PATCH netfilter] netfilter: conntrack: udp: generate event on switch to stream timeout

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <YWyd44P+ey9VXvRn@salvia>
Date:   Mon, 18 Oct 2021 00:04:19 +0200
From:   Pablo Neira Ayuso <pablo@...filter.org>
To:     Maciej Żenczykowski <zenczykowski@...il.com>
Cc:     Florian Westphal <fw@...len.de>,
        Linux Network Development Mailing List 
        <netdev@...r.kernel.org>,
        Netfilter Development Mailing List 
        <netfilter-devel@...r.kernel.org>
Subject: Re: [PATCH netfilter] netfilter: conntrack: udp: generate event on
 switch to stream timeout

On Fri, Oct 15, 2021 at 03:15:07AM -0700, Maciej Żenczykowski wrote:
> On Fri, Oct 15, 2021 at 2:57 AM Florian Westphal <fw@...len.de> wrote:
> > Maciej Żenczykowski <zenczykowski@...il.com> wrote:
[...]
> A udp flow becoming bidirectional seems like an important event to
> notify about...
> Afterall, the UDP flow might become a stream 29 seconds after it
> becomes bidirectional...
> That seems like a pretty long time (and it's user configurable to be
> even longer) to delay the notification.
> 
> I imagine the pair of you know best whether 2 events or delay assured
> event until stream timeout is applied makes more sense...

This 2 events looks awkward to me, currently the model we have to
report events is:

- status bits are updated
- flow has changed protocol state (TCP).

but in this case, this is reporting a timer update. Timeout updates
are not reported on events, since this would trigger too many events
one per packet.

What's the concern with delaying the IPS_ASSURED bit?

By setting a lower timeout (30 second) my understanding is that this
flow is less important to those that are in the stream state (120s),
so these should also be candidate to be removed by early_drop. IIRC,
the idea behind the stream concept is to reduce lifetime of shortlived
UDP flows to release slots from the conntrack table earlier.