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:   Thu, 14 May 2020 12:54:49 -0600
From:   David Ahern <dsahern@...il.com>
To:     Lorenz Bauer <lmb@...udflare.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 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.

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.