netdev - Re: AF_PACKET fanout not working on MPLS traffic

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: <20190115082250.GA23010@svana.org>
Date:   Tue, 15 Jan 2019 09:22:50 +0100
From:   Martijn van Oosterhout <kleptog@...na.org>
To:     Willem de Bruijn <willemdebruijn.kernel@...il.com>
Cc:     Network Development <netdev@...r.kernel.org>
Subject: Re: AF_PACKET fanout not working on MPLS traffic

Hoi Willem,

On Mon, Jan 14, 2019 at 03:03:42PM -0500, Willem de Bruijn wrote:
> On Mon, Jan 14, 2019 at 2:12 PM Martijn van Oosterhout wrote:
> > I see a two ways this could be fixed.
> >
> > Option 1: include FLOW_DISSECTOR_KEY_MPLS in
> > flow_keys_dissector_symmetric but that seems a big assumption, we don't
> > do that for VLANs for example.
> 
> This sounds fine to me. Though it will require extra work to make
> __skb_get_has_symmetric actually use the entropy. And in practice it's
> not clear that this will result in much entropy.

Ok, I guess this really depends on the kind of traffic. You'd have to
assume that flows in both directions get the same labels, which may or
may not be true. (The assumption here is that you want flows to stay
together, otherwise you may as well use round-robin).

> > And there is actually another problem: MPLS provides no information
> > about the next header because it assumes the endpoints in the network
> > recognise the MPLS headers. Which means you'd have to make a guess
> > about what the next layer should be.
> 
> This is the real issue. I don't think this can be done in general
> purpose code. The new BPF flow dissector, however, does allow you to
> deploy a custom dissector in environments where the inner protocol is
> known.
> 
>   https://lwn.net/Articles/764200/

Thanks for the reference! Is this code considered mature enough for
production?

Also, since this is new, I can't find much info on how to use it. But
if I understand correctly you create a flow dissector in BPF which
extracts the various parts.  There is one such dissector per namespace,
it replaces the internal one completely.  You attach it using
bpftool[1], which loads the program and confiigures where the BPF
program will store various keys.  We can then make a BPF program which
works for our traffic, load it and then the hashing code from AF_PACKET
will start using it instead of the builtin dissector.

Does that sound right?

[1]: https://patchwork.kernel.org/patch/10673201/

Thanks in advance,
-- 
Martijn van Oosterhout   <kleptog@...na.org>   http://svana.org/kleptog/
> The combine: one man, one day, wheat for half a million loaves of bread.
Download attachment "signature.asc" of type "application/pgp-signature" (812 bytes)