On 9/25/25 5:34 AM, Miroslav Lichvar wrote:
On Wed, Sep 24, 2025 at 08:19:48AM -0700, Robert Sparks via Datatracker wrote:
Major issues:
It's been awhile since I dove deeply into NTP, but isn't it possible for
responses to be larger than requests in normal operation? This draft requires
that the PTP message containing the NTP response MUST NOT be larger than the
PTP message containing the NTP request. What's supposed to happen if the NTP
response _is_ bigger than the request? Consider either a brief exploration of
this, or an explanation of why it won't be an issue.
Responses larger than requests are normally expected only with the NTP
control (6) and private (7) modes. They are the ones which were used
for the widely known traffic amplification DDoS attacks.
This draft only covers the client-server and symmetric timing modes,
I see the first sentence of the abstract. The document would be better
if this was made explicit in section 2, and that when you do so, you
include the word "only".
where the responses are expected to have the same length as requests
to avoid causing an asymmetric delay in network, which would add an
error to the measured offset.
There is a known exception and that is Autokey (RFC 5906), which can
have some larger responses (e.g. in the certificate exchange). Autokey
was shown to be insecure and already replaced by NTS, but I think this
can still work by padding the request to the maximum expected length
of the response.
I've prepared an update of the paragraph:
An NTP server or peer responding to an NTP request received over the
PTP transport MUST form its response as the NTP TLV using the same
PTP transport. To avoid traffic amplification, the server or peer
MUST NOT send the response if the PTP message containing the NTP
response is longer than the PTP message containing the NTP request.
This requirement impacts Autokey [RFC5906], which has some responses
longer than requests (e.g. certificate exchange). The request SHOULD
be padded with the PTP PAD TLV (type 0x8008) to the maximum expected
length of the response.
This feels on the right path to me.
Minor issues:
Requiring that a PTP message MUST conform to any future version of the PTP
specification doesn't make sense.
The sentence "The PTP message MUST conform to PTP version 2
[IEEE1588-2008], PTP version 2.1 [IEEE1588-2019], or any future
version of the PTP specification." was supposed to give a list of
possibilities. The message can conform to only one version (the
version number is in the header). If some future version for some
reason cannot contain the NTP TLV, that version cannot be used for NTP
over PTP. I guess I should just replace the word "any" with "a"?
My original observation is about the difficulties of trying to speak to
what future protocols (especially not an IETF protocol) might do.
But you're pointing out that the real problem is with the MUST in the
sentence. The paragraph reduces to "PTP implementations are supposed to
follow the PTP specifications", and I suggest you simply remove it from
this document - it's not needed here. What would an implementer do wrong
if it were removed?
Nits/editorial comments:
Please reference BCP14 rather that RFC2119.
That is RFC8174 should be referenced in addition to RFC2119?
A bit more than that. Look at the xml for recently published RFCs for
what the BCP14 description and reference looks like.
Thank you for the review.
_______________________________________________
Gen-art mailing list -- [email protected]
To unsubscribe send an email to [email protected]
