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

[Denis Reilly <[e-mail]>]

Hello, Eric! Thanks for the review. Sorry for the late reply. I've posted a new version of the draft which incorporate the feedback from the review.

Please see our responses in-line:

--
Denis Reilly  |  Technical Lead  |  [e-mail]  [phone]

-----Original Message-----
From: Eric Rescorla <[e-mail]> 
Sent: Wednesday, December 19, 2018 8:49 PM
To: The IESG <[e-mail]>
Cc: [e-mail]; Karen O'Donoghue <[e-mail]>; [e-mail]; [e-mail]; [e-mail]
Subject: Eric Rescorla's Discuss on draft-ietf-ntp-bcp-10: (with DISCUSS and COMMENT)

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.

Response:
We worked closely with Sharon Goldberg, one of the authors on the referenced paper, when writing this section. While the paper makes the recommendations you list, we simply didn't want to include everything in the BCP, but rather include the things that would have the most immediate impact.

- The advice for not putting INIT in the reference ID on restart might be useful to include after all, as we do give other advice for implementors at the end of the "Avoiding Daemon Restart Attacks" section, so we will add it.

- The paper lists "eliminate NTP's KoD" as one recommendation, but then immediately acknowledges that it eliminates a server's ability to deal with heavy volumes of traffic. We elected to not recommend the elimination of KoDs, in part because there will be many servers deployed who still use them.  Perhaps that is a topic for NTP v5, someday.

- The paper suggests that the attack surface for the NTP fragmentation attack is "small but non-negligible". We felt the attack surface was not large enough
to include directly in this BCP. Since the paper is referenced in multiple places, though, interested readers (such as yourself) would be able to find it.

- The paper mentions Source Port Randomization as a possibility to mitigate the fragmentation attack, but then goes on to say that it is not a "sufficient defense".

--


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?

Response:
As part of another comment, we've moved the "mitigating source address spoofing attacks" sentence to the next paragraph, to further highlight
it's relation to BCP38. 

BCP38 would provide some level of protection against spoofing attacks, but as you note it's not really effective when applied at the server 
level. This is why we give the guidance for large ISP's and networks.

We do have normative language later in that paragraph now saying that "It is RECOMMENDED that ISP's and large corporate networks implement ingress and egress filtering", and we feel that's enough.

--

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.

Response:
The primary goal of Chronos is to provide a NTP client that prevents from time shifting (delay) attacks. Chronos applies a very interesting approach to mitigate such attacks. However, it is not yet a stable standard that can be applied out of the box. Currently, there is a draft draft-schiff-ntp-chronos-01 that is considered for adoption in the ntp working group. This draft aims to standardize the main concepts of Chronos so that NTP implementations may benefit from them. But currently usage of Chronos cannot be recommended.

--

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.

Response:
In Sec. 3.2 we give advice on the number of time sources so that NTP's  inherent selection mechanisms are enabled to protect against unintentionally false time sources. We don't consider the case in which adversaries are able to manipulate NTP packets. This is done in Sec. 4.

--

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

Response:
RFC 5905 directly states that the reference implementation is located at ntp.org, and the NTF currently maintains that. But we understand the point that ntpd has made some improvements that deviate from 5905 as written. So perhaps there is no reference implementation anymore. 

We've removed "reference implementation" from the description in the Appendix.


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

Response:
We think there is some old text here. With the recently improved Security Considerations section, I think we can remove the first paragraph entirely.

--

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.

Response:
Only if the iPhone is smart enough to disqualify the rogue source, in which case you're still back to 1 source. I think the advice here still stands.

--

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

Response:
We've clarified that a bit: "But these facilities can be a vector for amplification attacks when abused."

--


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.

Response:
We've rewritten this for clarity:
If a system starts to receive NTP Reply packets from a time server
that do not correspond to any requests sent by the system, that can be
an indication that an attacker is forging that system's IP address in
requests to the remote time server. The goal of this attack would be to
convince the time server to stop serving time to the
system whose address is being forged.

--

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.

Response: We've added the citations.

--


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.

Response: 
changed to "much earlier".

-- 


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.

Response:
We've modified the text to clarify that MD5 is specifically called out in RFC 5905.

--


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.

Response:
We have no problem making these changes. We wrote it this way because we weren't sure which would get through the gauntlet first, but it looks like ntp-mac will. I will update the 8174 language, and if ietf-ntp-mac gets published before this we'll include it as an RFC.

--

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.

Response:
Ben Kaduk made a similar comment; we will change this to "local key storage", and we've removed that last sentence.

Sicne we are strengthening other normative statements in this section regarding keys, we will also change the guidance here to MUST.

--


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.

Response:
We're comfortable with the first point, as the panic threshold is specified in RFC 5905. But the next draft will have language that makes the second point more general:

Increase the minimum number of servers required before the NTP 
client adjusts the system clock. This will make the NTP client wait 
until enough trusted sources of time agree before declaring the
time to be correct.

--

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.

Response: 
We now include a reference to Section 7.4 of RFC 5905 for RATE packet.


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.

Response:
They are different, as the advice in this section is applicable to embedded device vendors specifically. The advice in RFC 4085 is specifically applicable to embedded devices.

--

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.

Response: 
This does look like it can be cleaned up a bit: we can move this more descriptive text to the Pool Servers section, and then reference that section from this one.


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.

Response:
The idea is that all clients can be configured with a shared NTP server IP Address. There will be multiple servers servicing those requests, and  the network operator can add or remove servers from the Anycast group without having to touch the configuration of each client. 

Even if all servers are managed by the same entity, they can have their own errors: there may be servers with their own GNSS connections, and only one servers' antenna is faulty, for instance. The separate unicast addresses are useful to have a side-channel way to get to the individual time servers to monitor them.

--

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

Response:
The guidance is to the network operators, and ultimately to the users of the  NTP service. Utilizing Anycast in this manner may affect the quality of the 
recovered time. But in some applications, this is preferable to potentially  having to change the configuration of a large number of clients whenever a server is added or removed.

--


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"

Response:
" This appendix contains additional recommendations specific to this implementation."

--


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.

Response:
We agree we should specify this.

--


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?

Response: 
That can be removed. If a user is using 'minclock' or 'maxclock', they already have their own good reasons.

--


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"

Response: 
We've removed the comment.


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