netdev - Re: [PATCH net-next 3/4] bpf: BPF for lightweight tunnel encapsulation

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: <CALx6S34hHZDdtZgLBZzw-QiOc80tjrLAuAVBDeWRuUonR1MfXA@mail.gmail.com>
Date:   Mon, 31 Oct 2016 07:17:41 -0700
From:   Tom Herbert <tom@...bertland.com>
To:     Thomas Graf <tgraf@...g.ch>
Cc:     "David S. Miller" <davem@...emloft.net>,
        Alexei Starovoitov <alexei.starovoitov@...il.com>,
        Daniel Borkmann <daniel@...earbox.net>,
        Linux Kernel Network Developers <netdev@...r.kernel.org>,
        roopa <roopa@...ulusnetworks.com>
Subject: Re: [PATCH net-next 3/4] bpf: BPF for lightweight tunnel encapsulation

On Mon, Oct 31, 2016 at 5:59 AM, Thomas Graf <tgraf@...g.ch> wrote:
> On 10/30/16 at 06:28pm, Tom Herbert wrote:
>> Right, that's why we rely on a dst cache. Any use of LWT that
>> encapsulates or tunnels to a fixed destination (ILA, VXLAN, IPIP,
>> etc.) would want to use the dst cache optimization to avoid the second
>> lookup. The ILA LWT code used to call orig output and that worked as
>> long as we could set the default router as the gateway "via". It was
>> something we were able to deploy, but not a general solution.
>> Integrating properly with routing gives a much better solution IMO.
>> Note that David Lebrun's latest LWT Segment Routing patch does the
>> second lookup with the dst cache to try to avoid it.
>
> Noticed while implementing this: How does ILA ensure that dst_output()
> is not invoked in a circular manner?
>
> dstA->output() -> dstB->otuput() -> dstA->output() -> ...

It doesn't. We'll need to add a check for that. Maybe the rule should
be that an skbuff is only allowed to hit one LWT route?

Another scenario to consider: Suppose someone is doing protocol
translation like in RFC7915. This is one of operations we'd need with
ILA or GRE to implement an IPv4 overlay network over IPv6. Would this
be allowed/supported in LWT BPF?

Tom