ntpsec | add mid 2018s leap-second.list file under ./etc (!839)

[Hal Murray]

(Moved to devel@ where more people will see it.)

gitlab at mg.gitlab.com said:
> Someone should carry it on a fast, reliable website. http://hpiers.obspm.fr
> is presumably bandwidth limited, the USNO has a slow FTP site, the IETF is
> out of date, and https://github.com/eggert/tz updates late. 

We should be very very careful not to contribute to DoS-ing somebody else's 
resources.

Crappy NTP implementations have a long history of being involved in abuse.   
The wiki page is pretty good.
  https://en.wikipedia.org/wiki/NTP_server_misuse_and_abuse

I think Dave Plonka's writeup of the U-Wisc event should be required reading 
for any CS networking class.  We should all reread it every now and then.
  http://pages.cs.wisc.edu/~plonka/netgear-sntp/

There can also be problems on the server side.  The return address on UDP 
queries can be forged.  That lets the attacker hide.  The server can do 
traffic limiting, with the obvious trade off between blocking small attacks 
and blocking legitimate traffic.

Many years ago, ntpd was setup to support amplification.  A small ntpq request 
could generate a huge response.  That's a wonderful resource for DDoS-ers.  
(The current code requires a cookie on large responses.  The cookie ensures 
that the request came from the return address.)

----------

Back to leap-seconds.

Their are 2 cases to consider: big servers with many clients and end-users 
with no clients.  There is probably a gray area in between.

End-clients don't need a leap-seconds file and/or can get it from their distro.

Big servers should probably have a leap-seconds file.

We shouldn't include it in our source tree.  It's only good for a year, and 
the timer starts when the upstream file is released, not when somebody grabs 
our tarball (which gets created N months after the official release).  Any 
distro using it from our tarball will break if they don't keep up to date.  
They should be able to update leap-seconds without touching the rest of the 
package.

We shouldn't wire in any URLs that could possibly be abused unless we control 
the target and/or have explicit permission.  (The pool sites in a sample 
ntp.conf are the only case I can think of where we have permission.)

We could setup a web site to distribute copies of the file.  We should use a 
separate DNS name so we can move the load to another site if problems develop.

I think distros can piggyback on the tzdata/IANA site.  It gets updated 
several times a year.  Distros are used to their updates.  I'm pretty sure we 
could convince them to push a special update if nothing else is going on.

How long does it take a distro to push out a tzdata update?



-- 
These are my opinions.  I hate spam.