[Ntp] Roman Danyliw's Discuss on draft-ietf-ntp-interleaved-modes-07: (with DISCUSS and COMMENT)

[Roman Danyliw via Datatracker <[e-mail]>]

Roman Danyliw has entered the following ballot position for
draft-ietf-ntp-interleaved-modes-07: Discuss

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/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


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



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Other ADs have commented on the benefit of providing additional clarifying
language where guidance is described using “SHOULD”.  On a subset of those
instances, it appears that these phrases could potentially cause
interoperability issues or have security implications depending on their
interpretation.

** Per the possibility of interoperability or under-specification of the
algorithm:

-- Section 3
   The peer SHOULD process the requests in the same way as a
   server which supports the interleaved client/server mode.   It MUST
   NOT respond in the interleaved mode if the request was not in the
   interleaved mode.

Is there any interoperability impact if the peer chooses NOT to process the
request the same way as the server?  When would one choose this behavior?

-- Section 3
   A peer A SHOULD send a peer B a packet in the interleaved mode only
   when all of the following conditions are met:

When would a peer ignore the conditions described after this clause? If
implementations chose different criteria (since this list is not mandatory)
would this cause interoperability issues?

-- Section 3
   The peers SHOULD compute the offset and delay using one of the two
   sets of timestamps specified in the client/server section.

How would this computation be done without one of the two sets of timestamps
described in this section?

-- Section 6
   A client which supports the interleaved mode SHOULD check if the
   origin timestamp is not zero to detect packets in the interleaved
   mode.  The client SHOULD also compare the origin timestamp with the
   transmit timestamp from the previous packet to detect lost packets.
   If the difference is larger than a specified maximum (e.g. 1 second),
   the packet SHOULD NOT be used for synchronization in the interleaved
   mode.

How would interleaved mode be detected without the “not zero” approach above? 
Perhaps by configuration?

-- Section 6
   The client SHOULD compute the offset using the origin timestamp from
   the received packet and the local receive timestamp of the previous
   packet.

What is the alternative to computing the offset if not with the algorithm
described above?

** Per the Security implications:

-- In Section 6.

Clients using the interleaved mode SHOULD randomize all bits of both
receive and transmit timestamps

When is it acceptable use predictable bits in the timestamps?


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

Thank you to Reese Enghardt for the GENART review.

** Is there confidence that this document still has IETF consensus given that
it sat in IETF review since 2021?

** Section 4.
   The timestamp cannot be included in the packet itself unless the
   driver or hardware supports NTP and can modify the packet before or
   during the actual transmission.

Is this a common setup for “software NTP implementation running on a   
general-purpose operating system” to have NIC “driver or hardware support for
NTP?

** Why does the WG consider draft-ietf-ntp-port-randomization a suitable source
of normative guidance given that it was an adopted by the WG, but never
finished (and it expired 5 years ago)?