[tsvwg] l4s and sce testing on vpns

Dave Taht <dave.taht@gmail.com> Mon, 22 February 2021 01:53 UTC

MIME-Version: 1.0
From: Dave Taht <dave.taht@gmail.com>
Date: Sun, 21 Feb 2021 17:53:09 -0800
Message-ID: <CAA93jw7Jo=adYmJBqt5DC=WUB8W3wzjOVWQj2Kd4APtnzg08aA@mail.gmail.com>
To: tsvwg IETF list <tsvwg@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/DB0G_n7SkYjpMjnyRwipZRn2W00>
Subject: [tsvwg] l4s and sce testing on vpns
Precedence: list

The last time I paid attention to all this, I'd called for more
testing. While a minority opinion at the time, in particular, I'd
wanted a survey of the scope and extent of this vpn decapsulation bug
in linux, to see how serious it was, and to see if it was in any other
operating systems or hardware, particularly firewalling
products like checkpoint, etc. I felt it would take a very, very long
time to flush it out of the field, regardless

Most recently endianess was fixed in this commit:

2867e1eac61016f59b3d730e3f7aa488e186e917

Author: Toke Høiland-Jørgensen <toke@redhat.com>
Date:   Mon Nov 30 19:37:05 2020 +0100

    inet_ecn: Fix endianness of checksum update when setting ECT(1)

    When adding support for propagating ECT(1) marking in IP headers it seems I
    suffered from endianness-confusion in the checksum update calculation: In
    fact the ECN field is in the *lower* bits of the first 16-bit word of the
    IP header when calculating in network byte order. This means that the
    addition performed to update the checksum field was wrong; let's fix that.

    Fixes: b723748750ec ("tunnel: Propagate ECT(1) when decapsulating as recomme
nded by RFC6040")
    Reported-by: Jonathan Morton <chromatix99@gmail.com>
    Tested-by: Pete Heist <pete@heistp.net>
    Signed-off-by: Toke Høiland-Jørgensen <toke@redhat.com>
    Link: https://lore.kernel.org/r/20201130183705.17540-1-toke@redhat.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>



Has anyone done a study/survey of the effects of this fix and the
original attempt? Was a detection method for L4S derived for it?

There were more than a few other things I'd wanted tested since last
time. I've read over the SCE and L4S related reports as of, august, or
so of
last year, is there new data?

Have the L4S and SCE codebases been updated to modern kernels so they
can be easily tested again?


-- 
"For a successful technology, reality must take precedence over public
relations, for Mother Nature cannot be fooled" - Richard Feynman

dave@taht.net <Dave Täht> CTO, TekLibre, LLC Tel: 1-831-435-0729

[tsvwg] l4s and sce testing on vpns Dave Taht
Re: [tsvwg] l4s and sce testing on vpns Jonathan Morton