Re: [Ntp] [EXT] Re: I‑D Action: draft‑ietf‑ntp‑ntpv5‑requirements‑00.txt

[Danny Mayer <[e-mail]>]

On 8/12/22 10:26 AM, David Venhoek wrote:
> Given the comments on the refid and its uses and desires around it, I
> think it would be good to rework that section of the requirements
> document somewhat.
>
> As I can tell, there seem to be two desires here, each of which has
> different requirements. Perhaps we should reformulate (and even split)
> this section to better reflect the two desires here. If i have some
> time this weekend I will try to make a suggestion via the drafts
> github repo.
>
> Going into the nitty gritty for discussion right now, I see the
> following two parts to the future of refids:
>
> 1. A server provided identifier for logging and allow/deny listing
> I'm not a hundred percent sure on whether we should want this in
> NTPv5, but if we do, it seems weird to me to rule out something like
> an FQDN since those are basically the identity building blocks on the
> internet. If we want this name to be anything more than just something
> the server claims about itself and want any trust-based backing for
> it, FQDNs seem to me at least an option worth considering given the
> existing trust infrastructure around them.
This makes no sense. NTP is based on UDP which is both connectionless 
and stateless. There is no way to validate that something sent to you 
can be relied upon to deal with allow/deny listing. DDOS exploits take 
advantage of this to fake the from IP address. There's nothing to ensure 
that an identifier added can be trusted.
> 2. Loop detection
> Thinking about it, I think refids are unnecessary for loop detection,
Actually they ARE necessary. The problem has to do with the fact that 
packets can be sent out on different IP addresses and that includes 
broadcast and multicast ones.
> and although they do accelerate rejection of some connections faster,
> I think we can do with just the stratum mechanism for loop rejection.

Nope, the most reliable result may be the one you sent out to the server 
that's sending you it's own packet.


> In general though, I think it would be worthwhile to reconsider the
> way we require stratum to be calculated, especially in light of
> clients potentially using an average of more than 1 server as their
> reference. In such cases, I think rather than the current mechanism
> (appoint 1 as "the" upstream and add 1 to its stratum) we should at
> least consider specifying that the nodes stratum should be at least 1
> higher than the largest stratum of a server which it "used" (in the
> sense that it directly influenced steering, rather than just
> truth-finding) in synchronization. Similar updates should probably
> also be considered around path-length/error estimates included in the
> information send by an NTP server. Wording of both however is going to
> be somewhat tricky in light to the loosening (which we definitely
> should keep in my opinion) on algorithms.

That's what a server should be doing. It's always 1 higher than it's 
chosen server. I don't think that this is clear enough in RFC5905.

Danny