When I started putting in SSLSERV, I did it in a completely separate
stack (TCPTEST, SSLSERV, FTPTEST). When everything was working, I
migrated SSLSERV into the production stack with TN3270 available on 2
ports (cleartext on 23, secure on 992). Then we set the deadline for our
users to get secure clients. Eventually, we turned off port 23. Between
those two events, I used the TCPTEST stack without SSLSERV to experiment
with hypersockets between our z/VM LPARS. I now have the z/VM LPARs
connected by hypersockets with no SSLSERV, since only internal systems
connect to the hypersockets. This way if TCPIP is down on my LPAR1, I
can tn3270 into LPAR2, log onto my userid there and TELNET to LPAR2
using TCPHSF (server for hypersocket). We also have VTAM connecting the
z/OS LPARs with z/VM LPAR1 so I can get in that way too.
If I only ha ONE LPAR, I would have two TCPIP stacks, both with SSLSERV,
but the second one only supporting tn3270. Both tacks would be up ALL
the time but only the first one would be advertised for the general
users. The second stack would be for the support staff and would be
subject to maintenance and reboot whenever needed.
/Tom Kern
Alan Ackerman wrote:
We have been ordered to protect all TN3270 sessions to VM with SSL. This
means turning on SSLSERV and disabling non-SSL. (INTERNALCLIENTPARMS
SECURECONNECTION REQUIRED, I think.) IBM level 2 has suggested that other
shops have a second TCP/IP stack to use when there are problems with TCPIP
or SSLSERV. (We have found several problems with SSLSERV in our testing.)
I'm curious whether and how other shops use a second TCP/IP stack.
Some possibilities:
1. Have a second TCPIP stack up all the time (userids TCPIP2 and
MPROUTE2), but with no SSL. It would run on a second IP address. (This is
security by obscurity.)
2. Have a second TCPIP stack up all the time, with SSL required. (Userids
TCPIP2, MPROUTE2, SSLSERV2.) This takes 2-3 more 3390-3 packs per system,
as well as a second IP address for each. (We have 6 first-level VM
systems, so those packs add up. There is also the administrative time to
get new certificates, etc.)
3. Have a second TCPIP stack, kept down, with no SSL, but brought up by
operations when we request it. It would have a second IP address. (So we
could test without bringing down the other TCPIP stack.)
4. Have a second TCPIP stack, kept down, with no SSL, but brought up by
operations when we request it. Assume the first stack is down and steal
the IP address. We could only test during stand-alone time.
We do have a seond way to get into our systems, a PC-based product called
AP View. It has been unreliable here, and in some cases we have to ask
operations to page the AP View support, either becsaue it is not working
or because we are only allowed Read/Only access via AP View to some (the
most important, naturally) VM systems. This slows down recovery.
We are trying to get rid of VTAM. (Actually, we are waiting for the z/OS
folks on this.) So that is not a good alternative.
Alan Ackerman
Alan (dot) Ackerman (at) Bank of America (dot) com
