Subject: [Ntp] Adam Roach's No Objection on draft-ietf-ntp-bcp-10: (with COMMENT)

From: Adam Roach <[email-masked]>
Date: Mon, 17 Dec 2018 22:34:55 -0800

Adam Roach has entered the following ballot position for
draft-ietf-ntp-bcp-10: No Objection

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/

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

Thanks to everyone who worked on this document! It's well-written and easy to
understand. I offer a handful of editorial suggestions below.

---------------------------------------------------------------------------

§1:

>  This document also contains information for protocol implementors who
>  want to develop their own RFC 5905 compliant implementations.

Nit: "RFC-5909-compliant" or "[RFC5909]-compliant".

---------------------------------------------------------------------------

§2.1:

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

Nit: "...than..."

The use of "other" implies that NTP is a connection-oriented protocol, which
doesn't match my understanding. I think you want to simply remove "other".

---------------------------------------------------------------------------

§3:

>  This section provides Best Practices for NTP configuration and
>  operation.  Best Practices that are specific to the NTF
>  implementation are compiled in Appendix A.

Please expand "NTF" on first use.

---------------------------------------------------------------------------

§4.2:

Maybe cite RFC 5906 here?

---------------------------------------------------------------------------

§5.2:

Some of the mitigations in here seem specific to one implementation of an NTP
daemon (e.g., reference to "minsane" and "minclock" parameters and to the
"ntp.conf" file). As the remainder of the advice in the document to this point
appears to be generic, I propose that these practices either be described in an
implementation-neutral way; or, if that is not possible, moved to Appendix A.

---------------------------------------------------------------------------

§7:

>  With anycast, a single IP address is assigned to multiple interfaces,
>  and routers direct packets to the closest active interface.

This is kind of a confusing use of the word "interface" -- a simple reading of
this sentence is that you have a single server with, say, multiple network
cards, and the router is deciding which of those cards to send a packet to.
If I didn't already know the meaning of "anycast," this description would
leave me scratching my head.  Perhaps use the term "node" or "server" instead.

---------------------------------------------------------------------------

§7:

>  As
>  anycast servers may arbitrarily enter and leave the network, the
>  server a particular client is connected to may change.

It might be worth noting in the document that these changes can happen due to
factors other than NTP servers coming online and offline, such as changes in
routing tables.  In more extreme cases -- e.g., flapping routes --  this could
result in clients switching between two different servers rapidly.

---------------------------------------------------------------------------

§A.7:

>  (This is easy to do
>  because the origin timestamp on broadcast mode packets is not
>  validated by the client.  By contrast, client/server and symmetric
>  modes do require origin timestamp validation, making it more
>  difficult to spoof packets [CCR16].

Nit: This is missing a closing parenthesis.

---

From: "Ulrich Windl" <[email-masked]>
Date: Tue, 18 Dec 2018 08:01:18 +0100

>>> Adam Roach <[email-masked]> schrieb am 18.12.2018 um 07:34 in Nachricht
<[email-masked]>:

[...]
>>  server a particular client is connected to may change.

While reading this: Does it make sense to say "a client is connected" for a
connection-less protocol like NTP? Replace "is connected to" with "selects"?

> result in clients switching between two different servers rapidly.
[...]

Regards,
Ulrich

---

From: Denis Reilly <[email-masked]>
Date: Wed, 19 Dec 2018 20:32:42 +0000

Adam,

Thank you for your review! Responses are in-line.

Best Regards,

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

-----Original Message-----
From: Adam Roach <[email-masked]> 
Sent: Tuesday, December 18, 2018 1:35 AM
To: The IESG <[email-masked]>
Cc: [email-masked]; Karen O'Donoghue <[email-masked]>; [email-masked]; [email-masked]; [email-masked]
Subject: Adam Roach's No Objection on draft-ietf-ntp-bcp-10: (with COMMENT)

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

Thanks to everyone who worked on this document! It's well-written and easy to understand. I offer a handful of editorial suggestions below.

--DPR: We agree.

§2.1:

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

Nit: "...than..."

The use of "other" implies that NTP is a connection-oriented protocol, which doesn't match my understanding. I think you want to simply remove "other".

--DPR: Agree on all points.

--DPR: Agree, it is expanded in the appendix fir should be expanded here.
---------------------------------------------------------------------------

§4.2:

--DPR: We specifically did not want to cite RFC 5906 here as we are advising that people not use it. In retrospect, we will add it as an informative reference, in case people want the information..

§5.2:

Some of the mitigations in here seem specific to one implementation of an NTP daemon (e.g., reference to "minsane" and "minclock" parameters and to the "ntp.conf" file). As the remainder of the advice in the document to this point appears to be generic, I propose that these practices either be described in an implementation-neutral way; or, if that is not possible, moved to Appendix A.

--DPR: Change to "“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.”

> and routers direct packets to the closest active interface.

This is kind of a confusing use of the word "interface" -- a simple reading of this sentence is that you have a single server with, say, multiple network cards, and the router is deciding which of those cards to send a packet to.
If I didn't already know the meaning of "anycast," this description would leave me scratching my head.  Perhaps use the term "node" or "server" instead.

--DPR: We agree, will change to "servers"

> server a particular client is connected to may change.

It might be worth noting in the document that these changes can happen due to factors other than NTP servers coming online and offline, such as changes in routing tables.  In more extreme cases -- e.g., flapping routes --  this could result in clients switching between two different servers rapidly.

--DPR: we'll add a bit more information to that paragraph. It will read:
As anycast servers enter and leave the network, or the network topology changes, 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.  In extreme cases where the network topology is changing rapidly, this could cause the server connection with a client to rapidly change as well, which can lead to larger time inaccuracies. It is RECOMMENDED that anycast only be deployed in environments where this behavior can be tolerated.

--DPR: Yes, it is! We'll fix it.

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