From: Santucci Pierpaolo <santucci@epigenesys.com>
To: Jakub Sitnicki <jakub@cloudflare.com>
Cc: Andrii Nakryiko <andrii.nakryiko@gmail.com>,
Shuah Khan <shuah@kernel.org>,
Alexei Starovoitov <ast@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>, Martin Lau <kafai@fb.com>,
Song Liu <songliubraving@fb.com>, Yonghong Song <yhs@fb.com>,
Andrii Nakryiko <andrii@kernel.org>,
john fastabend <john.fastabend@gmail.com>,
KP Singh <kpsingh@chromium.org>,
Networking <netdev@vger.kernel.org>, bpf <bpf@vger.kernel.org>
Subject: Re: [PATCH] selftest/bpf: fix IPV6FR handling in flow dissector
Date: Wed, 11 Nov 2020 15:12:21 +0100 [thread overview]
Message-ID: <X6vxRV1zqn+GjLfL@santucci.pierpaolo> (raw)
In-Reply-To: <87imacw3bh.fsf@cloudflare.com>
Hi Jakub,
thanks for your reply.
Let me explain the problem with an example.
Please consider the PCAP file:
https://github.com/named-data/ndn-tools/blob/master/tests/dissect-wireshark/ipv6-udp-fragmented.pcap
Let's assume that the dissector is invoked without the flag:
BPF_FLOW_DISSECTOR_F_STOP_AT_FLOW_LABEL.
Without the proposed patch, the flow keys for the second fragment (packet
timestamp 0.256997) will contain the value 0x6868 for the source and
destination port fields: this is obviously wrong.
The same happens for the third fragment (packet timestamp 0.256998) and for
the fourth fragment (packet timestamp 0.257001).
So it seems that the correct thing to do is to stop the dissector after the
IPV6 fragmentation header for all fragments from the second on.
Regards,
Pierpaolo Santucci
On Wed, Nov 11, 2020 at 12:17:06PM +0100, Jakub Sitnicki wrote:
> On Wed, Nov 11, 2020 at 05:48 AM CET, Andrii Nakryiko wrote:
> > On Tue, Nov 10, 2020 at 9:12 AM Santucci Pierpaolo
> > <santucci@epigenesys.com> wrote:
> >>
> >> From second fragment on, IPV6FR program must stop the dissection of IPV6
> >> fragmented packet. This is the same approach used for IPV4 fragmentation.
> >>
> >
> > Jakub, can you please take a look as well?
>
> I'm not initimately familiar with this test, but looking at the change
> I'd consider that Destinations Options and encapsulation headers can
> follow the Fragment Header.
>
> With enough of Dst Opts or levels of encapsulation, transport header
> could be pushed to the 2nd fragment. So I'm not sure if the assertion
> from the IPv4 dissector that 2nd fragment and following doesn't contain
> any parseable header holds.
>
> Taking a step back... what problem are we fixing here?
>
> >
> >> Signed-off-by: Santucci Pierpaolo <santucci@epigenesys.com>
> >> ---
> >> tools/testing/selftests/bpf/progs/bpf_flow.c | 2 ++
> >> 1 file changed, 2 insertions(+)
> >>
> >> diff --git a/tools/testing/selftests/bpf/progs/bpf_flow.c b/tools/testing/selftests/bpf/progs/bpf_flow.c
> >> index 5a65f6b51377..95a5a0778ed7 100644
> >> --- a/tools/testing/selftests/bpf/progs/bpf_flow.c
> >> +++ b/tools/testing/selftests/bpf/progs/bpf_flow.c
> >> @@ -368,6 +368,8 @@ PROG(IPV6FR)(struct __sk_buff *skb)
> >> */
> >> if (!(keys->flags & BPF_FLOW_DISSECTOR_F_PARSE_1ST_FRAG))
> >> return export_flow_keys(keys, BPF_OK);
> >> + } else {
> >> + return export_flow_keys(keys, BPF_OK);
> >> }
> >>
> >> return parse_ipv6_proto(skb, fragh->nexthdr);
> >> --
> >> 2.29.2
> >>
next prev parent reply other threads:[~2020-11-11 14:12 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-10 17:12 [PATCH] selftest/bpf: fix IPV6FR handling in flow dissector Santucci Pierpaolo
2020-11-11 4:48 ` Andrii Nakryiko
2020-11-11 11:17 ` Jakub Sitnicki
2020-11-11 14:12 ` Santucci Pierpaolo [this message]
2020-11-11 23:06 ` Daniel Borkmann
2020-11-12 9:00 ` Jakub Sitnicki
2020-11-13 0:50 ` John Fastabend
2020-11-16 10:30 ` [PATCH v2] " Santucci Pierpaolo
2020-11-16 12:18 ` Jakub Sitnicki
2020-11-16 16:10 ` patchwork-bot+netdevbpf
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=X6vxRV1zqn+GjLfL@santucci.pierpaolo \
--to=santucci@epigenesys.com \
--cc=andrii.nakryiko@gmail.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=jakub@cloudflare.com \
--cc=john.fastabend@gmail.com \
--cc=kafai@fb.com \
--cc=kpsingh@chromium.org \
--cc=netdev@vger.kernel.org \
--cc=shuah@kernel.org \
--cc=songliubraving@fb.com \
--cc=yhs@fb.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox