netdev - Re: [PATCH net-next V2 1/2] net-next: use five-tuple hash for sk

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: <CALx6S349o0kOSV3TrjNRSUYUJ6GVENN_tVAk25zENekP=_X-7Q@mail.gmail.com>
Date:   Sun, 3 Dec 2017 08:02:21 -0800
From:   Tom Herbert <tom@...bertland.com>
To:     David Miller <davem@...emloft.net>
Cc:     Shaohua Li <shli@...nel.org>,
        Linux Kernel Network Developers <netdev@...r.kernel.org>,
        Martin Lau <kafai@...com>,
        Eric Dumazet <eric.dumazet@...il.com>, flo@...rcot.fr,
        Cong Wang <xiyou.wangcong@...il.com>, Shaohua Li <shli@...com>
Subject: Re: [PATCH net-next V2 1/2] net-next: use five-tuple hash for sk_txhash

On Sun, Dec 3, 2017 at 7:38 AM, David Miller <davem@...emloft.net> wrote:
> From: Shaohua Li <shli@...nel.org>
> Date: Fri,  1 Dec 2017 13:00:43 -0800
>
>> This causes our router doesn't correctly close tcp connection.
>
> Then please fix your router.
>
> How many times do I have to say this...  The flowlabel is not part of
> the socket connection identity, therefore you cannot use it for
> connection state.
>
> The more of these kinds of patches with this kind of nonsense in the
> commit message I let into the tree the more this illusion of the
> flowlabel meaning something on the connection level is made to seem
> like reality.
>
> Can we please stop pretending that the flowlabel is part of the
> saddr/sport/daddr/dport socket identity?  Please???
>
> I don't mind the flowlabel being set correctly, but your justification
> stinks.

Dave,

The problem isn't us, it's the rest of the world. There are countless
network devices that maintain connection state (load balancers,
firewalls, NAT, etc.). They force a requirement that all packets for a
flow follow the same path route through their device. This is
fundamentally incorrect per the architecture of Internet protocols,
but nevertheless it is pervasive and not going away anytime soon. If
the flow label is not persistent during a flow and used for ECMP then
flows through these devices can be broken. This is precisely why there
are some network operators running around now telling people to turn
off the flow label for ECMP (and continue doing DPI). We're not going
to win the argument that they need to fix their architecture, making
flow labels persistent as a default is a pragmatic solution.

Tom