IPv6/VSE Automatic SSL/TLS Sockets

SSL without SSL/TLS Programming

We often hear customers asking to be able to use SSL/TLS sockets without having to change their applications. Since converting their applications is a lot of work and requires at least a basic understanding of SSL/TLS programming, the conversion of plain text applications to SSL/TLS applications can be daunting to say the least.

IPv6/VSE provides an answer to this problem.

ATLS Automatic Transport Layer Security

Automatic Transport Layer Security is a facility that is similar to the z/OS AT-TLS (Application Transparent - Transport Layer Security) facility. When a socket is established, the BSTTATLS application automatically determines if SSL/TLS is needed (based on your configuration) and converts the socket to SSL/TLS transparently to the application.

For example, the BSTTFTPS FTP server is running and listening for connections on port 21. If a clear text FTP client wishes to connect, they use port 21. The BSTTATLS application is also listening on port 990 (the FTP over SSL port) and when an SSL/TLS connection arrives on port 990 it is automatically converted to clear text and passed to the BSTTFTPS FTP server on port 21. This effectively this means that the BSTTFTPS FTP server is supporting both clear text and implicit-ftps connections.

At the same time, when BSTTMTPC batch Email client attempts to connect to SMTP.GMAIL.COM on port 25 (SMTP), the BSTTATLS application automatically converts the outbound socket to a connection to SMTP.GMAIL.COM on SSL/TLS port 465 (Implicit-SMTPS).

In both examples, no changes were made to the BSTTFTPS or BSTTMTPC applications or the JCL used to run these applications.

BSTTATLS works for both client and server applications and its operation is completely transparent to the application. The BSTTALTS application supports both batch and CICS applications written in any supported API including applications using the ASM SOCKET macro, EZASMI, EZASOKET and LE/C APIs.

Using BSTTATLS is very useful if you want to use SSL/TLS to securely transfer data but do not want to re-code or change your batch or CICS applications. Your batch or CICS socket applications continue to run unchanged even though they are now transferring data using SSL/TLS to remote hosts.

Design

The IPv6/VSE TCP/IP stacks run in separate partitions. The IPv4 stack (BSTTINET) runs in one partition and the IPv6 stack (BSTT6NET) runs in another. The TCP/IP stacks are then coupled together acting as a single stack. The BSTTATLS application is associated with a specific stack (BSTTINET or BSTT6NET). When running a typical dual stack configuration there will be two BSTTATLS application partitions. One for each TCP/IP stack.

The reasons for this design are performance, reliability and robustness. Since the BSTTATLS application is performing SSL/TLS functionality, the overhead of this functionality is offloaded from both the TCP/IP stack and the applications BSTTATLS is servicing.

Operation

The BSTTATLS application must be started before any of the applications it is servicing. And, the applications BSTTATLS is servicing should be shutdown/terminated before terminating the BSTTATLS application. If the BSTTATLS application is terminated using the TERMINATE console command, all active sockets will be abnormally closed before BSTTATLS goes to EOJ.

To allow jobs to wait for the BSTTATLS application to start up, use the BSTTWTLS application.

// LIBDEF PHASE,SEARCH=(bsilib.slib) // OPTION SYSPARM='00' // EXEC BSTTWTLS,SIZE=BSTTWTLS /*

The BSTTWTLS application will attempt to verify the BSTTATLS application is available every 30 seconds. BSTTWTLS will go to EOJ when the BSTTATLS application is detected. The BSTTWTLS application can be terminated early by issuing a MSG BSTTWTLS command on the console. No data needs to be entered with the MSG command.

ATLS Types

Source	Destination
Server	Accept SSL connection Convert to clear text for local server application
Client	Accept clear text local client connection Convert to SSL/TLS connection for destination
IPv4 socket	To IPv4 socket
IPv6 socket	To IPv6 socket

ATLS Examples

Accept a clear text connection from BSTTMTPC and convert the connection to SSL/TLS on port 465. This type of connection is commonly called smtps.
Accept an SSL connection on port 443 and convert the connection to CICS TS Web Services on clear text port 80. This type of connections commonly called https.
Accept an SSL connection on port 992 and convert the connection to clear text on port 23. This type of connection is commonly called telnets.
Accept a clear text connection from BSTTFTPC and convert the connection to SSL/TLS on port 990. This type of connection is commonly called ftps.
Accept an SSL connection on port 990 and convert the connection to clear text on port 21. This type of connection is commonly called ftps.

Sample ATTLS Commands

Command	Description
OPTION CLIENT ATTLS 25 TO SMTP.GOOGLE.COM AS 465 SSL	Intercept outbound CLIENT connections made to SMTP.GMAIL.COM on port 25, convert them to SSL connections on port 465 (Implicit-SMTPS).
OPTION CLIENT OPTION FTP ATTLS 21 TO FTPS.BSIOPTI.COM AS 990 SSL	Intercept outbound FTP CLIENT connections made to FTPS.BSIOPTI.COM on port 21, convert them to SSL connections on port 990 (Implicit-FTPS).
OPTION SERVER ATTLS 23 AS 992 SSL	Intercept inbound SERVER connections made on SSL port 992 (Implicit-TELNETS), convert them to clear text connections on port 23.
OPTION SERVER ATTLS 80 AS 443 SSL	Intercept inbound SERVER connections made on SSL port 443 (Implicit-HTTPS), convert them to clear text connections on port 80.
OPTION SERVER OPTION FTP ATTLS 21 AS 990 SSL	Intercept inbound SERVER connections made on SSL port 990 (Implicit-FTPS), convert them to clear text connections on port 21.

BSTTATLS JCL

The following shows sample JCL for using the BSTTATLS proxy server.

// OPTION SYSPARM='66' // SETPARM IPTRACE='NNNNNNN' // SETPARM LRGBUF=YES // LIBDEF *,SEARCH=(ssllib.slib,bsilib.slib) // EXEC BSTTATLS,SIZE=BSTTATLS ID 66 * KEYRING PRD2.CONFIG DNAME MYCERT SECTYPE TLSV1 * OPTION SERVER ATTLS 23 AS 992 SSL /*

Partition Size

The BSTTATLS server application requires a minimum 20M partition plus 72K for each possible socket to be handled by the BSTTATLS server.
For example, to support 600 TELNETS sessions, 4 FTPS sessions and 100 HTTPS sessions you will need a 20MB + 51MB = 71MB partition.

Partition Priority

The BSTTATLS server is very CPU intensive due to SSL encryption and decryption processing. The BSTTATLS partition priority should always be lower than the TCP/IP stack partition.

BSTTATLS Sample Configuration

// OPTION SYSPARM='00' // SETPARM IPTRACE='NNNNNNN' // SETPARM LRGBUF=YES // LIBDEF *,SEARCH=(ssllib.slib,bsilib.slib) // EXEC BSTTWAIT,SIZE=BSTTWAIT /* // EXEC BSTTATLS,SIZE=BSTTATLS ID 00 * KEYRING PRD2.CONFIG DNAME MYCERT SECTYPE TLSV1 * * Convert outbound SMTP connections to Implicit-SMTPS * but only connections to SMTP.GOOGLE.COM OPTION CLIENT ATTLS 25 TO SMTP.GOOGLE.COM AS 465 SSL * * Convert Implicit-TELNETS connections to TELNET OPTION SERVER ATTLS 23 AS 992 SSL * * Convert Implicit-HTTPS connections for CICS TS CWI OPTION SERVER ATTLS 80 AS 443 SSL * * Convert outbound FTP connections to Implicit-FTPS OPTION CLIENT OPTION FTP ATTLS 21 TO FTPS.BSIOPTI.COM AS 990 SSL * * Convert inbound Implicit-FTPS connections to FTP OPTION SERVER OPTION FTP ATTLS 21 AS 990 SSL /*

IPv6/VSE SSL Programming

IPv6/VSE SSL Programming

Before you start writing your application, let's look at how SSL programming works.

The SSL protocol begins with a “handshake.” During the handshake, the client authenticates the server,

the server optionally authenticates the client, and the client and server agree on how to encrypt and

decrypt information.

X.509 certificates are used by both the client and server when securing communications using System

SSL. The client must verify the server's certificate based on the certificate of the Certificate Authority (CA) that signed the certificate or based on a self-signed certificate from the server. The server must verify the client's certificate (if requested) using the certificate of the CA that signed the client's certificate. The client and the server then use the session keys and begin encrypted communications.

Using the IPv6/VSE GSK SSL API

The figure on the next page describes the basic structure of the elements needed in your System SSL source program. These elements are:

1. A socket() call to obtain a socket descriptor.
2. A gsk_initialize() call to set up the application's environment for secure communications. In most cases, this means extracting and verifying the certificate from the specified key database file to be used by the application (to eventually authenticate itself to the peer system in later processing).
3. Socket calls to activate a connection (a connect() call for a client program or bind(), listen(), and
   accept() calls for a server program).
4. A gsk_secure_soc_init() call to initiate the SSL handshake negotiation of the cryptographic
   parameters. gsk_secure_soc_init() initiates the handshaking process. The z/VSE application
   programmer does not have to write the "handshaking" function. This is a function of the SSL support. gsk_secure_soc_init() makes calls to the user supplied *skwrite() and *skread() routines.
5. A gsk_secure_soc_write() call to encrypt data and pass it to the user supplied *skwrite() routine for transmission.
6. A gsk_secure_soc_read() call to read data by calling the user supplied *skread() routine, to decrypt the data, and to return the decrypted data.
7. A gsk_secure_soc_close() call to disable System SSL support for the socket.
8. A close() call to destroy the connected sockets.
   
   
   
   

SSL Handshaking

The type of SSL handshake used determines the level of security used in the connection. 

Normally a server application uses handshake mode 1 and a client application uses handshake mode 0. This type of handshaking is normally used by a web browser connecting to a web server. The type of connection created is both secure (encrypted) and trusted (authenticated via certificates). However, often certificate authentication is not necessary if all you are interested in is a secure (encrypted) connection. In this case, the client application would use handshake mode 3.  This type of SSL connection is used by a TN3270E client connecting via SSL to an SSL proxy server. The connection is secure (encrypted) but not trusted (in the SSL sense of the word). Trust is not necessary since the user will be logging on to a host application and the host application (CICS) will authenticate the user.

Handshake	Description
GSK_AS_CLIENT: (0)	Client receives server's public key and cert. Client authenticates server's public key and cert. Client checks its local CA-cert file to authenticate. DNAME = Dummy RSA key and CA-cert for authentication *(1)
GSK_AS_SERVER: (1)	Server sends its public key and cert to client. DNAME = Public RSA key and cert *(1)
GSK_AS_SERVER_WITH_CLIENT_AUTH: (2)	Server sends its public key and cert to client. Client authenticates server's public key and cert. Client checks its local CA-cert file to authenticate. DNAME = public RSA key and cert AND CA-cert for authentication Client sends its public key and cert to server. Server authenticates client's public key and cert. Server checks its local CA-cert file to authenticate. DNAME = public RSA key and cert AND CA-cert for authentication
GSK_AS_CLIENT_NO_AUTH: (3)	Client receives server's public key and cert. Client accepts server's pubic key and cert without authentication. DNAME not used! no RSA key or cert required.

*(1) In the case of a server and client running on the same system they can use the same DNAME file (identical RSA key and cert - self-signed).

A typical web (HTTP) server is (1) and the browser is (0).

CICS TS web services with client authentication is (2).

SSL tunneling (SMTPS or TELNETS) is a (3) connecting to a (1).

IPv6/VSE provides access to secure sockets (SSL) through the LE/C, EZASMI and EZASOKET APIs. The various GSK function calls provide simple access to OpenSSL secure socket routines.

For information about calling OpenSSL routines directly please refer to the IBM OpenSSL programming manual. Directly calling OpenSSL routines is available only to C language applications.

For detailed information about the EZASMI GSK macro calls and HLL EZASOKET GSK calls, refer to the IBM z/OS System Secure Sockets Layer Programming SC24-5901-00 manual.

GSK Functions Provided

Function	Description
GSKINIT	GSK Initialize
GSKSSOCINIT	GSK Secure Socket Initialize
GSKSSOCREAD	GSK Secure Socket Read
GSKSSOCWRITE	GSK Secure Socket Write
GSKSSOCCLOSE	GSK Secure Socket Close
GSKSSOCRESET	GSK Secure Socket Reset
GSKUNINIT	GSK Uninitialize
GSKFREEMEM	GSK Free Memory
GSKGETCIPHINF	GSK Get Cypher Information
GSKGETDNBYLAB	GSK Get DName By Label

Basic Design

Non-SSL Simple Server	Non-SSL Client
EZASMI TYPE=INITAPI EZASMI TYPE=SOCKET EZASMI TYPE=BIND ACPT EZASMI TYPE=ACCEPT READ EZASMI TYPE=READ EZASMI TYPE=WRITE B READ EOD EZASMI TYPE=CLOSE (Accept socket) B ACPT EOJ EZASMI TYPE=CLOSE (Listen socket) EZASMI TYPE=TERMAPI EOJ	EZASMI TYPE=INITAPI EZASMI TYPE=SOCKET EZASMI TYPE=CONNECT EZASMI TYPE=WRITE EZASMI TYPE=READ EZASMI TYPE=CLOSE EZASMI TYPE=TERMAPI EOJ
SSL Simple Server	SSL Simple Client
EZASMI TYPE=INITAPI EZASMI TYPE=GSKINIT EZASMI TYPE=SOCKET EZASMI TYPE=BIND ACPT EZASMI TYPE=ACCEPT EZASMI TYPE=GSKSSOCOPEN READ EZASMI TYPE=GSKSSOCREAD EZASMI TYPE=GSKSSOCWRITE B READ EOD EZASMI TYPE=GSKSSOCCLOSE EZASMI TYPE=CLOSE (Accept socket) B ACPT EOJ EZASMI TYPE=CLOSE (Listen socket) EZASMI TYPE=GSKUNINIT EZASMI TYPE=TERMAPI EOJ	EZASMI TYPE=INITAPI EZASMI TYPE=GSKINIT EZASMI TYPE=SOCKET EZASMI TYPE=CONNECT EZASMI TYPE=GSKSSOCOPEN EZASMI TYPE=GSKSSOCWRITE EZASMI TYPE=GSKSSOCREAD EZASMI TYPE=GSKSSOCCLOSE EZASMI TYPE=CLOSE EZASMI TYPE=GSKUNINIT EZASMI TYPE=TERMAPI EOJ

See the IPv6/VSE SSL Installation, Programming and User's Guide for full details on the SSL GSK API.

Using the BSI SSL Proxy Server

BSTTPRXY SSL Proxy Server

The BSTTPRXY SSL proxy server allows non-SSL server applications running in z/VSE to accept connections from SSL based client applications. Or, BSTTPRXY will allow non-SSL client applications to connect to SSL based server applications.

The BSTTPRXY SSL proxy server will also proxy IPv4 connections to an IPv6 destination or IPv6 connections to an IPv4 destination.

Proxy Types

Source	Destination
Accept clear text connection	Proxy to clear text connection
Accept SSL connection	Proxy to SSL connection
Accept clear text connection	Proxy to SSL connection
Accept SSL connection	Proxy to clear text connection
Accept IPv4 or IPv6 connection	Proxy to IPv4 or IPv6 connection

Proxy Examples

Accept a clear text connection from BSTTMTPC on port 25 and proxy the connection to an SMTP server listening on SSL port 465. This type of connection is commonly called smtps.

Accept an SSL connection on port 443 and proxy the connection to CICS TS Web Services on clear text port 80. This type of connections commonly called https.

Accept an SSL connection on port 992 and proxy the connection to the BSTTVNET TN3270E server on clear text port 23. This type of connection is commonly called telnets.

Accept a clear text connection from BSTTFTPC on port 21 and proxy the connection to an FTP server listening on SSL port 990. This type of connection is commonly called ftps.

Accept an SSL connection on port 990 and proxy the connection to the BSTTFTPS FTP server on clear text port 21. This type of connection is commonly called ftps.

BSTTPRXY Examples

BSTTVNET TN3270E Server

x3270
x3270 is an IBM 3270 terminal emulator for the X Window System and Windows. It runs on most Unix-like operating systems -- e.g., Linux, Mac OS X, Solaris and Cygwin. It also runs natively on Windows.
X3270 is distributed as source code, and can be used for free. See http://x3270.bgp.nu

x3270 runs over a TELNET connection, emulating either an IBM 3279 (color) or 3278 (monochrome). It supports:

• The full TN3270E protocol
• SSL/TLS (via the OpenSSL library) for encrypted sessions
• APL2 characters
• Non-English character sets, including Hebrew and DBCS Chinese and Japanese
• IND$FILE file transfer
• NVT mode (emulating a color xterm)
• A pop-up keypad for 3270-specific keys
• A scrollbar
• Printer session integration
• Extensive debugging and scripting facilities

Command format: X3270 [prefix:]...[LUname@]hostname[:port] E.g., x3270 L:192.168.1.238:992

Prepending an L: onto hostname causes x3270 to first create an SSL tunnel to the host, and then create a TN3270 session inside the tunnel.

// OPTION SYSPARM='66' // SETPARM IPTRACE='NNNNNNN' // LIBDEF *,SEARCH=(ssllib.slib,bsilib.slib) // EXEC BSTTPRXY,SIZE=BSTTPRXY ID 66 KEYRING PRD2.CONFIG DNAME BSICERT SECTYPE TLSV1 OPTION SERVER PROXY TCP V4 992 SSL * TO V4 23 TXT * LOCALHOST /*

The above example executes the BSTTPRXY SSL proxy server in SERVER mode, accepting SSL connections on port 992 (implicit telnets) and proxies the connection in clear text to port 23. Port 23 is being used by BSTTVNET to accept connections to the TN3270E server.

The KEYRING parameter indicates the RSA key and certificate to be used by the BSTTPRXY server is located in PRD2.CONFIG and the DNAME parameter indicates BSICERT.PEM is the member name.

BSTTMTPC Mail Transport Client

The following sample JCL shows BSTTMTPC connecting to the BSTTPRXY server on port 25 (SMTP) and sending an email.

// EXEC BSTTMTPC,SIZE=BSTTMTPC ID 00 OPEN 127.0.0.1 25 * EHLO gmail.com AUTH LOGIN jeffrey.webmail ???????? MAIL From: RCPT To: SUBJ Subject: Test Email ORGA Organization: Barnard Software, Inc. * DATA * QUIT /* This is a test email text. See http://www.bsiopti.com Jeff /*

The following sample BSTTPRXY JCL shows the proxy server accepting connections on port 25 (SMTP) and proxying the connection to smtp.gmail.com port 465. This configuration uses SMTPS or SMTP through an SSL tunnel. Note: The KEYFILE parameter must specify an RSA key/certificate member with a valid RSA key and certificate. However, the certificate is not used.

// EXEC BSTTPRXY,SIZE=BSTTPRXY,PARM='TRAP(OFF)/' ID 00 * KEYRING PRD2.CONFIG KEYFILE ZVSE51 SECTYPE TLSV1 * OPTION CLIENT * 74.125.157.108 IS SMTP.GMAIL.COM PROXY TCP V4 25 TXT * TO V4 465 SSL * 74.125.157.108 /*

CICS TS Web Interface

The following sample BSTTPRXY JCL shows the proxy server accepting connections on port 443 (HTTPS) and proxying the connection to the CICS TS Web Server on port 8080.

// EXEC BSTTPRXY,SIZE=BSTTPRXY,PARM='TRAP(OFF)/' ID 00 * KEYRING PRD2.CONFIG KEYFILE CICSTS SECTYPE TLSV1 * OPTION SERVER * PROXY TCP V4 443 SSL * TO V4 8080 TXT * 127.0.0.1 /*

BSTTFTPC Batch FTP Client

The following sample JCL shows BSTTFTPC connecting to the BSTTPRXY server on port 2121 (FTP) and sending commands to a remote host FTP server on port 990(FTPS). BSTTPRXY supports Implicit-FTPS where the command connection is automatically encrypted using TLS.

// EXEC BSTTFTPC,SIZE=BSTTFTPC,OS390,TASKS=ANY ID 00 OPEN 127.0.0.1 2121 PBSZ 0 PROT P USER jcb PASS bsi PWD STAT QUIT /*

The BSTTFTPC JCL/commands looks pretty typical but notice the PBSZ 0 and PROT P commands that immediately follow the OPEN command. These two commands, exactly as shown, must immediately follow the OPEN command. When using an Implicit-FTPS connection the command connection is automatically encrypted. The PBSZ 0 and PROT P commands tell the remote host FTP server that any data transfer done should also be encrypted. If these two commands are missing any data transfer will be done in clear text mode.


The following sample BSTTPRXY JCL shows the proxy server accepting connections on port 2121 (FTP) and proxying the connection to 192.168.1.60 port 990. This configuration uses FTPS or FTP through an implicit SSL tunnel. Note: The KEYFILE parameter must specify an RSA key/certificate member with a valid RSA key and certificate. Port mapping, for the FTP data connection, is handled automatically by BSTTPRXY.

// EXEC BSTTPRXY,SIZE=BSTTPRXY,PARM='TRAP(OFF)/' ID 00 * KEYRING PRD2.CONFIG KEYFILE BSICERT SECTYPE TLSV1 * OPTION FTP OPTION CLIENT * PROXY TCP V4 2121 TXT * TO V4 990 SSL * 192.168.1.60 /*

BSTTFTPS FTP Server

The following sample BSTTPRXY JCL shows the proxy server accepting connections on port 990 (Implicit-FTPS) and proxying the connection to 192.168.1.60 port 21 (FTP). This configuration uses FTPS or FTP through an implicit SSL tunnel. Note: The KEYFILE parameter must specify an RSA key/certificate member with a valid RSA key and certificate. Port mapping, for the FTP data connection, is handled automatically by BSTTPRXY.

// EXEC BSTTPRXY,SIZE=BSTTPRXY,PARM='TRAP(OFF)/' ID 00 * KEYRING PRD2.CONFIG KEYFILE BSICERT SECTYPE TLSV1 * OPTION SERVER * PROXY TCP V4 990 SSL * TO V4 21 TXT * 127.0.0.1 /*

This example assumes you also are running the BSTTFTPS FTP server listening on port 21.
To test this function of BSTTPRXY we used the Linux LFTP FTP client. The LFTP client connected to BSTTPRXY using the 'lftp -d -u userid,password -p 990 ftps://192.168.1.238' command. The LFTP client connected to the BSTTPRXY server using an SSL connection on port 990. BSTTPRXY then proxied the connection to the BSTTFTPS FTP server on port 21.

The IPv6/VSE SSL proxy server is simple and easy to use. In addition to the examples shown in this post, many other types of connections can be proxied including MQSeries, DB2 UDB connections, etc.

SSL Support in IPv6/VSE

SSL Support in IPv6/VSE

Barnard Software, Inc. is pleased to announce that their IPv6/VSE product now provides SSL (Secure Socket Layer) support! Our new SSL support became available with GA Build 252. GA Build 252 is now available on our download page.

The initial release of IPv6/VSE did not contain any cryptographic facilities. During the 2011 GSE conference last October, in Berlin Germany,. BSI made a Statement of Direction indicating the SSL and IPSec features would be added to IPv6/VSE. 

IPv6/VSE SSL facilities will be released in two phases. 

Phase One will provide the BSI SSL Proxy Server that runs in a z/VSE partition. The BSTTPRXY server application will provide support for telnets (TN3270E over SSL), SMTPS (SMTP over SSL), HTTPS (HTTP over SSL) and FTPS (Implicit FTP over SSL) and more. IPv6/VSE also provides the SSL GSK API for use by customer and 3rd party vendor software. The GSK API is available using EZASOKET/EZASMI or LE/C interfaces. The only restriction is that this API is currently only available to LE batch applications. 

For IPv6/VSE users running on z/VSE 5.1 (or higher) support is provided for CPACF hardware cryptographic instructions and Crypto-Express adapters to improve performance.

Phase Two will remove the LE requirement providing support for both batch and CICS applications We also plan to provide explicit (Built in) SSL support for BSTTVNET (TN3270E server), BSTTMTPC (SMTP Client), BSTTFTPS (FTP server) and BSTTFTPC (batch FTP client).

Phase One of IPv6/VSE's SSL support is now available!

System Requirements

IPv6/VSE's Secure Sockets Layer (SSL) support uses the IBM z/VSE OpenSSL1.0.0 port. The IBM OpenSSL port was done using z/VSE C/VSE compiler permitting support for back level versions of z/VSE and VSE/ESA. The OpenSSL port became available with z/VSE 5.1. BSI IPv6/VSE customers have special options to enable IPv6/VSE's SSL support on back level releases of VSE/ESA and z/VSE. 

CPACF

The IBM OpenSSL port will take advantage of the System z's CP Assist for Cryptographic Function (CPACF) when running under z/VSE 5.1 (or higher). These CP Assists dramatically reduce CPU overhead involved when using cryptographic functions. Users of the z890, z990, z9, z10, z114, z196 (and newer processors) should have the no-charge enablement feature installed. This feature must be ordered to enable CPACF. z/VSE systems without CPACF will use system CPU resources to perform cryptographic functions.

Crypto Express Adapters

The IBM OpenSSL port will take advantage of the System z Crypto Express adapters supported by z/VSE 5.1 (or higher). Usage of Crypto Express adapters dramatically reduces the amount of CPU required to establish a secure socket connection. z/VSE 51 (or higher) systems without Crypto Express adapters  (or back level systems) will use system CPU resources to establish a secure socket connection.

Restrictions

Currently the IPv6/VSE SSL suport is in Phase One. Any application can make use the IPv6/VSE SSL Proxy server. This includes both batch and CICS, LE and non-LE applications. Also, any user or 3rd party LE conforming batch application can use the EZASOKET/EZASMI or LE/C GSK SSL API provided by IPv6/VSE. Non-LE based batch applications, CICS/VSE and CICS TS applications are currently not supported by the Phase I GSK SSL API. This restriction will be removed in a future build.

BSTTPRXY SSL Proxy Server

The BSTTPRXY SSL proxy server allows non-SSL server applications running in z/VSE to accept connections from SSL based client applications. Or, BSTTPRXY will allow non-SSL client applications to connect to SSL based server applications.

Proxy Types

Source	Destination
Accept clear text connection	Proxy to clear text connection
Accept SSL connection	Proxy to SSL conneIPv6/VSE SSL Supportction
Accept clear text connection	Proxy to SSL connection
Accept SSL connection	Proxy to clear text connection
Accept IPv4 or IPv6 connection	Proxy to IPv4 or IPv6 connection

Proxy Examples

Accept a clear text connection from BSTTMTPC on port 25 and proxy the connection to an SMTP server listening on SSL port 465. This type of connection is commonly called smtps.

Accept an SSL connection on port 443 and proxy the connection to CICS TS Web Services on clear text port 80. This type of connections commonly called https.

Accept an SSL connection on port 992 and proxy the connection to the BSTTVNET TN3270E server on clear text port 23. This type of connection is commonly called telnets.

Accept a clear text connection from BSTTFTPC on port 21 and proxy the connection to an FTP server listening on SSL port 990. This type of connection is commonly called ftps.

Accept an SSL connection on port 990 and proxy the connection to the BSTTFTPS FTP server on clear text port 21. This type of connection is commonly called ftps.

IPv6/VSE SSL Support

There you have it. IPv6/VSE SSL support is now available and supports SSL sockets for virtually any z/VSE application.

IPv6/VSE

IPv6/VSE

IPv6 news is everywhere these days. The availability of z/VSE 4.2.2 (and newer releases) provides the foundation of z/VSE's IPv6 support. Combine this with IBM's new TCP/IP solution, IPv6/VSE, which provides a single product solution for both IPv4 and IPv6 TCP/IP communications and you have a powerful way to take z/VSE into the future.


You are probably already hearing about IPv6 on z/VSE. Why? Your ISP is converting to IPv6 and makes it available to you. With the IPv4 address block exhaustion, new blocks of IPv4 addresses are now almost impossible to get. Your customers or business partners require IPv6 connections. Government organizations may only allow IPv6 capable devices and applications to participate in bidding. The US Department of Defense (DoD), for example, only allows products that are on the “Unified Capabilities Approved Products List” (UC APL) for its advertised bidding. This list is used by procurement offices in the DoD and the U.S. Federal agencies for ongoing purchases and acquisitions of IT equipment. Also, keep this in mind, as new standards are developed IPv6 is usually mandated. For example, 4G mobile devices are mandated to use IPv6 and IPv4 support is deprecated.


IPv6 support in z/VSE began with z/VSE 4.2.2.

IBM IPv6/VSE Version 1 Release 1

IBM licensed IPv6/VSE from Barnard Software, Inc.for worldwide distribution as their TCP/IP product solution for the future (IPv6/VSE is a registered trademark of Barnard Software, Inc.). IBM's IPv6/VSE announcement (210-066) was made on April 6, 2010. The availability of IBM's IPv6/VSE allows z/VSE users to participate in an IPv6 network and bring the benefits of IPv6 functionality to z/VSE users.


While the product is named IPv6/VSE, the product supports both IPv4 and IPv6 communications. IPv6/VSE provides a full-function IPv4 stack and applications as well as a full-function IPv6 stack and applications. Both TCP/IP stacks (IPv4 and IPv6) can be run together, individually or even stand alone. IBM's IPv6/VSE supports both IPv4 and IPv6 protocols and has been available since May 28, 2010.



IPv6/VSE IPv4 and IPv6 Support

IPv6/VSE Application	IPv4 Support	IPv6-Enabled	Description
BSTTFTPS	Yes	Yes	FTP Server
BSTTFTPC	Yes	Yes	FTP Client
BSTTVNET	Yes	Yes	TN3270E Server with DIRECT/LPR printing
BSTTNTPS	Yes	Yes	Network Time Protocol Server
BSTTNTPC	Yes	Yes	Network Time Protocol Client
BSTTSLOG	Yes	Yes	System Logger Client
BSTTMTPC	Yes	Yes	Mail Transport Protocol Client
BSTTREXC	Yes	Yes	Remote Execution Client
BSTTPING	Yes	Yes	Batch PING Utility
BSTTGZIP	Yes	Yes	GZIP Data Compression
REXX Automation	Yes	Yes	REXX Automation Support

IPv6/VSE Support for IBM Applications

Application	Supported by IPv6/VSE
CICS TS Web Services	Yes
CICS TS Listener	Yes
VTAPE	Yes
Connector Server	Yes
DB2 Server and DB2 Client	Yes
MQSeries	Yes
MQ Client	Yes
PSF/VSE	Yes
Linux Fast Path	Yes
VSAM Redirector	Yes
VSE Health Checker	Yes
VSE Script Server	Yes
VSE Navigator	Yes

Virtually all 3^rd party software vendors are now working with IPv6/VSE and support their customers using IPv6/VSE with their products.

IPv6 Programming Interfaces

Existing APIs have been extended. The Assembler SOCKET macro API has been extended to support IPv6 addressing and 64-bit virtual storage addresses. The EZASOKET and EZASMI API have also been extended. EZASOKET/EZASMI support for GETADDRINFO, FREEADDRINFO, NTOP and PTON with the new address family of AF_INET6 is available. Of course, the LE/C Socket API has been IPv6-enabled too.


The IBM IPv6/VSE Programming Guide has all the details on the IPv6-enablement features in these API's.

SSL and IPSec

During the 2011 GSE conference (October 2011 in Berlin Germany) Barnard Software, Inc. (BSI) issued a Statement of Direction that indicated BSI would make available both SSL and IPSec solutions for IPv6/VSE in a future release. At the time of the writing of this article the SSL support was undergoing beta test. Availability of these additions to IPv6/VSE is expected to become generally available (GA) during 2012.

Summing it up

There you have it. z/VSE is IPv6 ready with IBM's IPv6/VSE. IBM's IPv6/VSE provides both a full-function IPv4 stack and applications as well as a full-function IPv6 stack and applications. IPv6/VSE is a single product providing a complete solution, TCP/IP stacks, IPv6-enabled applications and programming interfaces. With IPv6/VSE your z/VSE system is IPv4 and IPv6 ready to go.