[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <b631abf1-b390-45fb-b463-ac49fec0fdfe@openvpn.net>
Date: Wed, 17 Jul 2024 13:03:11 +0200
From: Antonio Quartulli <antonio@...nvpn.net>
To: Sabrina Dubroca <sd@...asysnail.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
Hi,
On 17/07/2024 12:42, Sabrina Dubroca wrote:
> 2024-06-27, 15:08:40 +0200, Antonio Quartulli wrote:
>> IV wrap-around is cryptographically dangerous for a number of ciphers,
>> therefore kill the key and inform userspace (via netlink) should the
>> IV space go exhausted.
>>
>> Signed-off-by: Antonio Quartulli <antonio@...nvpn.net>
>> ---
>> drivers/net/ovpn/netlink.c | 39 ++++++++++++++++++++++++++++++++++++++
>> drivers/net/ovpn/netlink.h | 8 ++++++++
>> 2 files changed, 47 insertions(+)
>>
>> diff --git a/drivers/net/ovpn/netlink.c b/drivers/net/ovpn/netlink.c
>> index 31c58cda6a3d..e43bbc9ad5d2 100644
>> --- a/drivers/net/ovpn/netlink.c
>> +++ b/drivers/net/ovpn/netlink.c
>> @@ -846,6 +846,45 @@ int ovpn_nl_del_key_doit(struct sk_buff *skb, struct genl_info *info)
>> return 0;
>> }
>>
>> +int ovpn_nl_notify_swap_keys(struct ovpn_peer *peer)
>
> This is not getting called anywhere in this version. v3 had a change
> to ovpn_encrypt_one to handle the -ERANGE coming from ovpn_pktid_xmit_next.
>
Darn! I must have missed this. This must have been removed by accident
during the n-th rebase/reshuffle. Thanks for pointing it out.
> Assuming this was getting called just as the TX key expires (like it
> was in v3), I'm a bit unclear on how the client can deal well with
> this event.
Correct assumption.
>
> 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.
A future improvement could be to have ovpn proactively notifying
userspace after reaching a certain threshold, but for now this mechanism
does not exist.
I hope it helps.
Cheers,
--
Antonio Quartulli
OpenVPN Inc.
Powered by blists - more mailing lists