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

[Miroslav Lichvar <[e-mail]>]

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