Google public NTP service
Hi
I believe the point was: If you start tossing around packets that are odd sized, it is
likely to break a lot of existing code.
Bob
On Nov 30, 2016, at 3:35 PM, Gary E. Miller gem@rellim.com wrote:
Yo Poul-Henning!
On Wed, 30 Nov 2016 20:31:09 +0000
"Poul-Henning Kamp" phk@phk.freebsd.dk wrote:
In message F80F97D3-CE19-43B9-B37F-BE5D5F186D7E@n1k.org, Bob Camp
writes:
I would support an RFC to mark the type a time an chimer is
servings. Not only smeared and UTC, but also TAI, UT, UT0, UT1,
UT2, ET, TDT, TDB, TT, TCG, TCB, GPS, etc…
That would probably be a good point to make on the NTP list :)
The gotcha is that there is essentially zero time to approve and
implement something like that before the end of next month …
And no space in the NTP packets for the bits.
Not true. NTP has provision for arbitrrary extensions to an ntp packet.
See RFC 5905. https://www.ietf.org/rfc/rfc5905.txt section 7.3:
"The packet format consists of three components: the header itself,
one or more optional extension fields, and an optional message
authentication code (MAC). "
RGDS
GARY
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
gem@rellim.com Tel:+1 541 382 8588
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
Yo Poul-Henning!
On Wed, 30 Nov 2016 20:42:17 +0000
"Poul-Henning Kamp" phk@phk.freebsd.dk wrote:
In message 20161130123506.63853273@spidey.rellim.com, "Gary E.
Miller" writes :
Not true. NTP has provision for arbitrrary extensions to an ntp
packet.
Good luck getting that through firewalls after the lastest rounds
of NTP amplification attacks...
Good, then we get the firewalls eventually fixed as well.
Seems to me you gotta break things badly on the internet before they get
fixed.
RGDS
GARY
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
gem@rellim.com Tel:+1 541 382 8588
Yo Bob!
On Wed, 30 Nov 2016 15:42:58 -0500
Bob Camp kb8tq@n1k.org wrote:
I believe the point was: If you start tossing around packets that are
odd sized, it is likely to break a lot of existing code.
Not 'odd'. Fully specified in the RFC. Anyone that did not implement
the spec gets what they deserve.
IMHO, better for a packet that can be misinterpreted be dropped, Like
the new non-standard Google NTP. Unmarked these new packets can cause
havoc.
But, to be fair, some assert the spec is a bit ambiguous. So any
extention should be a new RFC. Like Autokey.
RGDS
GARY
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
gem@rellim.com Tel:+1 541 382 8588
In message 20161130125857.7229bba2@spidey.rellim.com, "Gary E. Miller" writes
:
Not 'odd'. Fully specified in the RFC. Anyone that did not implement
the spec gets what they deserve.
Gary,
Actually, anybody who does implement the spec precisely gets a lot
of things nobody should ever be at the receiving end of.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
From Gary Miller:
You gotta start sometime. Now is a good time. This is not the first
time Google has done this, and certainly will not be the last. It had
bad consequences last time and they did not learn from that.
This is not the fault of google. The big players will continue to innovate and solve timing problems as long as the official scientific and political world do nothing.
May I request that further discussion of this google / NTP / leap second issue take place in ntp forums or the LEAPSECS list, and not here on time-nuts.
Thanks,
/tvb
Moderator, http://leapsecond.com/time-nuts.htm
Yo Poul-Henning!
On Wed, 30 Nov 2016 21:01:44 +0000
"Poul-Henning Kamp" phk@phk.freebsd.dk wrote:
In message 20161130125857.7229bba2@spidey.rellim.com, "Gary E.
Miller" writes :
Not 'odd'. Fully specified in the RFC. Anyone that did not
implement the spec gets what they deserve.
Actually, anybody who does implement the spec precisely gets a lot
of things nobody should ever be at the receiving end of.
If you know of any such thing I suggest you bring it up on devel@ntpsec.org.
Several of the authors of the upcoming NTS spec hang out there.
If you can document anything specific the NTPsec team would like to get
it handled in their code and documentation. Currently they are turning
around fixes in days for most issues.
They have already changed a bit of their implementation of the RFC for
security reasons and would do so for any new issues. Things like
symetric mode are now automagically downgraded to a more secure client
server mode.
RGDS
GARY
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
gem@rellim.com Tel:+1 541 382 8588
Yo Tom!
On Wed, 30 Nov 2016 13:06:06 -0800
"Tom Van Baak" tvb@LeapSecond.com wrote:
From Gary Miller:
You gotta start sometime. Now is a good time. This is not the
first time Google has done this, and certainly will not be the
last. It had bad consequences last time and they did not learn
from that.
This is not the fault of google. The big players will continue to
innovate and solve timing problems as long as the official scientific
and political world do nothing.
This is not innovation, this is anarchy. We have standards that hard
working people have build over decades. Ignoring the lessons of the past
is a bad thing. Arbitrarily changing standards is the path to madness.
May I request that further discussion of this google / NTP / leap
second issue take place in ntp forums or the LEAPSECS list, and not
here on time-nuts.
I'll continue to suggest this move to devel@ntpsec.org. There are many
people on the NTP IETF committes there.
RGDS
GARY
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
gem@rellim.com Tel:+1 541 382 8588
On 11/30/2016 3:35 PM, Gary E. Miller wrote:
Not true. NTP has provision for arbitrrary extensions to an ntp packet.
See RFC 5905. https://www.ietf.org/rfc/rfc5905.txt section 7.3:
HA! ntp (the implementation) doesn't follow the RFC, which says that ntp
(the protocol) is supposed to count seconds in an epoch. It doesn't, it
deliberately miscounts when there's a leap second. Instead of simply
counting seconds like TAI, it's broken just like POSIX.
Michael Rothwell kirjoitti:
... was just announced.
https://cloudplatform.googleblog.com/2016/11/making-every-leap-second-count-with-our-new-public-NTP-servers.html?m=1
I wonder what this stupid "leap smear" will do to NTP driftfiles. Only
Google may be stupid enough to grow one second lasting minor timing
issue to ten hours lasting serious timing issue with even longer effects
if driftfiles will be adjusted to neet their temporary and changing
non-standard clock rate.
--
73s!
Esa
OH4KJU
On Wed, Nov 30, 2016 at 12:14 PM, Gary E. Miller gem@rellim.com wrote:
Yo Michael!
On Wed, 30 Nov 2016 14:21:39 +0000
Michael Rothwell michael@rothwell.us wrote:
... was just announced.
https://cloudplatform.googleblog.com/2016/11/making-
every-leap-second-count-with-our-new-public-NTP-servers.html?m=1
I sort of see where they are coming from, but this will cause problems.
The NTP packets google sends out have no way to be marked as 'not UTC'.
Given how promiscuous people are sharing NTP chimers these 'not UTC'
chimers will get into the mix. When they diverge from the real UTC servers
it will sorely confuse NTP clients.
No, not confused at all NTP is designed to detect this problem. The
Google servers will be detected as "False Tickers" and ignored. Of course
some clients might be configured to look ONLY at Google servers but those
people like did that on purpose because they wanted to wrong time. Anyone
with a normal NTP client that uses several different servers will be fine.
The for people who don't know how Ntp works, it is simple: If you (a
human) ask a bunch of people "what time is it?" you would expect them all
to give you the same answer (within the precision of their wrist watches)
and if one person tells you something that is very different from everyone
else. You do NOT become confused you just say to yourself "His watch must
be wrong," then you ignore his answer." NTP clients do about this same
thing. This is why we configure our NTP clients to query a wide and
diverse group of servers, so as to detect problems. So,.. Google will not
poison the pool e of NTP servers, Google's incorrect time will not
propagate very far.
I would support an RFC to mark the type a time an chimer is servings.
Not only smeared and UTC, but also TAI, UT, UT0, UT1, UT2, ET, TDT, TDB,
TT, TCG, TCB, GPS, etc...
No, that is the wrong way to do it. Then no one flavor of time has enough
servers to make the system work. A better way is to agree that all NTP
servers use UTC and then distribute the corrections from UTC to the other
flavors and those who need to to the conversions can do so.
RGDS
GARY
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
gem@rellim.com Tel:+1 541 382 8588
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/
mailman/listinfo/time-nuts
and follow the instructions there.
--
Chris Albertson
Redondo Beach, California