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

From: Robert Wilton via Datatracker <[email-masked]>
Date: Mon, 28 Jun 2021 08:55:52 -0700

Robert Wilton has entered the following ballot position for
draft-ietf-ntp-interleaved-modes-05: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ntp-interleaved-modes/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Hi,

Disclaimer, I don't know NTP.

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 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?  Or is it simply the
increase in packet length that is an issue?

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.

Regards,
Rob

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Note, it looks like the wrong shepherd writeup has been uploaded on the datatracker page.

---

From: Miroslav Lichvar <[email-masked]>
Date: Tue, 29 Jun 2021 10:53:03 +0200

Thanks for the review.

> me that this pseudo-extension will operationally make NTP harder to manage and

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.

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

> seems to be sending me garbage" error.

I think this would have the same problem as the negotiation.

-- 
Miroslav Lichvar

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Tue, 29 Jun 2021 09:44:35 +0000

Hi Miroslav,

Please see inline ...

> -----Original Message-----
> From: Miroslav Lichvar <[email-masked]>
> Sent: 29 June 2021 09:53
> To: Rob Wilton (rwilton) <[email-masked]>
> Cc: The IESG <[email-masked]>; [email-masked]; ntp-
> [email-masked]; [email-masked]; [email-masked]
> Subject: Re: Robert Wilton's Discuss on draft-ietf-ntp-interleaved-modes-05:
> (with DISCUSS and COMMENT)
> 
> Thanks for the review.
> 

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.

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

> 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

---

From: Miroslav Lichvar <[email-masked]>
Date: Tue, 29 Jun 2021 12:17:47 +0200

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

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

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

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Tue, 29 Jun 2021 11:09:27 +0000

> Sent: 29 June 2021 11:18
> > That makes it sound like the NTPv4 extension mechanism is just broken.
> I.e., nobody can define new extensions in practice?
> 
> 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,
> like interleaved. This doesn't happen in practice as far as I can

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

---

From: Miroslav Lichvar <[email-masked]>
Date: Wed, 30 Jun 2021 11:46:36 +0200

>    direction.  Such packets are called bogus packets in RFC 5905.

I can see how this paragraph is confusing. It was a late addition. It
should be improved. Bogus packets are responses, not requests.

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

No, servers that don't support the interleaved mode don't look at the
origin timestamp at all. They are stateless, they wouldn't know if it
was their previous TX or RX timestamp and most clients set it to 0
anyway.

This is different in the symmetric mode where both ends have to check
it and what RFC 5905 is mainly about as a more general case of the
client/server mode.

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

Yes.

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

The server wouldn't reach that part of the function. It would end in
the FXMIT case.

Thanks,

-- 
Miroslav Lichvar