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

[tom petch <[e-mail]>]

Denis

Looks good.  One last thought on the XML; when I want to create a
reference I look at the XML source, available on the tools website, for
an I-D or RFC that does things the way I like them.  Whenever I come to
write an I-D, an infrequent occasion, I find that everything has changed
and so, for the most part, lift someone else's source rather than try to
keep up to date with the official guidance..

Tom Petch


----- Original Message -----
From: "Denis Reilly" <[e-mail]>
Sent: Monday, November 12, 2018 6:54 PM

> Hello again, Tom! I appreciate the feedback. (And thank you to Ben
Kaduk, too!)
> Rather than keep things inline, I'll copy some responses to the top
here:
>
> -- on the Security considerations
> TP:
> "   Time is a fundamental component of security on the internet.  As
> such, much of this memo is about security - in particular, see
sections 3, 5 and 6."
>
> The point is that this will be read by security engineers whose only
interest is in security and do not want to read a line more than they
have to;  a sentence such as the above says, 'Tough - in this case, you
are going to have to read the whole memo!'  No need to do more than
refer to the sections.
>
> BK: Exactly so!  I might add a few more words here, though, noting
that it is fundamental in that "the absence of a reliable source of
current time subverts many common web authentication schemes, e.g.,  by
allowing the use of expired credentials or by allowing for replay of
messages only intended to be processed once.
>
> DR: I like Ben's language, so I've replaced it in the latest draft,
and also added your suggestion about referencing the other sections.
>
>
> -- Regarding the BCP38 URL
> > DR: We will change to "More information is available at the BCP38
Info
> Web page" to make clear that it is a URL.
>
> TP: Yes but I was hoping for something more than [1] which in times
gone by woule be a reference to an I-D or RFC; look for example at
RFC6991 which uses meaningful identifiers to link to a reference which
is a URL.
>
> DR: Maybe I am missing something, but when I first started looking
into the XML template, I looked at RFC 2629, which mentions that
external documents are references using <eref> tags, and they show up as
numbers like [1]. Maybe I should be referencing those differently?
>
>
> -- On Time Sources
> > 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.
> >
>
> TP: Well yes but I was hoping that a BCP would say you SHOULD have at
least .... (four?) because if you have less, ....
> so I was wanting 4.1 to be more concrete giving me a clear guidance.
>
> DR:  I did add some language advising operators that they SHOULD use
at least four sources, and that they MAY use fewer, subject to the risks
outlined. This may make some of the other text redundant, which I hope
to catch in the next pass. We struggled a bit with figuring out how
strong to make the language here, since fewer sources can be acceptable
under certain circumstances. But it's clear that the community wants to
see more definitive language here.
>
>
> -- On threats in the Monitoring section
> > 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?
>
> TP: yes, I did not pick up on the threats
>
> DR: I'll look at this in the next pass -- you won't see it in the
version I am about to upload.
>
> Best Regards,
>
> --
> Denis Reilly | Technical Lead | [e-mail] [phone]
>
> -----Original Message-----
> From: tom petch <[e-mail]>
> Sent: Tuesday, November 06, 2018 7:30 AM
> To: Denis Reilly <[e-mail]>; ietf <[e-mail]>
> Cc: [e-mail]; [e-mail]; [e-mail];
[e-mail]
> Subject: Re: Last Call: <draft-ietf-ntp-bcp-07.txt> (Network Time
Protocol Best Current Practices) to Best Current Practice
>
> Denis
>
> Responses in line, which gets a bit messy but seems the least messy
way to tie my reponses to yours.
>
> Tom Petch
>
>
> ----- Original Message -----
> From: "Denis Reilly" <[e-mail]>
> Sent: Wednesday, October 31, 2018 7:54 PM
>
> > Hello, Tom! We appreciate your comments. Responses are in-line.
> >
> > Denis Reilly | Technical Lead | [e-mail]
[phone]
> >
> > -----Original Message-----
> > From: tom petch <[e-mail]>
> > Sent: Wednesday, September 26, 2018 5:57 AM
> >
> > 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.
> >
> > 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.
>
> TP: I think that what is expected of a BCP is a tap into the experts'
> brains without having to have comparable brain power. I think that our
definitions of 'MUST' 'SHOULD' 'MAY' cover that quite well.  I think
that much of the text that I list above that I find too vague qualifies
as 'SHOULD'
> e.g.
>  - the MAC MAY be based on an MD5 hash (or ... MD5 hashes are weak and
SHOULD NOT be used where a stronger one is available)
>  - Readers SHOULD adopt its mechanisms.
>  - maintainers of your  implementation SHOULD be contacted for more
information.
>  - access control SHOULD be used to limit the exposure
>  - Mode 3 queries SHOULD be filtered
>  - If ntpd is started (you have a SHOULD later in the paragraph -
perhaps make that the first sentence)
>  - Readers of this BCP SHOULD understand
>  - Readers SHOULD check the current status of this memo,
>
> > 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.
> >
>
> TP:
> "   Time is a fundamental component of security on the internet.  As
> such, much of this memo is about security - in particular, see
sections 3, 5 and 6."
>
> The point is that this will be read by security engineers whose only
interest is in security and do not want to read a line more than they
have to;  a sentence such as the above says, 'Tough - in this case, you
are going to have to read the whole memo!'  No need to do more than
refer to the sections.
>
> >
> >  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.
> >
> > DR: We agree, we will reword the abstract to eliminate the
reference.
> >
> > 1.1.  Requirements Language
> > out of date no RFC8174
> >
> > 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] .
> > I did not immediately recognise [1] as a reference to a URL.
> >
> > DR: We will change to "More information is available at the BCP38
Info
> Web page" to make clear that it is a URL.
>
> TP: Yes but I was hoping for something more than [1] which in times
gone by woule be a reference to an I-D or RFC; look for example at
RFC6991 which uses meaningful identifiers to link to a reference which
is a URL.
>
> > 4
> > compilied in Section Appendix A.
> > compiled?
> >
> > DR: Yes, we are fixing this typo.
> >
> > 4.1
> > opposed to an SNTP implementation
> > expansion would be helpful
> >
> > 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".
>
> TP: Right but I was fishing for
> SNTP(Secure/synchronised/stream/s...? Not Terrribly Precise) or
whatever it stands for:-)
>
> > 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.
> >
>
> TP: Well yes but I was hoping that a BCP would say you SHOULD have at
least .... (four?) because if you have less, ....
> so I was wanting 4.1 to be more concrete giving me a clear guidance.
>
>
> > 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".
>
> TP: any guidance on how to find when implementations are independent -
I know that that can be a challenge with e.g. security stacks or routing
stacks when a single code base gets widely propagated  - and then,
perversely, a major manufacturer actually produces a different code base
in a new revision of old software!
>
> > 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
> > Is this a recommendation to use the 'syslog' protocol as opposed to
> > YANG:-)  Elsewhere, you use system logs which I think better.
> >
> > 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?
>
> TP: yes, I did not pick up on the threats
>
> >
> > 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
> > I would like expanded on first use
> >
> > 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.
> >
>
> TP: ok
>
> The rest of your responses look good to me.
>
> Tom Petch
>
> > 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
> > the MAC may always be based on an MD5 hash,
> > MD5 is regarded as too weak in many contexts; does that apply here?
> >
> > 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 /
> >
> > /BY default/by default/ ?
> >
> > DR: Agree!
> >
> > 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)
> >
> > ATTENTION: This email came from an external source.
> > Do not open attachments or click on links from unknown senders or
> unexpected emails.
> >
>
> ATTENTION: This email came from an external source.
> Do not open attachments or click on links from unknown senders or
unexpected emails.
>