On Sat, Aug 18, 2018 at 11:56 AM Tom Herbert <t...@herbertland.com> wrote:
>
> On Thu, Aug 16, 2018 at 9:44 AM, Petar Penkov <peterpenko...@gmail.com> wrote:
> > From: Petar Penkov <ppen...@google.com>
> >
> > This eBPF program extracts basic/control/ip address/ports keys from
> > incoming packets. It supports recursive parsing for IP
> > encapsulation, MPLS, GUE, and VLAN, along with IPv4/IPv6 and extension
> > headers. This program is meant to show how flow dissection and key
> > extraction can be done in eBPF.
> >
> > It is initially meant to be used for demonstration rather than as a
> > complete replacement of the existing flow dissector.
> >
> > This includes parsing of GUE and MPLS payload, which cannot be done
> > in production in general, as GUE tunnels and MPLS payloads cannot
> > unambiguously be detected in general.
> >
> > In closed environments, however, it can be enabled. Another example
> > where the programmability of BPF aids flow dissection.
> > +static __always_inline int write_ports(struct __sk_buff *skb, __u8 proto)
> > +{
> > + struct bpf_dissect_cb *cb = (struct bpf_dissect_cb *)(skb->cb);
> > + struct flow_dissector_key_ports ports;
> > +
> > + /* The supported protocols always start with the ports */
> > + if (bpf_skb_load_bytes(skb, cb->nhoff, &ports, sizeof(ports)))
> > + return BPF_DROP;
> > +
> > + if (proto == IPPROTO_UDP && ports.dst == bpf_htons(GUE_PORT)) {
> > + /* GUE encapsulation */
> > + cb->nhoff += sizeof(struct udphdr);
> > + bpf_tail_call(skb, &jmp_table, GUE);
> > + return BPF_DROP;
>
> It's a nice sentiment to support GUE, but this really isn't the right
> way to do it.
Yes, this was just for demonstration purposes. The same for
unconditionally parsing MPLS payload as IP.
Though note the point in the commit message that within a closed
network with fixed reserved GUE ports, a custom BPF program
like this could be sufficient. That's true not only for UDP tunnels.
> What would be much better is a means to generically
> support all the various UDP encapsulations like GUE, VXLAN, Geneve,
> GRE/UDP, MPLS/UDP, etc. I think there's two ways to do that:
>
> 1) A UDP socket lookup that returns an encapsulation socket containing
> a flow dissector function that can be called. This is the safest
> method because of the UDP are reserved numbers problem. I implement
> this in kernel flow dissector, not upstreamed though.
Yes, similar to udp_gro_receive. Socket lookup is not free, however,
and this is a relatively rarely used feature.
I want to move the one in udp_gro_receive behind a static key.
udp_encap_needed_key is the likely target. Then the same can
eventually be done for flow dissection inside UDP tunnels.
> 2) Create a lookup table based on destination port that returns the
> flow dissector function to call. This doesn't have the socket lookup
> so it isn't quite as robust as the socket lookup. But, at least it's a
> generic interface and programmable so it might be appropriate in the
> BPF flow dissector case.
Option 1 sounds preferable to me.
