netdev - Re: [oss-drivers] Re: [PATCH/RFC net-next 1/2] flow dissector: ND support

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]

Date:   Wed, 8 Feb 2017 11:10:06 -0800
From:   Tom Herbert <tom@...bertland.com>
To:     David Miller <davem@...emloft.net>
Cc:     Simon Horman <simon.horman@...ronome.com>,
        Jiří Pírko <jiri@...nulli.us>,
        Eric Dumazet <eric.dumazet@...il.com>,
        Dinan Gunawardena <dinan.gunawardena@...ronome.com>,
        Linux Kernel Network Developers <netdev@...r.kernel.org>,
        oss-drivers@...ronome.com
Subject: Re: [oss-drivers] Re: [PATCH/RFC net-next 1/2] flow dissector: ND support

On Wed, Feb 8, 2017 at 10:54 AM, David Miller <davem@...emloft.net> wrote:
> From: Tom Herbert <tom@...bertland.com>
> Date: Wed, 8 Feb 2017 10:33:46 -0800
>
>> On Wed, Feb 8, 2017 at 1:28 AM, Simon Horman <simon.horman@...ronome.com> wrote:
>>> I think the above paragraph gets back to Tom's original question regarding
>>> making things more complex just for OvS (use-cases). Possibly ND is an edge
>>> case even for OvS and on reflection my timing for posting it seems to have
>>> been less than ideal.
>>
>> If it wasn't ND it would be something else... with all the activity
>> happening in networking features and HW this is a timely discussion.
>> Flow dissector presents a good example of a function that might become
>> a dumping ground for an endless stream of features if we don't figure
>> out how exercise some restraint.
>
> I agree on most points.
>
> But, I would say that in this specific case, since we have ARP support in
> there already it behooves us to support the ipv6 side in the form of ND
> too.
>
> Then we can put a line in the sand and say that future feature additions
> in this area require serious discussion.
>
> Ok Tom?

Right, ND is okay on the basis that we already have ARP (although I
still may grumble from time to time that ARP, ND, and ICMP are being
identified as flows ;-) ).

I think there are two projects in the are that someone, maybe an
aspiring kernel network developer, might want to look into if they
have the time:

- Inevitably someone will want to support VXLAN or other UDP
encapsulations in flow dissector. The only correct way to do this is
going to be to do a lookup on UDP socket and have a flow_dissector
function related to the socket. This is the model for dealing with UDP
encapsulations in GRO that could be extended for flow dissection. We
cannot hard code port numbers in flow_dissector. The interesting part
here will be making a robust interface to avoid the pitfalls we've
seen in some of the protocols in flow_dissector.

- Allow calling a BPF function to do custom flow dissection. IIRC
there someone (Daniel?) had already implement flow_dissector in BPF
with pretty good results.

Tom