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

[Benjamin Kaduk <[e-mail]>]

On Thu, Mar 05, 2020 at 08:18:25AM +0200, Tal Mizrahi wrote:
> Hi Ben,
> 
> Thanks for the detailed comments.
> Please see the responses below.
> 
> Cheers,
> Tal.
> 
> 
> 
> On Thu, Mar 5, 2020 at 2:12 AM Benjamin Kaduk via Datatracker
> <[e-mail]> wrote:
> >
> > ----------------------------------------------------------------------
> > 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.
> 
> 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

Thanks!

> >
> > 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.
> >
> 
> Agreed, anti-replay mechanisms may be time-dependent but I agree that
> there is no need to mention them in the current document.
> 
> > 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?)
> >
> 
> 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.

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.

> > 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...
> >
> 
> 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 ...

Works for me :)

> 
> > 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?
> >
> 
> 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.

I agree with your assessment.

> > 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.
> >
> 
> Right, that is exactly the intention. We plan to start working on this
> document soon.
> 
> > 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.)
> 
> 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.

Sure, that sounds fine.

Thanks for the updates,

Ben

> >
> > Section 11.2
> >
> > 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.