mirror of
https://github.com/OpenVPN/openvpn.git
synced 2025-05-08 21:25:53 +08:00
9f4670fc71
With DCO and possible future hardware assisted OpenVPN acceleration we are approaching the point where 32 bit IVs are not cutting it any more, especially if we are limiting the IVs to the safe limits of AES-GCM where the limit is more 2^29. To illustrate the problem, some back of the envelope math here: If we want to keep the current 3600s renegotiation interval and have a safety margin of 25% (when we trigger renegotiation) we have about 3.2 million packets (2*32 * 0.7) to work with. That translates to about 835k packets per second. Currently, implementation trigger the renegotiation at 0xff00000000 or at 7/8 of the AEAD usage limit. With 1300 Byte packets that translates into 8-9 Gbit/s. That is far from unrealistic any more. Current DCO implementations are already in spitting distance to that or might even reach (for a single client connection) that if you have extremely fast single core performance CPU. With the AEAD usage limit, these limits are almost a factor of 8 lower so with the limit becomes 1-2 GBit/s. This is already reached without DCO on some platforms. This introduces the epoch data format for AEAD data channel ciphers in TLS mode ciphers. No effort has been made to support larger packet counters in any other scenario since those are all legacy. This uses the same approach of epoch keys as (D)TLS 1.3 does and switches the data channel regularly for affected AEAD ciphers when reaching the usage limit. For Chacha20-Poly1305, which does not suffer the same problems as AES-GCM, the full 48 bit of packet counter are used only after that the same logic to switch to a new key as with AES-GCM is done. Change-Id: I00751c42cb04e30205ba8e6584530831e0d143c5 Signed-off-by: Arne Schwabe <arne@rfc2549.org> Acked-by: MaxF <max@max-fillinger.net> Message-Id: <20250212161311.16888-1-gert@greenie.muc.de> URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg30845.html Signed-off-by: Gert Doering <gert@greenie.muc.de>