netdev - Re: [PATCH net-next v3 10/24] ovpn: implement basic RX path (UDP)

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

Message-ID: <80351026-0d15-460a-8002-4b24b893fefa@openvpn.net>
Date: Thu, 18 Jul 2024 15:27:42 +0200
From: Antonio Quartulli <antonio@...nvpn.net>
To: Sabrina Dubroca <sd@...asysnail.net>
Cc: netdev@...r.kernel.org, Jakub Kicinski <kuba@...nel.org>,
 Sergey Ryazanov <ryazanov.s.a@...il.com>, Paolo Abeni <pabeni@...hat.com>,
 Eric Dumazet <edumazet@...gle.com>, Andrew Lunn <andrew@...n.ch>,
 Esben Haabendal <esben@...nix.com>
Subject: Re: [PATCH net-next v3 10/24] ovpn: implement basic RX path (UDP)

On 18/07/2024 15:11, Sabrina Dubroca wrote:
>> basically the idea is: with our encapsulation we can guarantee that what
>> entered the tunnel is also exiting the tunnel, without corruption.
>> Therefore we claim that checksums are all correct.
> 
> Can you be sure that they were correct when they went into the tunnel?
> If not, I think you have to set CHECKSUM_NONE.

I can't be sure, because on the sender side we don't validate checksums 
before encapsulation.

If we assume that outgoing packets are always well formed and they can 
only be damaged while traveling on the link, then the current code 
should be ok.

If we cannot make this assumption, then we need the receiver to verify 
all checksums before moving forward (which is what you are suggesting).

Is it truly possible for the kernel to hand ovpn a packet with invalid 
checksums on the TX path?

Cheers,

-- 
Antonio Quartulli
OpenVPN Inc.