5.2.2.1. LightWeight Security PSK vs HMAC Only vs Full Security PSK

In RTI Connext 7.1 we introduced Pre-Shared Key Protection (PSK)` to secure the RTPS communication. This PSK can be leveraged in two ways: As a part of RTI Security Plugins, protecting bootstrapping communications before authentication is successfully concluded or as a dedicated library named RTI Lightweight Security Plugins, where PSK` is the only option and protects the entirety of the communication. PSK can be configured to use various cryptographic algorithms: AES128 or AES256 in GCM (for both integrity and confidentiality) mode.

In RTI Connext 7.1 we deprecated HMAC-only mode which is scheduled to be superseded in the next release with Lightweight Security. It supports non-configurable HMAC-SHA256 which only protects data integrity without its confidentiality.

Charts below compare performance of the Lightweight Security’s AES256 GCM algorithm with HMAC-only and a non-secure scenario. We show here that PSK performs better than HMAC-only.

x64 Linux (10Gbps)Test Info

Discovery TimeNetwork LoadMemory Usage

Endpoint Discovery

The following graph displays the time it takes to complete endpoint discovery, per number of participants. There is one endpoint for each participant; across all participants, half the endpoints are DataWriters and half are DataReaders. For each scenario, we graph three values: the maximum, median, and minimum times that the participants took to complete endpoint discovery. (Maximums and minimums are the dashed lines; medians are the solid lines.)

5.2.2.2. openSSL 3.0 vs openSSL 1.1.1

This section compares the performance of the cryptographic libraries that RTI Connext supports. We compare the performance of the OpenSSL 3, and OpenSSL 1.1.1 cryptographic libraries. Changes in the patch versions of those libraries (last digit in the OpenSSL 3, letter in the OpenSSL 1 version number) should not have a great effect on the performance results.

Notice that these tests use the cryptographic libraries along to the RTI Connext code, however, in order to prove that these differences are not due to the RTI Connext specific code we also gathered some metrics isolating the Cryptographic operations, see Cryptographic Libraries section.

10Gbps Network

Discovery TimeNetwork LoadMemory Usage

Endpoint Discovery

5.2.2.3. Ephemeral Keys Pairs for the Key Agreement Algorithm (7.0.0)

Note

This change was added for 7.0.0. Issue reference is SEC-1676

10Gbps Network

Discovery TimeNetwork LoadMemory Usage

5.2.2.4. 7.0.0 vs 6.1.1 (Security Governance Configuration Levels)

10Gbps Network

Discovery TimeNetwork LoadMemory Usage

5.2.2.5. Comparison between 6.1.1 and 6.0.1

Due to several improvements added in Connext DDS and Security Plugins in 6.1.0, you will see big improvements in discovery time in 6.1.1 (and 6.1.0). The following graph and tables show the results of the tests above done for both 6.0.1 and 6.1.1.

Note

Note that the numbers used to compare these two releases were taken independently, in a different laboratory, hence the mismatch between these numbers and the ones above See the hardware information for more details.

Linux x64

Time to complete Discovery (Seconds)

6.1.16.0.1Difference

Participants	No Security	Authentication Only	Secure Discovery	Secure Discovery + Sign
50	2.7320	3.0650	3.1160	3.3220
75	3.0160	3.5920	3.6760	3.8000
100	3.4170	4.2510	6.4510	6.1540
125	4.2110	8.1120	8.2910	8.7180
150	5.1460	11.2380	10.3900	10.5340
175	6.0260	14.2170	13.2850	13.2770
200	6.8690	15.0870	17.2230	17.1860
225	8.2230	18.6980	20.9340	21.5640
250	9.8220	24.4040	26.5830	26.7730
275	12.1190	28.1240	32.0280	32.5500
300	13.6740	32.6540	37.4390	38.4670

Participants	No Security	Authentication Only	Secure Discovery	Secure Discovery + Sign
50	2.630	3.101	5.071	5.093
75	3.446	3.766	5.706	7.085
100	4.011	4.541	9.122	9.024
125	5.165	10.544	14.980	15.788
150	6.148	11.256	23.689	25.663
175	8.081	14.872	38.195	39.401
200	9.589	18.650	56.997	59.554
225	12.328	21.932	78.655	80.577
250	17.073	27.133	102.576	106.598
275	18.369	35.549	129.574	135.227
300	21.289	39.642	160.880	165.835

Participants	No Security	Authentication Only	Secure Discovery	Secure Discovery + Sign
50	0.10	-0.04	-1.95	-1.77
75	-0.43	-0.17	-2.03	-3.29
100	-0.59	-0.29	-2.67	-2.87
125	-0.95	-2.43	-6.69	-7.07
150	-1.00	-0.02	-13.30	-15.13
175	-2.05	-0.65	-24.91	-26.12
200	-2.72	-3.56	-39.77	-42.37
225	-4.10	-3.23	-57.72	-59.01
250	-7.25	-2.73	-75.99	-79.83
275	-6.25	-7.43	-97.55	-102.68
300	-7.62	-6.99	-123.44	-127.37

For more information about the improvements that account for these gains, see:

• “Improved support for concurrency in data reception events in

  DataReaders in a DomainParticipant” in the Core Libraries’s Performance Improvements

• “Improved discovery scalability when using BuiltinQosLib::Generic.Security profile”

  in the Security Plugins’s Changes Related to Scalability

• “Endpoint state transition improvements for key distribution”

  in the Security Plugins’s Changes Related to Scalability

• “Potentially very long recovery times for timed-out authentications”

  in the Security Plugins’s Fixes Related to Scalability

Hardware information

Linux Nodes

Dell R340 Servers (13 Units)
Processor: Intel Xeon E-2278G (3.4-5GHz, 8c/16t, 16MB cache, 2 memory channels @2666MHz)
RAM: 4x 16GB 2666MHz DIMM (64GB RAM)
HD: 480GB SATA SSD
NIC 1: Intel 710 dual port 10Gbps SFP
OS: Ubuntu 20.04 -- gcc 9.3.0

Switch

Dell 2048 -- 10Gbps switch (10Gbps and 1Gbps interfaces)