I’ve often mentioned that in my view IPsec should be used between twoVMS nodes to encrypt all IP traffic. IPsec is almost non-existing in thepresent HPE TCPIP Services, but it is present in the Multinet stack, andit will be present in the new VSI TCPIP V10.5 Services.

So I wanted to know how to set it up, and it proofed to be remarkablesimple.

The following examples come from the MultiNet Installation andAdministrator's Guide, I give you the settings for one node.

I’ve often mentioned that in my view IPsec should be used between two VMSnodes to encrypt all IP traffic. IPsec is almost non-existing in thepresent HPE TCPIP Services, but it is present in the Multinet stack, and itwill be present in the new VSI TCPIP V10.5 Services.So I wanted to know how to set it up, and it proofed to be remarkable simple.The following examples come from the MultiNet Installation andAdministrator's Guide, I give you the settings for one node.# multinet:ipsec.conf ## packet will look like this: IPv4 AH ESP payload# the node is on 10.1.1.1, peer is on 10.2.1.1# Add encryption to outgoing packets and incoming packets, both withadd 10.1.1.1 10.2.1.1 esp 9876 -E 3des-cbc “hogehogehogehogehogehoge”;add 10.2.1.1 10.1.1.1 esp 10000 -E 3des-cbc0xdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeef;add 10.1.1.1 10.2.1.1 ah 9877 -A hmac-md5 “mogamogamogamoga”;add 10.2.1.1 10.1.1.1 ah 10001 -A hmac-md5 “lowalowalowalowa”;#require that all outgoing and incoming IP traffic to and from that peer isspdadd 10.1.1.1 10.2.1.1 any -P out ipsec esp/transport//useah/transport//use;spdadd 10.2.1.1 10.1.1.1 any -P in ipsec esp/transport//use ah/transport//use;That’s it, all IP traffic will be encrypted and authenticated. Thatincludes Telnet, FTP, SQL, DECnet over IP:(which ever version), clusterover UDP, name it.No need for other types of encryption between these two nodes, so no SSH orTLS.Simple and elegant, just the way it should be.

Yes, seems simple enough, for two nodes.

And on node 10.2.1.1 (in this case) you just do the same,but in reverse, so to speak. Can you just come up with anykeys, "hogehoge..." and so on, or do you need to create thosekeys first with some other tool?

Is it that, for IPsec, you always need to know beforehand whatnodes you will be communicating with? And exchange keys bysome other means.

I’ve often mentioned that in my view IPsec should be used between two VMSnodes to encrypt all IP traffic. IPsec is almost non-existing in thepresent HPE TCPIP Services, but it is present in the Multinet stack, and itwill be present in the new VSI TCPIP V10.5 Services.So I wanted to know how to set it up, and it proofed to be remarkable simple.The following examples come from the MultiNet Installation andAdministrator's Guide, I give you the settings for one node.# multinet:ipsec.conf ## packet will look like this: IPv4 AH ESP payload# the node is on 10.1.1.1, peer is on 10.2.1.1# Add encryption to outgoing packets and incoming packets, both withadd 10.1.1.1 10.2.1.1 esp 9876 -E 3des-cbc “hogehogehogehogehogehoge”;add 10.2.1.1 10.1.1.1 esp 10000 -E 3des-cbc0xdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeef;add 10.1.1.1 10.2.1.1 ah 9877 -A hmac-md5 “mogamogamogamoga”;add 10.2.1.1 10.1.1.1 ah 10001 -A hmac-md5 “lowalowalowalowa”;#require that all outgoing and incoming IP traffic to and from that peer isspdadd 10.1.1.1 10.2.1.1 any -P out ipsec esp/transport//useah/transport//use;spdadd 10.2.1.1 10.1.1.1 any -P in ipsec esp/transport//useah/transport//use;That’s it, all IP traffic will be encrypted and authenticated. Thatincludes Telnet, FTP, SQL, DECnet over IP:(which ever version), clusterover UDP, name it.No need for other types of encryption between these two nodes, so no SSH orTLS.Simple and elegant, just the way it should be.

I’ve often mentioned that in my view IPsec should be used between two VMSnodes to encrypt all IP traffic. IPsec is almost non-existing in thepresent HPE TCPIP Services, but it is present in the Multinet stack, and itwill be present in the new VSI TCPIP V10.5 Services.So I wanted to know how to set it up, and it proofed to be remarkable simple.The following examples come from the MultiNet Installation andAdministrator's Guide, I give you the settings for one node.# multinet:ipsec.conf ## packet will look like this: IPv4 AH ESP payload# the node is on 10.1.1.1, peer is on 10.2.1.1# Add encryption to outgoing packets and incoming packets, both withadd 10.1.1.1 10.2.1.1 esp 9876 -E 3des-cbc “hogehogehogehogehogehoge”;add 10.2.1.1 10.1.1.1 esp 10000 -E 3des-cbc0xdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeef;add 10.1.1.1 10.2.1.1 ah 9877 -A hmac-md5 “mogamogamogamoga”;add 10.2.1.1 10.1.1.1 ah 10001 -A hmac-md5 “lowalowalowalowa”;#require that all outgoing and incoming IP traffic to and from that peer isspdadd 10.1.1.1 10.2.1.1 any -P out ipsec esp/transport//useah/transport//use;spdadd 10.2.1.1 10.1.1.1 any -P in ipsec esp/transport//useah/transport//use;That’s it, all IP traffic will be encrypted and authenticated. Thatincludes Telnet, FTP, SQL, DECnet over IP:(which ever version), clusterover UDP, name it.No need for other types of encryption between these two nodes, so no SSH orTLS.Simple and elegant, just the way it should be.

I’ve often mentioned that in my view IPsec should be used between two VMSnodes to encrypt all IP traffic. IPsec is almost non-existing in thepresent HPE TCPIP Services, but it is present in the Multinet stack, and itwill be present in the new VSI TCPIP V10.5 Services.So I wanted to know how to set it up, and it proofed to be remarkable simple.The following examples come from the MultiNet Installation andAdministrator's Guide, I give you the settings for one node.# multinet:ipsec.conf ## packet will look like this: IPv4 AH ESP payload# the node is on 10.1.1.1, peer is on 10.2.1.1# Add encryption to outgoing packets and incoming packets, both withadd 10.1.1.1 10.2.1.1 esp 9876 -E 3des-cbc “hogehogehogehogehogehoge”;add 10.2.1.1 10.1.1.1 esp 10000 -E 3des-cbc0xdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeef;add 10.1.1.1 10.2.1.1 ah 9877 -A hmac-md5 “mogamogamogamoga”;add 10.2.1.1 10.1.1.1 ah 10001 -A hmac-md5 “lowalowalowalowa”;#require that all outgoing and incoming IP traffic to and from that peer isspdadd 10.1.1.1 10.2.1.1 any -P out ipsec esp/transport//useah/transport//use;spdadd 10.2.1.1 10.1.1.1 any -P in ipsec esp/transport//useah/transport//use;That’s it, all IP traffic will be encrypted and authenticated. Thatincludes Telnet, FTP, SQL, DECnet over IP:(which ever version), clusterover UDP, name it.No need for other types of encryption between these two nodes, so no SSH orTLS.Simple and elegant, just the way it should be.

Bad wording in my question from my side... :-)How is IPsec used when you do not know the other node?

Just as with SSH, you need to set up both nodes. Even if you candistribute keys with Rancoon2, you still need to set up a SecurityPolicy on both nodes. At least that is how I understand that this works.

I’ve often mentioned that in my view IPsec should be used between two VMSnodes to encrypt all IP traffic. IPsec is almost non-existing in thepresent HPE TCPIP Services, but it is present in the Multinet stack, and itwill be present in the new VSI TCPIP V10.5 Services.So I wanted to know how to set it up, and it proofed to be remarkable simple.The following examples come from the MultiNet Installation andAdministrator's Guide, I give you the settings for one node.# multinet:ipsec.conf ## packet will look like this: IPv4 AH ESP payload# the node is on 10.1.1.1, peer is on 10.2.1.1# Add encryption to outgoing packets and incoming packets, both withadd 10.1.1.1 10.2.1.1 esp 9876 -E 3des-cbc “hogehogehogehogehogehoge”;add 10.2.1.1 10.1.1.1 esp 10000 -E 3des-cbc0xdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeef;add 10.1.1.1 10.2.1.1 ah 9877 -A hmac-md5 “mogamogamogamoga”;add 10.2.1.1 10.1.1.1 ah 10001 -A hmac-md5 “lowalowalowalowa”;#require that all outgoing and incoming IP traffic to and from that peer isspdadd 10.1.1.1 10.2.1.1 any -P out ipsec esp/transport//useah/transport//use;spdadd 10.2.1.1 10.1.1.1 any -P in ipsec esp/transport//use ah/transport//use;That’s it, all IP traffic will be encrypted and authenticated. Thatincludes Telnet, FTP, SQL, DECnet over IP:(which ever version), clusterover UDP, name it.No need for other types of encryption between these two nodes, so no SSH orTLS.Simple and elegant, just the way it should be.

Bad wording in my question from my side... :-)How is IPsec used when you do not know the other node?

Just as with SSH, you need to set up both nodes. Even if you candistribute keys with Rancoon2, you still need to set up a SecurityPolicy on both nodes. At least that is how I understand that this works.

Which means you have to have some kind of control, or cooperation, on both ends.Not so good for Amazon and such, huh?

I’ve often mentioned that in my view IPsec should be used between two VMSnodes to encrypt all IP traffic. IPsec is almost non-existing in thepresent HPE TCPIP Services, but it is present in the Multinet stack, and itwill be present in the new VSI TCPIP V10.5 Services.So I wanted to know how to set it up, and it proofed to be remarkable simple.The following examples come from the MultiNet Installation andAdministrator's Guide, I give you the settings for one node.# multinet:ipsec.conf ## packet will look like this: IPv4 AH ESP payload# the node is on 10.1.1.1, peer is on 10.2.1.1# Add encryption to outgoing packets and incoming packets, both withadd 10.1.1.1 10.2.1.1 esp 9876 -E 3des-cbc“hogehogehogehogehogehoge”;add 10.2.1.1 10.1.1.1 esp 10000 -E 3des-cbc0xdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeef;add 10.1.1.1 10.2.1.1 ah 9877 -A hmac-md5 “mogamogamogamoga”;add 10.2.1.1 10.1.1.1 ah 10001 -A hmac-md5 “lowalowalowalowa”;#require that all outgoing and incoming IP traffic to and from that peer isspdadd 10.1.1.1 10.2.1.1 any -P out ipsec esp/transport//useah/transport//use;spdadd 10.2.1.1 10.1.1.1 any -P in ipsec esp/transport//use ah/transport//use;That’s it, all IP traffic will be encrypted and authenticated. Thatincludes Telnet, FTP, SQL, DECnet over IP:(which ever version), clusterover UDP, name it.No need for other types of encryption between these two nodes, so no SSH orTLS.Simple and elegant, just the way it should be.

Bad wording in my question from my side... :-)How is IPsec used when you do not know the other node?

Just as with SSH, you need to set up both nodes. Even if you candistribute keys with Rancoon2, you still need to set up a SecurityPolicy on both nodes. At least that is how I understand that this works.

Which means you have to have some kind of control, or cooperation, onboth ends. Not so good for Amazon and such, huh?

I’ve often mentioned that in my view IPsec should be used between two VMSnodes to encrypt all IP traffic. IPsec is almost non-existing in thepresent HPE TCPIP Services, but it is present in the Multinet stack, and itwill be present in the new VSI TCPIP V10.5 Services.So I wanted to know how to set it up, and it proofed to be remarkablesimple.The following examples come from the MultiNet Installation andAdministrator's Guide, I give you the settings for one node.# multinet:ipsec.conf ## packet will look like this: IPv4 AH ESP payload# the node is on 10.1.1.1, peer is on 10.2.1.1# Add encryption to outgoing packets and incoming packets, both withadd 10.1.1.1 10.2.1.1 esp 9876 -E 3des-cbc“hogehogehogehogehogehoge”;add 10.2.1.1 10.1.1.1 esp 10000 -E 3des-cbc0xdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeef;add 10.1.1.1 10.2.1.1 ah 9877 -A hmac-md5 “mogamogamogamoga”;add 10.2.1.1 10.1.1.1 ah 10001 -A hmac-md5 “lowalowalowalowa”;#require that all outgoing and incoming IP traffic to and from that peer isspdadd 10.1.1.1 10.2.1.1 any -P out ipsec esp/transport//useah/transport//use;spdadd 10.2.1.1 10.1.1.1 any -P in ipsec esp/transport//use ah/transport//use;That’s it, all IP traffic will be encrypted and authenticated. Thatincludes Telnet, FTP, SQL, DECnet over IP:(which ever version), clusterover UDP, name it.No need for other types of encryption between these two nodes, so no SSH orTLS.Simple and elegant, just the way it should be.

Bad wording in my question from my side... :-)How is IPsec used when you do not know the other node?

Just as with SSH, you need to set up both nodes. Even if you candistribute keys with Rancoon2, you still need to set up a SecurityPolicy on both nodes. At least that is how I understand that this works.

Which means you have to have some kind of control, or cooperation, onboth ends. Not so good for Amazon and such, huh?

Did I claim that?

No, nor did you state it either. Don't get me wrong, I like IPSEC. But it haslimitations. Must realize that.

I’ve often mentioned that in my view IPsec should be used between two VMSnodes to encrypt all IP traffic. IPsec is almost non-existing in thepresent HPE TCPIP Services, but it is present in the Multinetstack,and itwill be present in the new VSI TCPIP V10.5 Services.So I wanted to know how to set it up, and it proofed to be remarkablesimple.The following examples come from the MultiNet Installation andAdministrator's Guide, I give you the settings for one node.# multinet:ipsec.conf ## packet will look like this: IPv4 AH ESP payload# the node is on 10.1.1.1, peer is on 10.2.1.1# Add encryption to outgoing packets and incoming packets, both withadd 10.1.1.1 10.2.1.1 esp 9876 -E 3des-cbc“hogehogehogehogehogehoge”;add 10.2.1.1 10.1.1.1 esp 10000 -E 3des-cbc0xdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeef;add 10.1.1.1 10.2.1.1 ah 9877 -A hmac-md5 “mogamogamogamoga”;add 10.2.1.1 10.1.1.1 ah 10001 -A hmac-md5 “lowalowalowalowa”;#require that all outgoing and incoming IP traffic to and from that peer isspdadd 10.1.1.1 10.2.1.1 any -P out ipsec esp/transport//useah/transport//use;spdadd 10.2.1.1 10.1.1.1 any -P in ipsec esp/transport//useah/transport//use;That’s it, all IP traffic will be encrypted and authenticated. Thatincludes Telnet, FTP, SQL, DECnet over IP:(which ever version), clusterover UDP, name it.No need for other types of encryption between these two nodes,so noSSH orTLS.Simple and elegant, just the way it should be.

Bad wording in my question from my side... :-)How is IPsec used when you do not know the other node?

Just as with SSH, you need to set up both nodes. Even if you candistribute keys with Rancoon2, you still need to set up a SecurityPolicy on both nodes. At least that is how I understand that this works.

Which means you have to have some kind of control, or cooperation, onboth ends. Not so good for Amazon and such, huh?

Did I claim that?

No, nor did you state it either. Don't get me wrong, I like IPSEC. Butit has limitations. Must realize that.

IPsec is highly tunable, it is not meant for simple browser connections.For that TLS is fine.

But keep in mind, I have no experience with IPsec, I've just beenreading the manual. I even don't know if the Multinet version isstate-of-the art. I'm not saying it is not, I just don't know. Perhapsmore things are possible with IPsec, who knows.

Post by Dirk MunkJust as with SSH, you need to set up both nodes. Even if you candistribute keys with Rancoon2, you still need to set up a SecurityPolicy on both nodes. At least that is how I understand that this works.

Which means you have to have some kind of control, or cooperation, onboth ends. Not so good for Amazon and such, huh?

SSH needs coordination when the user wants to use a passphrase orno-password login to log into the remote server. That requires apublic key be copied to the target system.

Otherwise, SSH can connect to other hosts just fine, and the initialconnection is encrypted.

SSH can't prove whether the host it connects to is the intended host onthe first connection though; that's something that TLS does withcertificates and an out-of-band external coordination service; thepublic certificate authority, or a private CA for those that have asecure path to load the root certificate onto all of the hostsinvolved. Once that initial connection is made, subsequent connectionsdo check the host keys.

If you're coordinating public keys or such among your own clients andservers, then copying the necessary files viapuppet/salt/munki/ancible/WhateverYou'reUsing. Pragmatically, this isthe same as IPSec keys, for those cases where need to pre-share thepublic keys for logins and/or for that initial ssh connection.

TLS coordination of trust is via the commercial or private CA, eithervia public keys associated with the host software or within theapplication software, and possibly also pinned by the applicationsoftware.

If you're running your own root CA, you'll need a trusted path todistribute the root cert. That private CA public key can bedistributed via a browser-based TLS connection where the server isidentified by a private key signed by a commercial provider if you'reso inclined, and there are folks that do just that.

I’ve often mentioned that in my view IPsec should be used between two VMSnodes to encrypt all IP traffic. IPsec is almost non-existing in thepresent HPE TCPIP Services, but it is present in the Multinet stack, and itwill be present in the new VSI TCPIP V10.5 Services.So I wanted to know how to set it up, and it proofed to be remarkable simple.The following examples come from the MultiNet Installation andAdministrator's Guide, I give you the settings for one node.# multinet:ipsec.conf ## packet will look like this: IPv4 AH ESP payload# the node is on 10.1.1.1, peer is on 10.2.1.1# Add encryption to outgoing packets and incoming packets, both withadd 10.1.1.1 10.2.1.1 esp 9876 -E 3des-cbc “hogehogehogehogehogehoge”;add 10.2.1.1 10.1.1.1 esp 10000 -E 3des-cbc0xdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeef;add 10.1.1.1 10.2.1.1 ah 9877 -A hmac-md5 “mogamogamogamoga”;add 10.2.1.1 10.1.1.1 ah 10001 -A hmac-md5 “lowalowalowalowa”;#require that all outgoing and incoming IP traffic to and from that peer isspdadd 10.1.1.1 10.2.1.1 any -P out ipsec esp/transport//useah/transport//use;spdadd 10.2.1.1 10.1.1.1 any -P in ipsec esp/transport//use ah/transport//use;That’s it, all IP traffic will be encrypted and authenticated. Thatincludes Telnet, FTP, SQL, DECnet over IP:(which ever version), clusterover UDP, name it.No need for other types of encryption between these two nodes, so no SSH orTLS.Simple and elegant, just the way it should be.

I’ve often mentioned that in my view IPsec should be used between two VMSnodes to encrypt all IP traffic. IPsec is almost non-existing in thepresent HPE TCPIP Services, but it is present in the Multinet stack, and itwill be present in the new VSI TCPIP V10.5 Services.So I wanted to know how to set it up, and it proofed to be remarkable simple.The following examples come from the MultiNet Installation andAdministrator's Guide, I give you the settings for one node.# multinet:ipsec.conf ## packet will look like this: IPv4 AH ESP payload# the node is on 10.1.1.1, peer is on 10.2.1.1# Add encryption to outgoing packets and incoming packets, both withadd 10.1.1.1 10.2.1.1 esp 9876 -E 3des-cbc“hogehogehogehogehogehoge”;add 10.2.1.1 10.1.1.1 esp 10000 -E 3des-cbc0xdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeef;add 10.1.1.1 10.2.1.1 ah 9877 -A hmac-md5 “mogamogamogamoga”;add 10.2.1.1 10.1.1.1 ah 10001 -A hmac-md5 “lowalowalowalowa”;#require that all outgoing and incoming IP traffic to and from that peer isspdadd 10.1.1.1 10.2.1.1 any -P out ipsec esp/transport//useah/transport//use;spdadd 10.2.1.1 10.1.1.1 any -P in ipsec esp/transport//use ah/transport//use;That’s it, all IP traffic will be encrypted and authenticated. Thatincludes Telnet, FTP, SQL, DECnet over IP:(which ever version), clusterover UDP, name it.No need for other types of encryption between these two nodes, so no SSH orTLS.Simple and elegant, just the way it should be.

Bad wording in my question from my side... :-)How is IPsec used when you do not know the other node?

Just as with SSH, you need to set up both nodes.

No, first time I connect PuTTY using SSH against my VMS box,I just click "OK, I'll accept the certificate" and it's OK.

Yes, and while poorly documented as far as I'm concerned, SSH does provide someof the automatic configuration that Steve likes so much (as do I) and does someof the setup for you. Now if only (as far as I'm concerned) it would tell youwhat it was doing, so one might understand things.

Post by Dirk MunkEven if you can distributekeys with Rancoon2, you still need to set up a Security Policy on bothnodes. At least that is how I understand that this works.

And my browser doesn't even ask, if it is a trusted certificate. If itisn't, I have to click "accept". There is no "setup" in the sense thatthe IPsec config files represents.

Browsers use client certificates that authenticate against known trusted rootcertificates. They check that the server you're connecting to is who you thinkit is. They do not authenticate in the opposite direction, where the serverchecks that the client is who it says it is.

See Steve, some of that certificate stuff you've attempted to pound into my headactually made it.

Post by David FrobleBrowsers use client certificates that authenticate against known trustedroot certificates. They check that the server you're connecting to iswho you think it is. They do not authenticate in the oppositedirection, where the server checks that the client is who it says it is.

That is not a good description.

Usually browsers do no use client certificates. But it ispossible to install a client certificate in a browser(you can Google how to do it for your preferred browser).If the client send a client certificate, then the servercan check it.

This is rarely used for web browsers and web pages.

But it is sometimes used for web service clients andweb services server side. Authentication of the client isdone via a client certificate.

Post by David FrobleBrowsers use client certificates that authenticate against known trustedroot certificates. They check that the server you're connecting to iswho you think it is. They do not authenticate in the oppositedirection, where the server checks that the client is who it says it is.

That is not a good description.

I have been known to state how much I don't like certificates. Now you knowwhy. I find them complex and not easy to use.

Not nice to turn my B+ into a D-

:-)

Post by Arne VajhÃ¸jUsually browsers do no use client certificates. But it ispossible to install a client certificate in a browser(you can Google how to do it for your preferred browser).If the client send a client certificate, then the servercan check it.This is rarely used for web browsers and web pages.But it is sometimes used for web service clients andweb services server side. Authentication of the client isdone via a client certificate.Arne

Post by Dirk MunkThat’s it, all IP traffic will be encrypted and authenticated. Thatincludes Telnet, FTP, SQL, DECnet over IP:(which ever version), clusterover UDP, name it.No need for other types of encryption between these two nodes, so noSSH or TLS.Simple and elegant, just the way it should be.

Simple and elegant can be wrong, too. What you've shown establishesVPNs between hosts. Not much different from what's possible with afirewall box with an embedded VPN server, or using stunnel. But thathost-to-host VPN-like approach is ineffective in other sorts ofnetworks when the identity and addresses of the peers aren'tpre-estabished, or when dealing with peers that change addresses, orwhen there's any sort of volatility in the network and certificates orRADIUS authentication or such are used to establish access. Or whenyou need to revoke host access, for that matter. More than a few ofus are dealing with these much more volatile networks, too.

Post by Dirk MunkThat’s it, all IP traffic will be encrypted and authenticated. Thatincludes Telnet, FTP, SQL, DECnet over IP:(which ever version),cluster over UDP, name it.No need for other types of encryption between these two nodes, so noSSH or TLS.Simple and elegant, just the way it should be.

Simple and elegant can be wrong, too. What you've shown establishesVPNs between hosts.

No, Multinet can NOT setup tunnels. This is transport mode, check themanual.

Post by Stephen HoffmanNot much different from what's possible with afirewall box with an embedded VPN server, or using stunnel. But thathost-to-host VPN-like approach is ineffective in other sorts of networkswhen the identity and addresses of the peers aren't pre-estabished, orwhen dealing with peers that change addresses,

It seems to be working with DNS names too. Furthermore, I emphasize thatI'm talking about VMS <> VMS IP traffic here, and I don't think theiraddresses will change that much.

Post by Stephen Hoffmanor when there's any sortof volatility in the network and certificates or RADIUS authenticationor such are used to establish access. Or when you need to revoke hostaccess, for that matter. More than a few of us are dealing with thesemuch more volatile networks, too.

Post by Dirk MunkThat’s it, all IP traffic will be encrypted and authenticated. Thatincludes Telnet, FTP, SQL, DECnet over IP:(which ever version), clusterover UDP, name it.No need for other types of encryption between these two nodes, so noSSH or TLS.Simple and elegant, just the way it should be.

I'm not sure I'd call that simple or elegant. Particularly given thedislike most folks have for slogging through configuration files, andrequiring them to manage and update those configuration files acrossmultiple hosts and particularly over time, and ignoring discussions ofuser interface simplicity and automation in general.

No, Multinet can NOT setup tunnels. This is transport mode, check the manual.

I'm referring to VPN in the vernacular here; an encryptedpoint-to-point link, however that's implemented. Some VPNs arestatic, and some are dynamic. Obviously IPsec itself supports bothtransport and tunnel modes, too. But does the terminology make adifference for the purposes of discussions of the limitations ofconfiguring static host-to-host connections? Because I can do thatstuff now, with a VPN box. Or with stunnel, depending on what I'm upto, and assuming I don't have a good way to secure theapplication-specific communications. Or going back to the all-DECnetera, of scrounging a DESNC for that matter.

Post by Stephen HoffmanNot much different from what's possible with a firewall box with anembedded VPN server, or using stunnel. But that host-to-host VPN-likeapproach is ineffective in other sorts of networks when the identityand addresses of the peers aren't pre-estabished, or when dealing withpeers that change addresses,

It seems to be working with DNS names too. Furthermore, I emphasizethat I'm talking about VMS <> VMS IP traffic here, and I don't thinktheir addresses will change that much.

Many folks using OpenVMS aren't using just OpenVMS, and most folksaren't using static network configurations. Sure, some core serversare, but if you have to solve the more general configuration why bothersetting up static links? Once you need more flexibility inconnectiivity, or once you need applications to control theirconnection security or per-app or per-user authentication such asauthenticating remote access into a web or other network app, a staticIPsec configuration becomes less interesting.

Post by Stephen Hoffmanor when there's any sort of volatility in the network and certificatesor RADIUS authentication or such are used to establish access. Orwhen you need to revoke host access, for that matter. More than a fewof us are dealing with these much more volatile networks, too.

This still doesn't solve the problems that many folks have. If youhave a static network configuration and communications requirements,this stuff works fine. If you don't have a static configuration, orif you need per-connection authentication or revocation or other such,this IPsec static-configuration approach doesn't work quite as nicely.

Post by Stephen HoffmanMany folks using OpenVMS aren't using just OpenVMS, and most folksaren't using static network configurations. Sure, some core serversare, but if you have to solve the more general configuration why bothersetting up static links? Once you need more flexibility inconnectiivity, or once you need applications to control theirconnection security or per-app or per-user authentication such asauthenticating remote access into a web or other network app, a staticIPsec configuration becomes less interesting.

FWIW I had bit of a lightbulb moment recently when I wanted to changethe name of a server. Since this particular server was configured as aDHCP client, a simple name change in the DHCP server followed by areboot got the job done.

cf VMS where changing the node name is a major task.

and for that matter, there are multiple steps involved in changing thehost name on non-VMS platforms too. DHCP is very desirable in anychanging environment.

Yes of course, this also involves adjustments to DNS records and entriesin ssh known_hosts files, but that all happens externally to the serverconcerned.

Post by Paul StureFWIW I had bit of a lightbulb moment recently when I wanted to changethe name of a server. Since this particular server was configured as aDHCP client, a simple name change in the DHCP server followed by areboot got the job done.cf VMS where changing the node name is a major task.and for that matter, there are multiple steps involved in changing thehost name on non-VMS platforms too. DHCP is very desirable in anychanging environment.

Post by Paul Stureand for that matter, there are multiple steps involved in changing thehost name on non-VMS platforms too. DHCP is very desirable in anychanging environment.

The connection from some DHCP servers into DNS is handy, too. Not allsystems have that configured. There are also times when you don'twant that too, of course.

Gradually working on that. A current topic here is the topic ofallocating MAC addresses for interfaces on virtual machines. Untilrecently I was using the MAC address generation feature within VMwareFusion or VirtualBox, but there be dragons doing that.[1]

One way of getting a random MAC address:

<http://osxdaily.com/2010/11/10/random-mac-address-generator/>

openssl rand -hex 6 | sed 's/\(..\)/\1:/g; s/.$//'

(also see [2])

but of course that ignores manufacturer specific ranges, which isaddressed in the following thread:

There are actually 4 sets of Locally Administered Address Rangesthat can be used on your network without fear of conflict, assumingno one else has assigned these on your network:

x2-xx-xx-xx-xx-xxx6-xx-xx-xx-xx-xxxA-xx-xx-xx-xx-xxxE-xx-xx-xx-xx-xx

IOW, setting the second least significant bit of the most significantbyte of the address gives you a locally administered addresses versus aglobally administered one.

See the rest of the thread for comments about global addresses reservedfor use by MS, VMware, KVM etc.

Any large organisation should be managing MAC addresses for VMs andvirtual network interfaces carefully, and indeed should be doing this.

As ever, a well thought out MAC addressing scheme (ooh, namingconventions again!) could be a significant aid to management in thisarea, either to reflect the physical/virtual topology or business(applications), or a mixture of the two.

Post by Paul StureYes of course, this also involves adjustments to DNS records andentries in ssh known_hosts files, but that all happens externally tothe server concerned.

[1] what kicked off my interest in this area is that a few months ago Iran into an interesting "feature" of VMware Fusion. The steps are asfollows:

a) download a VMware Fusion image and start it.b) when it comes up, Fusion will detect that the VM is not in itsoriginal location and ask whether you moved or copied it.c) On nswering "I copied it", Fusion will allocate a new MAC address toavoid a conflict with the source. Answer "I moved it", and theoriginal MAC address will remain unchanged.d) respond with "I copied it" to force the generation of a new MACaddress.e) now copy the original image to a separate system (on the same LAN)and run it up there. Answer "I copied it", just like you did on thefirst system.

You now have two virtual instances on the same LAN with the same MACaddress! They exhibit similar problems to those exhibited by duplicateIP addresses so you check those first...

[2] for completeness, changing MAC addresses on OS X / macOS

<http://osxdaily.com/2012/03/01/change-mac-address-os-x/>

Post by Stephen HoffmanProvisioning via the preferred local configuration management software,and/or distributed configuration and control and coordination via LDAP,as well.

Given the pickiness of YAML as used by Saltstack (I ran into a problemyesterday copying some code straight out of its own documentation, dueto Unicode - arrggh), the obvious way forward is to devise testedtemplates work from there.

One of Salt's strengths, the use of existing serialization systems forrepresenting SLS data, can also backfire. YAML is a general purposesystem and there are a number of things that would seem to make sense inan sls file that cause YAML issues.

...and for that matter, there are multiple steps involved in changingthe host name on non-VMS platforms too. DHCP is very desirable in anychanging environment.

The connection from some DHCP servers into DNS is handy, too. Not allsystems have that configured. There are also times when you don'twant that too, of course.

Gradually working on that.

FWIW and you may have seen this already, some combinations of DNS andDHCP servers already do this. ISC BIND calls this capability dynamicupdate, and it's desirable to have the appropriate security settings toallow these updates (only) from the intended DHCP server(s) into theDNS server(s). Windows Server also implements this capability with itsconfiguration, as well.

Post by Paul Sture..."YAML IdiosyncrasiesOne of Salt's strengths, the use of existing serialization systems forrepresenting SLS data, can also backfire. YAML is a general purposesystem and there are a number of things that would seem to make sensein an sls file that cause YAML issues.

Post by Dirk MunkI’ve often mentioned that in my view IPsec should be used between twoVMS nodes to encrypt all IP traffic. IPsec is almost non-existing in thepresent HPE TCPIP Services, but it is present in the Multinet stack, andit will be present in the new VSI TCPIP V10.5 Services.So I wanted to know how to set it up, and it proofed to be remarkablesimple.The following examples come from the MultiNet Installation andAdministrator's Guide, I give you the settings for one node.# multinet:ipsec.conf ## packet will look like this: IPv4 AH ESP payload# the node is on 10.1.1.1, peer is on 10.2.1.1# Add encryption to outgoing packets and incoming packets, both withadd 10.1.1.1 10.2.1.1 esp 9876 -E 3des-cbc “hogehogehogehogehogehoge”;add 10.2.1.1 10.1.1.1 esp 10000 -E 3des-cbc0xdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeef;add 10.1.1.1 10.2.1.1 ah 9877 -A hmac-md5 “mogamogamogamoga”;add 10.2.1.1 10.1.1.1 ah 10001 -A hmac-md5 “lowalowalowalowa”;#require that all outgoing and incoming IP traffic to and from that peerspdadd 10.1.1.1 10.2.1.1 any -P out ipsec esp/transport//useah/transport//use;spdadd 10.2.1.1 10.1.1.1 any -P in ipsec esp/transport//useah/transport//use;That’s it, all IP traffic will be encrypted and authenticated. Thatincludes Telnet, FTP, SQL, DECnet over IP:(which ever version), clusterover UDP, name it.No need for other types of encryption between these two nodes, so no SSHor TLS.Simple and elegant, just the way it should be.

If you think the above is "simple", perhaps you need to refer to a definition of"simple". A good example of Steve's arguments for simpler implementation offeatures.

I’ve often mentioned that in my view IPsec should be used between two VMSnodes to encrypt all IP traffic. IPsec is almost non-existing in thepresent HPE TCPIP Services, but it is present in the Multinet stack, andit will be present in the new VSI TCPIP V10.5 Services.So I wanted to know how to set it up, and it proofed to be remarkablesimple.The following examples come from the MultiNet Installation andAdministrator's Guide, I give you the settings for one node.# multinet:ipsec.conf ## packet will look like this: IPv4 AH ESP payload# the node is on 10.1.1.1, peer is on 10.2.1.1# Add encryption to outgoing packets and incoming packets, both withadd 10.1.1.1 10.2.1.1 esp 9876 -E 3des-cbc “hogehogehogehogehogehoge”;add 10.2.1.1 10.1.1.1 esp 10000 -E 3des-cbc0xdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeef;add 10.1.1.1 10.2.1.1 ah 9877 -A hmac-md5 “mogamogamogamoga”;add 10.2.1.1 10.1.1.1 ah 10001 -A hmac-md5 “lowalowalowalowa”;#require that all outgoing and incoming IP traffic to and from that peerspdadd 10.1.1.1 10.2.1.1 any -P out ipsec esp/transport//useah/transport//use;spdadd 10.2.1.1 10.1.1.1 any -P in ipsec esp/transport//useah/transport//use;That’s it, all IP traffic will be encrypted and authenticated. Thatincludes Telnet, FTP, SQL, DECnet over IP:(which ever version), clusterover UDP, name it.No need for other types of encryption between these two nodes, so no SSHor TLS.Simple and elegant, just the way it should be.

If you think the above is "simple", perhaps you need to refer to adefinition of "simple". A good example of Steve's arguments for simplerimplementation of features.

Post by Dirk MunkI’ve often mentioned that in my view IPsec should be used between twoVMS nodes to encrypt all IP traffic. IPsec is almost non-existing inthe present HPE TCPIP Services, but it is present in the Multinetstack, and it will be present in the new VSI TCPIP V10.5 Services.So I wanted to know how to set it up, and it proofed to be remarkablesimple.The following examples come from the MultiNet Installation andAdministrator's Guide, I give you the settings for one node.# multinet:ipsec.conf ## packet will look like this: IPv4 AH ESP payload# the node is on 10.1.1.1, peer is on 10.2.1.1# Add encryption to outgoing packets and incoming packets, both withadd 10.1.1.1 10.2.1.1 esp 9876 -E 3des-cbc “hogehogehogehogehogehoge”;add 10.2.1.1 10.1.1.1 esp 10000 -E 3des-cbc0xdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeef;add 10.1.1.1 10.2.1.1 ah 9877 -A hmac-md5 “mogamogamogamoga”;add 10.2.1.1 10.1.1.1 ah 10001 -A hmac-md5 “lowalowalowalowa”;#require that all outgoing and incoming IP traffic to and from thatspdadd 10.1.1.1 10.2.1.1 any -P out ipsec esp/transport//useah/transport//use;spdadd 10.2.1.1 10.1.1.1 any -P in ipsec esp/transport//useah/transport//use;That’s it, all IP traffic will be encrypted and authenticated. Thatincludes Telnet, FTP, SQL, DECnet over IP:(which ever version),cluster over UDP, name it.No need for other types of encryption between these two nodes, so noSSH or TLS.Simple and elegant, just the way it should be.

If you think the above is "simple", perhaps you need to refer to adefinition of "simple". A good example of Steve's arguments for simplerimplementation of features.

Yes, you do need to do a bit of reading etc. But it took me less thenhalf an hour to understand the basics.

Post by David FrobleIf you think the above is "simple", perhaps you need to refer to adefinition of "simple". A good example of Steve's arguments forsimpler implementation of features.

Yes, you do need to do a bit of reading etc. But it took me less thenhalf an hour to understand the basics.

I'd love to be in the era where we had an easy and ubiquitousconnection encryption. In the era that OSI tried to reach, forinstance. (Ignoring for the moment that DECnet-Plus and theassociated OSI management user interface was poor at best. If thatparticular zombie ever gets back upright and staggering around again,that whole area really needs some work. But I digress.) There arecertainly reasons to use IPsec, but there are also good reasons not to.Implementing OpenVMS-to-OpenVMS solutions — DECnet or otherwise — isless interesting (to me) than OpenVMS-to-whatever configurations.Even when the OpenVMS-to-OpenVMS might be slightly better by somemeasures, as I'm still going to have to deal with OpenVMS-to-otherwiseconnections, so I might as well just use the same OpenVMS-to-whateverpath and not bother mixing in the static-connection configuration orthe platform-specific OpenVMS-to-OpenVMS path. And I'd still prefera network API here, as I still have to deal with establishing a secureconnection — I can't simply expect or trust that the end-user will haveslogged through the IPsec set-up — and I still need to deal with DNS,certificates — because I may well be running TLS across an IPsec link —and for dealing with connection errors and the rest. Yes, this APIwould be OpenVMS-specific, too. So there's that. (Now I have to golook at libtls again. But I digress. Again.)

Post by Stephen HoffmanThe less effort I have to put on the end-user to establish a secureconnection, the better off we all are.

Yes! Just that. Something for people, rather than computer geeks.It should be doable, an application that presents the options, getsdata, in a "really" simple manner, and then internally maybe builds theconfiguration stuff.The configuration stuff Dirk posted is not something I ever want to wade through.

This is stuff for system managers, if a system manager can't deal withthis (after a training) the he should look for another job.

Furthermore this is typical Unix/Linux syntax, and isn't that the futureof operating systems??????

Post by Stephen HoffmanThe less effort I have to put on the end-user to establish a secureconnection, the better off we all are.

Yes! Just that. Something for people, rather than computer geeks.It should be doable, an application that presents the options, getsdata, in a "really" simple manner, and then internally maybe builds theconfiguration stuff.The configuration stuff Dirk posted is not something I ever want to wade through.

This is stuff for system managers, if a system manager can't deal withthis (after a training) the he should look for another job.

See how you computer geeks are? You want to maintain the mystic aspect. Jobsecurity or such?

Post by Dirk MunkFurthermore this is typical Unix/Linux syntax, and isn't that the futureof operating systems??????

Post by Stephen HoffmanThe less effort I have to put on the end-user to establish a secureconnection, the better off we all are.

Yes! Just that. Something for people, rather than computer geeks.It should be doable, an application that presents the options, getsdata, in a "really" simple manner, and then internally maybe builds theconfiguration stuff.The configuration stuff Dirk posted is not something I ever want to wade through.

This is stuff for system managers, if a system manager can't deal withthis (after a training) the he should look for another job.

See how you computer geeks are? You want to maintain the mysticaspect. Job security or such?

If you have no configuration options, then you don't have to make achoice. If there are options, then you have to make choices, and inorder to do so, jou must understand the effects and consequences of thechoices. It's called craftsmanship, it can not be replaced.

To think that system management, network management, programming etc. is"Fisher Price work" is a big mistake. Believe me, I've seen theconsequences of that kind of thinking.

Post by David FrobleSee how you computer geeks are? You want to maintain the mysticaspect. Job security or such?

If you have no configuration options, then you don't have to make achoice. If there are options, then you have to make choices, and inorder to do so, jou must understand the effects and consequences of thechoices. It's called craftsmanship, it can not be replaced.To think that system management, network management, programming etc. is"Fisher Price work" is a big mistake. Believe me, I've seen theconsequences of that kind of thinking.

There are a number of areas that can be made a _lot_ easier to use(especially on VMS) by means of simplified and GUI interfaces whichmeans the person carrying out the task doesn't need a detailedunderstanding of the underlying concepts.

However, I balk big time at that when it comes to security andespecially network security when you are setting up site levelor server level security (as opposed to client side security).I think that a person should be required to understand theunderlying concepts (and the UI should enforce that) before theycan configure something.

By all means make the configuration mechanisms easier to use fora knowledgeable person (and VMS can certainly use those changes)but I still think it's a bad idea to have a security UI mechanismwhich doesn't require any real understanding of what is going onunderneath.

Simon.

--Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFPMicrosoft: Bringing you 1980s technology to a 21st century world

Post by David FrobleSee how you computer geeks are? You want to maintain the mysticaspect. Job security or such?

If you have no configuration options, then you don't have to make achoice. If there are options, then you have to make choices, and inorder to do so, jou must understand the effects and consequences of thechoices. It's called craftsmanship, it can not be replaced.To think that system management, network management, programming etc. is"Fisher Price work" is a big mistake. Believe me, I've seen theconsequences of that kind of thinking.

There are a number of areas that can be made a _lot_ easier to use(especially on VMS) by means of simplified and GUI interfaces whichmeans the person carrying out the task doesn't need a detailedunderstanding of the underlying concepts.However, I balk big time at that when it comes to security andespecially network security when you are setting up site levelor server level security (as opposed to client side security).I think that a person should be required to understand theunderlying concepts (and the UI should enforce that) before theycan configure something.By all means make the configuration mechanisms easier to use fora knowledgeable person (and VMS can certainly use those changes)but I still think it's a bad idea to have a security UI mechanismwhich doesn't require any real understanding of what is going onunderneath.Simon.

Post by Dirk MunkThis is stuff for system managers, if a system manager can't deal withthis (after a training) the he should look for another job.

See how you computer geeks are? You want to maintain the mysticaspect. Job security or such?

If you have no configuration options, then you don't have to make achoice. If there are options, then you have to make choices, and inorder to do so, jou must understand the effects and consequences of thechoices. It's called craftsmanship, it can not be replaced.

Running a server is a problem that very few folks have. Very fewfolks. Networking, servers, encryption, those are all means to theend. Those are all bumps and impediments on the way to solving theproblems that the folks actually have.

Post by Dirk MunkTo think that system management, network management, programming etc.is "Fisher Price work" is a big mistake. Believe me, I've seen theconsequences of that kind of thinking.

I've watched the numbers of system managers associated withinstallations shrinking, and the efficiency of the remaining managersincreasing. We all have. Part of that is because the systems arecontinuing to become easier and more automated, and the tools to managemasses of servers continue to improve. Are there going to be systemmanagers around, and particularly for complex configurations? Sure.But there'll be fewer of them, relative to the numbers of servers andthe complexity of the networks that get deployed. There'll always bemanagement pressure to eliminate the positions, too. Some will beoutsourced, too — either to ISVs or cloud providers or service bureausor part-timer staff, too. Servers are only getting better atmanaging themselves, or of picking reasonable defaults, or of pickingup settings from configuration servers. Which means fewer mistakes,less effort, and fewer (on average) system managers. And if we'relooking at 2022 or 2027 and beyond, that means fewer configurationfiles and fewer manual set-up steps to get to a working configuration.

As compared with requiring manual IPsec configurations, embedding TLSinto the application or utilizing the existing CA framework in a servermeans I don't have to add tasks onto the list for the local systemmanagers. It also means I don't have to troubleshoot the inevitablemistakes, and it means that I don't have to go rummage the system toensure the connection is secure.

And again, TLS also means we don't have the IPsec set-up. nor anyparticular set-up requirements onto the installer nor on local systemmanagement. If we have a CA chain in the host, we have all that'snecessary to move the connection encryption requirements into theapplication.

Post by Dirk MunkThis is stuff for system managers, if a system manager can't dealwith this (after a training) the he should look for another job.

See how you computer geeks are? You want to maintain the mysticaspect. Job security or such?

If you have no configuration options, then you don't have to make achoice. If there are options, then you have to make choices, and inorder to do so, jou must understand the effects and consequences ofthe choices. It's called craftsmanship, it can not be replaced.

Running a server is a problem that very few folks have. Very fewfolks. Networking, servers, encryption, those are all means to theend. Those are all bumps and impediments on the way to solving theproblems that the folks actually have.

Post by Dirk MunkTo think that system management, network management, programming etc.is "Fisher Price work" is a big mistake. Believe me, I've seen theconsequences of that kind of thinking.

I've watched the numbers of system managers associated withinstallations shrinking, and the efficiency of the remaining managersincreasing. We all have. Part of that is because the systems arecontinuing to become easier and more automated, and the tools to managemasses of servers continue to improve. Are there going to be systemmanagers around, and particularly for complex configurations? Sure.But there'll be fewer of them, relative to the numbers of servers andthe complexity of the networks that get deployed. There'll always bemanagement pressure to eliminate the positions, too. Some will beoutsourced, too — either to ISVs or cloud providers or service bureausor part-timer staff, too. Servers are only getting better atmanaging themselves, or of picking reasonable defaults, or of picking upsettings from configuration servers. Which means fewer mistakes, lesseffort, and fewer (on average) system managers. And if we're lookingat 2022 or 2027 and beyond, that means fewer configuration files andfewer manual set-up steps to get to a working configuration.As compared with requiring manual IPsec configurations, embedding TLSinto the application or utilizing the existing CA framework in a servermeans I don't have to add tasks onto the list for the local systemmanagers. It also means I don't have to troubleshoot the inevitablemistakes, and it means that I don't have to go rummage the system toensure the connection is secure.

Really. So don't have to keep track which applications have outdated andvulnerable SSL/TLS stacks. You don't have to reinstall that software.You don't have to tell your own software department or some othersoftware club that your software needs an update. You don't have to planthat with the users. You don't have to test the new software. You don'thave to keep track of your certificates, to prevent them from becomingoutdated.

I've done that kind of work, it's a pain in the ass when you have to geta dozen managers and departments so far that you can do an update, orconvince them that they need an update.

Compare that with a quick setup of an IPsec connection by an experiencedsystem manager, it will take about half an hour.

If you have a good system manager, then he can trace and solve problemsin a short time. If you have the type of ignorant and mediocre systemmanagers you seem to prefer, then problems can take months to be solved,or they are never solved.

I've seen it, I've experienced it over decades.

Post by Stephen HoffmanAnd again, TLS also means we don't have the IPsec set-up. nor anyparticular set-up requirements onto the installer nor on local systemmanagement. If we have a CA chain in the host, we have all that'snecessary to move the connection encryption requirements into theapplication.

Post by Stephen Hoffman...I've watched the numbers of system managers associated withinstallations shrinking, and the efficiency of the remaining managersincreasing. We all have. Part of that is because the systems arecontinuing to become easier and more automated, and the tools to managemasses of servers continue to improve. Are there going to be systemmanagers around, and particularly for complex configurations? Sure.But there'll be fewer of them, relative to the numbers of servers andthe complexity of the networks that get deployed. There'll always bemanagement pressure to eliminate the positions, too. Some will beoutsourced, too — either to ISVs or cloud providers or service bureausor part-timer staff, too. Servers are only getting better atmanaging themselves, or of picking reasonable defaults, or of pickingup settings from configuration servers. Which means fewer mistakes,less effort, and fewer (on average) system managers. And if we'relooking at 2022 or 2027 and beyond, that means fewer configurationfiles and fewer manual set-up steps to get to a working configuration.As compared with requiring manual IPsec configurations, embedding TLSinto the application or utilizing the existing CA framework in a servermeans I don't have to add tasks onto the list for the local systemmanagers. It also means I don't have to troubleshoot the inevitablemistakes, and it means that I don't have to go rummage the system toensure the connection is secure.

Really.

Yes, really.

Post by Dirk MunkSo don't have to keep track which applications have outdated andvulnerable SSL/TLS stacks.

I'd prefer not to, hence my comments around an API for this. But thenIPsec doesn't do what I need. For software updates, that's managed bypushing out updates. OpenVMS folks haven't seen these approaches andtools as many of the OpenVMS servers are customized. But we're allheaded toward software that gets pushed out — whether from VSI inBolton, from the ISV, or within the organization. OpenVMS does nothave tools for that, but other boxes do. That's already a problem forOpenVMS going forward, and one that's much bigger than the securitylibraries and tools and related infrastructure.

I'm usually doing software updates more frequently than TLS APIversions are rolling forward, though pushing out a new TLS library onshort notice is still a requirement. Unless TLS is entirely avoidedfrom a server configuration, there's still going to be a requirement toquickly push out new versions for servers, too.

Post by Dirk MunkYou don't have to tell your own software department or some othersoftware club that your software needs an update.

I'd like to be in that world, but I'm not. I'd like to havedecade-long deployments, but — if I'm on the open 'net — I can't havethat.

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 OpenVMSAPIs for transport and DNS and security and authentication, as has beenmentioned. That's a slog, whether using TLS or otherwise — or usingIPsec for that matter. But then security also moves forward andincreasingly rapidly, which generally means updates. Newerrecommendations around checks and practices, as well as fixes andcorrections. Which gets back to having easier and faster softwareupdates, 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 thenew software. You don't have to keep track of your certificates, toprevent them from becoming outdated.

All of which is wonderful, but for about the zillionth time I'veexplained this, none of which is even remotely relevant to the problemat hand. Like OSI, none of what IPsec provides does anything for whatI 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 prefernot to — plus dealing with a bad IPsec UI and the rest, and whateverpatches 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 toget 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 thinkcomputing still works the same way it did, that they can still dodeployments like they used to, and can ignore updates for days or weekswith impunity. Fun times. They eventually learn.

Post by Dirk MunkCompare that with a quick setup of an IPsec connection by anexperienced system manager, it will take about half an hour.

Post by Dirk MunkIf you have a good system manager, then he can trace and solve problemsin a short time.

Having that system manager costs money, and introduces mistakes. Iwrite that as somebody that's done more than a little systemmanagement, too.

Post by Dirk MunkIf you have the type of ignorant and mediocre system managers you seemto prefer, then problems can take months to be solved, or they arenever solved.

I'd prefer to have no system managers, and having the deploymentsautomated. That's increasingly common, too. Lights Out is one ofthe older names for removing folks from the process, akin to the end ofpreventive maintenance a generation or two before it. That's not aseasy with OpenVMS as with other boxes, as the OpenVMS tools are alllocally-developed or locally-ported or not available and which means wefall back to using system managers and manual processes.

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 DECnetand OSI networking providing all interconnection, and with IPsecallowing trivial interconnections among all systems, and all the rest.I'd like to have static network configurations, full control of allthe client systems and remote servers, and with locked-down or noconnections outside of the datacenters, with trusted and secureinternal networks, with off-hour windows available for backups andmaintenance, with production and application development efforts thateach permit queuing upgrades for installation once or twice a year atmost, having to rush-install upgrades only once every year or two andhaving a week to do it. I'd certainly prefer to have skilledtechnical staff ready on-site and on-call at the customer site, andstaff that has the budget and payroll and schedule time and thetechnical ability to find and read and understand the copiousdocumentation that's inevitably available, and obviously performingeach individual installation and upgrade with due care and no matterhow complex those might be and how arcane the software and the UI mightbe. I would like to have the ability to fund large development andsupport organizations, too. But I don't, I need to operate with theenvironments customers have, and are deploying. What I'm seeing anddealing with now is only going to get faster, too. IP and TLS are partof that. Ease of use and integration desperately needs to improve.Far better automation too, as what's happening now is only going toaccelerate. And certainly, there are some folks can or do stilloperate their OpenVMS servers and systems like they're back in theclassic OpenVMS era. Good on them.

Again, no matter what benefits you can and do (correctly) point toaround IPsec over TLS or otherwise, IPsec does NOT solve thefundamental problems that I'm dealing with, around network connectionsecurity. If IPsec solves your local requirements, wonderful. Go forit. Use it.

I'm usually doing software updates more frequently than TLS API versionsare rolling forward, though pushing out a new TLS library on shortnotice is still a requirement. Unless TLS is entirely avoided from aserver configuration, there's still going to be a requirement to quicklypush out new versions for servers, too.

How are your cloud-balanced desired-state VMs going you fucking dinosaur?

Again, no matter what benefits you can and do (correctly) point toaround IPsec over TLS or otherwise, IPsec does NOT solve the fundamentalproblems that I'm dealing with, around network connection security. IfIPsec solves your local requirements, wonderful. Go for it. Use it.

Yes I've never cared for screw-drivers either because I love my hammer :-(

I'm usually doing software updates more frequently than TLS API versionsare rolling forward, though pushing out a new TLS library on shortnotice is still a requirement. Unless TLS is entirely avoided from aserver configuration, there's still going to be a requirement to quicklypush out new versions for servers, too.

How are your cloud-balanced desired-state VMs going you fucking dinosaur?

Again, no matter what benefits you can and do (correctly) point toaround IPsec over TLS or otherwise, IPsec does NOT solve the fundamentalproblems that I'm dealing with, around network connection security. IfIPsec solves your local requirements, wonderful. Go for it. Use it.

Yes I've never cared for screw-drivers either because I love my hammer :-(

Over here, a hammer is also referred to as an America screwdriver. :-)

Post by Stephen HoffmanThe less effort I have to put on the end-user to establish a secureconnection, the better off we all are.

Yes! Just that. Something for people, rather than computer geeks.It should be doable, an application that presents the options, getsdata, in a "really" simple manner, and then internally maybe builds theconfiguration stuff.The configuration stuff Dirk posted is not something I ever want to wade through.

This is stuff for system managers, if a system manager can't deal withthis (after a training) the he should look for another job.

The goal here is to automate, to make deployments reproducable,maintainable, and to make things easier on system managers, and to eveneliminate the need for as many system managers.

The more any system manager has to do manually, the more mistakeshappen, the more problems arise, and the higher the efforts and thecost and the complexity. The more system managers are needed, too.

Yes, good system managers are always trying to automete themselves outof the most menial and tedious and error-prone parts of their own jobs,too.

Post by Dirk MunkFurthermore this is typical Unix/Linux syntax, and isn't that thefuture of operating systems??????

It'd be really nice if OpenVMS were better than that, and didn't needthis sort of stuff outside of expert and bespoke configurations, too.

The less I have to deal with a server, the more reliable and morereproducable and easier it is. the more I like it, and the more I wantto use it. The more I'll recommend it, too.

Outside of hobbyists and such, managing a server is never the end-goalfor an end-user. They all have something else that they want to getdone. The server is a means. Not an end. Which means theoverarching goal here is to figure out how to make the end user into ahero. To help them get done what they want to get done. And for acommercial entity, to make money doing that. They'll put up with someoverhead to get to their goals using your server or your applicationand they'll pay (somewhat) more when they believe its necessary to doso, but that's all adding to the friction associated with the future ofyour own product.

Post by Stephen HoffmanThe less effort I have to put on the end-user to establish a secureconnection, the better off we all are.

Yes! Just that. Something for people, rather than computer geeks.It should be doable, an application that presents the options, getsdata, in a "really" simple manner, and then internally maybe builds theconfiguration stuff.The configuration stuff Dirk posted is not something I ever want to wade through.

It's part of the same disaster of DECnet-Plus. OSI is catnip fornetwork folks. It does everything. DECnet-Plus and OSI were (are)great ideas, massively capable and extremely flexible, marvelouslycapable system, one of the most elegant and consistent implementations.Also a blasted and complete and utter disaster to implement a newclient or new server under EMA — all of those capabilities andflexibilities meant even the common cases were a whole lot moredifficult to implement, and hacked-together control programs are mucheasier — and the whole user interface for DECnet-Plus is an intractablemorass of reading for any doesn't-want-to-be-an-expert user to performeven a baseline server configuration for DECnet-Plus networking. Forthe folks that just want to get connected and going, or to troubleshootwhat should be a baseline problem.

Most (all?) of those issues could have been fixed given enough time andthought of course, and by removing more than a little of theflexibility from the default paths, but the computing market decidedthat cheap and mostly works and simpler to deal with was good enoughand went with IP and largely while the OSI folks weren't looking, andwere off solving, well, pretty much everything. This rather thanchoosing the better and elegant and expensive and late-to-market OSIimplementations.

Looking back, the market went the right way, too. They had work to doand budgets to keep, and OSI wasn't ready yet.

But then with OSI or with IP or with most anything else, we are NOT inthe same world that OpenVMS once was. We need OpenVMS and our ownapplications to be much simpler to configure and use. Configurationfiles are not the path forward, outside of knobs that only occasionallyneed to be tweaked, and only by experts. Worse on OpenVMS, there'snot even a consistent API and parser for this configuration file stuff,so we're all implementing our own and unique and less-than-robustversions of configuration files, which just adds to the problems.Nor should system parameter adjustments be a manual part of standardapplication installs and configurations, for that matter. That allneeds to be automatic. So should connections into Open Directory orActive Directory, pre-loaded certificates, easier patching, among otherenhancements.

Expecting all users to edit configuration files or MODPARAMS or such —for even baseline configurations of the server software, or for yourown application deployments and software — and you're on the wrongpath, or you're planning on bespoke configurations and basing yourbusiness revenues on providing those customizations for the end-users.

Somewhat more succinct idea of where we are and where we are headed?Take a look at most any of the existing installation manuals, andpaying folks to figure out how to remove as many pages and as manysteps and as much complexity as you can. Then remove some more. Thenlook at what's involved with downloading patches, and start slashingand burning there, too. That's where we are now or soon will be withother systems; looking forward at 2022 or 2027, too.

Post by Stephen HoffmanThe less effort I have to put on the end-user to establish a secureconnection, the better off we all are.

Yes! Just that. Something for people, rather than computer geeks.It should be doable, an application that presents the options, getsdata, in a "really" simple manner, and then internally maybe buildsthe configuration stuff.The configuration stuff Dirk posted is not something I ever want to wade through.

It's part of the same disaster of DECnet-Plus. OSI is catnip fornetwork folks. It does everything. DECnet-Plus and OSI were (are)great ideas, massively capable and extremely flexible, marvelouslycapable system, one of the most elegant and consistent implementations.Also a blasted and complete and utter disaster to implement a new clientor new server under EMA — all of those capabilities and flexibilitiesmeant even the common cases were a whole lot more difficult toimplement, and hacked-together control programs are much easier — andthe whole user interface for DECnet-Plus is an intractable morass ofreading for any doesn't-want-to-be-an-expert user to perform even abaseline server configuration for DECnet-Plus networking. For thefolks that just want to get connected and going, or to troubleshoot whatshould be a baseline problem.

I checked the authors of the IPsec RFC's absolutely no link with DEC. IfIPsec would have had anything to do with DECnet-Plus, then it would havebeen a part of TCPIP Services, It was not, or hardly.

I don't know where the Multinet stack came from, but I'm quite sure itis based on a Unix/Linux stack.

There are no links with DECnet-Plus, this is pure Unix style.

I also checked how IPsec is configured on Solaris, far worse then withMultinet.

Post by Stephen HoffmanMost (all?) of those issues could have been fixed given enough time andthought of course, and by removing more than a little of the flexibilityfrom the default paths, but the computing market decided that cheap andmostly works and simpler to deal with was good enough and went with IPand largely while the OSI folks weren't looking, and were off solving,well, pretty much everything. This rather than choosing the better andelegant and expensive and late-to-market OSI implementations.

Sure. it only means that that hadn't thought about the very limitedaddress space of IPv4, and now they have rebuild their networks andapplications to make them suitable for IPv6, and IPv6 isn't even anofficial internet standard.

Hurray, magnificent, I'm impressed.

Post by Stephen HoffmanLooking back, the market went the right way, too. They had work to doand budgets to keep, and OSI wasn't ready yet.

And neither was IP. OSI was ready for the future with its 160 bitaddress space, IPv4 with its 32 bit address space not, so now we get anew IP.

Post by Stephen HoffmanBut then with OSI or with IP or with most anything else, we are NOT inthe same world that OpenVMS once was. We need OpenVMS and our ownapplications to be much simpler to configure and use. Configurationfiles are not the path forward, outside of knobs that only occasionallyneed to be tweaked, and only by experts. Worse on OpenVMS, there's noteven a consistent API and parser for this configuration file stuff, sowe're all implementing our own and unique and less-than-robust versionsof configuration files, which just adds to the problems. Nor shouldsystem parameter adjustments be a manual part of standard applicationinstalls and configurations, for that matter. That all needs to beautomatic. So should connections into Open Directory or ActiveDirectory, pre-loaded certificates, easier patching, among otherenhancements.Expecting all users to edit configuration files or MODPARAMS or such —for even baseline configurations of the server software, or for your ownapplication deployments and software — and you're on the wrong path, oryou're planning on bespoke configurations and basing your businessrevenues on providing those customizations for the end-users.Somewhat more succinct idea of where we are and where we are headed?Take a look at most any of the existing installation manuals, and payingfolks to figure out how to remove as many pages and as many steps and asmuch complexity as you can. Then remove some more. Then look atwhat's involved with downloading patches, and start slashing and burningthere, too. That's where we are now or soon will be with othersystems; looking forward at 2022 or 2027, too.

Post by Stephen HoffmanBut then with OSI or with IP or with most anything else, we are NOT inthe same world that OpenVMS once was. We need OpenVMS and our ownapplications to be much simpler to configure and use. Configurationfiles are not the path forward, outside of knobs that only occasionallyneed to be tweaked, and only by experts. Worse on OpenVMS, there's noteven a consistent API and parser for this configuration file stuff, sowe're all implementing our own and unique and less-than-robust versionsof configuration files, which just adds to the problems. Nor shouldsystem parameter adjustments be a manual part of standard applicationinstalls and configurations, for that matter. That all needs to beautomatic. So should connections into Open Directory or ActiveDirectory, pre-loaded certificates, easier patching, among otherenhancements.Expecting all users to edit configuration files or MODPARAMS or such —for even baseline configurations of the server software, or for your ownapplication deployments and software — and you're on the wrong path, oryou're planning on bespoke configurations and basing your businessrevenues on providing those customizations for the end-users.Somewhat more succinct idea of where we are and where we are headed?Take a look at most any of the existing installation manuals, and payingfolks to figure out how to remove as many pages and as many steps and asmuch complexity as you can. Then remove some more. Then look atwhat's involved with downloading patches, and start slashing and burningthere, too. That's where we are now or soon will be with othersystems; looking forward at 2022 or 2027, too.

I completely agree that:* simple configuration is essential* much on VMS is way beyond below expectations of today for simplicity* no common config file format is a problem

But I totally disagree with the idea that configuration files is notthe path forward.

Post by Stephen HoffmanBut then with OSI or with IP or with most anything else, we are NOT inthe same world that OpenVMS once was. We need OpenVMS and our ownapplications to be much simpler to configure and use. Configurationfiles are not the path forward, outside of knobs that only occasionallyneed to be tweaked, and only by experts. Worse on OpenVMS, there's noteven a consistent API and parser for this configuration file stuff, sowe're all implementing our own and unique and less-than-robust versionsof configuration files, which just adds to the problems. Nor shouldsystem parameter adjustments be a manual part of standard applicationinstalls and configurations, for that matter. That all needs to beautomatic. So should connections into Open Directory or ActiveDirectory, pre-loaded certificates, easier patching, among otherenhancements.Expecting all users to edit configuration files or MODPARAMS or such —for even baseline configurations of the server software, or for your ownapplication deployments and software — and you're on the wrong path, oryou're planning on bespoke configurations and basing your businessrevenues on providing those customizations for the end-users.Somewhat more succinct idea of where we are and where we are headed?Take a look at most any of the existing installation manuals, and payingfolks to figure out how to remove as many pages and as many steps and asmuch complexity as you can. Then remove some more. Then look atwhat's involved with downloading patches, and start slashing and burningthere, too. That's where we are now or soon will be with othersystems; looking forward at 2022 or 2027, too.

* simple configuration is essential* much on VMS is way beyond below expectations of today for simplicity* no common config file format is a problemBut I totally disagree with the idea that configuration files is notthe path forward.A) app specific text config file to be editedB) app specific binary config file and admin GUIC) one big binary config file and admin GUI for each appIn the server market #A has won. It is what the market wants.Arne

There is another alternative.

Text file(s) to hold the config data, and, a GUI tool to use the data to presentthe options to the user in an easy to use format. Having a text file allows, onrare (hopefully) occasions for a knowledgeable user to make modifications thatthe GUI is not set up to do. Key words "knowledgeable user".

I don't like non-text. Too much like, "keep your nose out, you've no businesshere". Maybe I don't, but it should be my decision.

Post by Stephen HoffmanBut then with OSI or with IP or with most anything else, we are NOT inthe same world that OpenVMS once was. We need OpenVMS and our ownapplications to be much simpler to configure and use. Configurationfiles are not the path forward, outside of knobs that only occasionallyneed to be tweaked, and only by experts. Worse on OpenVMS, there's noteven a consistent API and parser for this configuration file stuff, sowe're all implementing our own and unique and less-than-robust versionsof configuration files, which just adds to the problems. Nor shouldsystem parameter adjustments be a manual part of standard applicationinstalls and configurations, for that matter. That all needs to beautomatic. So should connections into Open Directory or ActiveDirectory, pre-loaded certificates, easier patching, among otherenhancements.Expecting all users to edit configuration files or MODPARAMS or such —for even baseline configurations of the server software, or for your ownapplication deployments and software — and you're on the wrong path, oryou're planning on bespoke configurations and basing your businessrevenues on providing those customizations for the end-users.Somewhat more succinct idea of where we are and where we are headed?Take a look at most any of the existing installation manuals, and payingfolks to figure out how to remove as many pages and as many steps and asmuch complexity as you can. Then remove some more. Then look atwhat's involved with downloading patches, and start slashing and burningthere, too. That's where we are now or soon will be with othersystems; looking forward at 2022 or 2027, too.

* simple configuration is essential* much on VMS is way beyond below expectations of today for simplicity* no common config file format is a problemBut I totally disagree with the idea that configuration files is notthe path forward.A) app specific text config file to be editedB) app specific binary config file and admin GUIC) one big binary config file and admin GUI for each appIn the server market #A has won. It is what the market wants.Arne

There is another alternative.Text file(s) to hold the config data, and, a GUI tool to use the data to presentthe options to the user in an easy to use format. Having a text file allows, onrare (hopefully) occasions for a knowledgeable user to make modifications thatthe GUI is not set up to do. Key words "knowledgeable user".I don't like non-text. Too much like, "keep your nose out, you've no businesshere". Maybe I don't, but it should be my decision.

Dave, have you been getting out a bit too much, onthe quiet?

A GUI (and/or text-mode equivalent) largely backedby text config files and associated modularconfiguration handlers is the way configmanagement has been done on SuSe Linux (andrelated) for decades.

The tool is called Yast (yet another setup tool)and development goes back to the 1990s, so it may notbe trendy enough for everyone, though today's Yasthas probably changed quite a lot in detail sincethose days.

It administers pretty much everything I expect frommy Linuxes, and quite possibly what any reasonablesysadmin could expect in most places. Its underlyingarchitecture and much of its implementation probablycould work elsewhere than Suse, maybe even elsewherethan Linux. Things like replicated configs and suchare apparently handled too, though it's been a whilesince I used those features.

Other Linuxes generally don't have the same approachyet ("the nice thing about standards is there are somany to choose from"). Nothing wrong with "different"but no other Linux I've tried comes anywhere close,including hiptrendy ones like Ubuntu, Fedora, etc.I could be out of date by now, I eventually saw nopoint in looking elsewhere.

Further reading:Suse Linux:https://en.wikipedia.org/wiki/SUSE_Linux_distributionsYast background (2004):https://www.novell.com/coolsolutions/feature/1649.htmlYast in more recent times:https://en.wikipedia.org/wiki/YaST

Post by David FrobleThere is another alternative.Text file(s) to hold the config data, and, a GUI tool to use the datato present the options to the user in an easy to use format.

I use command-line tools for that. Some tools use that approachwithin themselves — such as postconf within Postfix SMTP server, forthose that have used that mail server — and some platforms offercommand-line and GUI interfaces. GUI for the most common changes,command-line changes for most of the rest, editing configuration filesfor the most arcane and unusual. OpenVMS has nothing here. Noconfiguration file API, no parser, no command tools, no GUI. (Notoutside of the X11 tools and the OpenVMS Management Station and a fewother baubles that just aren't set up for widespread use. Not thatsome descendent of OMS isn't likely, if VSI goes fully server-only withOpenVMS.) Everybody rolls their own. Which means we get somethingunderneath MAIL for those settings, something else under Notes,something yet else under each application, under SYSGEN/SYSMAN/SYSBOOT,LOGIN.COM and SYLOGIN.COM and SET TERMINAL et al, the utter *joy* thatis the DEC C RTL logical name configuration mechanism, etc...

SYSMAN tried to provide for some of this, but never got any sort ofcustomization or add-on capability, application-accessible APIs orsuch, and didn't itself become widespread for other purposes; just afew core bits.

Post by Arne VajhÃ¸jBut I totally disagree with the idea that configuration files is notthe path forward.A) app specific text config file to be editedB) app specific binary config file and admin GUIC) one big binary config file and admin GUI for each appIn the server market #A has won. It is what the market wants.

There is another alternative.Text file(s) to hold the config data, and, a GUI tool to use the data topresent the options to the user in an easy to use format. Having a textfile allows, on rare (hopefully) occasions for a knowledgeable user tomake modifications that the GUI is not set up to do. Key words"knowledgeable user".

Post by Arne VajhÃ¸jBut I totally disagree with the idea that configuration files is notthe path forward.A) app specific text config file to be editedB) app specific binary config file and admin GUIC) one big binary config file and admin GUI for each appIn the server market #A has won. It is what the market wants.

There is another alternative.Text file(s) to hold the config data, and, a GUI tool to use the data topresent the options to the user in an easy to use format. Having a textfile allows, on rare (hopefully) occasions for a knowledgeable user tomake modifications that the GUI is not set up to do. Key words"knowledgeable user".

That is also an option.But I do not believe in that either.The sysadm types know how to edit a config file.GUI only makes sense to me if it is going to be usedby end users.Arne

Well, if you're reading what Steve writes, there will be less sysadm types, andmore need for simpler roll out of systems.

Not saying I'm drinking that kool aid ....

Regardless, knowledge, or not, who hasn't had typos? When a tool can see thatsome syntax isn't correct, and can warn, and make suggestions, isn't that betterregardless of expertise?

Post by Arne VajhÃ¸jBut I totally disagree with the idea that configuration files is notthe path forward.A) app specific text config file to be editedB) app specific binary config file and admin GUIC) one big binary config file and admin GUI for each appIn the server market #A has won. It is what the market wants.

There is another alternative.Text file(s) to hold the config data, and, a GUI tool to use the data topresent the options to the user in an easy to use format. Having a textfile allows, on rare (hopefully) occasions for a knowledgeable user tomake modifications that the GUI is not set up to do. Key words"knowledgeable user".

That is also an option.But I do not believe in that either.The sysadm types know how to edit a config file.GUI only makes sense to me if it is going to be usedby end users.

Well, if you're reading what Steve writes, there will be less sysadmtypes, and more need for simpler roll out of systems.Not saying I'm drinking that kool aid ....Regardless, knowledge, or not, who hasn't had typos? When a tool cansee that some syntax isn't correct, and can warn, and make suggestions,isn't that better regardless of expertise?

...But I totally disagree with the idea that configuration files is notthe path forward.A) app specific text config file to be editedB) app specific binary config file and admin GUIC) one big binary config file and admin GUI for each appIn the server market #A has won. It is what the market wants.Arne

I'm working with server systems that completely avoid the need foraccessing configuration files for common installations andconfigurations. This is not some future server fantasy, this isworking servers and available software and hardware. Simplerapproaches — simpler for the end-users and the customers, but more workand more thought for the folks that have to design and write and testand deploy the server-related software that allows this simplicity —are easier on the end-users, and is only going to become more commonfrom server software vendors, too.

Underneath the installation processes and configuration utilities forthose servers, there's a morass of subsystem-specific parsers forsubsystem-specific configuration files, there's APIs and storage basedon and integrated with LDAP, and a decent and generic layer of toolsand parsers for the platform-specific configuration files. Yes, notwhat I'd want, but that's what we get when integrating code fromdisparate sources.

The platform-specific tools also allow easier integration with profilemanagement tools and automated deployments. Yes, it's possible toimplement profiles and deployment tools that contend with thesubsystem-specific tools, but that adds to the complexity and testing.And if I'm going to do the deployments in an automated fashion — whichI will usually prefer to do, when I'm outside of the defaultinstallation — I'll want to stay within whatever the profile managementtools uses for the target device — server, client, whatever —configuration interface.

If I have to create a configuration file on that platform as adeveloper, I'm going to use the platform-specific tools, becausethey're easier to use, the parser and the APIs are already written anddebugs, and they're very flexible. I'm probably also not going to behand-editing those files, as that's unnecessary given the command-linetools and callable APIs. But editing those files manually — aserror-prone as that can be — is possible. OpenVMS utterly lacks astandard format and APIs and a parser for this, so there's no choicebut to continue with the configuration file disaster; with the hostname scattered all over the place, the user settings all over theplace, with no standard directories for application-specific settingsfiles either per-user or system-wide, etc. It's all ad-hoc, no-rules,roll-your-own build-it-from-scratch. OpenVMS has utterly no clue aboutusing LDAP for that matter, and that's insane in this era. And nowtake a good, detailed, honest look at what that has produced for us onOpenVMS: go change your host name. Want another? Go sort out thecertificate implementation. Need another? There's the utter joy thatis MODPARAMS and AUTOGEN and SYSBOOT, and the knock-off complexity allthat produces and particularly if you want your apps to not simply fallover with weird errors when some setting isn't quite right.

OpenVMS seemingly revels in exposing complexity to the ISV and end-userdevelopers, to the end-users, and even to the OpenVMS developers.

This also ties into why I'd prefer to see Apache or nginx and othernow-table-stakes tools integrated into the base distro, because they'llbe in the same place, and all of us working on add-on software won'thave to conditionalize and complex-ify and glue-code-ify to deal withall of the installation permutations that result from this ad-hoc,no-rules, roll-your-own build-it-from-scratch server-construction-kitapproach. Disk space doesn't cost YS$12K for a 456 MB RA81 anymore;buying more space is cheap, and we're not short on disk space anymore.Trade-offs change — we have more and cheaper storage, more servers,less staff, etc. If you don't need Apache or nginx or SMTP or DNSservices or the rest in your particular server configuration, leavethem shut them off. But for those of us that do have thosedependencies for add-on software or — much more perniciously — coulduse those tools or services but don't because of the effort involved,this eliminates massive quantities of baggage and glue code andinstallation documentation and troubleshooting; of integrating with thewhere-the-sneakers-is-that-package-installed-on-THIS-server morass thatarises, and also with the configuration files being scattered all overthe place, and with more easily replicating deployments for that matter.

This complexity and the associated messes don't come from anywhere strange.

I don't see the future of servers and of applications as bespokeconfiguration files. Bespoke configuration files will certainly bearound and used and even newly created long after I'm past caring aboutthis certainly, but the need to manually edit configuration files willincreasingly not be in the installation path or the default operationspath. But we're already rolling out guest images and containers andLDAP integration and MDM tools, among other details.

...But I totally disagree with the idea that configuration files isnot the path forward.A) app specific text config file to be editedB) app specific binary config file and admin GUIC) one big binary config file and admin GUI for each appIn the server market #A has won. It is what the market wants.

I'm working with server systems that completely avoid the need foraccessing configuration files for common installations andconfigurations. This is not some future server fantasy, this is workingservers and available software and hardware.

Impressive.

Post by Stephen HoffmanSimpler approaches —simpler for the end-users and the customers, but more work and morethought for the folks that have to design and write and test and deploythe server-related software that allows this simplicity — are easier onthe end-users, and is only going to become more common from serversoftware vendors, too.

To me it seems like the trend is going in the opposite direction.

Post by Stephen HoffmanUnderneath the installation processes and configuration utilities forthose servers, there's a morass of subsystem-specific parsers forsubsystem-specific configuration files, there's APIs and storage basedon and integrated with LDAP, and a decent and generic layer of tools andparsers for the platform-specific configuration files.

Is it true generic product or is it a custom setup for a specificcustomer?

Post by Stephen HoffmanIf I have to create a configuration file on that platform as adeveloper, I'm going to use the platform-specific tools, because they'reeasier to use, the parser and the APIs are already written and debugs,and they're very flexible. I'm probably also not going to behand-editing those files, as that's unnecessary given the command-linetools and callable APIs.

Text config files can be edited manually, but they are also easyto edit automatically - either specific tools or general textfile manipulation tools. Editing is editing.

Post by Stephen HoffmanBut editing those files manually — aserror-prone as that can be — is possible. OpenVMS utterly lacks astandard format and APIs and a parser for this, so there's no choice butto continue with the configuration file disaster;

Post by Stephen Hoffmanwith the host namescattered all over the place, the user settings all over the place, withno standard directories for application-specific settings files eitherper-user or system-wide, etc. It's all ad-hoc, no-rules, roll-your-ownbuild-it-from-scratch. OpenVMS has utterly no clue about using LDAP forthat matter, and that's insane in this era. And now take a good,detailed, honest look at what that has produced for us on OpenVMS: gochange your host name.

Yep.

Post by Stephen HoffmanWant another? Go sort out the certificateimplementation. Need another? There's the utter joy that is MODPARAMSand AUTOGEN and SYSBOOT, and the knock-off complexity all that producesand particularly if you want your apps to not simply fall over withweird errors when some setting isn't quite right.

Yep.

Post by Stephen HoffmanThis also ties into why I'd prefer to see Apache or nginx and othernow-table-stakes tools integrated into the base distro, because they'llbe in the same place, and all of us working on add-on software won'thave to conditionalize and complex-ify and glue-code-ify to deal withall of the installation permutations that result from this ad-hoc,no-rules, roll-your-own build-it-from-scratch server-construction-kitapproach. Disk space doesn't cost YS$12K for a 456 MB RA81 anymore;buying more space is cheap, and we're not short on disk space anymore.Trade-offs change — we have more and cheaper storage, more servers, lessstaff, etc. If you don't need Apache or nginx or SMTP or DNS servicesor the rest in your particular server configuration, leave them shutthem off. But for those of us that do have those dependencies foradd-on software or — much more perniciously — could use those tools orservices but don't because of the effort involved, this eliminatesmassive quantities of baggage and glue code and installationdocumentation and troubleshooting; of integrating with thewhere-the-sneakers-is-that-package-installed-on-THIS-server morass thatarises, and also with the configuration files being scattered all overthe place, and with more easily replicating deployments for that matter.

I agree.

Post by Stephen HoffmanI don't see the future of servers and of applications as bespokeconfiguration files. Bespoke configuration files will certainly bearound and used and even newly created long after I'm past caring aboutthis certainly, but the need to manually edit configuration files willincreasingly not be in the installation path or the default operationspath. But we're already rolling out guest images and containers andLDAP integration and MDM tools, among other details.

Post by Stephen HoffmanI'm working with server systems that completely avoid the need foraccessing configuration files for common installations andconfigurations. This is not some future server fantasy, this isworking servers and available software and hardware.

Impressive.

Normal. Obvious. Straightforward. Simple. Once you've seen thisstuff used, you start wondering why it isn't more common, and you alsostart to incorporate this into your own designs, too.

Post by Arne VajhÃ¸jSimpler approaches —simpler for the end-users and the customers, butmore work and more thought for the folks that have to design and writeand test and deploy the server-related software that allows thissimplicity — are easier on the end-users, and is only going to becomemore common from server software vendors, too.To me it seems like the trend is going in the opposite direction.

What direction do you want the developers of an operating system towork toward, both for themselves and for their own and third-partydevelopers? Toward chaos and anarchy, or toward simpler and easier?

Post by Stephen HoffmanUnderneath the installation processes and configuration utilities forthose servers, there's a morass of subsystem-specific parsers forsubsystem-specific configuration files, there's APIs and storage basedon and integrated with LDAP, and a decent and generic layer of toolsand parsers for the platform-specific configuration files.

Is it true generic product or is it a custom setup for a specific customer?

Generic. Standard. Readily available for purchase. Not at allcustom, nor a customer-specific product.

But again, it doesn't matter where this these details come from or whatyou might think about a particular platform or software package — whereany particular good or bad ideas are found — it's how these ideas andapproaches change how we design and code our applications. What welearn from, and what are the results for our end-users and for ourcustomers.

Post by Stephen HoffmanIf I have to create a configuration file on that platform as adeveloper, I'm going to use the platform-specific tools, becausethey're easier to use, the parser and the APIs are already written anddebugs, and they're very flexible. I'm probably also not going to behand-editing those files, as that's unnecessary given the command-linetools and callable APIs.

Text config files can be edited manually, but they are also easy toedit automatically - either specific tools or general text filemanipulation tools. Editing is editing.

Sure. Now you have to find the file, and either manually edit or codea specific parser-generator for the format, and deal with all thepermutations and testing that results. If you're coding your own app,rolling your own parser is an afterthought — trivial, easy, simple, etc— but which easily balloons into special cases and on-going maintenanceand testing cases and parser error recovery and a whole host of othertopics that arise over time. Or the developer ignores all that, andthe app crashes with some weird error when column 42 of line 627contains an unexpected character, and things get really weird when aVFC file is fed into Apache and things blow up. As has happened onseveral occasions, of course.

Post by Stephen HoffmanBut editing those files manually — as error-prone as that can be — ispossible. OpenVMS utterly lacks a standard format and APIs and aparser for this, so there's no choice but to continue with theconfiguration file disaster;

Yes.And there are plenty of examples of standardization.Java properties, Java preferences, .NET app/web.config, YAML, old INIfile format, modern JSON etc..

Any number of options. I'm not particular what's used — even SQLitedatabases would work here — so long as there's an easy mechanism fortranslating from text to binary and back if the data is stored in anencoded format, and for accessing the contents of the configurationfile from the command line and from the application at run-time, andthere's a decent generic parser for processing the files.

What's most interesting for an operating system is to try to bring somesanity to what the operating system itself and the associated layeredproducts do, and what products and packages that are integrated withthe operating system (usually) do. That's preferably not forcing thesystem managers to learn each different formats and schemes andconfiguration file locations and the rest. Unfortunately, that's alsoexactly what OpenVMS currently forces system managers to do, anddevelopers and documentation folks to deal with and to describe.

Post by Stephen Hoffmanwith the host name scattered all over the place, the user settings allover the place, with no standard directories for application-specificsettings files either per-user or system-wide, etc. It's all ad-hoc,no-rules, roll-your-own build-it-from-scratch. OpenVMS has utterly noclue about using LDAP for that matter, and that's insane in this era.And now take a good, detailed, honest look at what that has producedfor us on OpenVMS: go change your host name.

...

Post by Stephen HoffmanI don't see the future of servers and of applications as bespokeconfiguration files. Bespoke configuration files will certainly bearound and used and even newly created long after I'm past caring aboutthis certainly, but the need to manually edit configuration files willincreasingly not be in the installation path or the default operationspath. But we're already rolling out guest images and containers andLDAP integration and MDM tools, among other details.

For provisioning the address and the rest, That's a profile file that'stypical on the systems I work with. Different format than what'sshown, but you can load all sorts of configuration data that way.

As for:

ip_address = 192.168.1.10ip_net_size = 8

I'd move to:

ip_address 192.168.1.10/24

Again, if you're having to deal with humans in these cases, then usehuman notation, and try to avoid having interconnected settings whereyou can manage it. I'd likely alsio want the DECnet settings block tobe separate from the IP settings, too; a separate block within theconfiguration file. Again, all of this is implemented in othersystems now, so there are examples to learn from. Both what can bedone and how, as well as existing designs that just don't work well andare best avoided.

And I'd prefer to have a command-line command such as the followingextremely hypothetical DCL-ish command, so I don't have to find andopen the file and edit it, and potentially deal with any odd charactersor typos in the resulting configuration file...

to set the host address and subnet, the gateway, and the DNS servers.Thanks to DCL, I'm either forced to quote the subnet, or specify aseparate qualifier.

As an alternative to these sorts of configuration steps — as a numberof folks I deal with do — use mDNS and DHCP to establish the settingsand/or to acquire the settings that have not been explicitly referenced.

OpenVMS was once commonly using this sort of configuration toolapproach — often with Control Program (CP) as the suffix on thefilename — that edited and managed the configuration files for theuser, and handled syntax errors and related processing. In recentyears, the configuration files have increasingly become directlyexposed. And that occasionally tip over when some change usesincorrect syntax, and which is an error that might occur months afterthe change was made because we all know everybody doesn't always syntaxcheck or reboot the application or the server right after the change.Some of these bugs can lurk for months, and some reboot a year latercan tip over and cause a scramble when some service reports a weirderror or — as has happened — when the TCP/IP Server SMTP mail serversilently turns itself into an open relay due to an errant logical namesetting.

Ayup. Or avoid all this, if the server asks the DHCP server for thisstuff, and loads the network configuration data automatically from theDHCP server and/or from the profile server and/or the local mDNSconfiguration, etc. All the configuration is acquired via the DHCPand/or profile server or LDAP or such, and nobody needs to log into thejust-installed OpenVMS box.

Careful now Master Hoffman, last time I suggested the VMS manager be made redundant the knifes cane it in force :-)

I still think it should be a vision. For those sharpening the knives again, a vision statement is just that, something you work towards as an ideal, not something you actually can obtain. I think this attitude moulds where VMS should be heading instead of the shit we have now, which is nothing more than a plitheral of years of lack of fuses planning all spread over the place. It's not just unattractive, it's butt ugly

What VMS has in its favour is uniformity by way of the English language

English has an incredible amount of redundancy built into it, redundancy that a lot of other languages don't have, so you can have parts missing and yet still comprehend meaning

VMS has capitalised on this with it's parameters and options, UNIX cannot match this with it's inconsistent switches because it choose abbreviation which resulted in loss of information redundancy

So, how can VMS capitalise on this further?

By consistency of design, which means an overall framework

Fora framework to integrate well, you need a common information interchange format. UNIX has stream files, VMS has records. This allows UNIX to export/import without structural concerns but the format knowledge is then passed on down to the utility to know. It has distinct advantages in allowing a disjointed OS to work with it's components

VMS as it stands cannot even do this. Utilities don't work nice with one another and God forbid if you wish to work with the rest of the world

VMS either transforms itself to be OO based at its heart and then objects are known across the spectrum and easily worked with or it employs a common interface format, like XML or json and modernises itself that way, but at least do something to begin to unify it's internal framework so as to build upon to reach new heights

Once that is done, then we can start to unify and integrate the various aspects of VMS so that networking, storage, clustering, management etc etc etc all form a unified and consist view our we will end up like UNIX, lots of utilities with little integration

Ayup. Or avoid all this, if the server asks the DHCP server for thisstuff, and loads the network configuration data automatically from theDHCP server and/or from the profile server and/or the local mDNSconfiguration, etc. All the configuration is acquired via the DHCPand/or profile server or LDAP or such, and nobody needs to log into thejust-installed OpenVMS box.

Before I left HP, I heard that the HP-IT groups were looking at DHCP serving (longer TTL's) supported by IPAM based solutions for all of their internal IT servers.

Not sure if this happened or not, but like most large shops today, since all of their internal servers had between 2 and 5 separate VLANS on EACH server (Prod, Mgmt, Cluster (Vmotion etc.), Backup etc.), you can see why moving to remote based IPAM (IP Address Mgmt) solutions is likely the way to go once you cross a threshold of X TCPIP addresses to manage manually. Add in IPV6 and IPAM is no longer an option for med-large shops.

I do agree the next step for med-large shops should be much improved profile based mgmt. of servers (can still include custom) that serves profiles (gold images with pre-installed agents start-up files etc.) not unlike how IPAM manages IP addresses.

Reference:

IP Address Management Tools – A Review of Some of the Best IPAM Tools Available Today (Feb 2015)http://bit.ly/2jjSMbg

Post by David FrobleIf you think the above is "simple", perhaps you need to refer to adefinition of "simple". A good example of Steve's arguments forsimpler implementation of features.

Yes, you do need to do a bit of reading etc. But it took me less thenhalf an hour to understand the basics.

I'd love to be in the era where we had an easy and ubiquitous connectionencryption. In the era that OSI tried to reach, for instance.

Yes, OSI had a design behind it. The OSI designers knew there were manydifferent operating systems that needed to be connected, not just Unix.So they designed something like FTAM, FAL but the OSI version. Alas theIt world choose to use the quick and dirty IP methods.

(Ignoring for the moment that DECnet-Plus and the associated OSImanagement user interface was poor at best. If that particular zombieever gets back upright and staggering around again, that whole areareally needs some work. But I digress.)

Sure, after 20 years of neglect, there would be a lot of work to do.

There are certainly reasonsto use IPsec, but there are also good reasons not to. ImplementingOpenVMS-to-OpenVMS solutions — DECnet or otherwise — is lessinteresting(to me) than OpenVMS-to-whatever configurations. Even when theOpenVMS-to-OpenVMS might be slightly better by some measures, as I'mstill going to have to deal with OpenVMS-to-otherwise connections, soI might as well just use the same OpenVMS-to-whatever path and notbothermixing in the static-connection configuration or the platform-specificOpenVMS-to-OpenVMS path.

You know very well that IPsec can also be used for VMS-to-whatever, orwhatever-to-whatever. I was concentrating on the VMS <> VMScommunication because of the difficulty in encrypting protocols likeDECnet over IP or the cluster over UDP protocol.

And I'd still prefer a network API here,

Yes, I would also like to see a lot of things that aren't there. Notonly in VMS, but in IP also. Most IP solutions that I see arehalf-baked, because IP is one big hobby project.

asI still have to deal with establishing a secure connection — I can'tsimply expect or trust that the end-user will have slogged through theIPsec set-up

The end-user will not do that, this is work for the system manager.

— and I still need to deal with DNS, certificates —becauseI may well be running TLS across an IPsec link — and for dealing withconnection errors and the rest. Yes, this API would beOpenVMS-specific, too. So there's that. (Now I have to go look atlibtls again. But I digress. Again.)https://www.k2esec.com/network-security-protocols-ipsec-vs-tlsssl-vs-ssh-part-ii/http://security.stackexchange.com/questions/42990/which-is-better-for-server-to-server-communication-ipsec-or-tlsetc,The less effort I have to put on the end-user to establish a secureconnection, the better off we all are.

Great, then IPsec is wonderful. The end-user always has a secureconnection if IPsec exists between the systems. He isn't even aware ofsecurity problems.

Post by David FrobleIf you think the above is "simple", perhaps you need to refer to adefinition of "simple". A good example of Steve's arguments forsimpler implementation of features.

Yes, you do need to do a bit of reading etc. But it took me less thenhalf an hour to understand the basics.

I'd love to be in the era where we had an easy and ubiquitous connectionencryption. In the era that OSI tried to reach, for instance.

Yes, OSI had a design behind it. The OSI designers knew there were manydifferent operating systems that needed to be connected, not just Unix. Sothey designed something like FTAM, FAL but the OSI version. Alas the Itworld choose to use the quick and dirty IP methods.

(Ignoring for the moment that DECnet-Plus and the associated OSImanagement user interface was poor at best. If that particular zombieever gets back upright and staggering around again, that whole areareally needs some work. But I digress.)

Sure, after 20 years of neglect, there would be a lot of work to do.

There are certainly reasonsto use IPsec, but there are also good reasons not to. ImplementingOpenVMS-to-OpenVMS solutions — DECnet or otherwise — is lessinteresting(to me) than OpenVMS-to-whatever configurations. Even when theOpenVMS-to-OpenVMS might be slightly better by some measures, as I'mstill going to have to deal with OpenVMS-to-otherwise connections, soI might as well just use the same OpenVMS-to-whatever path and notbothermixing in the static-connection configuration or the platform-specificOpenVMS-to-OpenVMS path.

You know very well that IPsec can also be used for VMS-to-whatever, orwhatever-to-whatever. I was concentrating on the VMS <> VMS communicationbecause of the difficulty in encrypting protocols like DECnet over IP orthe cluster over UDP protocol.

And I'd still prefer a network API here,

Yes, I would also like to see a lot of things that aren't there. Not onlyin VMS, but in IP also. Most IP solutions that I see are half-baked,because IP is one big hobby project.

asI still have to deal with establishing a secure connection — I can'tsimply expect or trust that the end-user will have slogged through theIPsec set-up

The end-user will not do that, this is work for the system manager.

— and I still need to deal with DNS, certificates —becauseI may well be running TLS across an IPsec link — and for dealing withconnection errors and the rest. Yes, this API would beOpenVMS-specific, too. So there's that. (Now I have to go look atlibtls again. But I digress. Again.)https://www.k2esec.com/network-security-protocols-ipsec-vs-tlsssl-vs-ssh-part-ii/http://security.stackexchange.com/questions/42990/which-is-better-for-server-to-server-communication-ipsec-or-tlsetc,The less effort I have to put on the end-user to establish a secureconnection, the better off we all are.

Great, then IPsec is wonderful. The end-user always has a secure connectionif IPsec exists between the systems. He isn't even aware of security problems.

How much "security problems" comes from listening to network traffic?And how much comes from getting access to the actual systems directly?

If I send a password over TELNET between my PuTTY client, out on my100 Mb fiber routed over "the internet" and into another router andreaching my VMS box, what is the risk that someone sits with his earto the line and evesdropping my password?

I'd say the risk is higher that someone utilise a bug in some componentand breaks in in some other way. Or guesses a weak password.

The user having his password on a sticker on the screen is probablya larger security problem.

Post by David FrobleIf you think the above is "simple", perhaps you need to refer to adefinition of "simple". A good example of Steve's arguments forsimpler implementation of features.

Yes, you do need to do a bit of reading etc. But it took me less thenhalf an hour to understand the basics.

I'd love to be in the era where we had an easy and ubiquitous connectionencryption. In the era that OSI tried to reach, for instance.

Yes, OSI had a design behind it. The OSI designers knew there were manydifferent operating systems that needed to be connected, not just Unix. Sothey designed something like FTAM, FAL but the OSI version. Alas the Itworld choose to use the quick and dirty IP methods.

(Ignoring for the moment that DECnet-Plus and the associated OSImanagement user interface was poor at best. If that particular zombieever gets back upright and staggering around again, that whole areareally needs some work. But I digress.)

Sure, after 20 years of neglect, there would be a lot of work to do.

There are certainly reasonsto use IPsec, but there are also good reasons not to. ImplementingOpenVMS-to-OpenVMS solutions — DECnet or otherwise — is lessinteresting(to me) than OpenVMS-to-whatever configurations. Even when theOpenVMS-to-OpenVMS might be slightly better by some measures, as I'mstill going to have to deal with OpenVMS-to-otherwise connections, soI might as well just use the same OpenVMS-to-whatever path and notbothermixing in the static-connection configuration or the platform-specificOpenVMS-to-OpenVMS path.

You know very well that IPsec can also be used for VMS-to-whatever, orwhatever-to-whatever. I was concentrating on the VMS <> VMS communicationbecause of the difficulty in encrypting protocols like DECnet over IP orthe cluster over UDP protocol.

And I'd still prefer a network API here,

Yes, I would also like to see a lot of things that aren't there. Not onlyin VMS, but in IP also. Most IP solutions that I see are half-baked,because IP is one big hobby project.

asI still have to deal with establishing a secure connection — I can'tsimply expect or trust that the end-user will have slogged through theIPsec set-up

The end-user will not do that, this is work for the system manager.

— and I still need to deal with DNS, certificates —becauseI may well be running TLS across an IPsec link — and for dealing withconnection errors and the rest. Yes, this API would beOpenVMS-specific, too. So there's that. (Now I have to go look atlibtls again. But I digress. Again.)https://www.k2esec.com/network-security-protocols-ipsec-vs-tlsssl-vs-ssh-part-ii/http://security.stackexchange.com/questions/42990/which-is-better-for-server-to-server-communication-ipsec-or-tlsetc,The less effort I have to put on the end-user to establish a secureconnection, the better off we all are.

Great, then IPsec is wonderful. The end-user always has a secure connectionif IPsec exists between the systems. He isn't even aware of security problems.

How much "security problems" comes from listening to network traffic?And how much comes from getting access to the actual systems directly?If I send a password over TELNET between my PuTTY client, out on my100 Mb fiber routed over "the internet" and into another router andreaching my VMS box, what is the risk that someone sits with his earto the line and evesdropping my password?I'd say the risk is higher that someone utilise a bug in some componentand breaks in in some other way. Or guesses a weak password.The user having his password on a sticker on the screen is probablya larger security problem.

Sure, but Steve is right that secure and encrypted network traffic isgoing to be standard, and that's fine with me.

Post by Jan-Erik SoderholmHow much "security problems" comes from listening to network traffic?And how much comes from getting access to the actual systems directly?If I send a password over TELNET between my PuTTY client, out on my100 Mb fiber routed over "the internet" and into another router andreaching my VMS box, what is the risk that someone sits with his earto the line and evesdropping my password?

Random attack: extremely low.

If you are targeted for an attack then I would say significant.

Post by Jan-Erik SoderholmI'd say the risk is higher that someone utilise a bug in some componentand breaks in in some other way. Or guesses a weak password.The user having his password on a sticker on the screen is probablya larger security problem.

Sure.

But that is not a valid reason to not avoid vulnerabilities thatcan be avoided.

Depending on your security requirements you might want to consider AES ("rijndael-cbc"), instead of 3DES.On top of that, 3DES is quite compute intensive when implemented in software instead of dedicated crypto-hardware.

Depending on your security requirements you might want to consider AES ("rijndael-cbc"), instead of 3DES.On top of that, 3DES is quite compute intensive when implemented in software instead of dedicated crypto-hardware.

Sure, but this is just an example. I certainly agree with you thatchoosing the best algorithm is very important.

Post by Dirk MunkI’ve often mentioned that in my view IPsec should be used between twoVMS nodes to encrypt all IP traffic. IPsec is almost non-existing in thepresent HPE TCPIP Services, but it is present in the Multinet stack, andit will be present in the new VSI TCPIP V10.5 Services.So I wanted to know how to set it up, and it proofed to be remarkablesimple.The following examples come from the MultiNet Installation andAdministrator's Guide, I give you the settings for one node.# multinet:ipsec.conf ## packet will look like this: IPv4 AH ESP payload# the node is on 10.1.1.1, peer is on 10.2.1.1# Add encryption to outgoing packets and incoming packets, both withadd 10.1.1.1 10.2.1.1 esp 9876 -E 3des-cbc “hogehogehogehogehogehoge”;add 10.2.1.1 10.1.1.1 esp 10000 -E 3des-cbc0xdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeef;add 10.1.1.1 10.2.1.1 ah 9877 -A hmac-md5 “mogamogamogamoga”;add 10.2.1.1 10.1.1.1 ah 10001 -A hmac-md5 “lowalowalowalowa”;#require that all outgoing and incoming IP traffic to and from that peerspdadd 10.1.1.1 10.2.1.1 any -P out ipsec esp/transport//useah/transport//use;spdadd 10.2.1.1 10.1.1.1 any -P in ipsec esp/transport//useah/transport//use;That’s it, all IP traffic will be encrypted and authenticated. Thatincludes Telnet, FTP, SQL, DECnet over IP:(which ever version), clusterover UDP, name it.No need for other types of encryption between these two nodes, so no SSHor TLS.Simple and elegant, just the way it should be.

You've got no chance with this crowd Dirk :-(

I can't remember when I started begging for IPsec and whne MattMuggeridge released a trial version or even when IPsec disappeared offthe VMS road map. Maybe with Multinet being licensed by VSI it will return.

Don't let then bait-n-swutch you to the "We need a totally homogeneousencryption and authentication solution" bullshit narrative! IPsec issimply the best and most efficient sever-to-server orknown-client-to-server solution! No it can't be used for anonymousweb-pages; so what? Use TLS.

For clients I usehttps://www.microsoft.com/en-au/store/p/pulse-secure/9nblggh3b0bp

Post by Dirk MunkI’ve often mentioned that in my view IPsec should be used between twoVMS nodes to encrypt all IP traffic. IPsec is almost non-existing in thepresent HPE TCPIP Services, but it is present in the Multinet stack, andit will be present in the new VSI TCPIP V10.5 Services.So I wanted to know how to set it up, and it proofed to be remarkablesimple.The following examples come from the MultiNet Installation andAdministrator's Guide, I give you the settings for one node.# multinet:ipsec.conf ## packet will look like this: IPv4 AH ESP payload# the node is on 10.1.1.1, peer is on 10.2.1.1# Add encryption to outgoing packets and incoming packets, both withadd 10.1.1.1 10.2.1.1 esp 9876 -E 3des-cbc “hogehogehogehogehogehoge”;add 10.2.1.1 10.1.1.1 esp 10000 -E 3des-cbc0xdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeef;add 10.1.1.1 10.2.1.1 ah 9877 -A hmac-md5 “mogamogamogamoga”;add 10.2.1.1 10.1.1.1 ah 10001 -A hmac-md5 “lowalowalowalowa”;#require that all outgoing and incoming IP traffic to and from that peerspdadd 10.1.1.1 10.2.1.1 any -P out ipsec esp/transport//useah/transport//use;spdadd 10.2.1.1 10.1.1.1 any -P in ipsec esp/transport//useah/transport//use;That’s it, all IP traffic will be encrypted and authenticated. Thatincludes Telnet, FTP, SQL, DECnet over IP:(which ever version), clusterover UDP, name it.No need for other types of encryption between these two nodes, so no SSHor TLS.Simple and elegant, just the way it should be.

You've got no chance with this crowd Dirk :-(I can't remember when I started begging for IPsec and whne MattMuggeridge released a trial version or even when IPsec disappeared offthe VMS road map. Maybe with Multinet being licensed by VSI it will return.Don't let then bait-n-swutch you to the "We need a totally homogeneousencryption and authentication solution" bullshit narrative! IPsec issimply the best and most efficient sever-to-server orknown-client-to-server solution! No it can't be used for anonymousweb-pages; so what? Use TLS.For clients I usehttps://www.microsoft.com/en-au/store/p/pulse-secure/9nblggh3b0bpCheers

Thanks Richard,

IPsec is a great solution for known connections, and of course serversare usually known.

I remember the first time I heard about IPsec, it was some kind ofsession in the DEC building in Utrecht (Netherlands). It immediatelystruck me as a brilliant idea, all IP traffic between known nodes can besecured by one setup. It covers almost all of your security needs insidea datacenter, or between two nodes over the internet.

It is not suitable for ad-hoc connections with browsers etc, but forthat we have TLS.

It's also great for the network people. Datacenters in big companies areoften littered with firewalls, well, with IPsec configuring suchfirewalls is very easy. A new application with new ports on two existingservers? No need to reconfigure and test firewalls.

So I agree with you, it is by far one of the best ways to secure networktraffic.