netdev - Re: [PATCH net-next v5 22/25] ovpn: kill key and notify userspace in case of IV exhaustion

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: <ZpfGgHOqgSc9vOnx@hog>
Date: Wed, 17 Jul 2024 15:26:24 +0200
From: Sabrina Dubroca <sd@...asysnail.net>
To: Antonio Quartulli <antonio@...nvpn.net>
Cc: netdev@...r.kernel.org, kuba@...nel.org, ryazanov.s.a@...il.com,
	pabeni@...hat.com, edumazet@...gle.com, andrew@...n.ch
Subject: Re: [PATCH net-next v5 22/25] ovpn: kill key and notify userspace in
 case of IV exhaustion

2024-07-17, 13:03:11 +0200, Antonio Quartulli wrote:
> On 17/07/2024 12:42, Sabrina Dubroca wrote:
> > I don't see any way for userspace to know the current IV state (no
> > notification for when the packetid gets past some threshold, and
> > pid_xmit isn't getting dumped via netlink), so no chance for userspace
> > to swap keys early and avoid running out of IVs. And then, since we
> > don't have a usable primary key anymore, we will have to drop packets
> > until userspace tells the kernel to swap the keys (or possibly install
> > a secondary).
> > 
> > Am I missing something in the kernel/userspace interaction?
> 
> There are two events triggering userspace to generate a new key:
> 1) time based
> 2) packet count based
> 
> 1) is easy: after X seconds/minutes generate a new key and send it to the
> kernel. It's obviously based on guestimate and normally our default works
> well.
> 
> 2) after X packets/bytes generate a new key. Here userspace keeps track of
> the amount of traffic by periodically polling GET_PEER and fetching the
> VPN/LINK stats.

Oh right, that's what I was missing. TX packet count should be
equivalent to packetid. Thanks.

> A future improvement could be to have ovpn proactively notifying userspace
> after reaching a certain threshold, but for now this mechanism does not
> exist.

If it's not there from the start, you won't be able to rely on it
(because the userspace client may run on a kernel that does not
provide the notification), so you would still have to fetch the stats,
unless you have a way to poll for the threshold notification feature
being present.

> I hope it helps.

Yup, thanks. Can you add this explanation to the commit message for
this patch in the next version? Documenting a bit the expectations of
the kernel/userspace interactions would be helpful, also for the
sequencing of key installation/key swap operations. I'm guessing it
goes something like this:

 1. client sets up a primary key (key#1) and uses it
 2. at some point, it sets up a secondary key (key#2)
 3. later, keys are swapped (key#2 is now primary)
 4. after some more time, the secondary (key#1) is removed and a new
    secondary (key#3) is installed
 [steps 3 and 4 keep repeating]

And from reading patch 21, both the TX and RX key seem to be changed
together (swap and delete operate on the whole keyslot, and set
requires both the ENCRYPT_DIR and DECRYPT_DIR attributes).

A rough description of the overall life of a client (opening sockets
and setting up the ovpn device/peers) could also be useful alongside
the code.

-- 
Sabrina