TLS Certificate Verification
With z/VM 7.1 TCP/IP APAR PH18435 and its CMS and LE corequisites, support was added to let the z/VM FTP server, the z/VM SMTP server, and any statically secured connection use client certificate verification. This extends the support previously added for the z/VM Telnet server.
This enhancement also changed the default behavior of the z/VM Telnet server as regards client certificate verification. Without the PTF, the default behavior for the Telnet server is CLIENTCERTCHECK NONE. With the PTF applied, the default behavior for the Telnet server is CLIENTCERTCHECK PREFERRED. Thus customers who had not coded explicit behavior for the Telnet server will experience different function and correspondingly different performance.
One workload was used to evaluate the additional encryption cost of the new default. Using a Telnet connection ramp-up workload, as the number of existing connections increased to 600, very steadily the SSL server CPU time needed to establish a connection increased by 24 msec when compared back to the previous default behavior. This is the CPU cost of verifying a client certificate.
MethodA Telnet-connect workload was used to evaluate the additional encryption. Figure 1 describes the Telnet-connect workload setup.
|Figure 1. 600 Secure Telnet Logo Connections.|
|Notes: CEC model 8561-T01, CP Assist for Cryptographic Function (CPACF) Support, z/VM 7.2|
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 on LPAR 2. The CMS-based SSL server was running on LPAR 2. The two LPARs communicated via OSA.
At the moment we did this analysis, z/VM 7.2 was already in evaluation and so we also used this experiment as a means to evaluate z/VM 7.2 behavior. Thus our runs used a mix of z/VM 7.1 without the PTF, z/VM 7.2, which included the PTF in the base, and z/VM 7.2 with the Telnet server explicitly configured to its pre-PTF behavior.
IBM collected MONWRITE data during measurement steady state and reduced 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 half a second. The TCPU column in FCX162 USERLOG for the SSL server was used to calculate guest CPU per transaction.
Results and Discussion
Table 1 shows the CPU time to establish a new Telnet connection versus existing number of connections.
|Table 1. CPU Milliseconds Needed for a New Connection|
|Notes: CEC model 8561-T01, Crypto Express CEX7A, CP Assist for Cryptographic Function (CPACF) Support, cipher ECDHE_RSA_AES_128_SHA256. "7.1" is z/VM 7.1 without the PTF. "7.2" is z/VM 7.2, which contains the PTF in the base. "7.2+CCC_NONE" is z/VM 7.2 with the Telnet server configured to INTERNALCLIENTPARMS CLIENTCERTCHECK NONE.|
Chart 1 shows a graph of the same information.
|Chart 1. SSL CPU Time to Establish a New Connection versus Existing Connections.|
|Notes: CEC model 8561-T01, Crypto Express CEX7A, CP Assist for Cryptographic Function (CPACF) Support, cipher ECDHE_RSA_AES_128_SHA256. "7.1" is z/VM 7.1 without the PTF. "7.2" is z/VM 7.2, which contains the PTF in the base. "7.2-chk" is z/VM 7.2 with INTERNALCLIENTPARMS CLIENTCERTCHECK NONE.|
With either the old default behavior or the new default behavior, the SSL server CPU time needed to establish a connection gradually increased with existing number of connections. Very steadily, over the measurement period, the SSL server CPU time to establish a new connection increased by 24 msec with the new default behavior, compared back to the old default behavior.
With the PTF applied, the old Telnet server behavior can be achieved by coding INTERNALCLIENTPARMS CLIENTCERTCHECK NONE in the z/VM TCP/IP configuration file, often named PROFILE TCPIP.
The new default behavior for the Telnet server increases the CPU time used by the SSL server in creating a new Telnet connection. The increase is about 24 msec. The old default behavior can be selected explicitly by coding it in PROFILE TCPIP.