Subject: [Ntp] Benjamin Kaduk's No Objection on draft-ietf-ntp-packet-timestamps-08: (with COMMENT)

From: Benjamin Kaduk via Datatracker <[email-masked]>
Date: Wed, 04 Mar 2020 16:12:35 -0800

Benjamin Kaduk has entered the following ballot position for
draft-ietf-ntp-packet-timestamps-08: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ntp-packet-timestamps/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Could this go for BCP instead of Informational?  (That would avoid a
need in the future to get it added to the downref registry.)

When we discuss the NTP timestamp formats, we say that "during and
possibly after the occurrence of a leap second, the value of the
timestamp may temporarily be ambiguous, as further discussed in Section
5."  But in Section 5 we discuss the possibility of behavior where
"[t]he clock is slowed down during the leap second and adjacent time
intervals until the new time value catches up."  These statements seem
incompatible unless "adjacent time intervals" occur only after the leap
second, which is not my understanding of how leap-second smearing is
performed in practice.

Section 1.1

   Timestamps are widely used in network protocols for various purposes:
   timestamps are used for logging or reporting the time of an event,
   delay measurement and clock synchronization protocols both make use
   of timestamped messages, and in security protocols a timestamp is
   often used as a value that is unlikely to repeat (nonce).

Some security protocols also use timestamps directly for security
functionality, e.g., using a replay cache for messages within a certain
time window of the past and discarding older ones.  That usage is mostly
unrelated to what is discussed in this document, and I don't really see
a need to mention it in the document, but will mention it here in case
opinions differ.

Section 3

When multiple fields are used (with different units), what needs to be
said about how the two fields are combined and/or any restrctions on the
allowed range of the fields?  (E.g., for the "joke" timestamp format
that has a seconds plus centiseconds representation, are values greater
than or equal to 100 centiseconds forbidden?  Do we envision
applications other than "convert values to a common unit and add them"
for multiple fields, such as explicit fields to convey timestamp
accuracy and/or precision?)

Section 4

   This document defines a set of recommended timestamp formats.
   Defining a relatively small set of recommended formats enables
   significant reuse; for example, a network protocol may reuse the NTP
   or PTP timestamp format, allowing a straightforward integration with
   an NTP or a PTP-based timer.  Moreover, since accurate timestamping
   mechanisms are often implemented in hardware, a new network protocol
   that reuses an existing timestamp format can be quickly deployed
   using existing hardware timestamping capabilities.

This text feels very familiar by this point in the document...

Section 4.2.1

Just to check: we assume by definition that no leap seconds occurred
prior to the creation of UTC when we say that 2272060800 is the number
of seconds between 1 Jan 1900 and 1 Jan 1972, right?

Section 7

I assume the WG considered whether this content could be spun off into a
separate document, e.g., one that defines specific timestamp control
fields, but decided that it is important enough to publish now.

Section 9

Is it in scope to discuss considerations relating to applications that
have an inaccurate sense of the current time, or network packets that
contain timestamps intended to be synchronized to a reference but in
fact are not?  (I see a decent argument that it is not in scope, but
want to check.)

Section 11.2

I assume the self-reference will get removed by the RFC Editor.

---

From: Tal Mizrahi <[email-masked]>
Date: Thu, 5 Mar 2020 08:18:25 +0200

Hi Ben,

Thanks for the detailed comments.
Please see the responses below.

Cheers,
Tal.

Agreed. Proposed text update:
OLD:
during and possibly after the occurrence of a leap second
NEW:
during and possibly before and/or after the occurrence of a leap second

> a need to mention it in the document, but will mention it here in case

Agreed, anti-replay mechanisms may be time-dependent but I agree that
there is no need to mention them in the current document.

> accuracy and/or precision?)

A fair point. In some cases a field may be limited to a range of
values, which may affect timestamp arithmetics.
Proposed text update:
OLD:
The units used to represent the timestamp.  If the timestamp is
comprised of more than one field, the units of each field are
specified.
NEW:
The units used to represent the timestamp.  If the timestamp is
comprised of more than one field, the units of each field are
specified. If a field is limited to a specific range of values, this
section specifies the permitted range of values.

> This text feels very familiar by this point in the document...

Agreed. Proposed text:
OLD:
   This document defines a set of recommended timestamp formats.
   Defining a relatively small set of recommended formats enables
   significant reuse; for example, a network protocol may reuse the NTP
   or PTP timestamp format, allowing a straightforward integration with
   an NTP or a PTP-based timer.  Moreover, since accurate timestamping
   mechanisms are often implemented in hardware, a new network protocol
   that reuses an existing timestamp format can be quickly deployed
   using existing hardware timestamping capabilities.  This document
   recommends to use one of the timestamp formats specified below.
  Clearly, different network protocols ...
NEW:
   This document defines a set of recommended timestamp formats.
  Clearly, different network protocols ...

> of seconds between 1 Jan 1900 and 1 Jan 1972, right?

Right. Not sure we need to explicitly say this, since the number of
leap seconds at any given time is assumed to be "common knowledge".
Please let me know if you think otherwise.

> fields, but decided that it is important enough to publish now.

Right, that is exactly the intention. We plan to start working on this
document soon.

> fact are not?  (I see a decent argument that it is not in scope, but

I believe that the scenarios you suggest are somewhat similar (or
related) to "any attack that compromises the synchronization
mechanism" (which is already mentioned in the draft), so I would be
fine with leaving this section as-is, unless you feel otherwise.

> I assume the self-reference will get removed by the RFC Editor.

The self reference is intentional (used in the examples of section 6).
It will be updated by the RFC Editor to the RFC number once it will be
available.

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 5 Mar 2020 13:35:37 -0800

> during and possibly before and/or after the occurrence of a leap second

Thanks!

> section specifies the permitted range of values.

Okay.  I guess we can wait to see if anyone wants to do anything other than
"convert to a common unit and add" ... it should be unlikely, given that we
recommend one of these three formats be used in most cases.

>   Clearly, different network protocols ...

Works for me :)

> Please let me know if you think otherwise.

I agree with your assessment.

> fine with leaving this section as-is, unless you feel otherwise.

Sure, that sounds fine.

Thanks for the updates,

Ben