netdev - Re: "Forwarding" from TC classifier

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:   Fri, 15 May 2020 10:59:21 +0100
From:   Lorenz Bauer <lmb@...udflare.com>
To:     David Ahern <dsahern@...il.com>
Cc:     bpf <bpf@...r.kernel.org>, Networking <netdev@...r.kernel.org>,
        Martynas Pumputis <m@...bda.lt>,
        kernel-team <kernel-team@...udflare.com>
Subject: Re: "Forwarding" from TC classifier

On Thu, 14 May 2020 at 19:54, David Ahern <dsahern@...il.com> wrote:
>
> On 5/14/20 9:41 AM, Lorenz Bauer wrote:
> > On Wed, 13 May 2020 at 18:48, David Ahern <dsahern@...il.com> wrote:
> >>
> >> On 5/13/20 10:40 AM, Lorenz Bauer wrote:
> >>> We've recently open sourced a key component of our L4 load balancer:
> >>> cls_redirect [1].
> >>> In the commit description, I call out the following caveat:
> >>>
> >>>     cls_redirect relies on receiving encapsulated packets directly
> >>> from a router. This is
> >>>     because we don't have access to the neighbour tables from BPF, yet.
> >>
> >> Can you explain more about this limitation? Why does access to neighbor
> >> tables solve the problem?
> >
> > We want to forward the packet to another machine, based on an IP address
> > stored in our custom encapsulation header.
> > If we always receive packets from a router we can plug in the new IP, swap
> > the MAC and send the packet back to the router. Inefficient, but it means we
> > don't have to deal with MAC addresses ourselves.
>
> Ok, so swapping source and destination addresses in the IP header, doing
> a fib lookup and redirecting to an interface based on the lookup. That
> does require a neighbor entry for the dest address. Access to the
> neighbor table does not directly solve that problem - if it is not there
> for the fib lookup, it won't be there for the straight neigh lookup.
>
> You could let the first packet go up the stack to create and resolve the
> neighbor entry. At that point follow on packets will take the fast path.

Yes, but that doesn't play well with changing the source address to
the local machine's, since the upper part of the stack will drop the
packet due to accept_local=0.

For this to work I need to set accept_local=1, which isn't desirable,
or redirect into the output queue of the device, which currently doesn't
trigger neighbour lookup, etc.

To sum it up: fib_lookup enables the fast path, but I don't have a way
to trigger the slow path in the way I want to. Maybe I need to dig into
bpf_redirect some more.

>
> Alternatively, you can create static entries in the table for known
> forwarding addresses or have a process on the server initiate neighbor
> resolution for none forwarding addresses.
> >>
> >> Usually, 'output' is for locally generated traffic headed out. XDP
> >> programs run on ingress are from an Rx perspective and do the lookup
> >> from the perspective of 'is this forwarded or locally delivered'.
> >
> > What if the XDP encapsulates the packet? At this point I know that I
> > want to forward it elsewhere. Would that use LOOKUP_OUTPUT?
>
> Yes, if you want the lookup to respond as if it is a locally sent packet
> versus a forwarded packet.



-- 
Lorenz Bauer  |  Systems Engineer
6th Floor, County Hall/The Riverside Building, SE1 7PB, UK

www.cloudflare.com