mirror of
https://github.com/OpenVPN/openvpn.git
synced 2025-05-09 21:51:05 +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>
Unit Tests
This directory contains unit tests for openvpn. New features/bugfixes should be written in a test friendly way and come with corresponding tests.
Run tests
Tests are run by make check. A failed tests stops test execution. To run all
tests regardless of errors call make -k check.
Add new tests to existing test suite
Test suites are organized in directories. example_test/ is an example for a test suite with two test executables. Feel free to use it as a template for new tests.
Test suites
Test suites live inside a subdirectory of $ROOT/tests/unit_tests, e.g. $ROOT/tests/unit_tests/my_feature.
Test suites are configured by a Makefile.am. Tests are executed by testdrivers. One testsuite can contain more than one testdriver.
Hints
- Name suites & testdrivers in a way that the name of the driver says something about which component/feature is tested
- Name the testdriver executable
*_testdriver. This way it gets picked up by the default.gitignore- If this is not feasible: Add all output to a
.gitignore* Use descriptive test names:coffee_brewing__with_no_beans__failsvs.test34
- If this is not feasible: Add all output to a
- Testing a configurable feature? Wrap test execution with a conditional (see auth_pam for an example)
- Add multiple test-drivers when one testdriver looks crowded with tests
New Test Suites
- Organize tests in folders for features.
- Add the new test directory to
SUBDIRSinMakefile.am - Edit
configure.acand add the newMakefiletoAC_CONFIG_FILES - Run
./configure, and enable the feature you'd like to test - Make sure that
make checkruns your tests - Check: Would a stranger be able to easily find your tests by you looking at the test output?
- Run
./configure, and disable the feature you'd like to test - Make sure that
make checkdoes not run your tests