[Info-vax] One possible market for VMS: secure credit card

[Stephen Hoffman]

On 2015-03-25 01:59:29 +0000, Kerry Main said:

>> 
>> -----Original Message-----
>> 
>> From: Info-vax [mailto:info-vax-bounces at info-vax.com] On Behalf Of 
>> Stephen Hoffman
>> 
> 
> 
>> 
>> 
>> IPSec <https://en.wikipedia.org/wiki/IPsec> is all that and a bag of
>> 
>> chips, at least with IP and DECnet over IP.  Alas, OpenVMS doesn't have
>> 
>> that support yet.
>> 
>> 
>> 
> 
> 
> Sure it does. Not with native stack, but Multinet certainly supports 
> IPSEC on OpenVMS.

Yes, loading a Process stack is an option — Multinet is good stack, 
albeit with a very different management interface.   But IPv4, and IPv6 
with IPsec, are not particularly integrated with OpenVMS itself.   
There was some integration work done back at OpenVMS V6.2, but AFAIK 
not all much has changed since then, and few servers and services have 
seen updates that allow those services to use IP more directly.  
Everybody's still solving this stuff for specific applications.  Or — 
in the case of folks still using cleartext credentials — not solving 
this.

> Since almost no one uses the native backup utility on Windows Servers, 
> 
> this statement is like saying Windows does not have much backup 
> 
> support  (true, but there are commercial options).

Windows Server does have IPv4 support and IPv6 support with IPsec, and 
it's integrated with most of (all of?) the Windows Server services.  
Network- and security-related details such as certificates are better 
integrated within Windows, for instance. 
<http://social.technet.microsoft.com/wiki/contents/articles/2167.how-to-use-the-certificates-console.aspx>. 
 Same for OS X, iOS, Android, Linux and other platforms.

As for OpenVMS, more than a few folks have only the HP stack available, 
such as a recent discussion here.  Sure, a Process stack is an option 
here, for those that have or can migrate to that.

VSI appears to be addressing the IP network stack and reportedly 
somewhere between V8.4-1H1 and V9.0, but details on what changes they 
have in mind here are scarce.

Sheer speculation: VSI integrates the Process Multinet stack into 
OpenVMS through negotiation and/or merger and/or acquisition, and this 
then pulls OpenVMS and the developer community forward by ensuring that 
the IP-related routines and APIs are available on all systems, then 
starts working to integrate IP into the base OS.  This would certainly 
be expedient, and would be much less complex than having to maintain 
the existing third-party IP product APIs.

> 
> 
> 
> 
>>> Maybe the above would be feasible for DECnet, since that most likely
>>> 
>>> would be VMS to VMS.
>>> 
>> 
>> 
>> DECnet is a dead-end protocol, as much as I still find occasional use
>> 
>> for it.  IP hasn't yet been integrated to the degree of DECnet.  If
>> 
>> (when?) that integration happens within OpenVMS, I'd suspect most
>> 
>> folks won't really miss DECnet all that much.
>> 
> 
> 
> While no one will argue DECnet in its current state is past its prime, if 
> 
> one were looking for a secure *internal* network protocol that only 
> 
> maybe <10 hackers in the world know enough to crack it, then DECnet 
> 
> might have a place.

Because finding cleartext passwords and usernames in a packet dump 
using the strings command or analogous is difficult, and because the 
protocol specs aren't published?   tcpdump has DECnet support, BTW.   
DECnet?  Secure?  Seriously?  No.  Not without a bevy of DESNC boxes 
around and — given the US encryption control and particularly the 
export regulations from back then  — arguably not all that secure.  
(For those less steeped in the DECronyms, the DESNC was the DIGITAL 
Ethernet Secure Network Controller; an outboard crypto box for DECnet 
networks.  One of the recent export-grade crypto attacks discussed: 
<http://blog.cryptographyengineering.com/2015/03/attack-of-week-freak-or-factoring-nsa.html>. 
 Some of the GPU-based attacks are much cheaper than the $104 cited in 
that posting, too.)

> I know of quite a few manufacturing environments that run their
> 
> very mission critical process control environments using DECnet and
> 
> the main reason is stability, security and reliability.

Two out of three isn't bad.   I too am very familiar with some of the 
DECnet-based manufacturing environments, and unfortunately — as 
demonstrated by Stuxnet <https://en.wikipedia.org/wiki/Stuxnet> and 
other and more recent shenanigans — manufacturing and SCADA and related 
environments are much bigger targets now than they once were.  But then 
corporate firewalls are also better viewed as the demarcation between 
the stuff you have to fix, and stuff somebody else has to fix.  Put 
another way, are all your HP printers running current firmware?  If 
not, you have a firewall problem.  But I digress.

> And I am sure folks here know that while TCPIP V4 is the std today, 
> 
> it Is what network engineers would likely describe as a std using the 
> 
> lowest common denominator protocol design.

IPv4 became ubiquitous while the OSI committees all sought to solve 
everything effectively and elegantly — and in many cases, they 
succeeded — and which led to expensive and often complex and 
closed-source products (DECnet-Plus/DECnet-OSI/DECnet Phase V being but 
one example), and which led to OSI utterly missing the marketing window.

Much like the recent x86 processor architecture discussion, IPv4 and 
IPv6 aren't the most elegant of morasses, but IPv4 and IPv6 are cheap 
and effective and do work for most of the common cases, preferably when 
the stack has been tracking recent features and security.  Are they 
what I would want?  No.  Do they work?  Yes.  Are they available 
everywhere?  Yes.  DECnet or OSI?  Not so much...

> IPV6 is definitely a step up, but there has not been a huge rush to 
> 
> adopt this (at least not yet)

IPv6 with support for IPsec and other related pieces?  Not on OpenVMS 
as easily as it should be, certainly.   Though Windows, OS X, Linux, 
iOS and Android/ASOS — which is only a few billion devices, after all — 
all support IPv6.



-- 
Pure Personal Opinion | HoffmanLabs LLC