Subject: [Ntp] Comments on draft-ietf-ntp-data-minimization

From: Harlan Stenn <[email-masked]>
Date: Mon, 5 Nov 2018 19:45:36 -0800

I am generally supportive of
https://datatracker.ietf.org/doc/html/draft-ietf-ntp-data-minimization,
draft 3, and believe 3 substantive changes are needed, and a clarifying
item should be addressed.

1) LI should be set correctly, rather than to zero.  A server that does
leap smearing needs to know if the client is aware of a pending leap
second.  If a leap-second-aware client sends LI=0 to a leap-smearing
server the leap-smearing server will offer leap-smeared time, which will
break expectations.

2) The second paragraph of 4.1 should be deleted, or at least all text
regarding zeroing the Origin and Receive Timestamps should be removed.
A conforming client will already have these fields as zero, so this
additional language is at best confusing or misleading.

3) When the Transmit Timestamp is set to a random number the client must
remember this random number and use it for the loopback check.  The
client must also remember the correct transmit timestamp in order to do
the math and processing with the response packet.  Please add a section
that includes this information.

For clarification, please add a definition/explanation of "blind
spoofing" so people will know exactly what is going on.

-- 
Harlan Stenn <[email-masked]>
http://networktimefoundation.org - be a member!

---

From: Harlan Stenn <[email-masked]>
Date: Mon, 5 Nov 2018 20:36:32 -0800

I forgot another substantive issue:

The Poll interval should be correct, and not zero.  This goes, for
example, to "keeping the flock in sync" when a leap smear is being
applied.erval

Clients should pay attention to the poll value returned by the server
(which is a general point, and not specific to this proposal).

H

---

From: "Dieter Sibold" <[email-masked]>
Date: Tue, 06 Nov 2018 12:35:03 +0700

> server the leap-smearing server will offer leap-smeared time, which 

There is no specification neither how leap-smearing servers nor how 
clients expecting leap-smeared time have to behave. Hence, Inferring 
requirements on this draft from how some implementation currently 
realize leap-smearing is in my opinion not advisable.

---

From: Harlan Stenn <[email-masked]>
Date: Mon, 5 Nov 2018 21:48:37 -0800

Dieter,

How much thought have you given to implementing leap-smear for a general
client pool, some that understand leap seconds and some that don't?

As written the current language would preclude the leap smear
improvements I'm talking about.  If it turns out that we don't need to
send accurate LI information, this draft can be amended.

>From another perspective, please quantify the risk of providing correct
LI values v. a 0 value.

H

---

From: "Ulrich Windl" <[email-masked]>
Date: Tue, 06 Nov 2018 08:11:51 +0100

>>> Harlan Stenn <[email-masked]> schrieb am 06.11.2018 um 05:36 in
Nachricht
> (which is a general point, and not specific to this proposal).

Good point: Where is specified what the poll interval returned by the server
actually means? (I only found: "Poll: 8-bit signed integer representing the
maximum interval between successive messages, in log2 seconds.")

Regards,
Ulrich

>> https://datatracker.ietf.org/doc/html/draft‑ietf‑ntp‑data‑minimization,
>> second.  If a leap‑second‑aware client sends LI=0 to a leap‑smearing
>> server the leap‑smearing server will offer leap‑smeared time, which will
>> break expectations.
>> 
> ‑‑ 
> http://networktimefoundation.org ‑ be a member!
> 
> _______________________________________________
> ntp mailing list
> [email-masked] 
> https://www.ietf.org/mailman/listinfo/ntp

---

From: Harlan Stenn <[email-masked]>
Date: Mon, 5 Nov 2018 23:58:47 -0800

> maximum interval between successive messages, in log2 seconds.")
I'm wondering if your question is a serious question or not.

It's described in 5905.  See 9.2. FXMIT, and A.5.1.1. for more information.

H

---

From: "Ulrich Windl" <[email-masked]>
Date: Tue, 06 Nov 2018 09:42:37 +0100

>>> Harlan Stenn <[email-masked]> schrieb am 06.11.2018 um 08:58 in
Nachricht

> I'm wondering if your question is a serious question or not.

Actually there's exactly one "p.ppoll" in RFC 5905. It seems to be described
in section 13: "...poll interval is fixed at 2 s; otherwise, the host poll
exponent hpoll is set to the minimum of ppoll from the last packet received
and hpoll from the poll routine, but not less than MINPOLL or greater than
MAXPOLL."

I wasn't aware that a server can "pull down" a clients polling interval.

Is the appendix normative?

> It's described in 5905.  See 9.2. FXMIT, and A.5.1.1. for more information.

Thanks,
Ulrich

---

From: Harlan Stenn <[email-masked]>
Date: Tue, 6 Nov 2018 03:13:53 -0800

> and hpoll from the poll routine, but not less than MINPOLL or greater than

In 5905, the server returns the poll interval sent by the client in a
mode 4 response.  And while there's no language requiring exactly this
behavior, there needs to be room for situations like this.  Nobody was
expecting leap smears when NTPv4 was initially being written.

Dave Mills (and several other folks) really hate leap smearing.

I don't have a strong opinion about it, but I look at this as a
mechanism/policy thing.  If somebody needs it, who am I to say they
cannot use it?  So if they're going to use it, I want to make sure that
we have enough mechanism in place to have a reasonable way to provide
that local policy choice.

> I wasn't aware that a server can "pull down" a clients polling interval.

I'm not aware of anything written that REQUIRES the client to follow the
direction indicated by the server's poll response, but this too is a
mechanism/policy choice.

In the case of a leap smear, if the client maintains a long poll
interval in spite of the server telling the client to poll more
frequently, well the client will simply take longer to adjust to the
leap smear.

> Is the appendix normative?

I don't know.  But regardless, we make improvements as often as we can
and folks are free to choose what they want to do - maintain strict
compliance with a Standard that was written as best was possible at some
point in the past, or take advantage of things we've learned since then
and have the best time possible.

It takes a LOT of time and a LOT of testing and interop to decide what's
the best way to go.

H
--

---

From: Miroslav Lichvar <[email-masked]>
Date: Tue, 6 Nov 2018 13:44:19 +0100

On Mon, Nov 05, 2018 at 07:45:36PM -0800, Harlan Stenn wrote:
> 1) LI should be set correctly, rather than to zero

It feels to me this goes against the idea of data minimization.

> A server that does

It's not very clear to me how this helps. Leap smear is supposed to be
used in tightly controlled environments where all clients should
follow the leap smear. There are existing clients that always send
leap=11. ntpdate is one example. Should they not see the smear?

If the server applied leap smear only to clients with leap=0 and they
got the leap bits from other servers during an ongoing smear, e.g. 1
or 12 hours before midnight, should they see a sudden step in the time
from the smearing server?

> additional language is at best confusing or misleading.

I think it's good to have an explanation on why it is important to
zero the origin timestamp.

-- 
Miroslav Lichvar

---

From: Brian Haberman <[email-masked]>
Date: Mon, 12 Nov 2018 08:52:32 -0500

>> Is the appendix normative?

No. Appendices in an RFC are illustrative/informative.

Brian