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]

Date:   Tue, 15 Jan 2019 11:06:20 -0500
From:   Willem de Bruijn <willemdebruijn.kernel@...il.com>
To:     Martijn van Oosterhout <kleptog@...na.org>
Cc:     Network Development <netdev@...r.kernel.org>
Subject: Re: AF_PACKET fanout not working on MPLS traffic

On Tue, Jan 15, 2019 at 3:22 AM Martijn van Oosterhout
<kleptog@...na.org> wrote:
>
> 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).

That's a good point, and I guess another reason to not enable this by default.

> > > 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?

It should be. It only became available in the most recent stable
kernel (4.20), so there may be some kinks to iron out.

> 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?

Yep, pretty much :) Besides the LWN article, the commits themselves
may also be informative. Specifically the one that introduced the
selftests: commit 50b3ed57dee9 ("selftests/bpf: test bpf flow
dissection").

> [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.