Re: [Ntp] Last Call: <draft-ietf-ntp-bcp-07.txt> (Network Time Protocol Best Current Practices) to Best Current Practice

[Karen O'Donoghue <[e-mail]>]

Folks,

Just a quick note as I know the editor of this document is unavailable at the moment… Thanks for the review of this document. We will be working on a response over the course of the next couple of weeks and will respond on the ntp mailing list. 

Karen 

> On Sep 26, 2018, at 4:54 PM, Joe Touch <[e-mail]> wrote:
> 
> Hi, all,
> 
> I agree with Tom’s review below. The text is too colloquial and imprecise - especially for describing advice that involves a level of precision itself.
> 
> Many of the recommendations lack rationale - e.g., simply choosing 4 time servers isn’t sufficient to help ensure reliable, accurate results unless they are chosen to reduce the number of shared “ancestor” servers. 
> 
> Even many of the words used need work, e.g., “since” is temporal (not rationale - which should use “because”), and the error is especially problematic in a document describing time. Time itself is referred to as if having a single definition, where the security concerns used as rationale often depends on the use of a single, common, *absolute* shared time scale, not simply “time” (which could also refer to relative time).
> 
> The section on leap smearing fails to underscore the key issue - that NTP is intended to provide a UTC time scale, and leap smeared-time is NOT UTC time, which then undermines the ability to compare NTP time values in a single time scale - which then can impact security protocols, financial transactions, etc. The issue is more than whether public servers should smear; the issue is whether smearing defeats the very definition of NTP as a protocol. BCP should indicate that smearing MUST NOT be used in an NTP server using the assigned NTP port number, period. Frankly, it was a mistake that its support was ever added to the NTP codebase. The only alternative would be for NTP to be extended to report “smeared time” as a *distinct* time scale, which it currently does not. The issue if multiple time scales is discussed in a draft I have been working on, FWIW (draft-touch-time).
> 
> This is just a short list of the failures of this document, where Tom lists others below.
> 
> I do think it would be useful to have a BCP for NTP, but I am not clear that this draft is more than a good reason to start that process. I worry whether using it as a starting point can evolve to the level that we should expect from a BCP.
> 
> Joe
> 
> 
>> On Sep 26, 2018, at 2:57 AM, tom petch <[e-mail]> wrote:
>> 
>> This I-D leaves me uncertain.  Should it be an RFC?  Does it qualify for
>> BCP status?  I think 'maybe' and 'no' respectively
>> 
>> There are a number of detailed glitches - see below - but the overall
>> style is of more concern to me where BCP status is concerned. Statements
>> such as:
>> - the answer is obvious
>> - they agree well enough
>> - Use your NTP implementation's remote monitoring capabilities to
>>  quickly identify servers which are out of sync
>> - the MAC may always be based on an MD5 hash
>> - Readers are encouraged to adopt its mechanisms.
>> - Contact the maintainers of your  implementation for more information.
>> - access control should be used to limit the exposure of this
>> information to inappropriate third parties
>> - A much better approach might be
>> - If, against long-standing recommendation,
>> - Readers of this BCP already understand
>> - Readers are encouraged to check the status of the draft,
>> 
>> some of which I think misleading, none of which I expect to see in a
>> BCP.  Most of it is too vague for me; section 6 stands out as being more
>> of what I would expect to see in a BCP.
>> 
>> Also, it is symptomatic, for me, that the 'Requirements Language' is out
>> of
>> date, lacking reference to RFC8174, and yet I see a lot of lower case
>> words, such as 'recommended', along with some upper case.
>> 
>> Likewise, the I-D starts with
>> 'Many network security mechanisms rely on time'
>> so security is a key part, if not the point, of the I-D yet I find
>> Security Considerations weak.  Section 5 references RFC7384,
>> 'profound threat analysis for time synchronization protocols '.  Yes,
>> but it is ironic that that RFC, detailed, thorough, useful, is only
>> Informational; and it is not mentioned in this, the section on Security
>> Considerations. This section  does not point to threats
>> and mitigations from the body of the I-D, rather it seems to weaken the
>> whole I-D with somewhat vague statements.
>> 
>> Picking up on some details,
>> 
>> Abstract
>> RFC 5905 [RFC5905].
>> looks like a reference which is not ok for an Abstract which needs to be
>> plain text.
>> 
>> 1.1.  Requirements Language
>> out of date no RFC8174
>> 
>> 3.1
>> BCP38 Info page [1] .
>> I did not immediately recognise [1] as a reference to a URL.
>> 
>> 4
>> compilied in Section Appendix A.
>> compiled?
>> 
>> 4.1
>> opposed to an SNTP implementation
>> expansion would be helpful
>> 
>> this section in general lacks any detail of 'how'.  What is agreement,
>> between two
>> sources?  How do I converge three sources?  I look to a BCP for advice
>> on such matters.
>> 
>> 4.2
>> There is a general principle behind this that I would like to see
>> stated, namely to ensure that multiple sources are really independent.
>> I learnt this when I read about Apollo moon shots, but have seen it
>> ignored many times since.  You have to work hard to track back to the
>> details of the technology in use to find out if there is really more
>> than one code base, or chip set, or... in use.  Where security
>> depends on such matters, you really need to do that to ensure you have
>> independence. Appendix A suggests that there is but one code base.
>> 
>> 4.4
>> its syslog shows
>> Is this a recommendation to use the 'syslog' protocol as opposed to
>> YANG:-)  Elsewhere, you use system logs which I think better.
>> 
>> I think too that there is a general point that is missing that these
>> systems
>> need error logging, need (remote) monitoring, else ... well, what is the
>> threat?  what is the mitigation?
>> 
>> broadcast client
>> sounds like a client that broadcasts rather than one that receives
>> broadcasts.
>> 
>> 4.6
>> GNSS
>> I would like expanded on first use
>> 
>> IERS
>> ditto
>> 
>> 4.6.1
>> using a leap-smear can cause your reported time to be "legally
>> indefensible
>> sounds like a SHOULD NOT if this is a BCP
>> 
>> 5
>> /A profound threat analysis for time synchronization protocols are
>> given/
>> A profound threat analysis for time synchronization protocols is given/
>> 
>> 5.1
>> the MAC may always be based on an MD5 hash,
>> MD5 is regarded as too weak in many contexts; does that apply here?
>> 
>> Generally, is there any difference between IPv4 and IPv6 here?  IP
>> addresses are
>> often mentioned but no mention of different versions.  RFC4786, e.g., is
>> explicit that it covers both.
>> 
>> Appendix A
>> 
>> /specific to various implementation of RFC 5905./
>> specific to various implementations of RFC 5905./
>> except that the advice seems to be specific to ntpd and not
>> apply to any other implementation
>> 
>> A.1.2
>> /mode 7 /Mode 7 /
>> 
>> /BY default/by default/ ?
>> 
>> 
>> Tom Petch
>> 
>> ----- Original Message -----
>> From: "The IESG" <[e-mail]>
>> To: "IETF-Announce" <[e-mail]>
>> Cc: <[e-mail]>; <[e-mail]>;
>> <[e-mail]>; <[e-mail]>
>> Sent: Monday, September 24, 2018 6:07 PM
>> 
>> => The IESG has received a request from the Network Time Protocol WG
>> (ntp) to
>>> consider the following document: - 'Network Time Protocol Best Current
>>> Practices'
>>> <draft-ietf-ntp-bcp-07.txt> as Best Current Practice
>>> 
>>> The IESG plans to make a decision in the next few weeks, and solicits
>> final
>>> comments on this action. Please send substantive comments to the
>>> [e-mail] mailing lists by 2018-10-08. Exceptionally, comments may
>> be
>>> sent to [e-mail] instead. In either case, please retain the
>> beginning of
>>> the Subject line to allow automated sorting.
>>> 
>>> Abstract
>>> 
>>> 
>>>  NTP Version 4 (NTPv4) has been widely used since its publication as
>>>  RFC 5905 [RFC5905].  This documentation is a collection of Best
>>>  Practices from across the NTP community.
>>> 
>>> The file can be obtained via
>>> https://datatracker.ietf.org/doc/draft-ietf-ntp-bcp/
>>> 
>>> IESG discussion can be tracked via
>>> https://datatracker.ietf.org/doc/draft-ietf-ntp-bcp/ballot/
>>> 
>>> No IPR declarations have been submitted directly on this I-D.
>>> 
>>> The document contains these normative downward references.
>>> See RFC 3967 for additional information:
>>>   rfc1305: Network Time Protocol (Version 3) Specification,
>> Implementation and Analysis (Draft Standard - Legacy stream)
>>>   rfc5905: Network Time Protocol Version 4: Protocol and Algorithms
>> Specification (Proposed Standard - IETF stream)
>>>   rfc7384: Security Requirements of Time Protocols in Packet
>> Switched Networks (Informational - IETF stream)
>>>   rfc7094: Architectural Considerations of IP Anycast
>> (Informational - IAB stream)
>> 
>