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

[Sabrina Dubroca <sd@queasysnail.net>]

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