Re: [Ntp] [EXT] I-D Action: draft-ietf-ntp-ntpv5-requirements-02.txt

Hi!

I find the part " particularly where the network is unable to offer or does not require PTP [IEEE-1588-2019], " rather confusing: What is the relation to NTP there?
Likewise for " such as customer-premises equipment where reduced accuracy may be tolerable": It may be, or not. I think  this is just speculation.

For " 3.1. Denial of Service and Amplification" I'd start the section with a sentence explaining that the UDP protocol can be misused for packet injection and packet redirection, and when a response is longer than a request it can be used as traffic amplification attack as well. Thus extra security measures have to be applied to prevent such (maybe also add a reference to some RFC dealing with that subject). Just listing "private mode" as culprit seems a bit biased IMHO.

For " The risk that an on-path attacker can delay" it could read "... systematically delay" instead, meaning that a single random delay will likely be detected and handled by the protocol.

For " 3.3. False Time" it's not obvious how " consideration should also be made for hardware-based timestamping " will help. Should packet replays be mentioned there, too?

On " 4. Requirements": Is (remote) "monitoring" definitely no longer a requirement?

On " servers receiving large amounts of unauthorised traffic [ntp-misuse] and the design of NTPv5 must ensure the risk of these can be minimized.": I think NTP cannot minimize the risk of such things (large amount of unauthorized traffic) to happen, but it can (or at least try to) _handle_ the situation properly.

Isn't it preferable to use _positive_ requirements instead of negative ones? For example: Instead of " The protocol's loop avoidance mechanisms SHOULD NOT use identifiers tied to network topology." Why not " The protocol's loop avoidance mechanisms SHOULD be able to use identifiers that change over time. "?

On " The protocol MUST have the capability for servers to notify clients that the service is unavailable": I think it should be mentioned that clients deliberately ignoring such signaling SHOULD (or MUST) be handled accordingly (still to be defined or at least suggested how to).

Think this section is rather confusing: " Clients SHOULD periodically re-establish connections with servers to prevent attempting to maintain connectivity to a dead host and give network operators the ability to move traffic away from hosts in a timely manner": What is the relationship between clients querying servers and network operators moving traffic?

On " MAY be supported and SHOULD NOT be required": it's redundant (both says the same).

I would re-phrase (too much in one sentence IMHO): " To minimise ongoing use of deprecated fields and exposing identifying information of implementations and deployments payload formats SHOULD use the least amount of fields and information where possible, favouring the use of extensions to transmit optional data."

On " Signalling of algorithm use or preference SHOULD NOT be transmitted by servers." I'd add that the algorithm does not have to be specified (enumerated), but the essential properties of the algorithm MUST (or SHOULD) be obvious (like precision, etc.). 

On " to allow for implementations to more easily support both versions of the protocol." "more easily than WHAT?"

Maybe re-phrase " UTC and TAI [TF.460-6]." To " UTC (the current timescale up to NTPv4) and TAI [TF.460-6]. (a possible future timescale starzing at NTPv5)"

On " all transmissions of time data SHALL indicate the timescale in use.": Why not "MUST"?

Why use " greater than 1 calendar day" and not "greater than 24 hours in linear timescale"?

On " Smearing of leap seconds": Should there be some reference when "smearing" occurs first?

On " the protocol MUST support servers transmitting both": It's not clear what "both" actually is.

Also the requirement that the exact smearing algorithm MUST be specified is missing IMHO.

On " ossification of the protocol": I'm unsure everybody understands what that is intended to mean.

On " Servers that support multiple versions of NTP must send a response in the same version": Why not MUST?

On " Many other documents make use of NTP's data formats ([RFC5905] Section 6) for representing time, notably for media and packet timestamp measurements.": It's not clear what those "other" (non-NTP?) documents are, and how they would be affected when the NTP timestamp format would change.

On " Unknown extensions received by a server from a lower stratum server SHALL not be added to response messages sent by the server receiving these extensions.": Isn
t the part " sent by the server receiving these extensions " completely redundant?: A "response" is specific to a request, isn't it?

On " Data authentication and optional data confidentiality MUST be integrated into the protocol": Isn't that missing the most important "integrity"?

Why not rephrase " Cryptographic agility" to "Upgrading cryptographic algorithms"?

On " Intermediate devices such as hardware capable of performing timestamping of packets SHOULD be able to add information to packets in flight without requiring modification or removal of authentication or confidentiality on the packet.": shouldn't it be preferable to integrity-protect these, too? Here it's not clear whther such hardware will replace a timestamp in  a packet or will add some extension field to a packet. In the latter case one could also add a MAC built from the existing MAC and the new timestamp. So the receiver could check both MACs: If the additional MAC fails, it would ignore the hardware timestamp and continue checking the original MAC...

Should some kind of "boot protocol" be part of the specification? Meaning: If the client has no idea what the current time is, how can the "chicken-egg paradoxon" be solved (time required to check authentication, authentic responses needed to trust the time sent). I think in times of "IoT" this might be an important aspect (in the past "servers" had a battery backed up clock, or a trusted operator that sets/verifies/checks the clock on boot).

Kind regards,
Ulrich

-----Original Message-----
From: ntp <ntp-bounces@ietf.org> On Behalf Of internet-drafts@ietf.org
Sent: Saturday, July 29, 2023 5:46 PM
To: i-d-announce@ietf.org
Cc: ntp@ietf.org
Subject: [EXT] [Ntp] I-D Action: draft-ietf-ntp-ntpv5-requirements-02.txt

A New Internet-Draft is available from the on-line Internet-Drafts
directories. This Internet-Draft is a work item of the Network Time Protocols
(NTP) WG of the IETF.

   Title           : NTPv5 use cases and requirements
   Author          : James Gruessing
   Filename        : draft-ietf-ntp-ntpv5-requirements-02.txt
   Pages           : 10
   Date            : 2023-07-29

Abstract:
   This document describes the use cases, requirements, and
   considerations that should be factored in the design of a successor
   protocol to supersede version 4 of the NTP protocol [RFC5905]
   presently referred to as NTP version 5 ("NTPv5").

Note to Readers

   _RFC Editor: please remove this section before publication_

   Source code and issues for this draft can be found at
   https://github.com/fiestajetsam/draft-gruessing-ntp-
   ntpv5-requirements (https://github.com/fiestajetsam/draft-gruessing-
   ntp-ntpv5-requirements).

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-ntp-ntpv5-requirements/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-ntp-ntpv5-requirements-02.html

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-ntp-ntpv5-requirements-02

Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts

_______________________________________________
ntp mailing list
ntp@ietf.org
https://www.ietf.org/mailman/listinfo/ntp