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

From: tom petch <[email-masked]>
Date: Wed, 26 Sep 2018 09:57:29 +0000

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" <[email-masked]>
To: "IETF-Announce" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>;
<[email-masked]>; <[email-masked]>
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
> [email-masked] mailing lists by 2018-10-08. Exceptionally, comments may
be
> sent to [email-masked] 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)

---

From: Joe Touch <[email-masked]>
Date: Wed, 26 Sep 2018 07:54:09 -0700

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 <[email-masked]> wrote:
>