Re: MIPS for SSLSERV

[Alan Altmark]

On Friday, 10/19/2007 at 08:06 EDT, Alan Ackerman 
<[EMAIL PROTECTED]> wrote:

> What I see is:
> 
> Error 0x800b0109 (CERT_E_UNTRUSTEDROOT) returned by
> CertVerifyCertificateChainPolicy!
> Connected to 171.177.29.52 port 6443
> from 171.184.0.226 port 2027
> ...
> 
> The error is because we are using a self-signed certificate for testing.

There may be an option in QWS3270 to accept those automatically or prompt 
you. 

> Even if I figure out whether it can resume or not, I don't know any way 
to
> determine the number of new connections versus resumes. Is there 
anything
> in a console log that shows this? Or monitor record?

The SSL server does not generate monitor records and there are no messages 
that would indicate a resume.

Alan Altmark
z/VM Development
IBM Endicott

Re: MIPS for SSLSERV

[Alan Ackerman]

On Thu, 18 Oct 2007 19:31:16 -0400, Steve Bireley 
<[EMAIL PROTECTED]> wrote:

>Hi Alan,
>For telnet, the SSL session resume is insignificant since the sessions 

last so long.  Further, interactive sessions typically result in very 
little traffic because users type slowly and the 3270 datastream is prett
y 
efficient.  We have a SSL proxy product that handles 1000's of users and 

uses very little CPU (Windows OS).  We do get spikes in CPU usage when 

something happens on the network that disconnects 100's of users, who the
n 
reconnect simultaneously.  That is rare though.
>
>Steve Bireley
>BlueZone Software
>www.bluezonesoftware.com

I think you are probably right.

According to the z/VM performance report, a new session connect takes 
about 3x as many CPU cycles as a reconnect. That was why I was concerned.
 

On the other hand, it is beginning to look like these numbers are trivial
.

The highest cost given, for new session connects and 1024-bit keys, is 84
 
ms total CPU on a 2064-109. My peak rate (on one of our 5 VM systems) 
appears to be 50 connects per HOUR:

50 * 84.0 / (60*60) / 1000 = 0.00117 = 0.117% of one engine of a 2064
-109

0.00117 * 174 MIPS = 0.20 MIPS

(Does that look right?)

Assuming

ModelMIPS  MIPS/processor
2064-109 1563  174

MIPS Source: Technology News


I haven't included the costs of the actual data transfer, because I don't
 
know how to get the number of bytes, but it may also be trivial.

Re: MIPS for SSLSERV

[Alan Ackerman]

On Thu, 18 Oct 2007 17:54:32 -0400, Alan Altmark <[EMAIL PROTECTED]
> 
wrote:

>On Thursday, 10/18/2007 at 04:07 EDT, Alan Ackerman
><[EMAIL PROTECTED]> wrote:
>
>> We don't have PCOMM, but QWS3270 Secure, so I don't know what our
>> situation will be.  [re: Resumed SSL sessions]
>
>If you get a trace (e.g. Wireshark or something built into QWS3270) you
>can see if sessions are resuming by looking at the SSL/TLS handshake.  I
f
>you see CLIENT KEY EXCHANGE, you know a session was NOT resumed.
>
>Alan Altmark
>z/VM Development
>IBM Endicott
>
=


I used the QWS3270 Secure trace. I don't see that message, even the first
 
time.

What I see is:

Error 0x800b0109 (CERT_E_UNTRUSTEDROOT) returned by 
CertVerifyCertificateChainPolicy!
Connected to 171.177.29.52 port 6443
from 171.184.0.226 port 2027

(Actual session.)
(LOGOFF with Automatically Re-Connect selected, which gives me a LOGO 
screen.)

Connection to vmdev2 closed
Error 0x800b0109 (CERT_E_UNTRUSTEDROOT) returned by 
CertVerifyCertificateChainPolicy!
Connected to 171.177.29.52 port 6443
from 171.184.0.226 port 2028

The error is because we are using a self-signed certificate for testing.

Even if I figure out whether it can resume or not, I don't know any way t
o 
determine the number of new connections versus resumes. Is there anything
 
in a console log that shows this? Or monitor record?

Re: MIPS for SSLSERV

[Steve Bireley]

Hi Alan,
For telnet, the SSL session resume is insignificant since the sessions last so 
long.  Further, interactive sessions typically result in very little traffic 
because users type slowly and the 3270 datastream is pretty efficient.  We have 
a SSL proxy product that handles 1000's of users and uses very little CPU 
(Windows OS).  We do get spikes in CPU usage when something happens on the 
network that disconnects 100's of users, who then reconnect simultaneously.  
That is rare though.

Steve Bireley
BlueZone Software
www.bluezonesoftware.com




From: The IBM z/VM Operating System [EMAIL PROTECTED] On Behalf Of Alan 
Ackerman [EMAIL PROTECTED]
Sent: Thursday, October 18, 2007 4:05 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: MIPS for SSLSERV

On Wed, 17 Oct 2007 10:43:51 -0400, Steve Bireley
<[EMAIL PROTECTED]> wrote:

>The most expensive part of the connection is the public key exchange
during the SSL negotiation.  This negotiation occurs every time the
control or data port is opened.  In a multiple file transfer scenario,
each file transfer results in the data port being opened and closed.  Many
small files being transferred should use more CPU than one large file
being transferred.  I am not sure if SSLServ supports session caching
(reuse of the session keys) to lessen the CPU impact of the key exchange,
or if the FTP clients can even support it.  I will check the RFC for that.
>
>Steve Bireley
>Vice-President
>Product Development
>BlueZone Software
>1-404-364-1731
>www.bluezonesoftware.com
>"BlueZone Secure FTP is now Free"
>

I'm concerned with TN3270, not FTP, but I think the principle is the same.

The Performance Report says about session caching:

"Telnet Connect/Disconnect

The SSL protocol allows a cache of recently generated handshake output in
order to eliminate much of the handshake overhead in cases
where a given client makes repeated connections. The first time the client
connects, the client and server go through the complete
handshake and the resulting handshake output (session id plus associated
information) is saved in the server's cache. This is referred to
as a new session. The next time that client connects, it may pass the
session id to the SSL server and if a valid copy of it is found in the
server's cache, most of the handshake is bypassed. This case is referred
to as a resumed session.

Whether or not this resumed session optimization is used is up to the
client. Clients that include connect/disconnect in their mainline
path (such as http browsers) are likely to use this optimization. Clients
such as FTP and Telnet that establish a connection and then use
it for a (potentially) long conversation are less likely to support this
optimization. It turns out that IBM's eNetwork Personal Communications
terminal emulator application (PCOMM) does both. When a disconnect and
connect are done manually from the
Communication menu, the optimization is not used and consequently all
sessions are new sessions. When the disconnect is done
implicitly by logging off the remote system and the auto-reconnect option
is checked, the optimization is used and all sessions except
the first are resumed sessions. This characteristic allowed us to measure
both the new and resumed cases."

We don't have PCOMM, but QWS3270 Secure, so I don't know what our
situation will be.

It appears I can count conntects simply by counting these messages in the
TCPIP service machine log:

DTCSTM163I Telnet server: Conn 1:Connection opened 10/18/07 at 00:19:08
DTCPRC150IForeign internet address and port:  net address =
165.44.75.39, port= 1774
DTCSTM132I Conn 1: Ldsf device 000A created

Alan Ackerman
Alan (dot) Ackerman (at) Bank of America (dot) com

Re: MIPS for SSLSERV

[Alan Altmark]

On Thursday, 10/18/2007 at 04:07 EDT, Alan Ackerman 
<[EMAIL PROTECTED]> wrote:

> We don't have PCOMM, but QWS3270 Secure, so I don't know what our
> situation will be.  [re: Resumed SSL sessions]

If you get a trace (e.g. Wireshark or something built into QWS3270) you 
can see if sessions are resuming by looking at the SSL/TLS handshake.  If 
you see CLIENT KEY EXCHANGE, you know a session was NOT resumed.

Alan Altmark
z/VM Development
IBM Endicott

Re: MIPS for SSLSERV

[Alan Ackerman]

On Wed, 17 Oct 2007 10:43:51 -0400, Steve Bireley 
<[EMAIL PROTECTED]> wrote:

>The most expensive part of the connection is the public key exchange 
during the SSL negotiation.  This negotiation occurs every time the 
control or data port is opened.  In a multiple file transfer scenario, 

each file transfer results in the data port being opened and closed.  Man
y 
small files being transferred should use more CPU than one large file 
being transferred.  I am not sure if SSLServ supports session caching 
(reuse of the session keys) to lessen the CPU impact of the key exchange,
 
or if the FTP clients can even support it.  I will check the RFC for that
.
>
>Steve Bireley
>Vice-President
>Product Development
>BlueZone Software
>1-404-364-1731
>www.bluezonesoftware.com
>"BlueZone Secure FTP is now Free"
>

I'm concerned with TN3270, not FTP, but I think the principle is the same
. 

The Performance Report says about session caching:

"Telnet Connect/Disconnect

The SSL protocol allows a cache of recently generated handshake output in
 
order to eliminate much of the handshake overhead in cases
where a given client makes repeated connections. The first time the clien
t 
connects, the client and server go through the complete
handshake and the resulting handshake output (session id plus associated 

information) is saved in the server's cache. This is referred to
as a new session. The next time that client connects, it may pass the 
session id to the SSL server and if a valid copy of it is found in the
server's cache, most of the handshake is bypassed. This case is referred 

to as a resumed session.

Whether or not this resumed session optimization is used is up to the 
client. Clients that include connect/disconnect in their mainline
path (such as http browsers) are likely to use this optimization. Clients
 
such as FTP and Telnet that establish a connection and then use
it for a (potentially) long conversation are less likely to support this 

optimization. It turns out that IBM's eNetwork Personal Communications 

terminal emulator application (PCOMM) does both. When a disconnect and 

connect are done manually from the
Communication menu, the optimization is not used and consequently all 
sessions are new sessions. When the disconnect is done
implicitly by logging off the remote system and the auto-reconnect option
 
is checked, the optimization is used and all sessions except
the first are resumed sessions. This characteristic allowed us to measure
 
both the new and resumed cases."

We don't have PCOMM, but QWS3270 Secure, so I don't know what our 
situation will be.

It appears I can count conntects simply by counting these messages in the
 
TCPIP service machine log:

DTCSTM163I Telnet server: Conn 1:Connection opened 10/18/07 at 00:19:08
DTCPRC150IForeign internet address and port:  net address = 
165.44.75.39, port= 1774
DTCSTM132I Conn 1: Ldsf device 000A created

Alan Ackerman
Alan (dot) Ackerman (at) Bank of America (dot) com

Re: MIPS for SSLSERV

[Steve Bireley]

The most expensive part of the connection is the public key exchange during the 
SSL negotiation.  This negotiation occurs every time the control or data port 
is opened.  In a multiple file transfer scenario, each file transfer results in 
the data port being opened and closed.  Many small files being transferred 
should use more CPU than one large file being transferred.  I am not sure if 
SSLServ supports session caching (reuse of the session keys) to lessen the CPU 
impact of the key exchange, or if the FTP clients can even support it.  I will 
check the RFC for that.

Steve Bireley
Vice-President
Product Development
BlueZone Software
1-404-364-1731
www.bluezonesoftware.com
"BlueZone Secure FTP is now Free"


-Original Message-
From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Tom 
Duerbusch
Sent: Wednesday, October 17, 2007 10:32 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: MIPS for SSLSERV

I can't say about TN3270, but if you assume that all encryption has the same 
cost (i.e. cost per MB), then:

On SLES10, FTP encryption seemed to become the default vs older Suse systems.
When I FTP iso images now, it takes 4 X the CPU power then the non-encrypted 
version.

This is based on our z/890 IFL.

So, my first guess is 4 times the current cost of your TCPIP stack.

Tom Duerbusch
THD Consulting

FELINE PHYSICS:
Law of Cat Motion

  A cat will move in a straight line, unless there is a really good
  reason to change direction.


>>> Alan Ackerman <[EMAIL PROTECTED]> 10/16/2007 6:01 PM >>>
We have been asked to encrypt all TN3270 traffic to our VM systems (5
LPARS + 14? guests). I am planning to use the VM SSLSERV, running on Red
Hat (RHEL 4) Linux. My management wants me to estimate the MIPS (or CPU
cycles) cost of this. Any ideas?

I can get number of users logged in via TCP/IP via NETSTAT TELNET, so a
per-user cost would be nice, or a total cost and number of logged-in
users, but I will take any estimates you have.

These are CMS users, or users dialing in to VTAM. (Existing Linux guests
are not affected by this, as they already use encrypted TELNET.)

z/VM 5.3.0 (soon) on z9 EC processors. QWS3270 Secure (although I don't
think the PC client makes any difference).

Re: MIPS for SSLSERV

[Alan Ackerman]

On Wed, 17 Oct 2007 00:03:17 -0500, Alan Ackerman 
<[EMAIL PROTECTED]> wrote:

>On Tue, 16 Oct 2007 20:03:07 -0400, David Kreuter <[EMAIL PROTECTED]
resources.com> wrote:
>
>>What else is running through the VM TCPIP stack?
>>What else are you encrypting via TCPIP and SSLSERV?
>>David
>
>Mainly FTP and SMTP.  Some NFS. Some DB2 (DRDA?).
>Nothing else encrypted, although FTP will be next.
>
>I found the z/V performance report. It has lots of numbers for CPU cost 

for Telnet CONNECTS. Any 
>idea how I can get a count of those? It also has FTP cost in bytes, but 

no other Telnet costs.
>
=
===

I forgot to mention the web servers -- probably our biggest load. Nothing
 
there is encrypted.

Re: MIPS for SSLSERV

[Alan Ackerman]

On Wed, 17 Oct 2007 02:56:38 -0800, barton <[EMAIL PROTECTED]
software.com> wrote:

>all TCPIP application (such as telnet) connects per second are reported 

on ESATCPA report
>for z/VM connections if you have ESATCP or ESALPS.  Overall connection 

rates are reported
>for other servers on the ESATCP1 report.

We don't.

Re: MIPS for SSLSERV

[Tom Duerbusch]

I can't say about TN3270, but if you assume that all encryption has the same 
cost (i.e. cost per MB), then:

On SLES10, FTP encryption seemed to become the default vs older Suse systems.
When I FTP iso images now, it takes 4 X the CPU power then the non-encrypted 
version.

This is based on our z/890 IFL. 

So, my first guess is 4 times the current cost of your TCPIP stack.

Tom Duerbusch
THD Consulting

FELINE PHYSICS:  
Law of Cat Motion

  A cat will move in a straight line, unless there is a really good
  reason to change direction.


>>> Alan Ackerman <[EMAIL PROTECTED]> 10/16/2007 6:01 PM >>>
We have been asked to encrypt all TN3270 traffic to our VM systems (5 
LPARS + 14? guests). I am planning to use the VM SSLSERV, running on Red 
Hat (RHEL 4) Linux. My management wants me to estimate the MIPS (or CPU 
cycles) cost of this. Any ideas? 

I can get number of users logged in via TCP/IP via NETSTAT TELNET, so a 
per-user cost would be nice, or a total cost and number of logged-in 
users, but I will take any estimates you have.

These are CMS users, or users dialing in to VTAM. (Existing Linux guests 
are not affected by this, as they already use encrypted TELNET.)

z/VM 5.3.0 (soon) on z9 EC processors. QWS3270 Secure (although I don't 
think the PC client makes any difference).

Re: MIPS for SSLSERV

[barton]

all TCPIP application (such as telnet) connects per second are reported on ESATCPA report 
for z/VM connections if you have ESATCP or ESALPS.  Overall connection rates are reported 
for other servers on the ESATCP1 report.




Alan Ackerman wrote:


On Tue, 16 Oct 2007 20:03:07 -0400, David Kreuter <[EMAIL PROTECTED]
com> wrote:



What else is running through the VM TCPIP stack?
What else are you encrypting via TCPIP and SSLSERV?
David



Mainly FTP and SMTP.  Some NFS. Some DB2 (DRDA?).
Nothing else encrypted, although FTP will be next.

I found the z/V performance report. It has lots of numbers for CPU cost f
or Telnet CONNECTS. Any 
idea how I can get a count of those? It also has FTP cost in bytes, but n

o other Telnet costs.

Re: MIPS for SSLSERV

[David Kreuter]

What else is running through the VM TCPIP stack?
What else are you encrypting via TCPIP and SSLSERV?
David


-Original Message-
From: The IBM z/VM Operating System on behalf of Alan Ackerman
Sent: Tue 10/16/2007 7:01 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: [IBMVM] MIPS for SSLSERV
 
We have been asked to encrypt all TN3270 traffic to our VM systems (5 
LPARS + 14? guests). I am planning to use the VM SSLSERV, running on Red =

Hat (RHEL 4) Linux. My management wants me to estimate the MIPS (or CPU =

cycles) cost of this. Any ideas? 

I can get number of users logged in via TCP/IP via NETSTAT TELNET, so a =

per-user cost would be nice, or a total cost and number of logged-in 
users, but I will take any estimates you have.

These are CMS users, or users dialing in to VTAM. (Existing Linux guests =

are not affected by this, as they already use encrypted TELNET.)

z/VM 5.3.0 (soon) on z9 EC processors. QWS3270 Secure (although I don't =

think the PC client makes any difference).

MIPS for SSLSERV

[Alan Ackerman]

We have been asked to encrypt all TN3270 traffic to our VM systems (5 
LPARS + 14? guests). I am planning to use the VM SSLSERV, running on Red 

Hat (RHEL 4) Linux. My management wants me to estimate the MIPS (or CPU 

cycles) cost of this. Any ideas? 

I can get number of users logged in via TCP/IP via NETSTAT TELNET, so a 

per-user cost would be nice, or a total cost and number of logged-in 
users, but I will take any estimates you have.

These are CMS users, or users dialing in to VTAM. (Existing Linux guests 

are not affected by this, as they already use encrypted TELNET.)

z/VM 5.3.0 (soon) on z9 EC processors. QWS3270 Secure (although I don't 

think the PC client makes any difference).