netdev - Re: [PATCH bpf-next v2 1/3] net: Parse IPv6 ext headers from TCP sock

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] [day] [month] [year] [list]

Message-ID: <548feb0a-c066-93fd-c040-558624c8e429@gmail.com>
Date:   Tue, 14 Dec 2021 23:15:02 +0100
From:   Mathieu Jadin <mathjadin@...il.com>
To:     Jakub Kicinski <kuba@...nel.org>
Cc:     bpf@...r.kernel.org, KP Singh <kpsingh@...nel.org>,
        netdev@...r.kernel.org, Martin KaFai Lau <kafai@...com>,
        Song Liu <songliubraving@...com>, Yonghong Song <yhs@...com>,
        John Fastabend <john.fastabend@...il.com>,
        Andrii Nakryiko <andrii@...nel.org>,
        Alexei Starovoitov <ast@...nel.org>,
        Daniel Borkmann <daniel@...earbox.net>,
        Eric Dumazet <edumazet@...gle.com>,
        "David S. Miller" <davem@...emloft.net>,
        Joe Stringer <joe@...ium.io>, David Ahern <dsahern@...nel.org>,
        Hideaki YOSHIFUJI <yoshfuji@...ux-ipv6.org>
Subject: Re: [PATCH bpf-next v2 1/3] net: Parse IPv6 ext headers from TCP
 sock_ops


On 10/12/2021 03:01, Jakub Kicinski wrote:
> On Tue,  7 Dec 2021 23:56:33 +0100 Mathieu Jadin wrote:
>> Add a flag that, if set, triggers the call of eBPF program for each
>> packet holding an IPv6 extension header. Also add a sock_ops operator
>> that identifies such call.
>>
>> This change uses skb_data and skb_data_end introduced for TCP options'
>> parsing but these pointer cover the IPv6 header and its extension
>> headers.
>>
>> For instance, this change allows to read an eBPF sock_ops program to
>> read complex Segment Routing Headers carrying complex messages in TLV or
>> observing its intermediate segments as soon as they are received.
> 
> Can you share example use cases this opens up?
> 
In the context of IPv6 Segment Routing, Host A could communicate to Host 
B the Segment Routing Header (SRH) that it should use. For instance, a 
server could alleviate the load on its load balancer by asking the other 
host to route data away from the load balancer.
This can be more generic: Host A can have better information about the 
paths to use than the Host B.

Host A could communicate that in two ways:

1) Host B could simply reverse the segment list of an SRH used by Host 
A. This would make Host B follow the same path as Host A.

2) Host A could use a custom TLV in its own SRH to give an SRH to Host B.

For both options, Host B needs another patch to actually set the SRH in 
the same eBPF program. I plan to submit that later.

As for the other IPv6 extension headers, this seemed like a good 
opportunity to enable users to parse their received extension headers in 
eBPF.

Mathieu