Doh. I got wrapped around the axle thinking about the client, didn’t focus on the fact that the tn3270 server is integrated into z/OS! Sorry about that.
In any case, I believe what I wrote is correct, just not relevant to the question asked 😊 From: Phil Smith III <[email protected]> Sent: Friday, May 7, 2021 9:19 AM To: [email protected] Subject: Re: 3270 emulator / telnet with encryption Radoslaw Skorupka wrote: >I can be wrong, but I read that data portions for telnet traffic are so >small that there is no interest to call ICSF functions and just built-in >TCPIP/TN3270 procedures are used. Note: I talk about symmetric key >crypto, not handshaking. And that part of "software based" encryption is >eligible to zIIP offload. >Can you confirm that? You want to be careful with definitions here. Calling ICSF might mean any of three things, depending on what you’re calling and how the system is configured: 1. Software in ICSF 2. CPACF (“crypto on the chip”, so onboard but in millicode) 3. Crypto Express (CEX), the HSM It’s a reasonably safe bet that any machine today has CPACF; that was not always true, of course. CEX is expensive for short operations (not talking about SSL accelerator mode, I mean for plain ol’ encryption), so right, for a telnet session you might want to not use it. ICSF has a bunch of functions, but sure, it’s not free, requires a context switch, etc. I suspect it really comes down to whether the emulator vendor feels up to implementing and validating the crypto, as well as how much it matters: when I hit an AID key, how significant is ICSF overhead (and perhaps even CEX overhead) compared to network latency? In Ye Olden Days when we had thousands of users, this might have mattered more; nowadays, with a handful of connected users, it might not even be worth worrying about. It would be interesting to see. I sure don’t notice any terminal-level response difference between a connection to a z15 using TLS and a connection to a zPDT without encryption. Yes, I realize that’s the wrong test: z15 without and zPDT with would be more interesting, but that’s not what I have available. Point is, neither feels at all laggy. When you talk about zIIP offload, remember that there’s nothing automatic there: a vendor could zIIP-enable their processing, but that’s up to them. I imagine ICSF can do stuff on the zIIP but haven’t looked. >To make things more complex: some CPACF functions can be called directly >from assembler code, without ICSF. “Some”? I’d say “all”. It’s just an instruction (well, a couple: KM and KMC, IIRC [no, IIRC is not another instruction, though I’d like to see one called that!]). Not hard to use at all. Used to be trickier since you couldn’t assume it was available, or that the specific subfunction was available, but as noted above, not so much now. Note that if ICSF has ever run since IPL, there are flags in the CCVT that tell you what CPACF functions are available. HTH ...phsiii ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
