Re: [Ntp] comments on draft-mlichvar-ntp-ntpv5-03 / Extension fields

[Miroslav Lichvar <[e-mail]>]

On Fri, Nov 26, 2021 at 09:48:20PM -0600, Dan Drown wrote:
> After a day of thinking about my proposal above, I have the following
> concerns:
> 
> * The added packet size, 20+4 bytes is very large for NTP

What would you consider the maximum acceptable size? Please note that
only clients serving time to other servers would need to use it.
Clients that don't serve time, which I think is the most common case,
don't need to care about loops.

As you pointed out, it should be even much larger if we want a lower
false positive rate. But it doesn't have to be transmitted all at
once. The client could get it in multiple parts over multiple requests
(e.g. 4 or 8). This would add a delay to the loop detection.

> * I need to consider compatibility between NTPv4 refid and v5 extension.
> Specifically, what translations happen when switching between versions

Most of the information would be lost if an NTPv4 server was in the
chain. This would be common in the beginning. For NTPv4->NTPv5
compatibility, we could specify a mapping of the 32-bit refids to the
bloom filter.

> * The 1% false positive rate would be a problem when you have a set of
> servers each with 10,000+ clients

Right. It needs to be much lower.

> * Packet logging for monitoring and management would be challenging

You mean manually checking whether a server is in the filter?

> * Operators would probably want some way to make this more deterministic,
> maybe a configured local ref id

It could be saved to disk to not change across service restarts.

> I'm doubting if a bloom filter is the right choice for NTP loop detection.

Are there any other reasonable options?

Maybe a combined approach using 32-bit or 64-bit IDs for detecting
loops between two servers and a slowly updated bloom filter to detect
loops over a larger number of servers?

-- 
Miroslav Lichvar