Using IPsec on VMS

[Dirk Munk]

I’ve often mentioned that in my view IPsec should be used between two
VMS nodes to encrypt all IP traffic. IPsec is almost non-existing in the
present HPE TCPIP Services, but it is present in the Multinet stack, 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 remarkable
simple.

The following examples come from the MultiNet Installation and
Administrator'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 with
different keys:
add 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-cbc
0xdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeef;
#Add authentication headers to outgoing and incoming packets:
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
is encrypted and authenticated:
spdadd 10.1.1.1 10.2.1.1 any -P out ipsec esp/transport//use
ah/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. That
includes 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 no SSH
or TLS.

Simple and elegant, just the way it should be.

[Jan-Erik Soderholm]

I’ve often mentioned that in my view IPsec should be used between two VMS
nodes to encrypt all IP traffic. IPsec is almost non-existing in the
present HPE TCPIP Services, but it is present in the Multinet stack, 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 remarkable simple.
The following examples come from the MultiNet Installation and
Administrator'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 with
add 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-cbc
0xdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeef;
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 is
spdadd 10.1.1.1 10.2.1.1 any -P out ipsec esp/transport//use
ah/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. That
includes 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 no SSH or
TLS.
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 any
keys, "hogehoge..." and so on, or do you need to create those
keys first with some other tool?

Is it that, for IPsec, you always need to know beforehand what
nodes you will be communicating with? And exchange keys by
some other means.

How is IPsec used when you do not know the other IP address?

Of course, things like HTTPS can be handled dynamicaly since
most web browsers and web servers handles encryption today.

[Dirk Munk]

Post by Jan-Erik Soderholm

I’ve often mentioned that in my view IPsec should be used between two VMS
nodes to encrypt all IP traffic. IPsec is almost non-existing in the
present HPE TCPIP Services, but it is present in the Multinet stack, 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 remarkable simple.
The following examples come from the MultiNet Installation and
Administrator'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 with
add 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-cbc
0xdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeef;
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 is
spdadd 10.1.1.1 10.2.1.1 any -P out ipsec esp/transport//use
ah/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. That
includes 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 no SSH or
TLS.
Simple and elegant, just the way it should be.

Yes, seems simple enough, for two nodes.

Extendible to more nodes of course.

Post by Jan-Erik Soderholm
And on node 10.2.1.1 (in this case) you just do the same,
but in reverse, so to speak.

Yes

Post by Jan-Erik Soderholm
Can you just come up with any
keys, "hogehoge..." and so on, or do you need to create those
keys first with some other tool?

You can come up with any key, binary (hexadecimal) non-readable keys are
preferred. I think it's also possible to generate keys with Racoon2, but
I haven't read all that.

Post by Jan-Erik Soderholm
Is it that, for IPsec, you always need to know beforehand what
nodes you will be communicating with? And exchange keys by
some other means.

Yes, you do know the nodes you want to communicate with, you have to set
a security policy for every node. Racoons 2 seems to be capable to
distribute keys.

Post by Jan-Erik Soderholm
How is IPsec used when you do not know the other IP address?

You can use DNS names, so it seems.

Post by Jan-Erik Soderholm
Of course, things like HTTPS can be handled dynamicaly since
most web browsers and web servers handles encryption today.

Yes, with TLS and certificates. IPsec can cover *all* IP traffic, no
need for any kind of encryption at the application level.

[Jan-Erik Soderholm]

Post by Dirk Munk

Post by Jan-Erik Soderholm

I’ve often mentioned that in my view IPsec should be used between two VMS
nodes to encrypt all IP traffic. IPsec is almost non-existing in the
present HPE TCPIP Services, but it is present in the Multinet stack, 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 remarkable simple.
The following examples come from the MultiNet Installation and
Administrator'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 with
add 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-cbc
0xdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeef;
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 is
spdadd 10.1.1.1 10.2.1.1 any -P out ipsec esp/transport//use
ah/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. That
includes 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 no SSH or
TLS.
Simple and elegant, just the way it should be.

Yes, seems simple enough, for two nodes.

Extendible to more nodes of course.

Post by Jan-Erik Soderholm
And on node 10.2.1.1 (in this case) you just do the same,
but in reverse, so to speak.

Yes

Post by Jan-Erik Soderholm
Can you just come up with any
keys, "hogehoge..." and so on, or do you need to create those
keys first with some other tool?

You can come up with any key, binary (hexadecimal) non-readable keys are
preferred. I think it's also possible to generate keys with Racoon2, but I
haven't read all that.

Post by Jan-Erik Soderholm
Is it that, for IPsec, you always need to know beforehand what
nodes you will be communicating with? And exchange keys by
some other means.

Yes, you do know the nodes you want to communicate with, you have to set a
security policy for every node. Racoons 2 seems to be capable to distribute
keys.

Post by Jan-Erik Soderholm
How is IPsec used when you do not know the other IP address?

You can use DNS names, so it seems.

Bad wording in my question from my side... :-)

How is IPsec used when you do not know the other node?

[Dirk Munk]

Post by Jan-Erik Soderholm

Post by Dirk Munk

Post by Jan-Erik Soderholm

I’ve often mentioned that in my view IPsec should be used between two VMS
nodes to encrypt all IP traffic. IPsec is almost non-existing in the
present HPE TCPIP Services, but it is present in the Multinet stack, 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 remarkable simple.
The following examples come from the MultiNet Installation and
Administrator'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 with
add 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-cbc
0xdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeef;
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 is
spdadd 10.1.1.1 10.2.1.1 any -P out ipsec esp/transport//use
ah/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. That
includes 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 no SSH or
TLS.
Simple and elegant, just the way it should be.

Yes, seems simple enough, for two nodes.

Extendible to more nodes of course.

Post by Jan-Erik Soderholm
And on node 10.2.1.1 (in this case) you just do the same,
but in reverse, so to speak.

Yes

Post by Jan-Erik Soderholm
Can you just come up with any
keys, "hogehoge..." and so on, or do you need to create those
keys first with some other tool?

You can come up with any key, binary (hexadecimal) non-readable keys are
preferred. I think it's also possible to generate keys with Racoon2, but I
haven't read all that.

Post by Jan-Erik Soderholm
Is it that, for IPsec, you always need to know beforehand what
nodes you will be communicating with? And exchange keys by
some other means.

Yes, you do know the nodes you want to communicate with, you have to set a
security policy for every node. Racoons 2 seems to be capable to distribute
keys.

Post by Jan-Erik Soderholm
How is IPsec used when you do not know the other IP address?

You can use DNS names, so it seems.

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 can
distribute keys with Rancoon2, you still need to set up a Security
Policy on both nodes. At least that is how I understand that this works.

[David Froble]

Post by Dirk Munk

Post by Jan-Erik Soderholm

Post by Dirk Munk

Post by Jan-Erik Soderholm

I’ve often mentioned that in my view IPsec should be used between two VMS
nodes to encrypt all IP traffic. IPsec is almost non-existing in the
present HPE TCPIP Services, but it is present in the Multinet stack, 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 remarkable simple.
The following examples come from the MultiNet Installation and
Administrator'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 with
add 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-cbc
0xdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeef;
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 is
spdadd 10.1.1.1 10.2.1.1 any -P out ipsec esp/transport//use
ah/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. That
includes 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 no SSH or
TLS.
Simple and elegant, just the way it should be.

Yes, seems simple enough, for two nodes.

Extendible to more nodes of course.

Post by Jan-Erik Soderholm
And on node 10.2.1.1 (in this case) you just do the same,
but in reverse, so to speak.

Yes

Post by Jan-Erik Soderholm
Can you just come up with any
keys, "hogehoge..." and so on, or do you need to create those
keys first with some other tool?

You can come up with any key, binary (hexadecimal) non-readable keys are
preferred. I think it's also possible to generate keys with Racoon2, but I
haven't read all that.

Post by Jan-Erik Soderholm
Is it that, for IPsec, you always need to know beforehand what
nodes you will be communicating with? And exchange keys by
some other means.

Yes, you do know the nodes you want to communicate with, you have to set a
security policy for every node. Racoons 2 seems to be capable to distribute
keys.

Post by Jan-Erik Soderholm
How is IPsec used when you do not know the other IP address?

You can use DNS names, so it seems.

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 can
distribute keys with Rancoon2, you still need to set up a Security
Policy 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?

[Dirk Munk]

Post by David Froble

Post by Dirk Munk

Post by Jan-Erik Soderholm

Post by Dirk Munk

Post by Jan-Erik Soderholm

I’ve often mentioned that in my view IPsec should be used between two VMS
nodes to encrypt all IP traffic. IPsec is almost non-existing in the
present HPE TCPIP Services, but it is present in the Multinet stack, 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 remarkable simple.
The following examples come from the MultiNet Installation and
Administrator'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 with
add 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-cbc
0xdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeef;
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 is
spdadd 10.1.1.1 10.2.1.1 any -P out ipsec esp/transport//use
ah/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. That
includes 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 no SSH or
TLS.
Simple and elegant, just the way it should be.

Yes, seems simple enough, for two nodes.

Extendible to more nodes of course.

Post by Jan-Erik Soderholm
And on node 10.2.1.1 (in this case) you just do the same,
but in reverse, so to speak.

Yes

Post by Jan-Erik Soderholm
Can you just come up with any
keys, "hogehoge..." and so on, or do you need to create those
keys first with some other tool?

You can come up with any key, binary (hexadecimal) non-readable keys are
preferred. I think it's also possible to generate keys with Racoon2, but I
haven't read all that.

Post by Jan-Erik Soderholm
Is it that, for IPsec, you always need to know beforehand what
nodes you will be communicating with? And exchange keys by
some other means.

Yes, you do know the nodes you want to communicate with, you have to set a
security policy for every node. Racoons 2 seems to be capable to distribute
keys.

Post by Jan-Erik Soderholm
How is IPsec used when you do not know the other IP address?

You can use DNS names, so it seems.

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 can
distribute keys with Rancoon2, you still need to set up a Security
Policy 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?

Did I claim that?

[David Froble]

Post by Dirk Munk

Post by David Froble

Post by Dirk Munk

Post by Jan-Erik Soderholm

Post by Dirk Munk

Post by Jan-Erik Soderholm

I’ve often mentioned that in my view IPsec should be used between two VMS
nodes to encrypt all IP traffic. IPsec is almost non-existing in the
present HPE TCPIP Services, but it is present in the Multinet stack, 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 remarkable
simple.
The following examples come from the MultiNet Installation and
Administrator'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 with
add 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-cbc
0xdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeef;
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 is
spdadd 10.1.1.1 10.2.1.1 any -P out ipsec esp/transport//use
ah/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. That
includes 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 no SSH or
TLS.
Simple and elegant, just the way it should be.

Yes, seems simple enough, for two nodes.

Extendible to more nodes of course.

Post by Jan-Erik Soderholm
And on node 10.2.1.1 (in this case) you just do the same,
but in reverse, so to speak.

Yes

Post by Jan-Erik Soderholm
Can you just come up with any
keys, "hogehoge..." and so on, or do you need to create those
keys first with some other tool?

You can come up with any key, binary (hexadecimal) non-readable keys are
preferred. I think it's also possible to generate keys with Racoon2, but I
haven't read all that.

Post by Jan-Erik Soderholm
Is it that, for IPsec, you always need to know beforehand what
nodes you will be communicating with? And exchange keys by
some other means.

Yes, you do know the nodes you want to communicate with, you have to set a
security policy for every node. Racoons 2 seems to be capable to distribute
keys.

Post by Jan-Erik Soderholm
How is IPsec used when you do not know the other IP address?

You can use DNS names, so it seems.

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 can
distribute keys with Rancoon2, you still need to set up a Security
Policy 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?

Did I claim that?

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

[Dirk Munk]

Post by David Froble

Post by Dirk Munk

Post by David Froble

Post by Dirk Munk

Post by Jan-Erik Soderholm

Post by Dirk Munk

Post by Jan-Erik Soderholm

I’ve often mentioned that in my view IPsec should be used between two VMS
nodes to encrypt all IP traffic. IPsec is almost non-existing in the
present HPE TCPIP Services, but it is present in the Multinet
stack,
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 remarkable
simple.
The following examples come from the MultiNet Installation and
Administrator'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 with
add 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-cbc
0xdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeef;
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 is
spdadd 10.1.1.1 10.2.1.1 any -P out ipsec esp/transport//use
ah/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. That
includes 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 no
SSH or
TLS.
Simple and elegant, just the way it should be.

Yes, seems simple enough, for two nodes.

Extendible to more nodes of course.

Post by Jan-Erik Soderholm
And on node 10.2.1.1 (in this case) you just do the same,
but in reverse, so to speak.

Yes

Post by Jan-Erik Soderholm
Can you just come up with any
keys, "hogehoge..." and so on, or do you need to create those
keys first with some other tool?

You can come up with any key, binary (hexadecimal) non-readable keys are
preferred. I think it's also possible to generate keys with Racoon2, but I
haven't read all that.

Post by Jan-Erik Soderholm
Is it that, for IPsec, you always need to know beforehand what
nodes you will be communicating with? And exchange keys by
some other means.

Yes, you do know the nodes you want to communicate with, you have to set a
security policy for every node. Racoons 2 seems to be capable to distribute
keys.

Post by Jan-Erik Soderholm
How is IPsec used when you do not know the other IP address?

You can use DNS names, so it seems.

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 can
distribute keys with Rancoon2, you still need to set up a Security
Policy 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?

Did I claim that?

No, nor did you state it either. Don't get me wrong, I like IPSEC. But
it 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 been
reading the manual. I even don't know if the Multinet version is
state-of-the art. I'm not saying it is not, I just don't know. Perhaps
more things are possible with IPsec, who knows.

[Stephen Hoffman]

Post by David Froble

Post by Dirk Munk
Just as with SSH, you need to set up both nodes. Even if you can
distribute keys with Rancoon2, you still need to set up a Security
Policy 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?

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

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

SSH can't prove whether the host it connects to is the intended host on
the first connection though; that's something that TLS does with
certificates and an out-of-band external coordination service; the
public certificate authority, or a private CA for those that have a
secure path to load the root certificate onto all of the hosts
involved. Once that initial connection is made, subsequent connections
do check the host keys.

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

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

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

[Jan-Erik Soderholm]

Post by Dirk Munk

Post by Jan-Erik Soderholm

Post by Dirk Munk

Post by Jan-Erik Soderholm

I’ve often mentioned that in my view IPsec should be used between two VMS
nodes to encrypt all IP traffic. IPsec is almost non-existing in the
present HPE TCPIP Services, but it is present in the Multinet stack, 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 remarkable simple.
The following examples come from the MultiNet Installation and
Administrator'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 with
add 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-cbc
0xdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeef;
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 is
spdadd 10.1.1.1 10.2.1.1 any -P out ipsec esp/transport//use
ah/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. That
includes 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 no SSH or
TLS.
Simple and elegant, just the way it should be.

Yes, seems simple enough, for two nodes.

Extendible to more nodes of course.

Post by Jan-Erik Soderholm
And on node 10.2.1.1 (in this case) you just do the same,
but in reverse, so to speak.

Yes

Post by Jan-Erik Soderholm
Can you just come up with any
keys, "hogehoge..." and so on, or do you need to create those
keys first with some other tool?

You can come up with any key, binary (hexadecimal) non-readable keys are
preferred. I think it's also possible to generate keys with Racoon2, but I
haven't read all that.

Post by Jan-Erik Soderholm
Is it that, for IPsec, you always need to know beforehand what
nodes you will be communicating with? And exchange keys by
some other means.

Yes, you do know the nodes you want to communicate with, you have to set a
security policy for every node. Racoons 2 seems to be capable to distribute
keys.

Post by Jan-Erik Soderholm
How is IPsec used when you do not know the other IP address?

You can use DNS names, so it seems.

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.

Post by Dirk Munk
Even if you can distribute
keys with Rancoon2, you still need to set up a Security Policy on both
nodes. At least that is how I understand that this works.

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

[David Froble]

Post by Jan-Erik Soderholm

Post by Dirk Munk

Post by Jan-Erik Soderholm

Post by Dirk Munk

Post by Jan-Erik Soderholm

I’ve often mentioned that in my view IPsec should be used between two VMS
nodes to encrypt all IP traffic. IPsec is almost non-existing in the
present HPE TCPIP Services, but it is present in the Multinet stack, 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 remarkable simple.
The following examples come from the MultiNet Installation and
Administrator'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 with
add 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-cbc
0xdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeef;
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 is
spdadd 10.1.1.1 10.2.1.1 any -P out ipsec esp/transport//use
ah/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. That
includes 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 no SSH or
TLS.
Simple and elegant, just the way it should be.

Yes, seems simple enough, for two nodes.

Extendible to more nodes of course.

Post by Jan-Erik Soderholm
And on node 10.2.1.1 (in this case) you just do the same,
but in reverse, so to speak.

Yes

Post by Jan-Erik Soderholm
Can you just come up with any
keys, "hogehoge..." and so on, or do you need to create those
keys first with some other tool?

You can come up with any key, binary (hexadecimal) non-readable keys are
preferred. I think it's also possible to generate keys with Racoon2, but I
haven't read all that.

Post by Jan-Erik Soderholm
Is it that, for IPsec, you always need to know beforehand what
nodes you will be communicating with? And exchange keys by
some other means.

Yes, you do know the nodes you want to communicate with, you have to set a
security policy for every node. Racoons 2 seems to be capable to distribute
keys.

Post by Jan-Erik Soderholm
How is IPsec used when you do not know the other IP address?

You can use DNS names, so it seems.

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 some
of the automatic configuration that Steve likes so much (as do I) and does some
of the setup for you. Now if only (as far as I'm concerned) it would tell you
what it was doing, so one might understand things.

Post by Jan-Erik Soderholm

Post by Dirk Munk
Even if you can distribute
keys with Rancoon2, you still need to set up a Security Policy on both
nodes. At least that is how I understand that this works.

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

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

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

:-)

[Arne Vajhøj]

Post by David Froble
Browsers use client certificates that authenticate against known trusted
root certificates. They check that the server you're connecting to is
who you think it is. They do not authenticate in the opposite
direction, 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 is
possible 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 server
can check it.

This is rarely used for web browsers and web pages.

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

Arne

[David Froble]

Post by Arne Vajhøj

Post by David Froble
Browsers use client certificates that authenticate against known trusted
root certificates. They check that the server you're connecting to is
who you think it is. They do not authenticate in the opposite
direction, 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 know
why. I find them complex and not easy to use.

Not nice to turn my B+ into a D-

:-)

Post by Arne Vajhøj
Usually browsers do no use client certificates. But it is
possible 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 server
can check it.
This is rarely used for web browsers and web pages.
But it is sometimes used for web service clients and
web services server side. Authentication of the client is
done via a client certificate.
Arne

[Stephen Hoffman]

Post by Dirk Munk
That’s it, all IP traffic will be encrypted and authenticated. That
includes 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 no
SSH or TLS.
Simple and elegant, just the way it should be.

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

[Dirk Munk]

Post by Stephen Hoffman

Post by Dirk Munk
That’s it, all IP traffic will be encrypted and authenticated. That
includes 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 no
SSH or TLS.
Simple and elegant, just the way it should be.

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

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

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

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

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

[Stephen Hoffman]

Post by Stephen Hoffman

Post by Dirk Munk
That’s it, all IP traffic will be encrypted and authenticated. That
includes 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 no
SSH or TLS.
Simple and elegant, just the way it should be.

I'm not sure I'd call that simple or elegant. Particularly given the
dislike most folks have for slogging through configuration files, and
requiring them to manage and update those configuration files across
multiple hosts and particularly over time, and ignoring discussions of
user interface simplicity and automation in general.

Post by Stephen Hoffman
Simple and elegant can be wrong, too. What you've shown establishes
VPNs between hosts.

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

I'm referring to VPN in the vernacular here; an encrypted
point-to-point link, however that's implemented. Some VPNs are
static, and some are dynamic. Obviously IPsec itself supports both
transport and tunnel modes, too. But does the terminology make a
difference for the purposes of discussions of the limitations of
configuring static host-to-host connections? Because I can do that
stuff now, with a VPN box. Or with stunnel, depending on what I'm up
to, and assuming I don't have a good way to secure the
application-specific communications. Or going back to the all-DECnet
era, of scrounging a DESNC for that matter.

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

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

Many folks using OpenVMS aren't using just OpenVMS, and most folks
aren't using static network configurations. Sure, some core servers
are, but if you have to solve the more general configuration why bother
setting up static links? Once you need more flexibility in
connectiivity, or once you need applications to control their
connection security or per-app or per-user authentication such as
authenticating remote access into a web or other network app, a static
IPsec configuration becomes less interesting.

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

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

[Paul Sture]

Post by Stephen Hoffman
Many folks using OpenVMS aren't using just OpenVMS, and most folks
aren't using static network configurations. Sure, some core servers
are, but if you have to solve the more general configuration why bother
setting up static links? Once you need more flexibility in
connectiivity, or once you need applications to control their
connection security or per-app or per-user authentication such as
authenticating remote access into a web or other network app, a static
IPsec configuration becomes less interesting.

FWIW I had bit of a lightbulb moment recently when I wanted to change
the name of a server. Since this particular server was configured as a
DHCP client, a simple name change in the DHCP server followed by a
reboot 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 the
host name on non-VMS platforms too. DHCP is very desirable in any
changing environment.

Yes of course, this also involves adjustments to DNS records and entries
in ssh known_hosts files, but that all happens externally to the server
concerned.

[Richard Maher]

Post by Paul Sture
FWIW I had bit of a lightbulb moment recently when I wanted to change
the name of a server. Since this particular server was configured as a
DHCP client, a simple name change in the DHCP server followed by a
reboot 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 the
host name on non-VMS platforms too. DHCP is very desirable in any
changing environment.

Try changing the license on an Azure VM!!!

[Stephen Hoffman]

Post by Paul Sture
cf VMS where changing the node name is a major task.

That name-change sequence is an utter embarrassment of accreted,
incomplete and ill-considered disparate implementations. But then I'm
feeling polite today, too.

Post by Paul Sture
and for that matter, there are multiple steps involved in changing the
host name on non-VMS platforms too. DHCP is very desirable in any
changing environment.

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

Post by Paul Sture
Yes of course, this also involves adjustments to DNS records and
entries in ssh known_hosts files, but that all happens externally to
the server concerned.

Provisioning via the preferred local configuration management software,
and/or distributed configuration and control and coordination via LDAP,
as well.

[Paul Sture]

Post by Stephen Hoffman

Post by Paul Sture
cf VMS where changing the node name is a major task.

That name-change sequence is an utter embarrassment of accreted,
incomplete and ill-considered disparate implementations. But then I'm
feeling polite today, too.

:-)

Post by Stephen Hoffman

Post by Paul Sture
and for that matter, there are multiple steps involved in changing the
host name on non-VMS platforms too. DHCP is very desirable in any
changing environment.

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

Gradually working on that. A current topic here is the topic of
allocating MAC addresses for interfaces on virtual machines. Until
recently I was using the MAC address generation feature within VMware
Fusion 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 is
addressed in the following thread:

<http://serverfault.com/questions/40712/what-range-of-mac-addresses-can-i-safely-use-for-my-virtual-machines#40720>

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

x2-xx-xx-xx-xx-xx
x6-xx-xx-xx-xx-xx
xA-xx-xx-xx-xx-xx
xE-xx-xx-xx-xx-xx

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

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

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

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

Post by Stephen Hoffman

Post by Paul Sture
Yes of course, this also involves adjustments to DNS records and
entries in ssh known_hosts files, but that all happens externally to
the server concerned.

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

a) download a VMware Fusion image and start it.
b) when it comes up, Fusion will detect that the VM is not in its
original location and ask whether you moved or copied it.
c) On nswering "I copied it", Fusion will allocate a new MAC address to
avoid a conflict with the source. Answer "I moved it", and the
original MAC address will remain unchanged.
d) respond with "I copied it" to force the generation of a new MAC
address.
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 the
first system.

You now have two virtual instances on the same LAN with the same MAC
address! They exhibit similar problems to those exhibited by duplicate
IP 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 Hoffman
Provisioning 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 problem
yesterday copying some code straight out of its own documentation, due
to Unicode - arrggh), the obvious way forward is to devise tested
templates work from there.

A note on the use of YAML:

<https://docs.saltstack.com/en/latest/topics/troubleshooting/yaml_idiosyncrasies.html>

"YAML Idiosyncrasies

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

..."

[Stephen Hoffman]

Post by Paul Sture

Post by Stephen Hoffman

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

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

Gradually working on that.

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

Post by Paul Sture
...
"YAML Idiosyncrasies
One of Salt's strengths, the use of existing serialization systems for
representing SLS data, can also backfire. YAML is a general purpose
system and there are a number of things that would seem to make sense
in an sls file that cause YAML issues.

Writing parsers can be interesting. Writing a parser processing
untrusted input with security relevance is "fun", particularly if
you're sufficiently unwise to be parsing untrusted input in a
privileged context.

[David Froble]

Post by Dirk Munk
I’ve often mentioned that in my view IPsec should be used between two
VMS nodes to encrypt all IP traffic. IPsec is almost non-existing in the
present HPE TCPIP Services, but it is present in the Multinet stack, 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 remarkable
simple.
The following examples come from the MultiNet Installation and
Administrator'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 with
add 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-cbc
0xdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeef;
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
spdadd 10.1.1.1 10.2.1.1 any -P out ipsec esp/transport//use
ah/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. That
includes 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 no SSH
or 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 of
features.

[Jan-Erik Soderholm]

Post by David Froble

I’ve often mentioned that in my view IPsec should be used between two VMS
nodes to encrypt all IP traffic. IPsec is almost non-existing in the
present HPE TCPIP Services, but it is present in the Multinet stack, 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 remarkable
simple.
The following examples come from the MultiNet Installation and
Administrator'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 with
add 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-cbc
0xdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeef;
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
spdadd 10.1.1.1 10.2.1.1 any -P out ipsec esp/transport//use
ah/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. That
includes 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 no SSH
or 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 of features.

To read about it, see:

http://www.process.com/psc/service-support/multinet-support/multinet-documentation/

http://www.process.com/docs/multinet5_5/install_admin.pdf

Chapter "29. Configuring IPSEC and SETKEY".

[Dirk Munk]

Post by David Froble

Post by Dirk Munk
I’ve often mentioned that in my view IPsec should be used between two
VMS nodes to encrypt all IP traffic. IPsec is almost non-existing in
the present HPE TCPIP Services, but it is present in the Multinet
stack, 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 remarkable
simple.
The following examples come from the MultiNet Installation and
Administrator'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 with
add 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-cbc
0xdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeef;
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
spdadd 10.1.1.1 10.2.1.1 any -P out ipsec esp/transport//use
ah/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. That
includes 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 no
SSH or 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 of features.

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

[Stephen Hoffman]

Post by Dirk Munk

Post by David Froble
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 of features.

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

I'd love to be in the era where we had an easy and ubiquitous
connection encryption. In the era that OSI tried to reach, for
instance. (Ignoring for the moment that DECnet-Plus and the
associated OSI management user interface was poor at best. If that
particular zombie ever gets back upright and staggering around again,
that whole area really needs some work. But I digress.) There are
certainly reasons to use IPsec, but there are also good reasons not to.
Implementing OpenVMS-to-OpenVMS solutions — DECnet or otherwise — is
less interesting (to me) than OpenVMS-to-whatever configurations.
Even when the OpenVMS-to-OpenVMS might be slightly better by some
measures, as I'm still going to have to deal with OpenVMS-to-otherwise
connections, so I might as well just use the same OpenVMS-to-whatever
path and not bother mixing in the static-connection configuration or
the platform-specific OpenVMS-to-OpenVMS path. And I'd still prefer
a network API here, as I still have to deal with establishing a secure
connection — I can't simply expect or trust that the end-user will have
slogged 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 API
would be OpenVMS-specific, too. So there's that. (Now I have to go
look at libtls 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-tls

etc,

The less effort I have to put on the end-user to establish a secure
connection, the better off we all are.

[David Froble]

Post by Stephen Hoffman
The less effort I have to put on the end-user to establish a secure
connection, 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, gets data, in a
"really" simple manner, and then internally maybe builds the configuration stuff.

The configuration stuff Dirk posted is not something I ever want to wade through.

[Dirk Munk]

Post by David Froble

Post by Stephen Hoffman
The less effort I have to put on the end-user to establish a secure
connection, 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, gets
data, in a "really" simple manner, and then internally maybe builds the
configuration 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 with
this (after a training) the he should look for another job.

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

[David Froble]

Post by Dirk Munk

Post by David Froble

Post by Stephen Hoffman
The less effort I have to put on the end-user to establish a secure
connection, 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, gets
data, in a "really" simple manner, and then internally maybe builds the
configuration 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 with
this (after a training) the he should look for another job.

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

Post by Dirk Munk
Furthermore this is typical Unix/Linux syntax, and isn't that the future
of operating systems??????

NO!

[Dirk Munk]

Post by David Froble

Post by Dirk Munk

Post by David Froble

Post by Stephen Hoffman
The less effort I have to put on the end-user to establish a secure
connection, 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, gets
data, in a "really" simple manner, and then internally maybe builds the
configuration 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 with
this (after a training) the he should look for another job.

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

If you have no configuration options, then you don't have to make a
choice. If there are options, then you have to make choices, and in
order to do so, jou must understand the effects and consequences of the
choices. 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 the
consequences of that kind of thinking.

Post by David Froble

Post by Dirk Munk
Furthermore this is typical Unix/Linux syntax, and isn't that the
future of operating systems??????

NO!

[Simon Clubley]

Post by Dirk Munk

Post by David Froble
See how you computer geeks are? You want to maintain the mystic
aspect. Job security or such?

If you have no configuration options, then you don't have to make a
choice. If there are options, then you have to make choices, and in
order to do so, jou must understand the effects and consequences of the
choices. 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 the
consequences 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 which
means the person carrying out the task doesn't need a detailed
understanding of the underlying concepts.

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

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

Simon.

[David Froble]

Post by Simon Clubley

Post by Dirk Munk

Post by David Froble
See how you computer geeks are? You want to maintain the mystic
aspect. Job security or such?

If you have no configuration options, then you don't have to make a
choice. If there are options, then you have to make choices, and in
order to do so, jou must understand the effects and consequences of the
choices. 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 the
consequences 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 which
means the person carrying out the task doesn't need a detailed
understanding of the underlying concepts.
However, I balk big time at that when it comes to security and
especially network security when you are setting up site level
or server level security (as opposed to client side security).
I think that a person should be required to understand the
underlying concepts (and the UI should enforce that) before they
can configure something.
By all means make the configuration mechanisms easier to use for
a knowledgeable person (and VMS can certainly use those changes)
but I still think it's a bad idea to have a security UI mechanism
which doesn't require any real understanding of what is going on
underneath.
Simon.

Agreed

[Stephen Hoffman]

Post by Dirk Munk

Post by David Froble

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

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

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

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

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

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

As compared with requiring manual IPsec configurations, embedding TLS
into the application or utilizing the existing CA framework in a server
means I don't have to add tasks onto the list for the local system
managers. It also means I don't have to troubleshoot the inevitable
mistakes, and it means that I don't have to go rummage the system to
ensure the connection is secure.

And again, TLS also means we don't have the IPsec set-up. nor any
particular set-up requirements onto the installer nor on local system
management. If we have a CA chain in the host, we have all that's
necessary to move the connection encryption requirements into the
application.

[Dirk Munk]

Post by Stephen Hoffman

Post by Dirk Munk

Post by David Froble

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

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

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

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

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

I've watched the numbers of system managers associated with
installations shrinking, and the efficiency of the remaining managers
increasing. We all have. Part of that is because the systems are
continuing to become easier and more automated, and the tools to manage
masses of servers continue to improve. Are there going to be system
managers around, and particularly for complex configurations? Sure.
But there'll be fewer of them, relative to the numbers of servers and
the complexity of the networks that get deployed. There'll always be
management pressure to eliminate the positions, too. Some will be
outsourced, too — either to ISVs or cloud providers or service bureaus
or part-timer staff, too. Servers are only getting better at
managing themselves, or of picking reasonable defaults, or of picking up
settings from configuration servers. Which means fewer mistakes, less
effort, and fewer (on average) system managers. And if we're looking
at 2022 or 2027 and beyond, that means fewer configuration files and
fewer manual set-up steps to get to a working configuration.
As compared with requiring manual IPsec configurations, embedding TLS
into the application or utilizing the existing CA framework in a server
means I don't have to add tasks onto the list for the local system
managers. It also means I don't have to troubleshoot the inevitable
mistakes, and it means that I don't have to go rummage the system to
ensure the connection is secure.

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

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

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

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

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

Post by Stephen Hoffman
And again, TLS also means we don't have the IPsec set-up. nor any
particular set-up requirements onto the installer nor on local system
management. If we have a CA chain in the host, we have all that's
necessary to move the connection encryption requirements into the
application.

[Stephen Hoffman]

Post by Dirk Munk

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

Really.

Yes, really.

Post by Dirk Munk
So don't have to keep track which applications have outdated and
vulnerable SSL/TLS stacks.

I'd prefer not to, hence my comments around an API for this. But then
IPsec doesn't do what I need. For software updates, that's managed by
pushing out updates. OpenVMS folks haven't seen these approaches and
tools as many of the OpenVMS servers are customized. But we're all
headed toward software that gets pushed out — whether from VSI in
Bolton, from the ISV, or within the organization. OpenVMS does not
have tools for that, but other boxes do. That's already a problem for
OpenVMS going forward, and one that's much bigger than the security
libraries and tools and related infrastructure.

Post by Dirk Munk
You don't have to reinstall that software.

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

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

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

As for code modularity, that depends on how the libraries are packaged.
I've already done some work in that area. I'd like to see OpenVMS
APIs for transport and DNS and security and authentication, as has been
mentioned. That's a slog, whether using TLS or otherwise — or using
IPsec for that matter. But then security also moves forward and
increasingly rapidly, which generally means updates. Newer
recommendations around checks and practices, as well as fixes and
corrections. Which gets back to having easier and faster software
updates, another capability that I'd prefer to see.

Post by Dirk Munk
You don't have to plan that with the users. You don't have to test the
new software. You don't have to keep track of your certificates, to
prevent them from becoming outdated.

All of which is wonderful, but for about the zillionth time I've
explained this, none of which is even remotely relevant to the problem
at hand. Like OSI, none of what IPsec provides does anything for what
I need to do. and it adds a pile of complexity onto the existing mess.
So I have to go through all of what I have to go through — I'd prefer
not to — plus dealing with a bad IPsec UI and the rest, and whatever
patches IPsec itself needs. In aggregate, more work.

Post by Dirk Munk
I've done that kind of work, it's a pain in the ass when you have to
get a dozen managers and departments so far that you can do an update,
or convince them that they need an update.

I'm fully aware that managers are living in the OSI era, and think
computing still works the same way it did, that they can still do
deployments like they used to, and can ignore updates for days or weeks
with impunity. Fun times. They eventually learn.

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

Wonderful. Doesn't solve my problems. I'm doing app updates anyway,
so the TLS rolls along with it.

Post by Dirk Munk
If you have a good system manager, then he can trace and solve problems
in a short time.

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

Post by Dirk Munk
If you have the type of ignorant and mediocre system managers you seem
to prefer, then problems can take months to be solved, or they are
never solved.

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

Post by Dirk Munk
I've seen it, I've experienced it over decades.

Expecting trained humans is a wonderful thought, but an expensive one.
Force-fitting IPsec where it doesn't work — much like DECnet or OSI —
doesn't help there, either.

I'd like to live in the world with OpenVMS everywhere, and with DECnet
and OSI networking providing all interconnection, and with IPsec
allowing trivial interconnections among all systems, and all the rest.
I'd like to have static network configurations, full control of all
the client systems and remote servers, and with locked-down or no
connections outside of the datacenters, with trusted and secure
internal networks, with off-hour windows available for backups and
maintenance, with production and application development efforts that
each permit queuing upgrades for installation once or twice a year at
most, having to rush-install upgrades only once every year or two and
having a week to do it. I'd certainly prefer to have skilled
technical staff ready on-site and on-call at the customer site, and
staff that has the budget and payroll and schedule time and the
technical ability to find and read and understand the copious
documentation that's inevitably available, and obviously performing
each individual installation and upgrade with due care and no matter
how complex those might be and how arcane the software and the UI might
be. I would like to have the ability to fund large development and
support organizations, too. But I don't, I need to operate with the
environments customers have, and are deploying. What I'm seeing and
dealing with now is only going to get faster, too. IP and TLS are part
of that. Ease of use and integration desperately needs to improve.
Far better automation too, as what's happening now is only going to
accelerate. And certainly, there are some folks can or do still
operate their OpenVMS servers and systems like they're back in the
classic OpenVMS era. Good on them.

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

[Richard Maher]

Post by Dirk Munk
You don't have to reinstall that software.

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

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

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

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

[Dirk Munk]

Post by Richard Maher

Post by Dirk Munk
You don't have to reinstall that software.

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

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

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

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. :-)

[Paul Sture]

Post by Dirk Munk

Post by Richard Maher
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. :-)

"Manchester screwdriver" here. "Manchester" for short.

I assume that in Manchester they call it something else.

[Arne Vajhøj]

Post by Dirk Munk
Furthermore this is typical Unix/Linux syntax, and isn't that the
future of operating systems??????

NO!

If you look at *nix percentage of servers 1986, 1996, 2006 and 2016
then I think you will see a trend.

Arne

[Stephen Hoffman]

Post by Dirk Munk

Post by David Froble

Post by Stephen Hoffman
The less effort I have to put on the end-user to establish a secure
connection, 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, gets
data, in a "really" simple manner, and then internally maybe builds the
configuration 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 with
this (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 even
eliminate the need for as many system managers.

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

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

Post by Dirk Munk
Furthermore this is typical Unix/Linux syntax, and isn't that the
future of operating systems??????

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

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

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

[Stephen Hoffman]

Post by David Froble

Post by Stephen Hoffman
The less effort I have to put on the end-user to establish a secure
connection, 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, gets
data, in a "really" simple manner, and then internally maybe builds the
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 for
network folks. It does everything. DECnet-Plus and OSI were (are)
great ideas, massively capable and extremely flexible, marvelously
capable system, one of the most elegant and consistent implementations.
Also a blasted and complete and utter disaster to implement a new
client or new server under EMA — all of those capabilities and
flexibilities meant even the common cases were a whole lot more
difficult to implement, and hacked-together control programs are much
easier — and the whole user interface for DECnet-Plus is an intractable
morass of reading for any doesn't-want-to-be-an-expert user to perform
even a baseline server configuration for DECnet-Plus networking. For
the folks that just want to get connected and going, or to troubleshoot
what should be a baseline problem.

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

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

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

Expecting all users to edit configuration files or MODPARAMS or such —
for even baseline configurations of the server software, or for your
own application deployments and software — and you're on the wrong
path, or you're planning on bespoke configurations and basing your
business 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, and
paying folks to figure out how to remove as many pages and as many
steps and as much complexity as you can. Then remove some more. Then
look at what's involved with downloading patches, and start slashing
and burning there, too. That's where we are now or soon will be with
other systems; looking forward at 2022 or 2027, too.

[Dirk Munk]

Post by Stephen Hoffman

Post by David Froble

Post by Stephen Hoffman
The less effort I have to put on the end-user to establish a secure
connection, 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, gets
data, in a "really" simple manner, and then internally maybe builds
the 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 for
network folks. It does everything. DECnet-Plus and OSI were (are)
great ideas, massively capable and extremely flexible, marvelously
capable system, one of the most elegant and consistent implementations.
Also a blasted and complete and utter disaster to implement a new client
or new server under EMA — all of those capabilities and flexibilities
meant even the common cases were a whole lot more difficult to
implement, and hacked-together control programs are much easier — and
the whole user interface for DECnet-Plus is an intractable morass of
reading for any doesn't-want-to-be-an-expert user to perform even a
baseline server configuration for DECnet-Plus networking. For the
folks that just want to get connected and going, or to troubleshoot what
should be a baseline problem.

I checked the authors of the IPsec RFC's absolutely no link with DEC. If
IPsec would have had anything to do with DECnet-Plus, then it would have
been 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 it
is 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 with
Multinet.

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

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

Hurray, magnificent, I'm impressed.

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

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

Post by Stephen Hoffman
But then with OSI or with IP or with most anything else, we are NOT in
the same world that OpenVMS once was. We need OpenVMS and our own
applications to be much simpler to configure and use. Configuration
files are not the path forward, outside of knobs that only occasionally
need to be tweaked, and only by experts. Worse on OpenVMS, there's not
even a consistent API and parser for this configuration file stuff, so
we're all implementing our own and unique and less-than-robust versions
of configuration files, which just adds to the problems. Nor should
system parameter adjustments be a manual part of standard application
installs and configurations, for that matter. That all needs to be
automatic. So should connections into Open Directory or Active
Directory, pre-loaded certificates, easier patching, among other
enhancements.
Expecting all users to edit configuration files or MODPARAMS or such —
for even baseline configurations of the server software, or for your own
application deployments and software — and you're on the wrong path, or
you're planning on bespoke configurations and basing your business
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, and paying
folks to figure out how to remove as many pages and as many steps and as
much complexity as you can. Then remove some more. Then look at
what's involved with downloading patches, and start slashing and burning
there, too. That's where we are now or soon will be with other
systems; looking forward at 2022 or 2027, too.

[Arne Vajhøj]

Post by Stephen Hoffman
But then with OSI or with IP or with most anything else, we are NOT in
the same world that OpenVMS once was. We need OpenVMS and our own
applications to be much simpler to configure and use. Configuration
files are not the path forward, outside of knobs that only occasionally
need to be tweaked, and only by experts. Worse on OpenVMS, there's not
even a consistent API and parser for this configuration file stuff, so
we're all implementing our own and unique and less-than-robust versions
of configuration files, which just adds to the problems. Nor should
system parameter adjustments be a manual part of standard application
installs and configurations, for that matter. That all needs to be
automatic. So should connections into Open Directory or Active
Directory, pre-loaded certificates, easier patching, among other
enhancements.
Expecting all users to edit configuration files or MODPARAMS or such —
for even baseline configurations of the server software, or for your own
application deployments and software — and you're on the wrong path, or
you're planning on bespoke configurations and basing your business
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, and paying
folks to figure out how to remove as many pages and as many steps and as
much complexity as you can. Then remove some more. Then look at
what's involved with downloading patches, and start slashing and burning
there, too. That's where we are now or soon will be with other
systems; 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 not
the path forward.

Basically there are 3 approaches to config:
A) app specific text config file to be edited
B) app specific binary config file and admin GUI
C) one big binary config file and admin GUI for each app

In the server market #A has won. It is what the market wants.

Arne

[David Froble]

Post by Arne Vajhøj

Post by Stephen Hoffman
But then with OSI or with IP or with most anything else, we are NOT in
the same world that OpenVMS once was. We need OpenVMS and our own
applications to be much simpler to configure and use. Configuration
files are not the path forward, outside of knobs that only occasionally
need to be tweaked, and only by experts. Worse on OpenVMS, there's not
even a consistent API and parser for this configuration file stuff, so
we're all implementing our own and unique and less-than-robust versions
of configuration files, which just adds to the problems. Nor should
system parameter adjustments be a manual part of standard application
installs and configurations, for that matter. That all needs to be
automatic. So should connections into Open Directory or Active
Directory, pre-loaded certificates, easier patching, among other
enhancements.
Expecting all users to edit configuration files or MODPARAMS or such —
for even baseline configurations of the server software, or for your own
application deployments and software — and you're on the wrong path, or
you're planning on bespoke configurations and basing your business
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, and paying
folks to figure out how to remove as many pages and as many steps and as
much complexity as you can. Then remove some more. Then look at
what's involved with downloading patches, and start slashing and burning
there, too. That's where we are now or soon will be with other
systems; 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 problem
But I totally disagree with the idea that configuration files is not
the path forward.
A) app specific text config file to be edited
B) app specific binary config file and admin GUI
C) one big binary config file and admin GUI for each app
In 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 present
the options to the user in an easy to use format. Having a text file allows, on
rare (hopefully) occasions for a knowledgeable user to make modifications that
the 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 business
here". Maybe I don't, but it should be my decision.

[j***@yahoo.co.uk]

Post by David Froble

Post by Arne Vajhøj

Post by Stephen Hoffman
But then with OSI or with IP or with most anything else, we are NOT in
the same world that OpenVMS once was. We need OpenVMS and our own
applications to be much simpler to configure and use. Configuration
files are not the path forward, outside of knobs that only occasionally
need to be tweaked, and only by experts. Worse on OpenVMS, there's not
even a consistent API and parser for this configuration file stuff, so
we're all implementing our own and unique and less-than-robust versions
of configuration files, which just adds to the problems. Nor should
system parameter adjustments be a manual part of standard application
installs and configurations, for that matter. That all needs to be
automatic. So should connections into Open Directory or Active
Directory, pre-loaded certificates, easier patching, among other
enhancements.
Expecting all users to edit configuration files or MODPARAMS or such —
for even baseline configurations of the server software, or for your own
application deployments and software — and you're on the wrong path, or
you're planning on bespoke configurations and basing your business
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, and paying
folks to figure out how to remove as many pages and as many steps and as
much complexity as you can. Then remove some more. Then look at
what's involved with downloading patches, and start slashing and burning
there, too. That's where we are now or soon will be with other
systems; 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 problem
But I totally disagree with the idea that configuration files is not
the path forward.
A) app specific text config file to be edited
B) app specific binary config file and admin GUI
C) one big binary config file and admin GUI for each app
In 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 present
the options to the user in an easy to use format. Having a text file allows, on
rare (hopefully) occasions for a knowledgeable user to make modifications that
the 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 business
here". Maybe I don't, but it should be my decision.

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

A GUI (and/or text-mode equivalent) largely backed
by text config files and associated modular
configuration handlers is the way config
management has been done on SuSe Linux (and
related) for decades.

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

It administers pretty much everything I expect from
my Linuxes, and quite possibly what any reasonable
sysadmin could expect in most places. Its underlying
architecture and much of its implementation probably
could work elsewhere than Suse, maybe even elsewhere
than Linux. Things like replicated configs and such
are apparently handled too, though it's been a while
since I used those features.

Other Linuxes generally don't have the same approach
yet ("the nice thing about standards is there are so
many 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 no
point in looking elsewhere.

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

Have a lot of fun.

[Stephen Hoffman]

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

I use command-line tools for that. Some tools use that approach
within themselves — such as postconf within Postfix SMTP server, for
those that have used that mail server — and some platforms offer
command-line and GUI interfaces. GUI for the most common changes,
command-line changes for most of the rest, editing configuration files
for the most arcane and unusual. OpenVMS has nothing here. No
configuration file API, no parser, no command tools, no GUI. (Not
outside of the X11 tools and the OpenVMS Management Station and a few
other baubles that just aren't set up for widespread use. Not that
some descendent of OMS isn't likely, if VSI goes fully server-only with
OpenVMS.) Everybody rolls their own. Which means we get something
underneath 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* that
is the DEC C RTL logical name configuration mechanism, etc...

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

EMA tried this, and was way, way, way too complex for folks to use.

Ah, well.

[Arne Vajhøj]

Post by David Froble

Post by Arne Vajhøj
But I totally disagree with the idea that configuration files is not
the path forward.
A) app specific text config file to be edited
B) app specific binary config file and admin GUI
C) one big binary config file and admin GUI for each app
In 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 to
present the options to the user in an easy to use format. Having a text
file allows, on rare (hopefully) occasions for a knowledgeable user to
make 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 used
by end users.

Arne

[David Froble]

Post by Arne Vajhøj

Post by David Froble

Post by Arne Vajhøj
But I totally disagree with the idea that configuration files is not
the path forward.
A) app specific text config file to be edited
B) app specific binary config file and admin GUI
C) one big binary config file and admin GUI for each app
In 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 to
present the options to the user in an easy to use format. Having a text
file allows, on rare (hopefully) occasions for a knowledgeable user to
make 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 used
by end users.
Arne

Well, if you're reading what Steve writes, there will be less sysadm types, 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 can see that
some syntax isn't correct, and can warn, and make suggestions, isn't that better
regardless of expertise?

[Arne Vajhøj]

Post by David Froble

Post by Arne Vajhøj

Post by David Froble

Post by Arne Vajhøj
But I totally disagree with the idea that configuration files is not
the path forward.
A) app specific text config file to be edited
B) app specific binary config file and admin GUI
C) one big binary config file and admin GUI for each app
In 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 to
present the options to the user in an easy to use format. Having a text
file allows, on rare (hopefully) occasions for a knowledgeable user to
make 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 used
by end users.

Well, if you're reading what Steve writes, there will be less sysadm
types, 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 can
see that some syntax isn't correct, and can warn, and make suggestions,
isn't that better regardless of expertise?

The parser of the config file should note such things anyway.

Arne

[Stephen Hoffman]

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

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

Underneath the installation processes and configuration utilities for
those servers, there's a morass of subsystem-specific parsers for
subsystem-specific configuration files, there's APIs and storage based
on and integrated with LDAP, and a decent and generic layer of tools
and parsers for the platform-specific configuration files. Yes, not
what I'd want, but that's what we get when integrating code from
disparate sources.

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

If I have to create a configuration file on that platform as a
developer, I'm going to use the platform-specific tools, because
they're easier to use, the parser and the APIs are already written and
debugs, and they're very flexible. I'm probably also not going to be
hand-editing those files, as that's unnecessary given the command-line
tools and callable APIs. But editing those files manually — as
error-prone as that can be — is possible. OpenVMS utterly lacks a
standard format and APIs and a parser for this, so there's no choice
but to continue with the configuration file disaster; with the host
name scattered all over the place, the user settings all over the
place, with no standard directories for application-specific settings
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 no clue 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 produced for us on
OpenVMS: go change your host name. Want another? Go sort out the
certificate implementation. Need another? There's the utter joy that
is MODPARAMS and AUTOGEN and SYSBOOT, and the knock-off complexity all
that produces and particularly if you want your apps to not simply fall
over with weird errors when some setting isn't quite right.

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

This also ties into why I'd prefer to see Apache or nginx and other
now-table-stakes tools integrated into the base distro, because they'll
be in the same place, and all of us working on add-on software won't
have to conditionalize and complex-ify and glue-code-ify to deal with
all of the installation permutations that result from this ad-hoc,
no-rules, roll-your-own build-it-from-scratch server-construction-kit
approach. 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 DNS
services or the rest in your particular server configuration, leave
them shut them off. But for those of us that do have those
dependencies for add-on software or — much more perniciously — could
use those tools or services but don't because of the effort involved,
this eliminates massive quantities of baggage and glue code and
installation documentation and troubleshooting; of integrating with the
where-the-sneakers-is-that-package-installed-on-THIS-server morass that
arises, and also with the configuration files being scattered all over
the 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 bespoke
configuration files. Bespoke configuration files will certainly be
around and used and even newly created long after I'm past caring about
this certainly, but the need to manually edit configuration files will
increasingly not be in the installation path or the default operations
path. But we're already rolling out guest images and containers and
LDAP integration and MDM tools, among other details.

[Arne Vajhøj]

Post by Stephen Hoffman

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

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

Impressive.

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

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

Post by Stephen Hoffman
Underneath the installation processes and configuration utilities for
those servers, there's a morass of subsystem-specific parsers for
subsystem-specific configuration files, there's APIs and storage based
on and integrated with LDAP, and a decent and generic layer of tools and
parsers for the platform-specific configuration files.

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

Post by Stephen Hoffman
If I have to create a configuration file on that platform as a
developer, I'm going to use the platform-specific tools, because they're
easier to use, the parser and the APIs are already written and debugs,
and they're very flexible. I'm probably also not going to be
hand-editing those files, as that's unnecessary given the command-line
tools and callable APIs.

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

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

Yes.

And there are plenty of examples of standardization.

Java properties, Java preferences, .NET app/web.config, YAML, old INI
file format, modern JSON etc..

Post by Stephen Hoffman
with the host name
scattered all over the place, the user settings all over the place, with
no standard directories for application-specific settings 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 no clue 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 produced for us on OpenVMS: go
change your host name.

Yep.

Post by Stephen Hoffman
Want another? Go sort out the certificate
implementation. Need another? There's the utter joy that is MODPARAMS
and AUTOGEN and SYSBOOT, and the knock-off complexity all that produces
and particularly if you want your apps to not simply fall over with
weird errors when some setting isn't quite right.

Yep.

Post by Stephen Hoffman
This also ties into why I'd prefer to see Apache or nginx and other
now-table-stakes tools integrated into the base distro, because they'll
be in the same place, and all of us working on add-on software won't
have to conditionalize and complex-ify and glue-code-ify to deal with
all of the installation permutations that result from this ad-hoc,
no-rules, roll-your-own build-it-from-scratch server-construction-kit
approach. 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 DNS services
or the rest in your particular server configuration, leave them shut
them off. But for those of us that do have those dependencies for
add-on software or — much more perniciously — could use those tools or
services but don't because of the effort involved, this eliminates
massive quantities of baggage and glue code and installation
documentation and troubleshooting; of integrating with the
where-the-sneakers-is-that-package-installed-on-THIS-server morass that
arises, and also with the configuration files being scattered all over
the place, and with more easily replicating deployments for that matter.

I agree.

Post by Stephen Hoffman
I don't see the future of servers and of applications as bespoke
configuration files. Bespoke configuration files will certainly be
around and used and even newly created long after I'm past caring about
this certainly, but the need to manually edit configuration files will
increasingly not be in the installation path or the default operations
path. But we're already rolling out guest images and containers and
LDAP integration and MDM tools, among other details.

I would love to see vms.config with something like:

nodename = foobar
decnet_addres = 1.1
ip_address = 192.168.1.10
ip_net_size = 8
ip_router = 192.168.1.1
ip_domain = blabla.com
disk_mount = dka0:,dka1:,dka2:
start_scripts = sys$startup:xyz.com,sys$startup:xyz.com,
...

and then everything just happened.

One file to edit (manually or tool) and you are done for 95% of cases.

Arne

[Stephen Hoffman]

Post by Arne Vajhøj

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

Impressive.

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

Post by Arne Vajhøj
Simpler approaches —simpler for the end-users and the customers, but
more work and more thought for the folks that have to design and write
and test and deploy the server-related software that allows this
simplicity — are easier on the end-users, and is only going to become
more 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 to
work toward, both for themselves and for their own and third-party
developers? Toward chaos and anarchy, or toward simpler and easier?

Post by Arne Vajhøj

Post by Stephen Hoffman
Underneath the installation processes and configuration utilities for
those servers, there's a morass of subsystem-specific parsers for
subsystem-specific configuration files, there's APIs and storage based
on and integrated with LDAP, and a decent and generic layer of tools
and 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 all
custom, nor a customer-specific product.

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

Post by Arne Vajhøj

Post by Stephen Hoffman
If I have to create a configuration file on that platform as a
developer, I'm going to use the platform-specific tools, because
they're easier to use, the parser and the APIs are already written and
debugs, and they're very flexible. I'm probably also not going to be
hand-editing those files, as that's unnecessary given the command-line
tools and callable APIs.

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

Sure. Now you have to find the file, and either manually edit or code
a specific parser-generator for the format, and deal with all the
permutations 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 maintenance
and testing cases and parser error recovery and a whole host of other
topics that arise over time. Or the developer ignores all that, and
the app crashes with some weird error when column 42 of line 627
contains an unexpected character, and things get really weird when a
VFC file is fed into Apache and things blow up. As has happened on
several occasions, of course.

Post by Arne Vajhøj

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

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

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

What's most interesting for an operating system is to try to bring some
sanity to what the operating system itself and the associated layered
products do, and what products and packages that are integrated with
the operating system (usually) do. That's preferably not forcing the
system managers to learn each different formats and schemes and
configuration file locations and the rest. Unfortunately, that's also
exactly what OpenVMS currently forces system managers to do, and
developers and documentation folks to deal with and to describe.

Post by Arne Vajhøj

Post by Stephen Hoffman
with the host name scattered all over the place, the user settings all
over the place, with no standard directories for application-specific
settings 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 no
clue 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 produced
for us on OpenVMS: go change your host name.

...

Post by Stephen Hoffman
I don't see the future of servers and of applications as bespoke
configuration files. Bespoke configuration files will certainly be
around and used and even newly created long after I'm past caring about
this certainly, but the need to manually edit configuration files will
increasingly not be in the installation path or the default operations
path. But we're already rolling out guest images and containers and
LDAP integration and MDM tools, among other details.

nodename = foobar
decnet_addres = 1.1
ip_address = 192.168.1.10
ip_net_size = 8
ip_router = 192.168.1.1
ip_domain = blabla.com
start_scripts = sys$startup:xyz.com,sys$startup:xyz.com,
...
and then everything just happened.

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

As for:

ip_address = 192.168.1.10
ip_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 use
human notation, and try to avoid having interconnected settings where
you can manage it. I'd likely alsio want the DECnet settings block to
be separate from the IP settings, too; a separate block within the
configuration file. Again, all of this is implemented in other
systems now, so there are examples to learn from. Both what can be
done and how, as well as existing designs that just don't work well and
are best avoided.

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

SYSMAN> NETWORK SET /IPV4=192.168.1.10 /SUBNET=24 /GATEWAY=192.168.1.1
/DNS=(192.168.1.2,192.168.1.3) /DOMAIN=example.com foobar

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 a
separate qualifier.

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

OpenVMS was once commonly using this sort of configuration tool
approach — often with Control Program (CP) as the suffix on the
filename — that edited and managed the configuration files for the
user, and handled syntax errors and related processing. In recent
years, the configuration files have increasingly become directly
exposed. And that occasionally tip over when some change uses
incorrect syntax, and which is an error that might occur months after
the change was made because we all know everybody doesn't always syntax
check or reboot the application or the server right after the change.
Some of these bugs can lurk for months, and some reboot a year later
can tip over and cause a scramble when some service reports a weird
error or — as has happened — when the TCP/IP Server SMTP mail server
silently turns itself into an open relay due to an errant logical name
setting.

Post by Arne Vajhøj
One file to edit (manually or tool) and you are done for 95% of cases.

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

[IanD]

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

Where is the overall VMS framework vision?

/Posts and runs for cover...

[Kerry Main]

-----Original Message-----
Stephen Hoffman via Info-vax
Sent: January 9, 2017 9:06 PM
Subject: Re: [Info-vax] Using IPsec on VMS

[snip]

Ayup. Or avoid all this, if the server asks the DHCP server for this
stuff, and loads the network configuration data automatically from the
DHCP server and/or from the profile server and/or the local mDNS
configuration, etc. All the configuration is acquired via the DHCP
and/or profile server or LDAP or such, and nobody needs to log into the
just-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

Orig url will wrap:
http://www.routerfreak.com/ip-address-management-tools-a-review-of-some-of-the-best-ipam-tools-available-today/


Regards,

Kerry Main
Kerry dot main at starkgaming dot com

[Dirk Munk]

Post by Dirk Munk

Post by David Froble
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 of features.

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

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

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

(Ignoring for the moment that DECnet-Plus and the associated OSI
management user interface was poor at best. If that particular zombie
ever gets back upright and staggering around again, that whole area
really needs some work. But I digress.)

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

There are certainly reasons
to use IPsec, but there are also good reasons not to. Implementing
OpenVMS-to-OpenVMS solutions — DECnet or otherwise — is less
interesting
(to me) than OpenVMS-to-whatever configurations. Even when the
OpenVMS-to-OpenVMS might be slightly better by some measures, as I'm
still going to have to deal with OpenVMS-to-otherwise connections, so
I might as well just use the same OpenVMS-to-whatever path and not
bother
mixing in the static-connection configuration or the platform-specific
OpenVMS-to-OpenVMS path.

You know very well that IPsec can also be used for VMS-to-whatever, or
whatever-to-whatever. I was concentrating on the VMS <> VMS
communication because of the difficulty in encrypting protocols like
DECnet 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. Not
only in VMS, but in IP also. Most IP solutions that I see are
half-baked, because IP is one big hobby project.

as
I still have to deal with establishing a secure connection — I can't
simply expect or trust that the end-user will have slogged through the
IPsec 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 —
because
I may well be running TLS across an IPsec link — and for dealing with
connection errors and the rest. Yes, this API would be
OpenVMS-specific, too. So there's that. (Now I have to go look at
libtls 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-tls
etc,
The less effort I have to put on the end-user to establish a secure
connection, the better off we all are.

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

[Jan-Erik Soderholm]

Post by Dirk Munk

Post by Dirk Munk

Post by David Froble
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 of features.

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

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

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

(Ignoring for the moment that DECnet-Plus and the associated OSI
management user interface was poor at best. If that particular zombie
ever gets back upright and staggering around again, that whole area
really needs some work. But I digress.)

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

There are certainly reasons
to use IPsec, but there are also good reasons not to. Implementing
OpenVMS-to-OpenVMS solutions — DECnet or otherwise — is less
interesting
(to me) than OpenVMS-to-whatever configurations. Even when the
OpenVMS-to-OpenVMS might be slightly better by some measures, as I'm
still going to have to deal with OpenVMS-to-otherwise connections, so
I might as well just use the same OpenVMS-to-whatever path and not
bother
mixing in the static-connection configuration or the platform-specific
OpenVMS-to-OpenVMS path.

You know very well that IPsec can also be used for VMS-to-whatever, or
whatever-to-whatever. I was concentrating on the VMS <> VMS communication
because of the difficulty in encrypting protocols like DECnet 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. Not only
in VMS, but in IP also. Most IP solutions that I see are half-baked,
because IP is one big hobby project.

as
I still have to deal with establishing a secure connection — I can't
simply expect or trust that the end-user will have slogged through the
IPsec 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 —
because
I may well be running TLS across an IPsec link — and for dealing with
connection errors and the rest. Yes, this API would be
OpenVMS-specific, too. So there's that. (Now I have to go look at
libtls 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-tls
etc,
The less effort I have to put on the end-user to establish a secure
connection, the better off we all are.

Great, then IPsec is wonderful. The end-user always has a secure connection
if 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 my
100 Mb fiber routed over "the internet" and into another router and
reaching my VMS box, what is the risk that someone sits with his ear
to the line and evesdropping my password?

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

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

[Dirk Munk]

Post by Jan-Erik Soderholm

Post by Dirk Munk

Post by Dirk Munk

Post by David Froble
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 of features.

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

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

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

(Ignoring for the moment that DECnet-Plus and the associated OSI
management user interface was poor at best. If that particular zombie
ever gets back upright and staggering around again, that whole area
really needs some work. But I digress.)

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

There are certainly reasons
to use IPsec, but there are also good reasons not to. Implementing
OpenVMS-to-OpenVMS solutions — DECnet or otherwise — is less
interesting
(to me) than OpenVMS-to-whatever configurations. Even when the
OpenVMS-to-OpenVMS might be slightly better by some measures, as I'm
still going to have to deal with OpenVMS-to-otherwise connections, so
I might as well just use the same OpenVMS-to-whatever path and not
bother
mixing in the static-connection configuration or the platform-specific
OpenVMS-to-OpenVMS path.

You know very well that IPsec can also be used for VMS-to-whatever, or
whatever-to-whatever. I was concentrating on the VMS <> VMS communication
because of the difficulty in encrypting protocols like DECnet 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. Not only
in VMS, but in IP also. Most IP solutions that I see are half-baked,
because IP is one big hobby project.

as
I still have to deal with establishing a secure connection — I can't
simply expect or trust that the end-user will have slogged through the
IPsec 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 —
because
I may well be running TLS across an IPsec link — and for dealing with
connection errors and the rest. Yes, this API would be
OpenVMS-specific, too. So there's that. (Now I have to go look at
libtls 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-tls
etc,
The less effort I have to put on the end-user to establish a secure
connection, the better off we all are.

Great, then IPsec is wonderful. The end-user always has a secure connection
if 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 my
100 Mb fiber routed over "the internet" and into another router and
reaching my VMS box, what is the risk that someone sits with his ear
to the line and evesdropping my password?
I'd say the risk is higher that someone utilise a bug in some component
and breaks in in some other way. Or guesses a weak password.
The user having his password on a sticker on the screen is probably
a larger security problem.

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

[Arne Vajhøj]

Post by Jan-Erik Soderholm
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 my
100 Mb fiber routed over "the internet" and into another router and
reaching my VMS box, what is the risk that someone sits with his ear
to 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 Soderholm
I'd say the risk is higher that someone utilise a bug in some component
and breaks in in some other way. Or guesses a weak password.
The user having his password on a sticker on the screen is probably
a larger security problem.

Sure.

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

Arne

[Karl Sturm]

Post by Dirk Munk
add 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-cbc
0xdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeef;

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.

[Dirk Munk]

Post by Karl Sturm

Post by Dirk Munk
add 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-cbc
0xdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeef;

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 that
choosing the best algorithm is very important.

I'm working on an another contribution about the crypto-hardware.

[Richard Maher]

Post by Dirk Munk
I’ve often mentioned that in my view IPsec should be used between two
VMS nodes to encrypt all IP traffic. IPsec is almost non-existing in the
present HPE TCPIP Services, but it is present in the Multinet stack, 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 remarkable
simple.
The following examples come from the MultiNet Installation and
Administrator'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 with
add 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-cbc
0xdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeef;
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
spdadd 10.1.1.1 10.2.1.1 any -P out ipsec esp/transport//use
ah/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. That
includes 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 no SSH
or 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 Matt
Muggeridge released a trial version or even when IPsec disappeared off
the 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 homogeneous
encryption and authentication solution" bullshit narrative! IPsec is
simply the best and most efficient sever-to-server or
known-client-to-server solution! No it can't be used for anonymous
web-pages; so what? Use TLS.

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

Cheers

[Dirk Munk]

Post by Richard Maher

Post by Dirk Munk
I’ve often mentioned that in my view IPsec should be used between two
VMS nodes to encrypt all IP traffic. IPsec is almost non-existing in the
present HPE TCPIP Services, but it is present in the Multinet stack, 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 remarkable
simple.
The following examples come from the MultiNet Installation and
Administrator'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 with
add 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-cbc
0xdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeef;
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
spdadd 10.1.1.1 10.2.1.1 any -P out ipsec esp/transport//use
ah/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. That
includes 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 no SSH
or 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 Matt
Muggeridge released a trial version or even when IPsec disappeared off
the 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 homogeneous
encryption and authentication solution" bullshit narrative! IPsec is
simply the best and most efficient sever-to-server or
known-client-to-server solution! No it can't be used for anonymous
web-pages; so what? Use TLS.
For clients I use
https://www.microsoft.com/en-au/store/p/pulse-secure/9nblggh3b0bp
Cheers

Thanks Richard,

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

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

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

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

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

[Bob Koehler]

Post by Dirk Munk
So I wanted to know how to set it up, and it proofed to be remarkable
simple.

Yeah, Multinet has always been like that. That's why some of us
never stopped using it when UC started shipping with VMS.