Re: Regarding UDP-Lite deprecation and removal

[Paolo Abeni <pabeni@redhat.com>]

On Mon, 2024-03-18 at 18:58 +0100, Lynne wrote:
> Mar 18, 2024, 14:18 by fw@strlen.de:
> 
> > Lynne <dev@lynne.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?
> > 
> > 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.
> > 
> > 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.
> 
> 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.

I did not consider the mac-level csum - thanks Florian for bringing
that up.

Yes, you can disable FCS checking on the local host - for some NIC at
least - and AFAIK that is the only way to receive csum corrupted
packets. Delivery packets with bad FCS without F_RXALL set would be a
bug.

And you need to set F_RXALL on all the intermediate hops.

All in all, the use-case looks very thin at best.

In any case, to  step-in to maintain a specific protocol you should
start first contributing. I *guess* a reasonable good start would be
implementing UDP-lite selftests.

Cheers,

Paolo