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

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 <mlichvar@redhat.com>
wrote:

> 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
>
> _______________________________________________
> ntp mailing list
> ntp@ietf.org
> https://www.ietf.org/mailman/listinfo/ntp
>