Re: [Ntp] Mirja Kühlewind's Discuss on draft-ietf-ntp-using-nts-for-ntp-24: (with DISCUSS and COMMENT)

[Marcus Dansarie <[e-mail]>]

Hi Mirja!

Thank you for your work in reviewing the draft. We have carefully gone
over all your comments and DISCUSS points. Each of them is addressed below.

Kind regards,
Marcus Dansarie

On 2020-03-19 14:10, Mirja Kühlewind via Datatracker wrote:
> Mirja Kühlewind has entered the following ballot position for
> draft-ietf-ntp-using-nts-for-ntp-24: 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 IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-ntp-using-nts-for-ntp/
> 
> 
> 
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> Two rather small and hopefully quick-to-address points that I think must be
> clarified before publication of this spec:
> 
> 1) Sec 5.7: "In that
>    case, it MUST be able to detect and stop looping between the NTS-KE
>    and NTP servers by rate limiting the retries using e.g. exponential
>    retry intervals."
> Yes, rate limiting and exponential back-off is good here. However, you anyway
> need to define a maximum number of retries (to actually make it stop at some
> point) and further given some recommendation for an appropriate rate limit
> (e.g. initial retry after 3 seconds...?).

The exact values of this are implementation and application dependent.
What would be considered an acceptable value in one application may be
unacceptable in another. Furthermore, specifying good and safe values
for this would require operational experience that does not currently
exist and probably will not exist until NTS has been in use for a long time.

> 2) Sec 4.1.3: "      Error code 2 means "Internal Server Error".  The server
> MUST
>       respond with this error if it is unable to respond properly due to
>       an internal condition."
> At least for this error, I think you need to specify what the client should do
> on reception. Retry? Immediately? How often? Or wait for a while?

Same reply as above.

> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> In addition to Ben's discuss point on ports which I would also like to see the
> answer to, one more question: My understanding is that the TCP port (123) for
> NTP is not used and will likely never be used in future. Why are you not using
> that port for NTS-KE, as NTS-KE is using TCP?

As Harlan's reply to this comment indicates, there is WG consensus that
NTS-KE should not use the TCP port reserved for NTP. It should also be
noted that NTS-KE is not a protocol exclusively meant for NTP.

> A couple more small questions:
> 1) Sec 4.1.3:
> "The Critical Bit MUST be set."
> If you set the Critical Bit for error records, that would only mean that a
> receiver could send another error in response to that error which again has the
> critical bit set which then could cause another error, and it would go on
> forever. Yes, this case should never happen as all its-ke implementations must
> support error records but maybe it's safer to just not set the critical bit?

An error record loop between client and server is impossible in NTS-KE
for two reasons: First, error records are only allowed to be sent from
server to client. Second, client and server only send a single request
or response per NTS-KE session, see the first paragraph of Section 4.

> 2) Sec 4.1.4: I don't really understand the idea of the Warning record. There
> are no code points defined and there is no explanation given what this could be
> used for. Especially what should a client do that received a warning? Why is
> the error record not sufficient?

According to Section 4.1.4, a client which receives a warning code it
does not recognize MUST treat it as an error. The warning record type is
envisaged for future applications and experimental use. By creating a
"Network Time Security Warning Codes" registry, adding warning codes as
needed in the future is significantly simplified.

> 3) Sec 4.1.5: "   If the NTS Next Protocol Negotiation record offers Protocol
> ID 0 (for
>    NTPv4), then this record MUST be included exactly once. "
> In this case, I guess the critical bit should/MUST be also set to 1?

The reason for why the AEAD Algorithm Negotiation critical bit MAY be
set, instead of SHOULD/MUST, is to ensure compatibility with future
protocols which use NTS-KE, but not the AEAD Algorithm Negotiation record.

As an example, consider a hypothetical future Hyper Rocket Toaster Time
Transfer Protocol (HRTTTP) which uses NTS-KE, but utilizes some
different (and currently undefined records). A client that performs a
handshake with an NTS-KE server which only supports HRTTTP may send
multiple protocol IDs in the NTS Next Protocol Negotiation record. If
the client, for example, sends protocol ID 0 (NTPv4) and the protocol ID
for HRTTTP, it must include the required other records for both
protocols. If the client sets the Critical Bit of the AEAD Algorithm
Negotiation record in this case, the server MUST respond with error code
0 and the negotiation will fail, even though it is semantically correct
and it would have been entirely possible for the server to successfully
respond with HRTTTP cookies.

> 4) Sec 5.7:
> "1280 octets is
>    the minimum prescribed MTU for IPv6 and is in practice also safe for
>    avoiding IPv4 fragmentation.  Nonetheless, senders SHOULD include
>    fewer cookies and placeholders than otherwise indicated if doing so
>    is necessary to prevent fragmentation."
> RFC8085 says "For IPv4, EMTU_S is the smaller of 576 bytes and the
>    first-hop MTU [RFC1122]."
> Maybe it would be appropriate to note that.

This issue was brought up by Suresh in his AD review. We then elected to
keep the current text as is, since it refers to the general case, rather
than the strict requirements of RFC 1122.