Re: [Ntp] Robert Wilton's Discuss on draft-ietf-ntp-interleaved-modes-05: (with DISCUSS and COMMENT)

[Miroslav Lichvar <[e-mail]>]

On Tue, Jun 29, 2021 at 09:44:35AM +0000, Rob Wilton (rwilton) wrote:
> > That's a good point. The problem is that there is no good way to
> > negotiate it. Some widely-used server implementations drop requests
> > with unknown extension fields. From a missing response the client
> > cannot tell if the server doesn't support it, or if it's under heavy
> > load or there is a packet loss in the network somewhere.
> 
> That makes it sound like the NTPv4 extension mechanism is just broken.  I.e., nobody can define new extensions in practice?

Yes, that's one of the problems we are trying to fix in NTPv5.

NTPv4 practically has only Autokey and NTS as extensions. They are
both authentication mechanisms, so there is no point in negotiating
the extension, e.g. to fall back to unauthenticated NTP. Also, NTS has
a separate protocol for key establishment (NTS-KE). If there is a
misconfigured client trying to use a server that does not support it,
at least there should be a "Could not connect" error message.

> But it isn't clear to me how processing this as a bogus packet helps (noting that I don't know NTP).

A client request is never bogus. Only server response can be bogus,
for a client that doesn't support the interleaved mode, if it somehow
managed to form a request that from the server's point of view looks
like interleaved. This doesn't happen in practice as far as I can
tell.

> E.g., looking at figure 1 in section 2, then what would the flow look like between a client that supports interleaved mode and a server that doesn't know this extension at all?
> 
> I presume that the first 2 packets (client (B) -> server, server(B) -> client) would just be regular basic NTP.
> At this stage, wouldn't the client now send an I mode packet to the server?  Wouldn't the server treat this as a bogus packet, drop it, and not reply?  Or does the server still reply regardless in this scenario? 

A server is always expected to respond (except rate limiting, etc). If
it doesn't support the interleaved mode, or has the support disabled,
it doesn't care in what mode the request it is and always responds in
the basic mode. Clients are required to accept it, even if they are
sending interleaved requests.

Thanks,

-- 
Miroslav Lichvar