Alan didn't mention that we're a large shop, and most of the mainframes
are 2000 miles away from the programmers. One of them is on the other
side of the Atlantic. KVM switches and HMC access aren't going to work.
I looked for information on SSL support in OSA-ICC and didn't find any.
The Redbook I did find, SG24-6364-01, OSA-Express Integrated Console
Controller Implementation Guide, doesn't mention SSL, but does say that
the client PC's must use static IP addresses, not DHCP. That's not
going to work here, either. Even if those of us who aren't
telecommuters could get static IP addresses at the office, when we're
working from home, we go through a VPN server that assigns a new IP
address every time we connect to it.
An SSL server appliance might be approved by our Information Security
people, but it's not certain. Their standard requires "end-to-end"
encryption. Even if it's approved, we'd need at least two of them for
redundancy, and the cost is likely to exceed the cost of running z/VM's
SSL server.
We are aware of the session limits in the GA SSL server. I think our
choices will boil down to keeping a second stack up all the time with
SSL, or having a second stack that's only brought up for emergencies
without SSL. What choices have other shops made?
Dennis
"A society that gets rid of all its troublemakers goes downhill." --
Robert A. Heinlein
-----Original Message-----
From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On
Behalf Of [EMAIL PROTECTED]
Sent: Thursday, April 17, 2008 09:03
To: [email protected]
Subject: Re: [IBMVM] Second TCPIP stack and SSL
Our network went down overnight, so I couldn't connect to the mainframe
through my PC this morning. I hit the KVM switch tucked behind my
monitor and connected to the mainframe through the PC connected to the
ICC LAN. Is this a possible solution for you for emergency access?
Peter
-----Original Message-----
From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On
Behalf Of Alan Ackerman
Sent: April 16, 2008 19:27
To: [email protected]
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
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
The information transmitted is intended only for the person or entity to
which it is addressed and may contain confidential and/or privileged
material. Any review retransmission dissemination or other use of or
taking any action in reliance upon this information by persons or
entities other than the intended recipient or delegate is strictly
prohibited. If you received this in error please contact the sender and
delete the material from any computer. The integrity and security of
this message cannot be guaranteed on the Internet. The sender accepts
no liability for the content of this e-mail or for the consequences of
any actions taken on the basis of information provided. The recipient
should check this e-mail and any attachments for the presence of
viruses. The sender accepts no liability for any damage caused by any
virus transmitted by this e-mail. This disclaimer is property of the
TTC and must not be altered or circumvented in any manner.
