Re: [Ntp] WGLC - draft-ietf-ntp-ntpv5-requirements

[[e-mail]]

Dear James, dear all,

Martin and I have a number of comments on the NTPv5 Requirements draft.
We appreciate the effort that has gone into developing this draft. 
As always, our intention in providing this feedback is to contribute 
constructively to the ongoing work, and to help ensure that the final 
document is as helpful as possible in the development of NTPv5.


General comments:
- It often seems unclear what this document is regulating (what its MUST, 
SHOULD, etc. applies to).
        * Sometimes, it explicitly states that it applies to "the 
[upcoming NTPv5] specification"; this is at least clear and verifiable and 
seems helpful. We give a soft recommendation to change to this wherever 
possible.
        * Sometimes, it alludes to "the WG should be doing X"; we are 
unsure if this is proper for an RFC.
        * Sometimes, the context implies that the requirements apply to a 
(to each?) protocol implementation; we are unsure about this.
        * Most often, requirements are stated to apply to "the protocol"; 
this seems very abstract, non-verifiable, and overall confusing.
- There are lots of instances of non-capitalized "should" (and possibly 
others?); these need to be checked and either eliminated or capitalized. 
Related, there is at least one SHALL NOT between more MUST NOTs; overall, 
consistency needs to be improved for normative clauses.
- The overwhelming majority of normative terms are "SHOULD"; it seems more 
helpful to have more "MUST" - if we're going to regulate things, we should 
avoid so much use of a term that basically means "we would like you to do 
this, but in the end do whatever you want".
- We think the document should state the scope of its requirements 
(on-wire protovol only vs. including processing algorithms vs. everything, 
including clock disciplining).

2 Use Cases and Existing Deployments of NTP
- We are missing the overall description of NTP being used to sync large 
numbers of computer clocks via open (internet-like) networks; we are 
unsure how helpful the specific example use cases (data centers, NTP 
pool?) are
- The whole implied context of "NTP is what you use when PTP isn't 
available" gives a confusing impression; perhaps add (or replace with) a 
mention of the large numbers (billions of users, probably tens of billions 
of devices) that NTP has; 
- It feels like half the text in this section is about possible issues 
and/or PTP - without any transition to us wanting to solve the issues, or 
why NTP might ever be preferable. This should be improved (Martin and I 
could help with appropriate text on this).

3 Threat Analysis and Modeling
- We almost feel like it would be best just to refer to Tal's document 
RFC7384 rather than reproducing and summarizing it here. If the WG feels 
we need a section like this, Martin and I would be ready to supply a 
reworked text.

4 Requirements
- "It should be able to provide enough information for both basic time 
information and synchronisation." We don't quite understand the 
implication with 'basic time information' - can you explain?

4.1 Resource Management
- We feel this whole section runs counter to the subsequent one (Data 
Minimization); we feel that the requirements to support resource 
management (really, mostly rate limiting, some loop avoidance) are overly 
strong; we also feel like most of these features are prone to misuse/abuse 
and pose security risks. In conclusion, we would like to suggest 
lowering/rethinking the requirement levels.
- Couldn't servers simply drop packets when over capacity, clients simply 
look for another server if theirs doesn't respond, or reduce their request 
rate? The logic would be much simpler, the security clearer.

4.2 Data Minimisation
- The term "optional data" needs to be clearly defined (and in my opinion 
discussed again).
- While we agree with the point made about data minimization, we feel that 
it runs counter to many other features/aspects (timescale, resource 
management, leap seconds, security).

4.3 Algorithms
- The headline is confusing; the context with algorithm agility while not 
discussing crypto algorithms seems prone to misunderstandings. Perhaps 
change to "Time Processing Algorithms"?
- The formulation "SHOULD be obvious" seems confusing.
- The second paragraph seems to hint at specification-side modularity 
(on-wire protovol vs. processing algorithms vs. clock disciplining); while 
I like the idea, I believe it is controversial; I'm also unsure I'm even 
understanding the text correctly.

4.4 Timescales
- It seems we should make explicit that "a linear, monotonic timescale" 
cannot be UTC itself.

4.5 Leap Seconds
- The 24 hour explanation seems clunky. How about "ideally 24 hours in 
advance, otherwise as soon as possible"?
- We don't agree with the statement that leap smearing "SHOULD be 
supported [and MUST be dealt with]" in the specification and the 
implementations and "the protocol". 
This (specifally the hard requirement for clients to completely deal with 
all aspects of server side smearing) seems to require a great amount of 
work and effort by specification editors and all future implementors for 
supporting a hack that will be opbsolete in a few years. At the very 
least, this seems like a controversial point that needs more discussion... 
We would probably suggest relegating this to a separate document (and then 
more along the lines of 'if you're going to smear, do it like X').

4.6 Backwards Compatibility with NTS and NTPv4
- We feel that it might be problematic (e.g. security-wise) if an instance 
is running as an NTPv5 server but gets its time via NTPv4/v3.
- Structure: there shouldn't be a 4.6.1 if there isn't also a 4.6.2. (We 
are also unsure if the 4.6.1 'Dependent Specifications' text is needed at 
all.)

4.7 Extensibility
- "Unknown extensions received from a lower stratum server SHALL NOT be 
re-transmitted towards higher stratum servers." ... Should anything ever 
be? Also, isn't this part of "ignoring unknown extensions"?

4.8 Security
- If we shy away from naming a security option (e.g. NTS) as required for 
everyone, we leave the door open for a situation where two implementations 
can only do unsecured communication (because they support different, 
mutually exclusive security options).
- We don't have a strong opinion on what's best, but if we require 
security to be supported, we must specify a minimal supported set. 
- "Downgrading attacks that could lead to an adversary disabling or 
removing encryption or authentication MUST NOT be possible in the design 
of the protocol." is a difficult requirement. Under the problem outlined 
above, it might be simply unfulfillable. Also, it leaves unclear what is 
forbidden (only downgrading to zero security, or any downgrading at all)

5 Non-requirements
- This seems prone to misunderstanding: these are points that we as a WG 
have discussed and consented on not pursuing further; but it might sound 
like optional requirements?

5.1 Server Malfeasance Detection
- I find it problematic to cite a draft (!) and claim that it "already 
provides this capability"; Roughtime is IMO not mature enough to do this

7 Security Considerations
- We are not sure that this is still correct; we do think this document 
opens new considerations (e.g. by requiring authentication and integrity 
to be supported)


To be clear: we want an adapted document to advance and to be submitted to 
the IESG (not to hold up the process or anything).
Thanks for your understanding, and we look forward to your response, 
James; in any case where you might need help with concrete text, we are 
ready to work on it with you.


Besten Gruß / Kind regards,
Kristof Teichel (and Martin Langer)

__________________________________________

Dr.-Ing. Kurt Kristof Teichel
Physikalisch-Technische Bundesanstalt (PTB) 
Arbeitsgruppe 4.42 "Zeitübertragung"
Bundesallee 100
38116 Braunschweig (Germany)
Tel.:        [phone]
E-Mail:   [e-mail]
__________________________________________



Von:    "Karen ODonoghue" <[e-mail]>
An:     [e-mail]
Datum:  30.11.2023 22:29
Betreff:        [Ntp] WGLC - draft-ietf-ntp-ntpv5-requirements
Gesendet von:   "ntp" <[e-mail]>



NTP WG members,

This email initiates the NTP working group last call for the NTPv5 
requirements document. 
https://datatracker.ietf.org/doc/draft-ietf-ntp-ntpv5-requirements/03/

Please review this document and respond with an email on the following two 
questions: 
1) Please review the document closely and provide comments. It is only 
eleven pages in total so it is a quick read. 
2) Please state whether or not you think this document is ready to be 
submitted to the IESG for publication (pending resolution of any comments 
you have made). Remember that this document will be used to 
drive decisions in the NTPv5 work that is already underway. 

Given the brevity of the document, this WGLC will conclude on Wednesday 13 
November. 

Regards,
Karen and Dieter_______________________________________________
ntp mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ntp