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

[James <[e-mail]>]

I have attempted to map your numbering convention to all the issues you have raised. However, it is unclear as to which points map to what in some places - clarification and correction would be appreciated. At many points in your feedback there appears a lack of clarity either of what the issue is exactly, what the impact is, or possible routes to address.

- J

> On 12 Dec 2023, at 14:27, [e-mail] wrote:
> 
> 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).

(#1) My comment in response to this is in the next point raised.

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

(#1) Thank you for providing a recommendation, however what is specifically ambiguous of it being absent? The very first section of the document - the abstract - makes it clear we're talking about NTPv5 throughout. Are there any specific points where there is relative language is referring to a different protocol or could be (mis)interpreted as such?

>         * Sometimes, it alludes to "the WG should be doing X"; we are unsure if this is proper for an RFC.

(#1) The only immediate statement I note is in Section 4.3 (Algorithms) where it is suggested without normative text the WG create a separate document regarding algorithms as it has been a long-standing goal of NTPv5 to keep them separate from protocol specification to endorse agility. For all those allusions, which ones exactly are of concern to you, and what do you propose exactly?

>         * Sometimes, the context implies that the requirements apply to a (to each?) protocol implementation; we are unsure about this.

(#1) Could you provide specific examples of what you mean please.

>         * Most often, requirements are stated to apply to "the protocol"; this seems very abstract, non-verifiable, and overall confusing.

(#1) This appears to be a duplicate point to one already made regarding the recommendation of using language of "the [upcoming NTPv5] specification". Is that correct, or is there something I have missed?

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

(#1) The use of normative vs non-normative wording is not erratic and intentional, recognising the strength and impact normative language has on defining the limits and capabilities of the NTPv5 protocol. This document is not just about setting explicit MUST and MUST NOTs; it's also a reflection of discussion and viewpoint. If there is any normative or non-normative language you disagree with please state which ones exactly, what you propose they change to and why - I do not agree to any suggestion that all should either be made normative or removed.

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

(#1) The choice of using SHOULD has been in recognition that MUST can be confrontational and there may be valid circumstances where exceptions could be made, foresight is generally more limited than hindsight. As I've previously stated - if there are specific normative words you feel require changing please state which specifically. Please keep in mind just because this document says it "MUST" does not prevent future specification deviating.

> - We think the document should state the scope of its requirements (on-wire protovol only vs. including processing algorithms vs. everything, including clock disciplining).

(#1) The document does state that it covers what should be part of the protocol, and that algorithms should be done separately in section 4.3. If you feel this is insufficient - please could you clarify further on what is unclear, or suggest what it should state.

> 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

(#2a) Could you please clarify what you mean here as I do not understand - reference to the NTP Pool is just an example of a very large deployment of the protocol.

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

(#2a) Could you give an example of where you interpret this implied context, as I don't interpret my own text in that manner. PTP is mentioned as one example, and its name is not used in slander.

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

(#2a) I'm not sure I understand - the document is not intending to be a critique of PTP or any issues it may have. What do you suggest the text change to?

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

(#2b) This section was written before I was made aware of RFC7384, and subsequently it was edited in an attempt to be complimentary to it and cover explicitly what subjects and risks I believed are of relevance, and I don't think any overlap is problematic. Are there specific concerns to this section that you feel must be addressed, if so what specifically?

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

"Basic time information" here is, for example a representation of UTC/TAI along with leap second information as opposed to extended timezone information, or historic leap seconds which are explicitly mentioned as non-requirements in a later section. This is an opening statement to set theme, and is not intended to be explicit in definition - the further subsections expand on what types of time information are to be part of the specification. Besides your question is there any specific further action here such as additional text, and if so could you propose something?

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

(#3a) (#3b?) I strongly disagree. Resource management is important for NTPv5 to address, particularly for large scale, public deployments - historically it's been a big enough problem it has its own Wikipedia page. There's been attempts to try and find a balance between resource management and data minimisation - one key example is the requirement to not use identifiers tied back to IP addresses or certificates, limiting certain on-path observers. Data minimisation is not just "remove all unnecessary data" but also having focused value for what data is required. What do you propose exactly?

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

I disagree with this suggestion, as designed or implemented poorly would run the risk of DDoS, greatly impact the time for clients to synchronise amongst other potential issues. Dropped packets don't just happen when a server is congested, it can happen at any hop in the network when the link is congested. Explicit signalling is one of the ways attempting to prevent some of the challenges that have occurred in the past with unwanted traffic. How does your suggestion handle all possible scenarios of packets being dropped?

> 4.2 Data Minimisation 
> - The term "optional data" needs to be clearly defined (and in my opinion discussed again).

I'm not sure what needs to be specified here, as what is optional and required comes down largely to protocol design and what client and server need to fulfil higher level functional requirements. What exactly do you propose be specified here? Could you please suggest something?

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

This is unclear to me what the issue is here - could you please be specific of what you think is contradictory?

> 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 opening sentence to the section I think makes clear that it's not specifying anything of cryptography. That being said this is a trivial change that could be included later if need be.

> - The formulation "SHOULD be obvious" seems confusing.

Could you please make a suggestion or advise on what to put instead.

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

Can you please describe in more detail what specifically you feel is unclear? The WG has discussed at length the need for being able to produce both UTC and TAI representations from the protocol; I was under the impression we had moved on from that discussion already.

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

(#2c) I don't disagree with this, but I don't think this is a deal breaker and can address later if need be.

> 4.5 Leap Seconds 
> - The 24 hour explanation seems clunky. How about "ideally 24 hours in advance, otherwise as soon as possible"?

(#2d) There should be normative text here, one of the earlier requirements was also around transmitting the LI much earlier than 24 hours. Could you please propose something with normative language, or if you disagree state why?

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

(#2d) Leap second smearing and the resulting text was the result of an extensive series of discussions spanning years resulting in a working group consensus call being made. I disagree that, after we have achieved that consensus call, any more discussion needs to take place unless others in the working group feel that the consensus call and/or subsequent text is a concern. There was discussion at IETF 118 and suggestion to create an informational document which describes smearing algorithms in some detail but this is separate work and I don't believe that need be specified in the requirements draft.

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

Are you proposing that text be included covering that scenario? If so, I suggest further nuance be described - a server offering NTPv5 synchronising from another stratum with NTPv4 + NTS, or from a separate, private network would be less problematic for example.

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

What text do you think should be part of a subsequent subsection in "4.6.2" - there is no such section and your intent is unclear. Section 4.6.1 "Dependent Specifications" is an acknowledgment that many other specifications depend upon NTP. Do you propose this section be removed, and if so, why?

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

This was suggested text that does not appear contradictory to other text. Do you have a specific concern of this text being in the document?

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

(#3c) I disagree. The document clearly states the protocol must have certain security capabilities - how it gets them is left up to protocol design. If it's NTS or something else I see that as somewhat orthogonal to this document and I'd like to leave the door open to future agility.

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

Could you please clarify what must be supported exactly? I don't believe this document should cover cryptography primitives, only capabilities which I believe are described at sufficient depth to permit protocol design.

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

It's implied any downgrading - as an attack wouldn't just be weakening for the sake of it. Thieves don't cut only half the lock and leave it. I could adjust the text to directly state this.

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

I'm not sure what is unclear here - those under the non-requirements are explicitly stated as out of scope, there is no text stating they are optional, and exist in the document to show that they have been considered as they were mentioned in previous discussion. Their inclusion in the document does not prevent them or other requirements not described being developed for NTPv5 in the future by the working group. Do you suggest this section be removed, or edited?

> 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

Do you propose it be removed, or something else?

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

Previous versions of the document used the mandatory "Security Considerations" section to cover both threat analysis from section 3, and security requirements from section 4.8. They were split out to sit in proximity to their related sections rather than being towards the end of the document. What specifically of authentication and integrity do you think should be stated in the document, and why could it not be placed within section 4.8?

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