Subject: Re: [Ntp] WGLC: draft-ietf-ntp-refid-updates (Network Time Protocol REFID Updates)

From: Miroslav Lichvar <[email-masked]>
Date: Wed, 5 Dec 2018 18:36:54 +0100

On Tue, Nov 06, 2018 at 09:05:19PM +0000, Karen O'Donoghue wrote:
> 
> Folks,
> 
> This message initiates a three plus week working group last call for:
> 
> Network Time Protocol REFID Updates
> https://datatracker.ietf.org/doc/draft-ietf-ntp-refid-updates/

This document was started a long time ago and it had some nice
improvements, but I'm still not sure the proposed changes are worth
the problems they would cause. This was discussed many times before,
so just a quick summary of the issues I see:

The proposed IPv6 refid is not compatible with RFC 5905. This will
cause issues between new and old implementations. We can discuss what
impact these issues would really have, but they do exist.

Shrinking the refid space for IPv6 to 24 bits will make collisions
between IPv6 addresses more likely. There are public servers with IPv6
addresses that didn't collide before, but would collide with the
proposed change. I don't see a point in avoiding collisions between
IPv6 and IPv4 addresses, when the total number of collisions would be
much larger.

The NOT-YOU refid may have some small security benefits, but it breaks
existing use cases of the field.

For example, an NTP client can reject servers that are synchronized to
another server used by the client (e.g. A => C and A => B => C).
Hiding the refid will prevent this.

The refid field is useful for debugging. For example, it allows us to
find a small group of servers in a larger group that spreads wrong
information about leap seconds. I think that the time source of a
server shouldn't be secret, at least with public servers, and that's
where the NOT-YOU refid would probably be most useful for security.
I'm conflicted on this.

-- 
Miroslav Lichvar

---

From: Steven Sommars <[email-masked]>
Date: Wed, 5 Dec 2018 13:57:13 -0600

I'm monitoring public NTP servers, many of which are in the NTP pool (
https://www.ntppool.org)
Over twenty stratum 2 servers currently report via the refid field that
they are sync'd to Google NTP servers, time.google.com.
The Google servers implement leap second smearing, which may be
unexpected/unwanted.
There are other examples where a stratum 2+ server sync'd to a faulty time
source.

Implementation of this draft would make such identifications impossible.

On Wed, Dec 5, 2018 at 11:37 AM Miroslav Lichvar <[email-masked]>
wrote:

> _______________________________________________
> ntp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ntp
>

---

From: Harlan Stenn <[email-masked]>
Date: Thu, 6 Dec 2018 00:27:41 -0800

On 11/28/18 2:09 AM, Tal Mizrahi wrote:
> Hi,
> 
> A few comments:
> - "I-DO" is mentioned a few times in the draft, but not defined or
> specified. Some background is required, and also a citation of the I-DO
> draft (if it is relevant).

I've been asking how to do this for quite a while.  I haven't received
any responses yet.

> - IANA Considerations:
>     - Please clarify what you mean by "pseudo Extension Field Type" - does
> this registry exist? There is a registry called "NTP Extension Field Types".

That's the table, and in this case I mean the entry will be added to the
"NTP Extension Field Types" registry, but it will not be used as a real
extension field type.

This is also described in
https://datatracker.ietf.org/doc/draft-stenn-ntp-extension-fields/ .

>     - You requested the value 0xFFFF, which is also requested in the I-DO
> draft. How is this conflict going to be resolved?

My notes show:

0xFFFE	I-DO Leap Smear REFIDs
0xFFFF	I-DO IPv6 REFID hash

These values are used in the I-DO proposal, to indicate the ability to
offer functionality.

I believe they are talking about the same thing, but maybe I am mistaken.

Perhaps I don't understand what you believe is in conflict.  Please tell
me more.

It will, of course, depend on what happens to the I-DO proposal.  But
that code will soon see the light of day, so we should be prepared for this.

> - There are a few informal-early-draft-oriented sentences, including a few
> instances of "...", a few sentences in brackets [],

The ... instances are to indicate that there is text in the referring
document in the first and third cases.  In the second case, it's merely
punctuation that leads the reader to the next paragraph, which contains
significant relevant content.

What do you propose instead, for any of these cases?

The [] stuff is content where I expected there to be some questions or
comments.  Since there has been no feedback on these points, items in []
will/should be removed for publication.

> - The section "Questions" should be omitted at this point, as this is WG LC.

Yes.

> - As always, I suggest to add a general comment to the security
> considerations section: "The security considerations of time protocols in
> general are discussed in [RFC7384], and specifically the security
> considerations of NTP are discussed in [RFC5905]."

Happy to make that change, thanks!

H
--
> Cheers,
> Tal.
> 
> 
> On Tue, Nov 6, 2018 at 11:05 PM Karen O'Donoghue <[email-masked]> wrote:
> 
>>
>> Folks,
>>
>> *https://datatracker.ietf.org/doc/draft-ietf-ntp-refid-updates/
>> <https://datatracker.ietf.org/doc/draft-ietf-ntp-refid-updates/>*
>>
>> Please review the referenced document and send any comments to the mailing
>> list including your assessment of whether this document is mature enough to
>> proceed to the IESG. Please note that these messages of support for
>> progression to the mailing list will be used to determine WG consensus to
>> proceed.
>>
>> Please send all comments in by COB on Friday 30 November. We realize this
>> is a bit longer than normal but we are coming out of an IETF week and
>> heading into the Thanksgiving holiday in the US.
>>
>> Thanks!
>> Karen and Dieter

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