Post by Dirk MunkPost by Stephen Hoffman...
I've watched the numbers of system managers associated with
installations shrinking, and the efficiency of the remaining managers
increasing. We all have. Part of that is because the systems are
continuing to become easier and more automated, and the tools to manage
masses of servers continue to improve. Are there going to be system
managers around, and particularly for complex configurations? Sure.
But there'll be fewer of them, relative to the numbers of servers and
the complexity of the networks that get deployed. There'll always be
management pressure to eliminate the positions, too. Some will be
outsourced, too — either to ISVs or cloud providers or service bureaus
or part-timer staff, too. Servers are only getting better at
managing themselves, or of picking reasonable defaults, or of picking
up settings from configuration servers. Which means fewer mistakes,
less effort, and fewer (on average) system managers. And if we're
looking at 2022 or 2027 and beyond, that means fewer configuration
files and fewer manual set-up steps to get to a working configuration.
As compared with requiring manual IPsec configurations, embedding TLS
into the application or utilizing the existing CA framework in a server
means I don't have to add tasks onto the list for the local system
managers. It also means I don't have to troubleshoot the inevitable
mistakes, and it means that I don't have to go rummage the system to
ensure the connection is secure.
Really.
Yes, really.
Post by Dirk MunkSo don't have to keep track which applications have outdated and
vulnerable SSL/TLS stacks.
I'd prefer not to, hence my comments around an API for this. But then
IPsec doesn't do what I need. For software updates, that's managed by
pushing out updates. OpenVMS folks haven't seen these approaches and
tools as many of the OpenVMS servers are customized. But we're all
headed toward software that gets pushed out — whether from VSI in
Bolton, from the ISV, or within the organization. OpenVMS does not
have tools for that, but other boxes do. That's already a problem for
OpenVMS going forward, and one that's much bigger than the security
libraries and tools and related infrastructure.
Post by Dirk MunkYou don't have to reinstall that software.
I'm usually doing software updates more frequently than TLS API
versions are rolling forward, though pushing out a new TLS library on
short notice is still a requirement. Unless TLS is entirely avoided
from a server configuration, there's still going to be a requirement to
quickly push out new versions for servers, too.
Post by Dirk MunkYou don't have to tell your own software department or some other
software club that your software needs an update.
I'd like to be in that world, but I'm not. I'd like to have
decade-long deployments, but — if I'm on the open 'net — I can't have
that.
As for code modularity, that depends on how the libraries are packaged.
I've already done some work in that area. I'd like to see OpenVMS
APIs for transport and DNS and security and authentication, as has been
mentioned. That's a slog, whether using TLS or otherwise — or using
IPsec for that matter. But then security also moves forward and
increasingly rapidly, which generally means updates. Newer
recommendations around checks and practices, as well as fixes and
corrections. Which gets back to having easier and faster software
updates, another capability that I'd prefer to see.
Post by Dirk MunkYou don't have to plan that with the users. You don't have to test the
new software. You don't have to keep track of your certificates, to
prevent them from becoming outdated.
All of which is wonderful, but for about the zillionth time I've
explained this, none of which is even remotely relevant to the problem
at hand. Like OSI, none of what IPsec provides does anything for what
I need to do. and it adds a pile of complexity onto the existing mess.
So I have to go through all of what I have to go through — I'd prefer
not to — plus dealing with a bad IPsec UI and the rest, and whatever
patches IPsec itself needs. In aggregate, more work.
Post by Dirk MunkI've done that kind of work, it's a pain in the ass when you have to
get a dozen managers and departments so far that you can do an update,
or convince them that they need an update.
I'm fully aware that managers are living in the OSI era, and think
computing still works the same way it did, that they can still do
deployments like they used to, and can ignore updates for days or weeks
with impunity. Fun times. They eventually learn.
Post by Dirk MunkCompare that with a quick setup of an IPsec connection by an
experienced system manager, it will take about half an hour.
Wonderful. Doesn't solve my problems. I'm doing app updates anyway,
so the TLS rolls along with it.
Post by Dirk MunkIf you have a good system manager, then he can trace and solve problems
in a short time.
Having that system manager costs money, and introduces mistakes. I
write that as somebody that's done more than a little system
management, too.
Post by Dirk MunkIf you have the type of ignorant and mediocre system managers you seem
to prefer, then problems can take months to be solved, or they are
never solved.
I'd prefer to have no system managers, and having the deployments
automated. That's increasingly common, too. Lights Out is one of
the older names for removing folks from the process, akin to the end of
preventive maintenance a generation or two before it. That's not as
easy with OpenVMS as with other boxes, as the OpenVMS tools are all
locally-developed or locally-ported or not available and which means we
fall back to using system managers and manual processes.
Post by Dirk MunkI've seen it, I've experienced it over decades.
Expecting trained humans is a wonderful thought, but an expensive one.
Force-fitting IPsec where it doesn't work — much like DECnet or OSI —
doesn't help there, either.
I'd like to live in the world with OpenVMS everywhere, and with DECnet
and OSI networking providing all interconnection, and with IPsec
allowing trivial interconnections among all systems, and all the rest.
I'd like to have static network configurations, full control of all
the client systems and remote servers, and with locked-down or no
connections outside of the datacenters, with trusted and secure
internal networks, with off-hour windows available for backups and
maintenance, with production and application development efforts that
each permit queuing upgrades for installation once or twice a year at
most, having to rush-install upgrades only once every year or two and
having a week to do it. I'd certainly prefer to have skilled
technical staff ready on-site and on-call at the customer site, and
staff that has the budget and payroll and schedule time and the
technical ability to find and read and understand the copious
documentation that's inevitably available, and obviously performing
each individual installation and upgrade with due care and no matter
how complex those might be and how arcane the software and the UI might
be. I would like to have the ability to fund large development and
support organizations, too. But I don't, I need to operate with the
environments customers have, and are deploying. What I'm seeing and
dealing with now is only going to get faster, too. IP and TLS are part
of that. Ease of use and integration desperately needs to improve.
Far better automation too, as what's happening now is only going to
accelerate. And certainly, there are some folks can or do still
operate their OpenVMS servers and systems like they're back in the
classic OpenVMS era. Good on them.
Again, no matter what benefits you can and do (correctly) point to
around IPsec over TLS or otherwise, IPsec does NOT solve the
fundamental problems that I'm dealing with, around network connection
security. If IPsec solves your local requirements, wonderful. Go for
it. Use it.
--
Pure Personal Opinion | HoffmanLabs LLC