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

From: Karen O'Donoghue <[email-masked]>
Date: Wed, 3 Oct 2018 14:38:06 +0000

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 <[email-masked]> 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 <[email-masked]> 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" <[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: Nick Hilliard <[email-masked]>
Date: Wed, 3 Oct 2018 16:51:22 +0100

Without wanting to be overly contrarian on this--NTP being a prime 
example of a protocol where people have strongly felt opinions--this 
draft as it stands provides a pretty good basic set of practices which 
are immediately relevant for the vast majority of people inclined to 
look at deploying NTP.

The questions that Joe raises about its suitability for purpose comes 
down to the document's intended audience.  There is no doubt that the 
document is of questionable suitability for organisations or people who 
have a hard requirement for high precision, guaranteed quality 
timekeeping, e.g. reference or legal timekeeping.  However, there is 
equally little doubt that if most people who ran NTP services adhered to 
most of the recommendations listed in the draft, that NTP quality in the 
world would increase overall, probably dramatically.  My understanding 
is that the term "BCP" refers to the latter category of people rather 
than to the former, i.e. "best common practice" rather than "practice 
which which is provably consistent with a carefully defined and very 
specific set of inputs with consequently expected output results".

Regardless of intention, it's not going to be helpful to suggest that 
Jimbob's Bait and Tackle get their IT monkey to deploy 6 meinbergs using 
a mixture of gps and dcf77 and then set up a committee to create a set 
of recommendations on auth key deployment.

Conversely, what would be useful would be a clear statement in the 
document about its intended audience, i.e. where the recommendations in 
this draft are relevant, and more importantly, where they are not 
suitable for purpose.

Tom Petch's suggestions are useful - there are several areas where the 
language could be tightened up and tidied, and it would help to have an 
-08 version with not just this taken on board, but also a general 
stylistic edit because the language is genuinely too colloquial if not a 
bit sloppy in places.

On the leap smearing issue, some people are going to do it, and most 
people won't.  It's not useful for the IETF to pretend it doesn't happen 
or castigate people for using it; we don't run other people's systems 
and don't have to deal with their arrays of embedded devices which are 
locked to a specific kernel version which crashes every time ntp jumps 
forward by one second.  Also, we have no real visibility into what would 
happen to any specific organisation if a negative leap second were 
declared, but I suspect a lot of trouble, and a lot more trouble than if 
leap smearing were implemented within specific admin domains. Anyway, 
rant over - it's fine to say "SHOULD NOT" within your own admin domain, 
and "MUST NOT" for interfaces to others, and have a discussion about the 
mechanism in general (which is mostly there).

Nick

> Karen O'Donoghue <mailto:[email-masked]>
> 3 October 2018 at 15:38
> 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
>
>
>

---

From: S Moonesamy <[email-masked]>
Date: Wed, 03 Oct 2018 10:28:29 -0700

At 10:07 AM 24-09-2018, The IESG wrote:
>The IESG has received a request from the Network Time Protocol WG (ntp) to
>The IESG plans to make a decision in the next few weeks, and solicits final
>[email-masked] mailing lists by 2018-10-08. Exceptionally, comments may be

I would like to thank Tom Petch as his review prompted me to take a 
look at this draft.

The write-up states that type of RFC being requested is 
"Informational".  However, the request received (please see above) 
states that the document is intended to be a BCP.  Section 1 states 
that this documentation is a collection of best practices from the 
NTP community.  As a comment about overall document quality, the 
draft needs some work as it looks like a collection of informal 
advice which a person might give instead of advice which has been 
formalized.  It is unclear whether some of the URLs in the draft are 
acknowledgments of past work or advertisements.

Section 3 is about general network security best practices.  The 
section mentions BCP 38 and explains that it has been approved in 
2000.  There is a document from 2008 [1] about it.  Is BCP 38 
well-deployed nowadays?

In Section 4.1:

   "Interested readers should read"

Have the authors read the IETF RFC about uncapitalized letters?  Does 
it apply for the above?

Section 4.1 provides some examples of use of time sources.  It sounds 
like the draft is trying to explain different "use cases" instead of 
specifying a best practice.

Section 4.2 contains some questions about diversity.  It attempts to 
highlight the issues in terms of "are you doing this" and points out 
to a possible issue.

Section 4.6 states that "The IETF maintains a leap second list".  How 
is that list updated by the IETF?

Section 6 has the following: "but these concepts may (or may not) 
have been mitigate".  How are concepts mitigated?

Regards,
S. Moonesamy

1. https://www.ripe.net/publications/docs/ripe-432

---

From: Denis Reilly <[email-masked]>
Date: Wed, 31 Oct 2018 19:54:23 +0000

Hello, Tom! We appreciate your comments. Responses are in-line.

--
Denis Reilly  |  Technical Lead  |  [email-masked]  (585)321-5837

-----Original Message-----
From: tom petch <[email-masked]> 
Sent: Wednesday, September 26, 2018 5:57 AM
To: ietf <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: Last Call: <draft-ietf-ntp-bcp-07.txt> (Network Time Protocol Best Current Practices) to Best Current Practice

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
- access control should be used to limit the exposure of this information to inappropriate third parties

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.

DR: We are always looking for areas to improve the language and make it more like "what people expect" to have in a BCP. We are trying to balance the specific recommendations that we know we can make with the "best practices" that may only apply in certain situations.

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.

DR: That is my mistake, with this being the first time with a document in the IETF. I will add the latest requirements language and we will take a fresh look at the requirements language.

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.

DR: We can mention the RFC7384 directly in the Security Considerations section.  I'd be interested in your ideas about how to make the Security Considerations stronger without simply restating what is in the body of the text.

Abstract
RFC 5905 [RFC5905].
looks like a reference which is not ok for an Abstract which needs to be plain text.

DR: We agree, we will reword the abstract to eliminate the reference.

DR: We will update the boilerplate text (as well as review the text and make sure we are using the proper key words where we man to!)

3.1
BCP38 Info page [1] .

DR: We will change to "More information is available at the BCP38 Info Web page" to make clear that it is a URL.

4

DR: Yes, we are fixing this typo.

4.1

DR: The real intent here was to describe how implementations of RFC 5905 would behave, so we've replaced this text with "An NTP implementation that is compliant with RFC 5905".

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.

DR: The "how" is defined in RFC 5905. The operator has to decide how many time sources he/she is using.

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.

DR: Agree. Change "diversity of sources" to "diversity of sources with independent implementations".

After "may have the same bugs", add "Even devices from different vendors may not be truly independent if they share common elements." 
Then, we can strike "regardless of whether ... different vendors", because that will be redundant.

Denis likes that last line in the comment. After "application software bugs", we will add 
"When having the correct time is of critical importance, it's ultimately up to operators to ensure that their sources are sufficiently independent."

4.4
its syslog shows

DR: We agree, we'll change to "system logs" globally

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?

DR:  We do go into more specifics on particular threats and mitigations in other sections. Would you like that referenced here?

broadcast client
sounds like a client that broadcasts rather than one that receives broadcasts.

DR: We can change that to "client in broadcast mode"

4.6
GNSS

IERS
Ditto

DR: agreed

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

DR: Some users simply don't care if their time is traceable; they care more that all the machines on their network have the same time. We feel "SHOULD NOT" is too strong in this case, and the current language reflects properly that operators who wish to use leap-smearing should be aware of the implications.

5
/A profound threat analysis for time synchronization protocols are given/ A profound threat analysis for time synchronization protocols is given/

DR: Agree

5.1

DR: MD5 is in the process of being deprecated, but many implementations still support it, so it is appropriate to mention here. But we will clarify the situation, as well as include a reference to draft-ietf-ntp-mac , which replaces MD5 with AES-CMAC.

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.

DR: We can clarify (particularly in the Anycast section) that the recommendations cover 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

DR: We did originally make a broad call on the NTP mailing list for information from any of the available implementations, but we only received content specific to ntpd. Since there are no other implementations currently with appendixes, we will refactor to make Appendix A devoted solely to the NTF implementation. In the event this BCP is updated with information from different implementations, they can have their own appendix.

A.1.2
/mode 7 /Mode 7 /

DR: Agree!

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

final
be
beginning of

ATTENTION: This email came from an external source.
Do not open attachments or click on links from unknown senders or unexpected emails.