netdev - Re: Regarding UDP-Lite deprecation and removal

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: <20240321084139.4dac7e74@kernel.org>
Date: Thu, 21 Mar 2024 08:41:39 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: Lynne <dev@...ne.ee>
Cc: Florian Westphal <fw@...len.de>, Netdev <netdev@...r.kernel.org>, Kuniyu
 <kuniyu@...zon.com>, Willemdebruijn Kernel
 <willemdebruijn.kernel@...il.com>
Subject: Re: Regarding UDP-Lite deprecation and removal

On Mon, 18 Mar 2024 18:58:10 +0100 (CET) Lynne wrote:
> Mar 18, 2024, 14:18 by fw@...len.de:
> > Lynne <dev@...ne.ee> wrote:
> >  
> >> UDP-Lite was scheduled to be removed in 2025 in commit
> >> be28c14ac8bbe1ff due to a lack of real-world users, and
> >> a long-outstanding security bug being left undiscovered.
> >>
> >> I would like to open a discussion to perhaps either avoid this,
> >> or delay it, conditionally.
> >>  
> >
> > Is there any evidence UDP-Lite works in practice?

FWIW I also vote to delete UDP-Lite unless we have real uses that show
benefit, preferably _in production_.

> > I am not aware of any HW that will peek into L3/L4 payload to figure out
> > that the 'udplite' payload should be passed up even though it has bad csum.
> >
> > So, AFAIU L2 FCS/CRC essentially renders entire 'partial csum' premise moot,
> > stack will never receive udplite frames that are damaged.

Plus FEC protection on top of FCS is increasingly common.

I presume someone did mathematical analysis that UDP Lite is sound,
but my engineering senses are tingling at the thought that we're
simultaneously saying that BER is high enough to want to process
damaged packets, and low enough for the internet csum to be
sufficiently strong.

The whole thing feels a little bit like an attempt to preserve
zero-checksum for IPv6. For HW which wants to spit out IP headers
followed by a block of raw unchecksummed data. I've done such things
in the past on an FPGA out of laziness. Nothing to do with receiving
actually damaged frames.

> > Did things change?
> >  
> 
> I do somehow get CRC errors past the Ethernet layer on consumer rtl cards,
> by default, with no ethtool changes, so maybe things did change.

Yes, but that's just the last hop. Is the entire network going
to disable L2 csums? Or are we just going to use the UDP-lite-
-abilities on the last hop?

> I haven't sacrificed a good cable yet to get a definitive proof.
> The cargo-culted way to be sure is to enable rx-all.