TLS/SSL Server Changes
Abstract
In z/VM 6.4 the TLS default is changed to 1.2, the default cipher is changed to RSA_AES_128_SHA256, and the z/VM System SSL Cryptographic Library (herein, System SSL) is updated to V2.2. Two workloads were used to evaluate the changes.
In a first experiment using a Telnet connection rampup workload, as the number of existing connections increased to 600, the SSL server consumed more CPU per new connection. However, this experiment did not show regression when comparing z/VM 6.4 and its defaults to z/VM 6.3 and its defaults.
In a second experiment using a Telnet data transfer workload, increasing the TLS to 1.2 and the cipher strength to RSA_AES_128_SHA256 did not show regression when compared back to TLS 1.0 with cipher RSA_AES_256.
In a third experiment also using the Telnet data transfer workload, moving to z/VM 6.4 and SSL V2.2 increased CPU/tx by 13.6% compared to z/VM 6.3 and SSL V2.1.
Method
Two workloads were used to evaluate the new default TLS 1.2 protocol and the new default cipher strength RSA_AES_128_SHA256 in z/VM 6.4.
The first workload studied the Telnet-connect environment in which 600 remote Linux Telnet logo connections were established to the Logical Device Support Facility (LDSF) on LPAR 2. A delay of two seconds was used between each connection.
Figure 1 describes the Telnet-connect workload setup.
| Figure 1. 600 Secure Telnet Logo Connections. |
|
| Notes: CEC model 2827-HA1, CP Assist for Cryptographic Function (CPACF) Support |
A Linux client driving the workload was running on LPAR 1. The Linux client opened a total of three VNC servers. Each VNC server established 200 telnet connections to LPAR 2. The CMS-based SSL server was running on LPAR 2.
The two LPARs communicated via OSA.
IBM collected MONWRITE data during measurement steady state and reduced it with Performance Toolkit for VM. A transaction was one successful Telnet connection. The workload throughput was controlled by the Linux client initiating one Telnet connection every two seconds. The TCPU column in FCX162 USERLOG for the SSL server was used to calculate guest CPU per transaction.
The second workload studied a Telnet data-transfer environment in which 200 existing remote Linux Telnet connections issued 'QUERY DASD' within an exec in parallel for the duration of data collection. A delay of one second was used between queries. This resulted in the data being outbound from the z/VM system (LPAR 2).
Figure 2 describes the Telnet data-transfer setup. On LPAR 1 a Linux client driving the workload was running. The Linux client used five VNC servers to establish a total of 200 telnet connections to the CMS SSU users on LPAR 2. Each VNC server supported forty connections.
| Figure 2. 200 Secure Telnet Connections Doing Data Transfer. |
|
| Notes: CEC model 2827-HA1, CP Assist for Cryptographic Function (CPACF) Support |
If should be noted that in both workloads the system configuration was designed to have no CPU constraints or memory constraints.
IBM collected MONWRITE data during measurement steady state and reduced it with Performance Toolkit for VM. Workload throughput was controlled by the Linux client Telnet sessions issuing the CP command 'QUERY DASD' with a one-second sleep between each query. For this particular test case in which 200 Telnet sessions were issuing one 'QUERY DASD' command each second, the throughput was 200 transactions/second. The TCPU column in FCX112 USER was used to calculate guest CPU utilization per transaction for the SSL and TCPIP servers.
Results and Discussion
Telnet Connection
Chart 1 shows the CPU time to establish a new Telnet connection versus existing number of connections.
| Chart 1. SSL CPU Time to Establish a New Connection versus Existing Connections. |
|
| Notes: CEC model 2827-HA1, CP Assist for Cryptographic Function (CPACF) Support |
In the z/VM 6.3 with TLS 1.0, the z/VM 6.3 with TLS 1.2, and the z/VM 6.4 with TLS 1.2 measurements, the CPU time to establish a new Telnet connection gradually increased with existing number of connections for the SSL server.
Telnet Data Transfer
Table 1 shows the CPU/tx cost for the Telnet data transfer workload in a z/VM 6.3 environment. This illustrates the effect of increasing the TLS and default encryption strength.
| Table 1. Telnet Data Transfer, z/VM 6.3, TLS 1.2 vs. TLS 1.0. | ||||
| Base | Comparison | Delta | Percent Difference (%) | |
| Runid | 2HDX108L | 2HDX108M | ||
| TLS level | TLS 1.0 | TLS 1.2 | ||
| Cipher | RSA_AES_256 | RSA_AES_128_SHA256 | ||
| ETR tx/sec | 200 | 200 | 0 | 0.0 |
| SSL server CPU/tx (p) | 0.445 | 0.440 | -0.005 | -1.1 |
| TCPIP server CPU/tx (p) | 0.205 | 0.205 | 0.000 | 0.0 |
|
Notes:
CEC model 2827-HA1;
z/VM 6.3;
CP Assist for Cryptographic Function (CPACF) Support;
SSL V2.1.
| ||||
The SSL server total CPU/tx decreased by 1.1% with the RSA_AES_128_SHA256 cipher when compared back to to the RSA_AES_256 cipher. The TCPIP server total CPU/tx remained constant.
Table 2 shows the CPU/tx cost for the Telnet data transfer workload. This illustrates the effect of moving from z/VM 6.3 to z/VM 6.4 and moving from SSL V2.1 to V2.2 while keeping the cipher strength and TLS constant.
|
Table 2.
Telnet Data Transfer,
z/VM 6.4 vs. z/VM 6.3. | ||||
| Base | Comparison | Delta | Percent Difference (%) | |
| Runid | 2HDX108M | 2HDX722M | ||
| z/VM Level | z/VM 6.3 | z/VM 6.4 | ||
| SSL Level | SSL V2.1 | SSL V2.2 | ||
| ETR tx/sec | 200 | 200 | 0 | 0.0 |
| SSL server CPU/tx (p) | 0.440 | 0.500 | 0.060 | 13.6 |
| TCPIP server CPU/tx (p) | 0.205 | 0.210 | 0.005 | 2.4 |
|
Notes:
CEC model 2827-HA1;
TLS Protocol: 1.2;
CP Assist for Cryptographic Function (CPACF) Support;
TLS 1.2;
Cipher RSA_AES_128_SHA256.
| ||||
The SSL server total CPU/tx increased by 13.6% with z/VM 6.4 and SSL V2.2 when compared back to z/VM 6.3 and SSL V2.1. The TCPIP server total CPU/tx increased by 2.4%.
Summary and Conclusions
In a 600 Telnet connection rampup environment, the SSL server consumed more CPU per new connection as the number of existing connections increased to 600. When compared back to z/VM 6.3 TLS 1.2 and z/VM 6.3 TLS 1.0 environments, the z/VM 6.4 TLS 1.2 environment did not show regression.
In the Telnet data transfer workload, increasing the TLS to 1.2 and the cipher strength to RSA_AES_128_SHA256 did not show regression when compared back to TLS 1.0 with cipher RSA_AES_256. In a z/VM 6.4 with z/VM System SSL Cryptographic Library V2.2, the SSL server CPU/tx increased by 13.6%.
Epilogue
APAR PI72106 introduced CRYPTO APVIRT support for the TLS/SSL server and LDAP/VM. One workload was used to evaluate the new CRYPTO APVIRT support.
Figure 3 describes the Telnet-connect workload setup.
| Figure 3. 600 Secure Telnet Logo Connections. |
|
| Notes: LPAR 1: CEC model 2817-M66, LPAR 2: CEC model 2964-NC9, CP Assist for Cryptographic Function (CPACF) Support, Crypto Express CEX5S |
The Linux client driving the workload was running on LPAR 1. The Linux client opened a total of three VNC servers. Each VNC server established 200 telnet connections to LPAR 2. The CMS-based SSL server was running on LPAR 2.
The two LPARs communicated via OSA.
IBM collected MONWRITE data during the measurement steady state and reduced it with Performance Toolkit. A transaction was one successful Telnet connection. The workload throughput was controlled by the Linux client initiating two Telnet connections every second. The TCPU column in FCX162 USERLOG for the SSL server was used to calculate guest CPU per transaction.
Chart 2 shows the CPU time to establish a new Telnet connection versus existing number of connections.
| Chart 2. 600 Secure Telnet Logo Connections. |
|
| Notes: CEC model 2964-NC9, CP Assist for Cryptographic Function (CPACF) Support, Crypto Express CEX5S, TLS 1.2; Cipher RSA_AES_128_SHA256. |
In the z/VM 6.4, the z/VM 6.4 with APAR PI72106, and z/VM 6.4 with APAR PI72106 with crypto measurements, the CPU time to establish a new Telnet connection increased with existing number of connections for the SSL server. In the z/VM 6.4 with APAR PI72106 with crypto support measurement, the average CPU time per transaction to establish a new Telnet connection over the measurement period was 30% less when compared back to the two base measurements.