netdev - Re: [PATCH RFC net-next 0/7] net/ipv6: Add support for path selection using hash of 5-tuple

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: <CAJ3xEMhfj87LDtA57m_34awHojKqUzdeL9dTUNwUcjymfzHEWQ@mail.gmail.com>
Date:   Tue, 13 Feb 2018 15:16:18 +0200
From:   Or Gerlitz <gerlitz.or@...il.com>
To:     Ido Schimmel <idosch@...sch.org>
Cc:     David Ahern <dsahern@...il.com>,
        Linux Netdev List <netdev@...r.kernel.org>,
        Roopa Prabhu <roopa@...ulusnetworks.com>,
        Nikolay Aleksandrov <nikolay@...ulusnetworks.com>,
        Ido Schimmel <idosch@...lanox.com>,
        Tom Herbert <tom@...bertland.com>
Subject: Re: [PATCH RFC net-next 0/7] net/ipv6: Add support for path selection
 using hash of 5-tuple

On Tue, Feb 13, 2018 at 2:42 PM, Ido Schimmel <idosch@...sch.org> wrote:
> On Tue, Feb 13, 2018 at 01:03:14PM +0200, Or Gerlitz wrote:
>> On Tue, Feb 13, 2018 at 2:05 AM, David Ahern <dsahern@...il.com> wrote:
>> > Hardware supports multipath selection using the standard L4 5-tuple
>> > instead of just L3 and the flow label. In addition, some network
>> > operators prefer IPv6 path selection to use the 5-tuple.
>>
>> The HW supports using flow label and AFAIK that is the preferred approach
>> by the community (?)
>>
>> > To that end, add support to IPv6 for multipath hash policy
>>
>> so a question comes up if/what are the disadvantaged
>> to support 5-tuple. E.g Tom was commenting that such DPI is problematic
>> when multiple IPv6 header extensions are used.
>
> Tom is much more qualified to answer this, but I think the problem is
> that the flow label isn't always set. Also, apparently some devices
> change the flow label mid flow. See:

OK. But note we have two ends to deal with here (1) generation (2) usage

E.g if the kernel generates flow label but uses source port we have inconsistent
environment. Problem is that the generation and usage typically don't happen
on the same network point.