LWN: Comments on "A rift in the NTP world"

A rift in the NTP world

hridhya09 — Wed, 27 May 2020 09:26:51 +0000

I need a recipe for implementing ntpsec in an arm system

A rift in the NTP world

hridhya09 — Thu, 21 May 2020 14:08:46 +0000

Can you share the steps for ntpsec implementation working package

A rift in the NTP world

Cyberax — Mon, 20 Feb 2017 23:19:16 +0000

WAF supports DESTDIR out of box, but it's a command-line option and not a variable. It also is parallel, but since it doesn't integrate with make's job server it can't be parallel across multiple builds.

A rift in the NTP world

nix — Mon, 20 Feb 2017 23:08:18 +0000

Er, if you think the problem there was just with the *instructions*, you're missing something. Not supporting DESTDIR in this day and age will make packagers want to strangle you. Not supporting parallel make is even worse.

Was this *really* an improvement? It's not looking anything like one from where I'm sitting. Any autobuilder out there understands configure/make/make install based systems supporting DESTDIR, like upstream ntp, and will at most need telling "use configure, here are the configure script options". Handling your special snowflake build system will be a lot more work, a lot more cursing, and a lot more packagers asking "why does this project even exist?".

(I hate scons too. Building Samba 4 wasn't terribly pleasant, either, particularly not for platforms with no Python installation but with a working compiler. I actually had to have the autobuilder *compile Python first*, install it in a virtualenv, then build Samba with that. Samba was worth it -- just. ntpsec... wouldn't be.)

A rift in the NTP world

fallenpegasus — Mon, 20 Feb 2017 19:55:01 +0000

Thank you for discovering those issues with our INSTALL file instructions for cross compiling. We're now working on fixing them.

A rift in the NTP world

pizza — Sun, 19 Feb 2017 03:56:30 +0000

All else being equal, I'd agree that the CII best practices are good to follow, but I feel compelled point out that a project that does little more than print out "hello world" could achieve a similar 100% badge.

That 100% score doesn't mean that a given project is actually suitable for a given task or meets any objectively meaningful code quality targets.

A rift in the NTP world

jnareb — Sat, 18 Feb 2017 23:32:51 +0000

NTPsec passed with 100% the CII Best Practices Badge:
https://bestpractices.coreinfrastructure.org/projects/79

I doubt that NTP Classic would pass it.

A rift in the NTP world

branden — Fri, 17 Feb 2017 15:08:04 +0000

Here's another edifying Eric Raymond story, wherein he covers himself in his usual glory.

http://invisible-island.net/ncurses/ncurses-license.html

A rift in the NTP world

anselm — Fri, 17 Feb 2017 00:24:22 +0000

And if Sons was serious, she should at least have *started* by offering to help, not by forking ...

It seems that's how esr and his friends roll. After all, didn't esr fork many of his other feather-in-the-cap projects, like the Jargon File and fetchmail?

The problem is that offering help requires a certain degree of deference towards the developers who have already been working on the project for a long time, and that doesn't come easy to people who consider themselves the greatest Unix programmers ever (remember that esr basically wrote The Book on the subject, or thinks so, anyway). If you're all “I'm new to this project but you're doing everything completely wrong – wrong language, wrong build system, and your code is insecure, too, let me sort this out for you already”, then forking is basically your only option because nobody likes a know-it-all bully.

A rift in the NTP world

Cyberax — Thu, 16 Feb 2017 19:23:18 +0000

Oy vey...

Weather stuff is written in all kinds of languages. It does NOT need to do anything realtime, just fast enough. Fortran is used simply because the earliest models hark back to the beginning of 60-s.

A rift in the NTP world

Wol — Thu, 16 Feb 2017 16:49:03 +0000

The trouble is, in this brave new tech world, the younger generation often think they *don't* *need* an older mentor.

It's all very well us telling them "here be dragons", but by the time they find out there really are dragons it's too late. They've been eaten.

Cheers,
Wol

A rift in the NTP world

Wol — Thu, 16 Feb 2017 16:36:16 +0000

Don't forget, that apparently the XFree86 committee were telling people who wanted a GUI on *nix to "go and use Windows".

And the fork to Xorg happened when said committee kicked the primary maintainer (ie the Indian doing the work, not the Chiefs pontificating) out of the project.

And actually, I find the reported comments of NTPsec that "the guys doing NTP are burnt out and should be retired" a perfect example of offensive propaganda. If they're burning out, they need help not flaming. And if Sons was serious, she should at least have *started* by offering to help, not by forking ...

Cheers,
Wol

A rift in the NTP world

Wol — Thu, 16 Feb 2017 16:28:36 +0000

> > C is the only rational choice for things that truly need to be fast and as close to the metal as possible. (Assembly is the best choice for true performance and reliability.)

> No, it's not. And assembly? LOL.

Which is why a lot of time critical stuff was (and is) written in Fortran.

Fortran was the language of choice when simulations had difficulty keeping up with the real world, for example in weather forcasting ...

Cheers,
Wol

Code cleanups don't solve NTP's security issues

pizza — Thu, 16 Feb 2017 14:37:32 +0000

Oh, and my comments are even more applicable to NTP-the-protocol.

Code cleanups don't solve NTP's security issues

pizza — Thu, 16 Feb 2017 14:21:29 +0000

> My concern is appliances where the IP addresses used are baked in.

It seems misguided to blame NTPd-the-project when the fault lies entirely with the idiots who shipped consumer gear with hardcoded, bad configurations.

(From NTPd's perspective, there's no way to tell a difference between "bad" and "good" here; that's entirely the integrator/administrator's purview)

Code cleanups don't solve NTP's security issues

Cyberax — Thu, 16 Feb 2017 08:06:20 +0000

There has been an idea to add a timestamp to DHCP replies. That would easily allow ~1s precision - more than enough to bootstrap DNSSEC and then acquire reliable NTP.

Code cleanups don't solve NTP's security issues

akkornel — Thu, 16 Feb 2017 07:15:28 +0000

The issue I see with relying on DNS is, if DNSSEC becomes more used, then having NTP require DNS won't work well, as DNS would require NTP to verify signatures. You could bypass DNSSEC verification just for the NTP IP lookup, but that seems dangerous to me. Similarly, using TLS would also be problematic, as you need to already have good time in order to verify TLS certificate dates.

So much of security today relies on each party in the exchange having the same, or similar, time.

If changes are being proposed, I would suggest relying on capabilities that already exist within DHCP:

1: ISPs which provide DHCP service should run at least three NTP server, and must include those NTP server IPs in all DHCP offers. Smaller ISPs may make arrangements with a higher-tier ISP, or other entity, if they're unable to run their own NTP servers. ISPs which do not provide DHCP service are exempt, although they may wish to provide NTP service for their customer ISPs.

2a: Router vendors must each obtain a vendor zone from the NTP Pool project, and configure that as their NTP servers for their router software. For example, 0.linksys.pool.ntp.org, 1.linksys.pool.ntp.org, and 2.linksys.pool.ntp.org would be the default NTP servers for a Linksys router.

2b: When the router receives one or more NTP server IP addresses in a DHCP offer, if the router accepts the DHCP offer, then the router must replace its existing NTP server entries with the NTP server IP addresses received in the DHCP offer: For each IP received in the DHCP offer, replace one of the pre-configured NTP servers.

2c: If the router provides DHCP (for example, to its local network), and the router received NTP server IP addresses from upstream, then the router must provide those NTP server IP addresses in all DHCP offers that the router makes to local machines.

Item 1 would be agreed upon and implemented by the ISPs. Those ISPs would then lean on their router suppliers, to ensure that the routers sold/rented/leased/whatever by the ISPs met all of the requirements of point 2. From there things could slowly flow to the remaining consumer router market. Some OSes are able to support getting NTP servers from DHCP; as more routers begin to provide them, OSes will begin to use them.

This would allow devices to get NTP servers from a "trusted" source (the same source giving them their IP address), and helps to localize NTP traffic to within an ISP (or an ISP's ISP). It also eliminates the reliance on things like DNS and TLS, with one exception: As DNS embraces DNSSEC more and more, point 2a will stop working. Point 2a is only a stopgap, so that router vendors will have something to put in default configs.

Code cleanups don't solve NTP's security issues

gdt — Thu, 16 Feb 2017 06:03:11 +0000

In contrast, NTPd has proper rate-limit mechanism built-in, such as KoD and good pooling interval, blocking NTP does NOT causes more user traffic.

We had issues in 2003 with SMC routers, and blocking that traffic lead to a multiplication of incoming traffic. The KoD option didn't arrive in servers until later, and then not in clients for years after that. So we had to specially engineer the network for ntpd until most of the purchasers of those routers retired them.

It would be very useful if issuing a ICMP Administratively Denied prevented retries. The ACL is unlikely to suddenly disappear, so it would be safe to disable the association entirely. It's much easier for a network to issue a ICMP than to deploy an anycast edge of ntpd servers to issue KoD replies.

Please note that "we've fixed it now" is desirable but not immediately useful for operating a network. We'll probably have to run special queuing for ntpd UDP control plane traffic for the next decade. So there might be only a few years where the network hasn't been running without a special fix for some ntpd issue. As you can see, the timescales in network operations are much longer than the timescales in development: you are at the leading edge of deployment, we have to deal with the trailing edge of deployments.

That's why I say that the total security picture is important, human factors and all. It's better to avoid issues than to fix them.

We not adverse to change. It would be useful if the major NTP authors formed a small cabal and had an approximate date where they all make a new release which moves the control channel to TCP (or even to TLS if you think that is wise).

Code cleanups don't solve NTP's security issues

gdt — Thu, 16 Feb 2017 05:04:58 +0000

DHCP using IP addresses is fine. That's a mechanism an administrator can use to modify the NTP server used by the appliance's software. My concern is appliances where the IP addresses used are baked in.

Code cleanups don't solve NTP's security issues

dwh — Wed, 15 Feb 2017 19:25:55 +0000

FYI, most (all?) DHCP server implementations accept time-server configuration in DNS name format, and perform the DNS lookup on behalf of the client.

So while the wire format DHCP protocol contents is 4-octet network byte order IPv4 or 16-octet network byte order IPv6 addresses, their contents are the result of DNS resolution and caching by the DHCP/DHCPv6 server; DNS remains the source of truth and clients receive updated results as they renew their leases (or abandon stale configuration when leases expire).

This is even when the DHCPv6 server offers IPv6 address(es), IPv6 multicast address(es), and also FQDN(s) all together for some reason that can never be adequately explained (RFC 5908).

Code cleanups don't solve NTP's security issues

biergaizi — Wed, 15 Feb 2017 19:02:06 +0000

> Being able to list IP addresses in the configuration — rather than only DNS names — is a major misfeature. These IP addresses get hardcoded by device manufacturers.

It is a separate issue, the issue of human, and it is not related to this post. Having a different NTP implementation won't make any differences, current NTPd has nothing wrong. Having a different protocol may have no use neither. It is much harder to solve all these problems than your imagine.

Usually, if a device comes with hardcoded NTP addresses, it, in fact, usually indicates their program is poorly-written, and the manufacturers are irresponsible.

Those devices have the worst homebrew NTP implementation on the planet,

1. They send ancient NTPv1 packets, while the latest version is NTPv4.
2. They synchronize their time on the beginning of an hour, effectively making a flooding attack. Another larger flooding attack starts at 00:00 UTC.
3. They retry interval is around 3 minutes, if fails to reach the server, make even more traffic to the server, rather than an exponentially-increase interval.
4. They still try to talk to the default hardcoded servers, even if an alternative server list is set.
5. They don't support the Kiss of Death packet, nothing can stop them if they became wild.

ST-1 servers are the most vulnerable: they have highest accuracy, with reference clock. Despite the acceptable usage of ST-1 are passing time to downstream, or for scientific purposes, since there's only a handful of them and often listed publicly, they are often spotted by those manufacturers, and put in their devices by default.

ST-1 are usually provided by universities, or unpaid volunteers for the public good of the Internet. If a single server got hardcoded in those mass-manufactured devices, serious consequences can happen, the volunteer may literally bankrupt: your whole institute/school will be kicked out from the Internet [0]; when you came to the manufacture asking to pay the damage they are responsible for, you are threatened by a lawyer from California. [1] The whole Internet community should honor the spirit of self-sacrifice of these NTP volunteers.

Most of the NTP pool servers has similar issues, once you're in and became well-known on the net, there's no way out and keep receiving bad-traffic. Fortunately given a reasonable bandwidth, it is often a negligible issue though. But not as always. [2]

> That's because of a second misfeature, where blocking NTP — even returning a ICMP Administratively Denied — causes more traffic than servicing NTP.

In contrast, NTPd has proper rate-limit mechanism built-in, such as KoD and good pooling interval, blocking NTP does NOT causes more user traffic. What increased is the abuser traffic. The damage caused by a standard NTPd and silly sysadmin is much less significant and is negligible compared to the Internet of Scary Things.

By the way, not only hardware devices can contains dangerous NTP code, but also software.

As long as manufactures still write broken code and unaware of the proper way to use NTP, nothing can be done to solve this issue. Many involved in these misuses and abuses are totally unaware what they are doing. The proper way to use of NTP should have been written in all textbooks related to practical networking lectures.

NTPd does has issues, it has legacy code issues, it has vulnerabilities, it is not so actively maintained, and previously it has reflection attack issues, but the issue you mentioned is human issue, not NTPd issues. We still have reflection attack issues, though it has been fixed, it is still another human issue.

[0]: Flawed Routers Flood University of Wisconsin Internet Time Server
http://pages.cs.wisc.edu/~plonka/netgear-sntp/

[1]: Open Letter to D-Link about their NTP vandalism
https://web.archive.org/web/20060423012837/http://people....

[2]: Recent NTP pool traffic increase
https://mailman.nanog.org/pipermail/nanog/2016-December/0...

Tom.

A rift in the NTP world

moltonel — Wed, 15 Feb 2017 18:01:37 +0000

That's one area where Rust shines: benchmarks consistently place it at the same level as C (with similar algorithms and optimization efforts). And Rust will allow you to iterate your optimization work faster because you're less likely to unwittingly break stuff.

Concerning "will work every time, guaranteed", it's a no-brainer that Rust's safety guarantees make that goal easier to attain than C. And yes, you can boot to Rust to avoid that pesky interfering OS.

Sure, nothing beat C's portability. But when I see that Rust is arriving on Arduino for example, I stop worrying.

A rift in the NTP world

Cyberax — Wed, 15 Feb 2017 17:46:50 +0000

> C is the only rational choice for things that truly need to be fast and as close to the metal as possible. (Assembly is the best choice for true performance and reliability.)
No, it's not. And assembly? LOL.

Hint: lots of hard-realtime trading systems are written in... Java. And these systems are not these laughable cases like stability control in cars where a failure simply leads to lost lives. If a trading system failure occurs then a much worse outcome happens - people lose MONEY.

> Operating at real-world timescales, you probably don't even want the OS in the loop for timing critical processing - modern OSes and hardware are now fast enough to really give you a false sense of security about the ability of a system to reliably do hard realtime control - "statistically works almost all the time" is NOT the same as "will work every time, guaranteed" - the latter is required in life-critical applications.
WTF OS has to do with the language of a fairly simple daemon? And IoT? You've forgotten to mention Machine Learning and Big Data for the complete Bullshit Bingo.

NTP is designed to do one thing - synchronize clocks of computers across the wide-area network. It needs to be as good as the network jitter, which for regular Internet is usually within multiple milliseconds.

A rift in the NTP world

Nelson — Wed, 15 Feb 2017 17:40:44 +0000

So there was a single machine in the world that could build ntp and the root password was lost? (You said that around 2:20 in that video.)

Can you explain any of that in more detail or is it simply hyperbole or is it worse? I mean, I'm pretty sure I've built in myself before and I was unaware that I was dependent upon that machine.

I get the message, I understand that there are these old project and they need transition plans and fresh air and such and that it's important. I'm even open to the idea that long-term supporting an opensource project might not be emotionally healthy, maybe it's better to hand things off for many reasons. I also get that things change and most problems have a different looking solution after the fact. I'd suggest that respect should be a key component of hacking. We should assume hacker solved problems the best they could with the information and knowledge and tools that they had at the time when we re-examine their solutions. It feels really disrespectful to hear stories that might not be entirely true being told as part of the process. In your presentation you also state the the tooling choices and build process were made to "maintain control," is that something you could also elaborate on? NTP was fundamentally a forkable opensource project, you can take it and patch it however you want, fork it, do whatever, what was it that constituted a control issue? Versus maybe a comfort issue. I only ask because, again, it sounds a little disrespectful, if he was a real control freak, it wouldn't be opensource at all and he'd have never asked for help, right?

I can email if I don't hear back here.

A rift in the NTP world

jubal — Wed, 15 Feb 2017 17:35:33 +0000

LWN has this useful feature called “subscriber link”, where a subscriber may provide a non-subscriber with a direct link to the paywalled article; and the article becomes visible after two weeks anyway.

(If neither of the options appeals to you, the actual subscription is dirt cheap and supporting high quality and independent tech journalism is very important.)

A rift in the NTP world

dublin — Wed, 15 Feb 2017 17:13:28 +0000

C is the only rational choice for things that truly need to be fast and as close to the metal as possible. (Assembly is the best choice for true performance and reliability.)

Operating at real-world timescales, you probably don't even want the OS in the loop for timing critical processing - modern OSes and hardware are now fast enough to really give you a false sense of security about the ability of a system to reliably do hard realtime control - "statistically works almost all the time" is NOT the same as "will work every time, guaranteed" - the latter is required in life-critical applications.

Most of the discussion here is making a fatally flawed assumption - namely, that "regular" computers (PCs, servers, etc.) are the main kinds of things that need time synchronization. This is why the full functionality of the original NTP codebase (and its offshoots such as PTP) is important - as IoT moves increasingly into hard realtime (especially for apps like comms between self-driving cars, robots cooperating in the same workspace, etc.), PTP or something similar is required. (PTP is the Precision Time Protocol offshoot of NTP, and is the leading current standard in high-resolution industrial/commercial measurements.) NTP proper is only good to about 1/100 of a second - but 10 ms is forever: long enough for very, very bad things to happen in the real world.

So in short, this isn't just about syncing PC clocks - that's pretty much trivial - the real issue is secure, reliable, synchronized microsecond clocks suitable for hard realtime IoT. As Mills says, the NTP group really does understand what that takes. I'm not convinced the NTPSec guys do... (at least not yet.)

A rift in the NTP world

rkeene — Wed, 15 Feb 2017 15:47:58 +0000

The information about building NTPSec provided by the parent commenter is wrong. Running "./waf build" returns the following error:

--- building host ---
The project was not configured: run "waf configure" first!

Further, running "./waf configure" fails predictably when cross-compiling (as generally you need to tell the system what platform is being targeted, though it could figure it out):
+ ./waf configure
Setting top to : /home/rkeene/devel/aurae/node/root/packages/ntpsec/workdir-pcXttoUpzzwX
Setting out to : /home/rkeene/devel/aurae/node/root/packages/ntpsec/workdir-pcXttoUpzzwX/build
--- Configuring host ---
Checking for 'gcc' (C compiler) : /home/rkeene/devel/aurae/common/compiler/online/x86_64-coreadaptive-linux/bin/gcc
Checking for program 'bison' : /home/rkeene/devel/aurae/common/detected-tools/bison
Checking compiler : no
The configuration failed
(complete log in /home/rkeene/devel/aurae/node/root/packages/ntpsec/workdir-pcXttoUpzzwX/build/config.log)

The "build.log" referenced is full of escape sequences that hinder readabilty (but I'm sure if I were using "cat" to view it would make it very colorful on my terminal) and a huge, hundred or so line Python stack trace that, from what I can gather from the stack trace, means it tried to run the code it just compiled... which of course won't work, since the code being generated isn't for the platform I'm compiling it on.

Helpfully, an "INSTALL" file is provided which tells us how to cross-compile NTPSec:

== Cross-compiling ==

Set up a cross-compile environment for the target architecture. At minimum
it will need its own binaries for the OpenSSL library.

Configure NTPSec with:

waf configure --enable-cross=/path/to/your/cross/cc

But when we actually try to use that:
+ ./waf configure --enable-cross=gcc
waf [commands] [options]
<...hundreds of lines of usage omitted...>
waf: error: no such option: --enable-cross

The usage information, however, indicates a different option of:
--cross-compiler=CROSS_COMPILER

So we try with that...
+ ./waf configure --cross-compiler=gcc
Setting top to : /home/rkeene/devel/aurae/node/root/packages/ntpsec/workdir-oyqK4b6LB8gE
Setting out to : /home/rkeene/devel/aurae/node/root/packages/ntpsec/workdir-oyqK4b6LB8gE/build
--- Configuring host ---
Checking for 'gcc' (C compiler) : /home/rkeene/devel/aurae/common/compiler/online/x86_64-coreadaptive-linux/bin/gcc
Checking for program 'bison' : /home/rkeene/devel/aurae/common/detected-tools/bison
Checking compiler : no
The configuration failed
(complete log in /home/rkeene/devel/aurae/node/root/packages/ntpsec/workdir-oyqK4b6LB8gE/build/config.log)

And the build.log looks like the same stack trace as before.

Let's assume "waf" is really dumb and tries to look at the filename of my compiler to determine the platform and give it a different name -- no change.

Let's assume it's ultra-extra dumb and is running "$CC" expecting it to be a native-compiler instead of using HOST_CC or CC_FOR_BUILD -- that seems to have gotten us further !

+ CC="${CC_FOR_BUILD}" ./waf configure --cross-compiler=gcc
Setting top to : /home/rkeene/devel/aurae/node/root/packages/ntpsec/workdir-JoHiSwi4ewtB
Setting out to : /home/rkeene/devel/aurae/node/root/packages/ntpsec/workdir-JoHiSwi4ewtB/build
--- Configuring host ---
Checking for 'gcc' (C compiler) : /home/rkeene/devel/aurae/common/detected-tools/gcc
Checking for program 'bison' : /home/rkeene/devel/aurae/common/detected-tools/bison
Checking compiler : yes
Compiler found : GCC
...
Asking python-config for pyembed '--cflags --libs --ldflags' flags : yes
Testing pyembed configuration : yes
Asking python-config for pyext '--cflags --libs --ldflags' flags : yes
Testing pyext configuration : Could not build python extensions
The configuration failed
(complete log in /home/rkeene/devel/aurae/node/root/packages/ntpsec/workdir-JoHiSwi4ewtB/build/config.log)

At this point, things are failing because it's asking our build system's "python-config" how to compile a Python extension, which differs from the host system Python... but there doesn't seem to be a way to tell it to use the correct "python-config", so we play some PATH tricks and get going further...

At this point, after reading the wrong comment, wrong documentation, and finally following the usage information and making a few guesses, then some workarounds ... the configuration is complete. Time to build it !

Of course there's no Makefile but the INSTALL documentation says we should NOW do "./waf build". It seems to work -- it's a bummer that it's not using a Makefile since it would otherwise integrate into the parallel build system.

Now we have to figure out how to install it -- with no conventional "make install DESTDIR=..." and the INSTALL file lacking (hey, atleast it's not just wrong this time) information on how to use DESTDIR. There seems to be a --destdir option to "waf", we try it out and it works on the first try... but at this point we notice we forgot to specify "--prefix" and "--sbindir" options to the configure step...

But there's no option for "--sbindir" and the "--bindir" option doesn't stop it from installing "ntpd" in /sbin, so we have to move it to the correct directory after the installation completes... and finally, we have a working package.

A rift in the NTP world

HedgeMage — Wed, 15 Feb 2017 15:22:59 +0000

Jumping in, while this article is not paywalled (it has been at other times I've tried to visit).

I'm Susan Sons, the "ISO Emeritus" who presented on NTPSec at O'Reilly Security Conference. While I've stepped down from my official role with NTPSec, I do what I can to raise awareness of NTPSec, both for the good of its community, and as a case study in what much of our infrastructure software is going through. Mark has already done a more than adequate job of addressing points related to the NTPSec/NTP classic split, so I shall limit myself to some personal notes:

I was not, to my knowledge, contacted by Bruce Byfield or anyone else researching this article. I find this surprising as I am incredibly easy to find. Feel free to drop "Susan Sons NTP" or "Susan Sons ICEI" or any similarly logical set into a search engine and see what happens. I've chosen to make my email addresses ( susan@icei.org for open source organization things, hedgemage@binaryredneck.net for personal, and sesons@iu.edu at work) quite public, and finding at least one of my phone numbers as well as my office address and home address should be trivial as well. While I do travel extensively for work, I'm good at following up, and there are people in my office who will bridge the gap if needed.

Being a hacker, I find this is a great defense against getting doxxed: it's already out there, and I don't care.

The full video of my interview with Mac Slocum is here for anyone who would like to see my remarks in context and un-edited:
https://www.oreilly.com/ideas/the-internet-is-going-to-fa...

I speak at length about the education I received at the feet of previous generations of software engineers, and how I built my career on their mentorship. I also talk about how one day I looked around, and there were not enough people like me in my generation waiting to take the hand-off. Succession planning matters, and it has not been happening. I created New Guard to attract and mentor new infrastructure software maintainers, and specifically to help them find opportunities to work under the Old Masters and learn as I did. We, the community of hackers, need to plan ahead, or our software infrastructure will be taken over by centralized powers who are happy to Balkanize it and curb the many freedoms many now take for granted.

My slides from the security conference presentation are here: http://slides.com/hedgemage/savingtime
The video of the presentation is available on O'Reilly Safari

I can't promise to follow up in this comment thread, as it has not been accessible at all times I've tried to visit. However, anyone who has questions for me is welcome to email me.

A rift in the NTP world

federico3 — Wed, 15 Feb 2017 13:48:26 +0000

If only Nim was stable enough...

Code cleanups don't solve NTP's security issues

pizza — Wed, 15 Feb 2017 02:16:24 +0000

Oh, one more thing that I accidently left out -- DHCP's 'time-server' attributes are specified in terms of IP addresses.

So you're always going to need to handle NTP client configuration in terms of IP addresses.

Code cleanups don't solve NTP's security issues

pizza — Wed, 15 Feb 2017 02:09:47 +0000

> Being able to list IP addresses in the configuration — rather than only DNS names — is a major misfeature.

I disagree. Forcing use of DNS names makes you reliant on DNS, which:

* requires that there be a DNS server, and that it be accessible.
* opens you up to dns hijacking should said DNS server (and all intermediate resolvers) not be under your direct control. It may prevent use of DNSSEC (as the local resolver's clock needs to be at least in the same ballpark as the server's)

..As an end-user and administrator of small (<50 user) networks, I've been bitten by all of these situations.

Code cleanups don't solve NTP's security issues

gdt — Wed, 15 Feb 2017 01:39:23 +0000

I'm a network engineer on a large internet network. NTP causes us problems, and has done so for decades.

Being able to list IP addresses in the configuration — rather than only DNS names — is a major misfeature. These IP addresses get hardcoded by device manufacturers and that IP address is then forever bound to provide NTP service. That's because of a second misfeature, where blocking NTP — even returning a ICMP Administratively Denied — causes more traffic than servicing NTP. It's reasonable to require people providing NTP infrastructure to also configure DNS, and this small hassle is worth the cost when they no longer wish to prove the service at that particular IP address.

The configuration file isn't really designed for the NTP pool. There's no way to apply a "restrict" statement to a pool DNS name. So most NTP deployments from Linux vendors are vulnerable out-of-the-box to allowing a subverted NTP pool machine to use those NTP clients in a DDoS multiplcation attack.

NTP needs the control channel moved to TCP, again to limit the ability of servers to launch traffic multiplication attacks.

I don't see NTPsec making these sort of changes, so I'd question the "sec" appellation.

A rift in the NTP world

chrisV — Tue, 14 Feb 2017 11:52:58 +0000

Thankfully the only time I have come across WAF is when trying to build pycairo-1.10.0 (the latest version available) with python-3. The WAF build system for pycairo is broken for versions of python after python-3.2. Anything as brittle as this which breaks when a new minor version of python comes out is surely unusable?

A rift in the NTP world

Cyberax — Tue, 14 Feb 2017 03:22:08 +0000

WAF does support cross-compilation for real-life large projects: https://wiki.samba.org/index.php/Waf#cross-compiling

I've had my share of issues with build toolchains and debugging even esoteric issues with Unicode capitalization on MacOS X in Scons was easier than finding out why autotools is not rebuilding stuff properly.

A rift in the NTP world

pizza — Tue, 14 Feb 2017 01:44:54 +0000

> The decision to move off autotools was not done to move to the "new shiny", but as a deliberate decision to help drive the cleanup.

Yeah, the last time I experienced a "help drive cleanup" migration away from autotools, it was GPSd to scons. It turned out to be easier to just backport fixes rather than fix the build system to work in a cross-compiled environment.

To paraphrase, Autotools is the worst build system, except for all the others.

A rift in the NTP world

fallenpegasus — Mon, 13 Feb 2017 21:10:51 +0000

I'm sorry you feel that way.

The decision to move off autotools was not done to move to the "new shiny", but as a deliberate decision to help drive the cleanup. The existing autotools was ancient, was itself out to date with the latest autotools generators and so was very difficult to update and revise, it will full of errors, it ran very slowly, and it was tightly entangled with all the out of date portability shims and ifdefs.

We made the technical decision that having a Python dependency to build would not be a difficult barrier. Every modern distro of every still shipping and still supported UNIX has a sufficiently up to date Python package, and most UNIX distros in fact now either actually require a Python install, or have Python in their core package set.

Regular users or even builders of NTPsec are not required to know or code in Python. Just do a "./waf build" and it should work. If it doesnt work on your system, please email us at contact@ntpsec.org and let us fix it for you.

If the WAF project ever dies, we will port to another build system. Maybe even to a modernerized autotools, if that is appropriate at the time.

A rift in the NTP world

clemensg — Mon, 13 Feb 2017 18:37:47 +0000

I was just considering a switch to NTPsec but then I saw you moved away from the well established autotools to one of the new shiny build systems available nowadays and no one can say for sure if it is still maintained in a few years. Autoconf/-make will be, that's for sure. It's the de-facto standard build system, not only in the GNU world. It is especially nice if you are doing cross-compilation.

Now you introduced more barriers for users and for developers. To build, you have to install Python. To understand the build process they need to know Python + waf: https://github.com/ntpsec/ntpsec/blob/master/wscript
autotools is complicated but waf is not a big improvement, imho. Only a different kind of complexity.

Many new build systems come and go. Remember Scons? Google wrote ninja/gyp/gn to "replace" it. waf is also a Scons fork/rewrite.

Why not just keep using Autotools? Developers need to know it anyway if they work on other free software projects and it does its job.

A rift in the NTP world

mathstuf — Mon, 13 Feb 2017 01:31:08 +0000

Note that with SOURCE_DATE_EPOCH from reproducible build efforts will make that date the date of the release or tag or some other static timestamp rather than "when this binary was built".

A rift in the NTP world

jmscott — Sun, 12 Feb 2017 23:02:33 +0000

regarding affordable gps i recommend meinberg

https://www.meinbergglobal.com/

excellent linux interface.

-j

A rift in the NTP world

smcv — Sun, 12 Feb 2017 18:10:25 +0000

> However, systems that are starting up need to know the date within no more than 68 years

I like systemd's trick for dealing with this: during early boot, if the kernel clock is before the date/time on which this particular version of systemd was compiled, it brings the clock forward to that date/time.

As long as you don't leave a device for decades without upgrading its OS, and rebuild systemd at least every few years (either for a security or other bug fix, or just artificially to get a newer timestamp), that's good enough.

There'd be nothing to stop the kernel doing the same trick with its own release or compilation date/time.