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] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAHo-OoxsN5d+ipbp0TQ=a+o=ynd3-w5RZ3S3F8Vg89ipT5=UHw@mail.gmail.com>
Date:   Fri, 15 Oct 2021 03:15:07 -0700
From:   Maciej Żenczykowski <zenczykowski@...il.com>
To:     Florian Westphal <fw@...len.de>
Cc:     Pablo Neira Ayuso <pablo@...filter.org>,
        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 2:57 AM Florian Westphal <fw@...len.de> wrote:
>
> Maciej Żenczykowski <zenczykowski@...il.com> wrote:
> > > Hm, I still don't understand why do you need this extra 3rd
> > > update/assured event event. Could you explain your usecase?
> >
> > Currently we populate a flow offload array on the assured event, and
> > thus the flow in both directions starts bypassing the kernel.
> > Hence conntrack timeout is no longer automatically refreshed - and
> > there is no opportunity for the timeout to get bumped to the stream
> > timeout of 120s - it stays at 30s.
> > We periodically (every just over 60-ish seconds) check whether packets
> > on a flow have been offloaded, and if so refresh the conntrack
> > timeout.  This isn't cheap and we don't want to do it even more often.
> > However this 60s cycle > 30s non-stream udp timeout, so the kernel
> > conntrack entry expires (and we must thus clear out the flow from the
> > offload).  This results in a broken udp stream - but only on newer
> > kernels.  Older kernels don't have this '2s' wait feature (which makes
> > a lot of sense btw.) but as a result of this the conntrack assured
> > event happens at the right time - when the timeout hits 120s (or 180s
> > on even older kernels).
> >
> > By generating another assured event when the udp stream is 'confirmed'
> > and the timeout is boosted from 30s to 120s we have an opportunity to
> > ignore the first one (with timeout 30) and only populate the offload
> > on the second one (with timeout 120).
> >
> > I'm not sure if I'm doing a good job of describing this.  Ask again if
> > it's not clear and I'll try again.
>
> Thanks for explaining, no objections to this from my side.
>
> Do you think it makes sense to just delay setting the ASSURED bit
> until after the 2s period?

That would work for this particular use case.... but I don't know if
it's a good idea.
I did of course think of it, but the commit message seemed to imply
there's a good reason to set the assured bit earlier rather than
later...

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...

- Maciej