timekeeping with NTP & PTP

[Dirk Munk]

There have some discussions about exact timekeeping in the group lately.
For me the merits of exact timekeeping have been clear for decades. If
you are working in an environment where chains of computer systems are
passing information to each other, or where they are connected to
network devices, firewalls etc., then transactions, events, and other
things will have a timestamp attached to them. If there is some kind of
a problem in such a surrounding, then it is very important that you have
accurate timestamps to rely on, it is the only way you can analyse the
sequence of events with certainty.

For me it is self-evident that all devices in a network should have the
exact time, running an NTP client on every device is the best way to
achieve that.

Of course you can configure every server in such a way that it will get
its time from the internet. But then you may worry about malware getting
into your server over the NTP IP port (UDP or TCP). In that case you
might want to install your own NTP server with a GPS receiver. In fact
it is recommended that you have at least three time servers, and if you
have a big organization with enough cash, then that would be the best
thing to do. Three NTP servers on three different locations. Of course
there are other ways to implement an NTP infrastructure on your network
as well, it just requires a bit of thinking.

For some odd reason Microsoft never implemented the standard NTP
client/server program. The result is that Windows systems are often many
seconds out of sync, even if they have the SNTP client running.

However there is a real NTP client/server program based on the sources
from ntp.org available from the German GPS clock manufacturer Meinberg.
You can get it here:

https://www.meinbergglobal.com/english/sw/ntp.htm

I’ve been using it for years on Windows systems. The present version is
based on the current 4.2.8p9 sources from ntp.org. It seems the VMS NTP
stack is also based on the sources from ntp.org, perhaps some one can
check which version it is at present?

Meinberg produces a range of NTP/PTP GPS clocks and they also have a
PTPv2 interface card. It is used for nothing else as the PTP protocol,
so it can not be used as a network interface card. Since VSI is looking
at PTP, perhaps this can be a solution.

[Stephen Hoffman]

Post by Dirk Munk
There have some discussions about exact timekeeping in the group
lately. For me the merits of exact timekeeping have been clear for
decades. If you are working in an environment where chains of computer
systems are passing information to each other, or where they are
connected to network devices, firewalls etc., then transactions,
events, and other things will have a timestamp attached to them. If
there is some kind of a problem in such a surrounding, then it is very
important that you have accurate timestamps to rely on, it is the only
way you can analyse the sequence of events with certainty.
For me it is self-evident that all devices in a network should have the
exact time, running an NTP client on every device is the best way to
achieve that.

Ayup. IP networking is a fundamental capability of modern systems,
and should have been integrated into OpenVMS a decade ago. We will
continue to deal with the resulting mess and complexity and costs for
many years too, whether we might realize it or not.

Post by Dirk Munk
Of course you can configure every server in such a way that it will get
its time from the internet. But then you may worry about malware
getting into your server over the NTP IP port (UDP or TCP).

There's no reason to expose an NTP port to the 'net. Block that and
most other protocols at the firewall, save for those specific ports on
specific servers that must be exposed and those preferably in one or
more DMZ networks. If there's malware on the local local network —
which is increasingly likely in most non-trivial networks — then there
are problems well past NTP within OpenVMS given a long history of
down-revision versions and slow-to-arrive patches and
even-slower-to-be-installed patches. Within a larger organizational
network, placing a firewall in front of OpenVMS or segmenting a cluster
onto a restricted network or virtual network can help there and is
increasingly typical practice, though the necessary isolation that
entails is increasingly difficult to maintain over time. Folks tend to
connect printers or whatever they need to do their jobs, if the network
is not locked down.

Post by Dirk Munk
In that case you might want to install your own NTP server with a GPS
receiver. In fact it is recommended that you have at least three time
servers, and if you have a big organization with enough cash, then that
would be the best thing to do. Three NTP servers on three different
locations. Of course there are other ways to implement an NTP
infrastructure on your network as well, it just requires a bit of
thinking.

There are folks that use various time bases, and either
purpose-dedicated or host-based timebases. Whatever meets local
requirements.

If an organization is large enough or is time-sensitive enough to be
establishing an NTP infrastructure, there's more than a little other
thinking required, required, too. For an organization growing into
this complexity, this usually means setting up a Windows Server
configuration with Active Directory, DNS, Exchange Server and (where
needed) NTP servers, or setting up the Linux equivalents with Open
Directory and the other usual giblets possibly including NTP servers.

Post by Dirk Munk
For some odd reason Microsoft never implemented the standard NTP
client/server program. The result is that Windows systems are often
many seconds out of sync, even if they have the SNTP client running.

Not sure why I'm correcting a misconception around Microsoft Windows
here and particularly given I haven't used that platform in over a
decade, but Windows 7 Pro and Windows Server 2008 do have NTP and SNTP
capabilities. SNTP clients from Microsoft and Cisco can access NTP
servers, as well.

https://social.technet.microsoft.com/Forums/windowsserver/en-US/ffb1df0b-7c6e-4b2d-8fdf-b4ca0c014266/configuring-windows-7-as-an-ntp-server?forum=winserverPN

https://social.technet.microsoft.com/Forums/windowsserver/en-US/959d0bbe-96fa-4a07-a555-860596a5b1f5/windows-server-2012-as-a-ntp-server?forum=winserver8setup

http://microsoftgeek.com/?p=1359

[Dirk Munk]

Post by Dirk Munk
There have some discussions about exact timekeeping in the group
lately. For me the merits of exact timekeeping have been clear for
decades. If you are working in an environment where chains of computer
systems are passing information to each other, or where they are
connected to network devices, firewalls etc., then transactions,
events, and other things will have a timestamp attached to them. If
there is some kind of a problem in such a surrounding, then it is very
important that you have accurate timestamps to rely on, it is the only
way you can analyse the sequence of events with certainty.
For me it is self-evident that all devices in a network should have
the exact time, running an NTP client on every device is the best way
to achieve that.

Ayup. IP networking is a fundamental capability of modern systems, and
should have been integrated into OpenVMS a decade ago. We will
continue to deal with the resulting mess and complexity and costs for
many years too, whether we might realize it or not.

Post by Dirk Munk
Of course you can configure every server in such a way that it will
get its time from the internet. But then you may worry about malware
getting into your server over the NTP IP port (UDP or TCP).

There's no reason to expose an NTP port to the 'net. Block that and
most other protocols at the firewall, save for those specific ports on
specific servers that must be exposed and those preferably in one or
more DMZ networks. If there's malware on the local local network —
which is increasingly likely in most non-trivial networks — then there
are problems well past NTP within OpenVMS given a long history of
down-revision versions and slow-to-arrive patches and
even-slower-to-be-installed patches. Within a larger organizational
network, placing a firewall in front of OpenVMS or segmenting a cluster
onto a restricted network or virtual network can help there and is
increasingly typical practice, though the necessary isolation that
entails is increasingly difficult to maintain over time. Folks tend to
connect printers or whatever they need to do their jobs, if the network
is not locked down.

Post by Dirk Munk
In that case you might want to install your own NTP server with a GPS
receiver. In fact it is recommended that you have at least three time
servers, and if you have a big organization with enough cash, then
that would be the best thing to do. Three NTP servers on three
different locations. Of course there are other ways to implement an
NTP infrastructure on your network as well, it just requires a bit of
thinking.

There are folks that use various time bases, and either
purpose-dedicated or host-based timebases. Whatever meets local
requirements.
If an organization is large enough or is time-sensitive enough to be
establishing an NTP infrastructure, there's more than a little other
thinking required, required, too. For an organization growing into
this complexity, this usually means setting up a Windows Server
configuration with Active Directory, DNS, Exchange Server and (where
needed) NTP servers, or setting up the Linux equivalents with Open
Directory and the other usual giblets possibly including NTP servers.

You could do that, or use a simple hard to hack device to get the time
from the internet and use it as an NTP timeserver. My cheap home router
does that too, in fact it will announce itself as an NTP timeserver in
its DHCP messages.

Post by Dirk Munk
For some odd reason Microsoft never implemented the standard NTP
client/server program. The result is that Windows systems are often
many seconds out of sync, even if they have the SNTP client running.

Not sure why I'm correcting a misconception around Microsoft Windows
here and particularly given I haven't used that platform in over a
decade, but Windows 7 Pro and Windows Server 2008 do have NTP and SNTP
capabilities. SNTP clients from Microsoft and Cisco can access NTP
servers, as well.
https://social.technet.microsoft.com/Forums/windowsserver/en-US/ffb1df0b-7c6e-4b2d-8fdf-b4ca0c014266/configuring-windows-7-as-an-ntp-server?forum=winserverPN
https://social.technet.microsoft.com/Forums/windowsserver/en-US/959d0bbe-96fa-4a07-a555-860596a5b1f5/windows-server-2012-as-a-ntp-server?forum=winserver8setup
http://microsoftgeek.com/?p=1359

W32time isn't very accurate, in fact Microsoft recommends using a third
party time program if you need really accurate time.

My wristwatch is synchronised with the DCF-77 longwave time transmitter
in Germany, so it's always accurate. When I had installed my Windows 7
notebook years ago, I noticed a time difference between the time of the
notebook and the time of my wristwatch. This happened even though I had
set up the notebook to synchronize with nl.pool.ntp.org.

After installing Meinberg's NTP program (it runs as a service), the time
is always accurate.

[Stephen Hoffman]

Post by Dirk Munk
W32time isn't very accurate, in fact Microsoft recommends using a third
party time program if you need really accurate time.

The Microsoft folks had more than a little discussion of that over the
years — they weren't polling the time servers but once a week in
various Windows configurations and the local clocks inherently drift in
that interval — the same clock drift issue hits OpenVMS, as was
recently discussed here in the comp.os.vms in the the "What is setting
the time" thread — and Microsoft also didn't implement a means to
interpolate the time values received from multiple servers and to
establish the running time irrespective of noise — OpenVMS lacked that
for a while, too — and with the most recent Windows and Windows Server
releases, Microsoft has reportedly resolved these and related
timekeeping issues.

TL;DR: Upgrade to current Windows or Windows Server, and time skewage
should no longer be an issue.

With OpenVMS, wade through the utterly awful user interface and get NTP
configured and going. Why time synchronization not a default behavior
— with the requisite "do you want to allow your system time to be
inaccurate? [Y/(N)]" or some such question — is something to ponder.

Start here:
https://technet.microsoft.com/windows-server-docs/identity/ad-ds/get-started/windows-time-service/windows-2016-accurate-time


More background:
https://blogs.technet.microsoft.com/askds/2007/10/23/high-accuracy-w32time-requirements/

https://technet.microsoft.com/en-us/windows-server-docs/identity/ad-ds/get-started/windows-time-service/windows-time-service-tools-and-settings

https://technet.microsoft.com/windows-server-docs/identity/ad-ds/get-started/windows-time-service/windows-time-service


Can't say I've particularly noticed issues with Windows and Windows
timekeeping, given the use of other client and server platforms locally.

With OpenVMS servers and timekeeping, most of us have become accustomed
to the costs and the effort involved with the awful user interfaces,
unfortunately. But then again, IP networking is not and should not be
considered an afterthought or an add-on product anymore, either.
OpenVMS is still living in the last decade in that regard.

[Dirk Munk]

Post by Stephen Hoffman

Post by Dirk Munk
W32time isn't very accurate, in fact Microsoft recommends using a
third party time program if you need really accurate time.

The Microsoft folks had more than a little discussion of that over the
years — they weren't polling the time servers but once a week in
various
Windows configurations and the local clocks inherently drift in that
interval — the same clock drift issue hits OpenVMS, as was recently
discussed here in the comp.os.vms in the the "What is setting the
time"
thread — and Microsoft also didn't implement a means to interpolate
the
time values received from multiple servers and to establish the
running
time irrespective of noise — OpenVMS lacked that for a while, too —
and
with the most recent Windows and Windows Server releases, Microsoft
has
reportedly resolved these and related timekeeping issues.
TL;DR: Upgrade to current Windows or Windows Server, and time skewage
should no longer be an issue.
With OpenVMS, wade through the utterly awful user interface and get NTP
configured and going.

What do you mean with the 'awful user interface'? The ntp.conf file?
That is the standard configuration file for all NTP implementations,
also the one from Meinberg that I'm using on my PC.

Post by Stephen Hoffman
Why time synchronization not a default behavior —
with the requisite "do you want to allow your system time to be
inaccurate? [Y/(N)]" or some such question — is something to ponder.

I agree, but I've seen plenty of Unix system managers that were also to
lazy to configure NTP, or simply used NTPdate from a crontab batchfile.

Post by Stephen Hoffman
https://technet.microsoft.com/windows-server-docs/identity/ad-ds/get-started/windows-time-service/windows-2016-accurate-time

I've read it, but for stand-alone clients it's still a one time per day
synchronization, and no use of a drift file etc.

Post by Stephen Hoffman
https://blogs.technet.microsoft.com/askds/2007/10/23/high-accuracy-w32time-requirements/
https://technet.microsoft.com/en-us/windows-server-docs/identity/ad-ds/get-started/windows-time-service/windows-time-service-tools-and-settings
https://technet.microsoft.com/windows-server-docs/identity/ad-ds/get-started/windows-time-service/windows-time-service
Can't say I've particularly noticed issues with Windows and Windows
timekeeping, given the use of other client and server platforms locally.
With OpenVMS servers and timekeeping, most of us have become
accustomed
to the costs and the effort involved with the awful user interfaces,
unfortunately.

Again, the ntp.conf file is the standard file that is used by the NTP
software from ntp.org. It is used by all implementations of this
reference NTP software, and since VMS is also using it (according to
ntp.org), VMS has the same file. I just wonder which version of the NTP
software is used by VMS right now, older version are vulnerable for hacks.

Post by Stephen Hoffman
But then again, IP networking is not and should not
be
considered an afterthought or an add-on product anymore, either.
OpenVMS is still living in the last decade in that regard.

[Stephen Hoffman]

Post by Dirk Munk
What do you mean with the 'awful user interface'? The ntp.conf file?
That is the standard configuration file for all NTP implementations,
also the one from Meinberg that I'm using on my PC.

On other systems, I don't have to do anything — beyond maybe entering a
static IP address if I really need that — and entering a nearby city to
get the timezone. NTP and the rest is automatically available. I
don't have to install networking, go find a command line configuration
tool and futz around with a whole pile of cryptic concepts, and then go
enable NTP and then go edit a file. I'm skipping more than a few
ancillary steps here, such as figuring out how the editor works. The
sorts of stuff that experienced users are often utterly blind to
unfortunately, and that completely derail new users.

Post by Dirk Munk
Again, the ntp.conf file is the standard file that is used by the NTP
software from ntp.org.

On the other systems I deal with — which do have that file — I've never
had to access or modify it, and I have changed NTP servers on rare
occasions.

Post by Dirk Munk
It is used by all implementations of this reference NTP software, and
since VMS is also using it (according to ntp.org), VMS has the same
file.

But not all folks need to deal with the file, or the rest of the baggage.

Post by Dirk Munk
I just wonder which version of the NTP software is used by VMS right
now, older version are vulnerable for hacks.

TCP/IP Services V5.7 ECO5 is apparently based on ntp 4.2.0, though what
else might have happened to that version since ported to OpenVMS is
unclear. ntp-4.2.8p9 was released on 21 November 2016. The DNS
server is old, too.

[Dirk Munk]

Post by Stephen Hoffman

Post by Dirk Munk
What do you mean with the 'awful user interface'? The ntp.conf file?
That is the standard configuration file for all NTP implementations,
also the one from Meinberg that I'm using on my PC.

On other systems, I don't have to do anything — beyond maybe entering a
static IP address if I really need that — and entering a nearby city to
get the timezone. NTP and the rest is automatically available. I
don't have to install networking, go find a command line configuration
tool and futz around with a whole pile of cryptic concepts, and then go
enable NTP and then go edit a file. I'm skipping more than a few
ancillary steps here, such as figuring out how the editor works. The
sorts of stuff that experienced users are often utterly blind to
unfortunately, and that completely derail new users.

Perhaps NTP was used as a DHCP option? Then of course you you don't have
to do anything to get it working. That is what my router does.........

Post by Stephen Hoffman

Post by Dirk Munk
Again, the ntp.conf file is the standard file that is used by the NTP
software from ntp.org.

On the other systems I deal with — which do have that file — I've never
had to access or modify it, and I have changed NTP servers on rare
occasions.

DHCP.....? Normally the ntp.conf file has no configuration, just some
example lines. How should NTP know to look for internal NTP servers? Or
perhaps you want to use NTP broadcast messages?

Post by Stephen Hoffman

Post by Dirk Munk
It is used by all implementations of this reference NTP software, and
since VMS is also using it (according to ntp.org), VMS has the same file.

But not all folks need to deal with the file, or the rest of the baggage.

You have to figure it out once for all your servers. If a system manager
can't do this, he should look for another job.

Post by Stephen Hoffman

Post by Dirk Munk
I just wonder which version of the NTP software is used by VMS right
now, older version are vulnerable for hacks.

TCP/IP Services V5.7 ECO5 is apparently based on ntp 4.2.0, though what
else might have happened to that version since ported to OpenVMS is
unclear. ntp-4.2.8p9 was released on 21 November 2016. The DNS
server is old, too.

So it has nothing to do with VMS, VMS uses the reference software from
ntp.org, be it a rather outdated version.

[Michael Moroney]

Post by Dirk Munk

Post by Stephen Hoffman
TCP/IP Services V5.7 ECO5 is apparently based on ntp 4.2.0, though what
else might have happened to that version since ported to OpenVMS is
unclear. ntp-4.2.8p9 was released on 21 November 2016. The DNS
server is old, too.

So it has nothing to do with VMS, VMS uses the reference software from
ntp.org, be it a rather outdated version.

VMS can be, and has been, used as a reflector/amplifier in a DDOS attack
with that NTP version.

[Dirk Munk]

Post by Michael Moroney

Post by Dirk Munk

Post by Stephen Hoffman
TCP/IP Services V5.7 ECO5 is apparently based on ntp 4.2.0, though what
else might have happened to that version since ported to OpenVMS is
unclear. ntp-4.2.8p9 was released on 21 November 2016. The DNS
server is old, too.

So it has nothing to do with VMS, VMS uses the reference software from
ntp.org, be it a rather outdated version.

VMS can be, and has been, used as a reflector/amplifier in a DDOS attack
with that NTP version.

Yes, that happens when you don't update your software.

VMS is using open source software, Bind, NTP, OpenSSL, Samba, etc. In
that case VMS engineering should update their versions as soon as new
sources are published.

[Kerry Main]

-----Original Message-----
Dirk Munk via Info-vax
Sent: February 8, 2017 6:35 PM
Subject: Re: [Info-vax] timekeeping with NTP & PTP

Post by Michael Moroney

Post by Dirk Munk

Post by Stephen Hoffman
TCP/IP Services V5.7 ECO5 is apparently based on ntp 4.2.0,

though

Post by Michael Moroney

Post by Dirk Munk

Post by Stephen Hoffman
what else might have happened to that version since ported to

OpenVMS is

Post by Michael Moroney

Post by Dirk Munk

Post by Stephen Hoffman
unclear. ntp-4.2.8p9 was released on 21 November 2016. The

DNS

Post by Michael Moroney

Post by Dirk Munk

Post by Stephen Hoffman
server is old, too.

So it has nothing to do with VMS, VMS uses the reference software
from ntp.org, be it a rather outdated version.

VMS can be, and has been, used as a reflector/amplifier in a DDOS
attack with that NTP version.

Yes, that happens when you don't update your software.
VMS is using open source software, Bind, NTP, OpenSSL, Samba, etc.
In that case VMS engineering should update their versions as soon as
new sources are published.

Do not forget there is a danger in updating official versions to
quickly as well.

As other platforms have found out, releasing new versions without
proper testing can break both COTS and custom Apps big time -
especially when automated tools are being used to roll-out to large
numbers of servers.

Update quickly? Yes, but only after the appropriate amount of testing.


Commodity OS environments are used to "patch-n-pray" strategies, but
the OpenVMS Customer culture takes a different view.

Btw, Multinet is usually very current with its IP service components.


Regards,

Kerry Main
Kerry dot main at starkgaming dot com

[Dirk Munk]

Post by Kerry Main

-----Original Message-----
Dirk Munk via Info-vax
Sent: February 8, 2017 6:35 PM
Subject: Re: [Info-vax] timekeeping with NTP & PTP

Post by Michael Moroney

Post by Dirk Munk

Post by Stephen Hoffman
TCP/IP Services V5.7 ECO5 is apparently based on ntp 4.2.0,

though

Post by Michael Moroney

Post by Dirk Munk

Post by Stephen Hoffman
what else might have happened to that version since ported to

OpenVMS is

Post by Michael Moroney

Post by Dirk Munk

Post by Stephen Hoffman
unclear. ntp-4.2.8p9 was released on 21 November 2016. The

DNS

Post by Michael Moroney

Post by Dirk Munk

Post by Stephen Hoffman
server is old, too.

So it has nothing to do with VMS, VMS uses the reference software
from ntp.org, be it a rather outdated version.

VMS can be, and has been, used as a reflector/amplifier in a DDOS
attack with that NTP version.

Yes, that happens when you don't update your software.
VMS is using open source software, Bind, NTP, OpenSSL, Samba, etc.
In that case VMS engineering should update their versions as soon as
new sources are published.

Do not forget there is a danger in updating official versions to
quickly as well.
As other platforms have found out, releasing new versions without
proper testing can break both COTS and custom Apps big time -
especially when automated tools are being used to roll-out to large
numbers of servers.
Update quickly? Yes, but only after the appropriate amount of testing.
Commodity OS environments are used to "patch-n-pray" strategies, but
the OpenVMS Customer culture takes a different view.
Btw, Multinet is usually very current with its IP service components.
Regards,
Kerry Main
Kerry dot main at starkgaming dot com

You're right of course.

On the other hand it will take some time before such sources are
properly 'translated' to VMS, so any problems with other operating
systems will pop-up during that time.

The present NTP 4.2.0 version of VMS is about 11 years old, and
meanwhile we have seen all kind of security problems with NTP that have
been resolved in newer versions.

It only shows how much HP has neglected VMS I suppose, and I'm sure VSI
has much better plans.

[Simon Clubley]

Post by Kerry Main
Do not forget there is a danger in updating official versions to
quickly as well.
As other platforms have found out, releasing new versions without
proper testing can break both COTS and custom Apps big time -
especially when automated tools are being used to roll-out to large
numbers of servers.
Update quickly? Yes, but only after the appropriate amount of testing.

Define quickly.

Post by Kerry Main
Commodity OS environments are used to "patch-n-pray" strategies, but
the OpenVMS Customer culture takes a different view.

And what happens when everyone starts treating VMS in the same way as
other operating systems ?

Example: a security researcher reports a VMS security issue to VSI and
HP and gives them 60 days to fix it and issue a patch. The security
researcher then releases the details of the vulnerability at the same
time as the patch is released as this is the standard that other
operating systems are generally held to.

Question: What is an acceptable amount of time for the VMS site to
delay before installing this patch ?

VMS is in it's own little world at the moment where it gets to claim
how secure it is but without having to be held to the same standards
as everyone else. What happens when the security researchers decide
to start probing VMS with _today's_ security probing techniques
(and not those from the 1980s/1990s) and then hold VMS to the same
standards as everyone else ?

Question: why would the security researchers be motivated to do this ?
Answer: try reading some of the boasting on the VSI website.
That language is like a red flag to a whole herd of bulls if those
security researchers see it.

Simon.

[Kerry Main]

-----Original Message-----
Simon Clubley via Info-vax
Sent: February 11, 2017 10:08 PM
Subject: [Info-vax] VMS and security, was: Re: timekeeping with NTP

&

PTP

Post by Kerry Main
Do not forget there is a danger in updating official versions to
quickly as well.
As other platforms have found out, releasing new versions without
proper testing can break both COTS and custom Apps big time -
especially when automated tools are being used to roll-out to large
numbers of servers.
Update quickly? Yes, but only after the appropriate amount of

testing.
Define quickly.

Depends on severity of the issue.

Post by Kerry Main
Commodity OS environments are used to "patch-n-pray" strategies,

but

Post by Kerry Main
the OpenVMS Customer culture takes a different view.

And what happens when everyone starts treating VMS in the same
way as other operating systems ?

When issues are raised, I am confident they will be addressed in a
timeline that corresponds to the severity of the issue.

Why do you think otherwise?

Example: a security researcher reports a VMS security issue to VSI and
HP and gives them 60 days to fix it and issue a patch. The security
researcher then releases the details of the vulnerability at the same
time as the patch is released as this is the standard that other
operating systems are generally held to.
Question: What is an acceptable amount of time for the VMS site to
delay before installing this patch ?

Depends on severity of the issue.

VMS is in it's own little world at the moment where it gets to claim

how

secure it is but without having to be held to the same standards as
everyone else. What happens when the security researchers decide to
start probing VMS with _today's_ security probing techniques (and

not

those from the 1980s/1990s) and then hold VMS to the same
standards as everyone else ?
Question: why would the security researchers be motivated to do this ?
Answer: try reading some of the boasting on the VSI website.
That language is like a red flag to a whole herd of bulls if those

security

researchers see it.

And yet, to my knowledge, none have been raised yet. The language on
the VSI web site is no different than what the various OpenVMS web
sites have stated for the last 35+ years (DEC/Compaq/HP).

It would also require these security researchers to start learning
OpenVMS to the same level as they currently understand
Windows/Linux/UNIX.

To be clear, OpenVMS is not 100% secure - no platform is. I expect
there will be future security issues discovered.

However, as stated above, I am reasonably confident that security
issues will be addressed by VSI in a timeframe that is aligned with
the criticality of the issue.

I am still not clear why you think this is not the case.

Regards,

Kerry Main
Kerry dot main at starkgaming dot com

[Stephen Hoffman]

Post by Kerry Main
And yet, to my knowledge, none have been raised yet.

The second round of DEFCON hacks specifically mentioned the "cool and
unhackable" mantra as a reason why they started investigating OpenVMS.
They found vulnerabilities.

From one of the folks apparently involved: "We find the "unhackable"
monicker taken at face value by far too many people rather amusing (or
scary) and we are only using / making fun out of it to get the point
across."

Post by Kerry Main
The language on the VSI web site is no different than what the various
OpenVMS web sites have stated for the last 35+ years (DEC/Compaq/HP).

Whatever the origin of the language — and there are differences, IMO —
there's also that times and expectations and risks and exposures have
all changed markedly in the past decade.

Post by Kerry Main
It would also require these security researchers to start learning
OpenVMS to the same level as they currently understand
Windows/Linux/UNIX.

I'd rather the VSI folks start learning about what sorts of attacks are
being promulgated against other platforms, as well as how the other
platforms are responding to and patching those.

Post by Kerry Main
To be clear, OpenVMS is not 100% secure - no platform is. I expect
there will be future security issues discovered.
However, as stated above, I am reasonably confident that security
issues will be addressed by VSI in a timeframe that is aligned with the
criticality of the issue.

More than a few of the network services are down-revision, and have
been. Apache was down-revision for years. There are other issues.

Post by Kerry Main
I am still not clear why you think this is not the case.

Please review previous postings on this topic by Simon, myself and other folks.

Given Stark plans to have financial data on your servers, Stark is more
of a target than folks supporting a soda tax, too.
https://citizenlab.org/2017/02/bittersweet-nso-mexico-spyware/

[Simon Clubley]

Post by Kerry Main
However, as stated above, I am reasonably confident that security
issues will be addressed by VSI in a timeframe that is aligned with
the criticality of the issue.
I am still not clear why you think this is not the case.

Stephen has already said the same things I was going to say, so I
won't repeat them again.

However, there is one _very_ important point I need to make about
your comment above and it is a mistake I am seeing some people make
time and time again.

VSI represents the future of VMS development, but security issues
are not found on the systems of the future, they are found in the
installed base and VSI only has a portion of that installed base.

When a security issue is found, it's probably not only going to
be on VSI supplied systems, but it's also likely to be on HP
supplied systems as well.

There is a very very good reason why I always say VSI and HP when
discussing security matters and not simply VSI as any security issues
will have to be fixed by both VSI and HP in the timescale specified
by the security researcher (which is typically in the region of 60 days).

Simon.

[Stephen Hoffman]

When a security issue is found, it's probably not only going to be on
VSI supplied systems, but it's also likely to be on HP supplied systems
as well.

HPE are continuing to deliver on their roadmap for the future of OpenVMS.

Existing HPE OpenVMS customers should either be planning for or
acquiring and upgrading to the VSI OpenVMS releases, or planning their
migration to some other platform. Or continuing to invest minimally,
and hope that the associated debt that inevitably accrues won't be
called in sooner rather than later.

There is a very very good reason why I always say VSI and HP when
discussing security matters and not simply VSI as any security issues
will have to be fixed by both VSI and HP in the timescale specified by
the security researcher (which is typically in the region of 60 days).

BTW, incoming:
https://mta.openssl.org/pipermail/openssl-announce/2017-February/000095.html

[Kerry Main]

-----Original Message-----
Simon Clubley via Info-vax
Sent: February 13, 2017 9:22 AM
Subject: Re: [Info-vax] VMS and security, was: Re: timekeeping with
NTP & PTP

Post by Kerry Main
However, as stated above, I am reasonably confident that security
issues will be addressed by VSI in a timeframe that is aligned with
the criticality of the issue.
I am still not clear why you think this is not the case.

Stephen has already said the same things I was going to say, so I

won't

repeat them again.
However, there is one _very_ important point I need to make about
your comment above and it is a mistake I am seeing some people
make time and time again.
VSI represents the future of VMS development, but security issues

are

not found on the systems of the future, they are found in the

installed

base and VSI only has a portion of that installed base.

Security issues are found on not only older systems, but also recent
and new systems (as seen on the monthly security patches found on the
RH/MS security web sites).

When a security issue is found, it's probably not only going to be

on VSI

supplied systems, but it's also likely to be on HP supplied systems

as

well.

I would not say "probably" or "likely" as the code stream differences
from both companies is getting wider with each new VSI release.

Yes, there is a base code level, and if there is a common issue, then
HPE/VSI will need to coordinate their responses.

I have not seen any indication that this would not happen, just lots
of "what-if's".

There is a very very good reason why I always say VSI and HP when
discussing security matters and not simply VSI as any security

issues

will have to be fixed by both VSI and HP in the timescale specified

by

the security researcher (which is typically in the region of 60

days).

Simon.

And of course, the timeframe is based on criticality, potential impact
and a likely a few other considerations.


Regards,

Kerry Main
Kerry dot main at starkgaming dot com

[Simon Clubley]

Post by Simon Clubley

-----Original Message-----
Simon Clubley via Info-vax
Sent: February 13, 2017 9:22 AM
Subject: Re: [Info-vax] VMS and security, was: Re: timekeeping with
NTP & PTP
When a security issue is found, it's probably not only going to be

on VSI

supplied systems, but it's also likely to be on HP supplied systems

as

well.

I would not say "probably" or "likely" as the code stream differences
from both companies is getting wider with each new VSI release.

Yes, for the new stuff such as the TCP/IP stack but not if it's in
something like a core VMS system service.

Post by Simon Clubley
Yes, there is a base code level, and if there is a common issue, then
HPE/VSI will need to coordinate their responses.
I have not seen any indication that this would not happen, just lots
of "what-if's".

There is a very very good reason why I always say VSI and HP when
discussing security matters and not simply VSI as any security issues
will have to be fixed by both VSI and HP in the timescale specified by
the security researcher (which is typically in the region of 60 days).
Simon.

And of course, the timeframe is based on criticality, potential impact
and a likely a few other considerations.

In today's world, the timeframe is decided by the security researcher
and not the vendor although it is subject to some potential modification
based on requests from the vendor.

If the vendor decides that releasing a patch in the timeframe specified
isn't justified then the security researcher is likely to just go ahead
and release the information after the period given by the researcher
has expired.

At that point, the user community gets to decide if they agree with the
decision of the vendor.

Simon.

[Hunter Goatley]

Post by Kerry Main
Btw, Multinet is usually very current with its IP service components.

Kerry brought this thread to my attention. MultiNet V5.5 shipped with
NTP V4.2.7, I think, but in December, we released an ECO to bring it up
to the current release, NTP 4.2.8p9.

ftp://ftp.multinet.process.com/patches/multinet055/ntp-060_a055.zip

[Michael Moroney]

Post by Dirk Munk
Yes, that happens when you don't update your software.
VMS is using open source software, Bind, NTP, OpenSSL, Samba, etc. In
that case VMS engineering should update their versions as soon as new
sources are published.

Since the new VSI stack will be Multinet based, those who are using the
most recent Multinet release and find it's using outdated open source
software that could be a problem (like the NTP server I mentioned that
could be used as a DDOS amplifier), you may want to shoot an email to
VSI to be sure it gets updated, if we don't already know.

[Stephen Hoffman]

Post by Michael Moroney
Since the new VSI stack will be Multinet based, those who are using the
most recent Multinet release and find it's using outdated open source
software that could be a problem (like the NTP server I mentioned that
could be used as a DDOS amplifier), you may want to shoot an email to
VSI to be sure it gets updated, if we don't already know.

I would hope folks at VSI do know. If some key folks at VSI are not
already on the security notification lists for the constituent packages
as well as tapped into the more general security notification and
security breach lists and the new-version-release lists for constituent
packages, then please encourage the appropriate folks to do so now. If
folks at VSI haven't already done a constituent product version
inventory and a plan for upgrading those to current, please start that
work now too. Because as an operating system vendor, it is the job of
folks at VSI to know this stuff; when there are new versions and new
security patches. VSI is charging for its products and is marketing
those based on security, after all. Maybe research how to properly
offer a security bug bounty, if you want to try to set a floor on the
prices of OpenVMS hacks. Or start working with folks that can track
this sort of stuff for you, if y'all are busy with your existing
efforts; outsource some or all of it.

On these security lists, there'll also be some other interesting and
security-relevant discussions, such as a recent paper purporting to
show how to defeat ASLR using the MMU on modern processors.

Here's an example, though this case should already be in progress at
VSI:
https://mta.openssl.org/pipermail/openssl-announce/2017-February/000095.html


ps: VSI will also want to set up more formal security notification
paths, as Simon has certainly suggested once or twice. I'm certainly
skeptical around posting a security problem to an email address in a
posting such as yours, I don't know where that email will end up,
who or who else might have access to that mail, nor whether you really
work for VSI or are just somebody spoofing the name of somebody that
does phishing for security bugs,

[Simon Clubley]

Post by Stephen Hoffman

Post by Michael Moroney
Since the new VSI stack will be Multinet based, those who are using the
most recent Multinet release and find it's using outdated open source
software that could be a problem (like the NTP server I mentioned that
could be used as a DDOS amplifier), you may want to shoot an email to
VSI to be sure it gets updated, if we don't already know.

Michael, if VSI is approaching VMS on x86-64 development with the above
mindset, then it is going to get absolutely hammered if security
researchers start taking a serious look at VMS when it becomes available
on x86-64.

Stephen has written out a detailed list below of things you should be
doing and I _very_ strongly recommend you take his advice. It isn't
the 1980s/1990s any more when it comes to computer security and VSI
needs to stop behaving as if it is, or you are likely to be taught
this lesson the hard way.

You need to be part of the coordinated release process. You can't have
a security issue become public and then only have a patch become ready
1-2 months after a customer has told you about this new security issue.

Post by Stephen Hoffman
I would hope folks at VSI do know. If some key folks at VSI are not
already on the security notification lists for the constituent packages
as well as tapped into the more general security notification and
security breach lists and the new-version-release lists for constituent
packages, then please encourage the appropriate folks to do so now. If
folks at VSI haven't already done a constituent product version
inventory and a plan for upgrading those to current, please start that
work now too. Because as an operating system vendor, it is the job of
folks at VSI to know this stuff; when there are new versions and new
security patches. VSI is charging for its products and is marketing
those based on security, after all. Maybe research how to properly
offer a security bug bounty, if you want to try to set a floor on the
prices of OpenVMS hacks. Or start working with folks that can track
this sort of stuff for you, if y'all are busy with your existing
efforts; outsource some or all of it.
On these security lists, there'll also be some other interesting and
security-relevant discussions, such as a recent paper purporting to
show how to defeat ASLR using the MMU on modern processors.

Thank you for the list Stephen. Let's hope VSI take note of it.

Post by Stephen Hoffman
Here's an example, though this case should already be in progress at
https://mta.openssl.org/pipermail/openssl-announce/2017-February/000095.html
ps: VSI will also want to set up more formal security notification
paths, as Simon has certainly suggested once or twice. I'm certainly
skeptical around posting a security problem to an email address in a
posting such as yours, I don't know where that email will end up,
who or who else might have access to that mail, nor whether you really
work for VSI or are just somebody spoofing the name of somebody that
does phishing for security bugs,

Only once or twice ? :-) Seriously VSI, how long does it take to do
this ? This is an absolutely standard thing to expect from an OS vendor
these days along with Stephen's list above and it should have already
been done without me having to prompt you.

Simon.

[Michael Moroney]

Post by Simon Clubley

Post by Michael Moroney
Since the new VSI stack will be Multinet based, those who are using the
most recent Multinet release and find it's using outdated open source
software that could be a problem (like the NTP server I mentioned that
could be used as a DDOS amplifier), you may want to shoot an email to
VSI to be sure it gets updated, if we don't already know.

Michael, if VSI is approaching VMS on x86-64 development with the above
mindset, then it is going to get absolutely hammered if security
researchers start taking a serious look at VMS when it becomes available
on x86-64.

Looking back, I shouldn't have written that. We at VSI have very good
people working on the new TCPIP stack, and they know better than I to
keep it up to date. I am a little paranoid about TCPIP vulnerabilities
being the way to hack into systems, and the out-of-date HP stack makes
me cringe.

I am not involved with the new TCPIP stack, and what I wrote is not how
VSI plans to address TCPIP vulnerabilities.

[Dirk Munk]

Post by Michael Moroney

Post by Simon Clubley

Post by Michael Moroney
Since the new VSI stack will be Multinet based, those who are using the
most recent Multinet release and find it's using outdated open source
software that could be a problem (like the NTP server I mentioned that
could be used as a DDOS amplifier), you may want to shoot an email to
VSI to be sure it gets updated, if we don't already know.

Michael, if VSI is approaching VMS on x86-64 development with the above
mindset, then it is going to get absolutely hammered if security
researchers start taking a serious look at VMS when it becomes available
on x86-64.

Looking back, I shouldn't have written that. We at VSI have very good
people working on the new TCPIP stack, and they know better than I to
keep it up to date. I am a little paranoid about TCPIP vulnerabilities
being the way to hack into systems, and the out-of-date HP stack makes
me cringe.
I am not involved with the new TCPIP stack, and what I wrote is not how
VSI plans to address TCPIP vulnerabilities.

This link will give you some idea about the number of bugs that were
fixed since 4.2.0 (the VMS version of NTP):

https://www.eecis.udel.edu/~ntp/ntp_spool/ntp4/ChangeLog-stable

Do you have any idea what kind and version of NTP is being used in
Multinet?

[Stephen Hoffman]

Post by Michael Moroney

Post by Simon Clubley

Post by Michael Moroney
Since the new VSI stack will be Multinet based, those who are using the
most recent Multinet release and find it's using outdated open source
software that could be a problem (like the NTP server I mentioned that
could be used as a DDOS amplifier), you may want to shoot an email to
VSI to be sure it gets updated, if we don't already know.

Michael, if VSI is approaching VMS on x86-64 development with the above
mindset, then it is going to get absolutely hammered if security
researchers start taking a serious look at VMS when it becomes
available on x86-64.

Looking back, I shouldn't have written that. We at VSI have very good
people working on the new TCPIP stack, and they know better than I to
keep it up to date. I am a little paranoid about TCPIP vulnerabilities
being the way to hack into systems, and the out-of-date HP stack makes
me cringe.
I am not involved with the new TCPIP stack, and what I wrote is not how
VSI plans to address TCPIP vulnerabilities.

Ignoring that IP is a fundamental part of OpenVMS and can no longer be
separated — the utterly archaic and ill-considered layered product
implementation aside — security is far larger than IP.

Folks need to fundamentally understand how big a target is painted onto
y'all. Both as individuals, and as an organization. And then
painted onto your customers. Your mistakes become our exposures.
Your omissions, too.

What you don't know or don't implement or exposures not even considered
can hurt us.

As a developing example of this:

https://www.rsa.com/content/dam/pdfs/2-2017/kingslayer-a-supply-chain-attack.pdf


Don't think that something similar can't happen to OpenVMS.

TL;DR: You aren't even remotely paranoid enough.

[Stephen Hoffman]

Post by Dirk Munk

Post by Stephen Hoffman

Post by Dirk Munk
What do you mean with the 'awful user interface'? The ntp.conf file?
That is the standard configuration file for all NTP implementations,
also the one from Meinberg that I'm using on my PC.

On other systems, I don't have to do anything — beyond maybe entering a
static IP address if I really need that — and entering a nearby city to
get the timezone. NTP and the rest is automatically available. I
don't have to install networking, go find a command line configuration
tool and futz around with a whole pile of cryptic concepts, and then go
enable NTP and then go edit a file. I'm skipping more than a few
ancillary steps here, such as figuring out how the editor works. The
sorts of stuff that experienced users are often utterly blind to
unfortunately, and that completely derail new users.

Perhaps NTP was used as a DHCP option? Then of course you you don't
have to do anything to get it working. That is what my router
does.........

Post by Stephen Hoffman

Post by Dirk Munk
Again, the ntp.conf file is the standard file that is used by the NTP
software from ntp.org.

On the other systems I deal with — which do have that file — I've never
had to access or modify it, and I have changed NTP servers on rare
occasions.

DHCP.....? Normally the ntp.conf file has no configuration, just some
example lines. How should NTP know to look for internal NTP servers? Or
perhaps you want to use NTP broadcast messages?

DHCP to locate an NTP server? Sure, if that's around on the local
network. But many sites don't use DHCP with OpenVMS, and DHCP client
doesn't work all that well with OpenVMS servers, but that's fodder for
another day. There's no reason not to take a much simpler approach
here, and to establish a pool of default NTP servers in the default
OpenVMS install. Among those that folks don't choose to disable the
default NTP configuration and startup in this entirely-hypothetical
further integration of IP into OpenVMS, that'll cover the vast majority
of the folks installing OpenVMS. If the goal is to go full OSI here
with support for all configurations and variations, then sure, look
first for the local profile (once profiles are implemented), then any
locally-specified command configuration (or the config file if we're
going old-school), sniff for any multicast NTP servers, ask mDNS, and
then ask a DHCP server (RFC 5908). But a simple set of default
servers and network integration with a opt-out automatic startup solves
the common situations quite well without the added complexity. Yes,
additional customizations can be provided via a better user interface
than what presently exists, or by hacking around in UI-antiquity with a
manual and a text editor and a configuration file, ten meters of rope
and a torch, and do watch out for the grue.

If the VSI goal is to make OpenVMS more prevalent in the market,
there's simply no way that these sorts of fundamental UI weaknesses —
including sending people off to read arcane docs and manually edit text
files — are going to serve that goal.

The pool of NTP servers also accrues some simplistic telemetry data
that might be of interest to VSI, much like automatic patches and
related processing.

Post by Dirk Munk

Post by Stephen Hoffman

Post by Dirk Munk
It is used by all implementations of this reference NTP software, and
since VMS is also using it (according to ntp.org), VMS has the same file.

But not all folks need to deal with the file, or the rest of the baggage.

You have to figure it out once for all your servers. If a system
manager can't do this, he should look for another job.

You are quite mistaken here. This is unnecessary busy-work, and
unfortunately implemented in a characteristically overly complex and
unnecessarily manual means. Outside of comparatively unusual
circumstances, there is no need for an OpenVMS system manager to ever
see or need more than a "enable and use network time?" prompt at
OpenVMS configuration, as she has far better things to deal with than
to have to learn and spoon-feed a poor user interface with a
manually-invoked text editor session. Put another way, if the
platform developers cannot design and implement a far simpler means
using defaults and a simple configure-time prompt — if they can't do
better than the current morass — then the platform developers
themselves are either fundamentally resource constrained, or — should
these user interface trade-offs and shifts onto the end-users
accumulate past what customers will accept and pay for — the platform
developers too may well be looking for other jobs, along with many of
the system managers and application developers that learned the
platform-specific incantation.

This isn't about what the system manager knows, it's about recognizing
and respecting what else she has to contend with, and working to make
her job easier and more efficient. Customer focus, "the network is
the system", making the customer more efficient, whatever you want to
call this. RTFM ain't all that and a bag of chips. Increasingly not
in the current era, and certainly not with where we're headed.

Post by Dirk Munk

Post by Stephen Hoffman

Post by Dirk Munk
I just wonder which version of the NTP software is used by VMS right
now, older version are vulnerable for hacks.

TCP/IP Services V5.7 ECO5 is apparently based on ntp 4.2.0, though what
else might have happened to that version since ported to OpenVMS is
unclear. ntp-4.2.8p9 was released on 21 November 2016. The DNS
server is old, too.

So it has nothing to do with VMS, VMS uses the reference software from
ntp.org, be it a rather outdated version.

You are quite mistaken with that perception. You're not alone in that
misperception. IP network services are a fundamental part of any
modern computer. Not an add-on. This is the progression from "The
Network is the System", as DEC once used as a marketing mantra.
Unfortunately, OpenVMS development lost sight of that, preferring
instead to consider the pieces of the platform separately. Whether
VSI embraces that DEC mantra as part of their work toward the future of
the platform, we shall learn. Though they have little choice.

TL;DR: Simple is hard. But once you see and use a simpler user
interface, it greatly reduces interest in contending with UI
complexity. UI complexity such as pretty much the entirety of the
TCP/IP Services and the OpenVMS installation & configuration process,
for example. RTFM is not the best path to success, particularly when
there are approaches around that can completely eliminate the entire
manual configuration requirements — what amounts to the busy-work — for
the vast majority of the installations.

[Kerry Main]

-----Original Message-----
Stephen Hoffman via Info-vax
Sent: February 10, 2017 4:59 PM
Subject: Re: [Info-vax] timekeeping with NTP & PTP

[snip..]

You are quite mistaken with that perception. You're not alone in that
misperception. IP network services are a fundamental part of any
modern computer. Not an add-on. This is the progression from "The
Network is the System", as DEC once used as a marketing mantra.
Unfortunately, OpenVMS development lost sight of that, preferring
instead to consider the pieces of the platform separately. Whether
VSI embraces that DEC mantra as part of their work toward the future of
the platform, we shall learn. Though they have little choice.
From what I recall that is their direction i.e. VSI's new OpenVMS versions will only support the old (current) TCPIP stack for a limited time period.
TL;DR: Simple is hard. But once you see and use a simpler user
interface, it greatly reduces interest in contending with UI
complexity. UI complexity such as pretty much the entirety of the
TCP/IP Services and the OpenVMS installation & configuration process,
for example. RTFM is not the best path to success, particularly when
there are approaches around that can completely eliminate the entire
manual configuration requirements — what amounts to the busy-work
— for the vast majority of the installations.

I agree there is a need for much improved GUI mgmt. interfaces (web based btw) on OpenVMS as that is what Customers expect their L1 support resources to use when managing and/or configuring systems today.

Having stated this, as MS found out (finally implemented PowerShell after 25+ years), there is also a need for a very powerful command line environment to be used by L2 and other App support resources who need more than what a fancy GUI mgmt. provides.


Regards,

Kerry Main
Kerry dot main at starkgaming dot com

[Stephen Hoffman]

Post by Kerry Main

-----Original Message-----
Stephen Hoffman via Info-vax
Sent: February 10, 2017 4:59 PM
Subject: Re: [Info-vax] timekeeping with NTP & PTP

[snip..]

You are quite mistaken with that perception. You're not alone in that
misperception. IP network services are a fundamental part of any
modern computer. Not an add-on. This is the progression from "The
Network is the System", as DEC once used as a marketing mantra.
Unfortunately, OpenVMS development lost sight of that, preferring
instead to consider the pieces of the platform separately. Whether
VSI embraces that DEC mantra as part of their work toward the future of
the platform, we shall learn. Though they have little choice.

From what I recall that is their direction i.e. VSI's new OpenVMS
versions will only support the old (current) TCPIP stack for a limited
time period.

Alas, the stated plans of VSI have been a continuation of what OpenVMS
has traditionally done here, and specifically also what I've been
grumbling about in this thread.

Post by Kerry Main

TL;DR: Simple is hard. But once you see and use a simpler user
interface, it greatly reduces interest in contending with UI
complexity. UI complexity such as pretty much the entirety of the
TCP/IP Services and the OpenVMS installation & configuration process,
for example. RTFM is not the best path to success, particularly when
there are approaches around that can completely eliminate the entire
manual configuration requirements — what amounts to the busy-work — for
the vast majority of the installations.

I agree there is a need for much improved GUI mgmt. interfaces (web
based btw) on OpenVMS as that is what Customers expect their L1 support
resources to use when managing and/or configuring systems today.

You're about where things are now for various operating systems, and
OpenVMS is more than a few years behind that. VSI needs to aim five
or ten years into the future, given their development cycles. The
folks at HPE are certainly aware of remote management, and are pushing
hard on their preferred solutions. As are others. As for web GUIs,
I'd rather see a REST API via HTTPS, and maybe publishing the TNT/Argus
network protocols in the interim. See RedFish and DMTF giblets and
the REST APIs (related to HPE OneView) as one option here.

There's no good way for a third-party to implement their own custom
platform management for OpenVMS, either. I've thought about it.
Not with the present lack of documented OS-level APIs. Too small a
customer base, and too high a risk of having (for instance) the SMTP
configuration yanked out and reimplemented underneath your remote
management tool chain. Not that I'm a huge fan of editing text files
as a configuration UI, either. But I digress.

But all that is not what I was referencing in what was quoted of mine
above. My preference is to simply the whole complexity inherent in
dealing with OpenVMS and the add-on IP stack — whether that's based on
TCP/IP Services or the Process IP stack — and moving away from
requiring sequences that need management now; of removing and
simplifying management. Remote management is advantageous here and
certainly necessary. As are profiles, vastly better patch management,
LDAP and Kerberos integration, and improvements and overhauls in many
other areas. Requiring a system manager to futz around with NTP is
just stupid.

Post by Kerry Main
Having stated this, as MS found out (finally implemented PowerShell
after 25+ years), there is also a need for a very powerful command line
environment to be used by L2 and other App support resources who need
more than what a fancy GUI mgmt. provides.

Microsoft integrated the IP network stack into their platform more than
two decades ago. But then I don't usually look to Microsoft for
technical or user interface inspirations — though they have had some
very good ideas there, and some well worth reimplementing within
OpenVMS — they're far more skilled within the areas of business and
marketing.

[Dirk Munk]

Post by Stephen Hoffman

Post by Dirk Munk

Post by Stephen Hoffman

Post by Dirk Munk
What do you mean with the 'awful user interface'? The ntp.conf file?
That is the standard configuration file for all NTP implementations,
also the one from Meinberg that I'm using on my PC.

On other systems, I don't have to do anything — beyond maybe entering
a static IP address if I really need that — and entering a nearby
city to get the timezone. NTP and the rest is automatically
available. I don't have to install networking, go find a command
line configuration tool and futz around with a whole pile of cryptic
concepts, and then go enable NTP and then go edit a file. I'm
skipping more than a few ancillary steps here, such as figuring out
how the editor works. The sorts of stuff that experienced users are
often utterly blind to unfortunately, and that completely derail new
users.

Perhaps NTP was used as a DHCP option? Then of course you you don't
have to do anything to get it working. That is what my router
does.........

Post by Stephen Hoffman

Post by Dirk Munk
Again, the ntp.conf file is the standard file that is used by the
NTP software from ntp.org.

On the other systems I deal with — which do have that file — I've
never had to access or modify it, and I have changed NTP servers on
rare occasions.

DHCP.....? Normally the ntp.conf file has no configuration, just some
example lines. How should NTP know to look for internal NTP servers?
Or perhaps you want to use NTP broadcast messages?

DHCP to locate an NTP server? Sure, if that's around on the local
network. But many sites don't use DHCP with OpenVMS, and DHCP client
doesn't work all that well with OpenVMS servers, but that's fodder for
another day.

You were recalling your experiences with other systems, so my DHCP
remark was targeted at those systems. Furthermore in the IPv6 era DHCP
is the preferred way to set up the IP configuration.

Post by Stephen Hoffman
There's no reason not to take a much simpler approach
here, and to establish a pool of default NTP servers in the default
OpenVMS install.

pool.ntp.org? Already there, there's even a pool directive in NTP
(instead of server). But making that the default setting assumes the VMS
system has access to the internet, and that is not always? mostly? not
the case.

Post by Stephen Hoffman
Among those that folks don't choose to disable the
default NTP configuration and startup in this entirely-hypothetical
further integration of IP into OpenVMS, that'll cover the vast majority
of the folks installing OpenVMS. If the goal is to go full OSI here
with support for all configurations and variations, then sure, look
first for the local profile (once profiles are implemented), then any
locally-specified command configuration (or the config file if we're
going old-school), sniff for any multicast NTP servers, ask mDNS, and
then ask a DHCP server (RFC 5908).

I absolutely see no reason to use anything else then the open source
reference software from ntp.org. That automatically includes the
possible use of a configuration file.

Post by Stephen Hoffman
But a simple set of default servers
and network integration with a opt-out automatic startup solves the
common situations quite well without the added complexity.

Once again, it is by no means certain that the vms system will have
access to the internet. So that doesn't work.

Post by Stephen Hoffman
Yes,
additional customizations can be provided via a better user interface
than what presently exists, or by hacking around in UI-antiquity with
a manual and a text editor and a configuration file, ten meters of
rope and a torch, and do watch out for the grue.

I'm sure I'm an idiot, but I prefer manuals over days of searching the
internet and finding nothing else then conflicting information in
discussion groups etc.

Furthermore, configuration files offer the possibility to add comments
on the settings, why the settings are the way they are. That is what I
do, document the settings in the configuration files.

Post by Stephen Hoffman
If the VSI goal is to make OpenVMS more prevalent in the market,
there's
simply no way that these sorts of fundamental UI weaknesses —
including
sending people off to read arcane docs and manually edit text files —
are going to serve that goal.

Yes, Windows is much better in that respect. Hacking the registry is
very simple. And Linux has the advantage that there is no documentation
at all to speak of. That is why I liked Solaris, it is documented. Not
as good as VMS, but better then nothing. And that documentation helped
me lot in resolving problems.

Post by Stephen Hoffman
The pool of NTP servers also accrues some simplistic telemetry data
that
might be of interest to VSI, much like automatic patches and related
processing.

???? What do you mean???

Post by Stephen Hoffman

Post by Dirk Munk

Post by Stephen Hoffman

Post by Dirk Munk
It is used by all implementations of this reference NTP software,
and since VMS is also using it (according to ntp.org), VMS has the
same file.

But not all folks need to deal with the file, or the rest of the baggage.

You have to figure it out once for all your servers. If a system
manager can't do this, he should look for another job.

You are quite mistaken here. This is unnecessary busy-work, and
unfortunately implemented in a characteristically overly complex and
unnecessarily manual means. Outside of comparatively unusual
circumstances, there is no need for an OpenVMS system manager to ever
see or need more than a "enable and use network time?" prompt at
OpenVMS
configuration, as she has far better things to deal with than to have > to learn and spoon-feed a poor user interface with a manually-invoked > text
editor session. Put another way, if the platform developers cannot
design and implement a far simpler means using defaults and a simple
configure-time prompt — if they can't do better than the current
morass
— then the platform developers themselves are either fundamentally
resource constrained, or — should these user interface trade-offs and
shifts onto the end-users accumulate past what customers will accept
and
pay for — the platform developers too may well be looking for other
jobs, along with many of the system managers and application
developers that learned the platform-specific incantation.
This isn't about what the system manager knows, it's about recognizing
and respecting what else she has to contend with, and working to make
her job easier and more efficient. Customer focus, "the network is
the
system", making the customer more efficient, whatever you want to call
this. RTFM ain't all that and a bag of chips. Increasingly not in
the current era, and certainly not with where we're headed.

I totally disagree with you. I have seen what happens if system managers
get nothing else then rolling out pre-cooked configurations. they don't
have to think about anything, and consequently they don't know anything.
When there are problems, they have no idea where to look.

Post by Stephen Hoffman

Post by Dirk Munk

Post by Stephen Hoffman

Post by Dirk Munk
I just wonder which version of the NTP software is used by VMS right
now, older version are vulnerable for hacks.

TCP/IP Services V5.7 ECO5 is apparently based on ntp 4.2.0, though
what else might have happened to that version since ported to OpenVMS
is unclear. ntp-4.2.8p9 was released on 21 November 2016. The DNS
server is old, too.

So it has nothing to do with VMS, VMS uses the reference software from
ntp.org, be it a rather outdated version.

You are quite mistaken with that perception. You're not alone in that
misperception. IP network services are a fundamental part of any
modern computer. Not an add-on. This is the progression from "The
Network is the System", as DEC once used as a marketing mantra.
Unfortunately, OpenVMS development lost sight of that, preferring
instead to consider the pieces of the platform separately. Whether VSI
embraces that DEC mantra as part of their work toward the future of the
platform, we shall learn. Though they have little choice.
TL;DR: Simple is hard. But once you see and use a simpler user
interface, it greatly reduces interest in contending with UI
complexity. UI complexity such as pretty much the entirety of the
TCP/IP Services and the OpenVMS installation & configuration process,
for example. RTFM is not the best path to success, particularly when
there are approaches around that can completely eliminate the entire
manual configuration requirements — what amounts to the busy-work —
for the vast majority of the installations.

Is TCPIP$CONFIG so difficult? I don't think so. It is a simple question
and answer configuration, no more difficult then using a GUI. On the
contrary I would say. And still much better then the Unix way of
configuring.

[Stephen Hoffman]

Post by Dirk Munk
???? What do you mean???

I mean to use more modern knowledge and approaches and network
integration to reduce or to eliminate local logins and manual
management of at least key parts of the typical modern OpenVMS server.

You've made clear your preferences for the classic and more manual and
more knowledge-heavy approaches; an approach which DEC classically used
in years past, that required more effort and more focus — on tasks
which are increasingly either easily automated or otherwise
automatically determined or defaulted. That user interface approach is
increasingly problematic in my view. If you don't see problem with
TCPIP$CONFIG and with the rest, then I sincerely don't believe we're
going to have a reasonable path to further discuss these and other
changes. Changes that I absolutely believe are necessary for OpenVMS
to succeed outside the installed base.

[David Froble]

Post by Stephen Hoffman

Post by Dirk Munk
???? What do you mean???

I mean to use more modern knowledge and approaches and network
integration to reduce or to eliminate local logins and manual management
of at least key parts of the typical modern OpenVMS server.
You've made clear your preferences for the classic and more manual and
more knowledge-heavy approaches; an approach which DEC classically used
in years past, that required more effort and more focus — on tasks which
are increasingly either easily automated or otherwise automatically
determined or defaulted. That user interface approach is increasingly
problematic in my view. If you don't see problem with TCPIP$CONFIG and
with the rest, then I sincerely don't believe we're going to have a
reasonable path to further discuss these and other changes. Changes
that I absolutely believe are necessary for OpenVMS to succeed outside
the installed base.

Well, I don't have a large problem with TCPIP$CONFIG. However, there is a bit
too much assumption that the user knows what he's doing, and what it means.

Routing for example. It asks if you want to do gated routing, or something
else. Perhaps it might be nice if the tool, or something, told the user just
what the options mean.

No, don't start explaining gated routing, I can look it up if I need to. The
point is, the tool should not offer options without explaining them.

The BIND service is another.

The list could go one and on ....

[Stephen Hoffman]

Post by David Froble
Well, I don't have a large problem with TCPIP$CONFIG.

Neither do I. But then we — and our text editors for our
configuration files and our familiarity with the manuals — aren't
likely a growing future for OpenVMS, either.

Post by David Froble
However, there is a bit too much assumption that the user knows what
he's doing, and what it means.

Or that we have no idea what the user wants, and should ask about
everything and require manual configurations, etc.

Post by David Froble
Routing for example. It asks if you want to do gated routing, or
something else. Perhaps it might be nice if the tool, or something,
told the user just what the options mean.\

Or why you might even want to use an OpenVMS box as a very expensive
and inefficient router, for that matter.

Post by David Froble
No, don't start explaining gated routing, I can look it up if I need
to. The point is, the tool should not offer options without explaining
them.
The BIND service is another.

Or why OpenVMS would commonly be used as a really expensive DNS server,
and with a badly down-revision version of BIND. Some might want it on
OpenVMS, but I'd wager that's a small number. Most folks already have
an infrastructure with many of the folks having an affinity for running
DNS and LDAP and other service on Windows Server configurations, and
other folks running all that on Linux. For most OpenVMS
installations, aim the resolver at the existing router and the local
DNS servers and the rest, and off we go...

Post by David Froble
The list could go one and on ....

Ayup. And it does.

[Kerry Main]

-----Original Message-----
Stephen Hoffman via Info-vax
Sent: February 15, 2017 4:18 PM
Subject: Re: [Info-vax] timekeeping with NTP & PTP

Post by David Froble
Well, I don't have a large problem with TCPIP$CONFIG.

Neither do I. But then we — and our text editors for our
configuration files and our familiarity with the manuals — aren't likely a
growing future for OpenVMS, either.

Post by David Froble
However, there is a bit too much assumption that the user knows

what

Post by David Froble
he's doing, and what it means.

Or that we have no idea what the user wants, and should ask about
everything and require manual configurations, etc.

Post by David Froble
Routing for example. It asks if you want to do gated routing, or
something else. Perhaps it might be nice if the tool, or something,
told the user just what the options mean.\

Or why you might even want to use an OpenVMS box as a very
expensive and inefficient router, for that matter.

If one looks at hyper converged and software defined network strategies now starting to show up in DC's, there is a trend to move things away from physical network appliances to embed them on the hosts.

As an example, google "VMware NSX"
https://www.vmware.com/ca/products/nsx.html

Post by David Froble
No, don't start explaining gated routing, I can look it up if I need
to. The point is, the tool should not offer options without
explaining them.
The BIND service is another.

Or why OpenVMS would commonly be used as a really expensive DNS server,
and with a badly down-revision version of BIND. Some might want it on
OpenVMS, but I'd wager that's a small number. Most folks already have
an infrastructure with many of the folks having an affinity for running
DNS and LDAP and other service on Windows Server configurations, and
other folks running all that on Linux. For most OpenVMS
installations, aim the resolver at the existing router and the local DNS
servers and the rest, and off we go...

Post by David Froble
The list could go one and on ....

Ayup. And it does.

Lets not forget that this last statement is only true for the legacy TCPIP stack on OpenVMS which is in the process of being replaced with a new TCPIP stack that is based on current TCPIP standards.


Regards,

Kerry Main
Kerry dot main at starkgaming dot com

[Stephen Hoffman]

Post by Kerry Main

-----Original Message-----
Stephen Hoffman via Info-vax
Sent: February 15, 2017 4:18 PM
Subject: Re: [Info-vax] timekeeping with NTP & PTP
Or why you might even want to use an OpenVMS box as a very expensive
and inefficient router, for that matter.

If one looks at hyper converged and software defined network strategies
now starting to show up in DC's, there is a trend to move things away
from physical network appliances to embed them on the hosts.

I don't see how all that is even particularly comparable to running IP
routing on OpenVMS, nor as utterly cost-ineffective as running IP
routing on OpenVMS, nor are the (many) other details around how
deployments and SDN are implemented even remotely available on OpenVMS.
OpenVMS is a decade away from acceptance and integration into those
DC environments, in the best case. That includes VSI integration and
development work such as addressing the mess that is the current
OpenVMS installation and configuration and networking integration, as
well as then dragging the whole area forward to something more suited
for automated deployments; profiles, automated and remote management,
et al. There's far more to integrating into these networks, and
OpenVMS itself hasn't yet even integrated IP.

Post by Kerry Main
Lets not forget that this last statement is only true for the legacy
TCPIP stack on OpenVMS which is in the process of being replaced with a
new TCPIP stack that is based on current TCPIP standards.

VSI has already stated we're not going to get an integrated IP stack.
Not by any stretch. We're getting a variant of the Process variant of
the same add-on design. Integrating the stack will also either kill
the market for add-on network stacks, or will make the API integration
requirements more involved and complex. Neither of which will be
popular with the folks selling those stacks.

[Michael Moroney]

Post by Dirk Munk
Meinberg produces a range of NTP/PTP GPS clocks and they also have a
PTPv2 interface card. It is used for nothing else as the PTP protocol,
so it can not be used as a network interface card. Since VSI is looking
at PTP, perhaps this can be a solution.

Is a NIC with special firmware for PTP to keep timing sensitive code
away from the OS CPU, a special card, or an unmodified NIC that's
just not used for anything else to avoid other traffic from causing
interference and timing errors?

[Dirk Munk]

Post by Michael Moroney

Post by Dirk Munk
Meinberg produces a range of NTP/PTP GPS clocks and they also have a
PTPv2 interface card. It is used for nothing else as the PTP protocol,
so it can not be used as a network interface card. Since VSI is looking
at PTP, perhaps this can be a solution.

Is a NIC with special firmware for PTP to keep timing sensitive code
away from the OS CPU, a special card, or an unmodified NIC that's
just not used for anything else to avoid other traffic from causing
interference and timing errors?

First of all let me give you a link to a description of this card:

https://www.meinbergglobal.com/english/products/pci-express-ieee-1588-ptp-slave.htm

As you can see this is not a normal NIC, it is a special card with a
microprocessor and even a choice of very accurate oscillators to keep a
good clock source in case the connection to the master clock is lost.

It is even a 10/100Mb card, so my guess is that you should use a
completely separate network segment for PTP traffic, otherwise other
traffic will interfere as you suggested.

Intel has some 1 Gb/s NICs with special circuitry for PTP. These can be
used as general purpose NICs too, but they certainly have special
circuitry and processors for PTP. You can not use just any NIC for PTP,
that is not possible. I haven't seen any 10 Gb/s Intel card for PTP.

Unfortunately the Meinberg card doesn't have IPv6 support (yet?). On the
other hand if you are using a special network segment, it will not be
connected to anything else.

[Michael Moroney]

Thanks for the info. I don't know if there's any interest in that level
of time accuracy/precision on VMS.

[Dirk Munk]

Post by Michael Moroney
Thanks for the info. I don't know if there's any interest in that level
of time accuracy/precision on VMS.

Well, PTP is on your roadmap as something to look at.

VMS is also used in the financial world, and there very accurate time
seems to be very important.

I've even read an article where it said that they were developing hollow
fibers to increase the speed, and to increase the prolongation percentage.

The speed of light is 300,000 km/sec in a vacuum, but in a cable it is
60% of that speed, and in a fiber is also slower.

The reason for the all this was the financial world!

There are also some very interesting documents on the Meinberg web site
about timekeeping in Windows (difficult!) and Linux, and timekeeping
problems with the x86 architecture, all in conjunction with NTP (not
PTP!) I think you should read them.