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, 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. > 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"? > Nits/editorial comments: > > Please reference BCP14 rather that RFC2119. That is RFC8174 should be referenced in addition to RFC2119? Thank you for the review. -- Miroslav Lichvar _______________________________________________ Gen-art mailing list -- [email protected] To unsubscribe send an email to [email protected]
