netdev - Re: [PATCH net-next 6/7] openvswitch: Add force commit.

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: <CAOrHB_CLwEno6_0WHMwEPx6apwg85WyCCYR4E-tOPKp5L1FSnw@mail.gmail.com>
Date:   Tue, 7 Feb 2017 09:14:34 -0800
From:   Pravin Shelar <pshelar@....org>
To:     Joe Stringer <joe@....org>
Cc:     Jarno Rajahalme <jarno@....org>,
        Linux Kernel Network Developers <netdev@...r.kernel.org>
Subject: Re: [PATCH net-next 6/7] openvswitch: Add force commit.

On Mon, Feb 6, 2017 at 11:28 PM, Joe Stringer <joe@....org> wrote:
> On 6 February 2017 at 09:08, Pravin Shelar <pshelar@....org> wrote:
>> On Thu, Feb 2, 2017 at 5:10 PM, Jarno Rajahalme <jarno@....org> wrote:
>>> Stateful network admission policy may allow connections to one
>>> direction and reject connections initiated in the other direction.
>>> After policy change it is possible that for a new connection an
>>> overlapping conntrack entry already exist, where the connection
>>> original direction is opposed to the new connection's initial packet.
>>>
>>> Most importantly, conntrack state relating to the current packet gets
>>> the "reply" designation based on whether the original direction tuple
>>> or the reply direction tuple matched.  If this "directionality" is
>>> wrong w.r.t. to the stateful network admission policy it may happen
>>> that packets in neither direction are correctly admitted.
>>>
>> Why not have the check in all commit actions? I am not sure in which
>> case user would not want forced commit considering this can cause
>> packet admission issue?
>
> Seems like this case has involved one direction of a connection being
> handled by a flow that committed the connection. Then something has
> changed and you end up with a flow handling the opposite direction,
> committing the connection. What if the first flow wasn't actually
> removed? Plausibly you could end up with constant ct entry churn as
> the connection is recreated each time there is a packet from an
> alternating direction. Having a separate flag may assist with respect
> to shooting one's own foot..

I see. Thanks for explanation.