On 17/07/2024 15:26, Sabrina Dubroca wrote:

2024-07-17, 13:03:11 +0200, Antonio Quartulli wrote:

quoted

On 17/07/2024 12:42, Sabrina Dubroca wrote:

quoted

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.

np!

quoted

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.

You're right. Then scratch that because userspace is not ready for this.

quoted

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:

Sure, will document how this works.

  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).

You are correct. Encryption and decryption keys are derived from the 
same key material that is exchanged/generated upon each "renegotiation".

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.

ok, will add it too!

Thanks!


-- 
Antonio Quartulli
OpenVPN Inc.