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

["Rob Wilton (rwilton)" <[e-mail]>]

> -----Original Message-----
> From: Miroslav Lichvar <[e-mail]>
> Sent: 29 June 2021 11:18
> To: Rob Wilton (rwilton) <[e-mail]>
> Cc: The IESG <[e-mail]>; [e-mail]; ntp-
> [e-mail]; [e-mail]; [e-mail]
> Subject: Re: Robert Wilton's Discuss on draft-ietf-ntp-interleaved-modes-05:
> (with DISCUSS and COMMENT)
> 
> 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.

I'm still confused.

Section 2 of the draft states:

   The origin timestamp is a cookie, which is used to detect a packet
   which is not a response to the last packet sent in the other
   direction.  Such packets are called bogus packets in RFC 5905.

   A client request in the basic mode has an origin timestamp equal to
   the transmit timestamp from the previous server response, or is zero.

   A client request in the interleaved mode has an origin timestamp
   equal to the receive timestamp from the previous server response.

Looking at the t5 -> t6 packet from client to server in figure 1,
The Org timestamp has been set to the server's previous Rx timestamp, not the Tx timestamp.

When the server receives this packet from the client then would it not regard it as bogus?

And just for clarity, if the server did interpret this as a bogus packet, are you saying that a server (that knows nothing about this extension) would still be expected to respond back to the client with a basic mode packet?

I was trying to look at definition of receive() in A.5.1 of rfc5905, which seems to sometimes do a short return if it receives a bogus packet (at least under some circumstances), but not being familiar with the protocol or code, I cannot tell what the impact of that is.


 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.

Okay.

Thanks,
Rob


> 
> > 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