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

[Eric Rescorla <[e-mail]>]

Eric Rescorla 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:
----------------------------------------------------------------------

Rich version of this review at:
https://mozphab-ietf.devsvcdev.mozaws.net/D3844

I notice that a number of the recommendations here differ from those
in NDSS16. In particular the following recommendations from that paper
do not seem to appear:

- Do not put INIT in the reference ID on restart
- Do not send KoD
- Disable fragmentation
- Randomize source ports

I'm not saying that all of these recommendations need to be in this
document, but I am curious why they are not and would tend to think
that one should document why they are not.



DETAIL
S 2.1.
>      response to a small query, which makes it more attractive as a vector
>      for distributed denial-of-service attacks.  (NTP Control messages are
>      discussed further in Section 3.4).  One documented instance of such
>      an attack can be found here [1], and further discussion in [IMC14]
>      and [NDSS14].  Mitigating source address spoofing attacks should be a
>      priority of anyone administering NTP.

what does this text mean? What practices can I engage in as an NTP
server that mitigate source spoofing attacks? The next paragraph seems
to largely talk about traffic *sources*. Is the assumption that the
NTP server is supposed to do BCP 38 filtering? That seems not that
effective.

As a smaller point, I see that this text says "should", not SHOULD. Is
that a mistake or is this intended not to have any normative force?


S 3.2.
>      [RFC5905].  It is RECOMMENDED that that NTP users select an
>      implementation that is actively maintained.  Users should keep up to
>      date on any known attacks on their selected implementation, and
>      deploy updates containing security fixes as soon as practical.
>   
>   3.2.  Use enough time sources

I note that you don't seem to be recommending that people use Chronos
(http://wp.internetsociety.org/ndss/wp-
content/uploads/sites/25/2018/02/ndss2018_02A-2_Deutsch_paper.pdf),
which, as I understand it, is compatible with existing NTP servers but
far more resistant to spoofing. Is there a reason why? Assuming that
there is a good reason, that seems like it should be covered here.


S 3.2.
>      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.

It's not really possible to evaluate this advice without any
description of the threat model, which is pretty sketchily covered
below. In particular, if an attacker controls my network, then it's
basically like having one NTP server, no matter how many people I am
talking to, and even an inaccurate but secure server (e.g., tlsdate)
is superior.



S 11.3.
>      [10] https://support.ntp.org/bin/view/Support/ConfiguringNTP
>   
>   Appendix A.  NTP Implementation by the Network Time Foundation
>   
>      The Network Time Foundation (NTF) provides the reference
>      implementation of NTP, well-known under the name "ntpd".  It is

What makes this the reference implementation? Generally, the IETF does
not bless specific implementations as reference implementations unless
they themselves appear in the RFC (as with Opus).


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

S 3.1.
>      implementations, on many different platforms.  The practices in this
>      document are meant to apply generally to any implementation of
>      [RFC5905].  It is RECOMMENDED that that NTP users select an
>      implementation that is actively maintained.  Users should keep up to
>      date on any known attacks on their selected implementation, and
>      deploy updates containing security fixes as soon as practical.

This text is kind of hard to follow. It seems like it is making two
entirely separate points:

1. It is important to have accurate time.
2. It is important to have an up-to-date implementation of NTP.

I agree with both these claims, but they don't seem that closely
connected. It's true that an out-of-date version of NTP might lead to
inaccurate time, but it might also lead to (for instance) arbitrary
code execution on the client. For this reason, I would suggest that it
would be wise to separate these two paragraphs.


S 3.2.
>   
>      o  If there are 2 sources of time and they agree well enough, then
>         the best time can be calculated easily.  But if one source fails,
>         then the solution degrades to the single-source solution outlined
>         above.  And if the two sources don't agree, then it's impossible
>         to know which one is correct by simply looking at the time.

This isn't strictly true. Consider the case where I have an iPhone and
the onboard clock reads 2018-12-19 and the NTP server reads 2001. I
know the NTP server is wrong because iPhones didn't exist in 2001.


S 3.4.
>      optionally authenticated control of NTP and its configuration.  Used
>      properly, these facilities provide vital debugging and performance
>      information and control.  Used improperly, these facilities can be an
>      abuse vector.  For this reason, it is RECOMMENDED that publicly-
>      facing NTP servers should block mode 6 queries from outside their
>      organization.

Why are these facilites an abuse vector


S 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.

Why would this work? Some sort of rate limit on the server.


S 3.5.
>      attack is to convince the time server to stop serving time to the
>      system whose address is being forged.
>   
>      If a system is a broadcast client and its system log shows that it is
>      receiving early time messages from its server, that is an indication
>      that somebody may be forging packets from a broadcast server.

You need to provide citations for broadcast client and broadcast
server, even if they are just to some section of the NTP spec.


S 3.5.
>      receiving early time messages from its server, that is an indication
>      that somebody may be forging packets from a broadcast server.
>   
>      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

Why do you say "unusually fast". My understanding is that it's
actually quite common to be seconds off.


S 4.1.
>      periodically.  However, NTP does not provide a mechanism to assist in
>      doing so.
>   
>      [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.  Implementations will soon be

This comment about MD5 kind of comes out of nowhere. some context for
why I would think I should use MD5 would help.


S 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.  Implementations will soon be
>      available based on AES-128-CMAC [I-D.ietf-ntp-mac], and users are
>      encouraged to use that when it is available.

Do you want to use 8174 language here? Also, I-D.ietf-ntp-mac has
already been approved, so it seems like given the long latency between
here and the RFC, we should write this in the present tense rather
than the future tense.



S 4.1.
>      inclusive, and a label which indicates the chosen digest algorithm.
>      Each communication partner adds this information to its own key file.
>   
>      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.

Does *every* implementation have a key file like this? I'm not sure
what the point of this sentence is.


S 5.2.
>      o  Configure the ntp client to only ignore the panic threshold in a
>         cold start situation.
>   
>      o  Add 'minsane' and 'minclock' parameters to the ntp.conf file so
>         ntpd waits until enough trusted sources of time agree on the
>         correct time.

This seems pretty implementation specific.


S 5.4.
>      when asked to do so by a server.  It is even more important for an
>      embedded device, which may not have an exposed control interface for
>      NTP.
>   
>      That said, a client MUST only accept a KoD packet if it has a valid
>      origin timestamp.  Once a RATE packet is accepted, the client should

What's a RATE packet? It's not defined here or cited.


S 6.2.
>      Vendors are encouraged to invest resources into providing their own
>      time servers for their devices to connect to.
>   
>      Vendors should read [RFC4085], which advises against embedding
>      globally-routable IP addresses in products, and offers several better
>      alternatives.

This seems to kind of duplicate S 4.5.



S 6.2.1.
>      The NTP Pool Project offers a program where vendors can obtain their
>      own subdomain that is part of the NTP Pool.  This offers vendors the
>      ability to safely make use of the time distributed by the Pool for
>      their devices.  Vendors are encouraged to support the pool if they
>      participate.  For more information, visit http://www.pool.ntp.org/en/
>      vendors.html [8] .

This too, duplicates 4.5.


S 7.
>      own potential issues.  It means each client will likely use a single
>      time server source.  A key element of a robust NTP deployment is each
>      client using multiple sources of time.  With multiple time sources, a
>      client will analyze the various time sources, selecting good ones,
>      and disregarding poor ones.  If a single Anycast address is used,
>      this analysis will not happen.

I'm not sure I'm following this. The idea here seems to be that a
client would ordinarily be configured with N addresses, but with
anycast it will be configured with 1? Or that all the anycast
addresses will go to the same place? Presumably all the servers in an
anycast group are run by the same entity, in which case is there a
good reason to believe that whatever errors they have will be
independent? In this case, having unicast addresses would seem not to
help.

Separately, how many clients *actually* use >1 server.


S 7.
>      anycast servers may arbitrarily enter and leave the network, the
>      server a particular client is connected to may change.  This may
>      cause a small shift in time from the perspective of the client when
>      the server it is connected to changes.  It is RECOMMENDED that
>      anycast only be deployed in environments where these small shifts can
>      be tolerated.

Who is this guidance to? It seems like the clients might well not
know, but they are the ones who tolerate the shift (or not).


S 11.3.
>   
>      The Network Time Foundation (NTF) provides the reference
>      implementation of NTP, well-known under the name "ntpd".  It is
>      actively maintained and developed by NTF's NTP Project, with help
>      from volunteers and NTF's supporters.  This NTP software can be
>      downloaded from <http://www.ntp.org/downloads.html>

You probably want to explain why the rest of this section follows. For
instance "The remainder of this section describes how to implement
many of the recommendations in this document using that software"


S 11.3.
>      downloaded from <http://www.ntp.org/downloads.html>
>   
>   A.1.  Use enough time sources
>   
>      In addition to the recommendation given in Section Section 3.2 the
>      ntpd implementation provides the 'pool' directive.  Starting with

Where does this directive go? Some conf file, one assumes.


S 11.3.
>      ntp-4.2.6, this directive will spin up enough associations to provide
>      robust time service, and will disconnect poor servers and add in new
>      servers as-needed.  If you have good reason, you may use the
>      'minclock' and 'maxclock' options of the 'tos' command to override
>      the default values of how many servers are discovered through the
>      'pool' directive.

What would those good reasons be?


S 11.3.
>   
>      restrict default -4 nomodify notrap nopeer noquery
>      restrict default -6 nomodify notrap nopeer noquery
>   
>      restrict source nomodify notrap noquery
>      # nopeer is OK if you don't use the 'pool' directive

I assume this is a comment? What is it doing right below a line that
doesn't mention "nopeer"