Unless anything has changed, SSLSERV is a non-starter if you have more than 126 concurrent sessions. Aside from that, it is very stable with the latest patches (our VM is 520). An alternative is to get your VM behind a network firewall, then get an SSL device like Illustro's to protect all your telnet sessions. Port 23 telnet on VM stays open behind the firewall and only the SSL device can get to it. No second stack is needed and the SSL device handles all the encryption overhead.
Ray Mrohs -----Original Message----- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Alan Ackerman Sent: Wednesday, April 16, 2008 7:27 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Second TCPIP stack and SSL 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 TCPI= P 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
