Subject: [Ntp] Suggested improvements to the Roughtime draft (draft-ietf-ntp-roughtime-00)

From: Marcus Dansarie <[email-masked]>
Date: Sat, 15 Feb 2020 00:12:45 +0100

All,

I finally found some time to go through the recent Roughtime draft. A
number of issues, ideas, and suggestions follow below. I can submit any
accepted suggestions as pull requests on Github.
(https://github.com/aanchal4/draft-roughtime)

For the impatient, I make the following suggestions in this email:
* Defining a Roughtime packet format with a header containing a magic
number and message length.
* More detailed specification of server and client behavior in the TCP
transport mode.
* Removal of the padding requirement in TCP transport mode.
* Explicitly allowing multiple requests in TCP transport mode.
* Adding the DUT1 and DTAI tags for transfer of offsets between UTC and
UT1, and UTC and TAI.
* Adding the LEAP tag to transfer information on future and past leap
second events.
* Adding a VER tag to indicate supported versions.
* Fixing a couple of minor nits.
* Revisited discussion on the timestamp format.

First of all, the words "packet" and "message" are used interchangeably
throughout the draft to refer to Roughtime messages. This might cause
confusion as "packet" is also used in different meanings in the same
document. I suggest that we use the term "packet" only for the contents
of an entire request or response. We should probably also consider
renaming Roughtime "messages" to "records" which carries less risk of
confusion. In my opinion, "record" is also a more fitting name.

The following occurrences of "packet" should be changed to "message":

The first sentence of Section 5.1.3 should read: "Tags are used to
identify values in Roughtime messages."

Section 5.2, near the end of the second paragraph: "[...] with the
exception of the last value which ends at the end of the message."

Section 6.2, in the paragraph that begins with "The RADI tag value", the
last word should be removed so that the sentence ends with "at the time
they compose the response."

(I realize that I may be the culprit behind these uses of "packet",
since I contributed a lot of text to an earlier draft.)

When I started trying to implement the Roughtime TCP mode, I found the
current draft to be vague. The uint32 length prefix is also a bit of a
kludge and I believe the TCP and UDP formats should be identical as far
as possible. Therefore, I suggest changing the text in Section 6 to:

"As described in Section 3, clients initiate time synchronization by
sending requests containing a nonce to servers who send signed time
responses in return. Roughtime packets can be sent between clients and
servers either as UDP datagrams or via TCP streams. Servers SHOULD
support the UDP transport mode, while TCP transport is OPTIONAL.

A Roughtime packet MUST be formatted according to Figure 2 and as
described here. The first field is a uint64 with the value
0x4d49544847554f52 ("ROUGHTIM" in ASCII). The second field is a uint32
and contains the length of the third field. The third and last field
contains a Roughtime message as specified in Section 5 and Section 6.1
or 6.2.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  0x4d49544847554f52 (uint32)                  |
   |                        ("ROUGHTIM")                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Message length (uint32)                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   .                                                               .
   .                      Roughtime message                        .
   .                                                               .
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                    Figure 2: Roughtime Packet Format

Roughtime request and response packets MUST be transmitted in a single
datagram when the UDP transport mode is used. Setting the packet's don't
fragment bit [RFC791] is OPTIONAL in IPv4 networks.

Multiple requests and responses can be exchanged over an established TCP
connection. Clients MAY send multiple requests at once and servers MAY
send responses out of order. The connection SHOULD be closed by the
client when it has no more requests to send and has received all
expected responses. Either side SHOULD close the connection in response
to synchronization, format, implementation-defined timeouts, or other
errors."

Since there is no risk of amplification attacks in the TCP transport
mode, I suggest changing the text in Section 6.1 to

"A request is a Roughtime message with the tag NONC. The value of the
NONC tag is a 64 byte nonce. It SHOULD be generated by hashing a
previous Roughtime response message together with a blind as described
in Section 8.  If no previous responses are available to the client, the
nonce SHOULD be generated at random.

In the UDP transport mode, the size of a request message SHOULD be at
least 1024 bytes, responding to shorter requests is OPTIONAL for
servers, and servers MUST NOT send responses larger than the requests
they are replying to. To attain the minimum request size, clients SHOULD
add the PAD tag to the message. Its value SHOULD be all zeros.

The PAD tag SHOULD NOT be used in the TCP transport mode."

There may be cases where a Roughtime client wishes to send multiple
requests at the same time. Examples of this include proxies that perform
TCP to UDP connection bridging and clients that need to timestamp a
large number of hash values, e.g. for audit purposes. There is currently
no easy way of pairing received responses with their corresponding
requests. One way to facilitate this is for servers to include the NONC
tag in their responses.

Section 6.2 should also be updated to use RFC 2119 requirements language.

I suggest changing the beginning of the first paragraph to:

"A response MUST contain the tags SREP, SIG, CERT, INDX, and PATH as
described in this section. It SHOULD contain a NONC tag identical to the
one in the client's request."

ITU-R TF.460-6 recommends "that standard-frequency and time-signal
emissions, and other time-signal emissions intended for scientific
applications (with the possible exception of those dedicated to special
systems) should contain information on UT1 - UTC and TAI - UTC". To
satisfy this, I suggest adding support for the tags DUT1 and DTAI as
follows:

The first paragraph of Section 6.2 (in addition to the changes suggested
above) is appended with "Furthermore, the server MAY include the tags
DUT1 and DTAI in its response."

A description of those tags is then added to the end of Section 6.2:

"The DUT1 tag value is an int32 indicating the predicted difference
between UT1 and UTC (UT1 - UTC) in milliseconds as given by the
International Earth Rotation and Reference Systems Service (IERS).

The DTAI tag value is an int32 indicating the current difference between
International Atomic Time (TAI) and UTC (TAI - UTC) in milliseconds as
published in the International Bureau of Weights and Measures' (BIPM)
Circular T."

A new section defining the int32 data type should then be added after 5.1.2:

"A int32 is a 32 bit signed integer in signed magnitude representation
with the sign bit in the most significant bit. It is serialized with the
least significant byte first. The negative zero value (0x80000000) MUST
NOT be used."

The list of Roughtime tags in Section 13.2 and the terms and
abbreviations in Appendix A should also be updated accordingly.

Roughtime currently has no method for indicating future (or past) leap
seconds. It would be good if the protocol could warn about an upcoming
leap second event. I have also seen requests on this list for a method
to transfer leap second history information. For those reasons, I
propose that the LEAP tag is be added to the draft. It would be added
(along with DUT1 and DTAI) to the list of tags in Section 6.2 that a
server MAY include in its response. The following description could then
be added to the same section:

"The LEAP tag contains zero or more int32 values. Each value represents
the MJD of a past or future leap second event. Positive values represent
the addition of a second at the indicated date and negative values
represent the removal of a second at the indicated (negative) date. The
first item in the list MUST be the last (past or future) leap second
event that the server knows about. The leap second events MUST be sorted
in reverse chronological order. A leap tag with zero int32 values
indicates that the server does not hold any updated leap second
information."

The LEAP tag uses the new int32 type defined above. The list of
Roughtime tags in Section 13.2 should be updated to include the new LEAP
tag.

The previous drafts have made changes that make them incompatible with
each other. There is currently no way for either client or server to
indicate which version of the Roughtime protocol they are using. To
rectify this, I propose adding a VER tag to the protocol by making the
following additions to Sections 6, 6.1, and 6.2.

Section 6:

"All requests and responses MUST contain the VER tag. It contains a list
of one or more uint32 version numbers. The version of Roughtime
specified by this memo has version number 1.

For testing drafts of this memo, a version number of 0x80000000 plus the
draft number is used."

In Section 6.1, the following should be added as the penultimate paragraph:

"The VER tag MUST include at least one Roughtime version number
supported by the client. The client MUST ensure that the version numbers
and tags included in the request are not incompatible with each other or
the package contents."

In Section 6.2 the following changes should be made:

The VER tag is added to the list of required tags in the first sentence.

The following paragraph is added where suitable:

"The VER tag MUST include exactly one version number which indicates the
Roughtime version used for the response packet. How the server should
handle situations where it does not support any of the versions in the
request is currently unspecified."

A request to IANA for a Roughtime Version Number Registry should be
added to Section 13 and include a reserved space and a space for private
use. The list of Roughtime tags in Section 13.2 should also be updated
to include the new VER tag.

I have also found a couple of minor nits in the current draft and have
already submitted a pull request on Github to fix them. It was recently
accepted there by Watson Ladd.

* The title of Section 7 should read "Integration into NTP".

* The IANA request in Section 13.1 should be for both TCP and UDP as
transport protocols.

* The references section should contain a reference to RFC 793.

Another thing that needs to be addressed at some point is specifying the
JSON formats for exchanging information about server addresses and
suspected malfeasance.

Finally, I have revisited Peter Löthbergs suggestion regarding the
timestamp format. The current timestamp format specified in Section
5.1.4 doesn't use the full available resolution. His suggestion was that
we use the full 40 bits of resolution to represent fractions (2^-40) of
a day. The value is multiplied by 86400 * 2^-40 to get the number of
seconds since midnight. Using information from the LEAP tag suggested
above, clients will use 86401 * 2^-40 or 86399 * 2^-40 on leap second
days. An added advantage of this is that clients that wish to leap smear
can do so simply by always using the standard multiplier. I'd like to
hear your opinions on this.

Kind regards,
Marcus Dansarie

---

From: Watson Ladd <[email-masked]>
Date: Fri, 14 Feb 2020 17:12:00 -0800

> (https://github.com/aanchal4/draft-roughtime)

Thank you very much for doing this! I consider most of your suggestions
excellent ideas, but perhaps others have additional input they wish to give.

Some fields especially DUT1 and DUTC might not be available over NTP, PTP,
or NEMA. That makes it a bit tricky to get out of a GNSS unit, even if it
available from the satellite. Since these are optional fields I'm not that
concerned, but it would be a shame if no one could use it. I would make
NONC echoing a MUST: it's trivial for servers to do, has no downsides I can
see.

We may have to refine the notion of malfeasance to cover additional data
such as leap seconds, but that does seem a bit tricky as not all leap
second dissemination mechanisms function the same way or have the same view
ahead.
I have been working on providing formulas for MJD conversion, so the
textual changes you have suggested would be mostly complementary.

> hear your opinions on this.

I'm not sure I entirely understand the proposal: it seems that the idea is
to use the 5 fraction of day bytes to represent 2^-40 of the current day,
where the length of the current day in seconds is determined by the LEAP
field applicable to the day in question. My first concern is with the
intervals: if specified as additions to this timescale they change length
with respect to the SI second depending on what day it is. If we don't then
interval arithmetic becomes a bit tricky, as part of the interval is
converted with one number, and part with another number. Comparing packets
where there is disagreement over whether or not a leapsecond happened now
seems a bit tricky.

At a more practical level there is a problem with leap second indications
arriving later in the day. Not all leap dissemination mechanisms work ahead
of time: some only work the same day such as NTP. A server that learns that
there that there is a positive leapsecond in the middle of the day will
adjust the number of seconds it thinks are in the day, so the timestamps
here cannot be directly compared without knowing the leap state the server
is applying, and they have to be converted to some other scale to compare
numerically. That makes me hesitate to endorse this idea but perhaps when I
see formulas I'll be happier with it.

Sincerely,
Watson Ladd

---

From: Marcus Dansarie <[email-masked]>
Date: Sat, 15 Feb 2020 03:56:01 +0100

> excellent ideas, but perhaps others have additional input they wish to give.

Thank you!

> Some fields especially DUT1 and DUTC might not be available over NTP,
> PTP, or NEMA. That makes it a bit tricky to get out of a GNSS unit, even
> if it available from the satellite. Since these are optional fields I'm
> not that concerned, but it would be a shame if no one could use it. I
> would make NONC echoing a MUST: it's trivial for servers to do, has no
> downsides I can see.

I view the fact that DUTC and DUT1 are tricky to get hold of as a major
argument for including them. I only expect a few servers to actually end
up including them in responses, but even that would greatly increase the
availability of the information. For DUTC, an updated leap second file
should be sufficient, but DUT1 may be hard to get right without manual
handling.

> second dissemination mechanisms function the same way or have the same
> view ahead.

Agree. The absence of a future leap second from the list should probably
not be considered malfeasance. The question is what the absence of the
most recent past one should be considered, especially if the server
otherwise provides acceptable time. (And what if a server has a RADI of,
say, 10 seconds and misses multiple leap seconds?)

> I'm not sure I entirely understand the proposal: it seems that the idea
> is to use the 5 fraction of day bytes to represent 2^-40 of the current
> day, where the length of the current day in seconds is determined by the
> LEAP field applicable to the day in question. My first concern is with
> the intervals: if specified as additions to this timescale they change
> length with respect to the SI second depending on what day it is. If we
> don't then interval arithmetic becomes a bit tricky, as part of the
> interval is converted with one number, and part with another number.
> Comparing packets where there is disagreement over whether or not a
> leapsecond happened now seems a bit tricky.

Peter's original suggestion, which was forwarded to the list by me,
should be somewhere in the archive. But yes, that is the general idea. I
am not entirely convinced myself, and would be perfectly happy to
continue with the current timestamp format. My main concern with Peter's
suggestion is that it adds lots of complication to gain a small amount
of precision (in a protocol called ROUGHtime).

> At a more practical level there is a problem with leap second
> indications arriving later in the day. Not all leap dissemination
> mechanisms work ahead of time: some only work the same day such as NTP.
> A server that learns that there that there is a positive leapsecond in
> the middle of the day will adjust the number of seconds it thinks are in
> the day, so the timestamps here cannot be directly compared without
> knowing the leap state the server is applying, and they have to be
> converted to some other scale to compare numerically. That makes me
> hesitate to endorse this idea but perhaps when I see formulas I'll be
> happier with it.

Yes, I agree that what you describe is a real risk and a very valid
argument against using a fraction-of-day timestamp format.

Kind regards,
Marcus

---

From: Tony Finch <[email-masked]>
Date: Mon, 17 Feb 2020 20:23:09 +0000

> * Adding the LEAP tag to transfer information on future and past leap

The TF.460 requirements are largely about radio signals for celestial
navigation, so it's questionable that those aspects are relevant for
distributing civil time over computer networks. TF.460 also only requires
DUT1 to 100ms precision, so where does your 1ms precision requirement come
from? GPS provides DUT1 to sub-microsecond precision, for example.
(IS-GPS-200 table 30-VII, https://www.gps.gov/technical/icwg/)

There is no need to distribute both DTAI and a leap second list. (DTAI can
be derived from the list.) I think a new time protocol should just
transmit the entire list, because it can easily be compresed to less than
20 bytes - the current list is 16 bytes and we're unlikely to pass 20
bytes within the next 10 years.

I distribute cryptographically signed lists of leap seconds in various
formats over the DNS, e.g.

leapsecond.dotat.at.	TYPE65432 \# 16 00111111121134312112229D565285FA
leapsecond.dotat.at.	RRSIG	TYPE65432 13 3 3600 (
				20200227094640 20200215162742 53798 dotat.at.
				EWKpYcQOqnbnkMmf9+jQAHpBmqrHGpVOht9O8JzMPHUZ
				E95u/cuNWEMlIe8uTSkSfQRX3ZT/OZJIdIlkE9LkXA== )

Sketchy description of the format at
https://dotat.at/cgi/git/leapseconds.git/blob/HEAD:/syntax.md

(Leap seconds as currently specified will stop working between 1000 and
2000 years in the future, when DTAI is about 2h, and the leap second list
is about 4KB. https://www.ucolick.org/~sla/leapsecs/dutc.html)

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Channel Islands: West to southwest 5 to 7, occasionally gale 8 with gusts to
50kt early evening and again from late Tuesday afternoon. Rough to very rough,
occasionally moderate to rather rough in the southeast with a low to moderate
swell. Isolated showers becoming more frequent in the afternoon with a risk of
hail and thunder. Good, occasionally moderate or poor.

---

From: Watson Ladd <[email-masked]>
Date: Wed, 19 Feb 2020 07:54:13 -0800

> (IS-GPS-200 table 30-VII, https://www.gps.gov/technical/icwg/)

If you are designing your own receiver electronics, then this is feasible.
The problem is that standards like NMEA don't provide a field for the
information, so it's a challenge to integrate with GPS clock drivers on
commodity OS's. Our current setup at Cloudflare is fed by NTP, so that's
even less likely to get these fields.

> bytes within the next 10 years.

What's the point of distributing far past or far future leap seconds via
Roughtime? It can go into the tz database.

> _______________________________________________
> ntp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ntp

--
"Man is born free, but everywhere he is in chains".
--Rousseau.

---

From: Thomas Peterson <[email-masked]>
Date: Wed, 19 Feb 2020 18:23:23 +0000

Sending all leap seconds doesn't require the server to have any logic 
apart from ensuring it always sends up to date information as opposed to 
calculating the delta to send. Furthermore the overheads as Tony 
describes are so small for today's protocols that the size should not be 
a concern.

Regards

---

From: Marcus Dansarie <[email-masked]>
Date: Thu, 20 Feb 2020 16:17:49 +0100

> (IS-GPS-200 table 30-VII, https://www.gps.gov/technical/icwg/)

When I wrote the suggestion, I was envisioning distributing the DUT1 as
announced by IERS, which is done with a precision of 0.1 s. The
millisecond precision in my suggested format was selected mostly
arbitrarily. Since there are sources that distribute DUT1 with much
higher precision, I would not be opposed to changing the resolution to a
more suitable one. This would also add the need for a way to indicate
the DUT1 resolution.

> bytes within the next 10 years.

I view DTAI as (somewhat) separate from the leap seconds list, in that
it works even if the server does not have any information about past or
future leap seconds. For example, the GPS signals provide the current
UTC-GPS offset.

Using the LEAP tag, the server can send all past leap seconds if it
wishes. Since all Roughtime data comes in four byte increments, I would
strongly prefer any format in the LEAP field to be compatible with this.
I am, however, open to better data representations that the one I suggested.

Kind regards,
Marcus