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 <touch@xxxxxxxxxxxxxx> 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 <daedulus@xxxxxxxxxxxxx> 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" <iesg-secretary@xxxxxxxx> >> To: "IETF-Announce" <ietf-announce@xxxxxxxx> >> Cc: <ntp-chairs@xxxxxxxx>; <ntp@xxxxxxxx>; >> <draft-ietf-ntp-bcp@xxxxxxxx>; <suresh@xxxxxxxxxx> >> 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 >>> ietf@xxxxxxxx mailing lists by 2018-10-08. Exceptionally, comments may >> be >>> sent to iesg@xxxxxxxx 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) >> >
