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

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

Hi Miroslav,

Please see inline ...

> -----Original Message-----
> From: Miroslav Lichvar <[e-mail]>
> Sent: 29 June 2021 09:53
> 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)
> 
> Thanks for the review.
> 
> On Mon, Jun 28, 2021 at 08:55:52AM -0700, Robert Wilton via Datatracker
> wrote:
> > Thanks for this document, and whilst I agree with Eric that the mechanism
> is
> > clever, I am less convinced that it is wise.  Specifically, I have a deep
> > concern with repurposing fields to have a different meaning with no
> indication
> > other than heuristics on the field to deduce their true meaning.  It feels to
> > me that this pseudo-extension will operationally make NTP harder to
> manage and
> > to debug issues.
> 
> I agree it might feel that way, but as far as I can tell it's not a
> problem in practice. At least I have not heard any complains from
> people who use it.

My concern is less about people who have deployed it, and hence will presumably understand what is going on (but even then it looks that it will be more confusing to debug), and more about servers that have not deployed it and don't know about this optional pseudo-extension and start receiving lots of bogus packets when the clients start using this extension.

Operationally, this seems to come across more as the NTP client is sending the server bad packets, than the client is using an extension that the server doesn't know about.


> 
> > I note that Daniel Franke suggested that this extra information be carried in
> > extension fields, but the authors are concerned with the increase in packet
> > size causing problems.  I didn't really understand the explanation as to why
> > this would be a problem, in that it is comparing the length between basic
> and
> > extended packets, but if the extension was negotiated then could all
> packets
> > use the extension fields and be of the same length?
> 
> 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?

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

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? 



> 
> > Alternatively, would it at least be possible to use an extension field to flag
> > that the fields now have a different meaning?  Would that allow receivers
> to
> > discard the packets with an "unknown extension" warning rather than a
> "the peer
> > seems to be sending me garbage" error.
> 
> I think this would have the same problem as the negotiation.

I still question whether it is wise to be extending a protocol that seemingly doesn't support extensions!

Regards,
Rob


> 
> --
> Miroslav Lichvar