[Ntp] Benjamin Kaduk's Discuss on draft-ietf-ntp-bcp-10: (with DISCUSS and COMMENT)

[Benjamin Kaduk <[e-mail]>]

Benjamin Kaduk has entered the following ballot position for
draft-ietf-ntp-bcp-10: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ntp-bcp/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I see that Ben has already asked about the SHOULDs (vs. MUSTS) for secure
key exchange and prevention from disclosure, in Section 4.1, but I will
make that a Discuss point.  If these are to remain SHOULD, we should say
something about in what case(s) MUST would not be appropriate.

I'm also concerned that there is too much intermingling of general
BCP-worthy advice with implementation-specific knowledge for publication as
BCP in the current form.  I've tried to note instances of this in the
comment section, but for example this includes talking about the "key file"
and the format of the configuration file.  In a similar vein, it's unclear
that the guidance in Appendix A will age well, at least without a more
explicit disclaimer (including disclaimer of normativity) -- e.g,. are the
-4 and -6 modifiers to restrict still needed or best practice?  IIRC a
recent update on my FreeBSD machine updated ntp.conf to just use basic
restrict stanzas without an IP version.

I'm also surprised to see no discussion of the (non-)applicability of IPsec
for NTP traffic, when authenticity or access control is required.  (E.g.,
where IP acls are discussed in Section 5.1)


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

In general the writing could be tightened up some more, especially to
remove duplication and improve transitions.  I've noted several instances
in the comments (mostly tagged with "nit"), as well as some more
substantive comments.

Section 2.1

                   UDP-based protocols such as NTP are generally more
   susceptible to spoofing attacks then other connection-oriented
   protocols.  [...]

nit: was this intended to be "other, connection-oriented, protocols"?

               NTP control messages can generate a lot of data in
   response to a small query, which makes it more attractive as a vector
   for distributed denial-of-service attacks.  [...]

nit: more attractive than what?  (I.e., maybe just "makes it attractive")

   BCP 38 [RFC2827] was approved in 2000 to address this.  [...]

nit: maybe, "BCP 38 was published in 2000 to provide some level of
remediation against address-spoofing attacks"?


                                               It is RECOMMENDED that
   large corporate networks (and ISP's of any size) implement ingress
   and egress filtering.  More information is available at the BCP38
   Info Web page [BCP38INFO] .

BCP 38 already makes this recommendation, and the current document is
supposedly scoped to just NTP, so I would have expected wording more like
"It is recommended that [...] that use NTP implement ingress and egress
filtering.", if we can even be clear about who this directive is supposed
to apply to.

Section 3.1

   Many network security mechanisms rely on time as part of their
   operation.  If attackers can spoof the time, they may be able to
   bypass or neutralize other security elements.  For example, incorrect
   time can disrupt the ability to reconcile logfile entries on the
   affected system with events on other systems.  An application which
   is secure today could be insecure tomorrow once an unknown bug (or a
   known behavior) is exploited in the right way.  Even our definition
   of what is secure has evolved over the years, so code which was
   considered secure when it was written may turn out to be insecure
   after some time.

The first three sentences seem related, but the last two sentences seem to
be talking about something qualitatively different (namely, "more
vulnerabilities being discovered over time", compared to the original's
"accurate time is important for secure and correct operation").  I would
suggest a paragraph break and some transitional language.

Section 3.2

   But even with 4 or more sources of time, systemic problems can
   happen.  For several hours before and after the June 2015 leap
   second, several operators implemented leap smearing while others did
   not, and many NTP end nodes could not determine an accurate time
   source because 2 of their 4 sources of time gave them consistent UTC/
   POSIX time, while the other 2 gave them consistent leap-smeared time.
   See Section 3.7.1 for more information.

   Operators SHOULD monitor all of the time sources that are in use.  If
   time sources do not generally agree, find out the cause and either
   correct the problems or stop using defective servers.  See
   Section 3.5 for more information.

nit: the transition here is a bit odd.  I would suggest either introducing
leap second smearing as a separate concept first (e.g., by
forward-reference to Section 3.7), or making the second quoted paragraph
mention that leap second smearing is one of many potential causes for
disagreement amongst time sources.

Section 3.3

nit: the Q&A style in the second paragraph is not something I usually
expect to read in a BCP.

Section 3.4

                             Used improperly, these facilities can be an
   abuse vector.  [...]

I think (but am not 100% sure) that it's an attack vector on the server
itself, as well as an abuse vector.

Section 3.4

The BCP 38 recommendation was already made above; do we really need to
duplicate it here?

Section 3.5

   If a system starts getting unexpected time replies from its time
   servers, that can be an indication that the IP address of the system
   is being forged in requests to its time server.  The goal of this
   attack is to convince the time server to stop serving time to the
   system whose address is being forged.

nit: the writing here could probably be tightened up.  E.g., things like
"NTP reply packets that do not correspond requests it sent", "an attacker
is forging its IP address in requests to the time server", and "one reason
an attacker would do so could be to convince the time server to".

   If a server's system log shows messages that indicates it is
   receiving timestamps that are earlier than the current system time,
   then either the system clock is unusually fast or somebody is trying
   to launch a replay attack against that server.

Is "receiving timestamps" supposed to be for NTP messages in particular, or
all general syslog traffic?

Section 4.1

   [RFC5905] specifies a hash which must be supported for calculation of
   the MAC, but other algorithms may be supported as well.  The MD5 hash
   is now considered to be too weak.  [...]

nit: "too weak" for what?  (Maybe "considered to be weak and unsuitable for
cryptographic usage" would be better, with a reference to RFC 6151 or
similar.

   To use this approach the communication partners have to exchange the
   key, which consists of a keyid with a value between 1 and 65534,
   inclusive, and a label which indicates the chosen digest algorithm.

Surely there is also the actual cryptographic key material itself!

   Each communication partner adds this information to its own key file.

Does the reader know what a "key file" is at this point in the document?
(Alternately, is "key file" an implementation detail and not a protocol
concept?)

   Some implementations store the key in clear text.  Therefore it
   SHOULD only be readable by the NTP process.  Different keys are added
   line by line to the key file.

Similarly here; the "key file" is only vaguely and implicitly described
(and the line-by-line format is clearly implementation-specific); the main
actionable point here is just to ensure that it is only readable to the NTP
process and the rest could, I think, be safely omitted.

   An NTP client establishes a protected association by appending the
   key to the server statement in its configuration file.  Note that the
   NTP process has to trust the applied key.

If the configuration file format is not standardized, there's not much
useful for us to say here about its contents.  Also, what does "has to
trust" mean?

Section 4.2

The reference is provided only for the attack on autokey but not for
autokey itself.  Is there a stable reference for the autokey protocol (so
that people know what to not use)?

Section 5.1

                                                         NTP control
   queries also leak important information (including reference ID,
   expected origin timestamp, etc.) that may be used in attacks
   [CVE-2015-8139].  A remote attacker can learn this information by
   sending control queries to a target system and inspecting the
   response.

Er, so is it the control *query* that leaks information, or the response to
that query?

           It is recommended that operators SHOULD filter mode 3 queries
   at the edge, or make sure mode 3 queries are allowed only from
   trusted systems or networks.

nit: "at the edge" is not a well-defined concept here.

   Note well that proper monitoring of an NTP server instance includes
   checking the time of that NTP server instance.

Perhaps more explicitly state that the above recommendations for leaf hosts
preclude such monitoring [of leaf hosts]?

Section 5.3

Do we want to say anything about what to do when a (potential) attack is
detected (e.g., make an entry in the system log)?

Section 5.4

It seems worth reiterating that these KoD packets will be accepted in
common usage even when not cryptographically authenticated, which makes the
DoS risk more severe.

I am not sure whether the note about KoD packets indicating potential
attacks is better here or in the previous subsection.

Section 6.1

This is entirely editorial (and thus your preferences outweigh mine), but
if I were writing this I would say something like "an up-to-date and secure
NTP implementation" rather than "the latest NTP updates applied".

Section 7

Would it ever make sense to have multiple (disjoint?) anycast pools so that
clients could still benefit from having multiple servers concurrently
available to compare?

Appendix A.*

It would be helpful to distinguish which strings are literal syntax
that must be used unchanged and which strings are supposed to be
user-replaceable.