[Bug 1077] New: New traffic reduces conntrack timeout

[bugzilla-daemon at netfilter.org]

https://bugzilla.netfilter.org/show_bug.cgi?id=1077

            Bug ID: 1077
           Summary: New traffic reduces conntrack timeout
           Product: netfilter/iptables
           Version: unspecified
          Hardware: All
                OS: All
            Status: NEW
          Severity: normal
          Priority: P5
         Component: nf_conntrack
          Assignee: netfilter-buglog at lists.netfilter.org
          Reporter: zrm at trustiosity.com

The code intended to extend the conntrack timeout in the event of new traffic
doesn't check the existing timeout, so if the existing timeout was already
longer than the default, the timeout is reduced.

Example scenario: Default UDP timeout is three minutes (after SEEN_REPLY). The
timeout for one specific entry is extended to five hours using the conntrack
command or API. Three seconds later new traffic is seen for that entry and the
kernel resets the timeout from 04:59:57 to 00:03:00.

(Actual use case: Implementing RFC6887 PEER command so that e.g. UDP VPN can
reduce keepalives by explicitly requesting a long-lived entry.)

Might only need to check (and then keep the existing value) if existing timeout
is longer than new value in "int [proto]_packet()" in
net/netfilter/nf_conntrack_proto_[proto].c for each protocol.

Alternatively might be easier to do the check in __nf_ct_refresh_acct() in
net/netfilter/nf_conntrack_core.c. But notice that "if (newtime -
ct->timeout.expires >= HZ)" there has an integer underflow when newtime is
smaller than ct->timeout.expires, and some things are currently relying on it,
e.g. in tcp_packet() when a TCP connection coming out of ESTABLISHED has its
timeout reduced.

-- 
You are receiving this mail because:
You are watching all bug changes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.netfilter.org/pipermail/netfilter-buglog/attachments/20160628/25c2bdc4/attachment.html>