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

[Marcus Dansarie <[e-mail]>]

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