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

[James <[e-mail]>]

Thanks for the review, responses inline. Anything with a hash and number (e.g. #16) is reference to a Github Issue I've raised in my repository [1], and I would kindly suggest any deeper discussions on specific points happen there to make it easier to track as there are so many points raised.

- J

1: https://github.com/fiestajetsam/draft-gruessing-ntp-ntpv5-requirements/issues

> On 31 Jul 2023, at 09:38, Windl, Ulrich <[e-mail]> wrote:
> 
> 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.

The relation is that there are many deployments of NTP where time synchronisation is required, but PTP is not possible. This is part of introductory text setting the theme for the various places where NTP exists today, and I think acknowledging that NTP is used instead of other protocols is useful. Do you have a suggestion on how this could be more clear or appropriate? (#40)

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

Private mode was just the first obvious thing that came to mind. (#24)
 
> 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.

Agreed. (#27)

> For " 3.3. False Time" it's not obvious how " consideration should also be made for hardware-based timestamping " will help.

This refers to my point further down around issues previously raised with respect to applying cryptography to all timestamps. (#29)

> Should packet replays be mentioned there, too?

I don't know enough to consider this, could you please make some suggestive text of what might be included? (#25)

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

I'm not sure this was ever an explicit requirement - and I'm unable to find it in previous versions of the document. Could you please provide some more clarity on what you mean by this? (#31)

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

I disagree, the design of NTPv5 could minimise (but not 100% mitigate) large amounts of unauthorised traffic. I'm happy to consider any better ways of phrasing this sentence you'd like to suggest. (#28)

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

In the example you gave specifically the use of SHOULD NOT was chosen to prevent certain behaviours rather than enable the specification and thus implementations. On reading it again, I would propose actually stronger language, perhaps "The protocol's loop avoidance mechanisms MUST be able to use identifiers that change over time and are not tied to network topology". Do you agree or do you have a different suggestion? (#17)

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

Agreed, however do you have any suggestions on how the protocol should handle this? (#20)

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

Good point, in some cases the time service provider is also the network provider (e.g. ISPs) but not always. I'll try to rephrase it to be clearer. (#37)

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

What I'm trying to say is that broadcast/symmetric modes "MAY be supported in the protocol specification and SHOULD NOT be required of implementations". (#30)

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

Any suggestions you have would be warmly welcome. (#33)

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

I don't feel overly strong about this - ideally we'd want every algorithm to use the same basic properties, and otherwise use extensions. (#32)

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

The full sentence as of -02 reads:

> Ideally [NTPv5] should be similar or identical to the existing epoch and data model that NTPv4 defines to allow for implementations to more easily support both versions of the protocol.

The implication is that changing the data model, epoch etc across versions would require more business logic and code for implementations. Do you have a suggestion on how this could be better described? (#26)

This is also connected with my comment further down around analysis of dependant specifications. (#35)

> 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)"

I struggle to see the benefit of this inclusion, but also don't have strong opinions against it. (#22)

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

I think the decisions around this were to give room for the discussions earlier over what timescales are supported by the protocol - if there's only ever one timescale transmitted and other representations are derived separately, mandatory inclusion of timescale identification is arguably not necessary. Based on how that subject has changed it'll get updated. (#16)

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

This was phrased as such because it fits in line with how I see people talking and describing NTPv4's LI field, and also how leap seconds are announced. Of what benefit would there be for the reader if we used your suggestion? (#38)

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

Agreed on the first two points, however the third based on prior list discussions remains somewhat unclear - are we expecting the protocol to transmit the smearing algorithm in-band, or use an IANA registry for a list, etc? (#19)

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

This could use a bit more description as well as an informative ref to RFC 9065. (#18)

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

Agreed. (#23)

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

I discussed this at IETF 112 after analysing every reference I could find to NTPv4 and related RFCs. Do you think I should specifically cover all those documents potentially impacted? (#35)

https://youtu.be/X1plw3TXW5g?t=1239
https://datatracker.ietf.org/meeting/112/materials/slides-112-ntp-ntpv5-requirements-00.pdf

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

I think you're right, this is just clumsy editing on my behalf. (#34)

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

In ways data authentication brings the assertion of integrity with it - if the payload has lost integrity due to modification, then it can't be authenticated. Consider a hashing function like SHA can assert integrity, but a HMAC asserts both integrity as well as authentication. Do you think this should be written in a different manner? (#35)

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

Agreed. (#21)

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

This was discussed in the past on list, and there were concerns from people about the overheads of doing so - both in terms of the cryptographic cost impacting precision, as well as complexity. I also don't think this text prevents it, even if we're not prescriptive how. Given this, do you still think this should be changed to be stronger wording? (#29)

https://mailarchive.ietf.org/arch/msg/ntp/TzGA8SMpERhrhQDnMhz0Iv_Pp-w/

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

I'm not sure that is a specification requirement but solely a consideration for implementations and deployments. I think this should stay out of scope of the protocol specification, and instead the WG at a later point in time consider a best practices document that addresses this subject in more depth. Do you agree? (#39)

> Kind regards,
> Ulrich